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.