MR_Loyale

Just had a thought. If it is in mode7, that means there is internal ROM that is most likely the kernal of sorts. If what ANIM_Hooneru said was true, it may mean that Subaru had a precursor to the SSM in the EA82 cars. I would expect that functions related to this would be on the internal ROM. If at some point we wish to read that internal ROM we could alter the board settings to a mode that would go to the EPROM and allow us to run some code piping the values out via the SCI as your EPROM reader is not able to read the internal ROM. Of course we would have to get some hardware built to do that. Potentially a data logger could be constructed at some future point using the SCI.

Is there a crystal on there? I think I saw one one the lower left of the topside pic. Handbook makes references to baud rate selections in relation to different crystal frequencies of the main clock.

DaveT, In the assembly listing, the first things done are to clear locations 7F7F and 7F7A. I am thinking these are hardware control registers of some sort as I know hardware registers in general do exist as there are references to a "Rate Mode Register" for setting the baud rate on the Serial Communication Interface (SCI). This is built in functionality on the cpu itself. So if you happen to come across references to these addresses while reading, let us know. I wish this was a true PDF and not just scanned pages, the I could search the text. Anyway we could run this through an OCR progam to get searchable text?

DaveT, How hard would it be for you to backtrace the trouble code LED and produce a small schematic ? Either it goes back directly to the 6301 or it has some support circuitry that then goes back to the 6301. I am thinking this may be helpful in correlating the subroutine for trouble code output to some port addresses and since there are only 128 bytes of RAM we can potentially look for opcode references to the RAM address space to help us out. The trouble codes are the only data that is volatile and there are not any external RAM chips. Does this make sense?

Can you flip it over and take a pic of the bottom?

Looking at it from a systems perspective, I cannot believe that the EPROM does not contain any of the controller code simply because of the economics of having to remask the 6301 at the foundry to fix a bug - which is what you would have to do if you used it in mode 7. Probably the EEPROM also contains table data as well. Frankly, whether the EPROM contains table data or executable instructions is irrelevant at this point because in both circumstance, the EPROM must reside on an address bus in order to be read.

But if you look at the memory map for mode 7, all memory (RAM and ROM) is internal. The rest of the address space is listed as"unusable" which means to me that you cannot put an 8K EPROM in that space. That is the contradiction. Can you try to trace some of the pins from the EEPROM back to pins on the 6301? That might give us a clue as to how they put this together. The example given in the handbook appendices for a mode 7 application is dot matrix printer controller.

Not my intent to tune anything at all but good information nonetheless. I mentioned you might want to peruse the ROM file to see if anything pops out as "tuner stuff" as you have put forth yourself as a tuning authority (or at least experienced) in OBD1 which no one else here knows about. You would be most likely to recognize something like that hopefully. We are simply collecting a bunch of facts about the ECU here at this point. It has a yellow connector, a Hitachi CPU etc. Given your stated experience, the hope was if you look over it, something might pop up. Many unrelated facts, when put together can lead to new discoveries. I am finding it fascinating. I am geeky that way, you will have to get used to it. I would never have thought that my Subaru has something in common with a freaking radio shack computer from the 80s! Would 8 K be overkill for OBD1 era basic engine control tables? I am thinking they probably did not have 3d tables and the like that far back as this was still new stuff back then. One table I think we should be able to find is the one with the fault codes.

That would mean mode 7 (single chip mode). That doesn't make sense looking at the memory map for mode 7. That indicates NO external memory. We know we have an EPROM. What am I missing here?

Any chance you can scan that manual and upload the PDF?

Well, looking at pdf pg 179 note (2) at top, after reset, program execution begins at the address values stored in $FFFE and $FFFF (addresses are 16 bit). These are the last two addresses in the 64K memory space. This is listed as RES (RESET eg what happens when it is powered off the on) in the vector table below: Now depending on our mode (as explained previously) the vector map may or may not live on our EPROM, It may be masked into the chip from the foundry. Let's assume the vector map is on our EPROM and validate it with a logic exercise. If it is on our EPROM, the then it has to be wired as the last 8K in the 64K memory space. Looking at the possible memory map modes that are configured by the states of P22,P21 and P20 the possibilities are (PDF pg 156): Mode 1 - non-multiplexed Mode2,4 - multiplexed/RAM So from our ROM file we see FFFE has value DC and FFFF has 6F. Thus when reset, program execution starts at address DC6F, IF our EPROM holds the vector table. That is the rub. If our assumption was true, the address at which program execution should begin would be DC6F. However if we are in one of the modes we assumed, then whatever address the execution begins should occur in our EPROM memory range which is E000 - FFFF. Since DC6F falls below our beginning address, I think our mode is not 1,2 or 4. Confirmation should come when DaveT traces and or measure the states of P22, P21,P20. If I am correct, then the modes left are ones which include factory masked ROMS and allow for 8K for our EPROM. This would leave mode 0 or Mode 6.

So looking at the hd6301 handbook beginning on pdf page 156 looks like there are eight possible configurations of the mcu that are set based upon the state (high or low) of pins 22,21,20 . The memory map is different depending on how these are configured. Dave - can you visually look at those pins and see if they have a jumper high or low on each? Please report back to us. If you cannot be sure, you might be able to safely bench test this by supplying power and using a digital probe if you have one. These are going to be jumpers or hard wired. Just looking at it though, I think we can eliminate mode7 because we know there is an external ROM and that mode makes everything internal only. 0,1,2/4 or 6 appear to be the only modes possible based upon the memory maps show for each mode. I say this because none of the other modes makes available an 8K or greater space, since our EPROM is 8K I think we can eliminate those mode. Tracing should confirm this.

Pics would be nice. This is intriguing because the section 2.6 (PDF pg 169) of the handbook does mention a built-in serial communications interface.

If I ever do EJ stuff, that is the site I will start at. Those ECU's are in a different league compared to these old school ECU's What was the precursor to Subaru SSM?

Also I want to investigate where in the address space the memory mapped I/O lives. Those will be key to finding the code that reads the TPS and CTS and such.

Thats all good but I am still unclear as to what we are trying to do. So you might want to mozy on over to the ECU thread, download the hex editor and open up the ROM file. Starting browsing for stuff that looks "tuner like". If we have a running car and know this ecu works, we can get another UV ROM chip, alter our bin file, burn it into the ROM, change chips and see how it blows up. LOL.

Here is a fun fact, our old Subarus use almost the same microprocessor as the TRS80 Color Computer. Who ever used one of those? Raise your hands.

Here is another useful tool, a 6800 family disassembler. The disassembler takes as input a binary code/data image file (typically a ROM image) and generates either an assembler source file or a listing file. Here is a link: http://myweb.tiscali.co.uk/pclare/DASMx/ Reading through the instructions, it does claim to do Hitachi 6301. This is a command line tool folks, no fancy GUI for you! I will see if I can get a listing out of this, It also claims to be able to do code threading (eg identify regions of code rather than data).

Found a nice hex editor here: http://www.handshake.de/user/chmaas/delphi/download/xvi32.zip I have opened the bin file and I can see areas that are most likely data storage areas for settings of some sort as they have repeating values that would not be opcodes and operands simply due to their repetition. If we all use the same hex editor with rows arranged in a similar way we can discuss values at addresses using the same point of reference. Here is what it looks like: It shows an address for the first byte of the row in the first column. Next are 16 columns showing hex values for each byte. Finally an ASCII representation is shown in the right 16 columns. If there are any human readable strings, they will show up in the ASCII area (maybe Subaru or Leone or something).

I think the Hitachi HD46520P 40pin DIP is an A/D converter based upon searches for this I was directed to the spec sheets for the HD46508 which may be a substitute or one in the same family of "Analog Acquisition Units" as they call them: http://kazus.ru/datasheets/pdf-data/3211033/HITACHI/HD46508A-2.html Possibly this is used to digitize sensor inputs such as the TPS and CTS. Some following of the board traces to where they emerge to a connector may give a clue as we can identify the wires coming from both and their connector to the ECU box.

Looking at some documents from Hitachi regarding the processor, it apparently could be ordered with onboad eprom masked in at time of manufacture. So some of the actual coding may be onboard the processor chip itself, It would make sense though that any sort of car model specific stuff would be on an external UV erasable chip in case a bug was found, new regulations happened , recall etc. Are there possibly any ports that may be a diagnostic port (possibly an RS232 used for QC)?

We should be able to identify subroutines by searching for JSR (jump subroutine $90) opcodes and their endpoints with the RST ($38)opcodes. This would help in delineating code regions from data regions. EDIT: The disassembler claims it can do this for us.

What is the packaging of the HD6301V1P? Dual inline or square? Are there any other RAM or ROM chips? We may need to do some tracing on the address bus to the ROM chip to see where in the address space the ROM lives. I suspect it is in the lower 8K as the 6800 starts program execution at address 0000. EDIT: Actually our processor gets it's starting address from the RES vector at the end of the memory map ($FFFE and $FFFF).

More evidence this may indeed be the same Motorola 6800 instruction set: "After the 6800 project Bennett worked on automotive applications and Motorola became a major supplier of microprocessors used in automobiles." https://en.wikipedia.org/wiki/Motorola_6800

Here is a nice little intro to 6800 assembly langauge programming: http://www.hvrsoftware.com/6800.pdf