SIO format command question

[atari8warez]

Does anyone know what exact sequence of events happen (i.e. commands sent, responses received, and timings) between a format command sent to an atari disk drive and the completion of the format by the disk drive. I am trying to figure out a problem that I recently came across and can't tell exactly why it is happening.

 

Thanks in advance.

 

 

[Rybags]

Don't have the ref handy but along the lines of command & aux bytes sent, then short delay for Ack recvd.

 

Then a decent delay when the actual format takes place followed by Ack then list of bad sectors then Complete.

ed just have to add - thanks stupid tablet for "correcting" my spelling and otherwise doing the best to screw up m post.

Edited December 10, 2014 by Rybags

[phaeron]

For the most part it's just like a read sector command, with a really long delay. There are three quirks that I know of.

 

First, the number of bytes returned depends on the sector size.

 

Second, for an XF551, the high bit means to format with a high-speed skew, not to run the command in high-speed mode. $A1/$A2 commands do the entire SIO protocol in low speed.

 

Third, I have seen some indications that the timeout used for the format command depends on the last drive queried for status. A drive in the chain that is reporting a bogus timeout value can cause DOS to use too short of a timeout and not wait long enough for the format command to complete.

[atari8warez]

Third, I have seen some indications that the timeout used for the format command depends on the last drive queried for status. A drive in the chain that is reporting a bogus timeout value can cause DOS to use too short of a timeout and not wait long enough for the format command to complete.

 

Hmm!!, here's what exactly happens in my case:

 

Using DOS 2.5 with AspeQt and trying to do a disk copy (DOS menu item "J") from an ATR image to a real floopy.

 

 

My setup:

- DOS 2.5 is booted from virtual drive D1:

- Source ATR is mounted to virtual drive D2:

- Target disk is in real drive D3:

 

Upon launching the "J" command with parms D2:, D3: drive D3: starts formatting but I see several other Format commands for D3: scrolling on the AspeQt log window, after a few seconds DOS Duplicate Disk command aborts with an error 138. So my initial thought was that after the first format command issued to D3: the Atari didn't receive any response from the disk drive and kept issuing the format command several more times and then finally aborted thinking D3: does not exist (all the while when the drive was formatting the disk).

 

Then I tried the same scenario with APE, to my surprise this problem didn't happen there and the duplicate disk command ran successfuly. After that I was even more confused, given that APE had no problem running the command there must be something in AspeQt which may be causing the problem.

 

Your explanation above makes sense to me, If you have any suggestions or can elaborate on this bogus timeout situation I would be pleased to hear them, thank you.

Edited December 10, 2014 by atari8warez

[Rybags]

Sounds like the Dos or util is the problem. An improper format cmd should be realised straight up, no reason anything should fire off multiples in the expectation that one works and rest are ignored.

Edited December 10, 2014 by Rybags

[atari8warez]

thanks stupid tablet for "correcting" my spelling and otherwise doing the best to screw up m post.

 

Can the auto-correct be turned OFF by any chance

 

Sounds like the Dos or util is the problem. An improper format cmd should be realised straight up, no reason anything should fire off multiples in the expectation that one works and rest are ignored.

 

I will try this with a simple Format command this time and watch the log entries. If the DOS or the command is in fault then how does it work OK with APE, that's the confusing part which makes me believe there may be something going on within AspeQt.

Edited December 10, 2014 by atari8warez

[HiassofT]

Try changing the 3rd byte you return in the 0x53 get status command from 3 to 0xe0 (1050 returns 0xe0, XF551 0xfe).

 

This byte defines the timeout that should be used for the format command.

 

Maybe DOS 2.5 doesn't query the status of D3: and incorrectly uses the format timeout returned from a (previous) get status of D1:. That would explain the symptoms you are seeing.

 

so long,

 

Hias

[atari8warez]

Try changing the 3rd byte you return in the 0x53 get status command from 3 to 0xe0 (1050 returns 0xe0, XF551 0xfe).

 

This byte defines the timeout that should be used for the format command.

 

Maybe DOS 2.5 doesn't query the status of D3: and incorrectly uses the format timeout returned from a (previous) get status of D1:. That would explain the symptoms you are seeing.

 

so long,

 

Hias

 

Ok, will try that and see what happens, thanks Hias

[phaeron]

This is actually the specific scenario I ran into, trying to format a disk on a physical drive with AspeQt in the chain.

 

Did a check in the emulator -- 2.0S stores the format timeout in an internal variable and only updates it when it does disk drive scans before and after booting. Due to the way the scan works, the timeout always comes from D1:.

[atari8warez]

This is actually the specific scenario I ran into, trying to format a disk on a physical drive with AspeQt in the chain.

 

Did a check in the emulator -- 2.0S stores the format timeout in an internal variable and only updates it when it does disk drive scans before and after booting. Due to the way the scan works, the timeout always comes from D1:.

 

Ok, thank you both Phaeron and Hias, time to do some changes

[atari8warez]

Made the change and it now works perfectly , thank you guys....

Edited December 10, 2014 by atari8warez

[atari8warez]

Try changing the 3rd byte you return in the 0x53 get status command from 3 to 0xe0 (1050 returns 0xe0, XF551 0xfe).

 

Just out of curiosity, why do you think the 3rd byte (apparently being the "time the drive will need to format a disk" - according to Jindroush documentation) was set to 3 in AspeQt, was that an arbitrary value or was there a reason for that?. I am asking you this because I know you and cyc0130 were once co-operating to add high-speed SIO to AspeQt, so you may have an idea.

[atari8warez]

Well, thinking about this a bit more, I think I know the answer to my own question. He (like me) probably didn't realize that DOS would inherit the format timeout value from the boot drive and when implementing the GET STATUS command in AspeQt he used the minimum value that was necesssary to format a virtual drive, which incidentally a lot faster than formatting a real floppy. Anyway, changing the value to the one used by real drives doesn't seem to have any performance penalty in accessing the virtual drives, so there is no issue.

Edited December 11, 2014 by atari8warez

[HiassofT]

Just out of curiosity, why do you think the 3rd byte (apparently being the "time the drive will need to format a disk" - according to Jindroush documentation) was set to 3 in AspeQt, was that an arbitrary value or was there a reason for that?. I am asking you this because I know you and cyc0130 were once co-operating to add high-speed SIO to AspeQt, so you may have an idea.

I can't remember for sure, but I don't think I looked at the "get status" code back then or talked to cyc0130 about it. We were more focussed on getting highspeed running properly

 

so long,

 

Hias