Jump to content
IGNORED

PBI vs SIO


atarilux

Recommended Posts

Hello, I am getting back into the A8 stuff after nearly 30 years, so please excuse me if I am a little rusty. As part of it I plan to do some hardware projects, part of this my include the need for relatively fast IO - well for an ATARI A8.

 

Therefore I embark on a potentially pointless exercise, what the relative speeds of the PBI vs SIO?

 

Link to comment
Share on other sites

Currently 127Kb/s (~12KB/s) for SIO unless POKEY is clocked via an external source. A PBI device may imply serial or parallel communications, but if you are asking about parallel IO transfer speeds (typically supported by but not confined to PBI devices) on IDE and SD card based devices, you can typically expect to hit 80KB/s. With IDE, for example, bandwidth is limited by only two factors: the response time of the ATA device as it seeks the requested sector and fills its internal buffer (which typically happens in a few MS), and the raw read/write speed of the CPU. Since latency with modern storage devices is so low, the Atari's CPU is the primary limiting factor; it is - for the most part - simply doing load/store operations, coded in the most efficient manner possible.

 

DOS and OS overheads (as the system gets in and out of the PBI handler) will shave a bit off these figures. The SIDE cartridge running RWTEST on a PAL machine under SpartaDOS X will typically hit 64KB/s reads and around 55KB/s writes.

 

Edited by flashjazzcat
Link to comment
Share on other sites

2 hours ago, flashjazzcat said:

Currently 127Kb/s (~12KB/s) for SIO unless POKEY is clocked via an external source. A PBI device may imply serial or parallel communications, but if you are asking about parallel IO transfer speeds (typically supported by but not confined to PBI devices) on IDE and SD card based devices, you can typically expect to hit 80KB/s. With IDE, for example, bandwidth is limited by only two factors: the response time of the ATA device as it seeks the requested sector and fills its internal buffer (which typically happens in a few MS), and the raw read/write speed of the CPU. Since latency with modern storage devices is so low, the Atari's CPU is the primary limiting factor; it is - for the most part - simply doing load/store operations, coded in the most efficient manner possible.

 

DOS and OS overheads (as the system gets in and out of the PBI handler) will shave a bit off these figures. The SIDE cartridge running RWTEST on a PAL machine under SpartaDOS X will typically hit 64KB/s reads and around 55KB/s writes.

 

On typical DOS-over-SIO transfers, overhead is massive (in my opinion), north of 20-25%, which means effective SIO speeds will hardly reach 12 KB/sec, but more like 9KB. However, on SDX and packet-mode (PCLINK) it is possible to achieve 12 KB/sec, as long as data is fetched from 512 Bytes/Sector .ATR mounted in external source such as RespeQt, for instance.

 

As for SIDE 1 and 2, your drivers support up to 105 KB/sec (direct OS reads). About 90 KB/sec via DOS, provided that DMA os off (which is ok. in multiple instances, especially in SDX or non scree-interactive titles). QMeg 4.04 supports on-the-fly DMA=OFF via CTRL-6 keystroke, and immediate restore by pressing any key.

Link to comment
Share on other sites

Yeah, there are other factors I didn't go into, including ANTIC DMA and VBLANK. SDX appears to do an especially good job of mitigating overheads, but it has the advantage of supporting 512 byte sectors, which blow lower densities away.

 

I expect people will want to have the display enabled most of the time, but the crux of it is that divisor 0 SIO gets wiped out by parallel devices in terms of speed.

 

Link to comment
Share on other sites

 

Thanks for tips, I am starting from scratch after about 28 years! The PBI seems the way to go as, as I need "big data" and other time synced data although I could split up the channels so some go via SIO or perhaps even the joystick ports... all rather nuts but there you go. 
I am trying to set myself the programming challenge of doing something you would do in present-day computers with the help of perhaps one external PI/Arduino or similar, however the core processing should be done on a stock 800XL and within its standard memory limits. The other computer would bring all the data together before sending it to the A8. 

Next I need to learn how the PBI works and see if it is feasible...

 

Edited by atarilux
Link to comment
Share on other sites

Although a full PBI implementation isn't really necessary for fast data transfer (the SIDE cartridge being a perfect example; without U1MB, it's accessed via a SpartaDOS X driver which simply patches into DOS's SIO calls at a software level), the nice thing about PBI devices is that they can seamlessly hook into the OS SIO handler. They can also register CIO device handlers, external IRQ handlers, etc.

 

Some useful links if you haven't already found them:

 

http://www.atarimuseum.com/articles/pbi-1.html

 

https://www.atarimagazines.com/v3n9/Parallel_Bus.html

 

https://www.exxoshost.co.uk/atari/mirror/myatari/issues/may2001/pbi.htm

https://www.exxoshost.co.uk/atari/mirror/myatari/issues/jul2001/xl_pbi.htm

https://www.exxoshost.co.uk/atari/mirror/myatari/issues/aug2001/pbi_p3.htm

 

  • Like 1
Link to comment
Share on other sites

Thanks, that's really helpful to know also for the links. I will take a look at SpartaDos as well, I was a MyDos user when I had my Atari back it the day, but I have seen that more and more people are talking about SpartaDos these days, at least from the videos that I have seen.

 

I see you are also doing some cool projects, pre-emptive multitasking on an A8, that alone is impressive. 

 

 

 

 

 

  • Like 1
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...