SIO synchronous mode technical thread

[ijor]

Timeout management

 

Handling timeouts at these frequencies is not trivial. Interrupts must be disabled, of course, and at the highest frequencies we can't even afford to spend any cycles checking for timeout. There are some timeouts that should never happen under normal conditions and they are the most difficult to deal with. Once the transfer started, unless there is a hardware malfunction, no timeout should happen. Personally, I don't care too much to detect a timeout if I accidentally disconnected the SIO cable or turned off the drive. But I realize that a "professional" commercial product might don't want to lock and would prefer to issue a timeout error, even in those conditions that normally don't happen.

 

The way to detect a timeout without adding any extra cycles to the main loop is simply to unfold completely the inner, shorter, loop that waits for the incoming byte. Since the loop is already quite tight and it doesn't have too many idle cycles, the number of iterations to unfold is very small. Of course, this wouldn't be effective for slower frequencies. At slower frequencies we would need to unfold too many iterations. But then at slower frequencies we could afford a more "conventional" timeout strategy, like decrementing a counter.

 

This strategy of unfolding the loop doesn't work for the first byte that could take much more time. So again, for the first byte we must timeout using another method. I used a Pokey timer, but that's not the only way. When waiting for the first byte I don't wait until the byte arrived completely. If we would do that, we might risk to enter the main loop a bit too late. So instead I wait for the first byte just starting to arrive. Fortunately Pokey has a special flag for that at SKSTAT. This is signaled as soon as the first start bit is detected. This way we could start the main loop optimally even before the first byte has completely arrived:

 

	
;
; First byte timeout checking SKSTAT bit 1
;
	ldx		#$20
	sta		STIMER		; Reset timer
	lda		#$02
	sta		IRQEN		; Enable timer #2 IRQ
:wait0
	bit		SKSTAT		; 4 Pokey receiver busy?
	beq		:start		; 2/3 start bit detected by Pokey
	bit		IRQST		; 4
	bne		:wait0		; 2/3 No timer #2 IRQ
	beq		:timeOut	; More than a full byte time elapsed
	
:start
	stx		IRQEN		; Enable rcv IRQ, disable timer IRQ
	txa					; $20
	bne		:nextByte	; Unconditional
	
;
; "Fast" timeout, doesn't add any extra cycles to the loop
;

:waitByte
	and		IRQST		; 4
	beq		:gotByte	; 2/3
	and		IRQST		; 4
	beq		:gotByte	; 2/3
	bne		:timeOut	; More than 1 byte time elapsed
:nextByte
	and		IRQST		; 4
	bne		:waitByte	; 2/3
	; Fall through without branch taking
	; for fastest best in case we were a bit late
:gotByte
...
;
; Might use different timeout when receiving checksum
;
...
:timeOut

 

Again, some implementations might check for timeout just at the first byte, *AND* at the last byte. Even without a hardware malfunction, a timeout might occur when receiving the checksum. This could happen if Pokey missed a serial clock pulse. It is possible to implement a special strategy at the sender to avoid a timeout, even if the computer missed a byte. I.e., the peripheral might send an extra byte or two.

 

 

[phaeron]

What about using ANTIC to do the timeout? Since the display has to be turned off anyway, you could use a display list with a couple of chained JVBs and ending in a DLI as a watchdog timer. It'd only cost a few cycles every frame.

 

[Rybags]

I do say that there is the answer - at a cost of 3 bytes per frame a fairly cheap solution.

In theory you could have a short duration one to detect truncated records - just reset the low byte of DLISTL each received byte to restart the count.

 

[+Stephen]

Neat - today I learned that when ANTIC DMA is off, DLIs will still fire.

[ijor]

19 hours ago, phaeron said:

What about using ANTIC to do the timeout? Since the display has to be turned off anyway, you could use a display list with a couple of chained JVBs and ending in a DLI as a watchdog timer. It'd only cost a few cycles every frame.

 

That's a brilliant idea that, honestly, I didn't think about it. But I would need to check it carefully if it wouldn't be too tight. Yes, just 3 cycles per frame, but they happen all together almost one right after the other.

 

In anycase, it might still be a good idea to use a "fast" timeout when waiting for the checksum. Fast in the sense to detect it as soon as possible. This is just for the sake of efficiently retrying a packet in the case Pokey missed a clock pulse. Timeouts at other points should normally not happen, so it is perfectly ok to have a long timeout.

 

7 hours ago, Stephen said:

Neat - today I learned that when ANTIC DMA is off, DLIs will still fire.

No. You technically can have DLIs with ANTIC DMA being disabled. But this won't be very useful here. What he is suggesting is to not disable ANTIC DMA, but instead to use a minimum display list, without any actual display, that would just trigger a DLI after so many frames.

Edited March 10, 2021 by ijor

[Rybags]

Option 2 might be to use a DList that continually walks through.

Just have a succession of 8 blanks lines followed by one with a DLI, so just one cycle loss per 8 scanlines in the display area.

Though with the 1K wraparound that equates to only 34 frames.

Possibly Antic Mode 7 (Gr. 2) - that's 16 scanlines which would double the possible timeout period, just run with DList DMA on and PF DMA off.

 

Disadvantage here is it could get memory hungry.

[ijor]

Pokey serial shift maximum bitrate

 

Pokey SIO synchronous mode using an external clock can operate at bitrates much higher than the standard asynchronous mode. The maximum possible bitrate for Pokey is one third of the main clock, in other words, the period must be at least 3 PHI2 cycles. This is a limitation of how the Pokey shift registers work.

 

A shift register is typically based on edge triggered flip flops. Such a shift register can shift in a single cycle. An edge triggered flip flop can both shift in and shift out in the same cycle. But edge triggered flip flops are very expensive for the small transistor budget of the era. It was common to use much simpler cells based on asynchronous latches rather than edge triggered flip flops. Asynchronous latches use less transistors but because they are transparent latches, they can’t shift in a single edge. They need separate steps for shift in and shift out. Performing the shift in multiple steps requires a slightly more complicated control logic. But the control logic is shared by the whole shift register. It is then still cheaper, in terms of  the number of transistors, to implement a more complicated control logic with simpler cells for each bit.

 

Pokey shifts in three cycles. One cycle to shift out, two idle half cycles, and a third cycle to shift in. The idle half cycles between both steps are required to ensure they don't overlap. It is not completely impossible to use "cheap" asynchronous latches and still shift in a single cycle. This is implemented using half cycles controlled by both edges of the clock. But this method requires precise timing and might hinder performance. It is normal to avoid such method if possible. Pokey uses a safe and efficient method that was surely considered more than fast enough at the time.

 

This is the man shift register bit cell from my reverse engineered schematics:

 

 

This is a simulation waveform with Pokey receiving using an external clock with a period that is exactly three PHI2 cycles:

 

 

 

The names of most signals are the same used in my Pokey reverse engineered schematics:

 

PHI2 is the main system clock

rBCLK is the external serial clock as seen internally by Pokey after being synchronized

sdiClock is the single cycle clock pulse generated by Pokey for driving the receiver control logic

ssiShft  (in light blue) and ssiTransf (in red) are the main signals produced by the control logic to perform the shifting

ssi_7 and ssi_6 are the actual data bits at the shift register

The cycle counter is, of course, a virtual simulation counter that is not present in real hardware

 

Shifting starts at the middle of cycle 19 when ssiShft  is asserted and enables shift out. ssiTransf is asserted one a half cycle later, at the start of cycle 21 to enable shift in, and ssi_7 toggles.

 

This is a similar simulation waveform, now with a clock period of only two PHI2 cycles that cannot work correctly:

 

 

 

Note how the red signal ssiTransf never asserts once shifting starts. As an obvious consequence, shifting is actually not performed and the bit cells ssi_7 and ssi_6 stay unchanged.

 

Edited April 23, 2021 by ijor

[ijor]

On 3/2/2021 at 5:35 AM, thorfdbg said:

This POKEY bug reminds me of a similar if not identical bug in the VIA 6522 shift register which can also miss a clock. It is the bug which caused CBM using a bit-banging interface for the floppy, and which is responsible for the terribly slow floppy transfer rate of those machines. The problem was fixed in the CIA chips (revised and enhanced VIA), but CBM in their infinite wisdom decided to keep the bitbanging interface for compatibilty reasons.

 

I wonder whether Atari just copied the POKEY design from VIA, does anyone know?

 

 

This is very interesting. I wasn't aware about that VIA bug and spent some time researching the issue.

 

The bug is essentially the same. An unreliable synchronization of the external clock that might miss an edge if the external clock active transition happens too close to the internal clock edge. But the actual logic is quite different, it wasn't copied. I think that at the time these kind of issues weren't that uncommon. But they weren't always noted and many times they were just harmless. Say, if once in a while a system missed an edge on a joystick switch, probably nobody realized. OTOH, synchronizing an external clock as in Via and Pokey, is particularly sensitive.

 

A reverse engineered schematics of the VIA edge detector is available here (obviously very different than Pokey's one):

 

https://github.com/ijor/VIA6522/blob/main/viaSchem-EdgeDetector.png

 

 

Edited April 23, 2021 by ijor