Disk rom routine 4010H (DISKIO) behaviour

Resident (46)

09-02-2021, 00:29

I compile a bloadable .bin file with SDCC. After the bload"",r basic command, the program boots on page 2, then it mounts ram on all 4 pages and hooks directly 38h address (for interrupts).

Then, every time it needs to read from disk, it mounts disk rom on page 1 and calls 4010H. Results are:

- when it reads data from disk to page 2 it works fine.
- when it reads data from disk to page 3 it works fine unless it doesn't overwrite the stack and the memory beyond the stack.
- when it reads data from disk to page 0 the application crashes (even if it doesn't touch the interrupts hook area).
- when i relocate the stack in order to gain a few memory, the application always crashes, no matter where i read data and where i relocate the stack.

I suspect disk rom relies somehow on main bios and its environment, however, does anyone know something more? Unfortunatly i could not find anything about eventual constraints.

This is the routine i use, it does need 3 global variables to be set:

unsigned short start_sector;
unsigned char number_of_sectors;
unsigned short memory_address;

The routine:

__asm__ ("push af"); __asm__ ("push bc"); __asm__ ("push de"); // stack registers
__asm__ ("push hl"); __asm__ ("push ix"); __asm__ ("push iy"); // otherwise it won't work

__asm__ ("ld hl,(_start_sector)"); __asm__ ("ld d,h"); __asm__ ("ld e,l");
__asm__ ("ld hl,(_memory_address)");
__asm__ ("ld a,(_number_of_sectors)"); __asm__ ("ld b,a");
__asm__ ("ld a,#249"); __asm__ ("ld c,a"); // 248 for 360 kb disk
__asm__ ("ld a,#0"); __asm__ ("neg");
__asm__ ("call #16400");

__asm__ ("pop iy"); __asm__ ("pop ix"); __asm__ ("pop hl");
__asm__ ("pop de"); __asm__ ("pop bc"); __asm__ ("pop af");

Por lintweaker

Champion (369)

09-02-2021, 08:06

Indeed, the diskrom needs some BIOS calls like ENASLT to function.
If your program is for MSX2 and up, maybe you can use the mapper mechanism to get data into page 0 of RAM.

Por ro

Scribe (4360)

09-02-2021, 08:54

The diskrom it self is in page 0, so it can't transfer data to another mapper. Instead, map the memory you have in page 0 to page 2 and load it to that address space. When using DOS2, remember to also use the setmap routines or DOS will reset memmap for you...

Por lintweaker

Champion (369)

09-02-2021, 09:25

ro wrote:

The diskrom is in page 1 (4000-7fffh). Not sure if you made a typo.

Por ro

Scribe (4360)

10-02-2021, 11:09

Funny, I was lookup up this threat cuz I realized exactly that You know, you get inspiration when visiting the loo. At least I do. haha.

Yes, diskrom is in page 1. So thinks like FCB, filename, transfer address etc can't be in page 1 (#4000-#7FFFF) when doing disk actions using BDOS calls #4010/#F37D. And, as mentioned, DOS2 does some mapper resetting. However, I do data transfer to page 2 almost always.

hope that helps.

Por zeilemaker54

Champion (295)

11-02-2021, 08:51

DSKIO and other disk 'BIOS' calls:
If used in a MSXDOS environment, it supports page 0 and 1 transfers
If used in a DISKBASIC environment, it does NOT supports page 1 transfers (it does support page 0 transfers, but is useless because BIOS is at page 0)

The same applies to BDOS calls, so:
00005H does supports page 0 and 1 transfers
0F37DH does NOT supports page 1 transfers (it does support page 0 transfers, but is useless because BIOS is at page 0)

Por snake

Resident (46)

11-02-2021, 10:01

Thank you all for help. Target of the project are all Msx 2 (64 kb ram, no memory mapper, no Dos2).

Stack relocation now works properly (i provided a safe memory area and enough space).
Page 1 has disk rom, so, of course you can't transfer data to adresses 16384-32767.
You can't even transfer data to page 0 because, if i understand correctly, disk rom needs main bios.

I still have issues with page 3. I know bios relies on "work area" (see https://konamiman.github.io/MSX2-Technical-Handbook/md/Appen...), so you can't write on addresses above F380 (if i do, my application crashes). But when i transfer data to the addresses just below this value (for instance F17F-F37F), data will be slightly corrupted (although the application doesn't crash).

Por Daemos

Paragon (1893)

11-02-2021, 10:44

Isn't the stack located at f380? If so you may be corrupting your stack. You can check that with the debugger.

Por ro

Scribe (4360)

11-02-2021, 12:02

Quote:

Target of the project are all Msx 2 (64 kb ram, no memory mapper, no Dos2).

When page 0 is in ROM mode, you have one 16K page of RAM that is not used. In this case Mapper#3. MemoryMapper is just a term, by the way. MSX2 has "memory mapper", on a 64K machine there are 4 blocks of 16K memory. Page 0-3. You can "map" any of these "memory" blocks to a page (0-3).

When using DOS, page 0 is in RAM mode with "memory mapper" block 3. You don't need DOS to do that switching, you can do that yourself just perfectly. Beware if you do, ISR will prolly hang the system. (depending in #38 instructions..). Set it up correctly, and you will have extra 16K RAM at your hands. And transferring disk data to that piece of memory will work just fine

Por zeilemaker54

Champion (295)

11-02-2021, 12:10

snake wrote:

so you can't write on addresses above F380 (if i do, my application crashes). But when i transfer data to the addresses just below this value (for instance F17F-F37F), data will be slightly corrupted (although the application doesn't crash).

Also depending on the running environment, a general rule of thumb:
In a MSXDOS environment, never modify above TPA, top of TPA = (00006H)
In a MSXBASIC environment, never modify above HIMEM

And of course respect the stack (so never modify the stack space).

Por ro

Scribe (4360)

11-02-2021, 12:36

Hai Arjan, good to "see" you again