MCS-48 family, reprogrammed Intel 8749s not working - Page 1
Forum section: electronics / general

author: MJPIA
author_rank: Newbie
timestamp: August 13, 2025, 03:59:40 am
content: Gonna lead this off by stating I am far outside my knowledge zone, I can do damage with a soldering iron but code, programming, I'm completely out of my weight class learning as I go and there may be something incredibly simple I am overlooking that I just don't know enough to realize.I've been working on finding a path to restore dying AMC CeC MCUs used in various Jeeps and AMC Eagle cars to control the feedback carb and emissions systems from the early 80s to 1990, there are no aftermarket options outside replacing the carb and whole system entirely and these computers have spent the past 4 decades sitting directly above a heater core with no shutoff valve that is always at engine temp so there are very few in working order, 3 of the 4 computers I possess have various amounts of corrupted code and the fourth was good but the chip itself is unstable under load.They are controlled by an masked Intel 8049 which controls two high voltage driver chips, one for the carb stepper motor and the other for the emissions system.Since none of the various generic readers work on the MCS-48 family I ordered all the components and built one myself following Matt Millmans designhttps://www.mattmillman.com/projects/hveprom-project/an-easy-to-build-mcs-48-8748-8749-8741-8742-8048-8049-programmer-reader/After dumping several computers with bits of corrupted code I found one that was unstable above room temperature but when chilled with a peltier cooler worked and dumped what seemingly is good code from it.All of that is uploaded there in both the original .bin and disassembled assembly code.https://github.com/MJPIA/AMC-Jeep-CeC-MCU/tree/mainAll of the reading of the 8049 and writing of the 8479 was done through the program that is used for all of Matt Millmans readers.Put the 8049 in, hit the read button then saved as a .bin.Exposed the two 8749s I have for 15 minutes to UV lights, put them in the reader, hit the button to verify they were blank, loaded the .bin and let it do the blank, write verify cycle, which it seemingly did.Put the 8749 into the socket and it doesn't work at all, the device acts as if the CPU isn't even there, tried installing it into the jeep to see what it would do in a real world situation rather than a benchtop tester and with the engine running there was nothing coming from it.First step I tried was to verify all the traces were good and there were no shorts from the initial chip removal and installing the socket which seems fine.After that I dropped in the original 8049 I dumped from and it passes all the tests and controls the carb for a bit.I then tried my second 8049, went through the whole cycle and it seems to have programmed correctly and the exact same thing, no signs of life.I dumped and disassembled the code from the 8749s and put it in a text comparator and at a glance its identical to the original dump.I appear to have all the pieces of the puzzle, a good board, two seemingly good 8749s, a seemingly good programmer that has fairly dummy proof software to use it, but the pieces aren't going together and I don't know where to go from here or what I've done wrong.My first assumption would be operator error but unlike a command line system that my dyslexic self has to spell check frequently there's not much room for error when it comes to reading and writing these so I just don't know.If anyone has any suggestions I'm all ears.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 13, 2025, 04:23:20 am
content: Points to things may differ between mask and EPROM parts.An obvious one, is the PROG pin - google says that takes 18V during PGM, is it at a valid run level in the boards?You could also scope the pins, doing a comparison?

author: Adrian_Taylor333
author_rank: Regular Contributor
timestamp: August 13, 2025, 04:54:02 am
content: there are at least two versions of 8749 - 8749 and 8749H.They differ at least WRT programming voltage...

author: amyk
author_rank: Super Contributor
timestamp: August 13, 2025, 05:26:02 am
content: Program your 8749s with an LED blinker or similar program to check whether they are actually working first; the fact that you can program and verify them only means their EPROM works, not necessarily the rest of the MCU.

author: neillnz
author_rank: Contributor
timestamp: August 13, 2025, 09:06:36 am
content: As suggested above I think the best way forward would be to obtain the datsheets for the exact parts your have.With the two datasheets side by side look carefully for differences, starting with the pinout. If you find any differences in pin descriptions it could be the clue you need.If you are not sure what the pin description mean ask on here.Another way to tackle this, if you were very serious would be to reverse engineer the functionality and use a modern micro mounted onto a 40 pin DIP carrier. Not an easy task but possible.

author: bobxyz
author_rank: Contributor
timestamp: August 13, 2025, 06:18:36 pm
content: Using an oscilloscope, walk around the CPU pins and make sure they all look reasonable. Especially check: EA, XTAL1, XTAL2, RESET, Vcc, Vdd.If you haven't found it already, bitsavers.org has a bunch of Intel and National databooks for the MCS-48 chips. You may need to rummage around a bit to find all the relevant datasheets and microprocessor/microcontroller/embedded controller handbooks.What are the exact part numbers of the original and EPROM chips?

author: iMo
author_rank: Super Contributor
timestamp: August 13, 2025, 06:31:37 pm
content: Doublecheck the EA pin - the masked version may ignore it, but 8749 needs it high, I think..

author: floobydust
author_rank: Super Contributor
timestamp: August 13, 2025, 08:01:57 pm
content: Take a look at the hex file and see if it is 100% used, that there is code right to the end.It might be that this is a special MCU with more memory, and you are only reading out part of the code.Try read out beyond that, see what you get.2KB of EPROM is not much, not enough for an ECU really. Maybe it's an 8050 etc.

author: Adrian_Taylor333
author_rank: Regular Contributor
timestamp: August 14, 2025, 12:18:00 am
content: BTW, if it's not a secret, where have you procured your 8749 ?Have you found a decent cheap source ?I'd need a couple myself...

author: amyk
author_rank: Super Contributor
timestamp: August 14, 2025, 01:25:02 am
content: Quote from: floobydust on August 13, 2025, 08:01:57 pmThis is an 80s design. 2k, used well, can definitely be enough for the sort of simple control loop that you'd expect.

author: floobydust
author_rank: Super Contributor
timestamp: August 14, 2025, 01:48:17 am
content: An electronic carb ECU is likely just a (solenoid) fuel trim based on the O2 sensor, for the closed-loop system to meet emissions.Mid-80's GM and Denso were using 4KB and the Speed-Density system. Most of that code is lookup tables, ignition spark advance included. For the MHz clock speed it is quite impressive. You can't do much if any math.I hope OP's issue is just an improper (code size) read of the MCU F/W, or maybe bad programming of the new part. But a programmed part verifies OK.

author: MJPIA
author_rank: Newbie
timestamp: August 14, 2025, 03:38:27 am
content: Holy cow I did not expect so many responses, I'll follow up with what I can.Both my chips are D8749H's which I bought from ebay.The original chips are labeled 6003KN001 made by national semiconductor which you'll find nothing on.Other components also have custom Ford silkscreening on so I assume its a Ford number but have never seen the guts of Fords earliest feedback carb systems to compare against.If you are interested the white paper from 1980 on the system is herehttps://moscow.sci-hub.se/3022/3011d9d510f0169a457098d534d109d9/hittler1980.pdfThere are no fuel maps, there are no analog sensors, there is no crank sensor so the engine does not know what cylinder it is on, it just knows when its firing based on signals from the distributor.All it does it glance at sensors to know what mode to be in and otherwise stares at the input from the oxygen sensor and endlessly chases stoich aka a 14.7 air fuel ratio.Its so simple they use the same computer for the 4.2l 6 cylinder with a 2 barrel stepper motor controlled carb and a 2.5l 4 cylinder that uses an solenoid on a single barrel that cycles on and off with the only difference being jumpers.American motors was constantly teetering on the edge of bankrupcy and didn't invest anything into these and used 4 minorly different revisions of the same system for an entire decade with essentially no change in hardware, in 1983 when they added a pulse air system to inject air into the exhaust rather than adding an external prom they simply deleted the check engine light and self diagnostic system to make room for the code to run 3 solenoids.Went through the schematic to probe all 40 pins to the headers and everything seems to show the correct resistance values.The programmer is mounted to a sainsmart mega clone.The software has 10 tests to cycle through.It says everything should be within 5%, I didn't notice before but for test 1 pin 26 was fractionally above 5% and test 2 pin 7 was 6.7% high, every other test is good though including the programming voltages.Looking at the datasheet unless I'm misreading something it doesn't do anything at 12V and the programming voltages seem to match so I'm not sure if thats worth hunting down or not.QuoteThe tenth test is 8 pins where you flip bits, all 8 of them tested as it should.I tested all the pins that see voltage while it was programming the chip I reerased and everything seemed to match the datasheet specs for the D8749H.This is the unstable original chip vs a reprogrammed 8749 on the benchI tried both in a running Jeep, the original one attempts to control the stepper even after getting flaky and activates the emissions solenoids, the 8749does absolutely nothing.Its possible there is some issue with the board but it doesn't keep the failing chip from tryingI could covert another one of the MCU's into a testbed, problem is I only have one option currently for that and when the solenoid diodes short they blow one of the drivers and this one has that issue.It is a long term goal to also find a replacement with those but until I figure out what those silkscreened chips are its just sitting there and I can't fiddle with the other computer that is corrupted but works enough to drive.I'm trying to work on making a simple led flasher and see if that has any life.Quote from: neillnz on August 13, 2025, 09:06:36 amI'm not sure thats something I can do but the idea fascinates me so if you have any posts of anyone who did similar things I'd love to read those.There's someone on the AMC Eagle side of things that has also dabbled in researching these computers and even if it doesn't help me it may be of interest to him.

author: Adrian_Taylor333
author_rank: Regular Contributor
timestamp: August 14, 2025, 04:51:14 am
content: Quote from: iMo on August 13, 2025, 06:31:37 pmDatasheet say that it needs to be low as it is active high.Datasheet also hints that 80xx (ROM) line and 87xx(EPROM) lines differ only in enclosure, underlying chip being the same.Some signals are listed as active on 80xx line during verification both lines behaving the same outside of that.But still, as there were quite few fuckups in that era, EA pin difference might be well one of those.@MJPIA:If you have cheap source for those that you'd care to share, I'd be grateful.I'd love to have it for retro computing projects.8049 was used by Sinclair for their QL as a SPC == Second Processor and to play with it one needs 8749...

author: bobxyz
author_rank: Contributor
timestamp: August 14, 2025, 04:52:47 am
content: I just looked at the first line of your disassembled code in the "Good CeC Assembly raw binary" file:Code:0000 F5 SEL MB1This selects the upper 2KB of the 4KB code space, which doesn't exist in the 2KB EPROM D8749H chip, but does exist in a mask rom INS8050 chip. Can you modify your custom programmer Arduino code to read out 4KB from the original chip to see if the upper 2KB is different than the lower 2KB?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 14, 2025, 04:54:07 am
content: Quote from: MJPIA on August 14, 2025, 03:38:27 amIf you have a scope, you can run a simple test on a veroboard ZIF, by looping code that toggles all P0,P2 pins as a counter.Loop:INC AOUTL P1,AOUTL P2,AJMP LOOP

author: squadchannel
author_rank: Frequent Contributor
timestamp: August 14, 2025, 05:12:54 am
content: Quote from: bobxyz on August 14, 2025, 04:52:47 amno 4K EPROM model for the MCS-48, the only options are to use a piggyback 8750(NS87P50) or to create the adapter board of 8040 with external ROM.

author: Adrian_Taylor333
author_rank: Regular Contributor
timestamp: August 14, 2025, 05:21:44 am
content: Quote from: squadchannel on August 14, 2025, 05:12:54 amBut if you do that, you lose most of I/O pins, so that's probably no-go.Unless the PCB already uses external bus option and has allocated the pins for that.Which is highly unlikely.

author: picburner
author_rank: Frequent Contributor
timestamp: August 14, 2025, 08:27:36 am
content: It's also worth considering that the one mounted on the board isn't a standard 8049, but could be a custom product and therefore might have something different than the standard device (i.e. more memory).Besides, the chip's label says "+AA8741B," so it would be more logical to think of an 8741 which is compatible with the MCS-48 family but isn't the same as an 8749.

author: MJPIA
author_rank: Newbie
timestamp: August 14, 2025, 11:48:55 am
content: Quote from: bobxyz on August 14, 2025, 04:52:47 amThe reader can do 8050s, I will give that a shot in a couple hours.Quote from: picburner on August 14, 2025, 08:27:36 amFor what its worth the other chips I have all say 6003KN001 and above it one says +AA8902B, another says +B8646 and a third says +AA8741BQuote from: Adrian_Taylor333 on August 14, 2025, 04:51:14 amAll I did was go to ebay, check the US only toggle and grabbed two that seemed a reasonable price

author: MJPIA
author_rank: Newbie
timestamp: August 14, 2025, 05:11:12 pm
content: bobxyz solved it.Its an 8050 which would explain it, I was trying to run it with 1700 lines of code missing.Theres only one other person I've found who put work into deciphering these systems and his had an 8049, my code was slightly different but resembled his so I assumed it matched which obviously was an mistake.I probably would not have figured this out or had taken much longer so thanks for the assist.I guess on to plan b, whatever that is.The AMC CeC tester does have an NS87P50D in it along with piggyback cart is I suppose thats a path I could take if I just yank the emulator chip.I am kinda worried about availability of those chips if something goes wrong and I break it, I may be looking in the wrong places but they don't seem to be very common and those that do pop up are a bit expensive.

author: Adrian_Taylor333
author_rank: Regular Contributor
timestamp: August 14, 2025, 05:55:30 pm
content: Natsemi NS8750D:https://www.ebay.com/p/2338065644

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 14, 2025, 07:37:54 pm
content: Quote from: MJPIA on August 14, 2025, 05:11:12 pmThe emulator chips are $$$ and a bit delicate for engine control.A bit more work, would be to morph the disassembly to run on a 89c51 variant?A small carrier board would manage the pin out differences.An emulator chip could still be useful to have a working bench unit to confirm you have correct disassembly and to work out some bench tests.

author: bobxyz
author_rank: Contributor
timestamp: August 14, 2025, 11:11:48 pm
content: @MPJIA - Thanks for the latest picture! Before seeing it, I had read the AMC pdf that you posted and was scratching my head over this quote:What a weird way to protect electronics.The Intel 8051 family of parts were the successor to the 8048 family. The 8051 has an EPROM version, D8751A, but it is not pinout compatible with the 8749. Long ago, Intel offered a software tool to convert 8048 assembly code into 8051 assembly code. The software, and the Intel blue box development station that it ran on, are probably long gone.Attached is a page from the 8051 architecture spec that mentions the tool.Fromhttps://bitsavers.org/components/intel/8051/8051_Microcomputer_Preliminary_Architectural_Specification_May80.pdf

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 15, 2025, 12:41:44 am
content: A quick scan of flash 51's part with bootloaders or ispThe older '51s have positive reset and reset sets ports to quasi (light pullups) which is more 8749 compatible.In this camp are Atmel AT89C51Rx, STC89C5x which can be 12T and 6T cores, but most are 85°C, which may be an issue?More modern '51's tend to move to active low reset and ports float during reset.Reset is easily inverted if externally driven, & you would need to check a circuit to see if floating pins during reset was an issue.Modern 1T Flash 51'sAT89LP51Rx still 85°C TQFP44and more modern, 1T 51's with calibrated on chip oscillators (and clock prescalers, so you can slow them right down to 8748 speeds)Nuvoton MG51LD1AE (quite new, but just out online) in LQFP482.4 V to 5.5 V -40°C to +105°CEFT 4.4 kV ESD HBM 7 kV - English Datahttps://direct.nuvoton.com/en/mg51ld1ae?search_query=MG51LD1AE&results=5https://direct.nuvoton.com/en/numaker-mg51ld?search_query=NuMaker-MG51LD&results=5Some STC parts are 125°C, they have many in tqfp48, and a good modern choice with USB bootloader is STC8H8K64U1.9-5.5V -40°C to +125°C, but newest data is Chinese only.https://www.stcaimcu.com/data/download/Datasheet/STC8H-EN.pdfSTC 1T are faster than Nuvoton 1T, as more opcodes are 1Tand there are STC8H8K64U LQFP48 boards with DIP40 8051 pinouts like thishttps://www.aliexpress.com/item/1005006837871248.htmlSTC have a STC8051U that is newer, but not many boards show up on Aliexpress for that yet.Other choices : not many rated for elevated temperatures.Addit : Silabs have Automotive C8051F5xx series, eg C8051F501-IQ 64KB 48TQFP1.8V ~ 5.25V -40°C ~ 125°Cin 48-TQFP and 48-QFN, more $, but still way cheaper than 8748 or piggyback parts.ABOV (Korean) show A96G140/A96G148 series 1.8~5.5V -40°C to +105°C in 44-48 pinsAddit2: I also found this, looks to be an iterative 8048 & 8051 disasm, useful as you will need labels etchttps://www.bipom.com/dis51.php- says "The package also contains disassemblers for 8035, 8041, 8048 and Z80."The D52 disassembler allows the user to specify memory areas as code, binary data (8 or 16 bit), ascii text, address tables, or data that should be ignored (not disassembled). You may specify such areas in an ascii text file with the same name as the file to be disassembled, but with an extension of ctl (for example: program.ctl contros the disassembly of program.hex or program.bin).With the use of a control file, you can, by an iterative process, get a progressively more meaningful disassembly by modifying the control file based on examination of the output of previous runs of the disassembler. You can also specify names for labels and symbols in the control file, resulting in a much more readable source file.Addit3: Another useful reference, A Macro Assembler for both 8048 and 8051https://github.com/sbprojects/sbasm3

author: peter-h
author_rank: Super Contributor
timestamp: August 15, 2025, 06:45:43 am
content: QuoteIt is just to make reverse engineering hard. Nothing to do with environmental protection.If they used plain epoxy or other resin, that can be dissolved, but sand apparently cannot be.I used to have an Intel 8048 family data book but looked for it the other day and no longer have it.

author: MJPIA
author_rank: Newbie
timestamp: August 16, 2025, 04:25:56 am
content: Appreciate the replies.Short term I'm gonna try two things, since someone has seemingly good disassembled code from a 1982 system with the 8049 and I have 8749s and all the tools I'm going to take a stab at seeing what happens if I drop that in, if only to satisfy my curiosity.The factory tester uses piggyback chips to switch between the 4 and 6 cylinder tests and theres a service bulletin for the unit that states that because of the similarities to simply use the 1981-84 chip and select 1984 to test any computers past that year.Only drawback to this is I don't have the original .bin, just the dissembled code and asm48 is constantly throwing syntax errors about different lines in it and I don't have the skillset, knowledge or most importantly time currently to figure out why so I'm hoping I can just get the original file if that guy pops up online which he doesn't much often anymore.The piggyback chips are also cheap enough and can be programmed with what I have on hand so I'm keeping the use of the NS8750D as a secondary if I absolutely have to plan until something more permanent comes about.Converting into the MCS-51 family is something I'm digging intoThe STC8H8K64U looks compelling, my biggest question is have people successfully converted systems running on MCS-48 family of things before?The only thing I've stumbled across is that person who made an adaptor and says he converted with some dos program called convert51 but didn't really offer details about the hardware sidehttp://www.8052mcu.com/forum/read/167016My searches are coming up pretty dryI am more of a visual learner than anything so being able to look at other conversions people did would be a huge boon to me.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 16, 2025, 06:12:40 am
content: Quote from: MJPIA on August 16, 2025, 04:25:56 amThe 8051 is derived from the 8048 and is a substantial superset, so it has a lot more capability than an 8048If you look at the test pages for the multi chip assembler I linked abovehttps://github.com/sbprojects/sbasm3/blob/master/test/opcodes/intel/8051.asmhttps://github.com/sbprojects/sbasm3/blob/master/test/opcodes/intel/80c48.asmA visual scan of those can give a quick idea on what is similar and different.Examples of what is similar:Code:;------------------------------------; DJNZ instruction 8048 8051;------------------------------------DJNZ R0,TEST DJNZ R0,BRANCH2DJNZ R1,TEST DJNZ R1,BRANCH2DJNZ R2,TEST DJNZ R2,BRANCH2DJNZ R3,TEST DJNZ R3,BRANCH2DJNZ R4,TEST DJNZ R4,BRANCH2DJNZ R5,TEST DJNZ R5,BRANCH2DJNZ R6,TEST DJNZ R6,BRANCH2DJNZ R7,TEST DJNZ R7,BRANCH2; MOV instructions 8048 8051MOV A,#$12 MOV A,#DATAMOV A,PSW MOV A,DIRECTMOV A,R0 MOV A,R0MOV A,R1 MOV A,R1MOV A,R2 MOV A,R2MOV A,R3 MOV A,R3MOV A,R4 MOV A,R4MOV A,R5 MOV A,R5MOV A,R6 MOV A,R6MOV A,R7 MOV A,R7MOV A,@R0 MOV A,@R0MOV A,@R1 MOV A,@R1MOV A,T MOV A,DIRECTMOV PSW,A MOV DIRECT,AMOV R0,A MOV R0,AMOV R1,A MOV R1,AMOV R2,A MOV R2,AMOV R3,A MOV R3,AMOV R4,A MOV R4,AMOV R5,A MOV R5,AMOV R6,A MOV R6,AMOV R7,A MOV R7,AMOV R0,#$12 MOV R0,#DATAMOV R1,#$12 MOV R1,#DATAMOV R2,#$12 MOV R2,#DATAMOV R3,#$12 MOV R3,#DATAMOV R4,#$12 MOV R4,#DATAMOV R5,#$12 MOV R5,#DATAMOV R6,#$12 MOV R6,#DATAMOV R7,#$12 MOV R7,#DATAMOV @R0,A MOV @R0,AMOV @R1,A MOV @R1,AMOV @R0,#$12 MOV @R0,#DATAMOV @R1,#$12 MOV @R1,#DATAMOV T,A MOV DIRECT,AExamples of what is different :The 8048 is older/simpler, so their jump opcodes simply swap-in the lower 8 bits, which makes them same-pageabsolute. (0..255)The 8051 has more hardware, it was able to fit an adder so jumps arerelativeappx +/- 128 bytes, that's more flexible and things do not break if you add lines of code.You may spot the first fish-hook here : an 8048 JMP from location 4 to location 251 is legal in 8048, but too far for 8051, so some editing is needed.More comparisons - 8051 has more of everything, and can test any of 128 SFR bits, which include 8 ACC bits and all Port bits & timer flags etc.Code:; Branch instructions 8048 8051;------------------------------------JB0 TEST JB ACC.0,BRANCH1JB1 TEST JB ACC.1,BRANCH1JB2 TEST JB ACC.2,BRANCH1JB3 TEST JB ACC.3,BRANCH1JB4 TEST JB ACC.4,BRANCH1JB5 TEST JB ACC.5,BRANCH1JB6 TEST JB ACC.6,BRANCH1JB7 TEST JB ACC.7,BRANCH1TEST JC TEST JC BRANCH1JNC TEST JNC BRANCH1JZ TEST JZ BRANCH1JNZ TEST JNZ BRANCH1JF0 TEST JB PSW.F0,BRANCH1JF1 TEST JB PSW.F1,BRANCH1JNI TESTJNT0 TEST JNB P3.INT0,BRANCH1JNT1 TEST JNB P3.INT1,BRANCH1JTF TEST JB TCON.TF0,BRANCH1JT0 TEST JB P3.INT0,BRANCH1JT1 TEST JB P3.INT1,BRANCH1SEL RB0 CLR PSW.RB0SEL RB1 SETB PSW.RB0STOP TCNT CLR TCON.TR0STRT CNT MOV TMOD,#CounterSETB TCON.TR0STRT T MOV TMOD,#TimerSETB TCON.TR0The 8048 has separate opcodes to start timer or start counter, whilst the 8051 has a mode register and a run flag, so needs 2 ASM lines. (init here is 1 byte in 8048, 5 bytes in 8051)Simple slave-translate-line-by-line 8048 -> 8051 code can come in slightly larger, as eg JBn in ACC, is 2 bytes opcode in 8048 but 3 byte opcode in 8051Not much of an issue as 64K 8051 is 32x larger than a 2k 8048QuoteHmm.. no .hex either?Maybe try different ASM's that can support 8048 and see how their messages compare?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 17, 2025, 08:27:08 pm
content: Another topic reminded me of Ghidra, and that leads to some breadcrumbs, if the OP is still looking to port 8048https://www.eevblog.com/forum/projects/hp3478a-improvements-modify-code-to-store-4-wire-cal-data/msg4598314/#msg4598314and some Ghidra changes / improvements for 8048 resulted (relatively recent, at least on 8048 time scales !ryanmkurtz added this to the 10.3.1 milestone on Jun 13, 2023)https://github.com/NationalSecurityAgency/ghidra/pull/4825

author: MJPIA
author_rank: Newbie
timestamp: August 18, 2025, 04:46:20 am
content: Quote from: PCB.Wiz on August 16, 2025, 06:12:40 amSorry should have been more specific as I meant images of the hardware itself, how people put it together, any adapters they made or the like.And all I got is the raw text for the 8049.I found a archive of the ISIS-II tools which included the conv51 program and also found an Intel emulator to run said programs on dos so I was emulating the ISIS-II on emulated dos on 64 bit windows.It took a good 30 minutes but it took the code and made something out of it.It took longer than I care to admit to figure out it wanted the actual text and not a binary file and the garbled text it was outputting was simply because I'm stupid.There's the manual if anyone is interested.https://mark-ogden.uk/files/intel/publications/9800934-001%20MCS-51%208048-to-8051%20Assembly%20Language%20Converter-1979%23Jun83.pdfI just threw it all in the github depository.https://github.com/MJPIA/AMC-Jeep-CeC-MCU/tree/maincec.a51 is the converted file as the program spit out without any manual tweaks or being converted into its final form which opens in github and notepad.cec.lst is the what would have been 125 page document a printer would have spit out with back to back 8048 and 8051 code with all 76 notices mixed in that someone would be manually going through.The manual does note that just because an warning is issued doesn't mean its a problem that needs changing, just that it should be double checked.There's 15 warnings about how lines may have incorrect time spans for timing instructions, I don't know how'd I'd be able to tell if they need changing or if hardware like this even cares.There's 26 warnings about how address's may be invalid, I presume that is a case of comparing the lines of the original and conversion, see where they direct to and make sure the converted one is correct and heads to the right one?26 warnings about address expression may be invalid, all of which appear to be acall or ajmp commmands, same as above, compare to original and make sure they go to the proper line?I'm not fully grasping this one.QuoteThis assumes the person working actually knows what the code does, I don't know if those are needed or notThere's two lines to mov psw,a and those have warnings about a different format and to examine and change as necessary.What would I change that to if it needed it?I'm running into a problem of not having a background of this code which much of this stuff generally assumes people have and being severly dyslexic which makes it reallly hard to process and understand technical manuals and understand walls of code, I'm never going to be fluid at this and likely won't ever rise above staring at code, staring at document, fixing code, double checking document to make sure I didn't misread it then rereading the line to make sure I put the right thing in.If I smash my head against my keyboard over and over I will eventually get there, it just takes a very long time.The other thing I'm very unsure of and that I didn't notice until now is of the aprox 3600 lines of code MOV A,R7 shows up 717 times.And not just embedded in code but back to back to back lines of it, in one part of the code it shows up by itself 101 times in a row.First thought was maybe an issue with the disassembler, JC64dis since the ability to disassemble MCS-48 family was added 4 months ago so I tried with dis48 and got the exact same result.I know it can be hard to tell the purpose of code when there's no context or knowledge but any guesses at why it repeats so often?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 18, 2025, 06:13:17 am
content: Quote from: MJPIA on August 18, 2025, 04:46:20 amEasy ones first.MOV A,R7 is the opcode of 0xFF, so it appears at any blank sections of code.With the paged nature of 8048 jumps, it will often appear at the top part of a page, as small bits of not-practical-to-use space.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 18, 2025, 06:36:33 am
content: Quote from: MJPIA on August 18, 2025, 04:46:20 amI think that is housekeeping related to this detail in the 8048 vectorsQuoteRESET goes to 0000H and EXITINT goes to 0003H and TimerINT goes to 00007HSome systems manually position code and packer bytes to match those addresses, like this 8048 code snippetCode:clr a ; vetor de power-upjmp iniciodb 0,0,0,0 ; vetor de interrupcaosel rb1 ; vetor de interrupcaomov r2,amov a,#0A0h; etc ...L0b: retr : retr is end of INT code blockor you could do thisCode:ORG 0000Hclr a ; << RESETjmp inicioORG 0003Hdb 0,0,0,0 ; << now optional, in this code ExtINT is unused.ORG 0007Hsel rb1 ; vetor de interrupcaomov r2,amov a,#0A0h;etc ...L0b: retr : retr is end of INT code block

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 18, 2025, 09:55:06 am
content: Quote from: MJPIA on August 18, 2025, 04:46:20 amYou should attempt a reasonable best guess for core speeds.This is what I would do :The timers have a prescaler and the opcode most often used for SW delays is DJNZ Rn,On 8048 DJNZ takes 2 Machine cycles or 30 xtal cycles. (6MHz here ?)On STC8H DJNZ Rn takes 3 sysclks , so to match that 2*15/6M = 5us 5us/(3/24M) = 40, so STC CLKDIV register is set to 40, from a 24MHz flash-program-time CLK choice.Your STC sysclk is now 1.6667usThe timers take machine cycles and divide by 32, = xtal/15/32 = 80us = 48 STC.SysCLKsThe code expects a very simple 8 bit timer ticking at 80us, which brings us to a small fish-hook.The STC8H8K64U has timer prescalers but not yet on T0.T1The newer STC8051U/Ai8051U (same thing) does have a SYSCLK/(TM0PS+1) ability, which makes it a better fit here.so you add an INIT ofCLKDIV = 40TM0PS = 48-1Will have your 8051U ticking along with DJNZ matched and TF0 ticks matched, from a 24MHz internal clock.You could use the 6MHz crystal, if you think that is important. (CLKDIV = 5u/(3/6M) = 10 )Attached is a timers and clock tree picture.Addit: there are 6 places where timer flag is Sw checked and 8 places where timer register is read, as well as the timer interrupt, so this is doing a mix of HW & SW+HW timing.Addit2: If the Chinese data of 8051U is a problem, an alternative part could be AT89LP51Rx2 series.That would need the 6MHz Xtal, as the on chip RC osc is nominal, it has 3 timing registers, that allow alignment with 8048 speedsCLKDIV = 10 for 3T DJNZ Rn opcode speed matchAT89LP51Rx2 Timer divide of /48, needs /N /2^M solution,TCONB.PSC0 = /16 tapCLKREG.TPS3 = Divide by 3The code has 10 djnz uses, including nested ones for ~500us quanta timing, but that 500us*N subroutine seems to never be called from anywhere?AT89LP51Rx2/ED2 programming linkhttps://petervanhoyweghen.wordpress.com/Commercial LP51 programmer:https://www.tindie.com/products/microprogrammers/atmel-at89lp-standalonemass-production-programmer/

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 18, 2025, 10:18:45 am
content: Quote from: MJPIA on August 18, 2025, 04:46:20 amIt depends on what happens next.This warningCode:*** WARNING 014 *** PSW FORMAT DIFFERENT IN THE 8051does need care here.It looks to be checking the stack for where things are, and doing some reboot/restart ?The 8051 call stack is in SP, a full 8 bits wide, so MOV A,SP gets stack info, and MOV SP,#Const resets stack pointer. (likely to 07?)Code:867 W0400:868 mov A,PSW ; << This likely becomes MOV A,SP869 dec A870 anl A,#07h871 add A,#0FAh ;stack check ? Maybe ok as is, if stack in same ram offset.872 jc W0411873 jni W040F874 en I875 mov A,R6876 orl A,#01h877 mov R6,A878 W040F:879 mov A,R2880 W0410:881 retr882883 W0411:884 orl P2,#20h885 dis TCNTI886 dis I887 clr A888 mov PSW,A ; << This likely becomes MOV SP,#StackBase889 sel MB0890 call W0410891 sel RB0892 movx A,@R0893 jmp W0000 ; Cold Boot

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 18, 2025, 08:27:56 pm
content: Quote from: MJPIA on August 18, 2025, 04:46:20 amSome parts of code can be tables, so those need special care. Maybe Conv51 has a means to specify those areas ?This codeCode:1052 W04C7:1053 mov A,R31054 anl A,#03h1055 add A,#0CDh1056 jmpp @A ; JMPP @ A (PC 0 – 7) ← ((A)) Jump indirect to specified address within address page.*** WARNING 001 *** REFERENCED INSTRUCTION OR DATA MAY NOT BE IN CORRECT PAGERoutine is located at 04C7, gets a value 0,1,2 and adds 0xCD so that means the bytes just ahead of the jmpp are a jump table.That means these opcodes are likely jump table bytes xrl A,@R1 mov PSW,A xrl A,R5 movp3 A,@A and need to be converted to address references.As jump tables are 2 byte opcodes, more common is to have a RL A also in there, to have even number indexing, but we hope R3 is only 0 or 2

author: bobxyz
author_rank: Contributor
timestamp: August 27, 2025, 10:39:52 pm
content: Quote from: MJPIA on August 18, 2025, 04:46:20 amThat's Great! 45 year old tools FTW! Can you post the links for the ISIS-II tools and the Intel emulator?I ran your .bin file through the Ghidra 8048 disassembler - I think it does a much better job of automatically decoding and handling the upper/lower 2KB memory banks. This may[?] make the CONV51 output a little cleaner. I also did a little hand cleanup on the Ghidra results to produce a 8048 .asm file. See attached. I was able to re-assembly it and exactly match the original .bin file. I used the daveho 8048 assembler from here:https://github.com/daveho/asm48Note: this assembler uses ".ORG" and ".DB", instead of "ORG" and "DB". Can try running the ghidra .asm file through CONV51 and see if it's different? It should have a few extra instructions in the interrupt handlers at ORG 3 and ORG 7, and the address warnings may be reduced.I didn't look at the timer warnings. From the AMC whitepaper, the firmware is setup to sample the sensors every 1.28ms. This 1.28ms time needs to be retained in the 8051 code, but other timings may[?] not be critical.What are your current plans, and longer term plans, for this project? Are you thinking of making a 8051 adapter board, either a 1-of-a-kind just to see if it works with the factory tester, or a real PCB for AMC emissions box repairs?-Bob