From: Hársfalvi Levente (hlpublic_at_freestart.hu)
Date: 2004-10-31 23:29:51
A pretty late reply...
Jim Brain wrote:
> I noticed that you can adjust the reading by either the timing OR the
> resistance, so they probably set the 256+X*2 in the ASIC, and then fiddled
> with the resistor to get the start and end they wanted. The resistance
> changes would cancel out the accumulating effect of the mismatch, by
> sliding the effective numbers up or down accordingly.
Hmmm... I've played with this one, and in fact, they did not. The asic
waits 384 + x*2 ( 0 <= x <= 63) cycles. Although I had (and I have) no
1351, Frank Kontros was kind to make measurements on a partially working
1351 he owned. The values that you can read from the POT registers are
between ~64 and ~192 (approximately) on a PAL machine. You're right, the
delay caused by the series resistor, and the gain caused by the clock
difference approximately cancel each other. ...On the other hand, this
isn't true for NTSC machines. These machines count faster than the 1351,
thus the errors will be of the same sign, thus they add together.
How could the 1351 still work as intended?... Well, if you drop the read
value's MSB, the values between 64 and 192 (or whatever they are around
64 and 192) will map to somewhere between 64...127 and 0...63
respectively, with a "wrap-around" at the middle. The trick is: the
values transmitted by the 1351 are "cyclic". It's kind of irrelevant if
the internal counter of the 1351 start from 0 and count up to 64, then
wrap around, whilst the values in the POT registers count from 64 to
127, wrap around, and continue counting from 0 to 63.
Similarly, the static offset caused by the clock difference and the
series resistor doesn't count as long as the values are cyclic, and the
MSB is dropped. ...That case, the counting start from 70 or 75 or
whatever instead of 64, count up to 127, wrap-around, ...etc., really no
matter where.
(The accumulated error for the 128, and only for these 128 changing 1351
cycles still count, but the error will be made up by this component
only; no "static" errors will make it to the transmitted coord data
error, as long as the MSBs of the values are dropped and the absolute
position is irrelevant).
> I am positive you can:
>
> With a fast enough CPU (read as ubicom SX line at 50Mhz), startup code
> could watch until 2 transitions occur and then set the timer prescaler.
> Then, you'd essentially 'lock' to CPU freq (take period between two
> transitions, divide by 512, and that's your timer freq. Checking would
> need to be make sure number is sane (in case they plugged the unit into
> the port while some routine was switching to the other POT lines,etc.).
Yes, something like this.
> I actually started down that path, as I have SX units here and my AVR code
> was just not working. I got the POT stuff working, but then my bit-bang
> protocol on the other end (20uS cycle period, 50Kbps clocked serial
> stream, 17 IRQs per byte (1 for each timer half cycle IRQ, and 1 ack IRQ)
> quit working. It worked fine if I did not run the POT code, but stopped
> or bahaved badly if I turned that code on. I decided to try to use the
> on-board SPI to handle the incoming data, but the clock options for the
> SPI are a bit too high (lowest was 16uS cycle time). However, it worked,
> and it reduced the IRQ load from 17 to 1. It also reduced the code
> footprint considerably. I thought it was best to go down this route, as
> sourcing and programming an AVR is much easier than an SX, and my
> knowledge of PIC/SX is small as yet.
An AVR clocked at 8Mhz should be suitable for jitterless operation if
I'm right...
In the 1351 design (and also my emulator) the real problem was the
relatively low clock freq of the asic (in my emulator, the MCU). The
5717 was clocked from 1Mhz, and the 16c84 in the emulator was clocked
from 4Mhz, which in a PIC means 1Mhz core clock. At 1Mhz, there's no
possibility to catch the falling edge of the SID signal with better than
1Mhz resolution. The SID and the mcu clock are continously "sliding"
from each other, resulting in jitter just at the first stage of the
process. There's no way at 1Mhz to do anything about the jitter.
If however, the mcu core was clocked at for example, 8Mhz, the maximum
inaccuracy could be kept below or equal to 1/8th of the 1Mhz cycle. From
this on, the problem is "solved". All a jitterless "bit banging" SID POT
data transmitter would need a "8Mhz cycle exact" sync for the falling
edge of SID signal, and from that on, counting the correct number of
8Mhz cycles, so that the pulling up of the mcu output would happen at
the right SID cycle. As another requirement, it should happen between
two successive SID ~1Mhz cycles, so that it'd never happen at sampling
minutes (thus the minute of the switching could never introduce
unsteadiness). These two latter tasks would probably need, as you wrote,
the measurement of the SID signal's cycletime (maybe even continuously,
by keeping track on the total number of 8Mhz cycles between two
successive falling edges of the SID output signal)
BTW, as another comment on the above: I couldn't implement PS/2 mouse
handling for similar reasons. It would have needed fast synced serial
data read, that I couldn't implement together with the POT "generator"
routine (in fact, I was happy that I could even make it work together
with the rs232 routine ;-)))) ).
> Ouch. So, you use IRQs some of the time for the RS232, and poll other
> times. Impressive.
The 16c84 is so slow that each cycles of delay would have caused the
same "amplitude" of noise in the transmitted numbers. The timer
interrupt and the bit-read would have caused 0...15-20 cycles of erratic
delay. So I had no alternative... |-)
> Since I'm not completely comfortable with my overclocked solution, I might
> see if I can slow down the clock and go back to my bit bang idea (I don't
> need to get data from the other side at 50Kbps anyway, Getting it at
> 4.8Kbps (10 bytes of data, 60 times/sec, 8bits/byte) would be plenty
> fast.)
What's this equipment anyway, and what interface is this?
Best regards!,
L.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.