Tracking Down a RAM Issue in a VT100 (how does the 2114 chip work?)

[rjarratt]

I have a non-functioning VT100. I think it is failing in the POST during the RAM check. I don't know for sure because I can't get it to light up the LEDs on the keyboard, however I used my logic analyser (a HP1630G) to see what values were written to the UART to send to the keyboard and I see it sends the values FF then 1, 2, 3, 4 and finally 5. The last value corresponds to the RAM test so I am fairly confident the RAM test is what is failing.

I have disassembled the VT100 ROM and if I have understood it correctly it zeroes out the RAM (high address to low) and then for each address (low address to high) it tries first to read back the zero and then writes 0xAA to the location and tries to read that back.

I am also confident the 8080 is working OK because I was able to capture an address trace on the ROM that showed it executing the program as per the disassembled ROM.

My problem is getting the logic analyser reliably to tell me how each RAM chip is being addressed and what data is being read or written. I am seeing strange values for the addresses (sometimes) and I am not sure I have setup the logic analyser correctly. I have read the datasheet for the 2114 chip and I am not entirely clear that I have understood it correctly. Here is how I have set it up:

• Trigger on the -ve edge of Chip Select (pin 8)
• Capture A9-A0 as the address
• Capture WE as an indication of Read or Write

The timing diagrams show the write cycle where the WE signal and CE signal seem to transition at the same time and the data may be only valid a bit later than the CS -ve edge. But this may just be me not knowing how to read the datasheet. Using the +ve edge of CS seems no better.

Is there something I am missing about how to analyse how the RAM chips are being used?

 

[Uniballer]

I think I last built something with a 2114 in 1983. Maybe 1984.

The RAM write cycle ends when either CS- or WE- rises (whichever comes first). Data must be valid for at least the data hold time interval after that, tDH (0?). I would first run the logic analyzer asynchronously to see how a write cycle is done on that hardware, then trigger for data capture based on what I learned.

The exact hardware in front of you might help you. Do you have a schematic? Do you really understand it?

 

[rjarratt]

Yes the VT100 printset is available so I have the schematic. I did try triggering on the rising edge of CS, but perhaps I just need to trigger on WE too. Not sure my analyser can trigger on the first of those rising, I think it is a simple OR. I will see if I can do that, otherwise I will look at either capturing the timing or consider analysing the 8080 itself instead.

 

[AK6DN]

This may help, 2114 data sheet attached.

Unfortunately CS~ does not have to transition for every read; just change the address and tACC later the data lines reflect the read data.
CS~ rising would be a good trigger for ADDR and rdDATA if it rises; but it does not have to. Depends on the logic design.
For writes, WE~ rising is the best trigger for ADDR and wrDATA sampling.

 

[rjarratt]

Thanks for the datasheet, it is a better quality version of the one I already have. I think I may start by just capturing the writes. If I can see the increasing addresses writing the 0xAA pattern stopping at a particular address I think that may tell me which pair of chips has a bad chip.

 

[Eudimorphodon]

The 2114 is pretty much your run-of-the-mill bog-standard SRAM, so I'd say your scheme:

• Trigger on the -ve edge of Chip Select (pin 8)
• Capture A9-A0 as the address
• Capture WE as an indication of Read or Write

is correct so far as it goes. IE, in the 2114 the row/column selects are constantly following A0-A9 to select which four memory cells would be affected by a read or write; nothing will actually happen on the data pins (IE, they'll be in Hi-Z state) unless /CS, with or without /WE, is asserted:

* /CS without /WE sets the direction of the data lines to "output" and the contents of the addressed memory cells are asserted, while
* /CS *with* /WE sets the direction to "input" and state of the data lines asserted by the master device will be read into the cells.

It looks like here some of the are the "subtleties" to be aware of:

* Per @AK6DN's comment, you may not necessarily have a /CS transition between each read by the controlling device; it's valid behavior for reads to just hold down /CS all the time, the output data will follow changes in the address lines. The trick here is the data will only be "valid" X-many-nanoseconds (where "X" is the rated access time of the chip) following each change, if you sample too quickly you might get garbled data.

* Addresses should *not* change once /CS+/WE is asserted until at least one of them is de-asserted. The chip doesn't "latch" writes, the contents of the data lines basically "soak" into the selected cell during the period where both /CS and /WE are held down, so if you change addresses while /WE is asserted you may damage the contents of cells other than the one you're intending to change. (I think this behavior might be different on some other SRAMs, IE, they won't actually change the contents of any cells until /WE transitions back high?)

* The datasheet suggests that the master that's asserting the data bus during a write shouldn't do it *immediately* when the write cycle starts, because the chip may take some time switching the direction of its data pins from outputs to inputs. In theory that could mean you'd have the SRAM the device driving it briefly "fighting" with each other that the start of a write cycle if the data was already asserted when you triggered /CE and /WE together.... but one of the two datasheets I'm looking at seems to suggest this direction-changing proviso might only apply if /CS were held *before* /WE transitions low.

* EITHER /WE or /CS coming up terminates a write cycle. @AK6DN is in most cases correct that sampling the data pins on the rise of /WE with an analyzer is probably the most likely to give you the data being written to the chip, but it's at least *possible* in some weird edge case you might have a circuit that holds down /WE and just toggles /CS up and down. (That would be sort of dumb, granted.)

So with the above in mind:

The timing diagrams show the write cycle where the WE signal and CE signal seem to transition at the same time and the data may be only valid a bit later than the CS -ve edge. But this may just be me not knowing how to read the datasheet. Using the +ve edge of CS seems no better.

If you're consistently seeing /WE and /CS transitioning in lockstep with each other then, yeah, sampling data with either one goes high should give you what was written. Data might not be valid (in fact the datasheet suggests it *shouldn't* be valid) when they transition low.

Regarding this:

My problem is getting the logic analyser reliably to tell me how each RAM chip is being addressed and what data is being read or written. I am seeing strange values for the addresses (sometimes) and I am not sure I have setup the logic analyser correctly.

Are these periods of "strange addresses" periodic? Reading the manual for the VT100 it looks like it uses the same RAM for both video memory and CPU scratch space, and how video refresh works is once for every line of characters (IE, once every ten CRT scan lines) the video hardware does a DMA cycle that locks out the CPU and reads the characters for that line into a buffer RAM that's used for the intervening scanlines. Are these "strange values" episodes periodic and the addresses during them rapidly incrementing? Maybe you're seeing the refresh cycles butting in.

(Of course my assumption is you'd never see /WE low during these events...)

 

[rjarratt]

Thank you for the detailed reply. For some reason I didn't get notified of your reply (pretty sure other replies sent me a notification), so I only just noticed this. I think my best bet for checking what is actually being read is to check the schematic for any signal to say that the data being read is valid and to capture that. I guess the 8080 must get told, but I haven't looked in detail at the 8080 datasheet yet.