VVVVVV for MSX

Quoting the MSX Technical Databook Page 42.

And now it's up to you to decide how relevant this all is, nowadays.

Ditto ... I agree with both of you !
Keep up the good work !

I think should not be a soooo big effort to read from the proper location the address of vdp ports.
I also think this game is not soooo time critical that doing a simple RAM fetch to read vdp port address will be impossible.

@hap

Sorry, I didn't wanted to start a holly war on wether one must or not follow the guidelines.

My two cents: It's your game, it's your hobby. It must be fun for you to code it, and I'm glad you took the time for producing such a beautiful piece of art. It's only up to you to decide how your game will behave and where do you want to invest your time.

These days, I'm grateful to anyone tho take their time on producing anything for our beloved system. Be it a new game, a translation, a bugfix, translating documents, a new hardware.

On my side, I just run my standard set of tests I use to catch the main problems that usually arise when developing software MSX machines. It's just a checklist.

I'm not trying to convince you, but let me explain what kind of known problems I try to avoid when using the checklist:

1) Turbo test: This one is pretty simple. If the user forgot to turn off the turbo before running the software, it will still manage to run at the correct speed. Many machines, like the Panasonic 2+ and the ExpertTurbo don't have an external switch to turn it off, don't have the CHGCPU routine in BIOS and would require the user to reset and run the game again. Not a big problem, but your game will certain cause a better impression for running fine. Known "troublemakers" on this category are machines with native turbo:

- Panasonic MSX2+/TR machines
- CIEL Expert Turbo and Expert3
- Victor HC-90/HC-95 machines

2) Subslot handling: This one is a pest. Almost all owners of a MSX with internal subslots have headaches with software that freeze on startup and requires some annoying POKE-1,xxx before running. And there are a lot of examples of ROM games that just don't run on a slot expander, like 1942, requiring the user to remove the slotexpander before running the software. Bad subslot handling certainly causes a terrible impression. Known "troublemakers" in this category are:

- Victor HC-90/HC-95 machines have RAM on slot 0-2
- Philips RAM on slot 2-0 vs Japanese RAM on slot 3-0 "war"
- Game running on external slot expander. It's a shame to require the user to remove the slotexpander before running your software
- Any MSX with plain-64KB (no mapper) with an external memory mapper connected to a higher slot.

3) MSX coding guidelines compliance: The MSX ecosystem is huge. It's impossible to test every kind of hardware combination, be it original or an upgrade. And can we just deny upgrades? Complying to the standard is the best way to assure that your game will run on the vast majority of them. Bellow, I list some machines that are known "troublemakers" in this category:

- Victor HC-9x machines with V9938 will have VRAM corruption when the turbo is enabled if you don't use the BIOS accordingly
- On Brazil, there are many Expert Plus machines upgraded to MSX2/MSX2+. Since their MSX-Engine T7937A don't allow the internal VDP to be disabled, the only option is to configure the V9938 to the 88h/89h I/O ports and replace the EPROM with with the BIOS configured for this I/O ports. This means that software that do direct VDP I/O at 98h/99h I/O ports will fail on those machines, even knowing that they're fully compliant to the MSX standard. The same problem will occur on any similar MSX1 upgraded to MSX2.
- Similar to the previous problem, any MSX with an MSX-Engine inside can't have their individual chips (PSG, PPI) replaced if they broke. One easy/cheap and perfectly compliant way to fix it would be to replace the BIOS with one that redirects the I/O to a new chip, placed on another I/O port. From the standard point of view, this isn't any different than installing a SRAM on another subslot to have your machine upgrade to 512KB memory-mapper, like here.
- MSX Turbo-R machines are known to have their keyboard film easily damaged. Those films are very hard to obtain. It would be very sad to trash such a machine just because of this. One easy and compliant fix would be to build a cartridge with a keyboard connector, and replace the BIOS to access this external keyboard instead. But software that don't follow the guidelines will fail on such machine.
- The MSX-Audio BIOS v1.3 OPLL->OPLn translation will only work if the MSX-Music BIOS is used with compliance to the standard
- Machines with discrete PSG chips usually rely only on the BIOS routines to assure that they PSG will not be fried if the famous value is written on their PSG.

4) BIOS interface test: The BIOS may have it's internal addresses relocated when recompiled. To save some cycles, some programmers just ignored the BIOS jump table and called the routines directly. This caused those softwares to fail on newer generations, or fail even on the same generation. Known "troublemakers" are:

- C-BIOS is a different but perfectly compatible implementation
- The Sharp Hotbit had it BIOS recompiled, instead of a simple binary patch. Some software are known to fail to run on it because of incorrect BIOS access. The most notably example is Konami's Nemesis-3.
- Panasonic FS-A1ST had some routines relocated. Konami Game Master fails on those machines because of this.
- Many MSX1 software are known to fail to run on MSX2/2+/TR machines because of this.

Last but not least, there are other known troublemakers that my checklist still don't catch. Those are:

- Sony MSX2+ machines (HB-F1XDJ and HB-F1XV) are known to have slow VDP access. They require you to respect the "7T states delay" otherwise they usually begin corrupting VRAM data
- Panasonic MSX2+ machines require you to respect the MSX-Music initialization algorithm, otherwise the YM2413 chip will be muted
- MSX Turbo-R machines upgraded to 1MB are known to cause problems on programs that don't handle the memory-mapper correcly

I hope all this tips help MSX programmers to debug if people report problems when trying to run their software. Maybe it's a good idea to compile those known caveats on a MSX programmers guide or on the wiki.

So I read ROM location 6.
And there is written 0x98. So the retargeting fails!
Well I read slot 0. That is where System ROM is supposed to be, no?

So, is the app supposed to save the slot that is selected in page 0 and assume that to be "System ROM"?
That could fix it.
Is that the answer? Is there maybe a standard citation on that one?