Intel MCS-48 (8749 / 8049) HMOS vs CMOS differences, bus driver? (Dumping woe) - Page 1
Forum section: electronics / projects

author: trondl
author_rank: Regular Contributor
timestamp: March 14, 2024, 10:29:40 pm
content: Hi!FYI, this is a continuation of this thread:https://www.eevblog.com/forum/microcontrollers/need-help-dumping-the-rom-in-a-failing-80c49-(mcs-48)/I decided to start fresh as I've discovered some new potential solutions, and the old thread is full of newbie red herrings (me being the newbie, still am in many ways).I'm jumping straight to the questions regarding an unstable bi-directional bus during a maskROM dump and you may see where they come from further down:1. Is there a substantial difference between HMOS and CMOS bidirectional databus drive capabilities?2. Is an Intel M8216 "equivalent" to a 74LS/HCT245 in function, especially regarding the bus direction? The problem here is that it has to operate bidirectionally.3. Is a 10K pull-up a bad idea on a bi-directional databus, and what negative side effects may it have?This Arduino programmer hat is used, and my ideas are around this project:https://www.mattmillman.com/projects/hveprom-project/an-easy-to-build-mcs-48-8748-8749-8741-8742-8048-8049-programmer-reader/Schematics:https://www.mattmillman.com/wp-content/files/mcs48programmer.pdfMCS-48 dumping (verify) routine at page 46 here:http://www.bitsavers.org/components/intel/8048/1980_MCS-48_Users_Manual.pdfalso another confusing / contradicting datasheet regarding pin T0 and P1-0 / P1-1 on page 11:https://wiki.console5.com/tw/images/4/4a/MCS-48.pdfMy problem is that I am attempting to rescue the code from a failing 8049C (note theC), which fails miserably in the programmer with tons noise on the bi-directional Data bus.(See first image in this post:https://www.eevblog.com/forum/microcontrollers/need-help-dumping-the-rom-in-a-failing-80c49-(mcs-48)/msg4066693/#msg4066693)The same behavior is also identical with aworking8049C pulled from another unit intended to be the savior of this problem.The programmer works flawlessly in programming and reading an 8749H (note theH)This gave me a thought that it may be related to a potential bus drive capability difference between HMOS and CMOS.On the programmer, the bidirectional databus is connected straight through to the Arduino.I believe this is where the problem lies.It seems to be sufficient with HMOS, but may struggle with CMOS.In the MCS-48 catalog, two Intel M8216 4-bit parallel bidirectional bus drivers are used to split the bidirectional bus into dedicated inputs and outputs.Also a 7474 (LS ?) is used to sync ALE with RESET and switch bus direction on the 8216.Could a row of 10k pull-up resistors on the bus do the trick?Or is it more likely that using a 74LS or HCT245 bus driver is the best solution to stabilize it?An extra top hat with a 74245 and jumpers to let certain pins float seems like the most likely, then again, a resistor array should be easier to tack on to the hat.I could try to replace the 7805 with a 7806 as some sources suggest to overvolt when unstable, but I'd rather try other solutions first.Confusion also arises when there are inconsistencies about what to do with the PROG, T0, P1-0 and P1-1 pins during a dump.The programmer has P1-0 ad P1-1 permanently tied to ground, PROG and T0 gets 5V during a read.Some sources claim to let PROG and T0 float at the very least.Have tried to lift them all, but no change in the bus behavior.VDD is 4.5V due to a diode between the 5V rail. I have tried to tie it to VCC with no change other than a stable 5V.Thanks for your time and input!

author: iMo
author_rank: Super Contributor
timestamp: March 14, 2024, 11:07:34 pm
content: Last time I messed with the stuff you do was in mid 80ties - so take it as some thoughts only:1. Arduino with its 5V Vcc should work fine with any NMOS or CMOS 5V chips in this Universe2. there is a difference in NMOS and CMOS i/o drive capabilities, sure, but not relevant for your case, imho3. also mind there are chips with a "minimal" clock frequency as well, especially those NMOS types4. 10k pullup resistors may help5. no need to use any buffers - it only adds up another source of potential issues, in opposite - ie. 1k series resistors in the data (etc) lines may help when there are some issues with timing/levels (ie. the 2 outputs on the same line fight against each other), the 390ohm-1k resistors are the best bidi drivers (mind Sir CliveS)6. double check the output levels of your DUT chip first7. triple check your wiring, your code8. have you ever tried to read the DUT chip in a different programmer? There are many to get from ebay/ali..

author: PCB.Wiz
author_rank: Super Contributor
timestamp: March 15, 2024, 12:15:32 am
content: Quote from: trondl on March 14, 2024, 10:29:40 pmWhere do you get CMOS from ?As best I can tell a 8049C is a NMOS Mask ROM part from NEC.It would need to be 80C49 to be a CMOS part, and I think OKI made 80C49 parts.Your link above also says thisNote that not all MCS-48 mask ROM parts will allow the code to be read out.

author: trondl
author_rank: Regular Contributor
timestamp: March 16, 2024, 05:38:19 pm
content: Thanks for the input!Correction: The chip is a 80C49, not a 8049C. Didn't know there was a difference. Now I do (Thanks again!).The official part number is MSM80C49-44RS. It is used in both a Roland SDE-1000 and SDE-3000.Keep in mind that the chip I'm dumping is marginal, but works when frozen to bellow 10 degrees Celcius.The same behavior is present with a working chip. Therefore I'm "sacrificing" the failing one to iron out the issues.Quote from: iMo on March 14, 2024, 11:07:34 pm1. I still believe that a bump to 6V may at one point be necessary if all else has been tried.3. The programmer clocks the chip 4MHz. In the DUT, it clocks at 11MHz.Could be an issue?Need to research the differences between the MCU manufacturers.4. Will try it!Although the Arduino does have programmable pull-up on the lines, I don't know if they are used in the program it is running.Could dig into the source code though.If it actually is activating the internal pull-ups on the Arduino, could a pull-up in the 10-20K region cause instabilities as seen here?5. I have tried with series resistors in the 220-330 range (don't remember exactly). No change.My stomach tells me that the Arduino and IC fights over the line, or struggle to stabilize.When zoomed in on the DSO on a random data line, on the working 8749H the edges are clean and no visible distortion or timing issues.On the 80C49, the line is total chaos, and it seems like the line doesn't want to go low.The only thing that seems to have a hint of logic is the address input if I'm reading it to some degree correctly.Almost as if low is 1.5V and 5V is high, but very unstable.Another important note is that after a dump on the 8749H, the data lines idle at 5V, which may be driven by the Arduino as VCC and VDD is turned off (IIRC!).On the 80C49, it idles at around 1.5V in "no mans land", which may hint at something I don't understand yet.Also, VCC should be 0V when idle according to the 8749H, but VCC is also around 1.5V as the data lines do. VCC is 5V when reading though.Is CMOS driving the line low and "resting" high by design?I'm trying to massage the data lines into behaving with as little strain on the MCU as possible, therefore buffers came to mind, also the idea of VCC not being strong enough.7. The code (not made by me, I'm far from a coder) and hat works with the 8749H, both reading and writing.8. I did try a very archaic breadboard setup, but that gained nothing.There aren't that many programmers on the market here in Norway, most of them expensive (E)EPROM variants only.Haven't seen any with MCU-48 capability yet. Am searching though.I do have a TL866-II+, which only go as far back as MCS-51. Hopefully in the future at least MCS-48 reading could be supported.Any recommendations are welcome, although shipping to Norway and the recentinsaneimport fees makes local only the most sane option.Quote from: PCB.Wiz on March 15, 2024, 12:15:32 amThanks for explaining the differences!That should make this an OKI chip. Needs to be researched.Note that the designer of the programmer struggled with dumping a lot of chips and concluded that they must be security locked.I have averystrong hunch that the design of the programmer is based on the HMOS data sheet, and something has changed in later revisions of the chip design causing incompatibilities.Also, some say that noise/instabilities shouldn't happen on a locked chip, and even further, some say that the MCS-48 predates the technology to security lock.The biggest motivation here for me is thatmany8048/49 from the same synthesizer / audio manufacturers (Roland and Korg especially) from that era are dumped and made available.It doesn't make any sense that one product from the same manufacturer is locked and the other 5-6 from the same year is not locked, especially when the one is the cheapest of them.

author: trondl
author_rank: Regular Contributor
timestamp: March 16, 2024, 06:22:53 pm
content: Another thought just appeared now when reading the OKI data sheet (attached).There seems to be some additions made by OKI, and some of them seems to be around power saving modes and that there seems to be more floating of the pins than Intel intended, if I understand it.Worth further investigation?Also rated VCC is actually 4-6V, so it seems to be expecting 6VCC to "perform its best".

author: PCB.Wiz
author_rank: Super Contributor
timestamp: March 16, 2024, 09:59:56 pm
content: Quote from: trondl on March 16, 2024, 05:38:19 pmCan you find any dumps for your model ?The early 'ROM' models from intel may have been factory programmed EPROMS, so they would read the same.A newer part from a CMOS vendor, may existonlyin CMOS ROM form, and inability to read out the ROM easily, would have been a sales feature.They would still have some method to verify ROM in the factory, but it is not likely to need high voltage.

author: trondl
author_rank: Regular Contributor
timestamp: March 17, 2024, 08:03:27 pm
content: Quote from: PCB.Wiz on March 16, 2024, 09:59:56 pmSadly, this one hasn't been dumped yet, and I've been on this resurrection project for years (10 years to be specific).It is also a problem I've seen multiple times reported from others with the same issue, regarding a failing MCU in the Roland SDE-1000 and likely also the Roland SDE-3000 (identical ROM).I agree on the lock being a sales pitch but I still doubt it, although I fear that Roland choosing OKI in this case may have been a testing of waters as they mostly used Toshiba (TMS) at this point (1983-84).The Toshiba ones have been dumped (most of them at least). Haven't seen many OKIs dumped now that I've become aware of the difference.I've just read about power glitching MCUs to reveal its secrets.Probably worth a try in the future before decapping is considered.If anyone has a trick or two regarding the MCU-48, please chime in.I've heard about a way to start it up normally with EA pulled to 5V (normal high, not verify mode) and an external program that starts reading from $0000.Even single stepping in this condition is worth a try if no normal means are possible.No idea how that could be done easily though.