Bootstrapping from FAT formatted floppy disk?

[Benedikt]

Imagine the following scenario:

• A 3.5" drive is connected as drive B
• The disk in it has a FAT file system
• It already contains binaries for some other platform(s), e.g. MS-DOS, MSX-DOS, Enterprise 128, Atari ST
• We want an additional binary for CPCs

Is there any somewhat convenient way to load and run anything from that disk from Basic?
E.g. a few lines to load a "CPCDOS.SYS" from a known, continuous sequence of sectors?

Thank you in advance!

[andycadley]

Assuming you have a DOS capable of reading from FAT, you could just store some CPC binary on there. There's nothing in the FAT filesystem for reserving special sectors for a given machine though.

[Benedikt]

And is there any way to just read a specific sector in a file system agnostic way using Basic and to run it as machine code?
Putting a write-protected system file in a known sequence of sectors is solved problem.

The question is about bootstrapping, i.e a DOS with the relevant capabilities is not already running.

[Prodatron]

There is

BPB_RsvdSecCnt

"Number of reserved sectors in the Reserved region of the volume
starting at the first sector of the volume. This field must not be 0.
For FAT12 and FAT16 volumes, this value should never be
anything other than 1. For FAT32 volumes, this value is typically
32."

So as all discs are FAT12, there is no chance for having additional reserved sectors at fixed LBAs beside the boot sector.
But you can always reserve clusters on a FAT device using the FAT itself without assigning them to a file (a PC then may want to repair the disc ). If you have always the same disc size, this could be done at fixed LBAs (tracks/sectors).

[andycadley]

And is there any way to just read a specific sector in a file system agnostic way using Basic and to run it as machine code?
Putting a write-protected system file in a known sequence of sectors is solved problem.

The question is about bootstrapping, i.e a DOS with the relevant capabilities is not already running.

The only way from BASIC is |CPM which loads track 0, side 0 sector &41. It will only load 512 bytes though (whatever is booted is then expected to load the rest). 

[Benedikt]

But you can always reserve clusters on a FAT device using the FAT itself without assigning them to a file (a PC then may want to repair the disc ).

Reserving clusters by putting a file there sounds like a more intuitive and more robust option.
Ideally a hidden, write-protected system file or something.

The only way from BASIC is |CPM which loads track 0, side 0 sector &41. It will only load 512 bytes though (whatever is booted is then expected to load the rest).

In that case I will have to resort to some hideous CALL trickery, because |CPM only works with drive A and I need drive B.
Hopefully I can come up with something that is short enough to be usable.

[andycadley]

In that case I will have to resort to some hideous CALL trickery, because |CPM only works with drive A and I need drive B.
Hopefully I can come up with something that is short enough to be usable.

I'm not really sure you need any trickery. You can just RUN a binary file, provided the header is correctly set up for it.

[Benedikt]

The RUN command is probably not particularly useful for loading a FAT driver from a FAT formatted disk.

But in the meantime I came up with this code snippet, which should be roughly equivalent to |CPM:

Code Select Expand

kl_find_command equ 0bcd4h

entry:
        ld      hl,read_sector_rsx
        call    kl_find_command
        ld      (read_sector),hl
        ld      (read_sector+2),c
        ld      hl,100h                 ; destination address
        push    hl                      ; also save as return address
        ld      de,read_sector          ; load address of far pointer
        push    de                      ; save address of far pointer on stack
        ld      de,0001h                ; (track << 8) | drive
        ld      c,41h                   ; sector
        rst3                            ; far call via stack; "returns" to 100h

read_sector_rsx db  84h                 ; ID "string" of the RSX function
read_sector     db  ?                   ; far pointer
Could something like this work, if massaged into a Basic CALL statement?

[andycadley]

I don't think AMSDOS can read sectors from a format it doesn't know about, but I'll let someone more knowledgeable answer that for sure.

[HAL6128]

If the 3,5 inch floppy disc is a Double Density Disc (up to 720k / 840k) then it shouldn't be a problem to read a sector with AMSDOS?? (Doesn't MS-DOS up to version 3.3 used FAT12 on DD floppies?)

[Prodatron]

I don't think AMSDOS can read sectors from a format it doesn't know about, but I'll let someone more knowledgeable answer that for sure.

AFAIK the low level "Read Sector" (#84) command of Amsdos can handle any sector IDs with "format offset" (this CP/M hack using the high nibble for detecting the disc parameters).
So you should be able to read FAT sectors (which don't use the high nibble... - FAT provides useful disc parameters in the boot sector) with Amsdos.

[McArti0]

Format 160kB/320kB IBM sectors numbered 1-8, 40 tracks, Amsdos omits one track on both sides and use only 8 first sectors from track. You can order this sectors as bad (mark FF7 for FAT12)

[Prodatron]

Imagine the following scenario:

• A 3.5" drive is connected as drive B
• The disk in it has a FAT file system
• It already contains binaries for some other platform(s), e.g. MS-DOS, MSX-DOS, Enterprise 128, Atari ST
• We want an additional binary for CPCs

Is there any somewhat convenient way to load and run anything from that disk from Basic?
E.g. a few lines to load a "CPCDOS.SYS" from a known, continuous sequence of sectors?

Thank you in advance!

MyArti0 now proved, that this is possible in several ways:

https://www.cpcwiki.eu/forum/applications/symbos-3-1-released/msg241441/#msg241441
https://www.cpcwiki.eu/forum/applications/symbos-3-1-released/msg241662/#msg241662

[Benedikt]

Those are interesting findings!
The way I read it, a single 2 KiB file copied to an empty FAT formatted disk is then sufficient for bootstrapping on a CPC, because the data blocks on a CP/M-like disk can presumably overlap the directory.
If the second 1 KiB block in the 2 KiB directory is crafted to avoid conflicts with CAT/|DIR using appropriate status bytes on 32 byte boundaries, that should technically work.
If that 1 KiB block (2nd in the MS-DOS file but 1st in the AMSDOS file) then loads the first block, too, we get almost 2 KiB for FAT driver code, which sounds reasonable for basic use cases.

[McArti0]

Too many combinations. On a double sided FAT disk, you put a 4kB file at the beginning of the third track (0tr on 1 side,1tr on 2side,2tr on 1side), where Amsdos will place a 2kB root dir and a 2kB first file.  

[GUNHED]

Are you lucky to boot from Drive A?

That's easy: Add a switch to your CPC connecting to the Boot-LK on the main PCB. If you switch the boot switch ON, then the CPC will boot from drive A as soon als the AMSDOS get's initialized. In effect it't the same as typing !CPM.

What you want to boot depends only on what software you put on your disc. Just have one sector prepared to continue. 

However, why to do such primitive stuff like booting from mass media or floppy disc in 2024? It was ok for some simple OS in the 80ies to be booted from media. But today the CPC offers such a big variety of ROM expansions, that it would of course be better and quicker to 'boot' from ROM. See, imo modern software (f.e. 'orgAms') comes in ROM today. 

[Prodatron]

Imagine the following scenario: [...] MSX-DOS, Enterprise [...] CPC

Now you and McArti0 make me wonder, if this would be possible.

Here is the newest one:
https://www.cpcwiki.eu/forum/applications/symbos-3-1-released/msg241903/#msg241903

Maybe you can have one single 3,5" 720KB disc, from which you can boot the same on 3 different machines (CPC, MSX and Enterprise).

[Benedikt]

I reckon that it is possible, namely by making the FAT image just AMSDOS compatible enough to make a FAT driver available to the CPC.
Is there by any chance already a tool that can convert raw floppy disk images in IBM format to DSK images? If not, I will have to write my own.

[zhulien]

In the super rom, there is an msdos program for cpc, it adds Rex's to let you read and write msdos discs. Interestingly itinly works with 360k discs, not 720k. Maybe there is code in here that can help with this project?

https://www.cpcwiki.eu/index.php/Super_ROM

[Benedikt]

Is there by any chance already a tool that can convert raw floppy disk images in IBM format to DSK images? If not, I will have to write my own.

I have found dsktrans from the LibDSK package. Judging by the man page, it can do that.
The FAT image itself could e.g. be created using mtools' mformat and mcopy.

[zhulien]

Is the msdos boot sector the same sector in cpm?

Some programs on cpc when you simply cat display an whole screen of stuff, is that executing anything from a boot sector or is it careful use of control codes?

[McArti0]

Is the msdos boot sector the same sector in cpm?

Some programs on cpc when you simply cat display an whole screen of stuff, is that executing anything from a boot sector or is it careful use of control codes?

Same location, different content. Also on different formats. 

Amsdos System has sectors counted from &41 , msdos has sectors counted from &01.

Its careful use of control codes.

[robcfg]

I reckon that it is possible, namely by making the FAT image just AMSDOS compatible enough to make a FAT driver available to the CPC.
Is there by any chance already a tool that can convert raw floppy disk images in IBM format to DSK images? If not, I will have to write my own.

Try the software for the HxC Floppy Emulator, it allows you to convert between different formats including dsk.

[Prodatron]

Some programs on cpc when you simply cat display an whole screen of stuff, is that executing anything from a boot sector or is it careful use of control codes?

CAT never loads and executes a boot sector. It just displays the chars of the files using "TXT OUTPUT" (#bb5a) which will execute control codes as well. There were already tools from the 80ies for modifying a directory in a way that will display colourful chars placed at any location on the screen by adding dummy file entries with 0KB sizes. Or you hardcode it directly by yourself, which allows much more chars and effects.
The trick is to disable text output at the end of a filenam to prevent printing file sizes/line feeds and enable it again at the beginning of the next filename; and you also have to use one hidden char for sorting them in the correct order.