Wat is the oldest chip in your parts bin?

dougw said:

Have you designed with any of these famous chips?

Not sure if this counts but I've been getting pretty intimate with Hitachi's HD6303 in recent years which shares some history with the original 6800 series.

A now retired colleague of mine accidentally bought one as part of a rather unique classic car which uses it as part of its engine control unit. 

It all started with a photo like this and of course no documentation...

The manufacture appeared to enjoy obfuscating IC numbers on the early units either by erasing or covering with hot glue...  

Nice.  Sounds like the beginnings of a journey.  I have to admire the patience of tackling anything where the documentation is lacking.

What made it more difficult was that there was no second chance here and time was not on our side. There was engine mapping and configuration data stored inside a 'black box' that had to be extracted before it became corrupted due to the length of time. The system was last programmed around 35 years ago. The car was a bespoke demonstrator and unique in many ways so not as if you can just copy it from another vehicle if it doesn't end well.

Needless to say, the original diagnostics equipment used to connect to, configure, and update the mappings was missing, along with its software.

All there was to go on were two unmarked Fischer automotive connectors on the box, one 5-pin, one 3-pin and that somehow that was the way into the system. Initial probing with a scope revealed no clock or data signal, as it turned out that the diagnostics side initiated the (undocumented) comms.

Also I had no physical access to the device at the start as this 'project' was initiated during the first COVID lockdown period.

Does the code that the HD6303 runs reside in an external ROM?  If so, maybe it's possible to read back the contents.  Then of course you would have to find some method to do a disassembly of the raw binary.  It would be too much work for me. LOL.

The code on the HD6303 is held in an external EEPROM, so that gets corrupted along with the rest of the EEPROM data at some point in the not too distant future.

I've already managed to access the contents of the EEPROM and extracted the raw HD6303 binary data from it. I've also already written a HD6303 disassembler and now have a 6303 assembly language listing to work with.

Although I generally understand the individual 6303 instructions, what I'm struggling with is following the overall program flow. Every few instructions is a branch or jump and I find it hard keep track of what is actually going on. I've worked out some stuff though and commented about a quarter of it. Not sure if I should be looking at writing a basic debugger / interpreter so as I can step through the instructions one at a time and outputting the  register contents. 

I've worked out quite a bit of the overall address space - in addition to the processor and EEPROM there are five external analogue data acquisition units each of which contain three timers. Four of those ADUs are used to fire the 12 fuel injector pulses. The address decoding needs some more investigation work as I appear to see ghost data as if multiple address locations are pointing at the same registers due to the way the decoding is being done.

I've worked out most of the comms protocol now, however there is some 'engine math' that I'm not sure about in order to be able to convert from the parameter data to human data. I've got a lot of it logged as look-up tables and plotted the curves, but would be nice to understand the math that was actually used.

The code on the HD6303 is held in an external EEPROM, so that gets corrupted along with the rest of the EEPROM data at some point in the not too distant future.

I've already managed to access the contents of the EEPROM and extracted the raw HD6303 binary data from it. I've also already written a HD6303 disassembler and now have a 6303 assembly language listing to work with.

Although I generally understand the individual 6303 instructions, what I'm struggling with is following the overall program flow. Every few instructions is a branch or jump and I find it hard keep track of what is actually going on. I've worked out some stuff though and commented about a quarter of it. Not sure if I should be looking at writing a basic debugger / interpreter so as I can step through the instructions one at a time and outputting the  register contents. 

I've worked out quite a bit of the overall address space - in addition to the processor and EEPROM there are five external analogue data acquisition units each of which contain three timers. Four of those ADUs are used to fire the 12 fuel injector pulses. The address decoding needs some more investigation work as I appear to see ghost data as if multiple address locations are pointing at the same registers due to the way the decoding is being done.

I've worked out most of the comms protocol now, however there is some 'engine math' that I'm not sure about in order to be able to convert from the parameter data to human data. I've got a lot of it logged as look-up tables and plotted the curves, but would be nice to understand the math that was actually used.

Bit rot often kills undocumented electronics. Sad.

That is an amazing amount of effort especially writing your own dissambler.  The programmers of yesterday did seem to like jumping in and out of subroutines.  I formed that opinion, anyway, after seeing the dissasmbly of some Intellivision games.  And truth be told I couldn't extract enough meaning from the generated code to make any sense of it.  Best of luck if you ever resume this project again.

Actually, I found that was one of the easier parts as Hitachi had a datasheet on the HD6303 so I had the opcode map and the number of operands each opcode expected. I knew where the processor looked for the interrupt vector table in memory so the value stored there at told me the address where the executable code started. From there it is just a case of looking up the opcode and then finding how many operands it expects and away you go. It was a bit tedious as the data sheet was scanned so no quick cut and paste into the program. Add in a few extra routines to calculate addressing offsets to make it more readable. In-line data can be an issue. Also keeping an eye on the interrupt vector table can identify start addresses of other code blocks.  

If you want effort, then that was months of looking at data captures from a scope trying to figure out patterns in the data. It turned out that the comms was asymmetrically encoded so the few ASCII characters in the config section were initially obfuscated. Then finally once I had identified the encoding method there was a 'Twin Peaks moment' 

https://www.youtube.com/watch?v=mbi7rq-TSk8&t=78s

as the hex sequence for the Program ID and data ID strings finally matched one of the data captures and confirmed I was really on the right track.

If the code was originally generated from an optimising compiler, then it often can often be hard to follow as the optimisation can save program cycles by doing certain procedures in rather non-intuitive ways. Also by having lots of near jumps you can reduce the overall code size to fit in the limited memory by reusing code blocks, however once again it makes it a lot harder to follow.

It would make life easier I think if I had a way of turning the listing into a graphical diagram with the blocks of code linked by the jumps such that you could slide things around so that the related sections were next to each other. Also a way of labelling and commenting what you had identified so far. I think that's what the call 'data graph' structures in programming lingo ?  I once saw this done manually with string and post-it notes !

If I was a bit further along the line, then I might have given the LabVIEW challenge a go using it to connect to the ECU (or rather the ECU protocol simulator that I have also written as part of this project). However  I'm not sure what is involved in getting LabVIEW to talk to the ECU protocol and parse the data.

Something like Ghidra would have been useful.

beacon_dave said:

Also by having lots of near jumps you can reduce the overall code size to fit in the limited memory by reusing code blocks, however once again it makes it a lot harder to follow.

This has been my observation as well.  Thirty to forty years ago memory size was limited so reuse was the key.  Now us poor suckers that are trying to reverse engineer code from that era are paying the price.

If you can import the data. I don't think it supports HD6303 assembly ?

I've had a bit of a look at Ghidra and IDA Pro in the past but I've not found much training material surrounding the older platforms.

You need to add the instruction set with SLEIGH.

Now that sounds very interesting.

If there is an equivalent SLEIGH model already for the MC6800, then it may be fairly straightforward to add the additional features and to tweak the quirks.

Down another 'rabbit hole' we go...