SIO protocol

[candle]

i did that at #23, transmission of single byte is up to 1mbit, but this is not reliable

i'm doing irq version now

wonder how to calculate speed though

on pc-sisde i could query performance timer i suppose...

i've updated archive with siotest.asm and siotest.xex

here is pc-side software

it just sends 256 bytes to atari, some parts of code were cut from my other programms, so it's a bit messy, but should be simple to read

[atariksi]

I took the hard way and hooked up the PC parallel port in between disk drive and Atari 800 SIO line and logged the signals into a file at various baud rates and then figured out everything from there...

But it worked out better as I found out some things not in the documents. And the Clock In/Out signals are still not completely documented.

 

Exactly which undocumented issues you found?

 

I didn't bother documenting them (just joking).

 

IRQs are handled differently on Atari 400/800 vs. 800XL/XE/XEGS (CLD instruction).

 

When I hooked up the external clock out of SIO to the trigger line on the joystick port, I found out you can relatch HPEN position multiple times per scanline and this external clock is not according to documents (as I found out later when I got the documents). I have been trying to use this to simulate a mouse position registers on Atari using PC mouse but PC timing is a messy situation.

 

The formula for the frequency calculation is not what's documented.

 

Probably some other things -- I don't have all my notes organized in one place.

[atariksi]

Rybags: well, i have a goal of 87kbytes per second, calculate the bitrate for yourself, this would require 20 clocks per byte, and it might be a dream, but i think that with this type of communication this dream might become true

important question is how fast - following the sio protocol or not is smaller issue here - i can get the byte i sent put at specific memory location

all i need is loader, which would go as fast as possible

irq - for that speed, you need to calulate interrupt latency, add the time needed for stack operations and rti instruction - it might be not fast enought

ideally i would do first byte by polling the irqst regiester, and then just get remaining bytes as fast as possible

i don't know the limit of clock speed i can feed to pokey, but i think its well worth futher exploration

and what PMSL means?

 

atariksi: you get me wrong, i want to use ft232 in bit-bang mode - giving me full control of eight bi-directional data lines, so i don't have to deal with any protocol at all

 

If N81 is okay with you, then best approach is to just do: LDA 53773, STA mem; LDA 53773, STA mem+1, etc. and fill this throught a frame taking into account the refresh cycles (9 per 114 CPU cycles). Fill in some NOPs to slow down a bit and make up for refresh cycles where there are none (to keep things perfectly equal as PC won't be able to deal with asymmetric timed I/O). You can in theory get >100KBytes/second. I used the joystick port as I had audio playing in the background while downloading. The irq method and polling methods are inferior to this cycle-exact method.

 

Of course, you won't be able to use the code you posted here of calling API calls and LPT port as those are not timed EXACTLY.

 

Although USB supports high transfer rates-- those are only good for using their protocol which is supported by hardware and I don't think Atari supports that protocol. If you do manually bit settings of USB signals, the overhead of I/O port r/w and timer overhead on top of that will slow you down considerably.

[candle]

let me give all of you advice: start reading documentation

it will be much less of misunderstanding then

btw - its in english, should be easy to read if i'm not making myself clear enough

[atariksi]

let me give all of you advice: start reading documentation

it will be much less of misunderstanding then

btw - its in english, should be easy to read if i'm not making myself clear enough

 

Don't have time to read everything in the zip files you posted whether they are related to USB/RS-232/RT232/LPT/etc. But from the Atari side, the IRQ method only allow for about 3 bytes/scanline so you won't get 87KBytes/second, polling method somewhat better, and cycle-exact method is the only one that can keep up.

[HiassofT]

i have never seen so much ignorance in my entire life!

I'd really like to apologize for not reading the current ft232 docs before posting. I did in no way want to offend or discourage you, honestly.

 

Last time I read the ft232 docs was some 2 or 3 years ago, now I downloaded and read them again (plus also the appnotes concerning bit-banging).

 

Here are some comments:

 

With the FT232R you should be able to transmit up to 1Mbit/sec, but only if you connect the #WR line to the Atari clock in. Bit-banging the Atari BCLK line won't work (you'd be limited to 500k then).

 

Back to Atari stuff:

 

The Pokey datasheet doesn't explicitly contain an upper data rate for the external clocked mode. The only relevant values concerning this case are the 150ns needed for data setup. So, maybe you could go up to ~2Mbit/sec if the pokey uses asynchronous circuits for serial I/O. If there's some logic clocked by the system clock you might be limited to fractions of the system clock (at least at very high bitrates). I don't know how it works and can't tell you, so it's up to you to check it out.

 

But: The Pokey is not a standalone chip, it's integrated into the Atari. As I wrote in my first posting, there are capacitors from the SIO lines to ground. Take out a calculator an check what a 1nF capacitor will do to a 1MHz signal :-)

 

So, before doing any further experiments I highly recommend you remove these capacitors or bend up the Pokey pin(s) and connect short (<20 cm / 8") wires directly to your interface.

 

BTW: A lot of people already had problems using highspeed drives (highspeed meaning some 50-70kbit/sec) due to these capacitors in the disk drives and the Atari computers. Also, most docs of the (1050) highspeed upgrades mentioned this and told you to remove the caps in the drive.

 

so long,

 

Hias

[HiassofT]

What do you mean by Pokey Divisor 4,3 and 1 ?

The value written to AUDF3 to set the SIO transmission rate. Sometimes it's also called "speed byte", and you can read it from ultra speed compatible drives using the $3F SIO command.

 

When doing SIO pokey is usually configured to use 16 bit counters (AUDF3/4 combined, where AUDF4 is set to zero) in 1.79MHz mode, and according to the pokey datasheet the transmission rate then is 1.79MHz/(2*(SpeedByte+7)). To be precise: the clock base is not 1.79MHz, but either 1.773447 MHz (PAL) or 1.7897725 MHz (NTSC).

 

so long,

 

Hias

[HiassofT]

The formula for the frequency calculation is not what's documented.

This is interesting! Could you please elaborate on this?

 

so long,

 

Hias

[HiassofT]

If N81 is okay with you, then best approach is to just do: LDA 53773, STA mem; LDA 53773, STA mem+1, etc. and fill this throught a frame taking into account the refresh cycles (9 per 114 CPU cycles). Fill in some NOPs to slow down a bit and make up for refresh cycles where there are none (to keep things perfectly equal as PC won't be able to deal with asymmetric timed I/O). You can in theory get >100KBytes/second. I used the joystick port as I had audio playing in the background while downloading. The irq method and polling methods are inferior to this cycle-exact method.

NAK. This method will fail in case the clocks aren't synchronized properly. In real world you'll always have to deal with drifting clocks.

 

A method to solve is this problem is of course to introduce some synchronization points (like the pokey does, it synchronizes it's clock at the start bit). For example: define a maximum clock deviation, use a block mode, and set the block size so that the last item of the block will still be received within the set time limits (=target time plus/minus maximum allowed deviation). Then synchronize and go for the next block.

 

so long,

 

Hias

[Rybags]

Wouldn't it make sense that the actual bps rate would be a /10 function rather than a /8, since we have the start/stop bits?

 

I think an absolute best situation would see Pokey doing I/O at Master Clock Speed/2 bits per second (then divide by 10 again for bytes/second).

It needs to detect the clock transition. To do that, you need a low on one cycle, high on the other cycle. Even then, any skew between clocks will likely result in dropped bits.

So, something like 88,920 bytes per second on PAL in an "ideal world" situation.

 

If the external device was integrated into the Atari such that it used the system clock for timing, maybe that ideal best could be achieved.

 

But, in the real world with it hanging off the SIO port and running at an independant rate I think the best case speed will turn out significantly lower.

 

I don't know if it's documented or not - what about delays within Pokey for such things as resync, shifting bits within it's SERIN, and other tasks?

 

Still, why would we want 88 K/Second? I guess it would be fantastic for something like full-motion video+audio.

[candle]

Hias! now You're my mon, and here is my response: http://spiflash.org/files/IO-Board.pdf, http://spiflash.org/files/IO-Board.pcb.pdf

most of stock atari 130xe and those based on ca200519-001 borad don't have those caps on pcb, just nicely organized places that would happly accept goldpin connector

as i wrote before - i've already tested transmission with external clock, ft232r is best thing i could find since it has capability of external data strobes for write and read operations

i've also connected proceed and interrupt lines to get additional control if high-speed transfer will require

 

atariksi: if you don't have the time to read technical documentation, perhaps you shouldn't form an opinion about hardware it concerns?

[ijor]

The formula for the frequency calculation is not what's documented.

 

What formula are you talking about?

 

For channels clocked at ~1.79 MHZ, as used for SIO, I measured the formula more than once and I found it exactly as documented.

 

The formula is not exact however, when using the lower clocks (~15 KHz or ~64 KHz).

[ijor]

I think an absolute best situation would see Pokey doing I/O at Master Clock Speed/2 bits per second (then divide by 10 again for bytes/second). It needs to detect the clock transition. To do that, you need a low on one cycle, high on the other cycle.

...

I don't know if it's documented or not - what about delays within Pokey for such things as resync, shifting bits within it's SERIN, and other tasks?

 

Candle will probably say we aren't helping, but ...

 

I don't think Pokey can shift in just two cycles. I never tried, but if I'm not mistaken, Pokey requires a minimum of 3 cycles per bit. And that's just for shifting, didn't check other sections of the logic.

 

The Pokey datasheet doesn't explicitly contain an upper data rate for the external clocked mode. The only relevant values concerning this case are the 150ns needed for data setup. So, maybe you could go up to ~2Mbit/sec if the pokey uses asynchronous circuits for serial I/O. If there's some logic clocked by the system clock you might be limited to fractions of the system clock (at least at very high bitrates). I don't know how it works and can't tell you, so it's up to you to check it out.

 

It is not async. The external serial clock is synchronized with PHI2.

[Fröhn]

To be precise: the clock base is not 1.79MHz, but either 1.773447 MHz (PAL) or 1.7897725 MHz (NTSC).

Small precision improvement:

 

PAL = 1.7734475 MHz

NTSC = 4095/2288 MHz = 1.78977272727... MHz

[candle]

ijor: can You show me part of schematics, where external clock is synchronized with phi2? i didn't find such mechanism, but my knowledge is verry limited here, and beside this - exact speed one can gain using this method is not really an issue here

the goal is to transmission over curreent limit and everything above max speed ape, or any other pheripherial emulator is capable of will be some kind of success

when i live long enought to see 65c816 running at least 7mhz and having over 1mb of linear memory plus vbxe plus another suprise i'm working at it will be real pain to have sio transfers at 10kB/s max

in ideal world i would like to see atari running 14mhz or more (wdc is preparing 20mhz version from some time now) having vbxe or similiar solution and build in hard drive of some kind

even then one needs some way of communication between pc and atari

i've given 88kB/s as an example here, please don't focus on the speed here, if it will be 20kB/s we would only gain 100% of what current max transfer rate was

another thing is, when using ft232r older software, using standard approach for sio communication will also benefit - if it recognise "turbo" running 68k it will go 68k, if it will be 56k - no problem

serlial speed limited to standard rs232 ratios will not be an issue, as ft232r chip will synchronize to clocks lines from atari

as you can see - clock (upper waveform. Clock In, or rather Bi-Directional Clock line, pin #1 of sio connector) is present even on standard sio modes - this is frame sent by stock OS trying to boot from disk drive, lower waveform is Data Out line (taken using 1:10 probe, so it has reduced amplitude). What is the most important thing, both signals are sourced by Atari

Edited February 9, 2009 by candle

[ijor]

Small precision improvement:

PAL = 1.7734475 MHz

NTSC = 4095/2288 MHz = 1.78977272727... MHz

 

It doesn't make much sense attempting to be so precise. These are "simple" crystals and oscillators. The frequency on real life it is far from being the nominal one.

 

Besides, even the nominal value is different depending on the exact model.

[atariksi]

Hias! now You're my mon, and here is my response: http://spiflash.org/files/IO-Board.pdf, http://spiflash.org/files/IO-Board.pcb.pdf

most of stock atari 130xe and those based on ca200519-001 borad don't have those caps on pcb, just nicely organized places that would happly accept goldpin connector

as i wrote before - i've already tested transmission with external clock, ft232r is best thing i could find since it has capability of external data strobes for write and read operations

i've also connected proceed and interrupt lines to get additional control if high-speed transfer will require

 

atariksi: if you don't have the time to read technical documentation, perhaps you shouldn't form an opinion about hardware it concerns?

 

I do know the atari's technical side so in a communication event, I can deduce certain facts without having read FT232R stuff. In an IRQ, you need a RTI (6 cycles), vector jump (65534) (7 cycles), read from serial IN (4 cycles), writing to memory is another 4+ cycles, etc. so I can deduce you can't to 87KBytes/second. Polling, you can analyze the same way. I think you forget to take into account the overhead cycles in processing a byte when you claim 1mbit/second.

[ijor]

ijor: can You show me part of schematics, where external clock is synchronized with phi2?

 

It is synchronized inside Pokey, not at the board level.

 

as you can see - clock (upper waveform. Clock In, or rather Bi-Directional Clock line, pin #1 of sio connector) is present even on standard sio modes

 

Of course, that is the documented behaviour.

 

another thing is, when using ft232r older software, using standard approach for sio communication will also benefit - if it recognise "turbo" running 68k it will go 68k, if it will be 56k - no problem

 

Watching the clock signal for "autobaud" detection is certainly a very good thing. I think it was already done before, and I believe some current devices use this method already.

 

i didn't find such mechanism, but my knowledge is verry limited here, and beside this - exact speed one can gain using this method is not really an issue here the goal is to transmission over curreent limit and everything above max speed ape, or any other pheripherial emulator is capable of will be some kind of success

 

You didn't tell us before what you was really trying to do. For a sort of "generic" turbo SIO loader, then you should probably listen to some of the advices posted here.

 

HIAS is right, the caps on the SIO connector are going to be a problem. I can't say exactly how many boards have those caps and how many have not. But they are quite common.

 

And the software side on the Atari is an issue as well. If it were for say, something like streaming video, then you could afford to not use checksums, or even use Atariski idea (not even polling, just reading from Pokey at synchronized frequency). The problem is not the time for the transmission of the checksum, but the extra instruction(s) required for compute it at the Atari.

 

when i live long enought to see 65c816 running at least 7mhz ...

in ideal world i would like to see atari running 14mhz or more (wdc is preparing 20mhz version from some time now)

 

Well, as long as you are targetting "non-stock" machines, then you might afford some things that otherwise you couldn't. Say, if somebody is going to mod his computer with an accelerator, then you certainly can expect he could remove the caps in the SIO connector, in case they are present. Also a faster CPU might let you compute checksum almost for free.

 

I suppose you are aware that there is a parallel connector (PBI), I'm mentioning it just in case.

Edited February 9, 2009 by ijor

[atariksi]

If N81 is okay with you, then best approach is to just do: LDA 53773, STA mem; LDA 53773, STA mem+1, etc. and fill this throught a frame taking into account the refresh cycles (9 per 114 CPU cycles). Fill in some NOPs to slow down a bit and make up for refresh cycles where there are none (to keep things perfectly equal as PC won't be able to deal with asymmetric timed I/O). You can in theory get >100KBytes/second. I used the joystick port as I had audio playing in the background while downloading. The irq method and polling methods are inferior to this cycle-exact method.

NAK. This method will fail in case the clocks aren't synchronized properly. In real world you'll always have to deal with drifting clocks.

 

A method to solve is this problem is of course to introduce some synchronization points (like the pokey does, it synchronizes it's clock at the start bit). For example: define a maximum clock deviation, use a block mode, and set the block size so that the last item of the block will still be received within the set time limits (=target time plus/minus maximum allowed deviation). Then synchronize and go for the next block.

 

so long,

 

Hias

 

That's why I stated for one frame-- you resync at beginning of frame and then do a transfer of a block at exact intervals within that frame. You need to wait at least 10 CPU cycles before reading next data byte (to account for N81). So you take into account refresh cycles or use NOPs where there are none. It works for 54016 so it should work for 53773. However, you need to make sure the PC can clock bits to Atari at Atari cycle times otherwise you do some clock drift to take into account. At least we know Ataris amongst themselves can do this clocking consistently without any drift.

[Rybags]

I wonder... how about doing what some turboloaders on the C-64 do.

 

We have the Proceed and Interrupt lines, which are barely used but should be valid as inputs also. They seem to work in a latch type mode, and the status is reset by reading PORTA or PORTB of PIA (dummy read in Atari's case).

 

It wouldn't be the same straight-forward process, but they could be used at a reduced bitrate in parallel with normal SERIN.

 

e.g. Proceed and Int receive data at 1 bit transition occurring for each full byte received by SERIN.

Have the bit transitions occur somewhere around halfway, that gives the Atari program time to poll SERIN then fetch/store.

By such time, the next byte is probably 1/4 way through SERIN again. We have time (maybe) to grab the Int/Proceed inputs.

 

The order of things might be a bit odd so far as the overall picture goes. Maybe something like 3 bytes originating from SERIN, the fourth from Int/Proceed, then repeat n times per block of data.

[atariksi]

I wonder... how about doing what some turboloaders on the C-64 do.

 

We have the Proceed and Interrupt lines, which are barely used but should be valid as inputs also. They seem to work in a latch type mode, and the status is reset by reading PORTA or PORTB of PIA (dummy read in Atari's case).

 

It wouldn't be the same straight-forward process, but they could be used at a reduced bitrate in parallel with normal SERIN.

 

e.g. Proceed and Int receive data at 1 bit transition occurring for each full byte received by SERIN.

Have the bit transitions occur somewhere around halfway, that gives the Atari program time to poll SERIN then fetch/store.

By such time, the next byte is probably 1/4 way through SERIN again. We have time (maybe) to grab the Int/Proceed inputs.

 

The order of things might be a bit odd so far as the overall picture goes. Maybe something like 3 bytes originating from SERIN, the fourth from Int/Proceed, then repeat n times per block of data.

 

Well, just reading/writing a DATA byte from PORTA can already use up full bandwidth of Atari. But interrupt lines can be used for synchronization purposes so that PC triggers off beginning of cycle exact code so it can internally keep it's own clock in sync. But perhaps are talking about non-cycle exact code.

 

I haven't read anything about POKEY requiring more than one cycle to pass data through shift register. It should handle the full throttle 1.79Mhz through its shift register. It should be able to save the bit and shift the contents. The delays would be caused by processing the bytes that come in.

[carmel_andrews]

Interesting Idea Rybags, thing is, i guess the reason why turboloaders (i'm assuming tape versions)on the c64 were popular is because the hardware (the C2N) was built to exacting standards therefore you didn't have different degrees of max level tolerances (i.e the load levels for reading/recording and writing data) like you do have with the atari tape drives (410/1010/xc11/12)...hence i guess why turbo loaders were not such an option (unless you were in some parts of eastern europe) on the A8

 

The only game i recall that used high speed loading (tape) without the need for addit. tape hardware modding was synapse's dimension x

 

I guess you could point to turbo 2000 (which i think originated in czechoslovakia...or was it hungary) and it's british equivalent high speed turbo (micro discount) which is a renamed version of Rambit's hardware mod for atari tape drives, or the various software equivalents which if i recall only gave you between 50 to 100 percent seped increase ....even these were'nt universally popular

Edited February 9, 2009 by carmel_andrews

[Fröhn]

Small precision improvement:

PAL = 1.7734475 MHz

NTSC = 4095/2288 MHz = 1.78977272727... MHz

 

It doesn't make much sense attempting to be so precise. These are "simple" crystals and oscillators. The frequency on real life it is far from being the nominal one.

 

Besides, even the nominal value is different depending on the exact model.

Those crystals are for color carrier generating and because of that are far more accurate than the average crystal you will find in computers. Usually you will find a 4x color carrier frequency crystal (4x for easy 90° phase shifting of the wave).

[atariksi]

i have never seen so much ignorance in my entire life!

I'd really like to apologize for not reading the current ft232 docs before posting. I did in no way want to offend or discourage you, honestly.

 

Last time I read the ft232 docs was some 2 or 3 years ago, now I downloaded and read them again (plus also the appnotes concerning bit-banging).

 

Here are some comments:

 

With the FT232R you should be able to transmit up to 1Mbit/sec, but only if you connect the #WR line to the Atari clock in. Bit-banging the Atari BCLK line won't work (you'd be limited to 500k then).

 

Back to Atari stuff:

 

The Pokey datasheet doesn't explicitly contain an upper data rate for the external clocked mode. The only relevant values concerning this case are the 150ns needed for data setup. So, maybe you could go up to ~2Mbit/sec if the pokey uses asynchronous circuits for serial I/O. If there's some logic clocked by the system clock you might be limited to fractions of the system clock (at least at very high bitrates). I don't know how it works and can't tell you, so it's up to you to check it out.

 

But: The Pokey is not a standalone chip, it's integrated into the Atari. As I wrote in my first posting, there are capacitors from the SIO lines to ground. Take out a calculator an check what a 1nF capacitor will do to a 1MHz signal :-)

 

So, before doing any further experiments I highly recommend you remove these capacitors or bend up the Pokey pin(s) and connect short (<20 cm / 8") wires directly to your interface.

 

BTW: A lot of people already had problems using highspeed drives (highspeed meaning some 50-70kbit/sec) due to these capacitors in the disk drives and the Atari computers. Also, most docs of the (1050) highspeed upgrades mentioned this and told you to remove the caps in the drive.

 

so long,

 

Hias

 

The FT232R that I read about does 6Mhz, 12Mhz, 24Mhz, and 48Mhz internal clock so you won't get evenly divisible values for the Atari's 1.79Mhz rate so there's some error build-up which needs to be taken into account or use a different timing source for bit-banging to Atari (standard PC timer won't work either).

 

There's an Atari clock In and Clock Out and they also call the clock In the bi-directional clock so I don't see why you are distinguishing between clock In and BCLK.

[ijor]

I haven't read anything about POKEY requiring more than one cycle to pass data through shift register. It should handle the full throttle 1.79Mhz through its shift register. It should be able to save the bit and shift the contents. The delays would be caused by processing the bytes that come in.

 

May be you haven't read it can't shift in a single cycle, but I'm sure you never read it can, did you?

 

For sure the whole serial (both in and out) logic can't work at "full throttle". For starters because there are synchronous edge detectors in the clock generation. This means that the serial clock (either internal or external) must be, at the very least, one cycle high and one cycle low. Otherwise, if it is as fast as the main clock, then no edge would be seen, and no pulses would be generated. So a "full throttle" clock would be the same as no clock at all.

 

In second place, the Pokey shift registers can't shift not even in two cycles, let alone in a single cycle. Of course that it is possible to make a "single cycle" shift register, but it would require more transistors.

 

Those crystals are for color carrier generating and because of that are far more accurate than the average crystal you will find in computers. Usually you will find a 4x color carrier frequency crystal (4x for easy 90° phase shifting of the wave).

 

Nice theory. Now go and hook a scope to any Atari computer and see how accurate they are. Even if they were accurate when they came from factory, crystals have a considerable aging effect.

 

Besides, and once again, the nominal freq. value is not exactly the same on all models. So even if they would be the most accurate crystals in the world, you still can't talk about that precision across all models. And I'm not talking about NTSC vs PAL.

Edited February 9, 2009 by ijor