A bug CALSLT?

Por sd_snatcher

Prophet (3642)

imagem de sd_snatcher

30-08-2011, 00:37

Is it my impression or there's a bug on MSX's BIOS CALSLT routine when handling a call from an expanded slot to an not-expanded slot?

This is the situation:

Emulator: openMSX-0.8.1
Machine: Panasonic FS-A1FX expanded to 512KB
Extension: Panasonic FM-PAC SW-M004

This MSX2+ has RAM on slot 3.0
My program is a .COM running on MSX-DOS v2.20+CMD-2.44.
It calls the MSX-Music BIOS INIOPL (4113h) routine using CALSLT.

When execution returns, the frame-1 (4000h) have the slot 3-3 selected. This happens because the BIOS routines at EE3Fh check that the target slot (1, in this case) isn't expanded and decides to use the non-expanded routines, jumping to EE6Ah directly. This routine at EE6Ah will only get the current primary slot configuration and happily jump to CLPRIM (F38Ch).

Anyone can confirm this problem? Does it only happen under MSX-DOS or it will always happen?

What would be the best work-around for this problem?

Entrar ou registrar-se para comentar

Por sd_snatcher

Prophet (3642)

imagem de sd_snatcher

30-08-2011, 00:54

@konamiman

Could that be the cause of the problems you had on Deyonet BIOS?

Por flyguille

Prophet (3031)

imagem de flyguille

30-08-2011, 01:57

wow, sounds like an ancient microsoft bug.....

Por RetroTechie

Paragon (1563)

imagem de RetroTechie

30-08-2011, 08:31

Hmm... Question If routine returns with slot 3-3 selected in page 1, then expansion slot register for slot 3 (address FFFFh in any slot 3-x) was written to. BUT: If call goes to to slot 1 which isn't expanded, then there isn't any need to switch 3-x subslots. That is: CALSLT routines should be able to do their job only touching the primary slot register (I/O port A8h).

To check: find a C9h byte somewhere in that ROM, call that address & check that 3-x slot configuration is changed (my guess would be no). If yes: trace where it happens. If not: maybe the INIOPL (4113h) routine itself does something weird here?