Overview of .dsk files - nealcrook/multicomp6809 GitHub Wiki

To identify a data chunk on a floppy disk you specify a side, track and sector. In FLEX, the "side" gets hidden by either doubling the number of tracks or doubling the number of sectors per track. The data chunk (sector) size is fixed at 256bytes. Depending on the disk drive and the data encoding (historically FM or MFM for single and double sensity respectively), the number of tracks/sectors/sides on a disk is variable. The 3rd sector of a FLEX disk always contains a data structure called the System Information Record (SIR) which describes these parameters (which are often referred to as the "disk geometry"). The idea of disk geometry was carried across to early hard drives, where it was referred to as "CHS addressing" - C is for Cylinder (equivalent to Track), H is for Head (equivalent to Side) and S is for Sector.

A file on a FLEX disk can be located by looking up its name in the directory (which is a linked-list of sectors starting at a known point). The directory stores the track/sector of the first sector of the file. The file is stored as a linked list of sectors. In each 256-byte sector, the first 2 bytes are the track/sector of the next sector (0,0 if this is the final sector) and the remaining 254 bytes are payload.

A .DSK (or .dsk) file is an image of a FLEX floppy disk. Because it is a linear sequence of data the image itself has no "geometry". However, it does reflect the geometry of some physical floppy. Imagine that you had 2 .DSK files, one from a 10 track floppy with 20 sectors per track and one from a 20 track floppy with 10 sectors per track. The size of the .DSK files is identical. However, if you were asked for "track 5, sector 3" for the two .DSK files, you need to know the geometry in order to calculate the offset and extract the correct piece of data.

An SD card does not have a "geometry", rather it uses a linear addressing - referred to as LBA (Logical Block Addressing). On the multicomp SD controller, the address is specified by a 24-bit value written as three bytes to the address registers LBA2, LBA1, LBA0. LBA0 is the least significant byte.

In my FLEX port the disk driver assumes a specific geometry (lazy of me. I should have inferred it from the SIR). Here's the code: https://github.com/nealcrook/multicomp6809/blob/master/flex/multicomp09_flex_sd.asm

The disk driver code accepts a drive number and track/sector number and converts it into a 24-bit block address on the SD card. The drive number is used to select a hard-wired base block address (ie, the SD block address that identifies the first sector of the image for that disk). The track/sector number are used to compute an offset from the base address. The conversion is performed by the subroutine LDSDADRS which is common to both read and write operations.

**************************************************************
* HELPER SUBROUTINE LDSDADRS
*
* SET SDLBA2 SDLBA1 SDLBA0 FOR NEXT SD OPERATION
* DISK GEOMETRY IS HARD-CODED. ASSUMED TO USE 72 SECTORS PER TRACK
* AND TO HAVE THE SAME NUMBER ON TRACK 0.
* CONVERT FROM TRACK, SECTOR TO BLOCK AND ADD TO THE START BLOCK.
* COMPUTE LBA0 + 256*LBA1 + 256*256*LBA2 + A*72 + B - 1
*
* A: TRACK
* B: SECTOR
* RETURN WITH SDCONTROLLER SDLBA0-2 REGISTERS SET UP
* CAN DESTROY A,B,CC.

To take a .DSK file and put it onto SD card, there are 3 important factors:

the .DSK file must be of the correct geometry. If you need to change the geometry, use the tool flex_vfs (https://github.com/nealcrook/multicomp6809/blob/master/flex/flex_vfs) to create a blank disk of the correct geometry, load a disk of any arbitrary geometry and then copy all the files from one to the other.
the .DSK file must be padded. The SD card uses 512byte blocks and rather than packing 2 FLEX sectors into 1 SD block my driver only uses half of each block. Use the script flex_disk_manip or flex_vfs to do this padding. The result is an image exactly 2x the size of the original
the .DSK file must be placed at the correct location (offset) on the SD card. My FLEX disk driver supports 4 "drives" each of which has a fixed/hard-coded block start address on the SD card.

Steps 2 and 3 are taken care of in the script https://github.com/nealcrook/multicomp6809/blob/master/bin/create_sd_image.

The offsets on the SDcard for the four disk images are established by four sets of "magic numbers" which must be consistent between the disk driver code and the create_sd_image script. Here are the magic numbers in the disk driver code:

* MULTICOMP-SPECIFIC DATA AREA.
*
* FOR MULTICOMP, EACH DRIVE IMAGE STARTS AT A SPECIFIED BASE
* (BLOCK) ADDRESS ON THE SD CARD. THE BASE ADDRESS IS A 24-BIT
* VALUE, WHICH IS USE TO LOAD THE HARDWARE ADDRESS REGISTERS
* LBA2, LBA1, LBA0.
*
* THE TRIPLET MUST BE CORRECT FOR DRIVE0 IN ORDER FOR THE
* SYSTEM TO BOOT. SINCE THE FLEX LOADER ALSO HAS THIS
* INFORMATION, IT *COULD* BE PATCHED IN BY THAT PROGRAM PRIOR
* TO PASSING CONTROL TO FLEX.
*
* AN LBA2 VALUE OF $FF IS USED TO INDICATE "NO DISK PRESENT"
* AND TO CAUSE AN ERROR IF "DRIVE" ATTEMPTS TO SELECT IT.
*                  LBA2 LBA1 LBA0
SDDRV0         FCB $02, $20, $00 DRIVE0, SYSTEM DRIVE.
SDDRV1         FCB $02, $38, $00 DRIVE1,
SDDRV2         FCB $02, $50, $00 DRIVE2,
SDDRV3         FCB $02, $68, $00 DRIVE3,

And here are the magic numbers in the create_sd_image script (snipped for brevity)

# Drive 0: FLEX system disk
# (Allow) 3MBytes at offset 68MByte
# 68MByte is block offset 1048576 * 68/512 = 0x2.2000
dd if=multicomp09_flex.img of=multicomp09_sd.img obs=1M seek=68

# Drive 1
# (Allow) 3MBytes at offset 71MByte
# 71MByte is block offset 1048576 * 71/512 = 0x2.3800
dd if=flex_drive1.img of=multicomp09_sd.img obs=1M seek=71

# Drive 2
# (Allow) 3MBytes at offset 74MByte
# 74MByte is block offset 1048576 * 74/512 = 0x2.5000
dd if=flex_drive2.img of=multicomp09_sd.img obs=1M seek=74

# Drive 3
# (Allow) 3MBytes at offset 77MByte
# 77MByte is block offset 1048576 * 77/512 = 0x2.6800
dd if=flex_drive3.img of=multicomp09_sd.img obs=1M seek=77

The function of the create_sd_image script is to combine all the separate images for all the different OS that can be run from a single SD card. It is OK if some images are missing when you run it (they will generate errors but the images that are present will work correctly).