Lowest usable address on Page 3

By BadWolf359

Resident (38)

Аватар пользователя BadWolf359

21-03-2023, 16:30

Hey guys!
I'm trying to find out what part of the RAM in Page 3 is used by DOS 1.x, 2.x or Basic and where I can "always" place my own data or code.
On the "Special memory areas in RAM" page I can find the lowest address used is F1C9h to F37Fh Disc Communication Area (Disk-ROM 1.xx).
1) Does that mean the any address below F1C9h is free to overwrite and after my program is done DOS or Basic will restore without problems? After I start in Basic (NMS8250 on openMSX) most data from C000h-F190 seems empty. But some non "cleared (00,FF,00,FF)" data exists. In DOS1.x even more data is filled from C000 and up.
2) In DOS1.x Segment 0 and 3 are used. Segment 0 for any DOS program, and Segment 3 for the data in Page 3. Can I "always" expect the other pages to be free for use? (If I load no other programs like TSRs). And in DOS2.x? How about an IDE or other cartridge? I'm trying not to use Memman or so.

Any tips?

Для того, чтобы оставить комментарий, необходимо регистрация или !login

By snake

Expert (71)

Аватар пользователя snake

21-03-2023, 16:54

16 bit value stored at addresses 64586 and 64587 points to the beginning of reserved area of Dos and Basic. It should be more or less the last 10 kb.

By BadWolf359

Resident (38)

Аватар пользователя BadWolf359

21-03-2023, 18:50

@snake Yes I understand that this value at #FC4A "HIMEM" should contain the address of the end of the available RAM area. But the question is: Will this "always" work in DOS1.x and DOS2.x and Basic.
In DOS1.x this value is at #E5AB in Basic it's #DE79. But the strange thing is that in Basic a lot of the data above this addresses is still mainly "cleared (00,FF,00,FF)" data. With just a few small blocks of (unknown) other values. So is this really used? Has it been used temporarily by Basic.
I guess my question is not "has it been used", but more: "can I use it without breaking DOS or Basic".

Also can I count on the idea that all RAM segments except 0 and 3 are free for use? Even with cartridges inserted that for instance extend basic, like FM-PAC? Or RAM being used by a cartridge like an IDE drive or so.

By DarkSchneider

Paragon (1030)

Аватар пользователя DarkSchneider

21-03-2023, 20:29

I’d say the options are:
- Some areas you could use like the starting at “Data area used by CIRCLE statement” + the Paint space, or the starting at VOICAQ if you don’t use the PLAY, where you have 384 bytes.
- At the start of your program, read the SP value, and add enough (substracting to SP) so the new SP value is just below your first desired fixed usable address. Then restore at program exit.

The cartridges uses their own ROM so they don’t use the RAM segments, but have in mind that they could be mapped into some page at some point, i.e. in DOS at VBLANK the BIOS is set at page 0, but also the DiskROM is mapped at page 1, so if you want to access RAM while VBLANK in DOS, and use the page 1, you would be accessing really to the DiskROM. It depends on the system.

By gdx

Enlighted (6437)

Аватар пользователя gdx

22-03-2023, 01:18

Under MSX-DOS, the current user memory limit address (TPA) is that of the double SP register when a command is loaded. So you have to subtract a number of bytes to evaluate yourself depending on your program to avoid overwriting the stack.

By BadWolf359

Resident (38)

Аватар пользователя BadWolf359

22-03-2023, 11:20

  • In Basic the SP is set at about #DB80. That leaves about 7000 bytes in segment 0.
  • In DOS1.x the SP is set at #D5D1. That leaves about 5585 bytes in segment 0.

I wanted to have a large block of free data (8k+) in Page 3 so I think I'd be better off switching Page 3 to another segment and using the same locations for the all the BIOS variables.
OR (even better)... temporarily storing the Data between #D500 and #EFFF in another segment so I can overwrite this area in Page 3 segment 0. And restore the data just before exiting the application.
I think BDOS commands will not use the #D500 and #EFFF area.

Thanx guys! You've been a lot of help. I think I've got what I need to proceed, but any other suggestions are welcome.

By snake

Expert (71)

Аватар пользователя snake

09-04-2023, 22:01

Bios calls too rely on reserved area, so going over HIMEM isn't recommended (unless you won't use system related code at all).
Stack is part of user memory.
HIMEM value depends also on Msx models.

In my personal experiments i build bloadable binary files, and the only system call they use is DSKIO from Disk Rom. In such kind of environment i managed to use memory up to 61846 for my own purposes. From 61847 to 62335 is directly used by DSKIO (i have found informations in a dutch document from an ancient bbs). Over 62335, DSKIO crashes (i don't know why, i have to investigate).

By Briqunullus

Paladin (769)

Аватар пользователя Briqunullus

10-04-2023, 08:59

Incidently, I was asking myself a similar question this weekend. And I mapped out this area using the MSX system sourcefiles by zeilemaker54. This map is for Disk Basic 1.0 only.

There's more than just the system variables in this area. Without diskdrive, it's the same for every MSX machine.

HIMEM   F380  start of system area
VARTAB  8003

If you substract VARTAB from STKSTP, and then substract 14 you will get the amount of bytes free in Basic. So that's F0A0h - 8003h - 14 = 28815. That value of 14 is hard coded in the Basic rom.

When a diskdrive is present, things get a bit more complicated, and manufacturer specific. Values below are for Philips MSX2. I'll explain other manufacturers later.

var     addr    len     description
        F380            system area
        F1C9    439     disk system area
        F1C1    8       disk driver area (manufacturer specific)
        F197    42      number of drives * drive parameter block size (21 bytes)
        EF97    512     sectorbuffer (512 bytes)
        ED97    512     datasector buffer (512 bytes)
        EB97    512     dirsector buffer (512 bytes)
        E596    1537    FAT buffer drive 0 (3 * 512 bytes + 1)
        DF95    1537    FAT buffer drive 1 (3 * 512 bytes + 1)
        DE92    259     7 fcb's * 37 bytes
HIMEM   DE79    25      bload/bsave work area
VARTAB  8003

To check, DB99h - 8003h - 14 = 23432 bytes free. If you boot with ctrl you get only one drive. It will save a drive parameter block (21 bytes) and a FAT buffer (1537 bytes). You'll gain 1558 bytes, so that will be 24990 bytes free.

The differences will be in the manufacturer specific driver area. This driver resides in the diskrom and different drivers require a different amount of memory. Philips uses 8 bytes, Sony 9 and Panasonic or Sanyo 26. That will result in 23432, 23431 or 23414 bytes free.

There are a few diskroms that only support single sided drives, like the Philips VY-0010 or the Spectravideo SVI-738 X'PRESS. These will need only 1025 byte FAT buffers. And you will end up with 24456 bytes free.

When booting into DOS the map will be different as well, because MSXDOS.SYS will be loaded into high memory.

By snake

Expert (71)

Аватар пользователя snake

21-04-2023, 18:00

I also managed to use memory 62336-64766 for my own purposes. I have tested in a few Msx configurations with different disk rom and it worked. The only system code i use is DSKIO and DSKSTP from Disk Rom and i also hooked interrupt routine directly to address 56.