>How does BLU record this format byte? Does it copy it from the
>sector header, or does it guess based on the observed disk format?
BLU gets the format byte from the sector header, as stored in the disk controller's "VolFnd" aka "DiskID" variable when it reads a disk. If it is deemed important, I could try to figure out just which sector's header it comes from.
The sector header is created by the disk formatting process, which is coded in the I/O ROM on the Lisa (and the .Sony DRVR on a Mac as far as I know).
I believe that: since the sector header is not replaced when writing a sector (only when formatting a disk), it would be possible to "sector copy" a disk onto a disk with a different sector header format byte. Therefore the format byte really only designates what driver formatted the disk, and doesn't necessarily provide reliable info about the data on a disk.
In the BLU code I see this comment (of unknown reliability):
; image type $02 = Mac/Lisa 400k, rumoured: $12=400K, $22=>400K eg. 800K, $24=800K_AppleII
As far as I know, both Mac and Lisa use $02 for 400k disks. I think this is reasonable since the disk format is the same (ignoring the issue arising from the MacII making disks with 3 instead of 5 bitslip FF's).
Back in the days before Google, when information was a bit more difficult to find, I think there was an Apple "Technical Note" regarding the DiskCopy file format, but I don't have it at hand. I think I recall deciding the "rumour/error" regarding the $12 value may have originated in that tech note, but that brings up the question... just because one hasn't seen a system make a disk with that value, does that mean it doesn't exist? As suggested above, I think the format byte doesn't make claims about the data on a disk, only the machine that formatted the disk.
It is interesting that David found a disk image with the $12 value... perhaps the disk image was originally generated by software instead of hardware, or perhaps it was non-Apple hardware.
A document originally from
https://wiki.68kmla.org/DiskCopy_4.2_format_specification
says (again with unknown reliability),
quote:
Much information comes from the CiderPress and Mini vMac source
codes. More authoritative information
comes from nulib.com (http://www.nulib.com/library/FTN.e00005.htm).
Some info on tags from Inside
Macintosh, 1st ed. page II-212 (http://www.pagetable.com/?p=50). This
format is also used in DiskCopy 4.1.
DiskCopy 6.3.3 uses a variant with tags omitted. DART is a variant
which adds compression.
...
0x51: Format Byte
This byte has one of two meanings, depending on whether the disk is GCR format 400k or 800k, or MFM format. The byte is completely ignored for the rare GCR-on-HD format (which always has a 1:1 interleave and is always 2 sided).
If disk is GCR format 400k or 800k:
This byte is a copy of the GCR format nybble (6 bits), which appears
in the headers of every GCR sector.
$02 = Mac 400k
$12 = (documentation error claims this is for mac 400k disks, but
this is wrong)
$22 = Disk formatted as Mac 800k $24 = Disk formatted as Prodos 800k (AppleIIgs format) $96 = INVALID (Disk was misformatted or had GCR 0-fill (0x96 whichrepresents data of 0x00)
Values for bitfield:
76543210
|||||||| |||\\\\\- These 5 bits are sector interleave factor: ||| setting of 02 means 2:1 interleave: 0 8 1 9 2 10 3 11 4 12 5 13 6 14 7 15 ||| setting of 04 means 4:1 interleave: 0 4 8 12 1 5 9 13 2 6 10 14 3 7 11 15 ||\------ This bit indicates whether a disk is 2 sided or not. 0 = 1sided, 1 = 2 sided.
If disk is MFM format:
This byte is used to define MFM sector size and whether the disk is
two sided or not.
Interleave is ALWAYS 1:1 for these formats.
$22 = double-sided MFM diskettes with 512 byte sectors
Values for bitfield:
76543210
|||||||| |||\\\\\- These 5 bits are sector size as a multiple of 256 bytes ||| i.e. 02 = 2*256 = 512 bytes per sector ||\------ This bit indicates whether a disk is 2 sided or not. 0 = 1sided, 1 = 2 sided.
unquote.
-- -- ----- You received this message because you are a member of the LisaList group. The group FAQ is at http://lowendmac.com/lists/lisa.html To post to this group, send email to lisalist_at_email.domain.hidden To leave this group, send email to lisalist+unsubscribe_at_email.domain.hidden For more options, visit this group at http://groups.google.com/group/lisalist --- You received this message because you are subscribed to the Google Groups "LisaList" group. To unsubscribe from this group and stop receiving emails from it, send an email to lisalist+unsubscribe_at_googlegroups.com. For more options, visit https://groups.google.com/d/optout.Received on 2018-01-21 20:06:57
This archive was generated by hypermail 2.4.0 : 2020-01-13 12:15:17 EST