[1gcrazy]

Does anyone know if there is a software that the engineers used to load the ecu’s with their original maps from the factory? I’ve been told there is a software that they used on the backend that us consumers don’t have access to. Just looking for a name.

[tvrfan]

No doubt they did, but don't know what.

We used to 'burn' PROMS for quite a bit of custom stuff (for example old style map displays before full graphics) and the equipment was standard common stuff which would burn a range of (std) PROMS in various sizes.

On the basis the Ford ROM was itself special/custom, I would guess they had a matching burner design available, or given the numbers produced it could have been a 'pre-burn' supply (done at the chip builders), which also was available if you wanted enough chips...

[cgrey8]

I don't know that it would do you any good, even if you had a copy of the software.

Remember, whatever software they used, was intended for a machine of the 80s. And assuming that machine was Intel-based, it was most likely a 16-bit application that ran under MS-DOS. It wouldn't be compatible with any modern day 64-bit Windows OSs, of which no longer support 16-bit applications of any kind, even ones compiled for Windows.

I think the last attempt to support 16-bit applications on 64-bit machines was with Win7 Professional where you could download and run an "XP Mode" (32-bit) virtual machine which would allow you to run your older 16-bit applications on a physical machine loaded with a 64-bit OS.

There's also the distinct possibility that the software they used ran from a floppy disk. I've not tried this, but I've heard rumor that even if you have a floppy drive, there are some programs that just don't run on modern Intel architecture. It wouldn't surprise me if the old 8088/8086 era memory architectures (i.e. extended memory and expanded memory) that stuck around through the Pentium days were done away with. Being their usage pretty much died out in the 90s, I couldn't imagine support continuing on indefinitely.

Point being, even if we had access to that software, it's not likely it would be useful to us today.

[tvrfan]

Cgrey,

Actually that's NOT TRUE !!
There are quite a few 16 bit emulators which run perfectly on modern 64 bit computers. Even common virtual machine systems (Virtualbox, VMware) have 'DOS Mode' options, which are 16 bit (but expect x86 programs). There are emulators for many, many 'foreign' hardware setups.

From the end of the Ford handbook it would seem they used a VAX setup, which generated binary files (at least that's what the diagram implies).

So from that era, it would be a reasonable guess at a VAX PDP11 or VAX11 (32 bit version). They were both common and ran various operating systems, proprietary, UNIX and DOS variants. A search for "VAX Emulator" on web shows there are emulators around, there's even a short emulator section in Wikipedia's PDP11 entry.
So it might well be possible to do this, but as to whether any of that software still exists.... well that's another question entirely.

I actually recognised some of those VAX photos - makes me feel even more ancient.....I worked on a VAX11/780, but can't remember which OS, whether it was UNIX or not (RSX-11 was very popular, but proprietary).

[cgrey8]

Actually that's NOT TRUE !!
There are quite a few 16 bit emulators which run perfectly on modern 64 bit computers...There are also 'direct' type emulators for many things, e.g. DOSBOX for old games, which runs in Windows and Linux.

The emulators may be emulating to run 16 bit code, but the emulators themselves are compiled to be, at least, 32-bit, if not 64-bit.

Or am I wrong about that too?

...From the end of the Ford handbook it would seem they used a VAX setup, which generated binary files (at least that's what the diagram implies)...

That doesn't surprise me that they didn't use PCs to assemble their source. Mainframes were still quite big in the 80s and far more powerful than any desktop of the time. I remember when I first started here at my job back in 99, I was given a hand-me-down Pentium 133. To do a simple "compile" of our application took 10s of seconds to do the simplest of programs. Although that was actually pretty good to the old-timers at the time as they had been working on 386s and 486s where compiling meant multiple minutes of waiting. Once they upgraded me to a Pentium 500, the same task took 5 seconds maybe?

Point is, if Ford was having to assemble, burn, and test a lot of different strategies all the time, they needed processing power. I'm sure I'd be dumbfounded to know the technology they work with today. Although I doubt they are using it to make binary compiles. Their big number crunching tasks are more likely to run simulations...of which, probably do run on Intel architecture today. But maybe not.

...A search for "VAX Emulator" on web shows there are emulators around, there's even a short emulator section in Wikipedia's PDP11 entry !!

So it might well be possible to do this without too much hassle, but as to whether any of that software still exists.... well that's another question entirely.
I actually recognised some of those VAX photos - makes me feel even more ancient.....I worked on a VAX11/780 running UNIX for a short while.

It might be possible, but I'm not sure about the "...too much hassle" part. Then again, maybe they would be reasonably easy to work with. Relatively speaking, mainframes were much simpler than even Win2k was. So emulating one including their common OS might be easy. But trying to do what Ford did with the code is something altogether different.

Given enough time and resources, you can make most anything pull 10 second quarters, but it'd be a lot easier to start with something intending to do that. Thus, I still believe working with the tools we have today and the online resources of people that know those tools is far more preferable than trying to figure out how to make their stuff work.

But you are right, I probably said all that a little too absolute.

[tvrfan]

Yep, that's all I was trying to say - that there IS stuff around which could run that ancient software. May be hard, may not be.... don't know.

As I understand it -
The emulators *themselves* are 32 or 64 bit, but they present/emulate a 16 bit address range. Virtualbox/VMware actually use the 16 bit mode of the x86 (which is still there) so they aren't full hardware emulators, but then they do emulate stuff like the old soundcards and peripherals, so it's all a bit grey.

Whereas the full emulators (for games consoles, old CPUs etc) actually DO emulate the CPU.
In fact I read that DOSBOX does emulate an 8086 in software, so writers have full control over the emulation.

Hey, it could be that if Ford used Unix on their VAX(es), then their cross assembler code might even compile !! 'C' hasn't changed hardly at all for backwards compatibility - wouldn't THAT be amazing....

In order to get some stuff to work for SAD, I've had to emulate some of the instructions (e.g. address indexing), and I will have to do more to get variable arguments to work.

[sailorbob]

The calibrations were supplied as binary files to the chip manufacturers, this is described in the ROM identification section of the strategy documents.

[cgrey8]

...As I understand it -
The emulators *themselves* are 32 or 64 bit, but they present/emulate a 16 bit address range. Virtualbox/VMware actually use the 16 bit mode of the x86 (which is still there) so they aren't full hardware emulators, but then they do emulate stuff like the old soundcards and peripherals, so it's all a bit grey.

That is likely. The hardware chips still support you installing a 32-bit OS and with that OS, you can still run 16-bit applications, which means the hardware does still contain the support. It's just the 64-bit OSs have dropped that support, and I believe they are doing so because of the security holes in the old 16-bit stuff. In fact, I remember developers telling me that Windows closed those holes in the 32-bit world, which a lot of times had to do with differentiating between a real pointer and a virtualized pointer. Evidently 16-bit applications were doing pointer math that just isn't allowed in the 32-bit realm. I think this was to give them access to hardware registers or maybe to do inter-process communication with shared memory? I'm out on a limb with that speculation. But suffice to say there was no way they could sand-box the 16-bit code without breaking functionality. Virus writers often took full advantage of the leeway that Windows was giving to 16 bit applications so Windows was eager to drop support for 16-bit as soon as they could and it was decided that the 64-bit OSs would be where that happened.

However being the hardware still supports this, Virtualbox/VMware/VirtualPC would have access to the hardware via virtualization technology in the processors (assuming you have that enabled in the BIOS). So they would still be able to perform these actions on-behalf of their guest 32-bit OS.

...Whereas the full emulators (for games consoles, old CPUs etc) actually DO emulate the CPU.
In fact I read that DOSBOX does emulate an 8086 in software, so writers have full control over the emulation...

I've only used mame and the Original NES Nintendo emulator for playing old arcade and NES games. I have an Atari emulator, but I don't recall what it's name is. But I do believe they are completely emulating the target processor. I remember reading about Mame, and I believe there were 2-3 different processors that were popular in the arcade world in the 80s. I think the Z80 was one? But all these were sub 10MHz processors, most of which were closer to 1-3MHz. So emulating one of them on a multi-GHz, multi-core processor is not that challenging. Although the time and effort it took to implement it in software is impressive...something you would know a little bit about.

...Hey, it could be that if Ford used Unix on their VAX(es), then their cross assembler code might even compile !! 'C' hasn't changed hardly at all for backwards compatibility - wouldn't THAT be amazing....

If you could get a hold of their original source, you are probably right. Although the H-files might have to be tweaked to work with GCC. They most likely were using a Unix, but I don't have a clue how cross-compatible code written for AT&T or BSD Unix is with Linux and the GCC libraries. If they had custom/proprietary libs that were never ported to Linux, you'd have to reinvent them or rewrite the C-code in those areas to use an open source alternative/variant.

As I said, anything can be done with enough time and diligence. But would it be worth it? The answer to that depends on the individual. Some people, it would be just to give them something to do. The journey, not the outcome, would be the reward. For others viewing the task with a more practical eye would likely come to the quick conclusion of "No."

[XantheFIN]

I don't know that it would do you any good, even if you had a copy of the software.

Remember, whatever software they used, was intended for a machine of the 80s. And assuming that machine was Intel-based, it was most likely a 16-bit application that ran under MS-DOS. It wouldn't be compatible with any modern day 64-bit Windows OSs, of which no longer support 16-bit applications of any kind, even ones compiled for Windows.

I think the last attempt to support 16-bit applications on 64-bit machines was with Win7 Professional where you could download and run an "XP Mode" (32-bit) virtual machine which would allow you to run your older 16-bit applications on a physical machine loaded with a 64-bit OS.

There's also the distinct possibility that the software they used ran from a floppy disk. I've not tried this, but I've heard rumor that even if you have a floppy drive, there are some programs that just don't run on modern Intel architecture. It wouldn't surprise me if the old 8088/8086 era memory architectures (i.e. extended memory and expanded memory) that stuck around through the Pentium days were done away with. Being their usage pretty much died out in the 90s, I couldn't imagine support continuing on indefinitely.

Point being, even if we had access to that software, it's not likely it would be useful to us today.

Not so fast with making things so hard with emulators and so if it's old DOS software.


(Sorry not bothering make english as i moved other projects etc.. but you get idea with picture and links)
http://xanthe.arkku.net/?lang=fi&p=1b

Just make Windows 98 DOS bootable USB stick. Boot into that and enjoy (MS-)DOS on any pc!
Next thing is maybe with those softwares that you need real COM port and i have old T42 Thinkpad with modded real COM port for that fun.

[ollopa]

According to various sources of information...

Ford in the 1980's used DEC-20, DEC-VAX, PDP-11, and LSI-11 computer systems for strategy development.

They used remote terminals to log into a development environment called VECTOR that ran on DEC-20 and VAX mainframes. VECTOR was developed in-house at Ford and presented a menu interface to the various pieces of software used for development (FACT editor, compiler, variable analyzer, strategy analyzer, code generator, simulator, etc.).

Strategy development began with an English written specification called a strategy bluebook that was broken down into an algorithm, tabular data referenced by the algorithm, and calibration data which could be tuned during preproduction but was fixed after production.

The algorithm was hand-coded in assembly and the data was coded in a language called Ford Automotive Control Terminology (FACT). FACT was based on FLECS which is a structured preprocessor for FORTRAN. FACT provided two things: A data type specification with parameters such as signed or unsigned, range of values, and required resolution; and a meta-language for program flow. A FACT compiler would process the specification to determine what type of data to generate and how to manipulate it, then auto-generate assembler source for managing the data. The FACT-generated assembly would be merged with the hand-crafted algorithm assembly to generate the final strategy source code.

Independent of the 8061 assembly program, the algorithm was also coded into FACT which could auto-generate an algorithm implementation targeted for VAX machine code. This allowed engineers to compare the two implementation in simulation and measure how well they matched. The VAX version would be too inefficient to be put into an EEC but in theory it would exactly match the requirements it was auto-generated from, so it would act as a gold standard of behavior by which to compare the 8061 implementation to.

Controlled testing was done in real hardware using a programmable hardware simulator for the 8061 and in software using a simulation environment on the VAX. Identical input stimulus would be presented to both and their outputs would be compared statistically.

Strategy source files had a common base filename and varying extension according to function. FACT variable (data) specifications would go into a .FCA file and the FACT strategy would go into a .FST file. There could be up to two dozen files per strategy and they were broken out that way partially to control who had access to each part of the strategy.

VECTOR had two parsers: one for FACT variable specifications (declarations) and one for FACT algorithm specifications (strategy). The data specification would generate a symbol file (binary .BCA and pretty-printed listing .FCL) and the algorithm parser would generate an abstract syntax tree (binary .BST and pretty-printed .FSL). These would be binary representations of the FACT source code. All other programs in the VECTOR system would take the binary .BCA and .BST files as inputs.

The FACT compiler would take the BCA and BST files from the parsers and produce a .ACA 8061 assembly implementation of the FACT variable declarations and a VAX implementation of the strategy for simulation. A later enhancement would also produce a .80X 8061 implementation of the FACT algorithm section (auto-generated 8061 implementation to compare against the hand-crafted version). The compiler was broken into three components:

The Variable Analyzer would take the BCA and BST files and produce a .VAN file (and pretty-printed .VAL) which described machine-specific implementation details of the data defined the BCA file (storage assignment/allocation, base, displacement, etc).

The Strategy Analyzer would operate on the BST abstract syntax tree and create architecture-independent abstract machine code similar in concept to modern-day IL code. Its output would be a .AST file.

The Code Generator would produce the final machine-specific code and architecture-specific optimizations.

My primary source for this information is a document describing a performance evaluation of the FACT-generated 8061 algorithm vs hand-crafted assembly. I find its conclusion interesting:

The primary goal--to compile electronic engine control strategies for the Ford/Intel 8061 microprocessor from the higher level FACT language--was successfully met. A strategy was generated, passed certification tests, and controlled the intended vehicle successfully. Storage and time requirements were within those regarded as typical in normal commercial applications.

Engine control strategies are not normal commercial applications. The need to reduce unit cost to an absolute minimum dictates that the handcoded assembler version of the strategy be preferred to the EOS/RTI/FACT version unless storage efficiency yields a ratio close to 1:1, say less than 1.25:1 (FACT:Production)

There is reason to believe that the edge currently given to hand-coded assembler language strategies is short lived. A potential requirement exists to execute multiple concurrent strategies (perhaps engine control and transmission control). The multitasking environment of the EOS/RTI is ready for this--the production EOS is not. The use of a hierarchical approach, with its attendant inefficiencies, is absolutely necessary, even in hand-coded assembler systems, to reduce system complexity to understandable levels in multitasking environments. Thus the EOS sizes would become equal. As the size of the background strategy increases, the storage efficiency of the EOS/RTI/FACT system improves. Preliminary experience with the larger strategy bears this out.

The use of higher level languages for strategy development will yield the benefits enjoyed in the commercial environment where its use is universal.

There are three areas in which the current EOS/RTI/FACT approach could be improved.
(1) The EOS is written for the complete Ford/Intel 8061 environment. System generation should remove tables and code for input/output channels and other features which are not needed in the specific application.
(2) The FACT compiler maintains full precision in its computations. Many times the target of the expression uses only a part of this precision. New compiler strategies, designed and coded, but not tested, should be completed.
(3) Fixed-point code should be generated for the DEC-VAX. This would aid in the determination of correct engineering-oriented and binary-point attributes for variables. This requires only the writing of another code generator program for the FACT compiler.

This paper lists as references a few publications I wish somebody would drop in my mailbox for posterity's sake:
"The 8061 Microprocessor Software Manual. Ford Motor Company, Dearborn, MI, 1982."
"FACT User Guide. Ford Motor Company, Dearborn, MI, 1980."
"VECTOR User Guide. Ford Motor Company, Dearborn, MI, 1981."
"R.E. Gach, The FACT Compiler Status Report, Ford Motor Company, Dearborn, MI, 1983"

Also of curious note is the fact that Edward Nelson did a research project at Ford where he created a version of Pascal for the 8061 called Pascal-F. It had abstractions for the HSI/HSO I/O control as well an enhancements for structured data tables used in automotive control algorithms. They were able to reimplement an existing control strategy in Pascal-F but it seems to have been largely academic and bloated code by about 2x as compared to hand-crafted assembly.

John Nagle, also of Ford, did a follow-on research project to produce a code specification verifier for Pascal-F. His work was quite extensive and he has published his code from the early '80's on github: https://github.com/John-Nagle/pasv There is some interesting but non-production Pascal-F code there: https://github.com/John-Nagle/pasv/blob ... engine1.pf And our friend the EECIV is mentioned by name in this snippet: https://github.com/John-Nagle/pasv/blob ... ctuate2.pf

If I read between the lines I think Pascal-F was invented in Michigan and intended for automotive application but rejected, then considered by Ford's Aerospace group which is where John's work in mission-critical static analysis comes into play. All I can say is I had no idea this kind of work was going on at Ford in the 1980's and I'm very impressed.

[tvrfan]

Some interesting history there...

I was already wondering about the idea of a software 'engine model' (the idea of fuel, spark, throttle to get a basic rpm response) for a complete emulation of an EEC. So the fact that Ford did it (or partly did it) makes perfect sense to me. Interesting stuff about testing too.

So yeah, it sounds quite advanced for the times.

In the 80's we had people suggesting that the company should try out autotesting techniques. Never did it though, so testing was long and painful, and this was before proper IDEs and debugging shells/sandboxes, often all you got was a crash listing, and had to spend hours wading through pages of printed hex... (pre Windows, all text anyway)

When I look back now, some of the development jobs and decisions seem surreal, wasting huge amounts of man-hours for stuff that now takes seconds or minutes...... Ah well. And we (the company) should have jumped to Unix a lot sooner....

[srwarner]

:) this reminds me of my old days

Has anyone configured a simulator?
Found one (https://phyton.com/products/development-tools/80196)

With this set of tools, and the memory map, one can create a running simulation of the eec-Iv. I used to do this as a side project in my eec-iv days.

I used to play with the pascal compiler (though at a more granular level, and saw the 2x diff, the other fella/Nelson must have come along later with an entire strategy implementation, I’ll go read what he did some day). 100% of all the eec-iv stuff was written in assembly, then masm’d to a binary. The FACT stuff was primarily for control algorithms work, at least at the time I was involved; things like transient fuel/etc. Once the control system was understood, folks translated it to the strategy, which then ;) became the design to implement.

[jsa]

As a former EEC engineer, does this look familiar?

Code: Select all

223c: c3,01,00,1f,00      stw   R0,[R0+1f00]     [1f00] = 0;
2241: c3,01,00,1f,00      stw   R0,[R0+1f00]     [1f00] = 0;
2246: c3,01,00,1f,00      stw   R0,[R0+1f00]     [1f00] = 0;
224b: c3,01,00,1f,00      stw   R0,[R0+1f00]     [1f00] = 0;
2250: c3,01,00,1f,00      stw   R0,[R0+1f00]     [1f00] = 0;
2255: c3,01,00,1f,00      stw   R0,[R0+1f00]     [1f00] = 0;
.....