Spartados X SIO command bytes

[danwinslow]

Spartados X is using the following commands talking to d1:

 

31 D3 0 0

31 48 20 0

31 58 19 0

 

 

etc...

 

I can't find a lot of info on these codes..I think the 48 is looking for a happy drive but I don't know what 58 and D3 are supposed to do.

[danwinslow]

Hmm, well the D3 command has bit 7 on, so thats an xf551 high speed data sector flag. Without it, though, its an 83, which I don't know how to respond to.

 

*edit*

Ok, that $D3 is a $53, not 83 ( forgot to hit HEX again ). So $D3 is a status request ($53) with bit 7 high. This is spartadosx looking for an xf551. The problem I am having responding is that this drive uses the mode where the command gets sent at 19.2k, but the data blocks get sent at high speed. I need to put that response mode in, right now I have it all (command and data) at the same speed.

Edited August 20, 2005 by danwinslow

[danwinslow]

Bump?

[ijor]

Bump?

915442[/snapback]

 

I guess nobody knows … and I think you shouldn’t bother.

 

If I understand what you are doing, you are developing hardware. Then, IMHO, you should work the other way around. Don’t try to understand everything that the software sends, but instead properly process whatever your hardware is supposed to understand. If you want a hardware device compatible with Happy, USD, INDUS, etc; then just find what commands those devices support.

 

A piece of software, like SpartaDOS, might send commands for completely unknown reasons. It might be targeted for a type of drive that nobody knows, for a prototype that was never released. It might be an invalid command for debugging purposes, or it might be even a bug that was never fixed (because it would be harmless). It could also be a custom command that was previously programmed. For example, you can add custom commands to the Happy or the Speedy.

 

Being said that, if I’d need to guess, it might be related to the Indus Synchromesh. I’m not very familiar with the Indus, but Steven probably is. One possible way to find out is trying other DOS versions and check if they issue the same command. Try the DOS XL provided with the Indus, try different versions of SpartaDOS as well. For example, older versions of SpartaDOS don’t support the XF-551. Or yet better, if you have an Indus drive, just see how it replies to this command.

[danwinslow]

Well, I am developing software to interface hardware. This device is a combination ethernet card, 32MB flash disk for hosting ATR files, and real time clock. I am cycling through all of the various DOS's I have to ensure that I can at least boot from the device with all of them. I have been able to get Spartados X to boot, but I am also trying to get high speed IO going if possible. FTP is a lot better at 56k than at 19.2. I am trying to explore why Spartados X doesnt switch over to high speed the same as some other dos's ( or even earlier versions of itself ). Most other dos's seem to open with a $3F and they honor the response if they are able. Sparta X does not even send a $3F, at any point in the boot.

 

And yes, I was hoping you and Steve would weigh in on this

Edited August 21, 2005 by danwinslow

[ijor]

I am trying to explore why Spartados X doesnt switch over to high speed the same as some other dos's ( or even earlier versions of itself ). Most other dos's seem to open with a $3F and they honor the response if they are able. Sparta X does not even send a $3F, at any point in the boot.

 

What exactly are you replying to the custom commands (Happy,XF-551,USD, etc)? Or you are NAKing them all except the $3F one?

 

You might have a problem if you are trying to emulate all the enhanced drives together. It is fine as long as the software is targeted for a single type of drive. But SpartaDosX supports most of them, and then it might get confused if it thinks you are multiple drive types at the same, say, both an USD and a XF-551.

 

And what exactly are you booting with SpartaDosX? I mean, with other DOSes you boot the DOS disk itself, but you normally don’t boot anything with X. Or you are emulating an empty drive in this case?

[drac030]

Spartados X is using the following commands talking to d1:

 

31 D3 0 0

31 48 20 0

31 58 19 0

 

 

etc...

 

I can't find a lot of info on these codes..I think the 48 is looking for a happy drive but I don't know what 58 and D3 are supposed to do.

 

$D3, as you already figured out, is the STATUS code for XF-551. The rest you listed is loading Synchromesh routines into LDW 2000 Super (or Indus GT). You can safely ignore this, unless you are going to emulate these drives.

[danwinslow]

Ijor - I am booting from cartridge, so it doesn't matter ( I think ) whats in that ATR slot. It's been a variety. I have done pretty much everything I could think of in response to those bytes...ignored nak'd ack'd etc. Sometimes it does get confused, sometimes it goes on ahead, but it never switches over to high speed.

 

Draco - thanks..I was suspecting it might be Indus related, especially after Ijor mentioned that possibility. I have no interest in emulating specific disk hardware, but I would like to figure out how to get Sparados X to switch over to a higher baud rate.

[drac030]

I would like to figure out how to get Sparados X to switch over to a higher baud rate.

 

First, you must decide which high speed protocol you want to use. SpartaDOS X supports three of them, US Doubler, XF-551 and Indus. The easiest to implement is the US Doubler protocol, but Indus is faster (this does 68,2 kbps, while for the US Doubler the SpartaDOS X routines use fixed baud rate of 52 kbps).

 

Once you decide on the protocol, you simply implement it, and that's all. I admit, that you rather need a detailed description, and won't do much with trial and error. If you understand C, perhaps this will help you:

 

http://drac030.krap.pl/sio2bsd.tar.gz

[danwinslow]

I want to generically respond to any boot, if possible, such that I can get it into a higher baud rate. So depending on which one Spartados X probes for first, I would just like to respond appropriately. 52k and 68.2k are speeds I do not have handled yet, so perhaps adding them in would do something.

C is my native language. Thanks for the source, I will study it.

[danwinslow]

OK...thats about what I expected. The one significant thing I am missing is a uSec delay routine. It didn't seem to matter with the DOS's that just throw the whole bus into high speed, but I guess with the finicky ones that only want the data xmitted high speed it makes a difference. There's a comment to that effect as well in the source Drac posted.

The board I am working on does not have the usual DOS timers, so I will have to roll my own. Will post back with results.

[ijor]

OK...thats about what I expected. The one significant thing I am missing is a uSec delay routine. It didn't seem to matter with the DOS's that just throw the whole bus into high speed, but I guess with the finicky ones that only want the data xmitted high speed it makes a difference. There's a comment to that effect as well in the source Drac posted.

The board I am working on does not have the usual DOS timers, so I will have to roll my own. Will post back with results.

916631[/snapback]

 

I'm not sure your problem is related to delays in the order of microseconds. Delays are certainly important, and you should read the required delays for the SIO protocol. See the relevant section in the technical reference (Operating System User's Manual).

 

However SIO delays are not in the usec order. The smallest delay performed by drives is around 100/250 microsecs. You can safely use a single millisecond delay when needed.

 

Do you get XF-551/Indus high speed correctly with other DOSes (for example DOS XE)?

[danwinslow]

Hmm. OK, milli seconds are good with me too .

 

DOS XE never even tries. It does a status $53, and I guess there must be something its seeing ( or not seeing ) in the status reply that makes it conclude there's no xf551 attached. It never sends anything with bit 7 high, just cruises along reading sectors and then does some $4e's ( percom get ). Sparta X does not do a $4e. I am not currently responding to the $4e, so I'll put that in and see what DOS XE makes of it.

 

*edit*

I *do* have to wait for the computer to ask for high speed, right? I can't just start sending sector data at 38.4 on my own, can I?

Edited August 23, 2005 by danwinslow

[drac030]

I *do* have to wait for the computer to ask for high speed, right? I can't just start sending sector data at 38.4 on my own, can I?

 

Sure, you have to wait. Your device is supposed to change the speed not sooner than after it sent the first ack replying to a command where the command byte has bit 7 set.

 

Edit: unless you can somehow externally convince the computer's Pokey to change the speed. You could then change the transfer speed almost at any time you could want. Pokey has a CLOCK INPUT line, but honestly I don't know if it could be of any use.

Edited August 23, 2005 by drac030

[ijor]

Sure, you have to wait. Your device is supposed to change the speed not sooner than after it sent the first ack replying to a command where the command byte has bit 7 set.

 

Be very careful with this. It is much trickier than it seems. One thing is "after the byte was completely transmitted", and another is "after you wrote the byte in the UART xmit register". And this applies to delays as well, not only for changing the transmission speed.

 

If the delay is long enough, then there is usually no problem. Otherwise you must wait until the byte transmission ended. Exactly how to do this depends on your specific UART.

 

You could then change the transfer speed almost at any time you could want. Pokey has a CLOCK INPUT line, but honestly I don't know if it could be of any use.

 

That's an issue I raised some time ago. It is not useful here because pokey is in async mode. But Pokey can be programmed in sync mode at the computer side (actually, there are several pokey sync modes).

 

Interesting if it does work at all. AFAIK there is no peripheral that uses sync mode. So it's possible that this was never tested by Atari engineering. It would be very interesting to test it.

 

Note, btw, that you can use the Clock Output signal without any changes at the computer side. It is (again, in theory) active in async mode.

[drac030]

Be very careful with this. It is much trickier than it seems. One thing is "after the byte was completely transmitted", and another is "after you wrote the byte in the UART xmit register".

 

Yes, "sent" is to be understood litterally, as "transmitted out completely over the line to the other side".

 

Interesting if it does work at all.

 

Some guy here says he tried; he says it didn't work. But he might have overlooked something.

 

Note, btw, that you can use the Clock Output signal without any changes at the computer side. It is (again, in theory) active in async mode.

 

CLOCK OUT is said to be active. From what I was told, it is used by some third party disk drives to detect the US Doubler protocol. I can't verify it myself, I don't construct disk drives, I don't have an oscilloscope etc.

[danwinslow]

Well, a pause after the ack to allow the ack to be completely sent before switching speeds is easily done. Still wondering what I need to do in a $53 response to get DOS XE to poll for a XF551.

 

Sync mode....not real familiar with sync serial, except from way back in x.25 days. Any info on how to get started looking at that? I would really like to be able to crank SIO up and down manually from the atari side, but I got a bit shy of the work involved. Machine language on 6502 is not my strong point.

Edited August 23, 2005 by danwinslow