📄 oldx86.htm
字号:
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="Adobe PageMill 2.0 Win">
<TITLE>Untitled Document</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff" BACKGROUND="../image98.gif">
<H1>Long Term Development Tool Support For Intel 80x86 And 8085 Systems</H1>
<P><HR ALIGN=LEFT></P>
<P>This document will be of interest to reviving the following:</P>
<P><B>Intel Series I<BR>
Intel Series II<BR>
Intel Series III<BR>
Intel Series IV<BR>
PLM86, PLM286, PLM386, PASCAL86<BR>
IC86, IC286, IC386<BR>
Intel I2ICE, Intel VLSICE<BR>
Microsoft PASCAL<BR>
ZAX, Softaid, SAW, DUX<BR>
Aztec, Lattice C, Wizard C</B></P>
<P><HR ALIGN=LEFT></P>
<P><CENTER><B>Synopsis</B></CENTER></P>
<P>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.</P>
<P><B>Extended Lifecycles</B></P>
<P>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.</P>
<P>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.</P>
<P><B>Before The IBM-PC - The Series II/III/IV MDS</B></P>
<P>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.</P>
<P>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.</P>
<P><B>Restarting Old Developments</B></P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<H3>Recycling And Rehosting Old Tools</H3>
<P><B>1. Software Tools</B></P>
<P>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!</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P><B>2. In-Circuit Emulators</B></P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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 <I>above</I>
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.</P>
<P><B>Specialist Tools - Performance Analysers</B></P>
<P>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.</P>
<P><B>Where To Get Help</B></P>
<P>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.</P>
<P><HR ALIGN=LEFT></P>
<P><IMG SRC="../image62.gif" WIDTH="98" HEIGHT="97" ALIGN="MIDDLE" NATURALSIZEFLAG=
"3" ALT="ts86"><B><A HREF="x86index.html">Return to x86 main page...</A></B></P>
<P>
</BODY>
</HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -