SIO protocol

[supercat]

Rigurours synchronous design means such things as no ripple techniques, no divided or gated clocks, no async latches or delays, etc. These are issues all valid disregarding fully static or dynamic cells.

 

It's true that different parts of the TIA use different clocks, but I would regard the TIA more as a collection of synchronously-clocked subsystems than a bunch of asynchronous ripple logic. Synchronizers are generally used when subsystems driven by slow clocks feed signals to those driven by faster ones; there are a few interesting race conditions:

 

-1- sprite motion pulses are derived from sysclk/4, and are or'ed with a gated version of sysclk. In normal use, the motion circuitry will never have the /4 and /1 clocks enabled simultaneously; if they are both enabled, the timing of every fourth motion pulse will be skewed enough to cause distortion in the displayed sprite.

 

-2- at pixel 79, the playfield color mode will get switched a little early, with the interesting effect that despite the output synchronizer, pixel 79 will often end up showing the right color on one half and the wrong color on the other.

 

In general, though, the TIA is pretty straightforward. I've never looked at ANTIC, GTIA, etc.

[Fröhn]

I wasn't using a scope at all. I measured the differences between different models via phase shift over time measurement C64 vs 1541. It showed that if you swapped 1541s, you get some noticable difference but if you swapped the C64s the phase shift would not change.

...

3/10000 on the 16.000 MHz clock of the 1541. I was not able to measure any difference between different 17.734475 MHz crystals of the C64.

 

So what are you saying?

 

Are you saying that those crystals are so perfect (even after a couple of decades), that two C64's could be permanently "in sync" ?

 

Or, for that matter, are you saying that the precision of those crystals is better than 1 ppm, even after all those years?

No I am saying that those color carrier frequency based crystals are far more accurate than all those n.000 MHz crystals normally used in computers and that the exact definition of those frequencies is known so why not use them?

 

For PAL the definition is: 283.75 color clocks per line * line frequency (15625 Hz) + 25 Hz. That multiplied by 4 for easy 90° phase shift access (the V signal is just 90° phase shifted compared to U).

Edited February 10, 2009 by Fröhn

[atariksi]

In regards to POKEY, don't agree with that-- full throttle clock is same as no clock at all...

 

I'll try to post a picture later and you would understand what I meant.

 

All circuits are assumed to work according to spec unless you can prove otherwise so according to spec. POKEY should be able to deal with a bit coming in at 1.79Mhz and shift it as it shifts at other rates. Even if it's a cycle or two behind in shifting and receiving, at least it can deal with all the bits coming in.

 

Nowhere in the specs it is mentioned the max rate of the serial clock. And I think you are completely misunderstanding the issue. The issue is not the absolute frequency, the issue is the relation between Pokey main clock and the serial one. If you would overclock Pokey, and assuming it would work reliably, then you could increase the serial clock as well.

 

...

You are misunderstanding. POKEY is processing signals at 1.79Mhz accuracy-- just look pot scan counters.

The restriction in the spec via that formula of 2*(Audf+7) does not involve manually clocking and POKEY also allows for IRQs to 1 cycle accuracy using 1.79Mhz dividend.

 

>>All the WSYNC-based software or cycle-exact software relies on timing being consistent throughout all models and all of my old Ataris still have the same timing in tact. And this cycle-exact programming is documented.

 

>We are talking about oranges and you are replying about apples. We are talking about the accuracy of the crystal/oscillator in relation to its nominal value. This has no relation whatsoever with cycle-accurate software. You could use a crsytal that is out by 10% of the nominal frequency, and/or with a lot of jitter, and cycle accurate software would still work.

 

You need to stop reading those old emulation websites. The frequency is related to time (in the real world) t = 1/f. So 1.78979Mhz means a cycle time of 558 nanoseconds for NTSC Atari. 10% off means your time will be wrong by 10%. Yeah, I know there's some ppm rating, but Atari is dealing with it and giving a consistent results across all models. I know they use these PLL (phase-lock-loops) to get exactness of frequencies on newer Sound Blaster cards. The cycle exact results you see or time is as good an observation as your scope. Perhaps, your scope has a 10% error.

[+poobah]

phoobah: please... don't... just don't

well, technically, the serin line is being sampled...

[atariksi]

xl series without freddie chip have clocks multiplied by 4, xe and all that have freddie - by 8, and this is important, but not for this case

 

Rybags: proceed and interrupt are input signals, and pia is able to raise interrupt - good for slow devices, but not for fast transfers, but we can use motor_on and command

reason was to signal pc that atari software didn't recived byte and pc have to wait before sending next byte

from atari sfotware point of view reciving sector could look like that:

 

1 read data from serin

2 toggle motor on (make it 1, then 0 again, no wait, just pulse)

3 store to memory location

4 increase pointer

5 decrese byte count (loop)

6 if byte count is not 0 then jump to 1

 

practical implementation:

	ldy	#255
loop
cycles
0	lda	SERIN
4	ldx	#%00111000
6	stx	PACTL
8	ldx	#%00110000
12	stx	PACTL
16	sta	(Buffer),y
22	dey
24	bne	loop
27 cycles per revolution 64kbytes/s fully synchronized with pc

you may say byte order is reversed, but this is only true if pc side won't send it reversed too

it might be also not exact cycle count, since i really don't know 6502 verry well

 

This is better than polling and close to cycle exact method; I factored out the ack out of the block transfer and then loop unrolled the code. You need to multiply 1.78979Mhz/27 * (114-9)/114 to get the throughput for screen off (61055 bytes/second) and start with Y=0:

 

LDY #0

Loop: LDA SERIN

LDX #ACKH

STX PACTL

LDX #ACKL

STX PACTL

STA (BUFFER),Y

INY

BNE Loop

 

If you can detect level change rather than pulse and don't want to unroll loop, then you can speed up as follows:

 

LDY #0

LDX #ACKH

Loop: LDA SERIN

STX PACTL

LDX #ACKL

STA (BUFFER),Y

INY

LDA SERIN

STX PACTL

LDX #ACKH

STA (BUFFER),Y

INY

BNE Loop

 

This would be 39 cycles for two BYTES giving 84538 bytes/second.

[Rybags]

So, what you're doing there is relying on the external device to detect the transition on "Motor Control" and send the byte, and not bother checking if it's been shifted in?

 

I don't see any problem there... if you're dealing with 256 byte blocks (or whatever size), you can just use a Checksum or CRC to validate proper receipt anyway.

 

You could speed it up... self-modifying code for the store to buffer.

[atariksi]

So, what you're doing there is relying on the external device to detect the transition on "Motor Control" and send the byte, and not bother checking if it's been shifted in?

 

I don't see any problem there... if you're dealing with 256 byte blocks (or whatever size), you can just use a Checksum or CRC to validate proper receipt anyway.

 

You could speed it up... self-modifying code for the store to buffer.

 

It's a one-way ack setup that works great if one device much faster than the other. As long as you have some instructions between reads from SERIN, you can bet the PC will have sent the byte. In this case, you have at least 14 CPU cycles between SERIN reads. I didn't even bother doing checksums when I did it with MPDOS parallel transfers. I guess for serial case, you may need some checksums if there's some chance other device won't be able to transmit or line is noisy.

 

Self-modifying code would help if loop unrolling is not used.

[ijor]

No I am saying that those color carrier frequency based crystals are far more accurate than all those n.000 MHz crystals normally used in computers and that the exact definition of those frequencies is known so why not use them?

 

Because we aren't talking about the nominal NTSC/PAL color carrier frequencies. We aren't talking about the nominal color carrier crystal frequencies. Or for that matter, we aren't talking about the nominal frequencies on C64 computers.

 

We are talking about the frequencies on Atari 8-bit computers. We have three different ways to define them. Measure them with as much precision as possible. Use the nominal frequency written in the physical part. Use the nominal value described in Atari documentation.

 

In either of these three ways, you'll see differences in the order of 1/10,000. At this order of magnitude, using 5 digits is good enough, may be 6 if you want.

 

Your theory that they are exactly (or an exact multiple or divisor) the NTSC/PAL color carrier frequency, and that the crystals are extremely accurate, even after all these years, is ... well, just a theory. And this theory, at least on Atari computers, doesn't match reality.

Edited February 10, 2009 by ijor

[ijor]

You are misunderstanding. POKEY is processing signals at 1.79Mhz accuracy-- just look pot scan counters.

The restriction in the spec via that formula of 2*(Audf+7) does not involve manually clocking and POKEY also allows for IRQs to 1 cycle accuracy using 1.79Mhz dividend.

...

You need to stop reading those old emulation websites...

 

atariksi, what you are saying doesn't make any sense to me whatsoever.

 

I don't know if you are being unreasonable, or once again we are misunderstanding each other. I'll give you the benefit of the doubt and I'll assume it is all my fault about the misunderstanding.

 

Anyway, I posted above a picture of the serial clock logic on Pokey. If you would try too analyze it, you would see that a "full throttle" serial clock has no chance to work. Or alternatively, do the test you said you were going to do, sending serial data to Pokey at ~1.79 MHz, and tell us your results. I won't argue more with you about this, because this seems (to me, at least) more a "verbal debate between deafs" (or whatever is the corresponding phrase in English) than anything else.

Edited February 10, 2009 by ijor

[ijor]

It's true that different parts of the TIA use different clocks...

 

Ok, now it is more like I what heart before. And according to what you are saying, TIA seems to be even "worse" (in this sense) than the A8, which is expected due to being a few years earlier.

 

, but I would regard the TIA more as a collection of synchronously-clocked subsystems than a bunch of asynchronous ripple logic....In general, though, the TIA is pretty straightforward. I've never looked at ANTIC, GTIA, etc.

 

I didn't mean TIA, or the A8 are a "bunch of ripple logic". What I meant is that "modern synchronous rules" are broken, more than once, but obviously not in every single piece of logic. And I mentioned this, because for somebody more familiar with modern designs than vintage ones, it is helpful for understanding the schematics.

 

It is also closely related to some issues we were talking about here in this forum. The main "PHI2" clock is divided, gated and buffered in the A8. This is a big "no-no" by modern rules. In most practical cases it doesn't matter, but it matters a lot for some peripherals connected to the PBI (external parallel bus interface). Ken (and others) knows exactly what I'm talking about.

Edited February 10, 2009 by ijor

[Fröhn]

Because we aren't talking about the nominal NTSC/PAL color carrier frequencies. We aren't talking about the nominal color carrier crystal frequencies. Or for that matter, we aren't talking about the nominal frequencies on C64 computers.

 

We are talking about the frequencies on Atari 8-bit computers. We have three different ways to define them. Measure them with as much precision as possible. Use the nominal frequency written in the physical part. Use the nominal value described in Atari documentation.

Wrong. No matter if C64, A8 or several other 8 bit computers which directly generate YUV/YIQ, all clocks in the computer are derived from 4x color carrier clock.

 

PAL:

 

17.734475 / 10 = 1.77 MHz of A8

17.734475 / 18 = 0.985 MHz of C64

 

NTSC:

 

14.31818 / 8 = 1.79 MHz of A8

14.31818 / 14 = 1.023 MHz of C64

 

Your theory that they are exactly (or an exact multiple or divisor) the NTSC/PAL color carrier frequency, and that the crystals are extremely accurate, even after all these years, is ... well, just a theory. And this theory, at least on Atari computers, doesn't match reality.

I never said they were 100% exact, I only said they are siginificantly more exact than normal crystals since they were built for color carrier generating and not computer clocking.

[ijor]

Wrong. No matter if C64, A8 or several other 8 bit computers which directly generate YUV/YIQ, all clocks in the computer are derived from 4x color carrier clock.

 

Fröhn, you seems to be listening only to yourself. I don't want to beat this to dead, certainly not when it is off-topic in this thread.

 

If you are happy believing that all A8 computers have the same exact nominal crystal, please be my guest. If you believe that Atari schematics and Field Service Manuals are wrong with their crystal frequencies, please be my guest. If you believe that the physical crystal in those cases have the wrong nominal value labelled, and that Best Electronic lists them with the wrong frequency, please be my guest. If you believe that when I measure those crystals and I found that the difference between say, a 1200XL and a 130XE, tends to match the labelled difference in the nominal values, then I'm actually allucinating, please be my guest.

Edited February 10, 2009 by ijor

[atariksi]

You are misunderstanding. POKEY is processing signals at 1.79Mhz accuracy-- just look pot scan counters.

The restriction in the spec via that formula of 2*(Audf+7) does not involve manually clocking and POKEY also allows for IRQs to 1 cycle accuracy using 1.79Mhz dividend.

...

You need to stop reading those old emulation websites...

 

atariksi, what you are saying doesn't make any sense to me whatsoever.

 

I don't know if you are being unreasonable, or once again we are misunderstanding each other. I'll give you the benefit of the doubt and I'll assume it is all my fault about the misunderstanding.

 

Anyway, I posted above a picture of the serial clock logic on Pokey. If you would try too analyze it, you would see that a "full throttle" serial clock has no chance to work. Or alternatively, do the test you said you were going to do, sending serial data to Pokey at ~1.79 MHz, and tell us your results. I won't argue more with you about this, because this seems (to me, at least) more a "verbal debate between deafs" (or whatever is the corresponding phrase in English) than anything else.

 

I did look at that schematic and it doesn't state how many cycles each of those gates takes. I did not want to assume they take 558ns each. I do not see how bi-dir clock relates to the normal serial rate formula. That response was in relation to you claiming I would be over-clocking it.

[atariksi]

Because we aren't talking about the nominal NTSC/PAL color carrier frequencies. We aren't talking about the nominal color carrier crystal frequencies. Or for that matter, we aren't talking about the nominal frequencies on C64 computers.

 

We are talking about the frequencies on Atari 8-bit computers. We have three different ways to define them. Measure them with as much precision as possible. Use the nominal frequency written in the physical part. Use the nominal value described in Atari documentation.

Wrong. No matter if C64, A8 or several other 8 bit computers which directly generate YUV/YIQ, all clocks in the computer are derived from 4x color carrier clock.

 

PAL:

 

17.734475 / 10 = 1.77 MHz of A8

17.734475 / 18 = 0.985 MHz of C64

 

NTSC:

 

14.31818 / 8 = 1.79 MHz of A8

14.31818 / 14 = 1.023 MHz of C64

 

Your theory that they are exactly (or an exact multiple or divisor) the NTSC/PAL color carrier frequency, and that the crystals are extremely accurate, even after all these years, is ... well, just a theory. And this theory, at least on Atari computers, doesn't match reality.

I never said they were 100% exact, I only said they are siginificantly more exact than normal crystals since they were built for color carrier generating and not computer clocking.

 

Of course, they could end up being exactly the same especially if manufactured under same conditions and for the same purpose. They probably still put a ppm rating on them to be safe.

[ijor]

I did look at that schematic and it doesn't state how many cycles each of those gates takes. I did not want to assume they take 558ns each. I do not see how bi-dir clock relates to the normal serial rate formula. That response was in relation to you claiming I would be over-clocking it.

 

You are again misunderstanding my point. And once again it might be my own fault.

 

I think it is quite clear exactly which is the delay on any clocked gate, but I won't argue with you anymore. May be it is your fault, may be it is mine, may be both, but it is completely pointless to keep arguing, at least about this.

 

My only suggestion is that you should perhaps go ahead, and perform that test you said you were going to do. Try to send serial data to Pokey at ~1.79 MHz, and tell us how it worked out.

[Bryan]

ijor, you are very diplomatic.

[atariksi]

ijor, you are very diplomatic.

 

More like chewbacca defense.

[atariksi]

atariski: the limitation per cycle is easily explained. Imagine the High/low transitions of computer clock and serial input clock:

 

Computer HLHLHL etc.

Input: HLHLHL etc.

 

Of course in the real world they probably won't be aligned. But Pokey does it's work/samples the input clock only at a specific part of the cycle. So, like ijor said, it will only be seeing that one part of the input clock's cycle. To work, it will need to run at half of Pokey's clock rate (assuming if Pokey can in fact receive at that rate).

 

candle: with the Int/Proceed thing, I meant for the program to actually read the PACTL/PBCTL registers, not actually have any IRQs being serviced via those input lines.

 

What's with the Motor Control thing? Will you be just using that to signal your to your device that a byte has been received?

 

Regarding reading PACTL/PBCTL for Interrupt/Proceed lines, it will latch the IRQ that occurs so it can't be used as a general purpose read/write bit (bit 7). You will have to clear the interrupt request using PORTA/PORTB.

 

Regarding shifting in data, are you stating one cycle delay because another person is stating 3 cycle delay.

Or maybe I didn't understand you. Or maybe it's my fault. Or maybe it's your fault. Or maybe it's quite clear to you.

[Rybags]

I was saying "one cycle delay" as a best-case scenario.

 

It's already documented that some features of Pokey take several cycles, where they might be expected to only take one. It would be fair to assume that Pokey's designers had no inclination or necessity to optimise Serial I/O to have as little overhead as possible, since at the time it would have been assumed to never need > 19.2 kbps net throughput.

 

In the end game, it's all academic anyway. For starters, the routine you posted is fairly close to the best-case scenario so far as what the 6502 can process, and equates to almost 2 cycles per bit.

Secondly, I have doubts that any externally connected SIO device would be able to operate at the nearly megabit/second speeds of that "best-case" situation anyway.

 

Maybe if a direct to Pokey connection is jury-rigged and twisted pair with ground-return for every line might see serial comms being able to operate at whatever it's theoretical limit happens to be.

[candle]

ijor: the funniest thing is that only i and apperently atariksi is doing any transfers using external clock, and all you do is telling us it is impossible to do it as quickly as we currently do

well.. maybe i'm misunderstanding your point entairly, but i think there is some similarity to chewbacca (southpark?) defefnse line in your argumentation...

give it a try, and don't stay academic only

 

rybags: stray capacitance effects are to be overcomed by higher current output buffers, and are unnesesary here. atari don't have diffrential input and output lines, so all you would do adding twisted pairs is introducing another capacitance to the circuit

 

atariksi: would you have any complete program for me to test it?

[Bryan]

To test a serial transfer at 1.78MHz, you'll get 10 cycles per byte (plus possible refresh losses). That's gonna be tough. Just reading the byte is going to be 4. You could read it and store it to the joystick ports in a continual loop. Then you'd need some external apparatus to see if it always matches.

 

Are we talking about using a Pokey baud rate or an external one? Pokey can't count that fast internally. That's why Atari's official frequency divider formula has that +4 in it (Fout=Fin/(2(AUDF+4))). So, if I'm reading all this right, your fastest baud rate is: 225Kbps.

[Rybags]

I believe the +4 is just for counter reset. In 1.79 MHz mode, the timers do count down on a per-cycle basis.

 

In fast Pot Scan mode, Pokey does an increment/compare per cycle.

 

Serial Port - TBA. I haven't seen any posts here yet saying "Eureka - I got it to do 250 kbps!!!"

[ijor]

ijor: the funniest thing is that only i and apperently atariksi is doing any transfers using external clock, and all you do is telling us it is impossible to do it as quickly as we currently do

 

I don't think you tell us you are successfully transferring at 1.79 MHz or even close, do you? And I didn't read that neither atariksi was.

 

So what you mean by as 'quickly as we currently do'?

 

but i think there is some similarity to chewbacca (southpark?) defefnse line in your argumentation...

 

Sorry, no idea what chewbacca argument, or southpark is.

[Bryan]

I believe the +4 is just for counter reset. In 1.79 MHz mode, the timers do count down on a per-cycle basis.

 

In fast Pot Scan mode, Pokey does an increment/compare per cycle.

 

Serial Port - TBA. I haven't seen any posts here yet saying "Eureka - I got it to do 250 kbps!!!"

Yeah, but isn't AUDF3 your bit rate counter? I think it still holds.

 

This table shows it being half of what I came up with:

 

http://andersonaudioworks.com/Atari/divisors.html

 

This shows a 0 divisor at work:

 

http://video.google.com/videoplay?docid=6878550156146863655

[ijor]

Regarding shifting in data, are you stating one cycle delay because another person is stating 3 cycle delay.

Or maybe I didn't understand you. Or maybe it's my fault. Or maybe it's your fault. Or maybe it's quite clear to you.

 

Go ahead and make fun of me if you like. I was both honest and polite in my reply.

 

I didn't mean at all what you seem to understood in the other message, and honestly I don't know why this constant misunderstanding between us.

 

I didn't say that there is any direction relation between the bidir clock and the internal formula. And I didn't claim you are overclocking Pokey.