Using OpenMSX ACID MSX machine I'm not sure about RDSLT BIOS call for page 3 behaviour anymore...

Page 1/2
| 2

By friguron

Expert (102)

friguron's picture

03-02-2020, 01:15

Hi all...

I'm trying to create a rock solid 100% universal rom loader for some games that were only publised in .dsk .tap format. What have I achieved as of now? Being able to create a 99% universal one. That is I properly load some test.rom I have into different ram slot layout machines: Toshiba HX-10, Toshiba HX-20E, TurboR, Philips NMS 8250, Philips VG 8020... My .rom loads perfectly on these.
I'm very happy being after having reached sucess on whatever real life model I've come accross (using openmsx emulated modes).

My problem arises when I push the limit and want to use the wicked OpenMSX ACID test machine, which has one of the most bizarre (but legal) slots layout. What happens with my loader routines? They choke in a somewhat unexpected way:

Trying to read a byte from HL=0xC010 using "slot byte" 0x80 (that is expanded slot 0, subslot 0), makes this machine reset with a misconfiguration of slots...
When performing the call, RAM page 3 is in slot 0, subslot 2. The code doing the call is living in Z80 page 1, which in this case it means slot 1 (rom), subslot 3.

Is this behaviour normal? Or rewording it: does RDSLT BIOS call have limitations asking for data when you select a PAGE 3 address as the one I'm using, HL = 0xC010 ?
Does RDSLT work for page 3, when ram and SP are both pointing there just when you do the RDSLT call?
Are RDSLT routines aware of switching the SP/stack RAM page?

Greetings

NOTE: If something is unclear, please ask. I'm not sure my explanation is super sharp Smile OTOH, it's the first time I'm trying to get the most of BIOS routines, and maybe I'm not aware of some "BIOS/SLOT calling routine" basic foundation.

Login or register to post comments

By sdsnatcher73

Paladin (757)

sdsnatcher73's picture

03-02-2020, 05:44

Hi friguron, I cannot really help with the question. What I can do is say woohoo, meaning of course great job so far and cool that you are trying to make this 100% compatible! Keep it up.

By Parn

Champion (474)

Parn's picture

03-02-2020, 11:13

@friguron, The Red Book says RDSLT crashes if you try to access page 3 in any slot other than the one with the Workspace Area, due to the routine switching itself out. I know The Red Book isn't always accurate, but if this is truly the case then it explains the trouble you're having.

By friguron

Expert (102)

friguron's picture

03-02-2020, 11:49

Meh, as I expected, and had already kind of deducted from the observed behaviour, the problems I'm suffering are coming from this situation then... So I struggled while "reverse engineering" some official MSX behaviour to just discover the claim you told me I should have read on MSX Red Book beforehand (facepalm)...

As far as I understand also (and as MSX Red Book seems to also claim) not only RDSLT is affected, but much probably WRSLT and brother routines will also suffer from this expected behaviour...

This can only mean I should redesign my routines, particularly the one in charge of "discovering where in the pslot/sslot space" RAM 3 can be found. I should somewhat reinvent what BIOS does at boot time, this is, not using the stack/RAM (!!), and still managing to find where everything is.
"No-Stack programming" is too challenging for my taste T_T, specially when this is my first real Z80/MSX assembler program ever!

Option B: I might look for some BIOS variable around which might contain the "slot byte" definition for all 4 RAM pages at "ROM CARTRIDGE BOOT TIME". If MSX boot process creates an official "slot byte" definition for RAM page 3, then I'm saved Smile

Some more BIOS reverse engineering time will ensue this evening.
Thank you all anyway!!

By spacemoai1973

Expert (128)

spacemoai1973's picture

03-02-2020, 16:05

Your option B works, but only when DiskROM has been initialised. I guess your loader requires some sort of disk anyway?
RAMAD0: equ F341h ; slot address for RAM in page 0
RAMAD1: equ F342h ; slot address for RAM in page 1
RAMAD2: equ F343h ; slot address for RAM in page 2
RAMAD3: equ F344h ; slot address for RAM in page 3

By friguron

Expert (102)

friguron's picture

03-02-2020, 17:56

Yes, I saw them, but I don't want my loader code to depend on having disk.rom installed or not... Tempting, yes, but I'll try to invent some kind of routine on my own. Let's hope I might get creative and achieve it Smile

Let's remember it's only for the corner case of having RAM pages splitted all around pslot/sslot nightmare space of OpenMSX ACID machine.
I can't remember any comercial machine being THAT wicked (Toshiba HX-20 comes close).

I'll probably need some ingenious heuristic when dealing with my "RAM detection routines" that avoids using RDSLT/WRSLT when exploring z80 logic memory page 3. "Just" this Smile

Thanks again!

By Grauw

Ascended (8699)

Grauw's picture

03-02-2020, 19:04

Your goal is to determine the slot ID of the RAM in page 3? That is very easy to do using a GETSLT routine. No need for RDSLT or WRSLT. The DiskROM variables are for convenience only.

See my post here for more details.

By friguron

Expert (102)

friguron's picture

03-02-2020, 22:23

Ah yes, I see your code, I've just played with it and "it works". But then my original approach (and intention), was discovering which psslot/sslot contains RAM by writing/reading/checking values. Something more "low level" oriented (somewhat, what BIOS does when booting).
Maybe doing that for page 3 is something too ambitious, or even unneeded, or even impossible?
When I say "unneeded" I say it because apparently it seems you can assume things, as you seem to do in your code... I explain myself:

As far as I understand in your routine, you seem to assume that RAM is already set in page 3, SP is also there, fully working, etc... (maybe that's the proper assumption to do!)
Then you just consult FCC4 and FCC8, play with its bits to create whatever data "slot ID" is configured there and then you return it. I see it as "cheating", or at least is a simplified thing compared to my original intention, which OTOH, and as I suggested before, maybe it's not that easily achievable...

That was also one of my original doubts when looking up certain values on System RAM: can you assume that values in FCCX FCCX+4 are always properly set? Who set them in the past? Proper calls to ENASLT done by the BIOS or someone else?
If I had directly written to A8 and FFFF in the past, would FCCX/FCCX+4 System RAM values have got updated accordingly? (As far as I understand, they wouldn't...)

If I assume ram is already in PAGE 3, fully working, with SP pointing to useful data, etc... (as you seem to also assume), and we assume also no one is going to move its page/slots and subslots anymore, then I could just also play with bit of A8 and FFFF for that slot (as you do via FCCC area), and get what I want, am I right?

Or maybe I'm overthinking because I'm such a newbie with this MSX topic? Smile

Thanks and greetings, everything is being very instructive as of now...

By Grauw

Ascended (8699)

Grauw's picture

03-02-2020, 22:57

Indeed page 3 is always the main RAM, this can be assumed. Detection of page 3 RAM by read/writing is unnecessary. You do want to use that method for detecting RAM in pages 0-2 though, because the RAM of each page is not guaranteed to be in the same slot as the ACID tests and some machines or RAM expansion cartridges will show you. (Explanation of memory mappers is omitted.)

GETSLT is a common routine, unfortunately not part of the BIOS but described in the official manuals, which is also used by ROM cartridges to determine which slot they are in and also enabling the second half of their 32K ROM in page 2.

The stack pointer is set up by the environment before executing your program and isn’t normally outside page 3. It can be forced below 0C000H if HIMEM is set low enough via CLEAR, but that would not normally happen unless someone did so on purpose.

The EXPTBL system variables have been initialised by the BIOS boot routine and you can assume they are correct.

The SLTTBL mirror variables in system RAM are updated by the BIOS routines (ENASLT etc.), and you should not write directly to FFFFH without updating the SLTTBL mirror or you break the system environment and all bets are off. Actually I don’t recommend accessing A8H and FFFFH directly unless there is a very strong reason to do so, the BIOS routines will deal with the primary/secondary slot intricacies and make sure everything is updated correctly.

By friguron

Expert (102)

friguron's picture

03-02-2020, 23:04

Fantastic!

After so many days struggling with my own code, and your additional explanations hereby, my final assumptions about page 3 were right!
I just need to tweak my ram3 page routines for ldir/blitting and acid 3 memory layout will be a piece of cake!

Thanks a lot!

By Grauw

Ascended (8699)

Grauw's picture

03-02-2020, 23:22

Glad I could help. By the way, I do think checking the SP location on start-up to see if there is enough free memory for your program’s needs, and aborting if there isn’t, is good practice.

Page 1/2
| 2