Determining DFn: boot device in bootblock

[a/b]

It's only to determine the boot device. To get a list of all (floppy) devices I was using disk.resource to check unit IDs: empty if -1, 3.5' if 0, 5.25' if $55555555 (or something like that, it's been ~30 years ;P ).

[Thomas Richter]

A second, more sever problem of this approach is that it is not at all clear that the boot device is a floppy in first place. Clearly, the boot block is only executed for boot-block booting, and not for boot-point-booting, the latter being the mechanism by which hard-disks are booted. However, there are other devices such as CC0: (i.e. the carddisk.device) which may offer boot-point booting. Thus, in general, you *can* use the IORequest passed into the boot block code to read further blocks from the device being booted from, but you should not depend on what this device actually is.

Which brings me to the next question: Why exactly is the information on the unit actually particularly needed? It should not.

[ross]

Originally Posted by Thomas Richter

Which brings me to the next question: Why exactly is the information on the unit actually particularly needed? It should not.

The usual: disabling the system and using a custom loader (which simply takes the drive to load from as a parameter).
Ok ok, you could scan active drives and look for a pattern on any inserted disks to figure out where you're running from.
But why complicate life? Better to let the system do it and then focus on the important things

I know I gave you a tummy ache, but that's the way it is
And anyway a/b had warned about the side effects of this approach.

[a/b]

The whole thing is not meant for "serious" software, but for demos/games that exclusively run from a non-DOS floppy disk, as far as I'm concerned. Typically you want the bootblock code to be as short and possible, and that then implies (ab)using the OS to get the required info and wiping it out afterwards.
Back in the day people would go a long way just to 100% avoid using the OS (e.g. AttnFlags don't care, I can detect the cpu on my own, memory list don't care, I'll just write patterns to memory and scan, etc.), so this is a happy medium.
You just have to put it in the correct context....

[Photon]

Originally Posted by Thomas Richter

sever problem

Just like the longer OpenDevice() approach, it will only check the 4 floppy units. If you somehow booted from a different type of unit and reach this code, it will not be in the list or be openable with trackdisk.device, and so simply return -1 not found.
If someone rips boot code from a floppy and manually writes it to a different type of unit, they should expect a different outcome, shouldn't they?

The topic is nice and specific

Checking every type of unit would be ambitious and I guess requires some imagination to check all possible ways to boot, and not miss one.

Originally Posted by Thomas Richter

Why exactly is the information on the unit actually particularly needed? It should not.

On KS2+, you can boot from a different floppy than DF0. To check which boot floppy unit to continue loading from was missing from virtually every game and demo back in the day; they assumed DF0: since KS2.0 wasn't out yet. The games and demos have not been re-released with a fix. It would be gracious and proper to support it now.