• Expansion: Phase 2

    jimshortz • 1 天前 • 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 • 2 天前 • 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 • 5 天前 • 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 • 5 天前 • 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 • 5 天前 • 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 • 5 天前 • 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.