Need help dumping the ROM in a failing 80C49 (MCS-48)

[trondl]

Hi!
This is a continuation of this thread: https://www.eevblog.com/forum/repair/roland-sde1000-repair-guidance-needed!/
I chose to continue here as I now have a different problem.

First of all, an 80C49 with maskROM that is _very_ unlikely to have the copy protection enabled,
is failing and needs to be chilled to bellow freezing temperatures (-5 degC outside here in Norway) to work "in situ".
I say unlikely because most of the other ROM's from the same producer and era have been dumped and are for sale on the interwebs

I have built this Arduino shield and have verified it's function by programming a 8749 with success:
http://www.mattmillman.com/projects/hveprom-project/an-easy-to-build-mcs-48-8748-8749-8741-8742-8048-8049-programmer-reader/#comment-96692

The problem is that the MCU is failing and I just get semi-random garbage in the read-out, even in the same environment as when it is stable and working in the unit to be used in.
When probing the D pins on the MCU during the dump, I get steady pulse trains on pins 0-3, but on 4-7 it looks more like bursts.

Worth noting here is that in the Windows GUI application for the project gives me a warning about the Arduino VIN pin being low.
It should be 12V but I get 11,4V.
This caused no issue when programming the 8749.

My theory is that since it is failing, the access time is much higher than ideal for a normal read-out.
A similar story that almost proves my theory is here: https://forums.arcade-museum.com/threads/stumped-random-eprom-readings-need-input-from-eprom-gurus.320383/

Now, the project is open source, I've spoken to the author, but he is understandably not available to commit to this issue.
He guided me to try to add extra delays in the _read_ routine, hopefully not messing up the timings:
https://github.com/inaxeon/eightoduino/blob/master/app_hveprom/pgm_mcs48.c

My problem is that my programming skills are subpar to put it mildly.
Which lines are relevant to the read delay routine?
Is it somewhere between lines 49 to 61, or is it 107 to 110?

You can exclude the extra sections for programming/writing and the odd 8755 MCU.
All I need is a starting point at slowing down the dump to a point where I can hopefully get a stable transfer.

The XTAL attached to the mcu on the shield is 4MHz.
I think page 26 in this document has the min-max timings, but it's a bit beyond me:
https://archive.org/details/grokking-the-mcs-48/page/n25/mode/2up?view=theater

Thanks in advance!

[amyk]

AFAIK there is, unlike the programming pulses, no maximum times for readout, so you should be able to go as slow as you want.

[james_s]

Is that the new one you programmed that is giving you errors when reading out? Usually the problem is the other way around, read out works fine but fails when run at full speed in the intended application.

[trondl]

Is that the new one you programmed that is giving you errors when reading out? Usually the problem is the other way around, read out works fine but fails when run at full speed in the intended application.

No, it is the failing one that is giving no valid readout, even when cold, but works "in situ" when cold.

[trondl]

The author of the shield verified that lines 107 and 109 (pgm_mcs48_delay_4tcy, pgm_mcs48_delay_pre_read) are mostly responsible for the reading section.
Now, I've experimented a bit with both long and veeery long delays in the reading,
And,
I'm starting to see some expected results!
I have another ROM dump from the same producer, and they pad the remaining data with 00 01 02 03 all the way to FF repeated.
The problem is that some bits (sometimes bit 5 and 6, sometimes just bit 5) stay high 99% of the time, and that the data looks to be out of sequence.
Before half way through the dump I expect to see the padding data, but I get them either repeated or out of sequence,
to illustrate an example: 00 02 02 01 03 05 06 05 05 04

Any ideas here?
May it be trouble with the addressing as well?

[wraper]

Since MCU is temperature dependent, likely it's also voltage dependent. So I suggest playing with voltage, like powering MCU from 5.5V or 4.5V instead of 5V and checking if it helps.

[james_s]

So the new one you programmed does read out correctly?

It's possible that the failing one does in fact have the code locked if it has that feature. It's also possible that it has failed such that part of whatever is required to read out the code has failed completely. As was mentioned above you could try playing with the voltage but there is some risk there, you're probably fairly safe to go up as high as about 6V, maybe 6.5V for a modest period.

[wraper]

It's possible that the failing one does in fact have the code locked if it has that feature.

If code locked, you won't get changing readout.

[trondl]

So the new one you programmed does read out correctly?

It's possible that the failing one does in fact have the code locked if it has that feature. It's also possible that it has failed such that part of whatever is required to read out the code has failed completely. As was mentioned above you could try playing with the voltage but there is some risk there, you're probably fairly safe to go up as high as about 6V, maybe 6.5V for a modest period.

The 8749 programmed and verified, yes, and there is a hardware test in the application, also verified all checks.

The weird thing is that when I delay the readout, I'm starting to see expected padding data patterns compared to a known good dump for another product, although out of sequence and sometimes echoed, as if the correct address hasn't been decoded.
Also sometimes, some bits stay high 99% of the time.
Sometimes not.

To me, it all seems like the data isn't ready on the D0-7 pins when being read.

I probed the Reset pin during a dump, and it is in bursts pulled 8 times high very fast, maybe too fast for it to properly reset.

I may have to learn some C code and insert some delays for the reset and addressing, as delaying the reading clearly gives some results.

[trondl]

It's possible that the failing one does in fact have the code locked if it has that feature.

If code locked, you won't get changing readout.

Thanks for verifying!

[amyk]

was mentioned above you could try playing with the voltage but there is some risk there, you're probably fairly safe to go up as high as about 6V, maybe 6.5V for a modest period.

80C49 is on an old thick oxide large-geometry process, in fact according to datasheet typical recommended VCC/VDD is 5V+/-20% (4-6V) and absolute maximum is 7V(!) I wouldn't go over 7V but Intel tends to be quite conservative with the maximums, for reliability purposes.

[james_s]

About 20 years ago I had a classic arcade cabinet that wouldn't boot unless the 5V was cranked up to close to 7V. In retrospect it was probably a faulty ROM or something but at the time I didn't really know much about digital stuff and the way the board stack was set up made it a nightmare to work on. It ran for a couple years like that until I sold it.

[trondl]

I think I'll play with delays, rather than risk frying it for now.
But a last resort is better than none!
Thanks.

It's seems that I can insert some delays after the address latching at line 464 in the code.
I'll give that a go first.
Now, how to insert delays in C code...

[abyrvalg]

Inserting delays example: _delay_us(20); line will do 20 microseconds delay. _delay_ms(20); will do 20 milliseconds.
This assumes you are using a "normal" (AVR-based) Arduino, not the 80x86 one also mentioned in that project.

[trondl]

Inserting delays example: _delay_us(20); line will do 20 microseconds delay. _delay_ms(20); will do 20 milliseconds.
This assumes you are using a "normal" (AVR-based) Arduino, not the 80x86 one also mentioned in that project.

Thanks a bunch!
AVR compiler, yes

[james_s]

It's quite safe to bump the voltage up a bit, say 5.5-5.75V, it's just going beyond the absolute maximum in the datasheet that you should save as a last resort.

[dl6lr]

I often found it helpful to *lower* the Vcc voltage during read on aged EPROM devices as it lowers the threshold of the read amplifiers. Successful programming is therefor often verified with *higher* voltages whereas the blank check should be performed with the minimal voltage. So you may have a better chance by lowering the voltage of the 8049 to i.e. 4.75V or 4.5V and reading them slowly in the cold...

[artag]

The XTAL attached to the mcu on the shield is 4MHz.

That's the XTAL on the arduino-based programmer, not the original Roland board ? I guess if the programmer has a crystal then it's performing at least a part of the programming/verifying using the actual CPU. There may be some internal ROM that handshakes the data in from the pins and writes it to EPROM. So what's the XTAL on the Roland board ? Does it run slower than 4MHz ? Can you reduce the clock speed on the programmer ?

[trondl]

I often found it helpful to *lower* the Vcc voltage during read on aged EPROM devices as it lowers the threshold of the read amplifiers. Successful programming is therefor often verified with *higher* voltages whereas the blank check should be performed with the minimal voltage. So you may have a better chance by lowering the voltage of the 8049 to i.e. 4.75V or 4.5V and reading them slowly in the cold...

That sound a bit safer than going over!

I've now tried inserting huuuge (10ms) delays where I can, and still get a 100% verified dump on the known good 8749.
Time to dump is about 5mins.
I still get the same semi-random results.

Looks like Vcc mods are in order.
Starting at 4.5V

Now, the next problem is my little knowledge of connecting up multiple psu's with regard to the ground/common.
Both my laptop, 12V/3A generic arduino brick and my DIY "lab" psu I built years ago during education are not earth referenced.

Could this cause any problems?

In circuit on the shield, VCC is tied with T1, /SS and /INT/[CS] to 5V.
Should I lift the leg for VCC out of circuit and apply the "lab" psu between VCC and VSS?

Shield schematics attached.

The XTAL attached to the mcu on the shield is 4MHz.

That's the XTAL on the arduino-based programmer, not the original Roland board ? I guess if the programmer has a crystal then it's performing at least a part of the programming/verifying using the actual CPU. There may be some internal ROM that handshakes the data in from the pins and writes it to EPROM. So what's the XTAL on the Roland board ? Does it run slower than 4MHz ? Can you reduce the clock speed on the programmer ?

XTAL in Roland is 11MHz.
Arduino shield is 4MHz.

That's the odd thing, since it works when cold in the Roland, but not in the shield.

[abyrvalg]

You’ve mentioned an observable difference between D0-3 and D4-7 during dump. Try probing them in the original device (and cooled) - what’s the difference?

[trondl]

You’ve mentioned an observable difference between D0-3 and D4-7 during dump. Try probing them in the original device (and cooled) - what’s the difference?

In circuit, the DB on the mcu is controlling the display and input switches/latches, so there wouldn't be much data to verify except functionality.

Now, on to my next endeavor, under/over-voltage on the VCC pin.
The Arduino is powered by an external 12V/3A psu and connected to a laptop, all floating ground/common.
If I were to lift the VCC pin out of the shield and apply a secondary PSU (also floating) between VCC and VSS which by the way is also connected to the shield ground/common, could it cause any bad "feedback" into the Arduino shield?

[trondl]

Or should I lift both the VCC and VSS pin and connect them to the external PSU with floating ground/common?
Don't want to fry anything by accident here.

[james_s]

Just connect the ground of your PSU to the ground of your programmer, provided the PSU is something with an isolated floating output everything will be fine.

[trondl]

Just connect the ground of your PSU to the ground of your programmer, provided the PSU is something with an isolated floating output everything will be fine.

Thanks for verifying!

[m k]

Why 10ms delay is huge?
If it needs a week then it takes a week.

Reading subroutine starts from line 440 and its loop from 452.

461-464 is putting the address out.
There you have the first 4tcy delay.

466 changes the direction of a port, I guess.
467 has the next delay.

484 then is the actual read.

From pgm_common.c
uint8_t pgm_read_data(void)
{
#ifdef _M8OD
    return (uint8_t)cpld_read(PORTC);
#endif /* _M8OD */

#ifdef _MDUINO
    return DATA_PIN;
#endif /* _MDUINO */
}

Indented lines are actual read commands.
One for _M8OD and other for _MDUINO.

So despite all your pre read delays you're still actually reading like zap, it's done.
You should replace that 484 line with your own reading procedure.
Address is there and is not changing so you can read as many times as you like.
Maybe you should read 100 times and analyze what you get.
You can replace that 484 line with how ever more stuff also, so you can put there read, delay, read, delay and so on.

Maybe you should modify the board and read using analog pin.
If you have only one analog pin then probably easiest is to read one bit thru the chip and then manually connect it to the next bit.
Though it's probably not helping with weak output.

[trondl]

Why 10ms delay is huge?
If it needs a week then it takes a week.

Reading subroutine starts from line 440 and its loop from 452.

461-464 is putting the address out.
There you have the first 4tcy delay.

466 changes the direction of a port, I guess.
467 has the next delay.

484 then is the actual read.

From pgm_common.c
uint8_t pgm_read_data(void)
{
#ifdef _M8OD
    return (uint8_t)cpld_read(PORTC);
#endif /* _M8OD */

#ifdef _MDUINO
    return DATA_PIN;
#endif /* _MDUINO */
}

Indented lines are actual read commands.
One for _M8OD and other for _MDUINO.

So despite all your pre read delays you're still actually reading like zap, it's done.
You should replace that 484 line with your own reading procedure.
Address is there and is not changing so you can read as many times as you like.
Maybe you should read 100 times and analyze what you get.
You can replace that 484 line with how ever more stuff also, so you can put there read, delay, read, delay and so on.

Maybe you should modify the board and read using analog pin.
If you have only one analog pin then probably easiest is to read one bit thru the chip and then manually connect it to the next bit.
Though it's probably not helping with weak output.

Thanks for the input!

Could this be done without too much change in the code?
«Quasi-basic»:
10 write address to mcu
20 delay to let mcu latch them in
30 read the eight bits
40 delay
50 read the same bits once or twice more with delay between
60 compare the bytes
70 if different, goto 30, else next address

[abyrvalg]

A quick&dirty 2-of-3 majority selector with infinite retry:

Code: [Select]

uint8_t pgm_read_data(void)
{
    while(1)
    {
        _delay_us(20);
        uint8_t d0 = DATA_PIN;
        _delay_us(20);
        uint8_t d1 = DATA_PIN;
        _delay_us(20);
        uint8_t d2 = DATA_PIN;

        if (d0==d1) return d0;
        if (d0==d2) return d0;
        if (d1==d2) return d1;
    }
}

You can change the conditional part to a single

Code: [Select]

    if ((d0==d1) && (d0==d2)) return d0;
if you want all 3 samples to match.

[trondl]

Amazing!
Now we are getting somewhere, while learning a bit of code too!

Thanks a bunch.

I'll update as soon as I have time to implement this (busy times ahead...)

[m k]

abyrvalg's code is data level independent when your case is not.

Since your software situation is limited you should try to analyze dumps more.
Like reading 10 times and then comparing them all.

Can you somehow deside how the data is bad.
It can be many things form many angles.

Stressing output first is probably a good approach, so that all 3 match can be the first "if" but after that there should be something else.
You can also fiddle with those delays if you feel a need.

If all 3 are not matching the next thing should be a long delay, to give output stage time to stabilize.
But what then, how can you deside, actually on the fly, how to continue.

If you can construct an idea I'm pretty sure someone will code it for you.
You can also concentrate to bad bits but first you should deside how to generally treat that bad data, like up wrong or down wrong.
Good starting point could be those ascending fillers.

With those 3 reads 1 bad bit can be
001
010
011
100
101
110

4th and 6th can be guessed as up, 5th is a so-so but what about those first ones, can you guess them all being up.
All zeros can still be almost up and you just see them as totally down.

But if the machine is working in the cold I'd check that situation first, including all possible voltages.
Manual says that A.C. tests for inputs are 2.4V up and 0.48V down and output timings at 2.0V for up and 0.8V down.
Also, since the chip is a microController there are possibly no use of data lines in normal operation.

[abyrvalg]

Sure, understanding the failure mode instead of guessing could direct to more efficient approaches.
I.e. for marginal depleted EPROM cells the failure mode would be asymmetrical (0 reading as 1 sometimes, but no 1 reading as 0) and a better approach would be to take a logical AND of several samples to catch all 0 states:

Code: [Select]

uint8_t pgm_read_data(void)
{
    uint8_t result=0xFF, i;
    for(i=0; i<5; i++) //5 is number of samples, adjust if necessary
    {
        result &= DATA_PIN;
        _delay_us(20); //can be reduced/removed at all and number of samples increased instead
    }
    return result;
}


[wraper]

I suggest checking voltages on the pins with oscilloscope. There are failure modes when some pins may not pull exactly to the power rail. So input voltage threshold in reading device can make the difference. EPROM reading threshold is not relevant here since it's a mask ROM.

[trondl]

I suggest checking voltages on the pins with oscilloscope. There are failure modes when some pins may not pull exactly to the power rail. So input voltage threshold in reading device can make the difference. EPROM reading threshold is not relevant here since it's a mask ROM.

The problem is that since ground/common is floating on both the laptop and PSU, and my DSO is earth ref., I get sinusoidal waveforms mixed in.
I don’t dare to connect the probe ground/earth in the circuit.
I can see the activity, but meassurements are difficult.

[m k]

Norwegians and their floating mains.

Measure something stable with the other channel and invert it, then sum both.

[abyrvalg]

Measure the earth current via some resistor first, then (if nothing crazy measured) connect directly?

[james_s]

The problem is that since ground/common is floating on both the laptop and PSU, and my DSO is earth ref., I get sinusoidal waveforms mixed in.
I don’t dare to connect the probe ground/earth in the circuit.
I can see the activity, but meassurements are difficult.

Why? Common on the PSU and laptop are floating, that makes it safe to connect the scope probe ground clip to that node, a scope is useless without the ground clip connected. I don't understand the thinking that this would be in any way unsafe.

[wraper]

Norwegians and their floating mains.

Measure something stable with the other channel and invert it, then sum both.

If the ground is floating, you just connect the ground clip of the probe to it. It's actually less safe to probe without ground attached since it increases a chance to cause ESD damage to the circuit.

[m k]

I'm not exactly sure what is the complete situation here and what trondl is actually affraid of.
Or why he has dropped in the hole of one wire for all.
Specially if all parts are in front of him on the table.

The suspicious mains mindset is one possibility but it needs old and unknown connections.
Maybe not old in Russia but there also the building should be old, I guess.

Level of "ground" can be many things but if everything is in same space and using the same mains plug there are very little that are unknown.

One new thing though, non metal plumbing.

E,
b

[trondl]

First of all, thanks for verifying what I _thought_ but didn't _know_ regarding ground references.
Better safe than sorry.

On the other hand though, it may be toast now

I've now tried to power VCC (pin bent out off socket, and common to shield ground) through my DIY psu, first at 4.5V, 5V and 5.5V in room temperature (22 C), with and without a metal bolt directly from the freezer.
The PSU doesn't have current limiting though 

What I quickly noticed is that the mcu without cooling got quickly hot (ouch hot)  with that distinct warm chip smell, although no smoke.
It was even causing my psu to start sagging in voltage after about a short minute.
After cool down I noticed that VCC was drawing ~30mA at 5V with my DMM in between.

I do now with the "sample 3 times / compare" at least get "stable" readouts, which I didn't with VCC power from the shield (gave timeout error in the HVEPROM app).
Every time giving variations in the read outs.
The bits are mostly 0, with some small repeated burst of 1 in patterns.
In hex, I get values ranging from mostly 00 to 07 (only bits 0 to 2 toggling), and a weird dump that started with repeated F8 and later F9 for the first 16 offsets, then continuing with the 00 to 07 randomness.

Should I even attempt to go 6V, dare I say 6.5V?

I did after the panic had settled, verify that the shield was still intact with the known good 8749.
It was 

[m k]

I'd say that you need a second opinion now.
Something where you can put the hadware away for a while.

Make 10 dumps and get a hex editor with compare, HxD is one.
Then check if you can isolate good and bad areas.
You can also compare your dumps to that same producer's other dump and boot code (addr 0) there, with luck all are pretty equal.

First the code is probably jumping somewhere, from address 0.
After that (addr 3) can be an interrupt code jump.
Timer jump can be at address 7.
If interrupts are not used the code can start from address 0.

0 E5h (select memory bank 0)
1 [bbb0]4h (jump ([bbb0]/2)xxh)
2 xxh

is one possible start.

[james_s]

The chip getting "ouch hot" is a very bad sign, that should never be happening. Do you perhaps get the polarity wrong and connect +5V from your PSU to Vss instead of Vcc? Did you connect the - output from the PSU to the +5V rail on the board instead of ground, resulting in +10V across the IC? I agree that a second opinion here would be useful, or at least a schematic showing visually how you have tried to hook it up each time.

[trondl]

The chip getting "ouch hot" is a very bad sign, that should never be happening. Do you perhaps get the polarity wrong and connect +5V from your PSU to Vss instead of Vcc? Did you connect the - output from the PSU to the +5V rail on the board instead of ground, resulting in +10V across the IC? I agree that a second opinion here would be useful, or at least a schematic showing visually how you have tried to hook it up each time.

I always doublecheck such things. If tiered, triplecheck.
Positive to pin 40/VCC with the pin bent out of socket, and negative to arduino shield ground which VSS is tied to.
I believe that there has been an internal short or lose wire that was remedied by freezing.
The psu in the intended unit was probably not strong enough to heat up the chip, same with the arduino shield.
30mA at 5V would be a rather low resistance, but no direct short.

Another round of freezing temperatures (-10C) is inbound here in Norway.
I’ll give it a second chance, or I’ll toss it in the oven at 150C for some minutes as a last resort.

[trondl]

Sorry for the very late sitrep.
I had to put it aside to continue on some other projects.

Thought it was about time to see if something could be done again.
And something was observed!

I thought it was about time I did some of the most sane thing to to: compare the waveforms to a working 8749.
This time without a separate PSU for VCC, and in room temperature.

When idle, 8749 gets a clean 5V at the i/o bus and 0V at VCC.
8049 only get about 1.5V at the bus and VCC / VDD is about 1V.

When dumping (with the standard unmodified hex file loaded in the shield), the waveforms on the 8749 are stable with clean pulses and has a distinct beginning and end pulsing of the data stream.
The 8049 on the other hand has a very unstable and fast switching stream, as in hi-lo-hi-lo-hi-lo in the time frame the 8749 would only go hi-lo,  and as previously mentioned, "floating" areas of the stream at about 1-2V.

I still get the same semi-random values as before the "ouch" moment with the external psu.

Something seems very wrong here and may explain why I get no valid data.

With a DMM I tried to check if there was a resistance between VSS and the i/o pins, VCC and most of the readings where in the mega ohms if at all, compared to the 8749 in kilo ohms.
Could this indicate that the chip is indeed very dead and is no longer worth the time, considering that I still get the same "values" as before?

[trondl]

One further observation is that I see in the schematics that there are no pull-up or down resistors on the data bus D0 to D7 (AD0 - AD7).
It's all directly routed to the Arduino.
Could this be an issue?
The "floating" area of the stream may actually be Low bits, but not low enough in voltage (1.5V).
Also the additional address pins P20 to P23 (A8 to A11) all give perfect pulses.

[Andy Watson]

What are you doing with the PROG pin? Looking at an old datasheet for the Intel 8048/9 series there is a curious note under the programing and verify timing waveforms for the 8048 (I can't see an equivalent for th 8049 - so YMMV), it says:
"Prog must float if EA is low, or if T0=5V for the 8748. For the 8048 PROG must always float."

[trondl]

Hi again!
Got some update, although not the best kind of update.
Bought an almost cheap second unit from japan in the hope that dumping the second MCU would be a breeze.
Not so.
The dumping waveforms are almost exactly like the failing one.
It just seems like the LO bits never reach ~0V and VCC is also idle at 1.5V, just as the Data pins are doing.

Is this actually a fault on the Arduino or the code?
The Data pins on the shield are directly connected to the Arduino without any pull-up or down resistors (unsure about what to do when trying to help a signal go LO).

I've seen articles about a built in pull-up resistor in the Arduino itself.
Could this be utilized, if not already in the code (if so, where?)

Included screendumps from the DSO:
First: "new" 8049 during a dump on pin D7, second: VCC idle, third: working 8749 during dump, 8749 VCC idle.

What are you doing with the PROG pin? Looking at an old datasheet for the Intel 8048/9 series there is a curious note under the programing and verify timing waveforms for the 8048 (I can't see an equivalent for th 8049 - so YMMV), it says:
"Prog must float if EA is low, or if T0=5V for the 8748. For the 8048 PROG must always float."

PROG is HI during the entire dump

[abyrvalg]

Do I understand correctly? - the idle Vcc sags from 5V to 1.5V? Looks like there is some pin driven low connected directly to Vcc. Which pins of 8049 are connected to Vcc now? Try disconnecting them one by one while observing the Vcc level to find which one causes the sag.

Andy Watson says “PROG must float” and you say “PROG is HI” - is it floating and driven HI by the 8049 or you drive it HI? That can be the first candidate for disconnect.

[trondl]

Do I understand correctly? - the idle Vcc sags from 5V to 1.5V? Looks like there is some pin driven low connected directly to Vcc. Which pins of 8049 are connected to Vcc now? Try disconnecting them one by one while observing the Vcc level to find which one causes the sag.

According to the schematics: pin 39 T1, pin 5 /SS and pin 6 /INT / /CS are tied to VCC.
I'll try lifting them later today

[Andy Watson]

What are you doing with the PROG pin? Looking at an old datasheet for the Intel 8048/9 series there is a curious note under the programing and verify timing waveforms for the 8048 (I can't see an equivalent for th 8049 - so YMMV), it says:
"Prog must float if EA is low, or if T0=5V for the 8748. For the 8048 PROG must always float."

PROG is HI during the entire dump

Assuming I am looking at the correct programmer circuit, the PROG pin appears to be pulled HI (via a diode) with a 220\$\Omega\$ resistor - that's quite an aggressive pull-up, especially for a cmos device. I would not class it as "floating".

[PCB.Wiz]

When idle, 8749 gets a clean 5V at the i/o bus and 0V at VCC.
8049 only get about 1.5V at the bus and VCC / VDD is about 1V.
...

Bought an almost cheap second unit from japan in the hope that dumping the second MCU would be a breeze.
Not so.
The dumping waveforms are almost exactly like the failing one.
It just seems like the LO bits never reach ~0V and VCC is also idle at 1.5V, just as the Data pins are doing.

Something is very awry, if Vcc droops to 1.5V - Check the current demand ? and compare your 8749 with 8049's
Those old parts are NMOS so they need a lot of supply current

You might also want to check the pin-mapping, to make sure it really is an 8049 ?

[trondl]

Something is very awry, if Vcc droops to 1.5V - Check the current demand ? and compare your 8749 with 8049's
Those old parts are NMOS so they need a lot of supply current

You might also want to check the pin-mapping, to make sure it really is an 8049 ?

Thanks a bunch again for all the help from everyone so far!
Things are busy as usual, resulting in slow progress.

Yes, it is definitely a 8049 I'm dumping.
I've attached screenshots from the SDE1000 service manual and the Arduino shield for comparison.
When desoldering the "new" second chip, pin 34 (P1-7) was bent inwards / floating.
No Idea why that specific pin was in that state compared to the other unit I have, where all pins where soldered.

I need to clarify one thing here.
When the 8749 is idle, the only pins that are held high/5V are the DB0-7 pins.
VCC is at 0V then.
The 8049 is when the Ardino is fully restarted at 0V on all pins (even on the VCC and DB pins, but on successive read it seems like it enters a semi-stuck state with 0.9 to 1.5V on various pins (listed bellow).
I repeat that VCC should be 0V, not ~1V when idle.

I've also tried to lift some pins with no direct results: 25 Prog, 5 SS, 6 INT, 39 T1, 11 ALE.
Comparing which pins are absolutely necessary with this other project:
https://www.sbprojects.net/projects/8049spy/index.php

While at it, I made a list of which pins are stuck after a dump.
A curious discovery is at pins 27 & 28 (P1-1 / 2) is tied to ground, while the rest of P1 up to pin 34 is floating and has the stuck voltage.
Would it be safe to tie the rest of the P1 pins to ground?
Could there be more pins that could be tied low instead of floating?
Could VDD be disconnected?

Description:
Pin#, _x_ after pin indicates >0.9V present, Name, Notes in reference to Arduino shield schematics.

1   T0
2   xtal
3   xtal
4   Reset
5x   SS
6x   INT
7x   EA
8x   RD    floating
9   PSEN
10x   WR   floating
11   ALE
12x   DB0
13x   ..
14x   ..
15x   ..
16x   ..
17x   ..
18x   ..
19x   DB7
20   Vss

21   P2-0
22   ..
23   ..
24   P2-3
25x    Prog
26x   Vdd
27   P1-0 Gnd tied
28   ..   Gnd tied
29x   ..   floating
30x   ..   floating
31x   ..   floating
32x   ..   floating
33x   ..   floating
34x   ..   floating
35x   P2-4 floating
36x   ..   floating
37x   ..   floating
38x   P2-7 floating
39x   T1
40x  Vcc

[trondl]

Nevermind! All good again. Deep clean with IPA and brush solved it.

[old text]
The weirdest thing just happened:
The Arduino shield doesn't do EA above 4.4V anymore.
It's supposed to do 4.4V, 12V and 18V.

One of the transistors gone possibly?

Schematics here: http://www.mattmillman.com/wp-content/files/mcs48programmer.pdf
[/old text]

[trondl]

Another discovery: EA is actually pulled rather high actually, about 12.9V on my DMM, and there is a spike at the start also.
I've included the screenshot I did to compare EA enable and Reset to check for a dump start before EA was stable.
That may explain why the 8749 has no issues, where the 8049 should have a very close to 12V applied.
Could this be an explanation for the freakout / noisy waveforms?
I could try to lift EA and apply directly from the shields Vin from Arduino, giving a continuous stable 11.5V.

It still doesn't explain why there is no 5V idle on the 8049 Databus though.

I'm tempted to do a basic breadboard version as done here: http://qemulator.blogspot.com/2020/05/dumping-intel-8049-roms.html
Should have more control over voltages and such.

The second MCU from Japan is verified in the unit I'm repairing, so that is a relief at least.

[ooops]
I tried to lift Vin and apply directly to EA.
Now the arduino shield is no longer detected :S :S :S
My impatience is starting to show.
[/ooops]

[trondl]

Nevermind again!
Shield and arduino fully working.
I panicked when all of a sudden the default COM port was changed in the HvEprom app.

[trondl]

Very late update here.
I've been pondering for the last two years about whether the data bus needs a buffer or transceiver in between to get the signals to behave.

I read a bit further in the service manual about how the pins are by default configured and that the data bus is by default an output.

Then a noteworthy observation struck me: The T0 pin (pin 1) is used to configure the MCU in SDE-1000 or SDE-3000 mode (it's bigger brother).
Pull T0 to 5V and it's in SDE-1000 mode, and to ground it's in SDE-3000 mode.

I have a hunch that if T0 is floating at start up, which it most likely is during startup on the programmer, the code will crash as it is in an illegal state, causing weird things to happen.

Am I on to something here?
If my knowledge is correct, T0 is also used to set programming (0V) and verify (5v) mode.
In Intel's suggested ROM verify procedure, T0 is not mentioned, only the EPROM programming procedure mention the T0 usage.

Suggestion:
I could tie T0 permanently to 5V from VCC or the Arduino as that would both set SDE-1000 and Verify mode, which is my goal here.
Worth a try?
In the SDE-1000 it is tied directly to 5V, but should I be on the safe side and put a current limiting resistor of some value between?
In the SDE-3000 it is tied directly to ground.

When dumping, I should get the whole code, not just the code for which SDE mode it is in?

[wraper]

In the SDE-1000 it is tied directly to 5V, but should I be on the safe side and put a current limiting resistor of some value between?
In the SDE-3000 it is tied directly to ground.

You can tie it directly however it's better to use a resistor, say 1k. As it's possible to configure this input as CLK out.

[trondl]

Lifting T0 to 5V did nothing different.
Random probing around, I found VDD to be 4.5V.
I'm tempted to lift and tie VDD to VCC for a stable 5V.
VDD is only boosted during programming.
The Intel datasheet claims VCC = VDD = 5V during verification.
Should be safe hopefully

[trondl]

Tying VDD to VCC helped VDD with getting proper 5V, but no stable data bus yet, apart from a slightly higher idle voltage on said bus(may be a hint to what is going on?).
Either a jump in voltage and/or a buffer / transceiver in between is my next agenda.
I fear putting more than 5V on the Arduino data bus may not be the best idea if a higher VCC / VDD also affects the data bus level.
From what I gather, VDD is powering the RAM and controlling the MCU power mode (idle / standby).

The data bus should idle at 5V as the 8749H does, but as mentioned the 80c49 idles around 1.5V.
Is this a case for a stronger pullup?
No pullups in the circuit as it is direct to the Arduino.
The waveforms looks like what I can imagine a 3.3V device quarrelling with a 5V device looks like.
The Arduino is a 5V device so it shouldn't be the case.
Could this also be an issue where the programmer is designed around HMOS (8749H), not CMOS (80C49)?

Putting a 74245 (HCT or LS?) in between shouldn't be too hard?
The most practical way for controlling the direction is where I may need some guidance though.