[note: copied from the Internet Archive "Way-Back" copy of
http://www.hitex.demon.co.uk/x86/oldx86.html, for JUne 2008. No longer available at hitex's Web site. - Herb Johnson]
This document will be of interest to reviving the following:
Intel Series I
Intel Series II
Intel Series III
Intel Series IV
PLM86, PLM286, PLM386, PASCAL86
IC86, IC286, IC386
Intel I2ICE, Intel VLSICE
Microsoft PASCAL
ZAX, Softaid, SAW, DUX
Aztec, Lattice C, Wizard C
Military equipment and major capital projects often need to be maintained over many decades. New features must be added and revisions made from time to time to keep the end-product up to date. With many microprocessor-based systems now being almost twenty years old, the original tools used are often no longer operable or at the very least, unreliable. To younger engineers, older tools are very difficult to use and are a major obstacle to making changes. However, Hitex has supported the Intel x86 and 8085 since the early eighties and is able to offer rehosting and recovery services to users of older tools.
Extended Lifecycles
The average lifecycle for most commercial microprocessor-based products is probably no more than 5 to 6 years. After initial release, minor modifications may be required to fix bugs or introduce new features. However the nature of most developments is that after 3 years or so, no further changes are made to the software in particular and the original team members drift to other projects or companies. End of story.
However, projects in the military and aerospace worlds tend to have a rather longer lifespan. Indeed some microprocessor-based equipment can be almost twenty years old, if it is based on the Intel 8086, for example. Typically, such equipment may be part of a larger command and control system or other major plant which is still commercially available and which may be an important part of a companies’ product portfolio. The 4mhz NMOS 8086 and its predecessor the 8085 are very common in military systems even though they are obsolete in the commercial world. It is a characteristic of many military projects that support is required for twenty years or more so these antique processors and their development tools (compilers, emulators etc.) are expected to have a very long life indeed.
Before The IBM-PC - The Series II/III/IV MDS
Whilst most modern microprocessor development is on the ubiquitous PC with a smattering of workstation and VAX hosts, in the early eighties when many of these systems were developed, the dedicated Microprocessor Development System (MDS) was the dominant development platform; on some very large projects, they would be used as an adjunct to VAX or PDP11 hosts. In simple terms, the MDS was an 8080-based computers whose purpose was to host the assemblers, compilers and emulators that were used to create new applications. The Intel Series II and III, a.k.a. the “blue box” were by far the most common, with the 8088-based Series IV being something of a latecomer. The sheer size and importance of the projects meant that they were conducted “by the book” with only Intel tools being permitted by companies. In many instances though, Intel supplied the tools gratis as an investment in future silicon sales.. Regardless of type, MDSs were enormously expensive and were accompanied by similarly pricey maintenance contracts.
The languages used would probably be ASM86, PLM86, FORTRAN or PASCAL with CORAL sometimes being seen. Ironically, the C language was still restricted to academics writing UNIX operating systems and was deemed to be unsuitable for major projects of the early eighties. Intel was a major producer of high level language compilers with SDL (now EDS) providing some specialist PASCAL and CORAL tools. The ISIS and iRMX86 operating systems provided the means by which the various tools were launched.
Restarting Old Developments
To meet the demands of modern standards or requirements of prospective customers for a major project, it may be necessary to modify the software from time to time. Despite the availability of superior PC-based versions of the same tools, many MDSs soldiered on into the early nineties, being periodically fired-up to permit the changes to be made. After long periods of inactivity, many such revivals were accompanied by a loud bang and smoke as tired electrolytic capacitors in the power supplies exploded into oblivion. Ultimately, the death nell for all the old Intel MDS was Intel’s 1993 decision to jettison its tools arm and stop support for all the old systems.
This has left many major products with a big problem in that the security and reliability of the original development tools cannot be guaranteed. The age of the microprocessors concerned means that hardly any of the leading tool manufacturers still produce and support, for example, 8085/86 in-circuit emulators. The compilers originally used on the MDS may well be formally validated for use on the project and may not even be updated let alone replaced.
Fortunately for the managers of vintage projects, there are ways of continiung support into the nineties and beyond. Hitex was one of the leading pioneers of PC-hosted development tools for Intel microprocessors in the early 1980s. Unlike other independent tool manufacturers of the time, Hitex developed PC/MS-DOS interfaces to Intel MDSs and their operating systems. These are still available from Hitex to help in the maintenance of older projects.
1. Software Tools
In cases where the compiler is hosted on a VAX, PDP11 or like minicomputer, the development can continue as before. Where the compiler is based on a defunct MDS, there are several options. The simplest is to obtain a PC version of the same tool. This may not be very straightforward as there is no guarantee that a PC version of exactly the same release level can be found which may not be acceptable. The other route is to rehost the compiler onto a PC using something like IDOS80 which allows Series II and III compilers like PLM80 to run under a simulated ISIS operating system environment on a PC. A basic obstacle to this is that the old tool must first be physically moved from the MDS to the PC. Attempts to force 8” disks into even a 5.25” PC disk drive will not prove useful as if nothing else, the disk formatting is totally incompatible!
The HTRANS serial transfer utility allows a serial connection between a PC and any Series II or III MDS. Whilst painfully slow at 1200 baud, the old compilers and files can be moved to a PC, given enough time. Once there, modern editors can be used to modify the sources and the IDOS80 generates an ISIS interface to MSDOS to run the compilers.
IDOS80 itself can work in two ways; firstly, it can simply simulate 8080 instructions on a 486 PC so that the old compiler can run. Alternatively, if a V30-based PC is used (itself, likely to be a museum piece!), the 8080 emulation mode can be used. However, with the speed of modern 486 and Pentium PCs, the simulation of the 8080 is not too slow.
For the 8088-based Series IV MDS, HTRANS will establish a link to a PC to transfer the compilers and source files. As the former can directly execute the 8088 instructions contained within the old compiler, the situation is not quite so complicated as with the Series II and III. What is required is a runtime interface between the iRMX-hosted compilers and MS-DOS such as HRI86. This utility simulates the Series IV environment whereby, for example, unit names (c.f. disk drive names) used by iRMX are assigned to the physical drives on a PC. The old compiler is then invoked from MS-DOS as a parameter in the HRI86 command line.
Tools such as the PSCOPE debugger are perhaps best left on the defunct MDS as more modern PC alternatives are readily available. Unlike the situation with compilers and assemblers, the retention of the original debugger will not have an impact on software integrity.
2. In-Circuit Emulators
Whilst compilers on MDS are often recylable, the old in-circuit emulators are likely to be lost cause. In the early eighties, emulators were at best temperamental and the passage of time will certainly not have improved them. The lack of any maintenance facility for old Intel ICE86s combined with their poor technical performance means that they are best replaced with more recent, PC-hosted systems.
Where a modern emulator is available to support the old CPU in question, the loading of the code and symbol information may be a real problem. The Intel OMF86 object format is still the standard for 16 bit x86 systems but the variety of languages in use ten or fifteen years ago can cause real problems to modern source-level debuggers which are almost exclusively C-orientated.
Hitex’s T16 emulator was originally released in 1985 for the 8086 but is now on its third generation. Whilst supporting the latest 80C186EB/XL etc. it still offers support for the obsolete NMOS 8086, 80186 and 80286 devices. The HiTOP emulator-based debugger and its forerunner HiUSE, can work with any compiler which can generate OMF86 object files, regardless of the language involved. True source level debugging is possible via an auxilliary file which relates the >8 character module names permitted by ISIS and iRMX86 compilers to the 8 character filenames under MS-DOS. This makes the display of the original source lines possible within the debugger, something that may never have been possible when the project was started.
Many specialist compilers such as EDS’s PASCAL and CORAL66 produce no usuable symbol information and only a bare HEX file is likely to be available. In these cases, there is almost always a MAP file of some description which contains at least the location of every public symbol. It is then reasonably straight forward to produce a translation program which will allow the debugger to access addresses within the program via symbols, considerably more convenient than entering addresses for breakpoints etc. manually.
In a few instances, early versions of PC-based Microsoft and Borland PASCAL compilers were used from 1982-86. These produced .EXE files which usually required bolt-on locators to produce the HEX files needed for EPROM blowing. In the absence of commercial EXE file locators, companies produced their own in-house. To rehost the compiler output to an embedded 8086 required some homebrew assembler code to provide the runtime services provided by MS-DOS v2.11. Whilst these compilers did produce some symbol information their MAP files, it was not usable by Intel emulators.
Unfortunately, modern EXE file locators like Paradigm’s LOCATE and CSI’s CSILOC usually cannot handle antique EXE files, especially as the custom runtime environment code often contained absolute addresses above 1MB, which are not really supported. This effectively prevents modern emulators from being used, at least for symbolic debugging. HiTOP and HiUSE running on the T16 emulator can however extract usable symbol information from MAP files and assign the correct absolute addresses, independently from the locator. The HEX file used to produce EPROMS is subsequently loaded into the emulator to mate up with the symbols. Ultimately, it is possible for the debugger to display the source lines by using the CLIST source to LISTfile convertor. Hitex has developed a number of techniques for allowing these old PC-derived compilers with the modern HiTOP186/WIN which allow full source level debugging, including source lines.
Specialist Tools - Performance Analysers
One of Intel’s most interesting tools was the old iPAT software performance analyser extension for the ICE86 and I2ICE86. The use of this tool was mandatory on many military projects prior to any new software release. The non-availability of original iPAT units is not a problem as the Hitex equivalent to this is HiPAT16, which is still available as an extension to the T16 emulator. The original concept of iPAT has been extended by HiPAT16 and is worthy of a article in its own right.
Where To Get Help
Hitex are happy to advise or assist with the recovery or rehosting of x86 projects from obsolete hosts and can provide both consultancy and new tools. Continued support can be guaranteed for as long as necessary for long term projects.