It is currently Thu Dec 13, 2018 4:21 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Sun Sep 23, 2018 1:22 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1786
Location: Gothenburg, Sweden
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?

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun Sep 23, 2018 11:39 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7818
Location: Seattle
FrankenGraphics wrote:
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.
The controller port clock decodes reads from $4016 and $4017, but that doesn't mean you can't use it as a clock. BIT $4017 still causes it to bounce, and it lets you use one of the other bits for data instead.

Quote:
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.
[...]
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.
You could also use something that takes BCD as input instead of just one of ten bits, like the obsolete 7441, 74141, 74142, or marginally less obsolete 74ls445, shaving it down to 32 bits instead of 80.

Quote:
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.
[...]
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.
All that happens in the 2A03 and 2A07 is that it internally contains a latch on writes to $4016. It's only three bits wide, hence OUT0 through OUT2.

But you're absolutely right that there's nothing preventing you from adding an external latch to decode the upper bits. And yes, you could use one of OUT0 through OUT2 to clock an extra latch rather than needing to add this external logic.

Quote:
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?
D3 and D4 on the controller ports are fully isolated from the CPU's data bus by the 74HC368s.

On the controller ports, you have exactly:
3 inputs to the CPU (poll-able)
2 outputs from the CPU (one general purpose, the other low while reading)
2 power supply pins


Top
 Profile  
 
PostPosted: Sun Sep 23, 2018 12:20 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20870
Location: NE Indiana, USA (NTSC)
Would a 4515 or 74154 work to decode a 4-bit select to sixteen active low enables (ten of which you actually use)? A 4514 is the same with active high. Or are those obsolete too? Is level translation (which I assume is related to the "driver") a hard problem?


Top
 Profile  
 
PostPosted: Sun Sep 23, 2018 5:01 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7818
Location: Seattle
Microchip (formerly Supertex) has their HV509/HV528 parts, 16-bit shift registers capable of driving a 200V output. They also have the HV507, with 64 bits and capable of driving 300V, but it's more than 4x as expensive.

High voltage designs tend to be a little tricky. Not exactly hard to do, but hard to do without spending a few pretty pennies. random related search result. Most of the relevant parts are obsolete now—LEDs are usually just a better plan, albeit boringly familiar, and they need much lower operating voltages.


Top
 Profile  
 
PostPosted: Mon Sep 24, 2018 11:49 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1786
Location: Gothenburg, Sweden
tepples wrote:
Is level translation (which I assume is related to the "driver") a hard problem?


Yes-ish. I'm locked in on a set of DC neon display tubes ("nixies") and they're supposed to operate at 170v with some variance, at 2-3mA each. You can starve the voltage just a bit without any visual problems, but you still need a high-voltage tolerant driver and of course a supply. Or, something like a 50v tolerance (about as far as modern shift registers go) with a zener clamp helping it out can also suffice, maybe a bit depending on the specs of the tubes. The type of transistor used on the output is also important. You ideally want an open drain or open collector. I guess you could do a workaround with a push-pull (which is better suited for AC-operated electroluminescent displays).

But - there's nothing that says it all has to be on the same chip - it's just convenient in one end of the problem. Mostly, I just want to avoid having to solder in a discrete transistor (and possibly a zener) on each line, and there's several routes towards that end.



thanks, lidnariq, for the suggestions. They've been very helpful.

So this is the new plan: one single 32-bit shift register (or whatever) feeds #8 bcd->dec drivers. Simple as that. Provided the logic level matches the vintage parts' input (seems to be ttl). Anyway, i ordered a set of russian vintage nixie drivers. Less expensive than modern counterparts anyway! We'll see what happens when they arrive in 15 days or so. :)

Storing the score as BCD both for the program itself and for the readout is going to be so much more convenient.
A secondary 32-bit shift register capable of clearing itself on carry can tell the first register to pass itself forward to the drivers on the 32th write only if i want to get fancy.

Next up is figuring out if i can use the controller port only (that means no need for invasive modifications). The main problem (maybe not) is filtering out clocks from reading the controller... just a sanity check: if i read (or bit) either controller port, will the low pulse clock (and consequently the rising edge) show on both controller ports, or just the one being read? I'm thinking the latter. Then it's not a problem.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Mon Sep 24, 2018 12:26 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7818
Location: Seattle
FrankenGraphics wrote:
just a sanity check: if i read (or bit) either controller port, will the low pulse clock (and consequently the rising edge) show on both controller ports, or just the one being read? I'm thinking the latter. Then it's not a problem.
You're correct. Only +5V, ground, and OUT0 are shared between the two controller ports: the other four are independent.


Top
 Profile  
 
PostPosted: Mon Sep 24, 2018 12:30 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20870
Location: NE Indiana, USA (NTSC)
Strobe (writes to $4016) appears on both ports, but clock (reads from $4016 or $4017) appears on only one port.


Top
 Profile  
 
PostPosted: Mon Sep 24, 2018 12:58 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1786
Location: Gothenburg, Sweden
That's perfect! Thanks

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group