Project Logs

Collapse

• I/O - Part 1

  camfarnell • 05/02/2023 at 23:34 • 0 comments

  There is a fair bit to the I/O side of this machine. I had planned on doing a log entry once the I/O was done but it's taking a while so let's do an update now.
  

  There are six facilities to the Rack8 machine's I/O:

  1. The Keyboard
  2. The Bank Latch
  3. The Memory Mode Latch
  4. The Debug Latches
  5. The Omniport
  6. The System Latch

  Currently the first four are up and working while the Omniport and the System Latch are next in line for implementation. So what are these things, and what are they for?

  But before we launch into the details, a couple of photos. The breadboard version of Rack8 is built on a piece of wood to which are attached the solderless breadboards. But the board was full and now it was time to implement I/O. So I literally glued another piece of wood onto the top of the existing wood, attached more solderless breadboards, and populated it with the proposed I/O chips. Photo, as of two weeks ago, here:

  Now with much of the I/O working it looks like this:

  while the whole project now looks like this:

  with the I/O section way up at the top. Note the 20 conductor ribbon cable at the very top which goes off to the keyboard.
  

  The schematic for the implemented-so-far IO can be found here.

  Behind The Scenes...

  There are two GAL chips, upper left corner in the schematic, that generate the pulses to clock the various IO devices and any other signals needed. The logic equations for those GALs can be found here and here. Do note that both of these are a work-in-progress and will change as the rest of the IO is implemented.
  

  The Keyboard

  It's kind of obvious what this is for but the way it is implemented in the MCM/70 and hence this machine is interesting. Unlike most microprocessors, the 8008 I/O-READ  instruction is actually a WRITE-READ operation. Yup, a single instruction can both write and read at the same time. During a READ operation the content of the accumulator is presented on the low 8 bits of the address bus while the data to the processor you need to present on the data bus.
  

  The MCM/70 took advantage of this when reading the keyboard. The keyboard itself is just an X-Y matrix of keys; no chips, no diodes, just the keys. To scan the keyboard the CPU does an IO-READ operation wherein - on the WRITE side of things - it sends one bit to the X part of the matrix and - on the READ side of things - sees what comes out from the Y part of the matrix. By probing all eight possible WRITE bits you can which key is down, or if none are down.

  In the schematic the components for the keyboard start in the middle and then move diagonally to the upper right. In the middle U34 and U34 - open drain inverters - send the bits from the address bus to the keyboard which is connected to J5. What comes back from the keyboard is gated onto the data bus by U36. Because it's driven open drain, the pullup resistors RN5 keep any undriven lines high. Part of the reason that it's driven open drain is that the keyboard, like the original MCM keyboard, has no diodes so open drain keeps things from shorting if the user presses more than one key at a time.
  

  The Bank Latch

  Like the MCM/70, this machine has 16 banks of 2K each at address X'1800'-X'1FFF', and only one bank at a time can be active. A 4-bit latch, set by IO write instruction X'51', selects the current bank. In the schematic the Bank Latch is over on the right side in the middle. Nothing exciting here although - brain fade alert - I initially had the input to the bank latch connected to the data bus. You get data from the data bus, right? Well not on this machine you don't. Took me a bit of debugging to figure that out, then we had a DUH moment, followed by some rewiring. Then it worked..

  The Memory Mode Latch

  As discussed in the Real Memory log post, there are four bits that control the mode in which the Rack8 memory works at any given time. In the schematic U41 is the 4-bit latch that actually provides the bits. When the machine is running, the memory mode can be...

  Read more »

• The Keyboard - Part 2

  camfarnell • 05/02/2023 at 23:20 • 0 comments

  I've spent the last few weeks working on I/O but the keyboard is one of the main I/O devices so it kind of fell into the mix. The good news is that the keyboard itself works as intended: no messed up traces on the PCB or the like. The bad news, not that there was much bad news, is that I was short a couple of key switches and had to order more. There is not much more to say about the keyboard beyond that it works and I think it looks great. The keyboard, less the missing Space and Backspace switches, looks like this:

  While an actual MCM/70 keyboard looks like this:
  

  Not identical, but close enough.
  

• The Simulated SelfScan

  camfarnell • 03/23/2023 at 20:01 • 0 comments

  I don't have a SelfScan. eBay doesn't have any SelfScans. I would be delighted to source a working SelfScan and, in theory, it should plug into my Rack8 machine and work, provided I conjured up the required +250 Volt supply. If I had a real SelfScan I would be willing to do that. But in the mean time I've built a Simulated SelfScan which is plug-compatible with a real SelfScan other than not needing the high voltage.

  So here is my simulated SelfScan showing a few of the special APL characters (and a Syntax error, but we will overlook that):
  

  The photo really doesn't do it justice The crud at the bottom is reflections off the screen (which the camera picks up like crazy but in person is hardly noticeable) and the actual text is much closer to "SelfScan orange" than the photo would suggest. My simulated SelfScan consists of:

  • An Arduino Mega which responds to the Clock, Reset and Data lines that are intended for a real SelfScan, and
  • A 5" LCD TFT 480 x 272 color display screen from buydisplay.com. By using four screen pixels for each SelfScan pixel we use up 444 of the available 480 pixels in width.

  The displayed line is smaller than what a real SelfScan would show but it's way bigger than the usual text on my laptop so it's easily readable. A 7" display would probably result in something close to original SelfScan size.
  

  In the photo above it is the 8008-1 CPU, and the SelfScan interface described in the previous log, doing all the work. All the Arduino is doing is pretending to be a SelfScan. If I ever do get a real SelfScan, that would be great, but for now this will do.

  The code currently in the Arduino is proof-of-concept and quite slow: it takes about one second to do a full update of the SelfScan line. But we are turning on each LCD pixel individually and there are 6216 of them. There are various techniques that will speed this up a lot. Now that I know it works, writing that code is worthwhile.
  

  The entire system, as it currently stands looks like this:

  The simulated SelfScan is upper right with the SelfScan interface just below. There is actual text on the SelfScan but you will probably need the larger image to make it out.
  

• The SelfScan Interface

  camfarnell • 03/23/2023 at 00:16 • 0 comments

  The SelfScan was the visual output device for the MCM/70 computer. It could display one line of 32 characters, and it looked like this:

  CRTs were available at the time but they were very big, very heavy and very expensive. Not great for what was intended to be a small, portable machine. The SelfScan, made by Burroughs,  was a plasma display device with the method of operation similar in some respects to a Nixie tube. It was called a "self scan" because you didn't have to address the dots on the screen: after hitting it with a Reset pulse you then provided the 222 bytes of data in order and it "scanned" along by itself. It was actually pretty clever. Today it looks horribly dated but in the early 1970's it was quite reasonable. The version used by MCM provided a screen 222 pixels wide by 7 pixels high. Being memory mapped it allowed MCM to display all the special characters used by the APL language. You can see a scan of the SelfScan data sheet here (PDF). That sheet references a smaller model of 111 columns but the rest are the same.
  

  In terms of interfacing, it is both:

  • Simple: Only nine signals: Clock, Reset and 7 data lines.
  • Fussy: Needs +250 volts, the clock is asymmetrical with specified high and low times, data has to be provided at precise intervals, you have to make sure you let go of the data lines during reset and for the first 15uS of each clock pulse, and you must be able to drive the data input pullups down to no more than 300 milliVolts.

  And you have to implement this memory mapped device with a CPU that has no idea what DMA is.
  

  The Interface Design

  The schematic for the Rack8 SelfScan interface is here (PDF), while the logic for the 22V10 GAL is here. Looking at the schematic now it seems all very obvious. When I started working on the design it wasn't the least bit obvious. There were many iterations of trial and error, mostly error, before I arrived at the current, working, version. Fortunately most of the error was on paper - oops wrong edge, oops that's a clock too soon, oops the signal we need is now gone, oops that output needs to be clocked, oops we have no output to clear that flip-flop etc. etc. etc. Possibly because I am more of a software than hardware guy. But eventually I came up with the current design. Even then there was some debugging to be done at which time my old Bitscope was a life saver. I'll have to do a post on the Bitscope. The thing is at once tremendously useful but also tremendously frustrating. 
  

  Here be a photo of the working SelfScan interface:

  Counterclockwise from bottom right: the 22V10 GAL, the 74HC4040 Sync Counter, the two 74HC163 counters that generate the low 8 bits of the memory addres, the 74HC74 flip-flops, the 74HC573 data latch and finally the seven MOSFET transistors. Only six chips and a handful of transistors but it was a tricky design.

  How it Works

  Let's start with U19, the Sync Counter. It is a 74HC4040 12-bit ripple counter although in this application only the low 6 bits are used. It is clocked by the SYNC pulse from the CPU which is chugging along at 400KHz or 2.5uS per cycle. The clock is negative true so we use SYNC.H as the clock.
  

  This Sync Counter is used as a time base to make sure that things happen when they are supposed to. In particular, to keep the SelfScan happy we need to:

  • Clock it with a signal which is high for 115uS and low for 25uS.
  • Issue a negative-true Reset pulse which is True for one clock period.
  • After the Reset pulse is over, present data on the data inputs which have pullups and must be driven open-collector or open-drain.
  • The data inputs must be left to float high during the entire reset pulse and for the first 15uS of each clock period.

  So the low 6 bits of the Sync Counter are fed to the GAL. When the Sync Counter gets to 56 it is reset by the GAL. 56 x 2.5uS = 140uS which gives us the correct period for the SelfScan Clock.

  For the first 10 counts, aka 25uS, the GAL makes the clock to the SelfScan low, for the rest...

  Read more »

• Real Memory

  camfarnell • 03/22/2023 at 15:01 • 0 comments

  Here is a photo of the working Real Memory:
  

  Foreground right the 64Kx8 EEPROM. Above that the two 64Kx4 RAM chips (the upper one partially obscured by the wires). Above that the four switches which are standing in for the memory mode flip-flops. And above that, the 16V8 GAL. On the left are the six multiplexer chips.

  On to the design
  

  With the keyboard PCB in hand, if not yet assembled, it was time to move on to Real Memory. But first we need to talk a bit about the memory layout of the MCM/70 production machine, the memory layout of the original MCM rack machine, and about the proposed memory layout for my Rack8 machine.

  The address space in the production MCM/70 is laid out thus:

  • X'2000' - X'3FFF' - 8K RAM - the workspace for the user.
  • X'1800' - X'1FFF' - 16 ROM banks of 2K each, only one of which can be active at a time.
  • X'0000' - X'17FF' - 6K ROM of frequently used routines.

  The MCM rack machine, which was intended for program development, had a similar layout except that most of the ROM mentioned above was replaced by RAM. Only the lowest 2K - X'0000' through X'07FF' was EPROM in order to have some code when the machine was reset.

  For the Rack8 machine clearly we want to have RAM where the MCM rack machine had RAM and EPROM where the MCM rack machine had EPROM. But wait! There's more! In addition to working like the old MCM rack machine I would like the Rack8 to be able to run MCM/APL by flipping a switch. So, after a lot of cogitation we have the following design criteria:

  For the low 2K - X'0000' through X'07FF' nicknamed "LOW" - we want to be able to have:

  • A simple loader in EPROM suitable for startup in "Rack" mode, or
  • The first 2K of MCM/APL for running APL, or
  • RAM for doing development work

  For the next 6K - X'0800' through X'1FFF' "nicknamed "MID" - which includes the bank area we want to be able to have:

  • MCM/APL in EPROM, or
  • RAM for development

  And the high memory area - X'2000' - X'3FFF' nicknamed "WS" (because it is the users WorkSpace) - is always RAM.

  Then what?

  So we've got what we want figured out. Now how do we control it? The suggestion is three toggle switches and three flip-flops. The flip-flops will control who gets what in terms of EPROM and RAM, and those flip-flops will be settable by issuing an I/O command so we can change the setup dynamically. The toggle switches will control what the flip-flops get set to when the CPU is reset.

  The three flip-flops are:

  • LOWRAM.: If True the LOW memory area is RAM, otherwise it is EPROM.
  • LOWAPL: Has no effect unless LOWRAM is False. If True then LOW memory has MCM/APL in EPROM, if False then LOW memory has a simple loader in EPROM.
  • MIDAPL: If True the MID memory has MCM/APL in EPROM, if False them MID memory is RAM.

  Note that if all three switches are False then we have something very much like the old MCM rack machine: all RAM except for the low 2K which has the loader and some basic routines.
  

  But wait - there is even more! Flip-flops come in pairs and we are using three so the remaining one is burning a hole in our pocket, so to speak. And in our 64K memory we have a bunch left over. So we invent the flip-flop ALTWS. When True it selects an alternate workspace in RAM. Thus we have, in effect, two workspace banks: the regular one and the alternate one. This is not something that the original rack machine had, and I have no idea what it might be used for, but this is a fun little project so I'm putting it in for fun.

  Then how?

  So how do we implement this memory scheme? For RAM we are using two M5M5258 64Kx4 chips, and for EPROM we are using one 27C512 64Kx8 chip. For our purposes we consider these chips to consist of 32 chunks of 2K each which we allocate like this:
  

  Address	EPROM	RAM
  F800	APL Bank F	Bank F
  F000	APL Bank E	Bank E
  E800	APL Bank D	Bank D
  E000	APL Bank C	Bank C
  D800	APL Bank B	Bank B
  D000	APL Bank A	Bank A
  C800	APL Bank 9	Bank 9
  C000	APL Bank 8	Bank 8
  B800	APL Bank 7	Bank 7
  B000	APL Bank 6	Bank 6
  A800	APL Bank 5	Bank 5
  A000	APL Bank 4	Bank 4
  9800	APL Bank...

  Read more »

• The Keyboard - Part 1

  camfarnell • 03/15/2023 at 16:20 • 0 comments

  I wasn't entirely sure what I was going to do for the keyboard, but I got a lot of assistance from friendly folks along the way.
  

  The MCM/70 and the rack machine used an unencoded keyboard - the processor was connected directly to the keyboard and it figured out what key has been pressed by probing the XY matrix of the keyboard. I thought about buying a commercial keyboard and hacking as needed. Then there was the matter of the key caps. The MCM machines ran the APL language exclusively and had key caps showing all the special APL symbols.
  

  From Zbigniew I got a diagram showing the XY matrix layout of the MCM/70 keyboard, but that was just the matrix. It didn't show how the matrix was wired at the connector.

  I wanted to make my keyboard pin compatible with the MCM/70 keyboard, so the next task was to figure out that wiring. Santo Nucifora of vintagecomputer.ca has an actual MCM/70 and on his web site has many excellent photos of the MCM/70 including all the PCBs that make it up, including the keyboard. By inspection I was able to figure out about half of the connections, but of course the traces on the one side of the PCB are obscured by the keys themselves. Santo was kind enough - and a big shout-out of thanks here - to take the keyboard out of his MCM/70 and trace out the lines for me. With that in hand I had enough information to design a plug compatible replica.

  Then I came across Mike Gardi's MCM/70 Hackaday project. He has made an MCM/70 replica which looks remarkably like an actual MCM/70 while under the hood is running MCM/APL on a raspberry-pi which in turn is running Zbigniew's emulator. It's a very nice piece of work.
  

  Mike, having made replicas of several vintage personal computers, knew where to go to get a custom keyboard and custom keycaps. For the keyboard I was directed to the Unified Retro Keyboard project, the goal of which is to make available open-source designs for retro keyboards. None of the existing retro keyboards (Apple 2, OSI etc) were what I needed but I was able to load the basic retro keyboard design into Kicad, make the necessary modifications, and send it off for production. All with the patient help of Dave, last name unknown, from the Unified Retro Keyboard project. Per Mike's suggestion the actual Futaba keys were ordered from Electronic Surplus. And for the key caps Mike wanted some more and I wanted two sets, one for myself and one for future consideration, so we did a group buy which went well.
  

  The keyboard isn't assembled yet. There are a great many aspects of this project that need work, and only one person working on it. So the keyboard will have to wait until a few other things are done. Stand by for part-2. The photo below shows the keyboard PCB, a set of MCM style key caps and a two of the Futaba switches.

• Goldilocks and the Three Memories

  camfarnell • 03/12/2023 at 01:33 • 0 comments

  So, on a couple of solderless breadboards I build the CPU and support chips. Then what? Well, we need some memory to test it with but the actual memory layout that I have in mind for the final version is remarkably complex given the 16 banks which can be either EPROM or RAM, the low memory areas which can be either EPROM or RAM and the consideration that the SelfScan interface needs to be able to do what amounts to DMA on the RAM. That's memory number one, and my enthusiasm for debugging that and the CPU itself was, uh, limited.

  So let's posit a simple "proof of concept" memory that just has EPROM in the low 8K and RAM in the high 8K. That's memory number two. But for when debugging the CPU what I wanted was something Really Simple. Capital R, capital S.
  

  Therefore we invent "trivial memory". That's just a latch wired up so that whenever the CPU asks to read a byte from memory the latch gates X'C0' onto the bus. X'C0' is a NOP to the 8008. We totally ignore the address bus and we ignore any request to write. With this "memory" in place the CPU simply roars through successive memory locations executing NOPs. That's memory number three. In a sense quite useless but also painfully simple and likely to work, so that's the one I started with.

  2023-02-18 Trivial Memory working
  

  Here is a photo of the developments system with the working "trivial memory":

  Left to right:
  

  • Three electrically debounced toggle switches.
  • First breadboard panel: the 800 kHz 2-phase clock at the top. At the bottom the +5 to -9 converter. Yes, the 8008 requires +5 and -9. But on the bright side, it requires no ground connection. Seriously, there is no ground pin. Apparently it intuits ground based on +5 and -9.
  • One blank breadboard.
  • Next two breadboards: CPU and support chips. The 8008-1 CPU, very unobtrusive, is in the right hand row, second from the top.
  • Four vertical strips which carry the eight data lines.
  • Seven vertical strips which carry the 14 address lines.
  • Breadboard with the 2-chip "trivial memory"
  • At the bottom, a horizontal breadboard with the LEDs that show the address and data lines, and their corresponding drivers.

  2023-02-27 - Proof-of-concept Memory working
  

  With Trivial Memory working the next step was Simple Memory. The schematic of the Simple Memory is here (PDF) while the logic for the 16V8 GAL is here. It's about as simple as I could make it while having actual memory. A photo here of the CPU and working trivial memory:

  Now over on the right we have a mess of address and data wires. I wasn't too concerned about making these neat and tidy as this memory layout was but a way-station on the way to the real memory. Over on the right is a 64Kx8 EPROM and above that are two 64Kx4 RAM chips. And up above the data+address wires is a 16V8 GAL which supplies the logic glue between the CPU and the memory chips. These memory chips are way more than was is needed for this test, but they are also the chips that I propose to use for the final system, so good to know that they work here.
  

  ????-??-?? For-real memory
  

  I've got a preliminary design for the for-real memory, a final design will be forthcoming real-soon-now. But in the meantime I want to get the keyboard looked after - because it will take time to get the PCB produced - and I want to get the SelfScan interface designed because it has to interact with the real memory.
  

• The CPU

  camfarnell • 03/10/2023 at 02:29 • 0 comments

  This project almost didn't get off the ground at all. I've built Z80 systems from scratch, but the Z80 is a dead-easy CPU to make go. The i8008, on the other hand, is not easy at all. It is really about three quarters of a CPU with the rest up to you. It doesn't even have an address bus. What it does have is an 8-bit "everything but the kitchen sink" bus that carries address-high, address-low, control bit, and data. Then it's up to you, the hardware designer, to sort this out into a real address bus based on various status bits. I dabble in hardware but I'm fundamentally a software guy. If I had had to figure out how to make the 8008 go by myself from scratch it probably would have ended there.

  Fortunately, as I was looking at starting this project, I came across this web site where Len Bayles had, pretty much as an intellectual exercise, built a time-of-day clock based on an i8008 chip. And even better there was lots of documentation and schematics. His system had significant difference from what I wanted. He had switches so you could toggle data into memory and inspect memory - the original MCM rack machine didn't have that so I don't need it. His machine didn't have the ability to single step instructions, something I want to have. But the guts of his design, looking after all the weirdness to make the i8008 go, was enough to get me off the ground.
  

  He used 74LS whereas I want to use 74HC, and one of the chips he used is no longer available. So there was a certain amount of mutatis mutandis but it was enough of a jump start to get me going. 

  The 8008-1 requires a 2-phase 800 kHZ clock. The schematic of the current clock circuit is shown here (PDF). I will probably modify this. It's using a 6.4 MHz crystal because I couldn't find any 3.2 MHz or 1.6 MHz crystals at DigiKey. But they do have 3.2786 MHz crystals which I will probably try. I would also prefer to eliminate the one-shots. This was, of course, the very first circuit built for the project and before there was any certainty that the project would go to completion.

  The schematic for the CPU section is here (pdf). Clearly much of it is based on Len Bayles clock but with some changes. In the upper left is the circuit that mediates single stepping. The 8008 doesn't really have a single-step feature. What it does have is a READY input that slow memory (the very thought of a memory slower than this 800 kHz processor is somewhat mind boggling, but apparently such things did exist) can set False until the memory is ready, The 8008 marks time until READY is true, and there is no time limit on this. Thus we use the READY line to effect single-stepping, although this has some ramifications for the LEDs that display the address and data lines. Top, center, there is a 74HC574 which can gate one of eight possible instructions onto the data bus at reset time. In Len Bayles clock this was handled by the front panel switches. But Rack8 has no front panel switches, so this function got  moved to the CPU. The jumpers at J1 allow any of the 8 "reset" instructions to be used. Once the CPU is up and working it would always be reset-0 but during testing and debugging it is handy to be able to run up to eight different tests.
  

View all 8 project logs