SIO protocol

[Bryan]

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

 

Here you go:

 

http://www.metacafe.com/watch/1974564/chewbacca_defense/

 

[ijor]

This shows a 0 divisor at work:

 

Yes, zero divisor is known to work. But this is still far from what we are talking about here using Pokey synchronous mode.

[Bryan]

Yeah, sorry about that.

 

Edited February 12, 2009 by Bryan

[Rybags]

Bryan: I just consulted the hardware manual. The (+4) only applies to 1.79 mode using 8-bit counters.

 

Normal SIO uses 16 bit counters, so the formula should use (+7) in it's calculations.

 

Of course, with a custom SIO routine, you could just use 8-bit counter mode. And if we're talking external clocking, none of this should matter anyway.

[Bryan]

Bryan: I just consulted the hardware manual. The (+4) only applies to 1.79 mode using 8-bit counters.

 

Normal SIO uses 16 bit counters, so the formula should use (+7) in it's calculations.

 

Of course, with a custom SIO routine, you could just use 8-bit counter mode. And if we're talking external clocking, none of this should matter anyway.

 

Yeah, I got confused on the synchronous mode thing.

 

I noticed that the Pokey counters have clocked carry (actually, "borrow") positions that delay the counter by 3 cycles, plus the 1 reset clock. So 16 bit mode has 6 carry delays and a reset clock. I'm sure this was done because the propagation delays limited the number of cells the subtraction could ripple though.

[Rybags]

Dunno. We need Analog Multiplexer in here... he probably knows all this stuff backwards.

[Bryan]

Dunno. We need Analog Multiplexer in here... he probably knows all this stuff backwards.

I do agree with you, though. It is 4 or 7. I actually built up a Pokey counter in a logic simulator once and watched what it did.

[candle]

now i have to use chewbacca defense - it does not make any sense to take formulas about internal timer clock ratios to external clock

ijor: i may not make transfefrs at 1mbit on whole packet, but i do at byte level, so there is no problem clocking pokey to at least 1mhz, but above that it start loosing bits, and you have to transmit 10 bits of zeros to reset input buffers and corelated logic, otherwise you'll end up having your data shifted by a bit

you have your strong belives based on your knowledge about nmos asic design, i respect that, but consider this:

possiblities this mode implies is worth exploring whatever the outcome will be, so please, instead being sceptistic to all of this grab your atari, piece of wire and make interface, even using db25 connector, 4 wires and sio jack and try

 

i won't do everything myself, got other projects to finnish for atari, and we all gain something on this

 

Rybags, Bryan: its 4, when clocked from 64/15khz clock source, and 7 when clocked by phi2

Edited February 12, 2009 by candle

[Rybags]

Can you try running it slower? Maybe run it using 2 or more stop bits.

 

Are you checking SKSTAT flags? Overrun? Framing errors?

[candle]

i did that already, there is no problem for pokey to receive the data, there is a problem for 6502 to read the data on time, before overrun occours (at certain speed)

sync mechanism i've proposed some posts ago should be sufficient, but i won't spent any more time on doing lpt tests, need to move to usb adaptor, as this is my targed device

for this i need to get some time, and as usually - have to share my time among various activities

 

should get this done till monday though

[atariksi]

Nobody said they are "all too different". They are just not that identical in the "precision improvement" scale you were talking about. You don't agree, then tell Best Electronics to stop selling "bad" (according to your logic) crystals.

 

IMHO, it is useful and interesting to know the precise definition of colorburst being 1000/1001 times 30 frames/sec * 525 lines/frame * 227.5 cycles/line. That doesn't mean someone who doesn't specify it to the ninth place is "wrong", but merely that it's useful knowing where numbers come from. I still think that 1000/1001 multiplier is 'odd'; I understand that it's useful to have a number of clocks per line pair that's a multiple of small numbers (455=5*7*13) but I'm not sure why they chose 455 and then threw in the 1000/1001 kludge, rather than simply picking a different multiple (e.g. 495=5*9*11, or 429=3*11*13, or 441=3*3*7*7)?

 

Yeah, I agree it's not wrong to specify ninth or tenth digits since that 1000/1001 factor causes a repeated decimal (making it inexact regardless of how many digits you use) whereas in fractional form it's exact. NTSC colorburst rate comes to 227.5*525*30*1000/1001 = 3579545.4545Hz but Atari is using 228 clocks per scanline and 262 lines/field so it looks like NTSC supports this mode. It has some "leeway" so locks into the signal despite this difference. I saw on the Atari 5200 motherboard crystal of 3.579575Mhz whereas on an Amiga MB I have seen 28.636363636363Mhz which is more exact (8*NTSC colorburst).

[atariksi]

and let us not forget our good ol' friend nyquist.....

 

If you can lock into the phase of the signal coming in (know the phase), Nyquist's theory of sampling >=2X does not apply. So in this case since you know the POKEY frequency and transmitters frequency and if you synch up the phase properly intially, you don't need POKEY to be doing >=2X sampling of input.

[atariksi]

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.

 

I wasn't making fun of you-- I was pointing out how by being vague or unclear about something does not allow one to draw an exact conclusion.

 

You mentioned overclocking in post #55. Okay, so if there's no relationship between bi-dir clocking modes and internally clocked modes, then you can't state I am taking POKEY beyond its spec. by doing >1mbit/second transfers.

[Rybags]

But you can't phase adjust the Atari.

 

Pokey, 6502 and everything else on the board for that matter does specific things at certain times in a clock cycle.

 

It's not like Pokey can go "Hang on guys, we're all going to run the low point of the next cycle an extra 80 ns so we sync to the clock of this thing hanging off the serial port".

[candle]

Rybags: but you surely can phase-adjust pc

[Bryan]

Rybags, Bryan: its 4, when clocked from 64/15khz clock source, and 7 when clocked by phi2

 

That's only because of the change from 8 to 16 bit counting mode. It takes each 8-bit counter 3 cycles to "realize" it's reached 0, and one cycle to reload the counter.

 

So, that got me thinking about using the internal baud rate again. In 16-bit mode your max bit rate is 127840, but shouldn't you be able to go almost twice as fast if you knock off 3 cycles by using 8-bit counting?

 

-Bry

[atariksi]

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?

 

You can improve on what was posted before by disabling screen DMA (LDA #0/STA 54272), doing ack in the beginning to be consistent with the block, etc. For 1mbit/second, you need at least 10 microseconds between sending ack and reading next serial byte (18 CPU cycles) so use spare time for computing a checksum or something else:

 

LDX #ACKH

STX PACTL

LDX #ACKL

STX PACTL

LDY #0

LDA (BUFFER),Y ;6 cycle delay

NOP

STY ChkSum ;zero page variable

CLC

Loop: LDA SERIN

LDX #ACKH

STX PACTL

LDX #ACKL

STX PACTL

STA (BUFFER),Y

ADC ChkSum

STA ChkSum

INY

BNE Loop

 

For Level change version:

 

LDX #ACKL

STX PACTL

LDY #0

LDX #ACKH

LDA (BUFFER),Y ;6 cycle delay

Sty ChkSum ;zero page variable

CLC

Loop: LDA SERIN

STX PACTL

LDX #ACKL

STA (BUFFER),Y

SelfModify: ADC #0

ADC ChkSum

STA ChkSum

INY

LDA SERIN

STX PACTL

LDX #ACKH

STA (BUFFER),Y

STA SelfModify+1

INY

BNE Loop

 

;51 cycles for two bytes giving 64647 bytes/second.

[ijor]

ijor: i may not make transfefrs at 1mbit on whole packet, but i do at byte level, so there is no problem clocking pokey to at least 1mhz, but above that it start loosing bits, and you have to transmit 10 bits of zeros to reset input buffers and corelated logic, otherwise you'll end up having your data shifted by a bit

 

Are you sure you really clocked Pokey at 1 MHz, and are you sure it shifted all bits correctly?

 

possiblities this mode implies is worth exploring whatever the outcome will be, so please, instead being sceptistic to all of this grab your atari, piece of wire and make interface, even using db25 connector, 4 wires and sio jack and try

 

Nobody said it is not interesting to explore sync mode better, and try to push it to its limits.

 

I made some sync mode tests some time ago with a fast MCU. I didn't try the range of speed we are talking about here. I was then more interested in functional behavior. I might do more tests in a week or so, I'm currently out of home.

 

But even then, the theoretic debate is relevant. You can easily proof your point with a practical example. I cannot (easily) make my point with a sample. If a test doesn't work, I can't be sure exactly why failed, and then I couldn't proof my theory.

[ijor]

I wasn't making fun of you-- I was pointing out how by being vague or unclear about something does not allow one to draw an exact conclusion.

 

I didn't reach any (technical) conclusion. My only conclusion when I made that sentence, was that we have a hard time understanding each other.

 

You mentioned overclocking in post #55. Okay, so if there's no relationship between bi-dir clocking modes and internally clocked modes, then you can't state I am taking POKEY beyond its spec. by doing >1mbit/second transfers.

 

I did mention overclocking, but I didnt' say you are or were overclocking at 1.79 MHz. I was trying to explain my point, and I mentioned what it might happen if you would overclock Pokey (say, at 3 MHz). Please read that paragraph again and may be you would be able to understand what I was trying to say.

 

I didn't say anything at all regarding Pokey specifications. There are no such specifications AFAIK. I mean, AFAIK nowhere it is specificied which is the maximum Pokey serial rate.

[ijor]

So, that got me thinking about using the internal baud rate again. In 16-bit mode your max bit rate is 127840, but shouldn't you be able to go almost twice as fast if you knock off 3 cycles by using 8-bit counting?

 

I don't have the schematics with me here. But I don't think it would work. IIRC, the counter timeout would happen only when the selected clock is active. This means that, even when using a zero divisor on 8-bit mode, you still have the issue of the clock being 64 KHz (you can't use SIO in 8-bit mode at 1.79 MHz)

[Rybags]

Yep... easily overlooked. Only voices 1 & 3 can be 8-bit @ 1.79.

 

And only voices 2 & 4 are associated with any of the serial modes so far as clocking goes.

[Bryan]

Yep... easily overlooked. Only voices 1 & 3 can be 8-bit @ 1.79.

 

And only voices 2 & 4 are associated with any of the serial modes so far as clocking goes.

Ah, got it. You need counter 3 to clock counter 4... So, the only way becomes the external clock which is sampled once per cycle for a max of ~895KHz.

[+poobah]

and let us not forget our good ol' friend nyquist.....

 

If you can lock into the phase of the signal coming in (know the phase), Nyquist's theory of sampling >=2X does not apply. So in this case since you know the POKEY frequency and transmitters frequency and if you synch up the phase properly intially, you don't need POKEY to be doing >=2X sampling of input.

 

Nyquist always applies. "knowing" the phase of the incoming signal involves obtaining information from the signal (those are samples).

but that's theoretical nit picking.

 

How do you plan to "lock into the phase of the signal coming in" to pokey?

[candle]

ijor: pretty sure of that, i use the same setup for reading serial eeproms (8mbit or more) so it had to be fast for starters

and as i said, above that pokey will start making errors - not often, but it will

i think 895khz (or whatever phi2/2 is) should be treated as safe max speed for pokey

but sending or receiving a byte is not usefull on its own

there is hardware layer, and there is protocol above it, the goal would be to make an loader and test this method in practice

[Rybags]

If you're using Motor Control to ACK each byte, then I'd imagine that could also become the means to do phase-lock.

 

So long as you can guarantee the smoothness of transmission, then I don't see any problem maintaining whatever maximum speed Pokey and SIO happen to be capable of.

 

Data is expected to change on one transition and is sampled on the next transition, so you should be well and truly within a "safe" part of the waveform.