• Please review our updated Terms and Rules here

Intel User Libary - mid-1970s 8080

J

jonhales

Experienced Member
Joined
Jun 3, 2014
Messages
56
Location
UK
In researching the history of Intel's Intellec series (8, 8/80, 800, etc) I've come across references to a library of routines that Intel made available to users for an annual subscription of $100.

Here are screenshots of two pages that give hints about the scope of the library:

1976 Intel Data Catalog page 10-46 (on bitsavers)

IntelSoftwareLibrary1976.jpg





1979 inSite Program Library Volume 1 (also on bitsavers)

INSITE_pgmLibrManVol1__Page_007.jpg



It doesn't appear that any of the material from Intel's collection is available through repositories such as bitsavers, archive.org and other sites. Note: I'm not referring to the ISIS-II software that Intel issued on floppy, much of which is available.

Does anyone have any of the 8080 material, whether on paper tape, floppy or as listings? I'm particularly interested in locating programs for the Intellec 8/Mod80 and MDS-800.

Documentation of the software would also be of great value.
 
I'd have originally thought that this was the type of thing the Intel Museum would archive. I was wrong. I was interested in 4004 stuff but it turns out that I have more 4004 software than they have ( which isn't much ). I've been trying to recover Tom Pittman's 4004 assembler that ran on the Sim4-01 board. I've got EPROMs of the set but one of the EPROMs has got serious bit rot.
Their libraries were relatively good. Since things were on paper tape, their prices were not that bad.
For the 8/Mod80, you'll have to ask around for others that have them. For the MDS-800s there are a number of people with disk images and a few manuals. They kept the same vectors for the Series II machines so most software that ran on a Series II would run fine on a MDS-800.
Dwight
 
Is the code for your Sim4-01 EPROMs on the web anywhere (or would you be willing to share them)? I might be interested in seeing if I can reconstruct the bits that have rotted! Multiple sets of eyes and minds might help?

Dave
 
I'll send you a copy but it is in really bad shape. Even some of that looks like good code may have some issues. You also have to realize, this was mostly hand optimized code. I suspect Tom used a lot of tricks to get things the way they were.
Dwight
 
Thanks to Dwight and Dave.

A point I could have made in the initial post is that Intel later referred to the library as 'Insite'. For example, the "User's Program Library Catalog" dated 983 and also on bitsavers, continues to refer to some programs for the 8008 and 8080 processors.

As noted in the initial post, I'm interested in the programs and documentation - if any of the material still exists in someone's collection.
 
I thought I'd refresh this. I'm especially interested in a copy of the native Intel 4004 assembler, that was written by Tom Pittman. I have a copy on EPROM but I regret that the last EPROM has significant bit rot. I believe the copy I got is a copy of an original EPROM that had bit rot and not just the original with bit rot.
I'm asking for anyone with old 4004 stuff or old 1702s to look to see if they have one labeled A0743.
Thanks
Dwight
 
Do you want binary or hex? One file or 4 files?
Partial disassembled?
I've not seen the code anywhere on line.
I have the files address and data inverted, as it was originally for PMOS levels. It is both levels inverted to make sense when looking at the code. I'm currently analyzing the tty input routine. That is mostly in the first EPROM. It looks like it expects the data to have the MSB set to a 1 and use 7 bit ascii.
Dwight
 
Last edited:
Four (4) separate binary files (labelled something obvious like A0740, A0741, A0742 and A0743) in a single ZIP would be my choice.

Something that is directly readable as the contents of the 1702's would also by my choice.

If you have started your disassembly - that would also be a useful start.

From what I have read there is a 256 byte monitor (1 off 1702) and 768 byte (3 off 1702s) assembler. I would, therefore, assume that the terminal handler code is all within the A0740 ROM. But, as you say, (with tight limits on memory) there may be a few tricks pulled and bits of the monitor may have strayed out of A0740 - or bits of the assembler may have strayed into A0740...

Dave
 
Before I go farther I'd like to describe what I have and are working with. The PMOS uses inverted level for the physical EPROMs. This means that logical address 0 starts at the physical address of the EPROM of 0FFh. The data is similarly inverted. On my setup, the MCB4-10, there are switches to allow one to invert both address and data to match what is produced by a standard assembler. This is what I used to dump the EPROMs. So, I do not currently have direct EPROM image data. If you want, I can invert address and data to provide actual EPROM images, if that is what you really want. This would be incorrect for someone that used a 4289 that expects true data and address of the EPROM. I believe this is only related to use on the SIM4-01 or SIM4-02. I believe the Mod4/40 uses the normal data used by the traditional assembler output.
So, the question is do you really want the inverted data as are on the physical EPROMs or the normal data as would be used by other uses.
I would have to write an inverter first. ( not a real big deal but I wonder if that is what you really want ).
I don't believe there was an actual monitor on the SIM4-01 board, since there is no way to write and execute code on the SIM4-01, like with a 4289 or a Mod4/40.
As far as I've got, there is a simple editor that allows one to enter text on the tty to go directly to tape. I've not yet got to the editor function as it has take me some time to find the trick to end the edit function. I've just recently figured it out, it was a simple EOT ( I've forgotten too much over the years ).
I will be looking at the assembler operations next, at least as far as I can get before hitting the bit rot.
I should note, the editor has some code on all four EPROMs but is mostly on the first EPROM, A0740.
You can PM me with an address to send the files.
Dwight
 
Last edited:
Sorry Dwight, I wasn’t clear enough.

I am not interested in the data as stored within the 1702 EPROM but as the 4004 CPU will process the data.

For example:

The instruction RD0 would be coded as 0xEC, RD1 as 0xED and NOP as 0x00.

Likewise for the corresponding address.

Dave
 
That is what I thought. That is why I asked. In order to make sense of the data, you'd need to invert everything. I do have the EPROM file split up as well as one single large file, with all 4 together. The only thing to realize, when trying to analyse the data, is that you have to think about is that the erased value is a 0 bit instead of a 1 bit if it was the unmodified data straight from the EPROM.
The program uses 3 port bits, as described in MCS-4 User Manual. Input is taken from ROM0, bit0. A mark is seen by the code as a 0 and a space as a 1. There are two outputs. These are output bit0 of RAM0 and bit0 of RAM1.
RAM1 is used for the reader enable. A 1 enables the next character. RAM0 is the tty output. It is expected to be feed from a ASR33 like tty with 110 baud and 2 stop bits.
There are a number of tricky code tricks used. From a straight disassemble, the JCN operation can be used as a SKIP operation. At address 76h you see:
75 FIM RC 40
77 SKIP
78 FIM RC 00
If the code is entered at 75, RC is set to 40 and the processor only sees the 00 as a nop at 79. If the routine is enters at 78. RC is set to 00. In other code I've seen, the SKIP is used with the LDM, single byte instruction. This is the first I've seen with a two byte instruction.
Expect to see several different code tricks use as Tom was working with minimal space. I expect to see cases where undefined instruction are used. The 4004 treats them as NOOPs, as far as I can tell.
The input routine echos characters as it goes but there is a separate print routine as well.
That is all I have right now. It has taken me a little time to get the event coding working with the serial data but I've got that working now. The character loop is 357h processor cycles.
If you want, I can send what I've disassembled so far but it is in a form that I can use with my Forth assembler. In other words what is normally:
FIM RC 40
is:
40 RC FIM
It is a little confusing at first but one gets used to it.
Dwight
 
>>> It is a little confusing at first but one gets used to it.

Mode FORTH Engage.

Your partial disassembly would help to kick-start me off.

Dave
 
Hi Dave
At address 75 is the input routine. I've got that relatively worked out. The serial input returns as a byte in RE and RF with MSBs in RE.
I've not looked to much at the PRINT routine but it is at 50h. It also uses RE and RF pair. I've identified a number of ASCII codes that are printed in the comments.
The input routine also returns 0Ch in the accumulator. The input code does use this value as a simple way to see if low nibble contains the number 4 ( part of the EOT value ), by adding the number in RF to ACC to trap out EOT. Most routines use " 0 BBL " for the return.
A couple things about register pairs. When used as a pair, the lower numbered register is the higher MSBs of the pair. So when referencing, say a RAM with a register pair, the two high order bits of the lower numbered register designate the RAM within the SIM4-01 RAM bank. The two low order bits of the lower register combine with higher numbered register to create the address within the RAM. The status nibbles only use the the 2 low order bits of the lower numbered register and ignore the higher numbered register. ROMs are similarly referenced, with the most significant nibble in the lowest numbered register. So, the instruction " 12 RC FIM " would put 1 in RC and 2 in RD.
The Intel manual is not too clear about how this works. One has to think in terms of nibbles and also, how the register pairs are used.
ROM I/O can be used as inputs or outputs. This is usually a mask fixed thing on the 4001s. The SIM4-01 supports both input and output of the ROMs. The code only uses the ROM I/O ports as inputs and RAM I/O ports are always outputs.
It takes a little while to think in terms of nibbles instead of bytes. At least HEX values help in doing this.
The SIM4-01 only has 128 bytes ( 256 nibbles ) of addressed RAM. There are the status nibbles as well. There is one status for each 4 nibbles or 64 nibbles, in the SIM4-01, that uses 4 ea 4002 RAM chips. It often helps to think of them as a different addressable space, rather than trying to keep track of which ones are associated with which RAM locations, since one uses a different instruction to access each of the 4 within a particular RAM space. I've found it too confusing to try to keep track of how the RAM was physically, even if the data in the addressable RAM was associated with those particular status nibbles. These status nibbles were a holdover from the calculator usage as things like sign or exponents, associated with the particular RAM. Most of the code I've looked at just treats them as more storage.
Dwight
 
Last edited:
Dwight Elvey said:
I thought I'd refresh this. I'm especially interested in a copy of the native Intel 4004 assembler, that was written by Tom Pittman. I have a copy on EPROM but I regret that the last EPROM has significant bit rot. I believe the copy I got is a copy of an original EPROM that had bit rot and not just the original with bit rot.
I'm asking for anyone with old 4004 stuff or old 1702s to look to see if they have one labeled A0743.
Thanks
Dwight
Click to expand...

Hi Dwight, over the coming days I will will go digging into my old eprom horde. I know I had some 1702's just not sure what they were from, but I do have some pcbs that have 4004 support chips and I have vague memory I got a pcb with 4004 and support chips and eproms, but that was 40 years back and I am not sure where it got put during house move 20 years ago

regards
David
 
Last edited:
inotarobot said:
Hi Dwight, over the coming days I will will go digging into my old eprom horde. I know I had some 1702's just not sure what they were from, but I do have some pcbs that have 4004 support chips and I have vague memory I got a pcb with 4004 and support chips and eproms, but that was 40 years back and I am not sure where it got put during house move 20 years ago

regards
David
Click to expand...

It is always interesting to look at code from this early 4004 stuff, even if it isn't Tom's assembler. Both Daver2 and I can disassemble the code quickly for you.
Looking at code written for a printer control, I discovered a new use of the JCN ( conditional jump ) instructions and added it to my disassembler. It is what I call a SKIP instruction. It allows the next instruction byte to be skipped. The particular combination of the condition bits are used to never take the branch. The next byte can then be used for another instruction, say for common entry into a routine. An example might be:

DOCR LDM 0D
SKIP
DOLF LDM 0A
PRINT ....

Commonly used values can be attached to the print routine saving space in several places in code that uses these values.
There were many pieces of code written by Tom Pittman. It seems he may have been the first independent micro computer programmer. Tom had given his assembler to Intel and when Intel got request for someone to write code, Tom was often referred to. One wonders which pieces of code he had his fingers into?
Dwight
 
Dwight, DaveR

It's great to see there's some life in this thread. I'm not able to contribute as regards 4004 code, however. But your discussion is good to follow.

I recently acquired a 1975 Intel manual on PL/M programming for the 8008 and 8080. It's scanned and ready to be provided as a PDF to anyone who would like a copy. Just let me have a PM.

I'm still very interested to track down code from the Intel InSite Library, which is why it's good to see activity.

Regards

Jon
 
Daver and I are making some progress. We've got through the first part where it makes the first pass, picking up labels and adding marks for text to be ignored on the second pass. We,ve not exhausted all of the first phase. So far we've seen that the coding isn't too friendly to disassemblers. Tom had used a number of coding tricks to save every byte possible. I've been using my own simulator and Daver has been using one he got off the web ( I think he said it was written in Java ). Mine is in Forth.
He has run into one stumbling block. The 4004 has 4 registers for the stack. The PC uses one level so you normally can only go three levels into subroutines ( no stack is provided for data, you need to keep such in RAM ). If you use 4 levels of stack, the first entry is overwritten. In most cases, this would be considered an error but, like I said, Tom used every trick in the book. It looks like he has intentionally allowed this to happen. I suspect he uses it as a mode switching, while the stack is used for things like fetching and printing data. Clearly not to friendly but clever. It seems the simulator code that Daver has considers it an error. It isn't clear in the manual that last JMS actually wrote the PC to the stack but it does say that the 4 JMS will destroy the value saved from the first JMS instruction.
I don't have a ASR33 setup right now so I need to fake the punch operation. As soon as I have that working, I can make more progress.
Daver and I have been making comment in our assembly code as we go along. I hope to be assembling my first NOP soon.
Dwight
 
I solved the problem with the stack. I slightly re-wrote that part of the emulator.

I then found the assembler I was using (to assemble the disassembled source code with my created comments) complained at the "JIN P5" instruction at the end of the page. The assembler had implemented the 'rule' that this was illegal source code. I had the source code to the assembler - so that is valid now!

I am still not getting what you have so far though. I suspect another bug in the emulator somewhere.

I found this when writing the 6809 SuperPET emulation for VICE. I started off by using someone else's 6809 emulator and found so many bugs in it I had to throw it away and find another one with fewer bugs. Fortunately, I also found a 6809 instruction validation program that I was able to run. That also found an emulator bug... Just one though (that I fixed).

Dave
 
Yep, there is a major flaw in the emulator I am using.

The emulator doesn't bump the PC on for every instruction it reads. As a result the conditional and indirect jumps go to the wrong page if they occur at the end of the page (they go to the current page that the JIN/JCN is in rather than to the next page).

I will see what I can do to correct this...

Dave
 
You must log in or register to reply here.
Back
Top