Device driver for SD card

NitrOS-9 disk use logical sector number (LSN). A floppy disk uses track/sector addressing. A device driver for a real floppy controller has to convert the logical sector number into a track/sector, and the maths for doing that depends upon the geometry of the floppy (number of sides, number of tracks, number of sectors per track). The first sector of a disk, sector 0, is named LSN0 and contains information that includes a description of the disk geometry (use the toolshed os9 tool's "id" command to display this information)

The mc09 disk driver, level1/modules/mc09sdc.asm, uses 4 regions of the SD card as 4 virtual disks. Each virtual disk is 720kbytes in size. The 4 descriptors, (D0-D3) are created from level1/modules/mc09sdcdesc.asm.

The initial virtual disk images are created by the toolshed os9 tool using a sequence like this:

# create disk
os9 format -e -t80 -ds -dd nitros9_2.dsk -n"NitrOS-9/6809 Level 1 util disk2"
# create some stuff on each of them
os9 makdir nitros9_2.dsk,CMDS
os9 makdir nitros9_2.dsk,DSK2_INFO

I thought that it ought to be the case that the geometry of the drive is invisible outside of the device driver, but apparently that is not correct. The track and sector count are needed for calculations by RBF during writes.

Even allowing that this is so, it should be possible to create a disk with a maximum of 256 tracks and 256 sectors (ie, much larger than the current disks) but we can save that question until things are up-and-running. In addition, the toolshed os9 tool allows the creation of a virtual hard-disk image (presumably larger), but I don't know how this works and whether the driver would need any changes. Again, answering this question can be left until later.

There is also a device driver called the "Superdriver" which seems to be geared towards larger devices, but I have not looked into this as it's more complex and the current SD driver is very simple and works.

TODO: Go back and find the email from Bill Nobel explaining why this is. Consult the RBF code to see why this is needed and how it is used.

References:

https://sourceforge.net/p/toolshed/wiki/Documentation/

Device driver for Drivewire

Drivewire is a protocol typically implemented across an RS232 link and used to allow a modern computer (acting as the server) to provide print, disk and network services to an 'old' computer (acting as the client). In emulation, the RS232 is usually replaced by a virtual parallel connection (named a Becker Interface after its original author) between the client and the server; the server is implemented as part of the emulator. The current version of the protocol is named Drivewire 4, leading to the abbreviation DW4.

There are multiple implementations of the DW4 server code, but the "standard" one is implemented in JAVA and runs on Windows/Linux/Mac. I have it running on a Raspberry Pi.

Using Drivewire device drivers in NitrOS-9 allows the system to access virtual disk images (in DECB format??) on the server. Usually, you can't boot NitrOS-9 in this way - because there are no device drivers available on the target system until after NitrOS-9 has booted. However, there are recipes for building a KERNELFILE that contains the DW drivers, so that the associated BOOTFILE can be loaded from a DW4 server.

On the Coco machines, the RS232 ports are implemented by bit-banging and hand-tuned code loops. Since mc09 has real UARTs, adding DW4 support should be straightforward. I did not do it when I did the original Level 1 port but I have subsequently added DW4 support for mc09 in Fuzix and I think it will be easy to go back and add it to mc09 Level 1 and Level 2.