Jump to content
IGNORED

OS Programming the SIO


Recommended Posts

Is there any "Idiots Guide" type document out there that shows how to program the SIO directly?  As usual, most documentation is scattered to the four winds.  Mapping the Atari has some information, another web site has some other tidbits, etc., etc.  Reading the OS source code and all the other stuff has gotten me this far. 

 

What I am trying to do is to get the speed byte from a device.  If I understand it right, "all" I need to do is to setup everything properly in the Device Control Block.

 

So, everything from $300 to $30B might need set.  Or some things may be skipped.  Who knows?

 

I think if I want to get the speed byte I need to set everything as follows:

DDEVIC ($300) = $31

DUNIT ($301) = $01

DCOMND ($302) = $3F     (command for speed byte)

DSTATS ($303) = $40

DBUFLO/HI ($304,$305) = $0600   (yeah, I used page 6 for a test....all I want is one lousy byte)

DTIMLO ($306) = I left it alone.  Mapping the Atari says it's initialized to 31.

DUNUSE ($307) = I left it alone.  Mapping the Atari says it's not used.

DBYTLO/HI ($308,$309) = $0001  

DAUX1/2 ($30A,$30B) = Who cares?  I am looking for the speed byte....

 

I am calling within the OS to directly within the SIO routine.  So, it's a little different....but should work if all of the information is in place.

 

My response, in DSTATS is $8B.  This is supposed to be NAK as per http://www.oldcomputers.it/parts/atari/800/docs/atari_os/atari_os_user_manual_c.htm

I am thinking that DSTATS should be responding with $01 and that $600 should be my Pokey Divisor.

 

If there is anything that appears wrong or out of place, or missing, please let me know.

 

Oh, yeah, I am using Altirra with a US Doubler drive as drive 1.  The firmware is loaded for this drive.

 

If anyone has a link to a good manual on this, I'd love to RTFM but can't find the M.

 

Edit:  paging @HiassofT

 

Thanks!

 

Brian

 

 

 

Edited by reifsnyderb
  • Like 1
Link to comment
Share on other sites

What you want is the Sparta Dos Construction Set manual. Appendix G lists all the commands the US Doubler supports. Your code looks alright but I've never used the speed index command myself. DTIMLO is usually set to 15 for not slow operations, like read or write, but much higher for say formatting a diskette.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

19 minutes ago, Alfred said:

What you want is the Sparta Dos Construction Set manual. Appendix G lists all the commands the US Doubler supports. Your code looks alright but I've never used the speed index command myself. DTIMLO is usually set to 15 for not slow operations, like read or write, but much higher for say formatting a diskette.

Thank for the reference.  It's an interesting manual.  However, all it did was confirm that $3F is a valid command to get the speed byte. 

Link to comment
Share on other sites

5 minutes 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.

Thanks for finding that.  I don't know why it would be set but it didn't make a difference.  I am curious, though, as to why that was set.  Maybe something else that's undocumented?

 

  • Like 1
Link to comment
Share on other sites

What you have there looks valid. I would recommend setting DTIMLO, as you have no guarantee it's set appropriately, though if it timed out you would know (Y=$8A). Similarly, it's a good idea to clear AUX1/AUX2 even though they're not used by the command, because you never know what weirdness drive firmware may do. My favorite example is the XF551 V7.7 firmware, which will format the disk endlessly in a loop if the AUX bytes spell $1050.

 

In Altirra, there are a few things you can do to debug. The SIOCMD logging channel (lfe siocmd) will show you SIO commands being emitted from the computer, and SIODATA (lfe siodata) will log the raw data transfers. You can also see the SIO bus traffic in a performance trace (Debug > Performance Analyzer). The standard disk drive emulator also supports this command in most emulation modes.

 

  • Like 2
Link to comment
Share on other sites

NAK is an odd error, that's what you get when the drive door is open. I'm not sure about DTIMLO getting set by the OS, I think Mapping is thinking of the DSKINV call at $E453, which does do some stuff, but you should be calling SIO directly at $E459 for this command. Might as well try it, set DTIMLO to something, 5 or whatever, and $0307 to zero, and if that doesn't work, then it's probably a config issue in Altirra.

Link to comment
Share on other sites

7 minutes ago, phaeron said:

What you have there looks valid. I would recommend setting DTIMLO, as you have no guarantee it's set appropriately, though if it timed out you would know (Y=$8A).

Ok.  I set it to default.  No change.

7 minutes ago, phaeron said:

Similarly, it's a good idea to clear AUX1/AUX2 even though they're not used by the command, because you never know what weirdness drive firmware may do.

I set them both to zero.  No change.

7 minutes ago, phaeron said:

My favorite example is the XF551 V7.7 firmware, which will format the disk endlessly in a loop if the AUX bytes spell $1050.

Good grief.  I could imagine having some sort of odd problem and spending hours to track that down.

7 minutes ago, phaeron said:

In Altirra, there are a few things you can do to debug. The SIOCMD logging channel (lfe siocmd) will show you SIO commands being emitted from the computer, and SIODATA (lfe siodata) will log the raw data transfers. You can also see the SIO bus traffic in a performance trace (Debug > Performance Analyzer). The standard disk drive emulator also supports this command in most emulation modes.

Sounds interesting.  How do I use the SIOCMD logging channel?  Do you have a link to a doc on this?  I don't see anything about SIO bus traffic in the performance analyzer.  I probably have something configured wrong.

Link to comment
Share on other sites

3 minutes ago, Alfred said:

NAK is an odd error, that's what you get when the drive door is open. I'm not sure about DTIMLO getting set by the OS, I think Mapping is thinking of the DSKINV call at $E453, which does do some stuff, but you should be calling SIO directly at $E459 for this command. Might as well try it, set DTIMLO to something, 5 or whatever, and $0307 to zero, and if that doesn't work, then it's probably a config issue in Altirra.

Actually, I am re-compiling the OS and adding my own entry point to the SIO command.  The goal is to integrate high speed SIO into the OS.

 

In order to save space, I am trying to re-use the SIO function.  So, within the SIO function, once it's determined that the device isn't the cassette player, a function is called that checks to see if this device has been checked for it's type and speed.  If it has, the function returns back to the SIO function.  On the other hand, if it is determined that the device hasn't been checked, the device control block is saved and I am attempting to recursively use part of the SIO function to determine what sort of device this is.  (i.e.  That's why I need to call the get speed command.)  The plan is that once it's determined, the device control block will be restored and the SIO function will continue as though nothing happened.  Of course, the SIO function will be modified, slightly, to handle the higher speed devices.  Atari's high speed SIO patch should integrate nicely with this plan.  Looking through the source code, I believe this is a viable plan.  I managed to get the Get Status command working. 

Link to comment
Share on other sites

1 minute ago, Alfred said:

Looking at the OS SIO code, I see no evidence that is sets $0306 or $0307. NAK is the default error if the device responds with something other than ACK/NACK/ERROR.

Yeah, I didn't see it either.

 

Nak vs Nack?  Is there a difference or is that a typo?  I didn't see any mention of that....or missed it.

Link to comment
Share on other sites

15 minutes ago, Alfred said:

I think Mapping is thinking of the DSKINV call at $E453, which does do some stuff, but you should be calling SIO directly at $E459 for this command.

You not only should but must call SIOV. Otherwise DBYTLO/HI will automatically be set to $80.

Link to comment
Share on other sites

Just now, reifsnyderb said:

Yeah, I didn't see it either.

 

Nak vs Nack?  Is there a difference or is that a typo?  I didn't see any mention of that....or missed it.

The error codes in my copy of the OS source are different for the drive than what the OS returns. So it shows the drive returning an error of NACK whereas the OS returns the error code NAK which is a different value.

 

I see, you're rolling your own SIO. Well you can forget using the stock OS routines, they use interrupts. You can't do that for high speed sio, you have to switch to polling because interrupts are just way too slow. Instead of re-inventing the wheel, why not just patch in Hiasoft's code. Throw out the international character set, and the cassette handler, that's usually what everyone does to get room in the rom for their custom code. Good luck.

Link to comment
Share on other sites

7 minutes ago, Alfred said:

The error codes in my copy of the OS source are different for the drive than what the OS returns. So it shows the drive returning an error of NACK whereas the OS returns the error code NAK which is a different value.

Interesting.  I didn't know there was a difference.

7 minutes ago, Alfred said:

I see, you're rolling your own SIO. Well you can forget using the stock OS routines, they use interrupts. You can't do that for high speed sio, you have to switch to polling because interrupts are just way too slow. Instead of re-inventing the wheel, why not just patch in Hiasoft's code. Throw out the international character set, and the cassette handler, that's usually what everyone does to get room in the rom for their custom code. Good luck.

I am trying to keep the international character set and cassette handler in.  I think it's possible.  I've already re-wrote the self test and saved a considerable amount of space.

 

The Atari high speed SIO patch was from the 1450 XLD fork of the OS and doesn't use interrupts when going to high speed.  I think it will work.  I just have to figure out how to determine the speed and the drive.  I am using Hiasoft's excellent readme file to help figure out the correct algorithm to handle drive speed.

 

I was entertaining the idea of fixing the SIO routine to the right address and patching in Hiasoft's code.  However, then the international character set would be lost.  I am trying to keep it.   🙂

 

 

Edit:  Here's a link to the OS:    https://forums.atariage.com/topic/347696-compiling-a-new-atari-os/

 

 

Edited by reifsnyderb
Link to comment
Share on other sites

26 minutes ago, reifsnyderb said:

Sounds interesting.  How do I use the SIOCMD logging channel?  Do you have a link to a doc on this?  I don't see anything about SIO bus traffic in the performance analyzer.  I probably have something configured wrong.

I listed the commands -- the 'lfe' debugger command enables a logging channel. 'lfl' lists logging channels, and 'lfd' disables a logging channel.

 

The performance analyzer will automatically log SIO bus traffic. You do need to tell it explicitly to start and stop recording. This is what a trace of the get high speed index command looks like.

image.thumb.png.2d6c89e1be8295d7f769ebe9a07633d4.png

  • Like 2
Link to comment
Share on other sites

negative acknowledgement (device) vs not acknowledged(OS/software) , on some devices it can also mean rejected which is incorrect use of nack. The device itself NACKs, the OS NAKs.

NACK from a device to a receiver of the data sends a message to ensure that the requester resends the needed data.

Depending on its implementation, NACK can often serve the same purpose as other network acknowledgment solutions like REJ or ACK for things like the Network Cards/Cartridges, or even FujiNet, though I am not certain if FN implements it through SIO since REJ (reject) isn't something formally seen in our circles but is akin to Negative.

 

Original SIO outlined

First the computer sets the COMMAND line on the SIO line to the jack.
Then it sends the command block (4 bytes + checksum)
Then waits it waits for a response (1 byte without a checksum):
$41 (A) = Acknowledge, the command is valid and will be executed.
$4E (N) = Negative, the command is invalid.
If the device responds "N", the transfer is normally aborted.
If it responds "A" the data block is transferred with the checksum.
Now the computer waits for a final acknowledge of 1 Byte without a checksum
$43 (C) = Complete, operation completed successfully.
$45 (E) = an Error has occurred.

If any of these do not respond at all a timeout will occur.

 

https://github.com/HiassofT/highspeed-sio

https://www.horus.com/~hias/atari/#hipatch

explains things very well and his website carries the latest greatest stables

in addition to this excellent resource, search up PCLINK driver, and look over some of the burst mode discussions.

 

I know you want to implement just what Atari had in mind, and the smaller the changes the better so it's all food for thought.

 

Edited by _The Doctor__
  • Thanks 1
Link to comment
Share on other sites

9 hours ago, _The Doctor__ said:

https://github.com/HiassofT/highspeed-sio

https://www.horus.com/~hias/atari/#hipatch

explains things very well and his website carries the latest greatest stables

in addition to this excellent resource, search up PCLINK driver, and look over some of the burst mode discussions.

 

I know you want to implement just what Atari had in mind, and the smaller the changes the better so it's all food for thought.

 

I am using the readme file, from the Hiass patch, to figure out how to do this.  His documentation is very good.

 

That's a big part of the goal:  To keep the resulting OS along the lines of what the Atari OS would be if it was actively developed.

Link to comment
Share on other sites

9 hours ago, phaeron said:

I listed the commands -- the 'lfe' debugger command enables a logging channel. 'lfl' lists logging channels, and 'lfd' disables a logging channel.

 

The performance analyzer will automatically log SIO bus traffic. You do need to tell it explicitly to start and stop recording. This is what a trace of the get high speed index command looks like.

image.thumb.png.2d6c89e1be8295d7f769ebe9a07633d4.png

I think I figured out my problem.  I am running Altirra on Linux via wine.  I think I am unable to issue commands because of some incompatibility.

Link to comment
Share on other sites

hi @reifsnyderb,

 

   Maybe this is useful: https://www.atarimax.com/jindroush.atari.org/asio.html

 

   Also, you might try something simple like reading an $80 byte sector 1-3 (works on all drives apart from 512 byte sector drives, I believe), then tweaking the code for other commands, once you are sure you can talk to a drive.

 

    @tschak909 uses a nice approach in the FujiNet Mount and Boot routines of just defining the SIO DCB in tables, and then copies them into the DCB per call. See: https://github.com/FujiNetWIFI/fujinet-mount-and-boot/blob/main/atari/src/mount-and-boot.s

  • Like 2
Link to comment
Share on other sites

11 hours ago, _The Doctor__ said:

negative acknowledgement (device) vs not acknowledged(OS/software) , on some devices it can also mean rejected which is incorrect use of nack. The device itself NACKs, the OS NAKs.

NACK from a device to a receiver of the data sends a message to ensure that the requester resends the needed data.

Depending on its implementation, NACK can often serve the same purpose as other network acknowledgment solutions like REJ or ACK for things like the Network Cards/Cartridges, or even FujiNet, though I am not certain if FN implements it through SIO since REJ (reject) isn't something formally seen in our circles but is akin to Negative.

 

Original SIO outlined

First the computer sets the COMMAND line on the SIO line to the jack.
Then it sends the command block (4 bytes + checksum)
Then waits it waits for a response (1 byte without a checksum):
$41 (A) = Acknowledge, the command is valid and will be executed.
$4E (N) = Negative, the command is invalid.
If the device responds "N", the transfer is normally aborted.
If it responds "A" the data block is transferred with the checksum.
Now the computer waits for a final acknowledge of 1 Byte without a checksum
$43 (C) = Complete, operation completed successfully.
$45 (E) = an Error has occurred.

If any of these do not respond at all a timeout will occur.

 

https://github.com/HiassofT/highspeed-sio

https://www.horus.com/~hias/atari/#hipatch

explains things very well and his website carries the latest greatest stables

in addition to this excellent resource, search up PCLINK driver, and look over some of the burst mode discussions.

 

I know you want to implement just what Atari had in mind, and the smaller the changes the better so it's all food for thought.

 

Right, NAK is what the OS returns if the drive response is not A\N\C\E.

Link to comment
Share on other sites

2 hours ago, E474 said:

Thanks!  I've used that page.  It would be nice if it gave the entire DCB that was needed.

2 hours ago, E474 said:

   Also, you might try something simple like reading an $80 byte sector 1-3 (works on all drives apart from 512 byte sector drives, I believe), then tweaking the code for other commands, once you are sure you can talk to a drive.

I can get the status and it appears correct. 

2 hours ago, E474 said:

 

    @tschak909 uses a nice approach in the FujiNet Mount and Boot routines of just defining the SIO DCB in tables, and then copies them into the DCB per call. See: https://github.com/FujiNetWIFI/fujinet-mount-and-boot/blob/main/atari/src/mount-and-boot.s

I wish all code was that clean....

 

Link to comment
Share on other sites

I just changed to an emulated Happy 1050 and just got the speed byte!!!

 

Thanks to everyone that was trying to help.  I think the emulated US Doubler wasn't returning the speed byte for some reason.  I have no idea why not.  I'll get this working with the emulated Happy 1050 first.

Link to comment
Share on other sites

3 hours ago, E474 said:

@tschak909 uses a nice approach in the FujiNet Mount and Boot routines of just defining the SIO DCB in tables, and then copies them into the DCB per call. See: https://github.com/FujiNetWIFI/fujinet-mount-and-boot/blob/main/atari/src/mount-and-boot.s

That's a really neat way of doing it.

Link to comment
Share on other sites

17 hours ago, Alfred said:

I don't understand why DAUX1/2 needs to be set to $20, but Puff does it too, so there must be a reason.

The reason is probably to prevent Atari 850 from responding to that command (where $3F=POLL). Daux1=$00 and daux1=$01 select how the 850 responds to POLL, so I guess (I did not check it myself) when daux1 is anything but $00 or $01, 850 does not respond at all. I also saw daux1=$03 used with '?' with the same justification.

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...