Hi everyone!

Recently, I've been trying to bring an old computer back to life. Because of it's age, I'm worried if the EPROMs (two) that store the OS and interpreter still have it's data in original state. The ICs are about 23 years old, and one lost the quartz window protecting stick 10 years ago. It hasn't been exposed to strong sunlight or any light at all, but it may be compromised.

The ICs are HN482764G = 2764. Since I don't have an EPROM Reader/Programmer, I implemented a reading device using an AVR.
I just did some hacking on my breadboard, so I did a quick sketch of the schematics to attach here. As you can see, what I've done is wire my EPROM to AVR ports and carefully handle the communication by toggling it's control lines and clocking the 4040 to drive the address lines.

The AVR I'm using is a AT90USB162, mounted on a mini dev-board. The one on schematics isn't the correct part, as KiCAD doesn't have it. But it's the same thing concept-wise.

It's seems I've succedded to some extent. I can sample my AVR ports that are wired to the output pins of the EPROM and get the data back (and then send by USB, as a CDC serial device to my PC).

The problem is that my readings aren't reliable. If I try to read the same address over and over, I get two (sometimes three) different values.

I thought it would be a timing problem, but I tried increasing the delay between various steps in the communication (like the delay to gate data out after pulling G (output enable) low). I even tried something like 1 ms, that's way longer (and more safe) than the specified in datasheet (in nanoseconds). No success.

Does anyone have an comment or suggestion on what's going on? Mostly a timing problem? I've been wondering if I need to pull-up the data lines.

Maybe my EPROMs are so old that the data is trashed. Or the ICs are faulty. I've tried with both EPROMs and they have the same behaviour.

Or even worse: maybe I'm completely off with my schematic/code/ideas!

If anyone have some words to share about it, I would be very grateful! If more information is needed (like the AVR code), please tell me, I'll promptly reply!

Thank you very much for your time.

Best regards.

 

One thing to check is whether you are observing the setup and hold times.

hgmjr

 

Hi,

Here is the relevant code snippet that actually setups and read data from the EPROM. I've changed some of the code to make it a bit more readable:

#define CLK_4040     PB1
#define RST_4040    PB2
// OE_2764 = Output Enable (G) on 2764
#define OE_2764        PB0
// CE on 2764 is permanently low.

DDRB = 0xFF;
PORTB = 0xFF;

DDRD = 0;
PORTD = 0;

// Set reset line of 4040 to low, unfreezing it.
PORTB &= ~(1 << RST_4040);

// Timer1Val = 16 bit timer on TCNT1, to read bytes off 2764 slowly.
// It yields a delay of 320 ms between reads with current setup.
if(Timer1Val > 10000) {

    // Take CLK line of 4040 high
    PORTB |= (1 << CLK_4040);

    _delay_us(2);

    // Set OE low to gate out data.
    PORTB &= ~(1 << OE_2764);

    _delay_us(2);

    // Sample data from EPROM.
    data = PIND;

    _delay_us(2);

    // Set OE high, disabling I/O pins
    PORTB |= (1 << OE_2764);

    // 4040 increments on falling edge.
    PORTB &= ~(1 << CLK_4040);

    Timer1Val = TCNT1 = 0;

    // Put byte to buffer and send back to host.
    sendData(data);
}

As I've checked on 2764 datasheet, for example, the maximum time between the OE going low and the data being valid on it's output (tGLQV) is 100ns (for my part). I'm waiting 2us, so is more than enough. This would be my hold time, right? With 2us I cover all needed max times and 4040 propagation on worst case. (+5 V)

As for the other time parameters, all are in the nanoseconds range. In my code, I'm waiting 2us for all operations, so I think I'm ok. CE wouldn't be a problem, as it's tied to ground.

Am I doing something "nonsense" with my timing?

Also, I have a 2764 and not a 27C64. That means I have a NMOS part. Would that make any difference?

Thank you, please let me know if more info is needed.

Best regards.

 

Have you tried reducing the number of bytes you read to one or two to see if this reduce reads are consistent?

For example read the first two bytes and see if that is stable. Then gradually increase the number of bytes you read until you encounter a read error.

hgmjr

 

Hi,

Yes. One of my tests was exactly that.

Like I said, even if I tried to read the same address over and over, I got two or three different values. One would repeat more than another, so that would be a clue that byte is the correct one, the other are spurious.

Also, restricing my reading range to two bytes, for example, would lead different results in the same line of a single byte reading.

Thanks!

 

Try writing all ones to PORTD. This will turn on the internal pullups on the inputs to the AVR device. Even though you have PORTD configured as inputs you can write ones to PORTD.

hgmjr

 

Here is an excerpt from the datasheet on the ATTINY2313A that describes how to configure an AVR's input port to enable the internal pullups on the input port. Paragraph 3 in this excerpt is the one to which I am referring.

hgmjr

 

It's pretty simple. There are three registers for a port
PORTx PINx and DDRx.

DDRx determines the input or output state of the IO port 1 is output 0 is input
PINx is the direct logic state from the IO port comparator (this can even be read when the port is set to output to determine short circuit or pin overdrive conditions)
PORTx is dual purposed when DDRx is 1 then PORTx will determine which rail the output pin is driven to. When DDRx is 0 then PORTx will determine weather or not the pullup is enabled on that IO line, I think it's 1 for on 0 for off.

Many AVR's also have a little known feature, where if the PINx register is written to it will toggle the I/O port state of an output without having to read it first.

 

Hi,

Thanks for your reply.

I've tried with both internal pull-ups and external ones. Now my results are more stable. Except for some bytes at fixed locations, all other bytes are being read the same when I sample the same location. Here is a example of data output with pull-up. They are the first 16 bytes, being sampled again at each line:

Sorry for posting an image, GtkTerm wouldn't let me copy it as text.

Just some bytes at specific position does varies over time. This is even more strange now.
The difference in two varying bytes is always 2. Maybe my 2764's Q1 line (bit 1) is faulty? But the first byte (0x0B), for example, is 1011 in binary, so it uses the bit 1.

Any ideas?

Thank you for your time!

 

How are you transmitting the data from the AVR to the output host?

hgmjr

 

Sorry, I just reread you original post and I see you are using the USB port to transmit the bytes read.

hgmjr

 

Perhaps there is a bit of ringing on the data line. Are you using bypass capacitors on all of your devices?

Also make sure that you have healthy ground connections.

hgmjr

 

use your electronic reasoource capacitors do not cau's ringing ( neglecting long leads ) Inductance doe's, or long leads( cables ). most systems are quite forgiving, but dont push over the 10 -20 % line

 

I was trying to confirm that tripleoxygen had included adequate bypass capacitors on each of his devices. You are are correct that ringing is typically associated with unintended inductance in the circuit.

hgmjr

 

I mfg. a piec of equip. about 20 years ago, and the piec of EPROM was 2916. they are starting to come back, the originial data embeded was coorrupt, so I sent a new one, any thing that old probably has wrong data,sorry.

 

Reconfigure, your outputs to pull downs, It's called an inverter,all these chips are for PULL DOWN ONLY THats why they say " weak pull ups " usualy under 10 K, when you have 20 ma. pull down why not re design for that !

 

Old 2716 2764 ect are unreliable after 20 years, you can erase them and re-install the old software if you wish, but it's unsafe at best, the tech. At that date was only guarn. For 20 years. Good luck.

 

Hi,

Thanks for your reply.

I've tried with both internal pull-ups and external ones. Now my results are more stable. Except for some bytes at fixed locations, all other bytes are being read the same when I sample the same location. Here is a example of data output with pull-up. They are the first 16 bytes, being sampled again at each line:

Sorry for posting an image, GtkTerm wouldn't let me copy it as text.

Just some bytes at specific position does varies over time. This is even more strange now.
The difference in two varying bytes is always 2. Maybe my 2764's Q1 line (bit 1) is faulty? But the first byte (0x0B), for example, is 1011 in binary, so it uses the bit 1.

Any ideas?

Thank you for your time!

What size external pullups did you actually end up using?

hgmjr

 

Hi

Thanks everyone for the input!

@hgmjr

Yes, I'm using LUFA to create a virtual serial over USB.

As for the externals pull-ups, I used 4.7k resistors.

@hgmjr, knowitall

No, there are no bypass capacitors in my circuit. My setup is exactly like the schematics except that my AVR is a mini-dev board. Should I give a try? How many and of which value should I use (just need to tie it to my power lines, right?)?

@knowitall

Yes, data integrity was one of my main concerns. Unfortunately, I don't know anyone who owns the same computer to get a copy, except for a guy in another city that's currently selling it. I'll buy it anyway, if I indeed have a bad IC or it's data were compromised, I can try dumping data from it. But it's probably of the same age as mine, so if it's data is also corrupted, I'm like running out of alternatives.

I'll give a try with both pull-downs and bypass capacitors.

Thank you very much!

http://forum.allaboutcircuits.com/member.php?u=2236

 

Typically, you will place a 0.1 uF at a voltage rating of greater than 25V on each of the devices from the power pin to the ground pin. You will also benefit from adding at least one 1 uF electrolytic capacitor or greater value that is rated for a voltage that is 10V or higher across the 5 Volt power supply.

The 4.7K resistors should be a comfortable value since the 2764 is rated to sink something in the range 2 milliamps on its outputs. You can go as low as 2.7K but I would not go lower.

hgmjr