From: Jim Brain (brain_at_jbrain.com)
Date: 2004-10-25 23:36:34
> Yes, it was probably easier for the 1351 designers to choose this > region. ...And as an other reason: as the mouse is clocked at exactly > 1Mhz, it's slightly off from both the PAL and NTSC C64. The difference > isn't that much, but it's integrated at least for 256 cycles, thus it > becomes noticeable, provided that we catch the H-->L transition and > count cycles from there. This could or would cause problems if the full > 8-bit was used. If the used region is however the "middle" 7-bit area, > one simply skip the MSB and everything will work and become "cyclic" > (even the offset caused by the series resistor becomes unimportant). 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. > Though, I won't bet my life that it's impossible to create a routine > which introduces no jitter (or max. 1LSB) for the whole (or almost, > excluding the highest values) range. 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.). 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. > There is no RS-232 port in the 16c84... ;-) In the 1351 emulator code > it's done by bit banging. The two concurrent routines share the only > (8-bit) timer of the PIC. The cycle start is triggered by an external > interrupt. But, while the code is waiting for the external interrupt to > occur, the timer interrupts are disabled (the serial routine just polls > the timer and the serial line). Ouch. So, you use IRQs some of the time for the RS232, and poll other times. Impressive. 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.) Jim Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.