Some more explanation:
Back in 2009 I did some tests and discovered 2 important things:
Bit sampling in pokey is shifted by 5 PHI2 cycles, at divisor 0 sampling takes place in cycle 12 of 14, not in cycle 7 or 8 (the center of the bit) as one would expect. This explains the asymmetric tolerance against baud-rate deviations, you don't have some +/- 3% as usual but something like -6% .. +0% (i.e. lower speeds working fine, but higher speeds result in failures).
At divisor 0 it's even worse, one byte would usually be 14*10 = 140 PHI2 cycles, but POKEY isn't able to detect a new start-bit at cycle 140. Detection works fine at cycle 141 and later, so you need to lower transmission speed (I guess this was your main question). If the start bit begins at cycle 140, pokey synchronizes on the next high-to-low transition in the bit stream and uses this as the start-bit (which isn't correct, of course...).
In my patched SDrive firmware I disabled the transmitter UART and used bitbanging to work around the problems: I stretched the start-bit by 5 cycles, to compensate for late-sampling, and also stretched each bit by one atmel cycle so that the baudrate matches approximately the PAL Atari rate (SDrives uses a 14.318MHz "NTSC" crystal).
Other solutions can also just use a lower baudrate or, within several limitations, add a second stop-bit (but the latter doesn't help you with the late-sampling issue, so using a lower baudrate is preferable).
In the "real world" you also have to pay attention to 2 other things, but I guess you all know them very well already:
One thing is the speed difference between PAL and NTSC Ataris, you have to set your baudrates so that they work with both systems. It's fine to choose the lower speed PAL baudrates, due to late-bit-sampling.
The other thing is signal rise/fall time on the SIO bus, especially if you have a lot of devices connected. The edges are then far from being steep (looking more like a sine than a square wave), so detection of the start-bit (high-to-low transistion) can be somewhat skewed, by a few PHI2 cycles (let's say 1 or 2).
As for the baudrate values in atarisio: I wrote a small program to calculate all possible baudrates my 16950 UART could generate (you have fine-grained control over baudrates by using the times-clock and clock-prescaler registers) which matched somewhat the calculated NTSC/PAL pokey baudrates. At this time I didn't know about late-sampling and min. 141 cycles so I just experimented with different baudrates/stopbits. Later I started to investigate things, then knew that I had to keep the baudrates somewhat lower (at least with divisor 0 and 1), and kept the old testing-parameters as a reference in the source.
BTW: I wrote a short summary about this POKEY behaviour at the end of the README of my highspeed patch. Back in 2009 I was discussing the research in a thread on AtariAge: http://www.atariage.com/forums/topic/13 … try1696180. In 2010 I did some more tests, now also covering pokey IRQ timing, and also hooked up my logic analyzer. The discussion was also on AtariAge: http://www.atariage.com/forums/topic/16 … ng-details, the test-programs included in this thread also contain the logic-analyzer captures in VCD format (use gtkwave to view them), in case you are curious :)
so long,
Hias
