From the sublime to the ridiculous - 8-byte PROM

[barnacle]

After much playing around, I have been unable to arrive at a solder-bridge arrangement that is both big enough to be able to solder safely and small enough to fit on a eurocard. That would have allowed a fully programmable and alterable ROM, but even the best designs I came up with were significantly longer than my preferred Eurocard size (160x100mm).

So I've just ordered a fixed ROM with the VBIOS program built in. It _is_ modifiable, with scalpel and bodge wire, but it's not easy and certainly not for the whole board. All the parts are on the front side; it uses Jeff's diode binary encoder just for fun

Neil

[BruceRMcF]

How many bytes is VBIOS again?

[barnacle]

One hundred and twenty-seven... and for all its limitations, it works remarkably well.

Neil

[BigDumbDinosaur]

barnacle wrote:

One hundred and twenty-seven... and for all its limitations, it works remarkably well.

127 bytes spread out over that much board space makes you better appreciate how dense the storage is in even a small EPROM.

[barnacle]

To be fair, there's another byte that's there but unused bringing the grand total to 128

On the other hand, I just discovered an error in the circuit diagram from which I built the boards I received today: instead of using inputs for four diodes of bits 8-11 for some reason I chose to use 9-12. D'oh. At least its a single cut'n'bodge.

Neil

p.s. the boards look nice though. But I don't have the diodes yet.

[barnacle]

A reminder to myself... next iteration moves all four inputs to D7 and D8, just to be tidier.

Neil

[barnacle]

My components made it here from LCSC. After replacing a dead diode (and the cut and bodge wire fitting) the diode network gives the expected outputs. Which is nice

Now let's see how the rest of the board is working!

Neil

[barnacle]

Well, that's either good news or bad news, and I don't yet know which...

Every location in the ROM returns the correct value, as tested using the 'orrible proto board and a pencil. Which is good. But it doesn't do anything exciting when plugged into Mesolithic... so either:

• the response time isn't as fast as it needs to be (seems unlikely)
• the addressing logic on Mesolithic is not as it should be
• the addressing lines to the extension socket are incorrect
• ...other...

Next step is to make a header so it can plug in to the EEPROM socket - I know that the code and the EEPROM both work correctly, at least as far as reading data goes.

Neil

[barnacle]

And using it through the header, it still doesn't work. Further investigation is required.

Neil

[barnacle]

Well well well...

This is the start of the program when executing (correctly) from the eeprom: code starts at the symbol values 0x0080, 0x00FF (followed by A9,02,85,FF,64,FE...)

On the other hand,

shows the rom executing from the eeprom socket. It works perfectly for the first three bytes and then it curls up and dies. Something is being thumped somewhere.

(I also have a concern that I'm reading the wrong edge, but the other edge doesn't give consistent results so I probably am; I can never remember which way up ph0 should be )

Neil

[gfoot]

It's best to sample around the falling edge of the clock - that's what the MPU does, and that's when data written by the MPU is finalised - but really it depends how your circuit activates your "PROM", as if you're activating it (CS, OE, etc) before the clock rises then of course you can sample there instead.

Have you considered "plugging it in" to something like the TL-866II or similar EEPROM programmer? They can also read ROM contents so it might be a more convenient way to debug it.

Edit - it is possible the CPU is entering an interrupt sequence, which can happen spuriously if there are power supply problems (e.g. brownouts or brief power losses so it comes back without a clean reset). Looking at VPB and maybe RWB might give some indication. The "84 FF" could be the CPU attempting to push the PC to the stack for example.

[barnacle]

Well, I suddenly realised that I had not include an ~OE input to the ROM. Fortunately I had a spare pin on the connector and a spare active low input on the address decoder... Unfortunately, things got worse, not better.

I'm wondering again about timing; maybe the ROM is just too slow to operate? I can easily use a Nucleo and clock it at any old rate, but tomorrow: right now we're on our way to see a show: https://www.musical.berlin/en/musicals- ... sical.html (link may be considered slightly unsafe for work, depending how puritanical your workplace is).

Neil

[barnacle]

Hmm.

I am not totally sure what's going on here... the blue trace is ph2 in, the yellow is one of the bits output from the diode encoder, as it enters the output '541
The initial drop to LOW looks about as expected; the multiplexer has an internal delay of 50-60ns, plus however long it takes an HC139 to decode. Call it something under 100ns. (Ignore the edge spikes; that's poor earthing on the scope).

But the return to HIGH takes at a conservative estimate 1us, maybe more. Which means that sometimes the 'next' read should be HIGH but is still reading LOW, perhaps.

The datasheet says the BAT54A has a diode capacitance of 10pF, each output line is pulled up by 10k and connected to eight diodes, so 80pF. Which gives a time constant of, um, 800ns; that's to 60% of the rail so marginal even there.

Looks like I need some smaller resistors...

Neil

p.s. driving the address, ~oe and ~ce inputs using a nucleo and reading the outputs show everything fine, but because of the time taken to output the values (serially) it's a few milliseconds cycle time, so it of course reads everything perfectly.

[BigDumbDinosaur]

barnacle wrote:

Hmm...the return to HIGH takes at a conservative estimate 1us...Which gives a time constant of, um, 800ns...Looks like I need some smaller resistors...

“You’re gonna need a bigger boat.” 

Uh...I think I may have said something about resistor values many posts back. 

[barnacle]

True, but we were considering them in the context of too much current overloading a '154 that was sinking current... everything's either too much or too little in this game. Though I have to admit I didn't really consider the capacitance of the diodes, and to be honest, never have except when looking at using them as variable capacitors.

Today's lesson: everything is analogue, even digital.

dum dum, dum dum, dum dum dum dum dum dum dum dum... "Shark!"

Neil