[Coco] Oddball disk format question

[tim lindner]

Robert Gault <robert.gault at worldnet.att.net> wrote:

> Does anyone know how it might be possible to create a track where the 
> track ID number does not match the disk location, the sectors have 
> values 247 & 248, and there is data on sector 248?

This is easy, so I must be misunderstanding your qeustion.

Here is how I would answer the above question: "Step to the track you want, then
write the track with the data stream you need." If the data stream contains the
"wrong" track numbers then so be it.

Since the above is obvious, I must be missing something.

> I have determined the following. The track can be created by stepping to 
> the desired location (T35) and issuing a Write Track command with an 
> incorrect track value.
> The Coco controller will accept a sector value of 
> 248 even though it is not "legal. A sector with a value of 247 = $F7 
> (which is a reserved Western Digital command) can coincidentally be 
> created if the track ID is 164 when a crc is requested in the "wrong" 
> place. $F5, $F5, $F5, $FE, $A4, $F7 will create $A1, $A1, $A1, $FE, 
> $A4(track) ,$42(side), $F7(sector) because the crc of $A1A1A1FEA4 is 
> $42F7.

Tricky. Does it then write two of its own CRC characters, or does it issue
another $F7?

> It is not possible to place the desired data on sector 247 during 
> a format because it contains values in the range $F5-$FE.

Why not? Becuase you don't finish the sector ID field properly? Does the WD179x
get out of sync when you write a data field after the malformed sector ID field?

During a 'Format track' shouldn't this data stream work:

F5 F5 F5 FE A4 F7 01 xx xx (20 x 4E) (11 x 00) F5 F5 F5 FB (256 x data) F7
                  ^   \ /
                  |    + Proper CRC bytes
                  + Sector size
> I can't 
> access the sector with a disk zap program because of the mismatch 
> between disk and track IDs.

You need a better disk zap program. One that turnes off the track checking in
the read/write sector commands.

-- 
tim lindner
tlindner at ix.netcom.com                                            Bright