From the sublime to the ridiculous - 8-byte PROM

[BigDumbDinosaur]

barnacle wrote:

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

I remember hearing something to that effect back when dirt was new.    If anything, it’s truer today than it was in the late 1960s when I was getting comfortable with digital electronics.  Switching speeds have significantly increased, making the effects of parasitic capacitance more onerous.

Quote:

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

...especially around Australian beaches and in the Caribbean.  Several times I saw sharks up close when I was in the Navy.  It’s pretty impressive when one smiles at you. 

[barnacle]

So, progress... I changed the 10k pull-up resistors to 1k, and with the ROM plugged via an adaptor into the EEPROM socket, here's what I see:

Which is a lot better than yesterday.
However, it's running but not quite correctly: the display is multiplexing, the keyboard is being read (and stopping the multiplex until it's released, as expected) but (a) the initial display is incorrect: $F7F6 instead of $0200, and (b) no change when the keys are entered in the displayed memory address. Also, it doesn't reset _every_time; sometimes it locks up instead of running.

It's probably expected that the data doesn't change; the data is built a nibble at a time directly into the memory being addressed, and there's nothing there but the ROM (and the data at $FFF6 is in fact $77, which is what I see).

So my suspicion is either that it still isn't _quite_ fast enough (though it looks as if it should _just_ work at 1.8MHz) or that dropping it into the EEPROM socket has an effect I haven't considered. I can't (yet) fit it to the connector intended for it as I have now added a ~OE input to the rom which I haven't looked at Mesolithic to see what I can use.

But we're getting there. The joy of bootstrapping: which bit is not working?

Neil

[barnacle]

It's been a bit busy of late, but I got a chance to have another look at the issue.

To reiterate: Paleololithic produces the correct outputs depending on address, ~CE, and ~OE. However, it doesn't start if its in the socket I designed for it... so roll back one, try it in the EEPROM socket instead. Where it _mostly_ works, but doesn't appear to talk to RAM correctly. It doesn't reset every time, and when it does it looks as if it's working - multiplexing the display correctly, though with the wrong programming address displayed, and no change occuring to it.

I grabbed some data using a Saleae logic sampler; it is reading the data after reset as expected and apparently writing it (though for some reason there's a 110ms delay between the logic analyser seeing the reset line going high and the reset happening. Expected values are appearing on the data bus as the processor writes to RAM or the display. Reading from the keypad appears to be correct.

Code: Select all

80
FF		reset vector read
A9
02		lda #$02
85
FF		sta 0xFF
02		memory write
64
FE		stz $FE
00		memory write
A0
05		ldy #5
B9
F6
00		lda leds,y
F7		memory read
99
F8
9F		sta led_address,y
F7		memory write
AD
FF
9C		lda keys (expected AD FF 97)
9C		memory read
30
29		bmi update_leds
C9		memory read?
A2
00		ldx #0
A5
FF		lda $FF
FE		memory read
20
D2
F4		??? 
FF		jsr to_leds
C2		return address write to stack
FF		return address write to stack
5A		phy
48		pha
05		write y to stack

I think I've got some memory contention going on. The EEPROM is controlled by ~OE, ~CE, and R/~W; and this latter is not getting to Paleolithic; not enough wires. I'll have a look at that next. My suspicion is that for whatever reason addresses xx80 to xxFF are being overwritten by the DROM.

Neil

[barnacle]

Update: Dr Jeff asked me to point out that there is a possibility of confusion in this project, since it's spread over a couple of rather long threads. Hopefully this will summarise what's been going on.

• In the beginning was a quick design for a diode based PROM. That's at the start of this thread. That evolved over a number of iterations to two final candidates: one using individual diodes per bit, which doesn't work for reasons not yet thoroughly explored (but possibly I've soldered 509 diodes the wrong way around!), and the current version based on a suggestion from Jeff which uses 74hc4067 analog switches to pull one-of-n lines to ground. The grounded line goes to a diode encoder to produce (two) four bit nibbles. This version provides 128 bytes of program space.
• Having an eprom, I needed something to drive with it. That's the Mesolithic SBC, to be found in all its gory details here: viewtopic.php?f=4&t=8383
  The topic also includes development of the 127(!) byte VBIOS - very basic input output system, which manages the LED and keypad multiplexing, and allows the user to write and execute a program starting at $0200, and with a little gymnastics, write to the EEPROM.
• One of the aspects of Mesolithic is the inclusion of a socket to interface the DROM, with some logic selection so EEPROM at the same address can be written but not read when a link is in the right place.
• With the VBIOS blown into the appropriate bit of the EEPROM, everything so far tested is working as expected (VIA and UART as yet untested). However, as mentioned in the last post, while the stand-alone Paleolithic provides the expected outputs, it doesn't work at all when plugged into its socket. With an adaptor to fit the EEPROM socket, it sort of works; see above.

So that's where we are at the moment.

Neil