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.