Last edit April 16 2018 (c) Herb Johnson
This page began in 2009, to report on the software tools Bill Beech developed to work with Intel's 8-bit and 16-bit object file formats for their 808X products. Bill developed cross assemblers and non-ISIS tools to work with ISIS programs. Over time, Bill worked with ISIS disks, systems and programs. Following that work, others obtained Intel MDS systems and contributed their results accordingly. This Web page is therefore accumulting work-in-progress, so it will be a bit "lumpy" in continuity. - Herb
[Bill Beech NJ7P contacted me in June 2009 to exchange manuals and resources about our Intel System 310 Multibus systems. Since that time, we've talked about a number of his Multibus projects under 8080 and 8088 processors. Check this linked Web page, for links to all of his activities, and about Bill and his other work on the Web. Bill produced many Web pages about Intel Multibus development tools and systems, and the tools he's developed. I think the development discussion is informative, so this page preserves the discussion. My half of the conversation is in italics, some embedded comments of mine are in []'s.].
In June 2009, Bill and I discussed how to emulate and run Intel's8080-based ISIS OS. Later on, Bill obtained an Intel 80/10 8080 CPU board, and decided to build an ISIS system around it. Along the way, he built a number of software tools, or used tools he built previously. Our discussions about the 80/10 and ISIS are on another page.
In the fall of 2016, Bill and others engaged in email discussions initiated by Richard Main, a Multibus developer in the era, about obtaining and archiving today additional ISIS and Intel disks and Intel programs. Richard produced an archive and Web site, which unfortunately went away in 2017. Bill Beech and others have archives and programming resources on their Web sites. I'll try to detail developments in notes at the end of this Web page. - Herb
In Jan 2011 I asked him about making your own tools versus using other people's tools:
I understand the general impulse to make one's own software tools. But there's a lot of value in common tools that get improved over time, and common discussion about those tools. Together they encourage and support others who can use those tools, who are not able to create their own. That said, by all means consider making your tools available from your Web pages.
Those are a good points. I have made a version of my assembler available to the N8VEM group but they seem to want to stay with the proprietary assembler. Mine had some bugs to be worked out.
In June 2009 he described that assembler:
Working right now on a public domain assembler for 8048/8051/8085/z80 that I built for the N8VEM computer group. I have added relocatable object modules to it, using the old 8086 OMF as a basis. I can't seem to find the 8085 OMF that was described earlier. I am modifing the format slightly to fit better with the 8-bit processors with 16-bit address space. Have the assembler outputitng the relocatable modules, now I am working on the linker.
Jan 2011: Sure would like to find a copy of the Intel Relocatable Object Module Formats for the 8085! [That is, the] ISIS PLM compiler and ASM80 output relocatable object code in the version 4 format. It was used in the 1970's and early 80's. The manual was order 121747-001 "MCS-80/85 Relocatable Object Module Formats Manual". It was morphed into 8051 format then into the object format used by Microsoft and such in the 80's and 90's. That [later] manual was order 121748-001 "8086 Relocatable Object Module Formats" which is on bitsavers.org.
I'll see what I have. But I just looked through my immediate reference books from Intel and others. Most of them are hardware references. The software references at best document use of linkers (Microsoft's, DRI's, Intel's) but not their object code formats - [my impression is the object code formats were] mostly considered proprietary.
Actually, they standardized the OMF and it is on the internet. I have a z80 assembler I wrote that generates OMF in the X86 standard format. Used to use Microsoft Link to build executables for the Z80-based radio TNC's. [But] the earlier format lends itself to the 8-bit machines much better.
[Bill later added:]
Myself, I'd do a few things. One, some Web searching through tech magazines of the era and just after - see if someone disassembled the object code format, for various reasons. Two, see if some commercial or shareware/freeware assembler/linker uses the same format AND explains it or documents it. (I did a little of that as below.)
[I've] done a lot of searching. I would rather write my own tools - I really like doing it. I have tools to manage .IMG files for CP/M and ISIS-II. I have assemblers for 8048, 8051, 8085, Z80 and 6800. I even have a parser for PLM-80 BNF nearly working. Once it will parse a bunch of test PLM files I will get it to emit 8085 code.
Three, assuming you get/have working linkers, assemble a bunch of code with various offsets and examine the results. I haven't poked at it myself in decades so I don't recall how complicated it is.
I have written a disassembler to pull the code apart generated by the PLM-80 and ASM-80 Intel tools. I also have a tool to dump the V4 ,OBJ files so I can see what they generate. I will use that knowledge to build the code generator for the PLM compiler. Then there are the disassemblies and disPLM of the ISIS object code. I am in the process of reading the source code from the ISIS internals document. I have the source code in text format for all the iSBC208 drivers from the HWR manual.
[Bill and I discuss the ISIS side of things on another Web page. - Herb]
Will let you know when I have CP/M and ISIS-II up on the emulator and on the hardware. The ISIS-II code I have is for an older board so the I/O will have to be changed to work on the 208 controller.
I have disassembled the isis.t0 (booter) and isis.bin programs from ISIS-II V4.1. They are built to use the old two-board floppy disk controller or one with the 8271 controller. As I said, I have gotten pretty good at writing PLM from the disassembly. Almost all of ISIS was written in PLM. I need the source code to modify for the iSBC208 and later the iSBC214. The 214 is a combination of the iSBC215G, iSBX207 and iSBX208. I have several of them and they are direct replacements (no code change) for the three boards. So very slow progress on this. - Bill
[I did some Web searching in Jan 2011, and found a few sites and documents. Bill and I discuss them below. - Herb]
[My recent] Google search for "intel 8080 Relocatable Object Module Formats" yielded some links that may be marginally useful.
I have [also] spent a lot of time looking for information on the internet. A lot out there and a lot to pour through!
[this cfg.com Web site has] some tool which claims to support the Intel format. Probably not enough details.
This 8051 site has an Intel prublished 8051 document "EXTERNAL PRODUCT SPECIFICATION FOR THE MCS-51 OBJECT MODULE FORMAT V5.0", 1982, as an OCR'd document.
look for a copy of the IEEE-695 "IEEE Standard for Microprocessor Universal Format for Object Modules". May not be useful.
This MSX archive site has docs and programs. MSX was Microsoft's Z80 OS, mostly used in Japanese products in the 80's. May be informative to the extent someone disassembled something like LINK-80. Docs and executables for LINK-80 and MACRO-80 are in several CP/M archives.
Here's a "free" book about the art of 8086 disassembly on a Wiki or as PDF, with links to decompilers and such. Kinda interesting for your other purposes...
Are you familiar with these linker documents from the Tool Interface Standard (TIS) committee of the 1990's?
Open Watcom seems to have some Intel development documents on their site, including Intel's hex format document.
Bill responded:
[The MCS-51 object specification] is the morphed OMF for the 8051. I have [this document].
[The IEEE-695 Standard is] good info for a generalized solution but I want to be able to use the original tools even if under the ISIS emulator. It appears to be too generalized to provide info on the internal of version 4.0
MSX programs used a bit-streamed format that is very hard to work with. I have investigated these for 30 years and believe Intel had it right in going with a byte-oriented OMF.
[The X86 disassembly book] is a good book. I had not run across it in my searches of the net. Thanks!
[The TIS linker document] is the current X86 standard. It is what the 8085 standard became. I have these and have written a Z80 assembler that uses these. It is a poor fit to the 8-bit machines - tailored to the 16-bit X86 architecture. - Bill
Lotsa of good info [at the Open Watcom site.] I have [the Intel document you reference].
I want the 8085 spec so I can completely decode the output of the Intel PLM compiler and ASM80 assembler. I have most of it decoded and have regenerated the spec. There are some fields still that are not obvious. This is just fun to tinker with and is a part of the history that has been lost. - Bill
In Feb 2012, Bill did some more work on his 8-bit tools and ROM monitor:
I did synchronize some "include" files used in all my 80/10 software. I revisited a stack problem in the BDOS - currently using an external stack which works fine. I have the console I/O separate from the rest of the monitor. I changed the iSBC 208 base I/O address to 040h and verified everything worked. Found a couple of hard-coded I/O addresses in the monitor which are now fixed. I had to do this because [a Zendex 80/05 CPU I'm working on] uses I/O addresses 0-FH. I also have a iSBX 354 on the 208 board, so I can develop a console driver for the monitor.
I have assembled the monitor and the i8251 driver, linked them, and copied them onto a CPM floppy. The monitor ran! So that is a step much closer on the assembler/linker. This will allow me to have a library of serial drivers for the monitor, and select the one I need for the particular hardware target I am working on.
I also got the assembler to generate relocatable object modules in the Intel standard. I have a version of link also working and generating simple CPM .COM files.
Herb noted: Linking assemblers are a little uncommon in the early CP/M world. If you have time to write this up a bit, maybe refer to the Intel docs that provide further info, that would I think be a good thing.
Actually, Microsoft and DR used the .REL format, which was a bit-stream to save space on disk. Both were available in the late 70's. I like the byte-oriented format used by Intel because it is so much easier to work with. It was the basis for the current OMF's for the X86 processors. I will add a few things to it, such as named segments and comments, once I have a good set of reliable tools. The linker just fell into place from the object module dumper I had writtten.
[Although one can use "includes" and "if/then/else",] that is the technique I used before the linking loader. But it makes the code a mess and the nested includes are a pain to follow. Separate modules makes a whole lot more sense and require a lot less development and maintenance time.
Mar 5th: My linker is not generating a proper monitor ROM image [for an 8085 board I'm working on]. (Code segment org'ed at 0h and Data/Stack/Memory segments org'ed at 7800h as required by the board). So I have added a -R flag to the linker which passes the ROM and RAM origin to the linker. Now to get it to actually work.
I am at the point where I need to do a clean up to remove some unused code and variables, and possibly move some code out of the main file into one or two other files. I also duplicate sections of code in different parts of the linker, crying to be made into a subroutine. I have lost sight of the use of various parts of the symbol structure to the point of having duplicate entries. I hope to do this today. Each feature I add to the linker seems to simplify the code, when all is done.
Mar 11: Have gotten more on the linker and assembler. I have a bug resolving the public and external addresses together. The linker is getting confused, so I need to relook at my logic there. The resolution of addresses in the current segment and to an external segment is all working.
Mar 18: I have been working on multiple problems in the software. I corrected a bug in the linker so it would generate a correct .COM file for CPM80. Working on getting a usable memory map output from the linker. I have got a version of the monitor to work on the iSBC 80/10 with the iSBX 354 on the iSBC 208 board. This is a large step forward. I have to assemble the 354 driver for a different location (iSBX socket on the ZX-80/05) and link it with the monitor code to burn into a ROM. We will see if it works.
The Zendex [8085 board] is alive! The monitor just came up using the 354 serial board. I have some more work to finish the clean up of the monitor program. This is stuff left over from the move to linking the monitor to the driver.
May 28th: I have half completed my rewrite of my cross assemblers. I have one executable to handle all of the different processors. My main concern was I never did a complete analysis of the operands. This allowed errors to go unfound. This was a problem with the z80 assembler when we were doing N8VEM. I have got the relocatable stuff working on the 8085. I need to add some to the segment stuff to allow me to use this all properly on the monitor programs.
June 11: I have been rewriting the assembler and writing test code to verify each path (by a number) the assembler follows. I have found several holes in the process which cause the assembler to miss errors and have fixed them. I am closing in on one assembler executable for all the different processors which is configured by the first line in the assembler file. And I am now only generating an 8-bit relocatable object file IAW the Intel document. HEX and BIN files will be generated by the LINK/LOADER commands and some utilities. This is in keeping with the ISIS ASM80 and CPM RMAC assembler operation. These two assemblers are really tightly tied to the OS they support, so I will need a mode command in the assembler to switch. Default is for CPM-80.
June 28: I have been working on the assembler, disassembling most of ISIS-II V 4.1, and the linker. The problem I am trying to address is the lack of a real absolute or bin format, especially for the ROM images. The ISIS-II absolute load format addresses this nicely, allowing absolute load code to specify a starting address for each block to load. Currently, my .BIN format handles the load at 0 with ROM set at 0, but the file also pads with zeros to include the data segment located at the RAM address. Since all the RAM I use in the monitors is uninitialized, the linker does not need to do anything with it. I will have to think that one over. Another approach would be to output the link output as a hex file, which could have different load addresses, and a start address, which the ISIS II format provides.
I am in the process of cleaning up the monitor code to have separate modules for the monitor, the I/O driver, the iSBC 208 driver, and the IDE driver. This gives me one assembler file to modify to add functionality to all the different versions of the monitor for both the iSBC 80/10 and the Zendex ZX-80/05. One batch file will build all the different versions.
- Bill
In April 2018 I moved this material to my "restore" Web pages which focus on more recent Intel 8/16 bit and ISIS software work. Check there for the amazing progress made from 2016 into 2018 and beyond. - Herb
Contact information:
Copyright © 2018 Herb Johnson