High speed disk io

[danwinslow]

Can anyone provide me some information or links to information about responding to a speed byte request? I am working with a device to emulate a disk drive, and I would like to switch into high speed io.

 

The computer opens up the boot conversation with a $3F command, which is a request for pokey speed divisor. If I respond with $28 $28, it stays in 19.k baud mode. If I respond with $09 $09, for instance, that should switch it over to 57kbaud mode. I can swithc my serial line on the disk emulator over to that baud, but all I get is garbage. Here's whats happening :

 

computer sends: 31 3f 0 0 70 ( thats a request for a pokey speed divisor pair )

I respond :ack,complete,$09,$09

I switch line over to 57kbaud.

computer sends garbage : fe 0 0 10 f8

 

Do I have to wait to switch baud rate? Do I have to send a high speed SIO driver? Any info appreciated.

 

Thanks.

[ijor]

You don't have to send any driver code. You don't have to wait to swith the speed, but :

 

1) You should be ready to receive garbage. The software might be trying to talk to a different device, and then it might use a different transmission speed.

 

2) You need to adapt your speed dynamically. There are several reasons why the computer might go back to the standard SIO speed.

[ijor]

One more thing. I'm not sure every DOS/software is ready to handle the $09 divisor. Is possible that some are hardwired for the standard $0A divisor used by USD and compatible devices (yeah, I know you can't use it). This shouldn't be a problem with later and euro software though.

[danwinslow]

Thanks, Ijor.

 

On point 1 : Ok, I can ignore garbage.

On point 2 : I can adapt dynamically, but the question is, when? What conditions might make me need to drop back to the standard speed?

 

Also, why can't I use the $0A divisor? It leads to a non-standard serial baud rate you mean? 52k baud, if I recall. Actually, I can set my own baud rate divisor on the emulation side so maybe I can adapt to that.

[Shawn Jefferson]

I could be totally off-track here, but I thought I read somewhere that the computer sends commands at the normal baud rate, no matter what the data baud rate might be?

[danwinslow]

Yes...I have seen a few indications of that too...but I am not sure exactly when to switch to hi speed...is it strictly in the data block transmission? This would mean that all normal commands and acking and so forth would happen at 19.2k, and then put/get sector data block would switch into hi speed and then back down?

 

Here's a trace of what I get after responding for $09 $09 but NOT actually changing baud at all :

 

processing header 31 3f 0 0 70 // this is the hi speed query

processing header 31 53 0 0 84 // request status

processing header 31 52 1 0 84 // read sector 1,2,3

processing header 31 52 2 0 85

processing header 31 52 3 0 86

processing header 31 52 4d 7 d7 // still reading sectors

processing header 31 52 4e 7 d8 // still at 19.2k by the way

processing header 31 52 4f 7 d9

processing header 31 52 50 7 da

processing header 31 52 51 7 db

processing header 31 52 52 7 dc

processing header 31 52 53 7 dd

processing header 31 52 54 7 de

processing header 31 3f 4 7 7b // now this is another $3F request...with sector numbers set?

processing header 2f fe 2f fe 2f // looks like the atari swicthed to hi speed here?

checksum not ok, 47 != 92

processing header f fe 2f fe 2f

checksum not ok, 47 != 60

processing header f fe 2f fe 2f

checksum not ok, 47 != 60

processing header 2f fe 2f fe 2f

checksum not ok, 47 != 92

processing header 2f fe 2f fe f

checksum not ok, 15 != 92

processing header 2f fe f fe f

[ijor]

I can adapt dynamically, but the question is, when?

 

Whenever you detect that you are the "wrong" speed. Unmatched speeds usually leads to a fixed behavior. You shouldn't get exactly garbage. But instead, you should get a fixed value for, at least, the first byte. Plus checksum error, plus possible frame error.

 

The exact procedure would depend on the exact behavior of your UART. A possible way would be to swap speeds whenever you detect a frame error. I can post/send you what the USD code does. But not sure it will be very useful for you because the 1050 doesn't have an UART.

 

What conditions might make me need to drop back to the standard speed?

 

The computer might be reset (you can detect power off, but not reset). It might switch between high speed and low speed software, etc.

 

Actually, there are some high speed software that switch to high speed without issuing the $3F command. Technically, the command is/was not needed (as long as you expect a fixed reply value of $0A). It is not needed because the software knows the drive will detect and switch speed automatically.

 

Also, why can't I use the $0A divisor?

 

I should have saud that you might not be able to use it. It depends on your UART. For example, in a standard PC serial port you can't select a bps rate close enough for a pokey $0A divisor.

Edited July 24, 2005 by ijor

[ijor]

I could be totally off-track here, but I thought I read somewhere that the computer sends commands at the normal baud rate, no matter what the data baud rate might be?

 

No, this is true for some high speed devices like the XF-551, the Indus, or the Happy 810.

 

It is wrong for USD compatible devices, which are the ones that use the $3F command.

[danwinslow]

Hmm, ok, interesting. I changed my routines to cycle through a table of baud rates : 19.2,38.4, and 57.6. Every time it gets a bad checksum it rotates to the next baud rate in a round-robin fashion. That lets it lock in on whatever baud rate is trying to be established...seems to be working for stock 130xe OS at 38.4. I have Steve's 32-in-1 so I will be checking all of them.

[danwinslow]

Ok, some variances from documentation...

 

For some reason I have to send 2 bytes in response to the speed byte request. Otherwise the atari hangs.

 

For 57.6k baud, response bytes of $08 $08 seem to work, and $10 $10 for 38.4 baud.

 

A few of the 32 OS's don't like it, but most seem to do ok. The 57.6 speed instantly crashed Steve's Warp OS though. I'll have to ask him about that.

[ijor]

For some reason I have to send 2 bytes in response to the speed byte request. Otherwise the atari hangs.

 

For 57.6k baud, response bytes of $08 $08 seem to work, and $10 $10 for 38.4 baud.

 

Of course you must send two bytes, the second is the frame's checksum.

[danwinslow]

LOL

Um, yeah. Hehe, thanks Ijor.

[ijor]

For 57.6k baud, response bytes of $08 $08 seem to work

 

Be careful when you go for very high bps rates. The computer software might honour your Pokey divisor, but it might not be able to cope with the faster interrupt rate that this will provoke. I won't be suprised if software that runs perfectly well with the "standard" $0A divisor, it crashes when you use a $08 one.

 

And if you go high enough, at some point the small difference in the base clock between PAL and NTSC systems starts to be relevant. So a very high speed might work in PAL but not in NTSC or vice versa.