[direct floppy] Assume 360k floppy if no CMOS drives set

[ghaerr]

This will allow systems such as @toncho11's with no CMOS to use the direct floppy driver without special compilation.

[toncho11]

In Amstrad 1640 the static RAM is called the Non-Volatile RAM (NVR) and used to store system configuration data such as number of disk drives, memory size, serial I/O parameters, and default VDU screen mode. The ROS firmware maintains a checksum of the NVR and will reset the configuration data to 1sensible values1 during startup whenever the checksum value is incorrect (thus destroying your actual configuration).

I am working on my custom power supply for my Amstrad 1640, so it will be able to test later.

Thanks!

[toncho11]

Hi @ghaerr,

Can you please provide me an image?

[ghaerr]

Here you go @toncho11:

fd360.zip

[toncho11]

It works. Thanks.

[ghaerr]

Thank you for testing the latest DF driver @toncho11! After all the modifications its been through it is very nice to know it is still working on real hardware. I can see from the image above you have booted from DF, have a two partition hard disk, that both the BIOS and DF drivers are recognizing the floppy as 360k, and that the DF driver is defaulting to 360k with no CMOS.

The image you have has both BIOS and DF drivers linked in, allowing for 1) boot from DF (default), 2) boot from HD using BIOS driver and use DF for floppy, 3) boot from floppy or HD using BIOS driver only. These would be controlled using the root=hda1/root=fd0 option in /bootopts and the corresponding mount. Pretty cool :)

[toncho11]

Maybe the df driver should become the default at some point?

[ghaerr]

Maybe the df driver should become the default at some point?

Perhaps. Its not well tested at this point - few have used it for real work on real hardware, and that means a reasonable chance of failure on quasi-compatible systems that it seems lots of users try ELKS on.

It has the big benefit that the system doesn't wait for I/O and can do other things while waiting for the floppy. But that doesn't usually mean anything for the average user running typical commands from the shell. which needs to wait for floppy input anyways. If you're running networking off of floppy or writing data a lot and sitting at a console, it would really help.

The DF driver has a disadvantage that it only works for a floppy that is the same type as specified in CMOS; it doesn't (yet) auto probe more than one other format. (I don't know to what degree this matters, though). In contrast, the BIOS driver supports all floppy types and attempts to read the MSDOS FAT and/or ELKS EPB CHS format off the floppy, and supports full probing. (After having fully understood the DF driver, I also don't know to what degree supporting incompatible floppy types matters as well - few people try to use floppies that their disk drive doesn't support!)

Given all that, I kind of like the idea of booting from BIOS by default with async I/O enabled, but allowing for an easy user-specifiable upgrade to the DF driver with a quick /bootopts edit should they want to try async I/O. In this way, ELKS doesn't fail when a user first tries it, which is a real turn off.

What do you think?

[toncho11]

So the user boots safely with the fd driver and then he is able to switch to the df driver in /bootopts. Then he needs to restart to switch to the df driver.

Yes, sounds logical.