OS Programming the SIO

[HiassofT]

17 hours ago, Alfred said:

Perusing Hiassoft's code, he has the speed command as: ?CMD3F  .BYTE $3F,$40       
?ABS21  .WORD HIBUF,1,1,$20 

 

I don't understand why DAUX1/2 needs to be set to $20, but Puff does it too, so there must be a reason. Try that, set $30A to $20 and $30B to zero.

Not sure why Bob Puff did it, but in my case I set DAUX to $20 so it already contains the needed values for the possibly following $48 Happy command (to enable fast writes) - two additional LDA/STAs for DAUX would have needed more space than adding two more bytes to the ?CMD3F values and increasing the loop counter by two.

 

so long,

 

Hias

[TGB1718]

Just in case you didn't know, but if your reading sequential sectors into a buffer, there's no

need to reload the sector count (DAUX1 and DAUX2), nor the buffer address, I used this code

in a disk copier I wrote bitd, I also wrote one for DD disks, they used the 130XE extra memory

to copy SD in one pass, enhanced and double density in 2 passes 

Code snip:-

INCREMENT INC DAUX1 ; next sector
                  BNE ADD
                  INC DAUX2
ADD           CLC 
                 LDA #$80 ; add 1 sector to buffer pointer for SD/ED disks
                 ADC DBUFLO
                 STA DBUFLO
                 LDA #0
                 ADC DBUFHI
                 STA DBUFHI

[Zolaerla]

Just a few months ago, I wrote a complete SIO system for my custom OS from scratch, with a huge amount of drive detection in a loader (it is not included in the final OS, it only runs on initialize). I had to reference so many things to figure out the whole thing, but I have about a billion notes and a heavily commented (OOP-ish) CA65 assembly for it. I also translated HIASSOFT's HiSIO to CA65 and commented it like crazy as well to try to figure out how it handled the non-US Doubler high speed detection. So if you have any questions about the actual hardware side of things, I can help with that.

 

I am not knowledgeable about how the Atari OS handles it, since I only have ever worked directly with the hardware, however.

 

My post where I try to figure out how to detect drives is here, for the curious:

 

And I didn't notice Hiassoft posted already, but here are what those values translate to at ?CMD3F and ?ABS21:
DCOMND = $3F - Get Speed
DSTATS = $40 - Read
DBUF = HIBUF
DTIMLO = 2
DUNUSE = 0
DBYT = 1
DAUX1 = $20 - Set flags bit 5 (Enable/Disable Write Buffering)

DAUX2 = $0  - Enable Write Buffering

 

If you wanted to see the heavily commented HISIO, maybe it'll help clear some things up? Anyways, it's here:
http://docs.zolaerla.com/Media/Atari/SIO/HISIO-CA65.zip

 

Edited April 12, 2023 by Zolaerla
added additional info

[reifsnyderb]

I am now able to do some basic SIO speed detection but still can't get a high speed read to happen.  It fails with a Boot Error message.

 

Right now, I am working with, and focusing on, an emulated Happy 1050.  From what I understand it should work in "Ultraspeed" mode.  That is:  Both the command and data should be able to run at 52,600 baud.  If I try this, it fails.  After spending quite some time studying the available documentation, I am wondering if the read command is wrong.

 

So, right now, I get the high speed index, by sending the $3F command to the drive, and get the POKEY divisor as $0A.  Then, I send the the happy command $48 to the drive.  I also set the POKEY divisor to $0A.  But it still doesn't work.  (Reads with a POKEY divisor of $28, at 19,200 baud, work fine.)  Do I have to now access the drive with the high speed commands?  i.e.  Instead of using $52 for a read, I need to use $72 for the read command?  If this is the case, how can the software figure out that it should use $72 instead of $52 or even $D2 for a read?

 

Thanks!

 

Brian

[drac030]

In UltraSpeed you use standard commands, e.g. R ($52) for read etc.

 

But you may want to check - using e.g. Altirra as a debugger - if your SIO code receiving data is fast enough to cope with 52 kbs. Especially the Ack bytes may arrive too fast. At 19200 you have about 920 clock cycles of interval between bytes, at 52600 it is about 1/3 of that (340 or so).

 

[phaeron]

$72 is for the Happy 1050's native high-speed mode with XF551-like timing (38400 baud). It's separate from the US Doubler emulation.

 

You need to check which SIO call is failing and with what error code. If it's failing out almost immediately, then you're probably issuing the wrong calls to the drive. If you can hear it running through the full set of 27 retries, then it's probably a high-speed timing problem. Then, check the execution history in the debugger to see what bytes SIO read and whether it dropped a byte at some point.

 

 

[Zolaerla]

What you're describing is using the US Doubler-style of speeding up SIO. If you get a response from $3F of $0A, then you're on a Happy 1050 Rev 2, which supports this. Using the US Doubler-style speed up means that you are sending the command frame at the high speed. For non-US Doubler speed ups, you either speed up before the first ACK (1050 Turbo or Indus GT [Super]Synchromesh) or just after it.

 

In my implementation of US Doubler, I set PBCTL to $34, AUDF4 to 0, AUDF3 to the desired divisor ($0A), set AUDCTL to $28, set AUDC4 to $A0 (bit 7 set is all that needs to be set I believe), then have a forced ~720-750us [~1300 cycles] delay before writing the command frame out, and immediately set PBCTL to $3C then read the ACK byte. With US Doubler, it is expected that the command frame will fail on occasion so the drive internally can switch gears to fast communication, so it might take a couple tries to get a positive ACK. Is there a way you can test that you're just getting to an 'A' response successfully and then aborting the transmission just to make certain it's all working at that point? In Altirra, you can just debug it at that point as well, of course...

Edited April 13, 2023 by Zolaerla
I said ms, I meant us, for the delay

[reifsnyderb]

I got the Altirra Performance Analyzer working!  That thing is great!   🙂

 

I found a problem with Atari's implementation of high speed SIO and what is normally being used.  Atari used CRITIC and set CRITIC to $81 as a "supercritical I/O" flag.  When CRITIC was set, SIO was also set to 38,400 baud.  So, I changed the location of CRITIC being set to $81 and commented out the change to 38,400 baud as it was working against me.  Right now, I am focusing on using the performance analyzer, comparing what works and what doesn't work, and making sure the SIO code is working correctly.  It's not working beyond 38,400 baud, yet, but progress is being made.