So i'm testing out a one-off peripheral i'm making. It reads out a score (or whatever you want in digits 0-9) on an 8-digit display made of display tubes.
Basics:
I first thought of exploiting the fact that $4016.0-2 are latched internally. That gives me a 3-bit parallel line.
bit 0 is used for the data itself
bit 1 is used to toggle hi and low every write
bit 2 is used to update the display itself once all bits have been shifted in (so we don't get any fluttery artifacts, even if they should be very subtle at this rate).
the shift registers are more feature rich than that but i don't feel a need to for example turn the display on/off, clear the entire memory, or whatever. If i would, i guess the current use of bit 2 could be made a function of bit 1 to free bit 2 up. If i do that, the best utility is probably to split all the shift registers into two groups and thereby split the upload time in half.
i'm using a 1/4 from an off the shelf 74HCT86 (quad XOR) with an R and a C to synthesize a clock from the rising and falling edges of bit 1. This is used to strobe the shift registers on each write that there is new input to shift in. This was done under the assumption there's no useful clock to use while writing (the controller port clock is only good for reads, right?). 3/4 of the gate is left unused but it doesn't bother me.
There's 10x 8-bit shift registers. They currently daisychain their carry over to each other. They also happen to double as tube drivers. This reduces parts count greatly so i feel pretty comfy being locked in on these even if decade counters or a few couple of shift registers with a bigger word could've been more handy otherwise.
So.. this works in simulation. But i'm aware it isn't very lean. When the score changes, you first have to prepare a buffer in the format wanted by the shift registers + decade counting displays. Then you have to write the data serially - 80 times! The way i might go about this in code is space the tasks out between frames to not cause a significant CPU spike every time the score changes; so there's a slight but hardly noticeable delay between game and score display.
I was toying with the idea of using a middleman device (probably arduino) to calculate and transfer the buffer based on raw score data, but the point of the exercise is to use new-old-stock and off the shelf beans only.
Another option using the same controller connection is to tell a primary shift register what other registers to uptick and not daisychain their carry at all, which will shorten the length of bits to write. But this makes the buffer format less transparent (compressed, then decompressed by hardware) and increases vulnerability to sticky human error-caused bugs.
I could also reduce the number of digits. Meaning 10 less serial writes for each digit removed, and also less preparation. 8 just seemed like a nice number. But 6 might do. I also don't need to actually connect the first digit/tube to any logic if scores are always a base of 10. It could simply be hardwired to 0. That just might be enough to bring it into more palatable territory.
Since i'm tapping the expansion pins already, i might just pick up the data lines instead but that's deep water for me at the moment. I don't know the first thing about defining an address, avoiding conflicts, and so on.
A side effect of the scheme i'm currently using is that i'm constantly resetting the controller/s while updating the score, but that doesn't really matter.
Any thougths?
Edit: one question i have... are $4016.3-7 always discarded internally? Or could they, since they're not latched (derived from the info that 0..2 are latched), be used as a pulse trigger to serve as a clock? Assuming there's even a line to hook into. D3 and D4 being on the controller port would suggest there is.
Basically: What's the behaviour of D3 and D4 if you attempt to write to them to any hypothetical device that may be able to pick it up?
Basics:
I first thought of exploiting the fact that $4016.0-2 are latched internally. That gives me a 3-bit parallel line.
bit 0 is used for the data itself
bit 1 is used to toggle hi and low every write
bit 2 is used to update the display itself once all bits have been shifted in (so we don't get any fluttery artifacts, even if they should be very subtle at this rate).
the shift registers are more feature rich than that but i don't feel a need to for example turn the display on/off, clear the entire memory, or whatever. If i would, i guess the current use of bit 2 could be made a function of bit 1 to free bit 2 up. If i do that, the best utility is probably to split all the shift registers into two groups and thereby split the upload time in half.
i'm using a 1/4 from an off the shelf 74HCT86 (quad XOR) with an R and a C to synthesize a clock from the rising and falling edges of bit 1. This is used to strobe the shift registers on each write that there is new input to shift in. This was done under the assumption there's no useful clock to use while writing (the controller port clock is only good for reads, right?). 3/4 of the gate is left unused but it doesn't bother me.
There's 10x 8-bit shift registers. They currently daisychain their carry over to each other. They also happen to double as tube drivers. This reduces parts count greatly so i feel pretty comfy being locked in on these even if decade counters or a few couple of shift registers with a bigger word could've been more handy otherwise.
So.. this works in simulation. But i'm aware it isn't very lean. When the score changes, you first have to prepare a buffer in the format wanted by the shift registers + decade counting displays. Then you have to write the data serially - 80 times! The way i might go about this in code is space the tasks out between frames to not cause a significant CPU spike every time the score changes; so there's a slight but hardly noticeable delay between game and score display.
I was toying with the idea of using a middleman device (probably arduino) to calculate and transfer the buffer based on raw score data, but the point of the exercise is to use new-old-stock and off the shelf beans only.
Another option using the same controller connection is to tell a primary shift register what other registers to uptick and not daisychain their carry at all, which will shorten the length of bits to write. But this makes the buffer format less transparent (compressed, then decompressed by hardware) and increases vulnerability to sticky human error-caused bugs.
I could also reduce the number of digits. Meaning 10 less serial writes for each digit removed, and also less preparation. 8 just seemed like a nice number. But 6 might do. I also don't need to actually connect the first digit/tube to any logic if scores are always a base of 10. It could simply be hardwired to 0. That just might be enough to bring it into more palatable territory.
Since i'm tapping the expansion pins already, i might just pick up the data lines instead but that's deep water for me at the moment. I don't know the first thing about defining an address, avoiding conflicts, and so on.
A side effect of the scheme i'm currently using is that i'm constantly resetting the controller/s while updating the score, but that doesn't really matter.
Any thougths?
Edit: one question i have... are $4016.3-7 always discarded internally? Or could they, since they're not latched (derived from the info that 0..2 are latched), be used as a pulse trigger to serve as a clock? Assuming there's even a line to hook into. D3 and D4 being on the controller port would suggest there is.
Basically: What's the behaviour of D3 and D4 if you attempt to write to them to any hypothetical device that may be able to pick it up?