• Please review our updated Terms and Rules here

Flakey eprom?

M

mark0x01

Experienced Member
Joined
Oct 31, 2015
Messages
219
Location
Kaiapoi, New Zealand
Just how flakey do eproms get ?

I have a Televideo TS 803 giving issues.
A datalog capture (on the CPU pins) shows that particular instructions being read are occasionally corrupted in bit 0 & 1 if my interpretation is correct.

For some reason it seems just two instructions are frequently corrupted in the trace I have checked so far.

I suppose it could be the logging is bad, but the systems behaviour is very inconsistent on each reset, including random screen horizontal doubleups (two identical images)
The initial fault was failing memory test, and infrequent screen display - either nothing at all or working.
The memory was tested & socketed.
The fault then moved to failure at the floppy diagnostic, although the drives tested ok.
They should home, step out and back, but didn't.

I was using the data logger to see what was happening and this result was unexpected.

I have now programmed two spare eproms to try after multiple verify's of the origional were consistently good, so hopefully these are ok.
If that doesn't work, then things get a bit harder and replacing chips along the path will be next.

sample from Pulseview decoded as Z80 compared to disassembly of eprom (using ghidra and a lot of editing)
The code loops as it is doing a ram test which is how I spotted the discrepancy.

44807-44817 Z80: Instructions: JP NZ,02DAh
44817-44823 Z80: Instructions: INC HL
44823-44827 Z80: Instructions: LD A,H
44827-44831 Z80: Instructions: OR L
44831-44841 Z80: Instructions: JP Z,0053h
44841-44854 Z80: Instructions: DJNZ $-11
44854-44859 Z80: Instructions: LD A,(HL)
44861-44865 Z80: Instructions: CP B
44865-44875 Z80: Instructions: JP NZ,02DAh
44875-44881 Z80: Instructions: INC HL
44881-44885 Z80: Instructions: LD A,H
44885-44889 Z80: Instructions: OR L
44889-44899 Z80: Instructions: JP Z,0053h
44899-44912 Z80: Instructions: DJNZ $-11
44912-44917 Z80: Instructions: LD A,(HL)
44919-44923 Z80: Instructions: CP B
44923-44933 Z80: Instructions: JP NZ,02DAh
44933-44939 Z80: Instructions: INC HL
44939-44943 Z80: Instructions: LD A,H
44943-44947 Z80: Instructions: OR L
44947-44957 Z80: Instructions: JP Z,0053h
44957-44970 Z80: Instructions: DJNZ $-11
44970-44975 Z80: Instructions: LD A,(HL)
44977-44981 Z80: Instructions: CP B

....
45295-45305 Z80: Instructions: JP Z,0053h
45305-45318 Z80: Instructions: DJNZ $-11
45318-45323 Z80: Instructions: LD A,(HL)
45325-45329 Z80: Instructions: CP C C should be B ?? bit 1
45329-45339 Z80: Instructions: JP NZ,02DAh
45339-45345 Z80: Instructions: INC HL
45345-45349 Z80: Instructions: LD A,A A,A should be A,H bit 0+1
45349-45353 Z80: Instructions: OR L
45353-45363 Z80: Instructions: JP Z,0053h
45363-45376 Z80: Instructions: DJNZ $-11
....
45339-45345 Z80: Instructions: INC HL
45345-45349 Z80: Instructions: LD A,A
45349-45353 Z80: Instructions: OR L
45353-45363 Z80: Instructions: JP Z,0053h
45363-45376 Z80: Instructions: DJNZ $-11
45376-45381 Z80: Instructions: LD A,(HL)
45383-45387 Z80: Instructions: CP C C should be B ?? bit 1
45387-45397 Z80: Instructions: JP NZ,02DAh
45397-45403 Z80: Instructions: INC HL
45403-45407 Z80: Instructions: LD A,A A,A should be A,H bit 0+1
45407-45411 Z80: Instructions: OR L
45411-45421 Z80: Instructions: JP Z,0053h
45421-45434 Z80: Instructions: DJNZ $-11
45434-45439 Z80: Instructions: LD A,(HL)
45441-45445 Z80: Instructions: CP C C should be B ?? bit 1
...
45745-45751 Z80: Instructions: INC HL
45751-45755 Z80: Instructions: LD A,A
45755-45759 Z80: Instructions: OR L
45759-45769 Z80: Instructions: JP Z,0053h
45769-45782 Z80: Instructions: DJNZ $-11
45782-45787 Z80: Instructions: LD A,A
45789-45793 Z80: Instructions: CP E E should be B - bit 0+1
45793-45803 Z80: Instructions: JP NZ,02DAh
45803-45809 Z80: Instructions: INC HL
45809-45813 Z80: Instructions: LD A,A
 
After a long period of time EPROMs start to drop bits.

Before they go permanently faulty, they go intermittently faulty. The bits can change state depending upon environmental factors (e.g. voltage variations, temperature, electromagnetic fields - and even light).

Dave
 
If you continue your analysis you should be able to see that certain bits are sometimes reading as '1' and sometimes as '0', while the rest will always read a consistent '1' or '0'. This comparison will be much easier to make if you compare the content, read many times, as hex rather than looking at the differences at disassembly level.

Once you have identified which bits are sometimes reading high and sometimes reading low, try programming another EPROM with the code with those few 'variable' bits set low.

If you get lucky this will result in a 100% correct EPROM. If you are unlucky there are already some '0' bits which have 'faded' to the extent that they already consistently read '1' instead of the original '0'.

I can't stress enough how important it is to read and save file copies of the contents of EPROMs while their content is still 100% good. After doing so you can then (optionally) over-programme the EPROM with the same code. That will set the 'data fade' clock back to zero and they should be good for another 40-50 years.
 
An excellent tip to remember.
There are plenty of dumps in the usual archives for many systems, but for some reason I seem to collect systems with eproms that aren't usually there :(

I did find a dump for the TS308, but it is different to the version I have. It is part of the mame emulator set for a TS803H and I successfully ran the emulator with it.

I have now erased and programmed a replacement 2764, which seems to have fixed the flakey bit issue, but not the floppy issue.
I also tried a replacement 1793-2 which makes the floppy return to track 0, but not seek, so fails still.

I'll try some manual toggling of the driver logic chip with the 1793 removed and see if it will make the floppy step.
 
Another tip: EPROMs can become slow. I had an Elektor Junior, a kind of Commodore KIM clone, that didn't start up. Using my Debugger and running the program step for step, things went fine. But when trying to skip a subroutine or a loop, The KIM just stopped. I programmed another EPROM and things went fine.
I kept that EPROM and some years later I could lend a Logic Analyzer. That's how I found out that from the start on the EPROM didn't output all bits correctly. Even weirder, which bits weren't outputted correctly differed every run.
 
It looks like the origional eprom code is indeed bad, as a reprogrammed one still fails.

The alternative eprom image passes the diagnostics, but it still has a display issue and although I get the correct boot message, it doesn't boot, but that might be my floppy disk, as I haven't a known good PC controller yet.
I used Imagedisk and the same drive to make it, and it didn't report errors when creating the disk.

Origionally the display only appeared intermittently and was normal, but now, and only when the brightness is wound right up, I see the display as a narrow band.
The character size looks correct, and text is wrapped, although some is missing off the sides.

Time to check the line frequency.

Unfortunately I don't have a spare SY6545 CRT Controller to try, so have I just ordered one.

I think this machine has aged about as well as me over the years.
 
Going back to what Ruud said about EPROMs becoming slow, I wonder if one possible line of attack would be to use a custom reader, ie, Arduino, to read the code out of the original EPROM much more slowly (and checksum it). Initially just read it about 10-20 times and if the checksum is consistent when the device is read in slow-mo, then save the code and reprogramme another device with the code which was read out slowly.

The problem with conventional device readers is that they assume you are reading a healthy device, so they read at what would be near maximum speed for a healthy device. I've never known one which lets you dial down the 'read speed'.
 
I'll look to try that once I have a working system.

Just found I misread the FDC and used a 1795 instead of a 1793 - stole a loaner from a Cromemco 16FDC, and it now seeks, so working on the video issue.

Going with the shotgun approach and replacing electrolytic caps and semi's in the line osc area to start.
I'm pondering on what difference a modern NE555 might make. It looks like one of those ic's that are pin equivalent, but may behave differently between different manufacturers, and even compared to early versions.
Detailed datasheets seem scarce. Time to dig into may vintage parts boxes that are scattered all over the mountains of boxes in the garage.
I have started cataloging it, but could take a year or so to finish at this rate.
I did ship some rare XR2206's to France, so hasn't been in vain so far.
 
Another potential workaround or check for suspected 'slow' or faltering EPROMs in simple microprocessor systems is to (temporarily) fit a significantly lower main clock crystal to see if the system will run consistently at the slower speed.

However this is only really usable in something like a microprocessor trainer with integral keypad and display, as soon as you get to a system which is generating video with the sync and video dot rate being derived from the main clock then this dodge becomes too impractical to apply.
 
That won't work for the MOS 6502, for example. A 1 MHz 6502 will still run at 0.5 MHz but crashes at 250 KHz. I'm not familiar enough with other processors to know how they will act on lower speeds.
 
Yes, some CPU's contain internal 'dynamic' logic whereas others contain 'static' logic.

If you check the data sheet for the CPU part, and look at the specification for the CLOCK - a static part should have a minimum frequency of 'DC'. Slowing the CPU clock down on these parts is fine.

The 'dynamic' logic requires an internal refresh and was sometimes (often?) used for registers. It was 'cheaper' (in terms of transistor count) to go for 'dynamic' logic - and then have the expense of including the internal refresh logic.

As you drop the frequency - you approach the limit of storage on the devices - as the charge leaks away (depending upon whether you are an electron or a hole person...) the register contents become (first) corrupt, and then evaporate altogether.

For more details see the Intel 4004 (e.g. https://sites.google.com/site/intelcsclab/Home/intel-4004 and search for the word 'dynamic).

The Commodore SuperPET had a 6702 dongle protection device. This device deliberately used 'dynamic' logic so that the codes that were generated became corrupt if someone tried to analyse what was going on by slowing down the main system clock. It took me a while to work that one out when I reverse engineered the schematic from the device itself!

Of course, if the computer has 'real' DRAM chips - you are doomed to failure (for the same reason). Ditto with any VDU display if the crystal is used as the master timing generator for everything!

Dave
 
Indeed, as I said, the 'slowdown' approach is best suited to very simple systems without a video display (and as has been pointed out, without dynamic RAM) but it can be a useful diagnostic trick in the right sort of system.
 
I was particularly responding to Ruud's post - and thinking about a Commodore PET as I was typing it...

One thing to watch with the seven-segment types of displays is the multiplexing. Sometimes (thinking about the Sinclair MK14 here) there is an inherent assumption in the choice of series current limiting resistors (or, in the case of the MK14, no resistors at all...) regarding the frequency of the multiplexing.

Slowing the main clock down may have an adverse effect on the average current flowing within the seven segment devices (it will rise as the frequency reduces) and may exceed the manufacturer's absolute maximum rating.

Morale is - check the schematics and circuit design first.

Dave
 
daver2 said:
One thing to watch with the seven-segment types of displays is the multiplexing. Sometimes (thinking about the Sinclair MK14 here) there is an inherent assumption in the choice of series current limiting resistors (or, in the case of the MK14, no resistors at all...) regarding the frequency of the multiplexing.

Slowing the main clock down may have an adverse effect on the average current flowing within the seven segment devices (it will rise as the frequency reduces) and may exceed the manufacturer's absolute maximum rating.
Click to expand...
That's a very interesting point that I haven't seen mentioned before. Thanks for making it :->.
 
Yes, I haven't seen it mentioned too many times either...

It was something I considered when I powered up my MK14 clone for the first time... Not specifically the crystal frequency - but whether it was going to power up correctly and actually multiplex the display without 'jamming' and burning out a segment (or more) on the display!

Dave
 
When you press reset down on an MK14 the display scanning action is halted, which usually leaves one display cell shining very brightly indeed. I try not to hold reset down for very long. (But now we are drifting).
 
You must log in or register to reply here.
Back
Top