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...  

Very respectable collection.  Some of the old parts I have on hand are one MC68000 processor, a Z80 variant, two 4464 DRAM chips and a couple of 76489 sound ICs.  I also have about 13 AY-3-8910 sound generator ICs.  I recall you've used the latter in some of your projects.  Around the 2018 to 2020 time frame I designed a couple of single board computers.  One based on the 65C02 and the other built around the 65C816.  I started to accumulate these old parts around then in support of these projects and some other projects that didn't quite get off the ground.

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

Same era as yours. Kept on hand for repairs and/or restorations. If hybrids count I have some about 10 years older.

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.

I have a vintage supply of tried and true TTL logic chips and 555 timers. I wouldnt doubt some ICs are 40+ years old, but if they work, why toss them ?  Projects can be prototyped on a whim using on hand inventory. 

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.

The old chips I have, have maybe a few dozen transistors each... basic analog, basic digital logic gates. 

Your chips are pretty fancy.