ESP32 and SIO Baud Rate calculation

[tschak909]

There seems to be a slight clock skew for the ESP32/ESP8266 baud rate clock.

 

Currently, we are using the baud rate calculation that is present in the Atari hardware documentation:

 

baud = 894895/(7+divisor)

 

This pretty much works for all baud rate divisor up to 2.

 

However, while the baud rate divisor of 0 (127840bps) does not work, it DOES work if I subtract 1858, and use 125984.

 

Am curious as to why, especially since we are running the ESP at a 240MHz clock...

 

-Thom

[ivop]

This might be a problem at the Atari side, i.e. capacitors still in place?  When I did my sio2world experiments, I noticed that somehow divisors <= 3 worked best with 8N2 instead of 8N1 with unmodified Ataris.

 

[tschak909]

I am using a 1200XL, so those caps aren't there.

-Thom

[HiassofT]

At the lower divisors (at least 0-2, better 0-3 or 0-4) you have to set the baudrate a bit lower to compensate for late pokey sampling (details are in README of my highspeed SIO patch).

 

Targeting a byte time of 3 Atari cycles more than what the formula gives works fine. See eg my AtariSIO implementation: https://github.com/HiassofT/AtariSIO/blob/master/tools/UserspaceSIOWrapper.cpp#L1148-L1168

 

so long,

 

Hias

[TheMontezuma]

1 hour ago, HiassofT said:

At the lower divisors (at least 0-2, better 0-3 or 0-4) you have to set the baudrate a bit lower to compensate for late pokey sampling (details are in README of my highspeed SIO patch).

 

Targeting a byte time of 3 Atari cycles more than what the formula gives works fine. See eg my AtariSIO implementation: https://github.com/HiassofT/AtariSIO/blob/master/tools/UserspaceSIOWrapper.cpp#L1148-L1168

 

so long,

 

Hias

I just wondered about compatibility of a high speed SIO device with a PAL/NTSC Computers.

For example Thom got the #Fujinet working with HSIndex 0 with an NTSC Atari and the same code didn't work for me (PAL Atari).

Altirra Hardware Reference mentions different baudrate valued for NTSC and PAL.

[Rybags]

The master clock difference would come into play at lower AUDF settings.

At higher ones (lower bitrate) Pokey is able to compensate and resync with the slight difference - likely the 7 cycle counter reset time is extended when that's necessary.

Fairly sure the tech docs mention +- 5%

[HiassofT]

2 hours ago, TheMontezuma said:

I just wondered about compatibility of a high speed SIO device with a PAL/NTSC Computers.

For example Thom got the #Fujinet working with HSIndex 0 with an NTSC Atari and the same code didn't work for me (PAL Atari).

Altirra Hardware Reference mentions different baudrate valued for NTSC and PAL.

For SIO devices it's best to target PAL rates, as NTSC rates are higher and that doesn't play nice with late POKEY sampling.

 

In theory you'd have max +/-5% tolerance for serial communication (that's +/-50% bit time at the tenth bit, the stop bit), rule of thumb is to target +/-3% so you have a bit of margin for slow edges and clock skew and jitter (yeah, the latter was a problem with two of the lotharek SIO2PC USB interfaces, 125000bit/sec was unreliable due to large clock jitter the dual SIO2PC/1050-2-PC ones were fine).

 

Compensating for only 3 of the clock cycles, targeting PAL, left enough headroom for NTSC as well as receiving from POKEY.

 

Another approach would be to stretch the start bit by about 7 Atari cycles when transmitting and use the exact PAL or NTSC rate (or something between) - then there's enough margin so the rate isn't too critical.

 

so long,

 

Hias

[Rybags]

Could you sample timing of part of the command frame then deduce the host system from that?

[HiassofT]

2 hours ago, Rybags said:

Could you sample timing of part of the command frame then deduce the host system from that?

Yes, that could work.

 

Easiest way would be to sample the clock line as there should be a square wave. Sampling the data line is a lot trickier as you only know that there should be 5 bytes in the command frame but can't make too many assumptions about the actual data.

 

Modems back in the 1980ies/90ies used a similar approach to determine the baud rate, parity etc in command mode, but as all commands had to start with "AT" it was a lot easier to implement as they knew what the bit pattern should look like.

 

If the UART baud rate selection is fine grained enough to use an eg ~125500 rate for divisor 0 then that's in general good enough to provide reliable operation (both in RX/TX direction and both on PAL/NTSC computers). SIO2PC implementations have been using that successfully for quite a while. If you have the possibility to stretch the start bit when transmitting to the Atari it's even better.

 

so long,

 

Hias

[ijor]

I posted a simulation waveform illustrating the pokey delayed serial input capture/sampling: