From the sublime to the ridiculous - 8-byte PROM

[BruceRMcF]

So that means mini-DROM would be about half of that, and that mega-DROM is a two board enterprise for leaded components and plated through holes?

[BigDumbDinosaur]

barnacle wrote:

Sadly, it turns out that using leaded components and plated through holes, there's only room for sixty-four bytes...It has a certain elegance, though...

Egads!  My eyes are watering just at the thought of forming that many diodes and soldering that many leads.    Reminds me of the long-ago days when I built diode decoding matrices to drive traffic signal displays (gazillions of light bulbs that pretended to be a seven-segment display).

[Dr Jefyll]

barnacle wrote:

I had to upset every rule the PCB program had

Yes, that's the challenge. Shrinking the cell size in order to maximize density.

I've been holding back on mentioning an alternative approach, and that's because I'm uncertain whether it can offer improved density. FWIW, I'll share that idea now. Yes there's a tradeoff -- of course there is! -- but perhaps the thing can nevertheless be made to show a net profit in terms of board area.

Since area is our concern, remember that, up until now, each of the bits to be stored requires a footprint for a diode and also a certain amount of overhead for the traces that attach to the diode. Spoiler alert: the alternative approach uses many fewer diodes, and a lot more traces. That's the tradeoff.

We use many fewer diodes by changing the encoding. (In microcode parlance, we'd say it's more "vertical.") The diagram below shows the contrast. It's important to focus on the area highlighted in color -- the customization area, I call it. This is where the data resides. The highlighted area is what gets duplicated umpteen times, so ruthless economy is paramount.

EDIT: the right-hand portion of this diagram fails to show how diodes are used between the two identical sections. Please see the revised diagram below.

DROM excerpt 00.png (6.04 KiB) Viewed 755 times

The original way amounts to one diode per bit, and -- given that the diode may or may not be present -- there's an implied SPST switch.

The new way has no diodes in the customization area. It's just one SP16T switch per nibble.

So, that's the challenge when it comes to "upset[ing] every rule the PCB program had." Although the customization area no longer contains any diodes, it has a lot more traces, and requires a pair of SP16T switches per byte. (Also we need a pair of nibble-encode matrices, but these are shared by all the bytes. And they'd be quite compact, just 32 diodes each. The other 32 positions take no space because they're never populated.)

Is there an area-efficient way to implement a SP16T switch?

The customization process will be a lot less time-consuming and error-prone. Each byte is just two decisions (one per nibble), as opposed to eight (one per bit). It even become plausible that one might temporarily hack the stored program for experimental purposes! Hm....

-- Jeff

[barnacle]

I think the issue with Jeff's approach might be the complexity of the row/column connection.

Here's a closeup of the single-sided leaded diode part. The address selectors run left-to-right; the bit pullups top-to-bottom. The holes are on 0.1" centres and the diodes provide the crossover. The courtyards are all on top of each other, as you can see.

The surface mount version can use both sides for the crossovers, and it fits on a double sided board because I am able to run the pullups from both sides of the board (H2, A5 and H3, A4) between a pair of diodes, courtesy of a _lot_ of vias.
The address selectors run up-down on this one, and of course each address selector controls all eight blocks.

The address selection is four bits for an address selector, three bits for the block selector, and a final bit for the expected value of A7. On the PTH version, just two bits of the block selector are valid and A7 is (currently) ignored.

I see two issues: firstly, you need sixteen x-direction lines per block, instead of eight, which would require a line spacing of, um, 0.05" for the same density; the second is the nature of the crossover itself. While it would be lovely to have a pin matrix, I suspect it would have to be a simple wire through a hole to connect the matrix. Which is probably fairly tricky even to draw; most PCB programs would want a plated through hole, and that's exactly what we don't need.

On the other hand, if you maintained an 0.1" centre, you could have two blocks (3.2") across one side of a eurocard (100x160mm), and you could fit a link every 0.1" along the board so maybe 64 bytes would fit. Just.

Neil

[barnacle]

On the gripping hand... through hole top setting rotary hex switches are 10mm square, six pins, two of them common.

So a block of eight by sixteen would (just) fit on a eurocard - with a strip 20mm high for the other electronics. and would give 64 bytes of directly accessed memory, rewritable at a moment's notice with a small screwdriver (and no diodes at all).

On the other hand, the diodes are six bucks a thousand, and the switches start at a buck and a half at Digikey. Still, it might be worth it.

Neil

[plasmo]

I have not done any detailed design, but my thoughts about making a 32-byte diode ROM board for Z80 in 50x100mm RC2014 format are: A) I already have a working 32-byte program, so the diode board is not field programmable; it is already “programmed” when the pc board is fabricated. Pc boards are cheap, so different pcb for different program is not unreasonable. B) I like to stand the diodes on their ends, but if that still need more room than 50x100mm, then I’ll consider manually wire the top connections out of the existing diode leads. The idea is similar to building SIP resistor pack out of discrete resistors. This allows diodes to be packed next to each other.

I probably will have different ideas once I’ve started designing.
Bill

[barnacle]

If you already have the code, then you can simply not include places for the unneeded diodes...

Neil

[barnacle]

Based on a modification of Jeff's idea - the pulldowns pull up and the diodes go the other way, because the '154 pulls down, but otherwise the same context.

Note: this is programmed at the PCB making stage! Once it's done it's done, but there's a lot less soldering as a result.

As you can see, there's loads of room. Easily space for another four '154s and the necessary decoding to select the right one, though the diode block is offensive large; a smaller package could shrink that. Not an issue soldering; let JLC put them together - but we'd get 128 bytes without any great problem.

Here's the programming; the code is the first sixteen bytes of my VBIOS. Just put a via in the appropriate place; an F is off piste just to indicate that it's not a mistake.

Neil

[Dr Jefyll]

Quote:

As you can see, there's loads of room.

Glad to hear that, Neil... because I think there's a simple but important modification required!

Regarding my previous post, I'm afraid I was being vague and hasty when I said "no diodes in the customization area." Having given it more thought (and it's a confusing business to get clear about, for me, at least), I think we do require one diode on the common leg of each SP16T switch. It needn't be physically located in the customization area, but that diode does need to be in the circuit. Otherwise there's potential for backflow, causing erroneous activation of other address-decode lines. I've revised the diagram in my previous post to clarify this.

So, each output from each of your '154 decoders needs to drive two diodes, one of which feeds the common of the SP16T that produces the MS nibble, and the other which feeds the common of the SP16T that produces the LS nibble. Yes the extra diode in each circuit will result in increased voltage drop, but I expect that'll be tolerable if Schottky diodes are used. (And use Schottky diodes in the nibble-encode matrices, too.)

Edit: the attached image shows one possible way the thing could be laid out. Each of the 16 outputs from each '154 travels both upward and downward. The upward path passes through a diode on the way to the SP16T switch for the MS nibble, and the downward path passes through a diode on the way to the SP16T switch for the LS nibble.

No vias are required in the two wide swaths where the rows of diodes reside. This suggests that the opposite side of the PCB could perhaps accommodate other circuitry (such as the nibble-encode matrices) in these swaths.

-- Jeff

[barnacle]

Funny, I was trying to decide whether the two rows would be affected by a single common cross point, and decided they probably would...

If we need to put a diode on each select address, though, we have (for a 128 byte store) 256 extra diodes. It might be more space efficient simply to use two decoders, one for high nibble and one for low...

I wonder, rather than using diodes to encode the row to binary, perhaps a binary encode would take less space. It would need a small amount of glue logic for the top bit, but I don't think that's difficult: four bits to two is two nand gates.

From the lack of screams, I assume you're happy with the non-reprogrammable aspect of the vias?

Neil

(Kicad note: Kicad will _not_ allow you to place a via at the intersection of two unrelated signals. However, it _will_ allow you to put a via in free space, and copy and paste it to the same forbidden intersection. Go figure.)

[Dr Jefyll]

barnacle wrote:

From the lack of screams, I assume you're happy with the non-reprogrammable aspect of the vias?

Well, it's your project, so why would I make a fuss? I'm happy just to share the amusement of kicking the problem around! (Or are you asking me to help you gauge whether there'd be more benefit for a newbie end user if it *were* reprogrammable? Interesting question... )

One thing for sure: being non-reprogrammable makes it comparatively easy to arrive at a compact design.

Quote:

I wonder, rather than using diodes to encode the row to binary, perhaps a binary encode would take less space.

Sorry, I'm somehow not quite following you. You said four bits to two. Do you mean anything remotely like this unused idea of mine below?

-- Jeff

[Dr Jefyll]

barnacle wrote:

If we need to put a diode on each select address, though, we have (for a 128 byte store) 256 extra diodes. It might be more space efficient simply to use two decoders, one for high nibble and one for low...

That's worth considering. But another space efficient alternative is to shrink the diode real estate by using diode arrays, each with two diodes. I believe such arrays are available in packages such as SOT-23-3 and maybe even smaller (while hopefully remaining absurdly inexpensive).

The image below suggests one possible layout approach. On each side of the '154 there'd be eight arrays containing 16 diodes. As you can see, I've rotated the '154 by 90 degrees. I had a notion that'd ease the trace routing, but perhaps there are reasons that non-rotated 154's would actually be better.

Edit: or perhaps the 154's belong on the other side of the board.

Edit: btw, there's no absolute need for the total capacity to be a power of two (eg, 128 bytes). If the code really, really wants to occupy 140 bytes, say, then that's worth considering, IMO.

-- Jeff

[barnacle]

I came up with another idea, which I'll need to draw up to see if it works, but here's the precis (all input lines have pullups, address lines pull low):
- replace the 16-4 diode arrays with 8-3 keyboard encoders; they return a value on the lowest zero and give a true binary out
- feed only 8 lines instead of sixteen; use a ninth line for bit three (so two vias for values higher than 7) and invert that top bit as bit 3 and combine the four bits as the nibble value directly
- use a single '154 for *all* address decoding
- but feed it through '241/541 (or is there a 16 bit version? I think so.) decoded in pairs for each 16-byte block. Use their three-state outputs to be either low or hi-z.

Now there's no feedback through any stray diodes, no need to isolate the drives, and only half as many feed lines.

I'll draw it up, see how it fits...

I agree that it doesn't have to be a power of two, but it's nice to be able to scale it.

Neil

[Dr Jefyll]

Quote:

Use their three-state outputs to be either low or hi-z.

Sounds as if you should maybe be considering the 74HC4067 one-of-16 analog mux/demux instead.

[barnacle]

Maybe, but I need to look it up. Meanwhile, here's the idea:

viaprom.pdf

(272.92 KiB) Downloaded 31 times

and a close up of the circuit board:

Which takes up less than half a eurocard for 64 bytes, albeit a little glue logic still to add...

Neil