#26 os9 format does not create hard drive images
"os9 format" does not honor the "-ss" single sided option when formatting a large hard disk image. This causes the DD.FMT byte to have the bit 0 (Double-sided) set, and causes tools like "os9 gen" to miscalculate where the kernel boot track is written.
This problem was observed when using a CoCoSDC, as it decides how to handle disk images by their size. If the image is not a 360K or 720K, CoCoSDC does not perform the track interleaving between sides and, instead, treats the image like a group of logical sectors. Thus, when "os9 gen" writes out the kernel boot track, it writes it out twice as far in to the drive (thinking it is a double sided floppy) than it needs to be for a hard drive image.
Honoring the "-ss" option when using the "-l" hard drive option may solve this issue. (By manually editing the produced disk image to change the FMT byte from $10 to $00 gets cobbler placing the kernel track in the right location, BUT it does not allocate the sectors properly so there may be an issue in cobler as well.)
This formats a disk with DD.FMT set to $00 (BUT, sid=1 too, which is not the same, like I originally thought. I will need to dig in to the OS-9 format source to see what it is doing.)
OS9: format /sd1 1
These format a disk with DD.FMT set to $01 (2 is the default):
OS9: format /sd1 2 OS9: format /sd1
Since native OS-9 format defaults to double sided, it makes sense for "os9 format" to do the same. BUT, we need to allow specifying the single sided option.
Here is an example:
*** Format the largest size .dsk image OS-9 can use without reclustering (524280).
alsmb:CoCo allenh$ os9 format -e -l524280 128MB.DSK Format Summary -------------- Geometry Data: Cylinders: 1020 Heads: 2 Sectors/track: 257 Sector size: 256 Logical Data: Total sectors: 524280 Size in bytes: 134215680 Cluster size: 1
*** "os9 id" shows the "Disk format" of the newly created 128MB image:
alsmb:CoCo allenh$ os9 id 128MB.DSK LSN0 Information: Total sectors : 524280 Track size : 1 Bytes in bitmap : 65535 Sectors/Cluster : 1 Root dir sector : 257 Disk owner : 0.0 Disk attributes : dsewrewr Disk ID : $180 Disk format : $1 (48 TPI, Single Density, Double Sided) Sectors/track : 257 Boot sector : 0 Bootfile size : 0 Creation date : 02/02/2015 20:58 Disk name : CoCo Disk Bytes/Sector : 256
*** Because of this "double sided" type, "os9 gen" will place the kernel boot track in the wrong location:
alsmb:CoCo allenh$ os9 gen -c -t=kernel_cocosdc 128MB.DSK Boot track written! LSN: 1224, size: 4608
*** When inspecting the disk image, the kernel boot track is indeed located at sector 1224, but the CoCoSDC firmware sees this image as a hard drive and does not interleave the tracks like it would a double sided floppy image.
When making a double sided 40 track floppy image, it does the same thing (kernel boot track at sector 1224) BUT it works because CoCoSDC recognizes the image size (360K, 720K) as a double sided floppy image and does the interleaving.
alsmb:CoCo allenh$ os9 format -ds -t40 DS40.DSK Format Summary -------------- Geometry Data: Cylinders: 40 Heads: 2 Sectors/track: 18 Sector size: 256 Logical Data: Total sectors: 1440 Size in bytes: 368640 Cluster size: 1 alsmb:CoCo allenh$ os9 id DS40.DSK LSN0 Information: Total sectors : 1440 Track size : 18 Bytes in bitmap : 180 Sectors/Cluster : 1 Root dir sector : 2 Disk owner : 0.0 Disk attributes : dsewrewr Disk ID : $180 Disk format : $3 (48 TPI, Double Density, Double Sided) Sectors/track : 18 Boot sector : 0 Bootfile size : 0 Creation date : 02/02/2015 21:17 Disk name : CoCo Disk Bytes/Sector : 256 alsmb:CoCo allenh$ os9 gen -c -t=kernel_cocosdc DS40.DSK Boot track written! LSN: 1224, size: 4608
*** In the 40 track DS example, the kernel boot track is still at sector 1224, but it is found as expected because CoCoSDC presents that sector as the top side of a floppy disk as expected.
After manually setting the DD.FMT to be single sided, "os9 gen" will place the bootfile at sector 612 and it works.
alsmb:CoCo allenh$ os9 id 128MB.DSK LSN0 Information: Total sectors : 524280 Track size : 1 Bytes in bitmap : 65535 Sectors/Cluster : 1 Root dir sector : 257 Disk owner : 0.0 Disk attributes : dsewrewr Disk ID : $180 Disk format : $0 (48 TPI, Single Density, Single Sided) <-*** Sectors/track : 257 Boot sector : 0 Bootfile size : 0 Creation date : 02/02/2015 21:38 Disk name : CoCo Disk Bytes/Sector : 256 alsmb:CoCo allenh$ os9 gen -c -t=kernel_cocosdc 128MB.DSK Boot track written! LSN: 612, size: 4608
*** It could be argued that, by using the "-l" option you are specifying hard drive and thus it should default to single sided. I personally like this approach, but if anyone was relying on the default behavior (which matches OS-9's default), the honoring of -ss makes more sense for those of us that understand what we are trying to accomplish.
NOTES from the NitrOS-9 Technical Reference document:
The format attributes (DD.FMT) are these:
Bit 0 Number of sides
0 = Single-sided
1 = Double-sided
Bit 1 Density
0 = Single-density
1 = Double-density
Bit 2 Track density
0 = Single (48 tracks per inch)
1 = Double (96 tracks per inch)
Discussion
Anonymous
UPDATE: The "1" option on format DOES set FM.TYP to $00 as a single sided disk, but it ALSO overrides the sid=XXX value setting it to 1. "os9 format -ss" is therefore not the same as "format /sd1 1" as I thought it was.
It appears the OS-9 format command is also geared to single or double-sided floppy disks. I am unsure how to format a disk using "format" that has FM.TYP set as singled sided AND have multiple sides for hard drive sector calculation.
Ultimately, the "fix" for "os9 gen" should be a way to toggle that single-sided/double-sided bit OFF when making a hard drive image. (I will have to explore further to see if it's even possible to do within OS-9's "format").
It looks like os format is trying to calculate a c/h/s value that equals the -l option specified in the command line.
So you think if the -l option is used, the head variable should always be 1? Thus only the track count, and sectors per track should be adjusted to fulfill the sector count request?
--tim lindner
Last edit: tim lindner 2015-02-03
I spent hours working on this, and did many experiments. Ultimately, there is a bit for "single sided" or "double sided". This is a floppy bit, and should be clear when making a hard drive image. That throws cobbler off. I think "-l" should not set the double sided bit. That seems only useful for floppies. A hard drive might have 8 heads, or 2 (like format's default with -l) and neither is a double sided floppy disk.
There is still an issue in cobbler. With that bit clear in LSN0, it placed the boot track in the proper location ($264/612) BUT it did not allocate the bits -- which means it probably wrote them somewhere else on the hard drive, miscalculating that as well. I will find them and open a ticket on cobbler too once I know the problem and a fix.
NOTE:
sid= and the FMT bit are independent. format with "1" sets sides to 1, and clears the sides bit. format with "2" sets sides to 2, and sets the double sided bit. Format with >1 sides also sets the bit (OS-9 command). "os9 format" seems to just set this bit all the time, unless you are formatting a floppy size image and using -ss.
Diff:
Ok so here is what I am working on to try to fix this issue.
I am going to modify the os9format.c section so that when the "-l" option is used it will set a flag that we are going to be working with a hard drive image. Then rather than always assuming floppy in the pd_typ being 0x20 it will get set to 0x80.
Then in the os9gen.c when when you attempt to load a boot track into a image that has its pd_typ set to 0x80 (hard drive) it will ignore the sides value and always used the single side mode and put the boot track at 612.
This should take care of the issues with setting up a new image file with drivewire and cocosdc. As it stands now if you format a new os9 image with the -l524280 the boot track is in the wrong place.
So far I am testing my modified code and once I feel it is ready I will push the changes to the repo, but thus far it looks good.
Can we please have confirmed that the fixes in the repo address the problem reported?
I will have to verify that this is taken care of. I was hoping Allen would have responded if things were working as expected.
@tormod & @boisy,
So as far as this goes I have tested the updated code and currently I have been using the os9 format command to create the HDD images for use on DriveWire.
Now on the SDC I make sure to use a layout that is single sided to make sure that is comes as close to 128MB as I can get without switching to the next cluster size.
So far that setting creates a workable HDD image that works fine on the CoCoSDC.
Though at this point still need to find out if this has been workable for @os9al since he is the one who reported the problem.
Not sure what other options could be added. Otherwise my tests have gone well at this point.