RST 30h

Page 2/7
1 | | 3 | 4 | 5 | 6 | 7

By ARTRAG

Enlighted (6192)

ARTRAG's picture

07-10-2018, 11:18

This is exactly what I see following the code in the debugger.
The CALLF function cannot deal with calls to RAM in the same SLOT of the ROM BIOS for page 0.
If the CALLF code is the same in all roms, in all machines where rom and ram are in the same slot, if you try to use CALLF in page 0 you should see that CALLF swaps out iself crashing the machine.

Maybe from the openmsx database it could be possible extract a list of machines with an expanded slot 0 with rom and ram

By gdx

Prophet (2871)

gdx's picture

07-10-2018, 11:46

gdx wrote:

A memory extension should fix it.

Only if Memory Mapper and if DOS2 is installed because otherwise the first RAM found is always selected by the system.

MSXs with RAM in slot 0 or 1 are more difficult to manage memory. HB-500 is even worse since its RAM is in two parts. This bug complicates even more.

By DarkSchneider

Paladin (819)

DarkSchneider's picture

07-10-2018, 12:47

Well the truth is that it should not be your concern. Exclusive software for handling their bad?. Using RST 30H is the official way, as we can see here at List 5.14:
https://www.konamiman.com/msx/msx2th/th-5b.txt

So if the manufacturer did a copy-paste of the BIOS without fixing it, is really your job to fix it?

Then now is only your good will to do extra work if want it to run fine in any manufactured MSX, even if it is a faulty system. I am not much friend about those things. You could try an ENASLT solution for page 0 with the ways I put before in the links instead inter-slot call. Tested on computers with RAM at slot 0 and seems to work.
I don't remember exactly but has the CALSLT the same problem? I think yes.

By ARTRAG

Enlighted (6192)

ARTRAG's picture

07-10-2018, 23:47

FYI
ENASLT cannot swap page 0 without crashing

By ARTRAG

Enlighted (6192)

ARTRAG's picture

08-10-2018, 08:50

And CALSLT is a different entry point to the same code used by CALLF

By DarkSchneider

Paladin (819)

DarkSchneider's picture

08-10-2018, 10:27

For ENASLT:

- If you are under MSX-DOS, you can copy the system one out of page 0 and use it:
https://www.msx.org/forum/msx-talk/development/enaslt-for-page-0-in-msx-dos

- If you are not under MSX-DOS, try this routine:
https://www.msx.org/forum/msx-talk/development/safe-set-bios-and-restore-ram-on-page-0-from-msx-dos?page=3
If you are in a closed environment (like ROM) with your program fully controlling the behavior, the routine could be optimized bypassing all the SLTTBL stuff and precompute the values to apply instead reading and composing on the fly.
But if you'd like to use the system one is comprehensible, so this one is optional. Then there would not be way to ENASLT for page 0 out of MSX-DOS.

I think MSX-DOS has these routines "installed" at page 3 and then has jump vectors at page 0.

By ARTRAG

Enlighted (6192)

ARTRAG's picture

08-10-2018, 15:41

I'm updating a turbo basic program so I can't touch page 1 and 2 if not at initialization time

By ARTRAG

Enlighted (6192)

ARTRAG's picture

08-10-2018, 22:22

I did a bit of tests on msx2 machines with floppy drive.
This is a set of Msx2 machines where CALLF and CALSLT cannot call ram in page 0:

Daewoo CPC-400S
Pioneer UC-V102
Sony HB-F500P
Victor HC-95A

By DarkSchneider

Paladin (819)

DarkSchneider's picture

09-10-2018, 13:29

ARTRAG wrote:

I'm updating a turbo basic program so I can't touch page 1 and 2 if not at initialization time

A hard question then. Maybe putting some REM at BASIC program begin to make room, then place the ENASLT for page 0 code there, and call it with USR.
The code must be written at lower user space, that is where the BASIC code 1st line is placed from, that on MSX2 BASIC is always 8000H.
https://www.konamiman.com/msx/msx2th/th-2.txt

Quote:

3.1 User's Area

The lowest address of the user's area was different in the MSX1 machine whose
amount of RAM was 8K, 16K, 32K, or 64K; in MSX2, it is always 8000H, because
MSX2 machines have at least 64K of RAM. It can be obtained from the content
of BOTTOM (FC48H).

So it is a known data.

It is weird but I can't think about another way at this moment. The other is ignore faulty machines.

By Grauw

Ascended (8208)

Grauw's picture

09-10-2018, 16:22

ARTRAG wrote:

I did a bit of tests on msx2 machines with floppy drive.
This is a set of Msx2 machines where CALLF and CALSLT cannot call ram in page 0:

Daewoo CPC-400S
Pioneer UC-V102
Sony HB-F500P
Victor HC-95A

You can check the wiki pages for all MSX2 machines and look at the handy slot layout tables there. Also you can check openMSX machine XML definitions, for the machines which it emulates.

As I said before, for MSX2+ and up they standardised the slot layout so RAM should always be in slot 3.

DarkSchneider wrote:

The other is ignore faulty machines.

Not sure why you’re calling it faulty. It’s just something that’s not supported by the BIOS, just like you can’t touch page 3. It also seems like a hard thing to fix, because subslot switching code can’t be in page 3, so it needs to be in another, which is page 0 which is why there’s this problem. Only way to fix it would be to check for this case and interslot call a support routine in page 1, but this isn’t functionality provided by the BIOS, probably due to space, overhead and complexity considerations.

In the MSX2+ standard they "fixed" it by standardising the slot layout, but the MSX & MSX2 spec allows it, so the manufacturers are not at fault. And it works fine in DOS, calling ROM from RAM, just not the other way around. Then again switching out the BIOS is a bit on the edge of standard compliant programming anyway if you ask me (but this may be a controversial statement :)).

Page 2/7
1 | | 3 | 4 | 5 | 6 | 7