Intel SDK-80 module

This Web page last updated date Sept 17 2020.

Introduction

I acquired this Intel SDK-80 board (with chips) sometime in 2018 or 2019. It's pretty dusty and has some unknown history of use. I'll keep track on this Web page, whatever I do with it.

I have other Multibus items listed on this linked Web page. - Herb Johnson

SDK-80 board

So this is a 1975 Intel SDK-80 board, which supports an Intel 8080 and provides some serial and parallel I/O. The edge connector is some early version of Intel's Multibus. There's a prototype area in the upper right of the board, which has several wire-wrap sockets wired up. They are wired to the LEFT-hand DB-25 connector. There is a right-hand DB-25 connector with cabling; oddly enough nothing is wired to it.

The closer photo near the crystal, gives a little better idea of the condition of the board. Again, dusty and slightly rusty. The solder-side of the board, looks like hand soldering. It's possible that Intel sold this board unassembled, maybe they supplied the Intel chips too.

The board as obtained was populated with the Intel chip-set as appropriate, and some TTL logic. On the board photo you can see that I pulled them off. However, the wire-wrapped proto area chips were NOT on the board. So those chips are unknown. The 2708 ROM is hand-marked "SDK", presumably the SDK-80 Intel monitor program.

SDK-80 chips

Immediate inspection of the Intel chip set on this board, showed some damage. The surface damage to the ceramic gold chips is clear: a cruddy rust, and also dirt on the white ceramic. the closeup of the 8255's provides detail.

While almost all of the chips have intact pins (so far), unfortunately the Intel 8080 chip does not. A legs-up photo of the 8080 shows the missing pins. Apparently the huge ZIP socket gave less protection from corrosion than the cheap TI and Augat sockets under the other Intel IC's.

The 2708 is intact and readable. See my "MON-80" details below.

Restorations by others

My good friend and colleage Jon Chapman AKA Systems Glitch, decided in 2019 to restore an SDK-80. Along the way, he produced a modern RAM module to provide substantially more memory on the board. You can read about his RAM board on the linked Web page. There's a link to his "clean-up" work also. When I saw Jon's module available in early March 2020, that encouraged me to dust off this board. He discusses his work at this link, on the SDK-80 in 2019.

And, Robert Coward has done a nice restoration of an SDK-80. He has the unassembled kit too. I'll add some photos of his results soon but here's a small photo of the kit and assembled board. Robert's done a bunch of code recovery too and some tools, they are on various free shared-drives and so not readily accessable to the public. Here's a ZIP of the SDK-80 codes he has made himself. I discuss the SDK-80 monitor sources later in this Web page.

He says ".. [my assembled SDK-80 board] was not too bad, actually, though I had to replace every IC socket, as they were causing unreliable operation. I was also lucky with the unbuilt kit, insofar that the conductive foam was turning into disintegrating goop. But it hadn't done any significant damage to the IC pins. The IC sockets and D type DB-25 connector were worse, though cleaned up after dipping in vinegar solution. And the PCB was perfect, as it had apparently been stored away from the foam; it would have been ruined if it had contacted the old goopy foam. The unbuilt kit had several components missing, including the CPU, but I managed to source almost identical replacements."

Restoring my SDK-80

The board is stripped of wire-wrap sockets and the 40 pin ZIF
The back of the board
I did a little damage to the CPU area, a few PC lands lost
... but the wirewrap sockets and components came out without damage

Space for the GW-SDK-80 RAM board

A profile of the ROM and 8212 area where Jon Chapman's SDK-80 RAM board might fit. I'm worried about the height of the 8212 sockets on the left versus the address decoder sockets on the right. The RAM board straddles both.

SDK-80 MON-80 monitor

The 2708 is intact and readable. I'm fortunate to have an ancient 2708 PROM reader. So, the binary file is here and the Intel hex record file is here. According to Robert Coward, my binary matches the Intel source he has. That calls for a little explanation....

Source errors

Another friend and colleague Bill Beech AKA NJ7P, has a huge Web site of Intel Multibus work. Among his pages are a collection of ROM monitor programs including the SDK-80 monitor. Bill and other sites like bitsavers.org, have the "intel MCS-80 System Design Kit User's Guide" on their sites as PDF files. But there's a problem with variations of the SDK-80 monitor listings in those PDFs.

An imaged PDF of the SDK-80 monitor is at bitsavers.org. I explain what "imaged" means below. Unfortunately, some earlier OCR'd PDFs of the SDK-80 monitor, have some transcription errors. Look at the locations 029CH to 02A1H for the HILO routine. This PDF file has the correct instructions, they are consistent with my binary. The correct code should be:

        HILO:
        29C C5        PUSH B
        29D 47        MOV B,A
        29E E5        PUSH H
        29F 7A        MOV A,D
        2A0 B3        ORA E
        2A1 CA BD 02  JZ 02BDH 

The Intel SDK-80 Manual includes a MON-80 source listing. Some years ago, Bill Beech at nj7p.org obtained the SDK-80 source and assembled it into listing and Intel hex. As of June 2020, these sources and listings are now consistent with the binary I have. Prior to June 2020, Bill's source had the HILO code error, and also mis-assembled a string as a single character. Those are since corrected on his site, and these files are the early June 2020 corrected versions. I believe the code error in HILO was in code Bill Beech recieved; as I'll describe below.

The problem with the MON-80 source, began with an OCR or transcribed listing of the source, put into distributed PDF's of the SDK-80 Manual. At some early point, a transcription (or edited OCR) of the listing as text, contained errors in the HILO routine. A PDF of the listing text with those errors, replaced the PDF of the image of the original listing in the manual. And, as Robert Coward pointed out to me, a imaged PDF of the source in the SDK-80 manual, has different (correct, same as my binary) codes for the monitor. Here's a ZIP of the SDK-80 codes Robert produced.

So if you obtain a PDF of the SDK-80 manual, see if the listing pages "look like" OCR'ed text; or if they look the same visually as other pages in the SDK-80 manual. Imaged pages usually have dark spots of dirt, and of course images of holes, tears, colors, etc. PDF's of OCR'ed or other text pages are "clean" and the text is crisp. Verify the HILO routine in whatever sources you have.

As of June 6 2020, the SDK-80 manuals at bitsavers.org and Bill Beech's nj7p.info, have the incorrect PDF source listings. Again: the link above to a PDF of only the monitor listing, is the correct source. The SDK-80 manuals as PDF's, are otherwise just images of the original pages except possibly the code listing pages. Bill is aware of the SDK-80 manual problem, this is an effort in progress. My thanks to Robert Coward for finding this problem and calling it to attention, and to Bill Beech for responding to this alert in June 2020.

Jon Chapman's monitor notes

Jon Chapman asked me to read off my PROM, as he had some issues with a PROM monitor on his boards. Here's what he found in mid-March 2020:

"I got a chance to test your ROM image out, and it does work! I've run into an issue with the SDK-80 monitor that I finally figured out: on all previous versions I've tried, except the heavily modified one that came with my SDK-80, the `G` command didn't seem to work properly. I assumed this was due to the other ROM images being corrupted or incomplete. Your image behaved the same, though! It turns out the problem is this:

* When the monitor starts up, it initializes the USART then saves some registers, including the stack pointer, assuming that it may have been entered through a breakpoint
* The `G` command, with no starting address, will use the saved SP, registers, and PC to return from the breakpoint
* If you specify a starting address, e.g. `G0800` the starting address is pushed onto the stack so that the same RET that works from breakpoints can be used
* The problem is, they restore the user SP, and when the monitor first comes up, the SP after a reset is in an invalid state.

Jon said: "Intel should've included a flag for whether or not the monitor had been initialized previously, or if it was coming up from a cold start. The fix is of course to modify the two memory locations used to save the SP and set them to some valid area of memory." He and I discussed various fixes.

But later he reconsidered. "We were both overthinking this: the solution is to press RESET twice on power-up :) Thought of it this morning when I was moving the SDK-80 stuff around. The second reset causes the monitor's stack pointer to get saved out, and there's enough room in the stack for the two-byte return address. - Jon Chapman

Copyright © 2020 Herb Johnson