Several questions
1) It is indeed not possible to read the palette registers. Some MSX software does keep a copy of the palette in VRAM (I don't know the address by heart). Similarly you can't read the content of the regular VDP registers, but some software (e.g. if you use the BIOS routines to change the VDP registers) keep of copy of the register values in RAM.
2) It's also not possible to get the current value for the VRAM pointer.
3) I don't understand this part of the question. Why would the disk sub-system not yet be initialized?
By Google
1) I do not have ideas about it either.
2) There's a way but I need to formalize it and write algorithm/program
3) if you insert cartridge in slot 1 and have diskrom in slot 3 - diskrom does not get initialized (because cartridge code hacks init process completely).
Given the DIY-ness of GR8BIT, wouldn't it be possible to track the changes in the VDP registers with some additional hardware?
3. How to reliably find disk kernel in the memory/slot/subslot space to initialize and use if it was not intialized?
3) if you insert cartridge in slot 1 and have diskrom in slot 3 - diskrom does not get initialized (because cartridge code hacks init process completely)I've seen it on several occasions: (cartridge) software intercepts normal startup procedure, then tries to do initialization that would have been done if startup procedure hadn't been intercepted. This opens up a Pandora's box of problems; some solvable, some not.
The proper method is to not interfere with that normal startup process, if it involves initialization of hardware that you want to use. All that's needed then, is another way to start, after normal startup process has completed.
Don't know how well it's coded, but a good example might be King's Valley 2: it's a cartridge but supports saving/loading files from disk. IIRC it's done by not starting from cartridge INIT entry, but only initializing an hook there (if I'm not mistaken, a hook that gets called somewhere in BASIC initialization). So hook is set, startup process (including diskROM initialization) continues as normal, and just before getting to a BASIC prompt, that hook is called, the game starts but can use disk BIOS when needed.
Given the DIY-ness of GR8BIT, wouldn't it be possible to track the changes in the VDP registers with some additional hardware?
That's next step. At this time "save state" works with BASIC and DOS, but not with games. Surely special device sitting on the bus can sense access to VDP registers and PSG registers and then dump data to save to disk.
Alwin, thank you for background. That's the way things should work... I saw really weird ways how cartridges and ROM images in .COM format are started... However I think there's a way how to do proper savestate even in these cases.
What you think about this?
http://www.msx.org/forum/msx-talk/hardware/io-capture-cartridge
msx.org/forum/msx-talk/hardware/io-capture-cartridge
(Sorry, it seems I can't post links or my message gets deleted)
.... and PSG registers and then dump data ...
I think for psg you can read all regs directly. Not so sure at 100% however
Here is the link, but as links tend to be posted by spammers, you'll have to do CAPTCHA'ing, I guess: http://msx.org/forum/msx-talk/hardware/io-capture-cartridge

By Eugeny_Brychkov
Champion (457)
13-01-2012, 10:14