[Jman]

I've been curios about a several things and thought this would be a good place to seek answers. I'm a little familiar with the 8763 ROM and know it's used in the SFI-MA12 EEV4s (Mustang AL9 and GUFx) but I've never seen the others.

ROM chips used according to the EEC-IV Custom Integrated Circuits Architecture and Hardware Reference.
8762 (8K x 16-Bit) Possible address ranges: $2000-$5FFF or $6000-$9FFF
8763 (16K x 16-Bit) Possible address ranges: $2000-$9FFF or $A000-$FFFF
87C66 (28K x 16-Bit) Possible address ranges: $2000-$FFFF with Shadow array $2000-$2FFF
87F66 (28K x 16-Bit) Possible address ranges: $2000-$FFFF with Shadow array $2000-$2FFF

Questions
1. My biggest question is with 8763, Has anyone ever seen the higher address range $A000-$FFFF used? If so, where?
2. What cars or EECs are the 8762 ROMs used in?
3. What cars or EECs are the 87C66 ROMs used in?
4. What cars or EECs are the 87F66 ROMs used in?
5. Looking at an SFI-MA13 from a Thunderbird the ROM chip used is labeled as N7704120 FRNG, is this actually an 8763?

6. There's a 5 bit ROM read-only input port built into these chips. The address of it changes depending on which chip and which address range is being used. Does anyone know if it's ever used, or what for, on any EECs?

**Edit 10-22-2025: I found out that the SFI-MA12 (A9L and other GUFX EECs) uses Rom Port 2 (RP2 on the 8763) as the input that proves if the fuel pump is getting 12 volts power. This signal comes into the EEC on Pin#19 of the 60-pin connector. Rom port 2 (RP2) is an input on the D8763 EPROM chip on its PIN #5.***

If anyone has the answers to some or all of these please chime in. These questions have been eating away at me for a while.
Thank you
J.W.S.

[jsa]

Previous discussion on chips
https://eectuning.org/forums/viewtopic. ... 04#p135885


This has a couple of nuggets of info.
http://eectuning.org/forums/viewtopic.p ... 75#p133435

1. Not me.
2. Early EEC-IV no doubt, but no idea exactly.
3. Mid 90's EEC-IV. CARD has N70413FEC which may be shortened from N7704130FECAGA. DZA1 has N70513FEC.
4. Not me.
5. Appendix D-2 of the Hardware Manual says it is.
6. ROMPORT I've seen it in a bin somewhere. Maybe an Aussie Falcon bin. Used for binary inputs.

[Jman]

JSA,

Thank you this is a great response. I knew I came to the right place for this information. I missed the Appendix D-2 information. I swear I've read through that information, but it seems like you run across certain things while you're seeking different information and don't absorb it. I'll read through those other threads I go a long way down the one talking about odd word reads to get even bytes... or something along those lines and the finer points of interpreting things in the EEC-IV Custom Integrated Circuits Architecture and Hardware Reference. I've been browsing around here since (I think) around 2014 on and off.

Thank you
J.W.S.

[Jman]

Does anyone know the original source of the Strategy download files as they’re found on the EECanalyzer web site. As in are these all reads that have been sucked out of ECCs over the years or is there a chance they came from Ford somewhere along the way.

I’m specifically wondering if inside the Ford engineering department back in the 80s and 90s if all there Binary files started at $2000 or if they started at $0 like you find when downloading from the EECanalyzer web site?

I also wanted to know if anyone knows how that pattern in the filler at the end of the binary files was made? Is that from Ford or BE or some other after market tuning software?

Thank you
J.W.S.

[jsa]

Some on eecanalyser have come from EEC's, don't know about all.

All ROM files start at 0x2000, originals won't have 0x0000 to 0x1fff in the file. Opening an unpadded ROM file in a hex editor will show file address starting at 0x0000, but actual address is 0x2000.

Most bin file have 0xFF, what pattern would you be referring to?

Fill at the end would depend on the OEM ROM size VS file size. Say for a box with 32kB ROM chip for which you find a 56kB file, 24kB of fill has been added by some other method. Fill can be added using a hex editor or it maybe added by other software.

[tvrfan]

More background info which might be useful.

As a IT geek, know that hardware-wise you can put any memory (or chip) at any address you like, within reason. The 8061 was a descendant of the original 8096, but with lots of changes for a 'real time' setup. The 8061 starts from its 'boot' at 0x2000, which is why all the ROM dumps start there. Why ? I don't know. As the addressing is 16 bits maximum, that gives usable addresses from 0x100 through to 0xffff. (0-0xff is reserved for the CPU itself) So the default design was that code would be 0x2000 - 0xffff maximum, and RAM from 0xff to 0x1fff maximum. Arbitrary, but consistent design.

When the ROM is read by a program, it will start reading at 0x2000, and then it's up to the reader design where it puts the data in a file. It makes equal sense to state that the file begins at 0x2000, or to 'pad' the file with dummy entries from 0-0x1fff so that the start address is 'correct' or matches with the file address. So various people who wrote their code came up with different options.

By default in hardware, addresses which are 'invalid' (= don't exist, or can't be read) will return all 1s, which is 0xff in an 8 bit byte or 0xffff in an 8 bit word. (Why? because it's simpler to do). To save hardware (which was expensive in the 70's, but it's cheap today) the actual 'bus' which communicates out the CPU was 8 bits wide, and many of the instructions and internal registers are also byte based. This again was much more common when the CPU was designed, even though it was technically a 16 bit processor.

When Ford started running out of space (as many other computers did everywhere) they wanted to reuse what they had designed to save money, so they came up with a 'memory expansion' bolt on to allow them to have more then one set of 0-0xffff addresses, and 0-0xffff became a 'bank' in their description. (the 8065 CPU) This allowed them to use most of the same design tools, compilers, hardware.... all about saving them money. But truly, it's messy and complicated to code.

For comparison, Intel personal PCs did the same, with 8086 (16 bit) 80286 80386 80486 (16 bit with a 32 bit address extension, but still with 16 bit bus to start with) then upwards to Pentiums, which had three 'modes' of 16/32/64 bit working. That was even worse, and insanely complicated.... but Intel made lots of profit from it, and CPU instruction set became a default standard.

I worked on a proprietary computer for a while which also had some interesting/horrid memory extension tricks to get 16+8 (=24 bit) memory addressing, similar idea to 8065, but very different detail how it actually worked.

RAM - Some of the multibank EECs *DO* have RAM in higher address ranges, but mostly Ford managed to get all the 'variable' data in a small space, so RAM still only occupies 0x10400 to 0x11fff (where first digit is the 'bank number', which can be 0,1,8 or 9. Why those values? well it makes a kind of twisted sense when you work out how the hardware works). Most of the calibration data also sits in Bank 1 in nearly all the multibank EECs.

So various hardware chips came in various memory sizes and speeds.... and you can't always tell without actually reading it with a tool+program of some kind.

I hope that little lecture helps !!

Off topic but might be interesting. In 90's DEC corporation released the 'DEC Alpha' chip and it was a beautiful simple design instruction set, all 64 bit hardware, no pissing around with banks or extended memory tricks. At one point DEC showed that the Alpha could emulate an Intel Pentium FASTER than the Pentium actually ran. And it was doing this with software/code. But they couldn't compete with the Intel behemoth, and the chip slowly died off. Just shows the best doesn't always win.

[Jman]

Thank you TVR Fan, I've got a decent collection of EECIV's and have been looking inside many of them and reading through the EEC-IV Custom Integrated Circuits Architecture and Hardware Reference. It's interesting that some of the custom FORD eproms were designed to be able to select different address ranges and others were made with two options of range. However, anything besides starting at 0x2000 must have been rare or just so much older and basically irrelevant such that folks didn't study those EEC's enough to have seen the higher start addresses. I wonder where PCs would be now if the DEC Alpha had been able to outshine Intel?

Thank you
J.W.S.

[tvrfan]

Yeah, if you think about the address ranges in binary, they will typically be only 1 bit difference, which in real life could be an external pin (maybe 2) on the chip which will be grounded or +5 volts, so again a kind of 'shortcut'. Or may have been a built in option.

Alpha - Who knows ? there have been great designs in all sort of stuff which didn't make it because they were stifled by something bigger.... Modern mutlicores (Intel Core and AMD Ryzen etc.) are more like a mini operating system inside the chip itself, and they emulate the instruction set with all sorts of sneaky tricks to get max speed, etc. Some of those tricks turned out to be serious security problems of course (spectre, meltdown,...).

I think those modern CPUs are about 1000 times more powerful( maybe more) , so Alpha would have had to change to keep up....

[tvrfan]

For learning about how the code works, I recommend you look at my 'AA' listing. Not 'cos it's mine, but because it's the smallest code found to exist (only 0x2000 to 0x3fff) and has no feedback sensors, no saved RAM, and was pretty much the first UK EEC IV to be released. So it's a simple, small start point.

[Jman]

I've opened up two EECIVs both with cal code 8AP and they have different ROM chips, one is Intel and the other is Texas Instruments so I would expect the numbering to be different, but it doesn't come close to anything in the Appendix A of the EEC-IV Custom Integrated Circuits Architecture and Hardware Reference that was mentioned earlier. I'm wondering if anyone knows if this TI chip is the same as the 8763 or if it could be an 87C66? It looks like the 87C66 could be used in place of the 8763 if the 8763 was range 0 and the 87C66 was a range A. See the pictures below.

*** Edit: The picture with the D8763 chip in a Zif socket is not the same Escort EEC. Its a different EECIV I use to read loose chips via the J3 connector. ***









Thank you
J.W.S.

[Jman]

Tvrfan,

Where do I find your 'AA' listing? I browsed around the github link in your signature line but didn't find it.

Thank you
J.W.S.

[tvrfan]

later on, chips were made by other companies, and I don't know what numbers or options they had. There were 8065 CPU ones made by Toshiba, which had all sorts of extras on the same physical chip, and it was called an 'EPIC' I think. Oh, and some of the boards had chips on both sides as well.

AA - Oops - it's in github under Openeec project https://github.com/OpenEEC-Project

This is a general repository for all things EEC.

[Jman]

JSA ,
I missed your question in there .

All ROM files start at 0x2000, originals won't have 0x0000 to 0x1fff in the file. Opening an unpadded ROM file in a hex editor will show file address starting at 0x0000, but actual address is 0x2000.

Most bin file have 0xFF, what pattern would you be referring to?

The A9L from EECanalyzer for example, must be an original since it starts a 0X000. This one also has the pattern I was referring to from 0x8000 to 0xDFFF.

Is this something Ford generated somehow?

Why not just FFs?

Could I put whatever I wanted in for filler that reads as notes in the ASCII area?

Does filler data affect any Cecksums that matter?

Thank you
J.W.S.

A9P.BIN

A9L.BIN How was the pattern generated from 0x8000 to 0xDFFF?

(56 KiB) Downloaded 566 times

[jsa]

The file you attached does not look original. An original would be 32kB as that is the chip size for those I believe. The file would be 0x0000 to 0x7FFF.

Who knows why someone added a pattern like that.

FF would do just fine to pad it up to 56kB.

BE has an option to specify EEC_32K as the PCMType, but the definition Z_TUNEPOS parameter is at file position 0xDFFE forcing EEC_56K PCMType and padding to that size.

You could choose an area of fill for comments of your own. You would need to check the definition to confirm it's not already being used like 0xDFFF is for Z_TUNEPOS. Other definitions may use fill for the logging payload list, though GUFA/B is not.

That BIN has internal checksum calculation for ROM address 0x2000 to 0x9FFF (file address 0x0000 to 0x7FFF) and so does the definition from EECanalyzer.

Yes changing fill can affect checksum, best to avoid that. If you changed fill at file address 0x7E89 to 0x7FFF the check sum would need to be adjusted. For the remainder of fill you would need to confirm it's not being used for something else. For other strategies you would need to confirm the definition checksum range.

[tvrfan]

Just a clarification on checksum. In all bins there is a start and an end address stored, and this defines what range the checksum uses. in A9L this is at 0x786a and 786c (two words, 0x2000 and 0x9ffe).

in AA bin, it's at 0x2050 and 0x205e. (0x2000 and 0x3fff).

Older bins like AA use a byte based add, later ones use word based. It's just a 'wrap around' addition calculation and end result should be zero.

In multibanks, addresses seem to be embedded in the code more, the checksum is calculated over all valid banks with a range for each bank. Code/hardware cannot do a 'global' pass of all addresses in one loop.

An example subroutine is 0434a in 22CA for 4 banks (notice the rombank calls).
shown here is xdt2, shorter one as it has only 2 banks (1 and 8 ) ...

Code: Select all

   Sub_8a4a7:
8a4a7: 01,40              clrw  R40              R40 = 0;
8a4a9: a1,00,20,3e        ldw   R3e,2000         R3e = 2000;
8a4ad: b1,ff,77           ldb   R77,ff           R77 = ff;
8a4b0: 10,08              rombk 8
8a4b2: 66,3f,40           ad2w  R40,[R3e++]      R40 += [R3e++];
8a4b5: 89,fe,ff,3e        cmpw  R3e,fffe         
8a4b9: d3,f2              jnc   8a4ad            if (R3e < fffe) goto 8a4ad;
8a4bb: 10,08              rombk 8
8a4bd: 66,3e,40           ad2w  R40,[R3e]        R40 += [R3e];
8a4c0: a1,00,20,3e        ldw   R3e,2000         R3e = 2000;
8a4c4: b1,ff,77           ldb   R77,ff           R77 = ff;
8a4c7: 66,3f,40           ad2w  R40,[R3e++]      R40 += [R3e++];
8a4ca: 89,fe,fe,3e        cmpw  R3e,fefe         
8a4ce: d1,f4              jleu  8a4c4            if (R3e <= fefe) goto 8a4c4;
8a4d0: 88,00,40           cmpw  R40,R0           
8a4d3: df,02              je    8a4d7            if (R40 != 0)  {
8a4d5: 17,44              incb  R44              R44++; }
8a4d7: f0                 ret                    return;

So you can see it does checksum from 0x2000 - 0xffff in bank 8 and 0x2000 - 0xfeff in bank 1.
(Yes, it's not directly obvious how to deal with the nailed on bank extension design.)

[edited for typo...]

[Jman]

I was asking further up in this thread:

6. There's a 5 bit ROM read-only input port built into these chips. The address of it changes depending on which chip and which address range is being used. Does anyone know if it's ever used, or what for, on any EECs?

JSA answered:

6. ROMPORT I've seen it in a bin somewhere. Maybe an Aussie Falcon bin. Used for binary inputs.

Adding to this tonight:
I found out that the SFI-MA12 (A9L and other GUFX EECs) uses Rom Port 2 (RP2 on the 8763) as the input that proves if the fuel pump is getting 12 volts power. This signal comes into the EEC on Pin#19 of the 60-pin connector. Rom port 2 (RP2) is an input on the D8763 EPROM chip on its PIN #5.

I'm considering trying to make a schematic for the SFI-M12 in KICAD or a series of schematics breaking it down into bite sized chunks.

Thank you
J.W.S.