PDA

View Full Version : Reading the Eprom data from a vintage UV Eprom CPU



Hugo Holden
July 16th, 2017, 05:06 PM
Possible or not question:

I have a 1986 vintage multi-standard video monitor whose system controller uses a vintage MC1468705G2 UV eprom. It was done this way so that all the monitor's controls could be touch buttons with memory for the various settings/selections .

This CPU was originally programmed at the factory by transferring data from another programmed EPROM, on a small programmer board, described in the application note on the link below. The data sheet for this IC is also on the link below.

I have a blank MC1468705G2 device which is now a rare part itself and one & only working programmed device from the original monitor. Without it the monitor is useless. I want to program the blank IC as a spare part, but the original 1986 vintage factory files (presumably BIN files) are not available.

Is it possible to read the contents of the MC1468705G2 UV eprom from the working device to create the image, or is this not possible with UV eprom CPU's of this type ?

http://matthieu.benoit.free.fr/cross/data_sheets/MC1468705G2.pdf (the CPU's data sheet)

http://matthieu.benoit.free.fr/cross/data_sheets/AN907A_REV0.pdf (application note for programmer pcb)

ardent-blue
July 16th, 2017, 05:51 PM
MC1468705G2

Depends on _IF_ the algorithm exists. I will check my Needham EPROM programmer.

I wonder if the 68764 and/or 68766 are compatible. I have algortihms for those...

68764 is not an MCU

gslick
July 16th, 2017, 06:05 PM
My BP Microsystems device programmer claims to support the MC68HC705G4 device, but not the MC68HC705G2 device.

I don't see it in the Data I/O device support list either.
http://www.dataio.com/Support/Device-Search

Hugo Holden
July 16th, 2017, 06:56 PM
Yes, the whole problem seems a lot more tricky when the EPROM is part of a CPU. I'll look up the MC68HC705G4 device.

Presumably an Eprom writer can write CPU/Eproms, if they are able to program the specific device in the first place and as part of the verify process read them too. So maybe there is one out there that can do it.

gertk
July 16th, 2017, 08:22 PM
It looks like the bootstrap part is programming and verifying the internal eprom from the external (ep)rom.
So there could be a tedious way to get the contents but you need a rom emulator to do it:

You can use the supplied circuit in the datasheet and set switch S3 to 'verify only'
In the emulated rom you need to set all 8 kBytes (the CPU seems to supply 13 address lines??) to all 256 possible values and reset the programmer and check if 'verified' comes up, if not try next value and repeat.

I don't know how the verify agorithm works, if it stops after the first error then the process can be much faster, or after checking all the bytes but it might be a way to get the contents.

Al Kossow
July 17th, 2017, 06:16 AM
Yes, the whole problem seems a lot more tricky when the EPROM is part of a CPU.

And it supports inhibiting the ability to read what was written after programming.

gertk
July 17th, 2017, 09:58 AM
In this case only the MCU itself can verify its contents against the external rom so you have to go through some hoops..

Chuck(G)
July 17th, 2017, 12:07 PM
It's not at all clear to me (reading the MC1568705 datasheets) that verification can be separated from programming. The documents appear to say that the progression from programming to verification is automatic. Perhaps you could remove Vpp when RESET/ is raised so that nothing gets programmed, but that's just a guess.

Hugo Holden
July 17th, 2017, 05:34 PM
Hi gertk,

I could see how this could work. It doesn't really matter how time consuming it is. Where would I acquire a Rom emulator ?

I would also have to modify the programming board to make 100% sure that it couldn't alter the contents of the existing chip.

Its a real shame they didn't use a separate CPU & UVeprom.

Chuck(G)
July 17th, 2017, 05:36 PM
Wait'll you get a modern MCU with security fuses.... :(

Hugo Holden
July 17th, 2017, 05:38 PM
ChuckG,

Is there any setup you could think of where the chip could be put in some sort of test sequence where the Eprom data could be deduced from the overall behavior of the IC ?

Chuck(G)
July 17th, 2017, 05:56 PM
I doubt it. I suppose you could observe the chip I/O during various operations and come up with a set of rules that could be implemented with some code. But that's a long and arduous way to go...

I know that some de-capping operations claim to be able to read UVEPROM contents. Expensive and uncertain.

Hugo Holden
July 17th, 2017, 07:10 PM
Chuck, yes I guess if one could gain physical connections to the eprom it could be read in a conventional manner. Not something easily done in the average workshop.

gertk
July 17th, 2017, 07:54 PM
It's not at all clear to me (reading the MC1568705 datasheets) that verification can be separated from programming. The documents appear to say that the progression from programming to verification is automatic. Perhaps you could remove Vpp when RESET/ is raised so that nothing gets programmed, but that's just a guess.

There is a switch named S3 which selects programming+verify or verify only (see circuit diagram note 2)

Chuck(G)
July 17th, 2017, 09:30 PM
I suppose you could, by trial and error, work out a means of reading the PROM then. It wouldn't be fast, of course, but better than nothing. I'd probably use a medium-scale MCU to perform the EPROM emulation. 8KB isn't so much these days.

gertk
July 18th, 2017, 08:19 AM
I suppose you could, by trial and error, work out a means of reading the PROM then. It wouldn't be fast, of course, but better than nothing. I'd probably use a medium-scale MCU to perform the EPROM emulation. 8KB isn't so much these days.

That would be an good option, you can then control the reset pin and test the 'verified' output (PD5) of the 68705 with the external MCU, you could even supply the clock signal for the 68705. Just take care that your modern MCU can handle 5 Volt IO levels. (the NXP 'mbed' LPC1768 for example can do this fine, I did a Videopac/Odyssey2 rom emulator on such a MCU and it handles read and writes from the 8048 with interrupts on the LPC...)

If the verify routine in the 68705 stops at the first unequal byte the process could be quite fast, if not you need to go through 8192*256 combinations..

Chuck(G)
July 18th, 2017, 11:30 AM
Oh heck, a $5 Maple mini or similar clone using an SM32F103 has 20K of SRAM and 5V tolerant GPIO logic at 72MHz. I think there's probably enough GPIO there, but I haven't counted pins.

GeoffB17
July 18th, 2017, 01:15 PM
I assume the problem is that the required code is in the monitor, and the memory there has address space, with addresses (as indicated in the docs attached to first message) BUT - this address space is NOT accessible from the main computer, and to a program running on that machine.

Is there any way that this memory COULD be accessible?

If there is, then you could create a little prog, even BASIC will do it if there's PEEK command, to read the required memory byte by byte and write to a .BIN file.

I did this for a FORTH ROM on my HX-20 machine, worked fine, but of course this ROM is in the address space of the main CPUs.

A very quick look at the docs does suggest some sort of access. Maybe via ports etc? A prog may be slow/fiddly, but if it works, you've got the file/data stored and safe, and can try writing the data to whatever whenever.

Geoff

Al Kossow
July 18th, 2017, 01:39 PM
Is there any way that this memory COULD be accessible?

Geoff

no

the classic way to deal with this on 68705s is try to program it with vpp disabled then change a byte during verify
until it matches.

this assumes the memory protect bit isn't set, which existed on parts after the P5

a long saga of recovering protected devices can be seen here
http://caps0ff.blogspot.com/

Hugo Holden
July 19th, 2017, 03:11 AM
no,
the classic way to deal with this on 68705s is try to program it with vpp disabled then change a byte during verify
until it matches.

So this has been done before ? Can you provide more information. The statement suggests that if vpp is disabled the MC1568705 won't actually program (so the data in it is safe) then, presumably you change the bytes at which locations ?..do you just step through the addresses or does the MC1568705 do that as part of the verify ? Is there a practical ROM emulator that I could use so I can set the values in the emulator easily via a computer until I obtain the byte match ?

Dwight Elvey
July 19th, 2017, 06:12 AM
You can make a ROM emulator without too much effort. 4264 chip and
some buss buffers would not be to hard to wire up.
Do you have a 1568705 to practice on? You'll most likely need a logic analyzer as well.
You need to determine the behavior of the verify light. If it comes on at the first mismatch,
it is possible but if it scans the entire address space first and then reports to the verify
light, the possible combinations are beyond any practical value. ( time of the universe type problem )
My guess is that one would want to know the failed location so the address lines likely stop
at the failed location.
The other possible is that the address continues but the light first comes on while it is being
addresses to the failed location.
Even if it doesn't wait until the end before updating the light, it is being run by software.
With a logic analyzer, one could watch the progression of the address lines the error
trapping is likely to cause a slight delay on the address that fails.
Working with a real part that you can program first is the best way to start.
Dwight

Hugo Holden
July 19th, 2017, 02:37 PM
You can make a ROM emulator without too much effort. 4264 chip and
some buss buffers would not be to hard to wire up.
Do you have a 1568705 to practice on? You'll most

Thank you. I have ordered a blank 1468705 to practice with. I will have my pcb maker make up a programmer pcb. I think I will have to get used to programming these IC's first with known contents and proving to my self I could harmlessly acquire the data before going anywhere near the IC with the original monitor program in it. I wonder if I could slow down the clock to step the 1568705 slowly through its program a step at a time to see exactly what it is doing. I agree it all comes down to the behavior of the verify light.
I have good scopes and some logic probes including one that can accept and display 8 bit data and latch it to a display, but no logic analyzer.

If I get this to work I will write up a detailed article on how to do it to help others with the same issue.

Does the 4264 have a prefix or suffix letter ? I am not familiar with this IC, or is is just a voltage regulator and and Tristate buffer outputs act as the emulator data ?

gslick
July 19th, 2017, 03:27 PM
Where did you order a 1468705 part? I did a real quick search and didn't find any.



Does the 4264 have a prefix or suffix letter ? I am not familiar with this IC, or is is just a voltage regulator and and Tristate buffer outputs act as the emulator data ?

Maybe 6264 (for example MCM6264)? A standard 8Kx8 SRAM.

Hugo Holden
July 19th, 2017, 06:35 PM
Where did you order a 1468705 part? I did a real quick search and didn't find any.



Maybe 6264 (for example MCM6264)? A standard 8Kx8 SRAM.



Great, I have the DS2064, the MCM6264 and FM16w08 and DS1225 in my junk box. I had been using these in my Tek scopes.

Can you give me a guide as to how I would set one up to act as a Rom emulator on the MC1468705G2 programming board ?

I got the MC1468705G2 on ebay, but I think the seller only had the one of them:

http://www.ebay.com/itm/Vintage-Motorola-MC1468705G2S-Rare-/162584520265?hash=item25dacae649:g:GZ0AAOSwrhlXTy~ q

gertk
July 19th, 2017, 07:49 PM
If you got the money to spend:

http://www.ebay.ca/itm/memSIM2-EPROM-Emulator-/162310534410?hash=item25ca76350a:g:IfAAAOSwMNxXVpj w

gslick
July 19th, 2017, 08:35 PM
If you got the money to spend:

http://www.ebay.ca/itm/memSIM2-EPROM-Emulator-/162310534410?hash=item25ca76350a:g:IfAAAOSwMNxXVpj w

Also, older used Grammar Engine PROMICE units sometimes show up on eBay. I have a few that I grabbed a bit cheaper than this example:

http://www.ebay.com/itm/322257899987

Chuck(G)
July 19th, 2017, 08:44 PM
I don't understand why the obscure parts, etc.

For about $10 shipped, you can get a 168MHz 32-bit processor with 192K of SRAM and oodles of 5V tolerant I/O. It's even got USB, UART, etc. It'll run rings around any simple TTL design using legacy parts.

Example (http://www.ebay.com/itm/STM32F4-Discovery-STM32F407VGT6-ARM-Cortex-M4-32bit-MCU-Core-Development-Board-/262675840220?hash=item3d28b33cdc:g:t-cAAOSw-CpYAiTn)

Hugo Holden
July 20th, 2017, 12:43 AM
Also, older used Grammar Engine PROMICE units sometimes show up on eBay. I have a few that I grabbed a bit cheaper than this example:

http://www.ebay.com/itm/322257899987

gslick, since you are familiar with this emulator do you know if it supports the MCM68764 or MCM68766 that are recommended for use on the programming board ? and if this emulator requires support software , is that the "Grammar Engine" ?

Chuck(G)
July 20th, 2017, 04:48 AM
Unless I'm missing something, you're going to have to get the data out of this thing (assuming that the MCU signals a verify error immediately, byte by byte, trying every combination of 8 bits until a match occurs, then re-running the verify to get the next byte and so on.

How is a PROM emulator going to help you?

I don't understand. :huh:

Hugo Holden
July 20th, 2017, 05:42 AM
Unless I'm missing something, you're going to have to get the data out of this thing (assuming that the MCU signals a verify error immediately, byte by byte, trying every combination of 8 bits until a match occurs, then re-running the verify to get the next byte and so on.

How is a PROM emulator going to help you?

I don't understand. :huh:

I had guessed, when it was suggested that it would be necessary to change the data, reasonably quickly, in the Eprom, to get a result where it matched the value in the CPU's eprom. Otherwise the eprom would have to come out of its socket, get erased and programmed again. I assume that the suggested emulator would act like an eprom where you could quickly change the byte value at any location. But I have never used one, so it would be good if the reason for needing one was clarified.

Dwight Elvey
July 20th, 2017, 06:00 AM
Chuck is right, some of these uP can act like a EPROM fast enough.
One can avoid the hassle of making a dual ported RAM.
For a ROMICE, you need a computer to parallel to write to the RAM.
You'd need a method to isolate while updating ( tristate buffers and
possibly tristate latches for address ).
The $10 uP could do all to a port.
It would not be a good idea to slow the programming down too much.
It would tend to hammer the cells more than needed.
You only need to program once because it is the verify step you are most
interested in.
Dwight

celsoken
July 4th, 2018, 04:04 AM
Dear Hugo,

The answer is probably Yes, you can. Matthieu Benoit has done it with the P3 and other NMOS members of this family.
See: http://matthieu.benoit.free.fr/MC68705P3_reader.htm
IMO you could use a dual-port ram accessed by the G2 and your master MCU, generate the clocks yourself (the MC1468705 are fully static) to ease checking at the spot.

Good luck,
Celso

Hugo Holden
July 5th, 2018, 03:33 AM
Thank you kindly for posting that Celso.
Hugo.

Al Kossow
July 5th, 2018, 08:01 AM
Matthieu Benoit has done it with the P3 and other NMOS members of this family.


Or find someone with a Data/IO Unisite programmer.
It supports reading and programming P3's and P5's if they haven't been protected.