Pagina 5/8
1 | 2 | 3 | 4 | | 6 | 7 | 8

Van hap

Paragon (2042)

afbeelding van hap

22-09-2012, 12:32

I'm not gonna let purists of the MSX-standard take away my precious out ($98),a Tongue

EDIT: I've had plenty of chats about MSX standard on IRC, clashing with strong and some grumpy opinions about it, even going as far as saying my software wouldn't be MSX software if it doesn't completely follow the MSX Standard. I get assertive now each time someone brings it up, so excuse me if I come accross as a rebel about this. Nishi

Van Manuel

Ascended (19469)

afbeelding van Manuel

22-09-2012, 12:32

Quoting the MSX Technical Databook Smile Page 42.


Although I/O addresses are defined above, the software must not access those deices directly using the above ports. All I/O accesses must be done using BIOS calls, in order to make the software independent of hardware differences. MSX manufacturers may change some of the hardware from the standard MSX system and maintain software compatibility by rewriting BIOS. The hardware differences would thus be transparent to the software.

The only exception to the above is the access to the VVDP. Locatiosn 6 and 7 o f the MSX system ROM contains the Read and Write addresses of the VDP register. Software that must access the VDP quickly may access the VDP directly by using the addresses stored in ROM.

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

Van Edwin

Paragon (1182)

afbeelding van Edwin

22-09-2012, 12:52

hap wrote:

I'm not gonna let purists of the MSX-standard take away my precious out ($98),a Tongue

I agree. I'm not adhering to that either. I'm coding for fun, not to satisfy people's needs for ridiculous levels of compatibility.

Van Metalion

Paragon (1625)

afbeelding van Metalion

22-09-2012, 14:16

Edwin wrote:
hap wrote:

I'm not gonna let purists of the MSX-standard take away my precious out ($98),a Tongue

I agree. I'm not adhering to that either. I'm coding for fun, not to satisfy people's needs for ridiculous levels of compatibility.

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

Van Huey

Prophet (2694)

afbeelding van Huey

22-09-2012, 15:10

I demand a disclaimer on startup!

Shame on you hap!

Van PingPong

Enlighted (4140)

afbeelding van PingPong

22-09-2012, 15:12

hap wrote:

3) fails: I like to write to I/O ports yes, such as out ($98),a for vdp. IMO using BIOS-calls is unneccesary, and I'd have to learn a new 'API' when I'm already expert on direct hardware access.

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.


Enlighted (6935)

afbeelding van ARTRAG

22-09-2012, 15:50

true, but who cares?
the time and the energies needed to patch code (already working!) to use out (c),a instead of out (0x98),a and to workaround the need of register C is totally wasted: spend it to go further in development.
nowadays the 2 or 3 guys in the world having (and using) hw with different ports (typically msx2 expansions for msx1) will play (eventually) the rom on emulators or on their plain msx1

Van sd_snatcher

Prophet (3659)

afbeelding van sd_snatcher

22-09-2012, 18:58


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.

Van AxelF

Champion (395)

afbeelding van AxelF

22-09-2012, 19:17

Very interesting matter, but maybe we should open a new forum topic about this subject
and discuss it further there.
We can put the results (Or some checklist ) in the WIKI as a guide for programmers
to achieve maximum compatibility for all MSX Systems if the programmer wants to, but is not required.

VVVVVV is damn addictive, great job.

Van hit9918

Prophet (2932)

afbeelding van hit9918

22-09-2012, 19:16

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?

Pagina 5/8
1 | 2 | 3 | 4 | | 6 | 7 | 8