Question for SIO experts: how to respond to format command?

[mellis]

I am connected to my Atari via an SIO2PC cable, and I am attempting to simulate a response to format commands from DOS 2.5 (command id $21 and $22). The documentation seems straight-forward. It says that I am to zero out all sectors on the disk and return a 128-byte command frame that identifies all bad sectors. The sector list within the frame is to be terminated by two $FF bytes.

 

Here's what actually happens when initializing a dual-density "disk" in DOS 2.5:

1) I receive a $22 format request

2) I respond with a COMPLETE byte followed by a 128 response frame. The response frame looks like this: "$FF $FF $00 $00 ..."

3) I receive seven more $22 requests, to which I respond as above

4) I receive a $21 format request

5) I respond as described above

6) I receive seven more $21 requests, to which I respond as above

 

It seems like DOS is not satisfied with my responses, and it is retrying the format a total of eight times. When the extended format "fails", it then makes eight attempts at a single density format.

 

The computer never sends write-sector commands for the VTOC sector ($168) or for the disk directory sectors ($169-$170) following initialization.

 

So my question is this: "Is there some response I should provide beyond the bad sector list? The 7 retry attempts suggest to me that DOS is dissatisfied. Should the COMPLETE byte be sent earlier than after the format completes? The documentation says 'no' to this."

 

Any thoughts?

[Rybags]

I think your problem might lie in the handshaking... stuff like ACK/COMPLETE responses.

 

Without looking, it should be:

 

Computer: Send Format command to device X

Device X: Send ACK

 

Computer: Wait for peripheral on long timeout.

 

Device X: Send COMPLETE

Device X: Send Data Frame containing bad sector list.

 

I'll look into it a bit more and correct if necessary. I did a 1050 emulator on the ST about 20 years ago... a bit rusty on this stuff.

[thorfdbg]

I am connected to my Atari via an SIO2PC cable, and I am attempting to simulate a response to format commands from DOS 2.5 (command id $21 and $22). The documentation seems straight-forward. It says that I am to zero out all sectors on the disk and return a 128-byte command frame that identifies all bad sectors. The sector list within the frame is to be terminated by two $FF bytes.

 

Here's what actually happens when initializing a dual-density "disk" in DOS 2.5:

1) I receive a $22 format request

2) I respond with a COMPLETE byte followed by a 128 response frame. The response frame looks like this: "$FF $FF $00 $00 ..."

3) I receive seven more $22 requests, to which I respond as above

4) I receive a $21 format request

5) I respond as described above

6) I receive seven more $21 requests, to which I respond as above

 

It seems like DOS is not satisfied with my responses, and it is retrying the format a total of eight times. When the extended format "fails", it then makes eight attempts at a single density format.

 

The computer never sends write-sector commands for the VTOC sector ($168) or for the disk directory sectors ($169-$170) following initialization.

 

So my question is this: "Is there some response I should provide beyond the bad sector list? The 7 retry attempts suggest to me that DOS is dissatisfied. Should the COMPLETE byte be sent earlier than after the format completes? The documentation says 'no' to this."

 

Any thoughts?

Not really - there isn't much to do wrong here. Just note that FORMAT is a regular "Read" command, that is, you should respond with 'A' acknowledge followed by 'C' command completed (as you do), and then return the "sector" you read, which is the bad sector list.The bad sector list is, as you state correctly, terminated by two 0xff bytes, and that's really all. SIO/FMS should accept your command on the first response, there should be no repeats.

 

Otherwise, additional help I could offer would be the source of a compatible SIO/DISKINTERF/FMS implementation you can check for reference:

 

http://www.math.tu-berlin.de/~thor/atari++/download/os++.tgz

 

There, handling of FORMAT is done in diskinterf.asm resp. fms.asm. Nothing really specific to this command, sorry.

 

So long,

Thomas

Edited April 27, 2009 by thorfdbg

[Rybags]

OK. That stuff I posted should be correct.

 

One stumbling block you might encounter is if you don't have sufficient delays between things like receiving commands and sending ACK, and sending COMPLETE and sending the data frame.

 

When I was developing the 1050 emu, I just went on the OS Manual... around Page 135 in the section "Adding new device handlers/peripherals".

 

It's not so clear on the Format command, but I think that on the communication level it just works the same as a general Read type command, except with a much longer timeout.

[mellis]

Thanks, guys.

 

I have the timings all worked out per the SIO specs (read/write works great), so I too was surprised that format was behaving differently.

 

I'll have a look at that source and see if it provides any new insight.

[mellis]

I'm embarrassed to say that the problem was a missing ACK for the FORMAT command.

 

I was __sure__ I had acknowledged that, but I must have been thinking of the READ an WRITE commands (which were properly acknowledged). Too much late-night coding, I guess. Once I added the proper ACK transmission, everything fell in line for the FORMAT handler.

 

One thing that is a little surprising is that I was using DOS 2.5 to initialize a disk, and the disk is capable of storing 1040 sectors. However, DOS reports 707 sectors free when the format completes. This makes me think that when a 1050 responds to the $22 format command, it must tag the disk as being enhanced density at some "well known" location. While we're discussing it, do you have any idea where I can get that info?

[Rybags]

The default format command on a 1050 will give you an enhanced density disk. The Format Single sends a different command to SIO.

 

$21 is the Format command.

$22 on the 1050 is the Format Single-Density command.

[GroovyBee]

Aren't the sectors twice the size in the enhanced density mode?

[Rybags]

Nope. That's true "Double Density".

 

So-called "Enhanced Density" is just 1040 sectors (26 per track) instead of 720 (18)

[GroovyBee]

Ooops! My mistake, enhanced density sectors are the same size as single density sectors. Double density sectors are twice the size. Sorry for the confusion .

 

Rybags beat me to it. LOL!

[thorfdbg]

One thing that is a little surprising is that I was using DOS 2.5 to initialize a disk, and the disk is capable of storing 1040 sectors. However, DOS reports 707 sectors free when the format completes. This makes me think that when a 1050 responds to the $22 format command, it must tag the disk as being enhanced density at some "well known" location. While we're discussing it, do you have any idea where I can get that info?

 

There is no such information - the trick is that DOS 2.5 writes two VTOCs: A cut-down 2.0S compatible VTOC at sector $168, and the "real" VTOC at sector $400 (IIRC). By that,

whenever 2.0S reads the VTOC, it only sees the part it understands, and this part reports 707 free sectors, namely all sectors up to $2cf. If DOS 2.5 needs to know the number of

free sectors, it reads the "real" VTOC at $400 and outputs *this* number.

 

Whenever 2.5 changes VTOC entries, it writes the "real" VTOC and then creates a "mock" cut-down version compatible to 2.0S and writes that to the old sector.

 

Greetings,

Thomas

[mellis]

There is no such information - the trick is that DOS 2.5 writes two VTOCs: A cut-down 2.0S compatible VTOC at sector $168, and the "real" VTOC at sector $400 (IIRC). By that,

whenever 2.0S reads the VTOC, it only sees the part it understands, and this part reports 707 free sectors, namely all sectors up to $2cf. If DOS 2.5 needs to know the number of

free sectors, it reads the "real" VTOC at $400 and outputs *this* number.

 

Whenever 2.5 changes VTOC entries, it writes the "real" VTOC and then creates a "mock" cut-down version compatible to 2.0S and writes that to the old sector.

 

Greetings,

Thomas

 

Thanks, Thomas.

 

That's very helpful information. Is there a document that has this level of technical detail regarding DOS 2.5, or did you reverse engineer it? If there is document somewhere on the Internet, I'd love to have a look at it.

[ijor]

The default format command on a 1050 will give you an enhanced density disk. The Format Single sends a different command to SIO.

$21 is the Format command.

$22 on the 1050 is the Format Single-Density command.

 

It is actually the other way around. For backwards compatibility reasons, $21 is single density and $22 is enhanced/dual.

 

I have the timings all worked out per the SIO specs (read/write works great), so I too was surprised that format was behaving differently.

I'll have a look at that source and see if it provides any new insight.

 

The "sources" to read here, aren't the DOS/FMS ones, but the OS SIO. Your problem (at least the initial one) has nothing to do with DOS, but with the basic SIO protocol. Both the SIO protocol and the source for the OS implementation are published in the "Technical References".

 

That's very helpful information. Is there a document that has this level of technical detail regarding DOS 2.5, or did you reverse engineer it? If there is document somewhere on the Internet, I'd love to have a look at it.

 

The original sources for DOS 2.5 were recently made public. They should be here somewhere available to download.

[thorfdbg]

The "sources" to read here, aren't the DOS/FMS ones, but the OS SIO. Your problem (at least the initial one) has nothing to do with DOS, but with the basic SIO protocol. Both the SIO protocol and the source for the OS implementation are published in the "Technical References".

 

The original sources for DOS 2.5 were recently made public. They should be here somewhere available to download.

(-: The sources there *are also* the FMS sources. This is the source of Os++, unlike the original OS, it does contain a D: handler and a DUP. It's not a 2.5 FMS, though, but a more 2.0S-ish VTOC layout.

 

So long,

Thomas

[thorfdbg]

Thanks, Thomas.

 

That's very helpful information. Is there a document that has this level of technical detail regarding DOS 2.5, or did you reverse engineer it? If there is document somewhere on the Internet, I'd love to have a look at it.

 

Back then, there was unfortunately never any official documentation of 2.5. That was reverse engineered. I think I *might* have a more detailed layout of the 2.5 VTOC somewhere, but it was pretty easy to guess from looking

at it with a disk editor.

 

The FMS sources I posted do not use the 2.5 layout, though. They use a 2.0S compatible layout with all other bits allocated to make use of as many sectors as possible. Historic accident, I used this FMS (or rather, its precursor) on most of my disks before 2.5 became available.

 

So long,

Thomas

[mellis]

Just to wrap this thread up, I thought I would post a summary of my findings.

 

1) I was receiving FORMAT retries (per original post) because I neglected to acknowledged the initial FORMAT request with an 'A' byte. Ooops.

 

2) The formatted disks were being reported as 707 sectors because I was not setting bit #7 of the virtual-1050's STATUS byte to 1 to indicate an enhanced disk was present. This little nugget was gleaned by analyzing the source code for the 1050's firmware, which is available here: 1050 firmware listing (whoever "pigwa" is, he is the man when it comes to useful Atari documentation -- thanks for maintaining that!)

 

Anyway, once DOS 2.5 knew that an enhanced density disk was detected, everything started working normally.

 

Thanks to those who helped out with this.