Project Logs

Collapse

• EPROMs

  jimshortz • 12/10/2023 at 21:53 • 1 comment

  Typing in hex is fun and all, but it gets old quickly.  Thankfully, Intel provided an EPROM expansion option that makes this easier.  By soldering in an additional socket, you can add your own 2 kilobyte 8755A EPROM that is mapped to address 800-FFF hex.  (It's also worth noting that you can replace the factory ROM with your own 8755A as well.  I haven't tried that yet).

  8755As are still readily available on eBay and other vintage parts sources.  However, these devices used a 25 volt programming voltage which is not supported by modern day programmers such as the venerable TL-866.  I searched the interweb and found Matt Millman's design for an 8748 programmer with optional 8755 adapter.  This is a fine design, but is overkill for my needs.  I don't need to program 8748s and don't own the Arduino Mega needed to host it.

  Since I already have the "Arduino of the 1970s", with ample RAM and GPIOs out the wazoo, the best choice for me was to build another daughterboard to program ROMs.  The design is trivially simple.  I use an off the shelf DC-DC converter module to produce the 25 volt programming voltage.  Matt's switching circuit was used to provide either 5 or 25 volts to Vdd.  Everything else is just straight through GPIO connections (see eprom.pdf).

  The support software is at https://github.com/jimshortz/sdk-85/tree/main/sys.  eprom.a80 contains the core programming routines written in assembly.  epmgr.plm is a fully featured, menu driven programming manager written in Intel's PL/M high level language.  It includes commands to download files from the host as Intel hex, perform blank checks, verify ROM contents against the buffer and, of course program the buffer to ROM.  It can also read ROMs into the buffer and upload contents back to the host.  This allows it to be used to duplicate or reverse engineer ROMs.

  To avoid the multiple stages of bootstrapping, I built a copy of my hex loader and located it at 800 hex.  I also included a copy of Simon at A00 hex.  I burned this to a ROM, so I can now easily download hex code after power-on by typing GO 800 enter.  (Or go A00 enter for Simon).

• Expansion: Phase 2

  jimshortz • 09/21/2023 at 00:20 • 0 comments

  While it's fun to play with a keypad, GPIOs, and 7 segment displays, you really can't do much without some more RAM.  In particular, I wanted to be able to run some vintage Altair software and do the normal "computery" things.  So, after handling the basics I set about adding significantly more RAM and a real serial port.

  As described in Table 3-4, Intel provided two options for the bus expansion - all addresses or upper 32K.  While having the full 64K to work with sounds appealing, there is a big caveat - you have to remove all of the existing RAM, ROM, and keypad chips.  If you are going to lose all of the special things that make it an SDK-85, you might as well just build your own board with an 8085 on it.  It would honestly be easier.

  First, a word about project goals.  I strive to keep this system as close to "period correct" as possible.  You won't see ethernet controllers, Raspberry Pis, or other modern wonders tacked onto it.  However, 1970s RAMs were very small and narrow.  32K in those days likely meant adding sixteen 4116 DRAMs along with refresh circuitry.  This SDK-85 appears to have exactly that.  This is just not something I want to undertake, so I have made a concession and am using a more modern single-chip 32K static RAM (the 62256 type).  The system will behave exactly the same (except for being slightly faster) and this is a reasonable compromise for convenience.  Also, I don't want to consume the entire prototype area with RAM.

  Given my difficulties with the "bit bang" serial port built into the 8085, I also wanted to add a real UART.  I chose the 8251 because it was an Intel part from the same time period that would have been used on other 8085 systems.  Also, I had one :-)

  Intel made it very easy to add things into the upper 32K.  My glue logic is implemented in a single 74LS00, with one gate to spare  The RAM is enabled if A15 is high and IO/M is low.  The UART is enabled if A15 is high and IO/M is high.  The 62256 and 8251 use Intel-style /RD and /WR lines, so no additional glue was needed.
  

  Fig 1 - Super Simple Glue Logic

  I also chose to do this part using wire wrapping.  This is to recreate more of the vintage experience, but also allowed me to incrementally add upgrades and easily change things around in the future.  I did not solder the chips down, so that all of this could be removed in the future to return the board to museum quality.

  I started by wiring in the RAM.  This was very straightforward and worked correctly the first time.  To test it, I simply used the keypad to punch data into 8000,8001, and FFFF and read it back.  I eventually wrote something to write the old 55 AA pattern and test every bit.  No problems encountered.

  The UART, however was a different story.  I used this vintage INS8251 from Radio Shack that I had in my junk box:

  Fig 2 - Vintage UART

  When I attempted to read and write the ports, nothing worked.  I tried numerous troubleshooting steps for days.  Eventually I intentionally swapped its CS line with the RAMs so that I could access the UART as a memory location and the RAM as an IO port.  RAM as I/O worked fine, so I didn't have any fundamental misunderstanding of how the IO ports worked.  But when I would read from the UART I would get back the port address (80 or 81) as data.  What the heck?

  Eventually I started looking at the /RD and /WR pulses on the scope and that got me thinking.  I re-read the datasheet for the INS8251 and discovered it expected a 430ns read pulse width.  Since the SDK-85 uses a 3.05Mhz clock, I was only getting a 327ns pulse.  Believe it or not, this part was too slow for the SDK-85.  So, I ordered a genuine Intel 8251A (320ns clock pulse width), installed it, and everything...

  Read more »

• Serial Port Part 1

  jimshortz • 09/20/2023 at 01:44 • 0 comments

  The Simon project was hand assembled and hand typed.  That was a lot of fun and was rewarding.  However, you quickly hit the limit of what can reasonably be done that way.  Several days after posting it on Hackaday, we had a brief power outage from a thunderstorm.  Retyping it was a 20-30 minute job.  While not awful, this isn't something I want to do every day.
  

  So, it was time to see how "the other half lived" and check out the SDK-85 serial port.  The manual explains the ROM monitor commands.  However, if you really want to know what's going on, AP-29 explains how the 8085 built in serial port works.  Basically, it's just bit banging the SID and SOD pins and using timing loops to achieve the desired bit rates.  While AP-29 provides tables for different baud rates, the SDK-85 firmware is locked to 110 bits per second (7E1).  Furthermore, it does not use a regular RS-232C interface but instead uses a 60ma current loop interface.  This is what the ASR-33 teletype of the time used and Intel chose to support this popular (at the time) piece of hardware.

  Section 5-7 provides instructions for converting the SDK-85 to use RS-232C (+/- 12V) signaling rather than current loop.  It begins with the phrase "If you are fortunate enough to have a CRT terminal...".  However, I chose not to do this since it was a modification and I wanted to leave the board as original as possible.  So, instead I designed and built a current loop to RS-232 adapter.

  Fig 1 - RS-232 converter

  This is a simple circuit that uses optocouplers to bridge between the receive and transmit loops and TTL-level signals which are immediately converted using a MAX232-type chip.

  Fig 2 - RS-232 converter schematic

  However, when I connected this to my modern laptop, I got nothing but garbled text.  Since scope traces revealed correctly formed characters I decided to do a loopback test.  It turns out that FT232RL-based USB to serial adapters are not capable of running below 183 baud.

  Having no other options, I pulled out an old DOS machine with a physical serial port and was greeted with an "SDK-85" prompt.  Success... sorta.

  The next challenge was formatting the data.  The SDK-85 monitor allows code to be loaded using the `I` command which accepts a single address, followed by 0 or more hex characters and an escape character.  This is not the standard Intel hex format that my tools emit.  So I did some hacking and came up with a script that converts each Intel hex record into an I command.

  Anyone who has connected a vintage computer to a modern one knows what happened next - data overruns.  Lots of them!  I was honestly surprised by this because 110 baud is extremely slow - surely the processor can save a byte of data every 80ms?  But the problem lies in the bit banged nature of the port.  The processor is busy waiting for every single bit (including the stop and start bits).  It has no time to do anything else.

  This problem is further compounded by the monitor's echoing back the typed characters.  A bit banged port is half duplex by necessity.  While the processor is echoing the character back, it's not doing anything else.  It definitely can't be receiving another character while that's going on.

  The obvious solution is to ask the terminal program to "slow down" and pause between characters.  My "go to" DOS terminal is MS-Kermit, but it only supports inter-line pauses, not inter-character.

  Since I didn't want to undergo a market survey of DOS terminal programs, I booted into Windows 98 and used Hyperterminal.  I don't love this program, but I was able to get the job done after enough digging around in the menus.  The secret is File->Properties->Settings->ASCII setup.  After some experimenting, I settled on 200ms delay.

  Fig 3 - Hyperterminal...

  Read more »

• Expansion: Phase 1

  jimshortz • 09/17/2023 at 19:06 • 0 comments

  As mentioned previously, the "basic configuration" consists of 256 bytes of RAM, 2K of ROM, and 36 GPIO lines.  There are also three ways the board can be expanded:

  * Add a second 8155 IC to double the RAM to 512 bytes.  This also adds 20 additional GPIO lines and a timer.

  * Add a second 8755 IC to double the ROM to 4K.  This also adds 16 additional GPIO lines.

  * Add bus expansion drivers to allow whatever the heck you want to be added to the prototype area.

  These upgrades are independent - you can do any combination of them.  It's also worth pointing out that if you perform the bus expansion upgrade, you can add generic 32K SRAMs and EPROMs giving you far greater amounts of RAM and a ROM that is both larger and easier to program.  These generic parts are also much easier to acquire.

  However, I chose to apply the 8155 upgrade as it was easy and I wanted the additional GPIO lines and timer port.  Simon did not fit in the basic RAM and I didn't want to undertake a large upgrade until I finished that project.

  I acquired the 8155, the 8212s, 8216s, and 74AC00 at the same time from a small vendor in the US with a healthy chip stash.  You can also order them from eBay, but will likely have to use multiple vendors and possibly go overseas.  It was much easier to just go to a single source.  Not all of the chips were advertised on his site, but I contacted him via email and he did have everything I needed.

  Installing the 8155 was straightforward, just solder in a 40 pin socket and plug the chip in.  Or at least it should have been.  After installing the new 8155, the system would no longer start.  After a couple of agonizing hours of troubleshooting, I discovered the problem.

  The SDK-85 is a 12 inch x 12 inch two layer board.  The bottom layer is mostly ground pour.  So, the ground pin of the 8155 had quite a large heat sink attached to it.  This resulted in a faulty solder joint that my aging eyes were unable to detect on the first (or fifth) inspection.  After cranking the heat and re-flowing, I was able to get a working system again with double the RAM.

  Fig 1 - The second 8155 installed.  Obviously a second source (Mitsubishi)

  Some weeks later I added the bus expansion chips as well.  This involves adding nine chips to the board:

  * Two Intel 8212 8 bit latches (for demultiplexing the address lines)

  * Five Intel 8216 buffers (for driving the big banks of RAM folks would have had in the 1970s)

  * A 74AC00 and 74LS74 for glue logic

  Each chip was installed with a socket and also required a 0.1uF disc capacitor for bypassing.  Strapping changes were also required as described in the manual.  After installing all the new chips and capacitors I tested them by booting up the system and everything worked correctly.  Little did I know that one of the 8216 had a bad ground pin connection caused by the heat sinking problem again.  This would rear its ugly head during a later phase.

  
  Fig 2 - All 9 bus expansion chips installed

  The bus expansion upgrade by itself does nothing. What I added is complex enough to get its own post which is forthcoming.

• First Programs

  jimshortz • 09/17/2023 at 18:26 • 0 comments

  Next, it was time to get familiar with programming the SDK-85.  As I often do when learning a new language, I decided to do a math problem.  Prime finding is my go-to, but with a 7 segment display I decided to go for something less verbose.  So, Fibonacci sequence it is.

  I wrote the code out on lined paper, leaving lots of space for the hex on the left side.  After writing the code I broke out the 8085 reference card and performed the translations.  To the modern reader, this may sound like absolute hell, but these programs are so short (and the instruction set so simple), assembling them takes only a couple of minutes.  That being said, my first attempt to read and write variables from memory used the MOV M,A instruction.  It did NOT work like I expected so I had to spend some quality time with the Intel 8080 Assembly Language Programming Manual to learn how these instructions work.  (Hint: you want LDA/STA, not MOV).

  My first version used 8 bit BCD numbers and would produce the numbers up to 99.  I used the FIRST and SECOND variables to contain the N-1 and N-2 values used to generate N.  I used UPDDT to display the number in the data area and RDKEY to wait for user input to move to the next.  Turns out there are only 12 numbers < 99, so this was pretty anticlimactic.

  My second version used 16 bit BCD numbers and produced numbers < 9999.  Amazingly, this version was 9 bytes smaller.  It was far easier to use use the BC and DE pairs to hold N-1 and N-2.  XCHG can be used to promote N-2 to N-1, and single byte PUSH and POP instructions preserve the values when ROM calls are made.  The astute reader will notice the use of the semicolon.  That's because I forgot the DAA and didn't want to erase and rewrite half the page.
  

  At this point, I decided to move onto a more "interesting" application and set about creating the Simon game.  Click here for details on that project. 

• Adding Connectors

  jimshortz • 09/17/2023 at 17:32 • 0 comments

  Other than the DB-25 serial port, the SDK-85 comes with no connectors.  However, the manual is quite complete and provides recommendations on page 3-5.  

  It is important to install the power connector for several reasons.  First and foremost, you want to avoid accidentally revering the polarity which would likely destroy this vintage board.  Equally important is to not mix up the +5 and -10V supplies as that would also destroy things.  Lastly, being able to unplug the power allows for the board to be easily flipped over for soldering, wire wrapping, or inspection.  I found myself flipping the board quite a lot.

  I was able to locate the Molex power connectors from several sources.  The easiest was a kit available from Digi-Key.  I was able to assemble the connectors using an ordinary "automotive-style" crimper.  I installed the male housing on the board and used the female housing for the power supply cable.

  However, I did make a mistake in assembly - I used a male housing but female pins.  I discovered this error when trying to connect the power cable which was male pins in a female housing.  It was difficult to get the connectors to mate and then the pins pulled out of the female housing.  I was able to work around it by jamming the wires into the pins without using the housing, but I need to fix this as I have negated the two most important benefits of the connector.

  Fig 1 - The "hacky" power connector

  I was unable to find the "spectra strip" connectors described for J1-J5.  So, I used snap pins instead.  I chose the extended length kind (Digi Key part S1052E-36-ND).  This allows me to connect either an IDC ribbon cable up top, or use the bottom for wire wrapping.  This also makes it possible to build daughterboards that plug directly on top of the SDK-85 and sit over the wrapping area.

  Fig 2 - Header pins installed in GPIO port

  Fig 3 - Header pins used as wrap posts (underside of board)

  Lastly, I used individual snap pins for the +5 and GND lines.  This provides both an easy point for wire wrapping and also a place to connect test equipment topside.

  Fig 4 - Power pins

• Initial Checkout

  jimshortz • 09/17/2023 at 17:05 • 0 comments

  What Is It?

  The Intel SDK-85 is a single board computer trainer from Intel.  It is very similar to the MOS (later Commodore) KIM-1 in that it features a keypad and 7 segment display.  2K of ROM and 256 bytes of RAM are provided by two multi-function chips (8155,8755) which also provide a generous 36 GPIO ports.  The board can be programmed using either the keypad or via a 110 baud serial port.

  The left half of the board is a "playground" area where the user can add their own chips (via wire wrapping).  Expansion options exist to double the RAM and ROM, and expand to a whopping 72 GPIO ports plus a timer.

  My Story

  The board was acquired from a local ham for a small cash sum.  Several years ago I missed an opportunity to get a Heathkit ET-4000 (it was literally purchased by the person in front of me in line for $20).  When I saw this SDK-85, it was a "buy first, ask questions later" situation.  As such, I am unsure of its history.  I didn't even think to make a note of who I purchased it from.

  The kit was in very good condition.  The original box, manuals, and 8085 reference card were included (the latter being very important).  It was a basic kit (no expansions) but had been fully assembled.  The only thing not attached was the red lens, but it was included.

  Fig 1 - The board as delivered

  No connectors were included, so I soldered some 18AWG zip cord into the connector holes.  I connected it to my bench supply and was greeted with an "8085" prompt after applying power.  All of the keys appeared to work and no smoke came out.  I keyed in the "4 digit hex counter" program from the manual and it worked correctly.

  Next, I typed in the "decimal counter" example.  This one did not work so well.  After some debugging I determined that the problem was due to interrupts.  Evidently, the authors of the manual had neglected to include instructions to clear out the RST vectors in RAM.  After doing so, the program worked correctly and I was smugly confident about discovering their oversight.

  Fig 2 - An appropriate program from the manual

  After some time, and having similar problems with other programs, I began to question my previous conclusion.  I started reviewing the construction steps just to make sure the previous builder had done it correctly.  On about the third read through, I discovered a mistake.  On page 3-4, the builder is instructed to strap pins 3 and 5 together if using the basic kit.  This step had been omitted.  After applying the strap, all of the example programs worked correctly without modification.  Omitting this strap was causing spurious RST6.5 interrupts to be fired, and my software changes had simply covered up the problem.

  I also used some double-sided tape to attach the red lens.  This was the original specification, though the suppled tape was long gone.  I used some 3M tape left over from hanging a poster.

  At this point, I now have a fully functioning "basic kit" with 256 bytes of RAM and 2K of ROM.

View all 7 project logs