From: Jim Brain (brain_at_jbrain.com)
Date: 2004-10-24 23:12:48
> Or, you could drive the POT line using 2 portbits, one with and
> another without (or a small) series resistor. The code could turn on
> the second output for, say, the first 1 or 2 SID cycles of the acive
> period, effectively shorting the charging time down to 1 or 2 cycles.
I'll try it.
>
> Just another thing that I should mention: the 1351 document describes
> only 1 LSB jitter. When I built my board and after I fixed the delay
> line code, I noticed similar results: the "noise" fell down to no more
> than 1 LSB. (If you noticed more jitter, then there's probably still
> some possibility to enhance your code -- no more than 1 LSB of jitter
> is possible).
I noticed a few things as I dug into the protocol:
If you constrain your range to 64-192, you don't have to fight the SID
clamping the line low at each end.
Also, jitter seems the least in the 64-192 "sweet spot"
If you go all the way to 255, you risk missing the H->L transition
needed to time your routines, as you clamp the line low so long
CBM chose to have the line low until the match is made, then go high
until 192 cycles into the charge. They could have went the other way,
but didn't. Putting it at the end of the cycle means less decay time,
but I also noticed that if you did this and went al the way to 255,
you'd be tying the line LOW at 255, and you'd miss the trigger. Doing
it LOW/HIGH means you are almost always high when the trigger time comes.
> (One idea: whilst interrupts are always "cycle exact" on the PIC, they
> aren't on the Atmel. ...Though, as the Atmel's core runs at a much
> higher frequency, this shouldn't explain the +-3 cycles noise. Noisy
> analog environment, and / or more than one enabled IRQ sources in the
> mcu, these are that I could suspect at first).
I did not look at your code to see if you used a PIC with an onboard
RS232 port, but in my prototype, I'm bit banging something on the other
end, and that code is IRQ driven, so there are times, when my routines
clash on times. For simulating a paddle, I doubt the extra jitter is an
issue, and if they constrain their range to 64-192, they shoudl see LSB
only jitter. They can also go to 16MHz, but I can't here, because I
use the SPI for the other interface, and I've got the SPI turned down
all the way (clock wise), and it's just barely slow enough. As well,
I'd rather not have to put space on the board for a crystal and caps.
> My protocol idea assumes you don't scan the keyboard rows during the
> time you request raw data.
>
> O.K. No, I didn't mean that it interfered with the keyboard scan
> process; I meant, it could interfere with the user who's currently
> typing, and by that, is shorting some lines that are currently used in
> the communication. (Or it's not possible, and I'm simply wrong in that).
Well, if all the CIA lines are set to input (except FIRE), then pressing
a key would likely not override my hard sink to ground... If you had
controllers in both ports, tho, it could be a problem.
Jim
--
Jim Brain, Brain Innovations
brain@jbrain.com http://www.jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.