An easy to build MCS-48 (8748 / 8749 / 8741 / 8742 / 8048 / 8049 / 8050 / 8755) Programmer / Reader

Recently I was repairing an old piece of equipment which was based on Intel’s first microcontroller: The MCS-48.

The nice thing about the MCS-48 is that it largely predates the concept of code security. With the exception of some newer dated parts, usually 8042 / 8049, if you’ve got the thing, you can steal the code from it, disassemble it, and learn lots about the equipment it’s fitted to.

In the past I have built a series of Arduino shields for programming old UV erasable devices for which programming hardware is difficult to come by (read more here). This is not so much the case for MCS-48 as hardware can be obtained for a hundred dollars or so, however, I wasn’t going to pass up on the opportunity to build another one of these, and, mine can be built for less money plus it has the ability to read mask ROMs.

At the same time as I designed the shield, I also built an entirely new project based on one of these. More about that here.

Programming and reading the list of devices mentioned in the title requires quite a range of different voltages including 5V, 12V, 18V, 21V, 23V and 25V. This programmer can generate all of them and software select between them as needed.

Supported devices

Regular UV erasable MCS-48

Parts 8748 and 8749. Vpp = 21V.

These were made also made under license by NEC. This programmer supports both NEC and Intel parts.

UV erasable UPI-41/42

Parts 8741 and 8742. Vpp = 21V for 8742. Vpp = 25V for 8741.

As with above, NEC parts also supported.

Mask ROM MCS-48

Read code only. Parts 8048, 8049 and 8050. EA = 12V. Note that not all MCS-48 mask ROM parts will allow the code to be read out.

8755A

An adapter is required to program the 8755A. There is a little bit of backstory about it here.

Build resources are linked to at the end of the page.

Warning to those building other designs

All home-brew MCS-48 programmers have pin drivers resembling the above, mine differs in that it uses a P-Ch FET to get the fastest possible rise time, and a 2K2 “pull-down” is also present to keep fall times within specification (< 2μS).

This is particularly important when programming CMOS parts, otherwise the timings specified in Intel datasheets cannot be achieved, instead arbitrary delays would have to be inserted throughout the programming algorithm to allow charge to bleed away from these inputs, as is frequently seen in other efforts.

The most important difference however, is the 220Ω resistor. Some batches (particularly 8742’s and some 8749’s) are very sensitive to over-current on the PROG pin. I purchased about 50 MCS-48 samples when designing my programmer, and blew a quarter of them discovering this.

This value was chosen because it reliably programs the earliest 1K NMOS parts, which require more current on this pin, and don’t appear to have this problem, while not destroying sensitive 2K parts.

Host software / firmware

Please see the main project page for more information.

Schematic

  • Can be downloaded from here.

Gerbers

There are two versions of the gerbers. A “Long” version which has the exact dimensions of an Arduino Mega. Choose this if your PCB house doesn’t charge extra for exceeding 100x100mm dimensions. Total size is 101.5mm x 53.5mm.

The “Short” version has the tab at the end clipped to keep it under 100mm. Total size is 99.95mm x 53.5mm.

BOM

Can be downloaded from here (or here CSV).

8755A Adapter

The 8755A adapter only has 3 parts:

  • 0.1uF (or whatever) bypass capacitor.
  • Samtec APA-640-T-A 40 position IC plug. These are a little difficult to come by. Instead have a search around for “male IC pins” there are various snap off types available. I wouldn’t recommend using regular 2.54″ pin headers as they’ll potentially damage the socket in the base unit.
  • 3M 240-3346 40 pin IC socket (anything roughly this form factor will do).

48 thoughts on “An easy to build MCS-48 (8748 / 8749 / 8741 / 8742 / 8048 / 8049 / 8050 / 8755) Programmer / Reader

  1. What a great compact little Intel 8749 programmer! Got the PCB made – can’t wait to try it out.
    Didn’t think I’d find one for this old mcu chip.

  2. Hi Matt,

    I’m building your MCS-48 reader and ordered the parts at Mouser, but the transistors are going to take until October to be restocked which is not ideal.

    Are there any equivalent transistors that would fit the bill?

    Thank you for your great projects!

      1. Thank you!

        I’ll send you some pictures once I have it complete.

        Later I’d like to build your 2708 reader too, as they are quite complicated to dump.

        Best regards,
        Rob

  3. Very interesting project. I might decide to build one just for the fun of it 😉 But with your experience, do you know any way to read a 8749 device? The datasheet doesn’t mention anything in this regard.

    All the best, Marcel

    1. Reading is explained in the datasheet. This project does it, source code and schematics all available of course.

  4. Ooops, of course your right, I only remembered the combined “program/verify” cycle. Cool, I’ll give it a try when I’m again ordering some PCB, thanks!

    1. P.S.: Turns out I’m not completely insane, the original P8049/P8749 datasheet only specifies reading of ROM chips. The later D8749 datasheet also shows a verify mode 😉 In any case, good to know that it works, thanks!

  5. OK, technically I don’t *really* need a programmer, but this is so cool that I went ahead and built one anyway 😉 https://www.kilgus.net/images/mcs-48.jpg is the result. Haven’t done this much through-hole in quite some time 😮 But worked perfectly on the first try, yay! I should probably now to continue to write the MCS-48 plug-in for IDA Pro…

    One comment, the avrdude supplied with my Arduino IDE needed “-c wiring” as a parameter instead of “-c arduino” to work.

    Anyway, great stuff, thank you!

      1. And Hex Rays wrote to me that nobody has ever requested a MCS-48 CPU module from the before 😉 So I started writing one based on the MCS-51, but it’s still tedious work and there is the slight chance that he original author of the code I’m after recovers the sources some time…
        The free Ghidra has MCS-48 support, but so far I’m not liking the user interface too much.

      1. I think I’ve got some left over. As a software engineer I hate shipping physical stuff, but I guess this one is easy enough within Europe. You can contact me through my web-page (click on the name).

  6. Hei!
    Anyone close to Norway and/or willing to let me borrow or sell a kit/complete unit here?
    I’m trying to resurrect a Roland SDE-1000 mono delay with a veeeery temperature sensitive 80c49 (Crashes above 12 degC), so I need to dump the maskROM while it is freezing cold and burn a 87c49.
    Really hope there is someone willing to help here as I’ve spent years to diagnose this problem.
    Thanks in advance!

    1. Sounds like a daring adventure. I didn’t have much success dumping mask rom MCS-48s. I purchased 10 or so off eBay and only 2 could be read out.

        1. Least you can buy it if unable to! Programming a new 8749 will be a piece of cake if you have the programmer.

          1. I’ve built it!
            Tried with an empty 8749 and burned a test image, and succeeded 😀
            Now, my problem is that after desoldering the 8049, it is even more temperature sensitive.
            I cannot get two identical dumps, even after cooling it.
            I installed a socket in the unit to be repaired, and have made the mcu work again for about a minute after heavy cooling.

            Windows GUI feature suggestion:
            Since I have no way of verifying that the mcu is actually working at the moment the dump is made.
            I have tried to compare two successive dumps in HxD a couple of times with no identical dumps.
            Now, wouldn’t it be easier if there was an automated compare function?
            The function would look something like this:
            Dump, dump again and compare, if not the same; dump again etc. for X amount of retries.
            Ideally getting two, three or more identical dumps.
            Would this be an easy addition?

          2. How different are the dumps? If they are significantly different, your 8049 probably has read out disabled, and the programmer is just reading whatever is sitting on the bus I.e. remnants of the address cycle.

          3. Somewhat random indeed.
            But here is the problem, the mcu is _very_ unstable.
            9 of 10 times it crashes, if not the perfect temperature is reached.
            Also, most of the other maskROMs from the same producer and era have been dumped, according to that link i posted earlier.

            I do get the VIN voltage low warning though, about 11.4V.
            Could this be something to investigate?
            The 8749 had no problems whatsoever.

          4. Also what I see with my DSO on the Digital pins 0-7 is that D0-3 gives a steady wave of data, but D4-7 gives something that looks like bursts.

          5. I believe it says in later versions of the 8049 datasheet that mask ROM customers have the option of disabling code read outs of any sort including the trick you have mentioned. I have quite a few samples here which cannot be read out with any trickery, short of decapping and looking at the ROM under a microscope.

            I’ve not seen that mentioned in any of the 8048 datasheets however.

          6. The VIN warning though (11.4V), could that cause an issue?
            Thanks a bunch for the help so far!
            Even if this project is a dud, I’ll still have plenty of use for the shield.
            Many early 80s synths used this mcu.

          7. I’ve just spoken to a guy in Portugal who sells most of the Roland/Korg and others 804x’s as eprom substitutes, and verified that he had _never_ encountered a Roland 8048 or 49 that was protected, although aware of the possibility from other manufacturers.
            It would be weird if my chip is the only one being protected.
            He is using the old industrial programmers to dump them though.

            Also, I have again verified that the mcu is functional at -5 degC outside here in Norway today.
            Tried dumping it in the very same conditions, but got exactly the same semi-random noise as previously.
            The weird thing is that many of the values appear to be repetitions of previous values.

            Before I send my mcu in the mail to Portugal and risk losing it in the process, I have one more possible solution:

            This thread talks about more or less the very same experience I have:
            https://forums.arcade-museum.com/threads/stumped-random-eprom-readings-need-input-from-eprom-gurus.320383/

            The verdict seems to be somewhat that worn/failing chips may have a much slower access time.
            One programmer had correct dumps all the time at slower speeds, and the one with just garbage had higher read speed.

            This could also explain why the output of the D pins 4 to 7 appear as bursts instead of a stable pulse train?

            How close to the MCS48 specs is the Windows Gui reading the code?
            Could there be a way to select the read/serial speed to the lowest possible / “Fail Safe” option in the application?
            Also, it there could be stability issues if too slow, a “medium” setting.

            I would be _very_ grateful if such an option existed, even if it was just in the command line version.

            Thanks again!

          8. Just one last question:
            What are the relevant sections/lines for the reading delays?
            I could experiment, but I see that I would easily get lost in red herrings.
            Thanks again for your time!

          9. Lines 107 and 109 (pgm_mcs48_delay_4tcy, pgm_mcs48_delay_pre_read) are probably going to make the most difference. Try steadily bumping those numbers up.

            Follow these instructions to setup the compiler:
            https://github.com/inaxeon/eightoduino/blob/master/app_hveprom/how_to_compile.txt

            Otherwise, yeah, you can pretty much go slapping delays in where ever you please, so long as you don’t increase the programming pulse (which you won’t because you’ll not be modifying the write function) there is no risk of damaging anything

          10. I’m getting somewhere!
            Thanks a bunch for the build instructions!

            I have started a thread over at EEVblog, so if you don’t have the time for this (very understandable), don’t reply.
            You have been _very_ helpful.

            I’ve tried both long (100s of us) and very long delays (10ms), and I’m starting to see almost valid data somewhere in between.
            I have a ROM dump from the same producer, and they pad the remaining data with 00 01 02 03 to FF, so it is easy to see if it is just noise I get.
            What I found in common is that bit 6 and/or 5 gets stuck high, and that the data seems out of sequence, to illustrate: 00 01 02 07 02 01 01 01 05 03 04

            Addressing, pull-down/up resistors, the “VIN low” warning (11.4V, not 12V) or timing issues?

          11. You can ignore the Vin warning. It’s actually mostly for the 2708 where this is important, for MCS-48, it’s main purpose to ensure that you’ve at least connected the +12V supply, granted it could be a little more generous on the range. There is an option to disable it in the setup dialog no?

          12. The was a checkbox!
            Could you clarify “delay_4tcy” and “delay_pre_read”?
            Is 4tcy referring to the 4 minimum clock cycles needed to reset?
            I probed the Reset during a dump, and it was in bursts toggled 8 times very quickly, maybe too quick for it to properly reset.
            Is “pgm_mcs48_reset” somehow involved?

            When it is working in the unit, the reset time is 250ms, but that is only done once.

            I’m starting to get a picture of how the process is sequenced, and I think that the delay from the address is selected to the data being stable and present on the D pins is too short.

            If you could give me a list of the names in the sequence I could delay, I’m happy to “go to town”

          13. 8 pulses of reset is expected. If you look at the datasheet i.e. https://www.ceibo.com/eng/datasheets/Intel-8048-8049-8050-plcc-dip.pdf on the last page you can see that reset needs to be asserted once per byte read. My programmer reads and writes in bursts of 8 bytes because 8 bytes + protocol overhead fits comfortably into a 16550A FIFO, which A) doesn’t have true hardware flow control, and B) the C#/.NET interface is too shitty to work properly with the emulated hardware flow in the Windows kernel.

            As for the matter at hand, it is possible that the MCS48 isn’t latching in the address cycle fast enough. 4TCY is indeed a very rough approximation of the 4 clock cycle delay period, actually I think my delay is a bit longer.

            The addresses is latched in at line 464 (pgm_mcs48_8755_reset_or_ale_disable). Perhaps try an extra delay at line 465, or perhaps more delays after line 463.

            When you delve deeply into this, you will discover, as I did, that it is a bit mysterious as to how the MCS-48 internally sequences the programming/verify cycles. I think the MCU core is actually beavering away executing a bit of microcode while this process is running which is rather different to how an EPROM is programmed.

  7. The Xf551 Atari 8-bits disk drive uses an 8040 and usually an eprom for the firmware. However, I got in my hands a drive without eprom with an 8050 without eprom. Nobody, that I know of in the Atari community, has been able to dump the firmware of this version of the 8050.
    As part of this preservation effort and kind of Indiana Jones endeavor, I would like to contact someone willing to try to extract the fiwmare from this 8050 chip.
    manterola@hotmail

  8. Thanks for this great project! I had to substitute one of the transistors (821-BC547B-A1 for 512-BC547B) which worked just fine. I also ended up using standard length headers because the extra long ones were backordered for months.

    The programmer allowed me to burn a new BIOS into a 8748 for a Magnavox Odyssey 2 game console, and brought it back from the dead.

    Just as a data point, all of the testing/burning/reading was done via CLI on a Linux Mint system.

  9. Any thoughts on reading the Philips MAB8441s? These appear to be a step up from the intel 8021 device in the size of ROM on board is 4K instead of the original 1K and the RAM is 128×8 in place of the original 64×8 – the pinout is the same. I assume the MAB84XX series is Philips numbering for their remake of the Intel MCS-48 series.
    I am trying to read a MAB8441 used for CD-Players from the late 80s and use that info to possibly recreate the chip with FPGA or similar.
    There is a Port Expander (for 8243 I/O Expander) PROG line that may enable reading of the ROM code.
    I also tracked down some 8401s which have a piggyback EPROM to verify good reads.
    I can’t find any Intel reference books after 1980 that are devoted to the MCS-48 series, Bitsavers, Archive.org, and the other repositories that I searched don’t seem to acknowledge the devices after 1980 – at least enough to have their own book – or I’m just looking in all the wrong places… It would be nice to find a Philips Data book on the MAB84xx series.
    Thanks!

    1. You’ve certainly thought about it more than I have! It’s not something I’d be adding myself as < 40 pin devices are rarely readable / programmable / used. Pinout of course is wrong for such a device, so an adapter would be needed. Some software changes too.

  10. If have the Command line Code built for Debian Linux Ver 11- 64 bit. The USB to Serial
    adapters now use /dev/ttyACM0 or /dev/ttyUSB0 versus /dev/ttyS{1..4}. You usage states
    /dev/ttyS?, so my question is does your code allow and work with /dev/ttyACM0?

    Do you know of a good Source for Intel or NEC 8749 Microcontrollers?

    Thanks.

    Larry

Leave a Reply

Your email address will not be published. Required fields are marked *