From the sublime to the ridiculous - 8-byte PROM

[barnacle]

But once again, Jeff pulls a hat out of the rabbit with the suggestion of multiplexors, which solves the issue of both decoding the row address and a tristate output, thereby replacing three chips with one.

Once again, shown with the first sixteen bytes of VBIOS. Values from 8 to F are arranged by setting a via on the '8' line and a second via on the same column (the column lines are on the back of the board) to give the total, so '8' would be rows 8 and 0; 'A' would be 8 and 2, and so on. That almost doubles the density available while still using large SOIC parts and .2mm lines on .025" centres (yes, mixed measurements. Sue me ) If you're desperate, there are smaller packages, tracks, and vias...

This has room for eight muxors along the array lines, which gives a handy 128 bytes, and the array stuff takes only half the circuit board height so it could very easily manage 256 bytes... and that's _loads_ of room to play with!

The big catch of course is that it's in no way reprogrammable. The positioning of the vias between the rows and columns rather mitigates against that... it's set at the PCB stage. But on the other hand, the bare PCB costs only a couple of quid (five for around ten euros from JLC to Europe) and the parts are not expensive (and could be swapped between boards). It's a genuine, official, factory programmed ROM.

Which is kinda where we started...

But here's another thought: stick with the 128 bytes on the top of the board, and a simple 65c02 system on the bottom half, with 64k ram and a mechanism to select the ROM on reset, turned off under program control. A flip-flop would do it, and 128 bytes is enough to get a simple terminal interface up and running.

Neil

[Dr Jefyll]

Are you confident there's no need for diodes to prevent back-feed? Upthread, I came close to getting tripped up on that point.

And is there a target audience for this project? If it's newbies and novices, my instinct tells me that tinkering and zany experiments are an important part of the learning experience! Certainly that was true of my own early career. In that light, a nonreprogrammable ROM seems to go against the grain.

AFAICT, area-efficient reprogrammability simply won't be possible except by the skillful -- indeed, devious! -- use of modern PCB technology. In this post, you said, "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."

So... are non-plated through holes an option in this day and age? (The alternative would be to drill out all the plate-throughs which aren't desired.)

Or, a rather different approach. Can the desired connections be manually established with just a dab of solder? You'd need a clever pattern, where each common point is a pad surrounded by several other pads; the common could be attached to any of the others by creating a little solder bridge. Ideally, the result would be a SP16T switch, but practically speaking you probably have to settle for multiple SP4T switches.

Or, is there a better idea no-one has mentioned yet?

-- Jeff

ps- another question. If it were a 4-layer board, can we do vias which only connect layers 1 & 2, or only connect layers 3 & 4?

[BruceRMcF]

barnacle wrote:

... The big catch of course is that it's in no way reprogrammable. ...

Yes, the strategic decision is whether the reprogrammability should be at the DROM level or at the punched in program level, since the punched in program is infinitely reprogrammable, but in a very, very old school style of punching the program in byte by byte.

But with a programmed at the factory DROM, you can indeed have an option between a punch in program DROM, and, when the punch in routine gets old, a boot-up terminal program DROM, just by plugging a different DROM board in.

There is no memory map conflict between a "punch it into RAM and run it", and "punch an EEPROM program routine in and program a boot-up EEPROM", since the "punch it into RAM and run it" programming exercises are for practical purposes not going to be so large that they need more than the bottom 32KB of RAM.

[barnacle]

Dr Jefyll wrote:

Are you confident there's no need for diodes to prevent back-feed? Upthread, I came close to getting tripped up on that point.

I don't believe so. There are if you are using diodes elsewhere to do the encoding, either in your schema, or in my original design - there, the diodes are required so that _only_ the selected row is pulled low. But here's the current circuit diagram (lacking some decoding logic, power rails, decoupling and no doubt a couple of other things):

muxprom.pdf

(228.71 KiB) Downloaded 41 times

The 4067 has a three-state output and that's the sneaky. If it's selected - and only one will be selected at once - it will decode the 1-of-16 row in its block, and it will be pulled to ground. But other pins on the same chip remain high impedance, and those on other unselected chips (if I read the data sheet correctly) remain hi-Z - the output stage is not totem-pole but transmission gate. Anything hi-Z doesn't affect the other data lines even if connected, except through capacitive load. (That's what I was aiming for with the '154 and 2x'541 (or '16541)).

Quote:

So... are non-plated through holes an option in this day and age? (The alternative would be to drill out all the plate-throughs which aren't desired.)

I think you could do it, either by special representation to the PCB maker (you did want a thousand, right? ) or by defining a hole as a surface mount part. Though when you want to put one on top of the other, your PCB program might complain.

Quote:

Or, a rather different approach. Can the desired connections be manually established with just a dab of solder? You'd need a clever pattern, where each common point is a pad surrounded by several other pads; the common could be attached to any of the others by creating a little solder bridge. Ideally, the result would be a SP16T switch, but practically speaking you probably have to settle for multiple SP4T switches.

I think you could easily define such a footprint, but you would need to be careful about defining the solder resist...

Quote:

ps- another question. If it were a 4-layer board, can we do vias which only connect layers 1 & 2, or only connect layers 3 & 4?

4-layer boards are made as two layer boards, stuck together. You can usually go 1-2 and 3-4, and 1-4, but rarely 2-3 (or at least you couldn't when I was doing this sort of thing for a living.)

Neil

[barnacle]

@ Bruce

Yup, it's a question of how much customisation you have/need. The original concept here is an absolutely minimal DROM which (a) gets you moving initially and (b) provides an emergency recovery mechanism.

I haven't yet tested, but I don't see why writing to the EEPROM would require any particular efforts (other than possibly playing to unlock it, as discussed upthread); in particular a manual write is pretty much guaranteed to take longer than the 10ms write delay. So the first move might be to key in (to ram, then eventually rom) a more sophisticated BIOS that lets you select a start address for your memory editing, possibly using the routines in the DROM. Or maybe start by copying the DROM to EEPROM and then doing it.

But you'd want a terminal/serial input pretty soon anyway, I think: you wouldn't want to hammer in even a tiny basic...

Neil

[pjdennis]

Dr Jefyll wrote:

Or, a rather different approach. Can the desired connections be manually established with just a dab of solder? You'd need a clever pattern, where each common point is a pad surrounded by several other pads; the common could be attached to any of the others by creating a little solder bridge. Ideally, the result would be a SP16T switch, but practically speaking you probably have to settle for multiple SP4T switches.

Or, is there a better idea no-one has mentioned yet?

-- Jeff

I've been thinking it could be possible to use 16-position rotary DIP switches—two per byte—to build a user-reprogrammable ROM. These are available in DIP packages around 10×10 mm, which gives an upper bound of about 80 bytes on one side of a 160×100 mm Eurocard. More realistically, accounting for the connector and decoding circuitry, I think around 48 bytes is achievable. The switches I’ve seen are labeled in hexadecimal; programming the ROM would be done with a screwdriver to set the byte value at each address.

Each rotary switch has a common pin and four outputs that encode the selected position in 4-bit binary by selectively connecting the common to the outputs. I haven’t found a particularly clever way to handle the address decoding, but one idea is to use decoders to pull the common pin high on the two switches corresponding to the addressed byte. Each switch output would pass through a diode (to prevent back-driving), and the high and low nybbles would then be separately bussed and buffered to drive the data bus.

It’s definitely not a low-cost solution—JLCPCB prices these around $1.15 each in quantities of 50+, so you’d be looking at over $100 just for the switches to implement a 48-byte ROM. Routing might also be a challenge. But from a technical standpoint, I think the approach is feasible.

-Phil

[BruceRMcF]

barnacle wrote:

... Yup, it's a question of how much customisation you have/need. The original concept here is an absolutely minimal DROM which (a) gets you moving initially and (b) provides an emergency recovery mechanism.

Yes, the "two DROM approaches" are for two different views of, (a) what "getting you moving initially" means, and (b) what constitutes an "emergency recovery mechanism".

Quote:

I haven't yet tested, but I don't see why writing to the EEPROM would require any particular efforts (other than possibly playing to unlock it, as discussed upthread); in particular a manual write is pretty much guaranteed to take longer than the 10ms write delay.

I'm not leaving the process of writing to the EEPROM blank to suggest it's a challenge, but rather that I don't know what it entails, and since whatever it is entailed could be wrapped inside a "write a byte to this address" call, it's orthogonal to what I was thinking about.

Quote:

So the first move might be to key in (to ram, then eventually rom) a more sophisticated BIOS that lets you select a start address for your memory editing, possibly using the routines in the DROM. Or maybe start by copying the DROM to EEPROM and then doing it.

Using the core process in the DROM is done most easily by copying them to RAM and then patching them, since they are relocatable 6502 code built within the limits of branching. The Hex digit table could be used in place by a RAM routine and copied directly into an EEPROM, and the subroutine calls used in place and copied directly into an EEPROM, but the bulk of the DROM routine could be used by punching in the copy routine (including the patch tables), then punch in the new function operations, then "Go" to execute the copy routine and the copy routine ends by executing the patched version in RAM.

Then a routine to piece together a micro BIOS from the patched DROM code and the resources used directly from DROM can be built somewhere in RAM, and executed in place.

Quote:

But you'd want a terminal/serial input pretty soon anyway, I think: you wouldn't want to hammer in even a tiny basic...

Yeah ... the above approach suggests programming the micro-BIOS into the EEPROM, and then using it to program the terminal elsewhere in the EEPROM, and then knowing the execution address of the mini terminal, when the micro-BIOS boots up, enter the address of the Terminal program and execute it.

But that can be shortcut with a second DROM that just boots straight up into Terminal mode. Even for routines that are intended to be programmed in through the Micro-BIOS approach, the code might be debugged working primarily in Term-BIOS mode.

[barnacle]

@ Phil: I very briefly mentioned the switch idea a few posts back, but it's probably lost in the noise. I think each byte would need two switches, eight diodes, and one line of a low-going selector - something like a '138, '154, or '4067. For maximum packing density, I suspect the selectors and diodes would have to be on the back of the board, and it's possible it might need four layers - I didn't go into that detail.

The parts I found on LCSC were 10mm square, so could arrange in an 8 by 16 array - just! - on a 100 x 160mm eurocard to give 64 bytes; eminently usable and dead easy to program. The parts I found in Kicad were a touch wider, so didn't quite fit, but that's an easily solved problem.

@ Bruce: the big issue with VBIOS is that there is no mechanism to enter an address either for storing/viewing code, or as an execution address. That's the first real program to enter; thereafter the world is the mollusc of your choice. Writing eeprom is a normal write action, with completion indicated by (a) reading the last byte written and waiting until it matches, (b) reading any address and watching for bit 6 to stop toggling, or (c) a 10ms timeout. My thought is that initially, a simple timeout - achieved just by the delay of human action - will let programming occur. A more robust solution will find its way in there sooner rather than later, I suspect.

It's interesting that between us we've come up with the spectrum from cheap but non-reprogammable (muxprom), through cheapish but painful to program (drom), and the absolutely simplest to reprogram but expensive (rotary switches). All of them solve the original issue: how to get a system bootstrapped without access to a prom programmer.

I thank you all for your contributions!

Neil

[Dr Jefyll]

Dr Jefyll wrote:

Are you confident there's no need for diodes to prevent back-feed? Upthread, I came close to getting tripped up on that point.

barnacle wrote:

I don't believe so. [...] If [the 4067 is] selected - and only one will be selected at once - it will decode the 1-of-16 row in its block, and it will be pulled to ground. But other pins on the same chip remain high impedance

Expressed verbally, that line of reasoning seems pretty solid. But IME this stuff is awfully slippery to think about! And -- as was the case with my own circuit upthread -- expressing the thing as a diagram yields a different and gloomier conclusion.

In the image below, I've made some connections which plausibly might arise in real life. Drawn in purple is a line driven by Address 6, and when it goes low it pulls low the input nibl2, as desired. But that low signal will also propagate in an undesired way, backwards along the connections drawn in green (which are only supposed to go low for Address 2). Unless I'm somehow missing something, diodes or some other measure *are* required to prevent the back-feed.

Dr Jefyll wrote:

Or, a rather different approach. Can the desired connections be manually established with just a dab of solder? You'd need a clever pattern [...]

barnacle wrote:

I think you could easily define such a footprint, but you would need to be careful about defining the solder resist...

Yes, it's this business about managing the solder resist which is outside my ken. I'm sure the desired deviousness is possible but what I don't know is how well it's supported by the various CAD programs and the various PCB fabs. (Ditto for my questions about vias in four-layer boards.)

FWIW, here (below) is my first pass on (just for example) a SP8T switch. Either...

• - a dab of solder would manually be placed in such a way as to connect one of the two center terminals to one of the eight surrounding pads, or...
  - that same connection would be ready-made as a slender copper trace, removable if so desired by use of a Dremel or X-acto knife.

Of course the opposite side of the board has eight traces running vertically (attaching to the vias, which I've drawn as yellow donuts).

SP8T switch (one).png (6.39 KiB) Viewed 977 times

The second image shows a space-efficient way of packing multiple switches together. As you can see, they're compressed in the vertical dimension because each row of pads serves both the switch above and the switch below.

It goes without saying that there will be a LOT of vias. And IIRC, Express PCB charges extra for that sort of thing. Is this common? Will via cost be an issue?

-- Jeff

ps- I think the density could be doubled by using a four-layer board with switches on both sides.

[barnacle]

Curse this non-linear thinking! At least we find things like this before ordering any PCBs... you are of course correct. The culprit in this case is that handy '8' line that provides a multiple routing.

Redrawn to reflect the pcb layout, it's clear that the '8' line is providing a convenient short circuit where we don't want one... it could be fixed with two diodes per hi-Z output, I think; one to the 0-7 lines and another to the 8 (and of course two more for the high order nibble).

It might be simpler to extend the encoder to sixteen bits; we could live with twice the density of vertical lines. But that's three chips per nibble. And we'd still need the diodes for the other nibble. Damn.

Re vias: there is no charge for vias on JLCPCB though most houses used to charge for them. I suspect they use lasers to make the holes these days rather than breaking drill bits, but I don't know. My diode boards were the same cost as the Mesolithic due to size, even though they have about 1100 vias.

Neil

edited via count. It's one per diode, plus the other random connections.

[barnacle]

It turns out that diodes, even in double packs, take up more space than an equivalent SOIC-24, so this version eschews diodes completely (they come in 8-packs too, but I'd still need an awful lot of them, and they're a couple of bucks each, which is just silly) and use separate 4067 multiplexors for each nibble. Still definitely read only, but can take 128 bytes.

(Power, decoding, decoupling, and the actual connection to the main board aren't drawn yet, but I see no lack of space for them.)

muxprom2.pdf

(382.2 KiB) Downloaded 29 times

Columns are hi-Z outputs which pull low, rows are logic inputs pulled high. The high and low nibble are completely separate, so no nasty backwards routes. I hope.

Neil

[barnacle]

So, it turns out that fitting all the diodes is very very tedious - pretty much all day to get half of them installed on one side, so far. Not helped by the facts that (a) the diodes I ordered for some reason didn't match the footprint I expected, so they're a bit tricky to get in position, and (b) the diodes are marked with very dim laser marks. It's taking a microscope to check the orientation of each diode.

Neil

[barnacle]

I think I may build this one up; soldering all those diodes is a pain and once the code is working, it will never change.
Separate columns for the high nibble and the low nibble are driven by the multiplexers which allows only one column to be low at any time; the other outputs are all high impedance (though there are multiple pins connected in many cases, there is no back-path because of the hi-Z outputs). Pull-ups hold the unselected bit rows high and two row encoders convert that to a four-bit nibble.

128 bytes, using eight address bits with add7 required to be high (easy to change). I _believe_ it might be possible to squeeze more on, with smaller packages, but this seems a reasonable compromise between legibility and space.

The multiplexers are under fifty cents at LCSC and the board would be about two dollars (though generally you'd need five) at JLC.

Neil (now back to soldering diodes...)

[Dr Jefyll]

The new design looks pretty tidy, Neil. But, as always, you can rely on me for a steady stream of nit-picking and background noise!

Can I suggest you omit these fills? I mean all fifteen of 'em between the bit lines, and the same in the other section. They make the actual bit lines harder to see, and -- more importantly -- harder to cut. I know it may be difficult to understand why anyone would wanna modify the ROM, but IMO novices should be allowed to tinker, as it can be an important part of how they engage.

Quote:

The multiplexers are under fifty cents at LCSC

I'm surprised. Is the price similarly low at Digikey and Mouser, for example? Although I'm the one who suggested those multiplexers, I can't help wondering if your original plan to use '154 decoders might be better. I suspect the 154's are more widely available than multiplexers (and in many cases more cheaply). Moreover, a person will only need half as many.

Yes I'm wandering back into diode territory, but the scheme I outlined in this post is fairly workable. Because it uses 3-pin diode arrays, the diode orientation can't be mistaken. And it's not that much more soldering. For each group of sixteen bytes, ...

• - the multiplexer approach requires soldering two 24-pin multiplexers
  - the '154 approach requires soldering one 24-pin '154 and sixteen 3-pin diode arrays.

-- Jeff

[barnacle]

Pick away, pick away. The fills come free of charge when I push the 'b' button in Kicad; my usual habit is to have a ground on the top plane and a Vcc on the bottom, and that's the case here.

The two times sixteen row lines on the top should never be cut anyway; any change would be on the back; probably a partial drill to remove the back of the via and disconnect the line, and a bodge wire (on the top) to the appropriate row input. But the idea for this one is a get you out of jail card for the Mesolithic (or anyone else who wants a 128 byte rom).

Digikey has the multiplexers with 11k in stock at 56 eurocents (also from TI) for single units. TI hc154 are 62 eurocents, but you only need half as many. The snag was that the diodes took up more board real estate space than an extra 24-pin soic - though to be fair, space isn't a big problem here.

However, the big advantage with this board is feeding the two nibble rows from top and bottom gives a very clean and obvious layout. I'm not sure if something could be done with the diodes to split into two halves, as it were... though to be fair, the PCB doesn't _have_ to match the drawing layout!

(Warning: big A2 pdf):

muxprom2.pdf

(929.63 KiB) Downloaded 59 times

Meanwhile, I've finished soldering diodes to the original diode design. Still some components to fit; pullups and decoupling, then I toss up whether to test it on a breadboard or just stuff it onto Meso. But for tonight, my eyes are on strike.

Neil