Mmmm... never noticed SD Snatcher was directly reading to SCC cartridge. Maybe the game code sets F342 to the ROM/SCC slot ? Thinking about that, (still IIRC), the low-level disk driver writes to a (512 bytes ?) buffer in high-RAM first, this is then transfered to the target address. There's a transfer routine for that somewhere... At which level are you doing your emulated part ?
Mmmm... never noticed SD Snatcher was directly reading to SCC cartridge. Maybe the game code sets F342 to the ROM/SCC slot ? Thinking about that, (still IIRC), the low-level disk driver writes to a (512 bytes ?) buffer in high-RAM first, this is then transfered to the target address. There's a transfer routine for that somewhere... At which level are you doing your emulated part ?
Yes, I'm pretty sure about that. The ROM code that performs the read is at 4000-7FFF, so it can't write directly to RAM at 4000-7FFF (at least at high speed).
It first reads to a buffer in high RAM,, this buffer is then transfered to the RAM (F342 slot ?) location by a transfer function located in high RAM too. You have the commented sources of the disk ROM driver here: https://sourceforge.net/projects/msxsyssrc/. Try to follow what is done at 4010.
I can give you more help tomorrow when I'll have access to my stuff (I had the same questions as you when coding SofaRunIt, which is also a disk driver emulation).
Additional note: some parts of the BIOS do not call PHYDIO but have direct entry points in the disk ROM IIRC. Maybe you should try to emulate the lower level functions that are somewhere in the ROM (the SLOTS / RAM / transfers / etc will be done by the ROM disk code). Look for the function that does the real "physical disk i/o" (from the disk i/o ports or mapped memory) and emulate only this one.
EDIT: most of the "file-based" disks (BASIC or MSX-DOS) won't run properly if you re-route only routines at 40xx.
Look for the function that does the real "physical disk i/o" (from the disk i/o ports or mapped memory) and emulate only this one.
The problem is finding where they are...
Louthrax wrote:
EDIT: most of the "file-based" disks (BASIC or MSX-DOS) won't run properly if you re-route only routines at 40xx.
Everything seems to be working fine, and it should work this way...
As per specification, the Disk Driver portion inside the Disk BIOS (the part that handles the hardware differences) are only the jump table routines DSKIO (not PHYDIO), DSKCHG, GETDPB, CHOICE and DSKFMT, besides INIHRD and DRIVES, which I also catch.
Except that I don't know where to write/read when HL is in 4000h-7fffh.
Can you give an example of a program that would not work?
Back home, had a quick look at my sources for SofaRunIt:
- I stand corrected on the "most of the "file-based" disks (BASIC or MSX-DOS) won't run properly if you re-route only routines at 40xx.". I mismatched that with other slot-related changes I had to patch in the disk ROM (as the driver of SofaRunIt is in RAM too, but you should'nt have that problem). So I basically only re-routed routines at 40xx and that worked.
- I'm not changing the slots for reading/writing addresses at 0000-4000 and 8000-FFFF. For addresses 4000-7FFF I take the slot at F342.
- The physical drivers for the disks are located in msxsyssrc/diskdrvs (in the .ZIP from the link I mentionned above). They implement the I/O with the physical drive (and are using a temporary buffer in RAM because they have no choice). All routines like DSKIO and such are implemented here.
I'm wondering which problems you have exactly with your current version? Probably I should have the same issues with SofaRunIt. If not it could help to spot the problem.
By that way are the SCC buffers not located in 8000-BFFF page? Maybe just using changing page 4000-7FFF and not changing anything for the others is the key here ?
I mentioned the SCC issue as an example that not always the transfers are made to/from RAM as per F341h-F344h.
Yes, I am doing exactly as you said. Leave the slots where they are, except for page 1, in that case forcing to RAM seems the only choice. Imagine you are a program running from RAM, and you want to make a disk read to 4000h. You have to first switch page1 to the disk ROM. Then you call the DSKIO function to read the data, and then the Disk Bios has no way to know where page1 was before your call..
Or... You can call the HPHYD hook that uses the CALLF mechanism. Do you know whether CALLF stores the original slot configuration somewhere before changing slots? Maybe the Disk BIOS uses that stored location do discover the original slot configuration for the transfers?
) 