Boot from disk

Pagina 1/2
| 2

Door aoineko

Paladin (1002)

afbeelding van aoineko

07-01-2023, 23:13

Hello,

In the MSXgl library, we have the possibility to launch directly a program from MSX-DOS 1 or 2 or BASIC, but it's long (time for the system to initialize) and it doesn't look very "professional" (we see the autoexec running).
I would like to add the possibility to start a game directly from a disk.
I would like a setup close to MSX-DOS 1 with 64 KB of RAM visible through the 4 CPU pages and access to the BDOS functions.

According to what I read on the MSX-DOS startup procedure, I just need to rename my program to MSXDOS.SYS and it will be copied in 0100h and executed instead of the original DOS file. And that's it!
I could also change the boot sector to another file name, but using the MSX-DOS 1 format as it is easier.
However, by doing this I interrupt the MSX-DOS boot procedure in state 7 (see MSX2 Technical Handbook) and it is not clear to me in which state the environment is.

The document says that "The environment for MSX-DOS is prepared" but I don't know exactly what it means. I imagine that the part of the memory between 0000h and 00FFh is initialized, but I don't know e.g. if I can use the DOS functions (e.g. to read files). I guess that the access goes to 0005h is not possible since I read that it is MSXDOS.SYS that makes the intermediary with the DOS kernel, but maybe via the address F37Dh like in DISK-BASIC?

I am interested in any advice or information.

Aangemeld of registreer om reacties te plaatsen

Van aoineko

Paladin (1002)

afbeelding van aoineko

08-01-2023, 00:41

Or I can rename my program to COMMAND.COM to let the MSXDOS.SYS initialize (COMMAND.COM is also copied and executed at 0100h). There is a better chance that the DOS environment will be viable in this case.

Van aoineko

Paladin (1002)

afbeelding van aoineko

08-01-2023, 01:20

I did a test with one of my sample programs that uses neither BIOS nor DOS. It works just fine by compile it at 0100h and renaming it MSXDOS.SYS.
See: https://msxvillage.fr/upload/raw_s_game.dsk

However, for a program that uses DOS functions, renaming it MSXDOS.SYS crashes directly (obviously). Renaming it COMMAND.COM (next to the original MSXDOS.SYS) works for few routines (e.g. text display) but not for file management.

The first method makes it easy to have a program of less than 24 KB that launches directly from a disk, but even if I create my own boot code, I don't see how I could access the BDOS functions.

Van aoineko

Paladin (1002)

afbeelding van aoineko

08-01-2023, 02:22

(less than 24 48 KB)

Van aoineko

Paladin (1002)

afbeelding van aoineko

10-01-2023, 09:56

After some tests, launching a program directly from the disk is quite simple. The trick of using MSXDOS.SYS works well and even changing the startup code of the disk is less complicated than I thought.

However, there is still the other problem. How to make sure that the prorgram executed this way can have access to the DISK-BASIC functions since it is not initialized. I imagine that it is possible to initialize it by hand. Is there a recommended method to do this?

Van Briqunullus

Hero (665)

afbeelding van Briqunullus

10-01-2023, 18:40

Well, I would expect that if the diskrom boots a disk, that it has fully initialized itself before that. I've taken a quick look at the MSXDOS.SYS sourcecode. The BDOS handler in there (coming from address 0005h) will directly call the diskrom. There's a jumptable in the source. It also calls routines in the diskrom system area (F368h and F36Bh) to invoke the right slots. I could not find when these routines would be initialized. They contain a jump instruction when in MSXDOS and a simple ret instruction when in Basic.

Van aoineko

Paladin (1002)

afbeelding van aoineko

12-01-2023, 01:55

I've been reading a lot of documentation on the subject lately, but things are still a bit unclear. The only detailed description of the process of booting a floppy disk that I have found is in the MSX2 Technical Handbook. From what I understand, whether I start my own program via code in the boot sector or replace the MSXDOS.SYS, when my program starts the initialization of the Disk-ROM will have taken place (step 1), but not what the doc describes as "the environment for DISK-BASIC is prepared" (step 2 and 3).
I don't understand what the initialization of the DISK-BASIC does in addition to the initialization of the Disk-ROM (which, if I understood correctly, initializes the RAM with the information necessary to make the connected disks work), but if this is necessary to use BDOS functions from a cartridge, why wouldn't it be when I start the game from a disk without using MSX-DOS?

In fact, I have to admit that it is not clear what is the exact role of the Disk-ROM, the DOS Kernel, the BDOS and the DISK-BASIC in the use of BDOS functions.
I tried to make a diagram to help me understand... but it's a failure ^^

Van jr

Champion (379)

afbeelding van jr

12-01-2023, 18:38

I don’t know what Disk BASIC functions you want to invoke from your own program but as you have already found out, you can call BDOS functions from the boot sector or from your fake MSXDOS.SYS (or anything loaded in by the boot sector code) by using 0xf37d as the entry point. Note that if you are using a custom boot sector ROM BIOS will be in page 0 instead of RAM when the boot sector code is called the first time (carry flag clear). This is step 5 in the document you linked in your previous post. Step 7 is when the boot sector code is called again, this time with RAM in page 0, and when the standard boot sector code will load in MSXDOS.SYS at 0x0100 using BDOS calls and run it. You can also use the routines at 0xf368 and 0xf36b to switch between Disk ROM and RAM in page 1. These routines (0xf368, 0xf36b, 0xf37d and others) are set in place by the Disk ROM before the boot sector code is invoked and they may use the RAM area between 0x0000-0x0100 so if you overwrite that area they may stop working. I know at least the Sony HBD-F1 cartridge which I had back in the eighties used RST 30 vector in the BDOS entry internally so it would break if 0x0030 did not contain an inter slot call handler.

Van Latok

msx guru (3938)

afbeelding van Latok

12-01-2023, 19:08

And then I stared at jr in starstruck awe.... To me, you are forever the fMSX/S60 king ^_^

Van Briqunullus

Hero (665)

afbeelding van Briqunullus

12-01-2023, 20:02

Thank for clarifying the boot process. I only wonder if there are any differences between the MSXDOS state and the Disk Basic state. In the debugger I've seen those F368h and F36Bh routines are available only when in MSXDOS. Of course this makes sense, but are there any other differences?

Van aoineko

Paladin (1002)

afbeelding van aoineko

12-01-2023, 21:51

For the moment I still using the default MSX1 boot sector and MSXDOS.SYS replacement.
I had not paid attention but, indeed, at the start of my program, I had the Disk-ROM selected in page 1.
With a call to F36Bh (SETRAM), I end up with the RAM in all pages and my program in 0100h.
I manage to use the STROUT, FOPEN, RDSEQ or FCLOSE functions via F37Dh (BDOS), but for example, SFIRST/SNEXT finds the right number of entries but returns empty file names. The same code works without problems from MSX-DOS.
Any idea where this could come from and/or if there are other things to initialize before using BDOS without DOS?

Pagina 1/2
| 2