Collecting data to debug IOB6120, testing of flash chip load process, rubber sleeve complete for IBM 1130 Expander box

DEBUG INFORMATION FOR IOB6120

The SBC6120 computer illuminates three LEDs to give a POST (Power On Self Test) code that indicates where it might have stopped and from that the cause of any problems. With the IOB6120 (IOB) plugged in, it stops with code 3 showing. The manuals for the computer list that as reserved for future use, but after I dug through the firmware of the system I discovered what this phase is attempting.

The firmware reads from a high memory address that is mapped to the flash ROM on the IOB board. If the firmware sees a specific header value and verifies the checksum of the remaining contents matches the expected value, it then activates the hooks that put the IOB into the system. 

Since it is stuck in that phase, I am assuming that the memory access is stalling somehow. It gives me something to look for as soon as I have the logic analyzer connected - memory address matching the value from the firmware and no contention from other parts of the IOB. 

CONNECTIONS FOR LOGIC ANALYZER REMAIN ELUSIVE

The length of signal travel between the FP6120 front panel and the IOB can't be very long. The original testing of the IOB was apparently directly connected to the SBC6120 without the front panel. This further shortens signal lines such that I might have a timing issue with any sort of access to the expansion slot signals. 

What I need does not seem to be manufactured. I need an IDC 50 pin (25 x 2) female socket with long leads, such as those used with a wire wrap system, so that I can use this as an extender between the IOB male pins and the front panel female socket, but have room to hang logic analyzer clips between the boards. 

POTENTIAL DESIGN ISSUE FOR THE IOB6120 WHEN HOOKED TO THE FRONT PANEL

On some online post about the IOB6120 there is a mention of an issue using the IOB with the front panel, such that modifications were made to the IOB to fix the issue. These are not documented. The post states that anyone with a board having the 74ACT345 chip, matching the design, needs to contact the designer of the IOB for advice on modifications. Boards with a different version of the 345 chip are okay. 

I of course contacted the designer through is web site but have heard nothing at all back from him. Perhaps I will be discovering the issue myself with the debugging I intend to accomplish and thus can develop my own parallel correction to fix the problem.

I thought I might just plug the IOB and SBC6120 boards directly together as a way of testing this theory. If the system completes power up and doesn't hang at POST code 3, then my board is good but the design itself needs a fix. If the same failure occurs, then the problem is defnitely on my board. 

TESTING FLASH CHIP LOAD APPARATUS BUT LOAD STILL NOT WORKING PROPERLY

I tried some alternate methods of programming (writing) and reading the flash memory, but rather than making things better, they got worse. I am concerned that I don't understand why the issues are happening, thus it would require dumb luck to get everything working properly. 

I was seeing the first byte duplicated as the second byte, with all the data shifted downward one position. I wasn't sure if this was a reading defect or a defect while writing. I put in the code to detect the rising edge of the RD/BY# signal but ran into the logic stalling partway through writing a block of 256 bytes. I went back to simply verifying that the ready signal is high before issuing a new command. 

I added some delays of 50 to 100 microseconds, enormous by the standards of the chip I am controlling. The read appeared to work better, with the duplicated data going away. I extended this to the writing process, but then saw that the second half of the block of 256 was untouched at xFF and a few bytes in the first 128 were bad as well. Increasing the delays increased the failure rate, with delays on the order of milliseconds giving me only one byte properly written.

I will pore over the data sheet, look at other manufacturers sheets for the same 29F400 technology, and hopefully figure out the issue. That, plus more experimentation. 

RUBBER SLEEVE GLUEDOWN COMPLETE

I completed gluing down all the flaps of the heavy rubber sleeve today. I will do some trimming of the rubber on the outside then assemble the connector onto the chassis. When that is done I can move forward with the checkout of my expander box for the IBM 1130 system. 

Wiring the logic analyzer to IOB6120, working on flashing the rom chip for IOB6120

 LOGIC ANALYZER CONNECTION TO IOB6120  MORE TWISTS AND TURNS

A clock is needed by the logic analyzer to know when to sample various signals, but the 50 pin expansion connector to the IOB6120 does NOT carry any clocking signals. The designer of that board depended on a much faster local FPGA clock to let him sample and detect the signals on the connector. I could do that and waste a lot of the limited memory space in my logic analyzer, but instead tied to the 5MHz clock on the SBC6120 CPU itself since that generates all the signals of note.

The FPGA runs at a bit over 29MHz, so I saved space in about a 6:1 ratio by finding the proper clock. It is present on pin 10 of the HD6120 microprocessor chip, which is where I snag it to wire to the logic analyzer clock input. 

MY APPARATUS TO PROGRAM FLASH CHIP STILL NOT PERFECT

With the change of the RD/BY# pin and the introduction of hardware to capture the low-hi transition of that signal, I had a setup that I believed could properly control the 29F400 flash chip to write the contents of my PC based file into the first 128000 bytes of the chip.

However, I found that it sometimes stalled partway through a block of 256 bytes - the transition wasn't detected or didn't occur, thus my code hung up. In addition, when I did a dump of the first block, I still saw the first value xE2 repeated for the first two locations, with everything else pushed 'rightwards' or 'downwards' one position. This could be a flaw in the reading or a flaw in the writing - more investigation is necessary.

I will refactor the code once again. My thinking is that I am free to issue a new command sequence as long as the RD/BY# signal is high, even if I didn't see it dip low for some interval. Thus the interrupt routines for the rising edge detection can go away. I will also carefully slow down the code that dumps one block, to make sure that I am not inducing the problem by changing address lines too close to when I read the results. 

Debugging my flash loading apparatus, gluing rubber sleeve to 1130 Expander chassis, hooking IOB6120 to logic analyzer

 DEBUGGING MY FLASH CHIP LOADING SETUP

My code to read the text file and respond to the prompts from the Arduino worked fine. The entire file can be transmitted, set up for writing and every checksum validates cleanly. However, when I write the contents to the flash I see an anomaly.

The first sector begins with a string of bytes, the first of which is xE2 but when the block of 256 is read back from flash, I see xE2 duplicated in locations 0 and 1, with the remainder offset by 1 and the final byte of the block lost.

My suspicions are focused on the RD/BY# signal and the handling of it by my Arduino sketch. This signal is an open collector output of the flash chip, requiring a weak pullup on the Arduino input to pull it high when not asserted low. 

I foolishly assigned this to pin 13 of the Arduino Mega, which as anyone who works with these knows is the pin that is wired to a resistor and LED on the board. Great for blinking a LED without wiring one up, but not so good as an input pin. 

I have reassigned this to pin 50, in the same port B as pin 13 but without the interference of the LED connection. I simply had to shift the bit patterns I used to make it input, turn on the pullup resistor and to read it with my sketch.

The other issue is timing. I really need to know that the pin went low and then returns to high to be sure that the automatic process, either writing (programming) a byte or erasing a sector, has completed. I suspect that I am not waiting thus barging in with a new request too early. Ideally this would be interlocked, the sketch requiring it to go low and then waiting for it to return to high.

I don't have sufficient control over timing to be sure that I am looking at the proper time for it to be low, so I will make use of the Atmel processor signal lines which trigger interrupts when the signal makes certain transitions. A bit more complicated to program but certain to catch a low to high transition. 

RUBBER SLEEVE GLUING WITH GORILLA GLUE IS WORKING WELL

I have to wait 2 hours for each glue joint to be fully set before moving on, thus there are four intervals of gluing required to get this in proper shape. Two were done this morning and the rest will get done when I return to the shop.

IOB6120 CONNECTION TO LOGIC ANALYZER

As I look at my carefully constructed line flipping cable, I seemingly have what I need to connect the logic analyzer and begin capturing status. I have a long lead header from the FP6120 where I can hook up the mirroring cable and also make connections to logic analyzer lines. 

Alas, I checked carefully and the SBC6120 does not buffer the signals going out on the connector, thus a ribbon cable introduces too much capacitive loading, signal distortion and delay to work properly. Back to the drawing board. Perhaps the best I can do is the long pin header between the sandwich of IOB6120 and FP6120. 

Gave up on finding Windows serial terminal to upload file with prompts; writing Python code to handle the job

TIRED OF DOWNLOADING PROGRAMS ONLY TO FIND THEY LACK PACING FOR FILES

I investigated more than a dozen programs, none of which offered the basic functionality I needed. I want the program to open a text file and feed lines to the serial port, but waiting for a prompt character from the far end before sending each line. 

PYTHON AND A WEE BIT OF CODING TO HANDLE THE JOB

It was a teeny bit of Python code to accomplish the task of reading all the lines of the text file and then looping, reading until we see the prompt character '>' from the Arduino then sending a line. When the input text file is exhausted we close the com port and go away. 

Investigating Arduino rig to write flash contents, completing IOB6120 probing cable

VERIFYING SIGNAL OUTPUTS OF ARDUINO MEGA USED FOR FLASH WRITING

I whipped up a sketch to assert and turn off the key control signals allowing me to verify that they worked properly on the Arduino I used. All was good with them, except for the data lines that run to the chip. I read the port directly after loading it but got back nonsensical values. 

It turns out that I failed to initialize port A as output, instead it was acting as an input so that when I wrote a 1, it turned on an internal pullup and when I wrote a zero it had no pullup, but in neither case was it driving output to the chip. A simple correction and then all was well. 

TESTING MY SKETCHES TO ERASE SECTORS, WRITE DATA AND VERIFY THE FLASH

My program to write a small bit of the flash chip now worked perfectly. When I ran the dump sketch the data coming out was exactly the 256 bytes that I wrote. Now I had to erase it again in order to program it with the proper contents from the file. I ran the eraseflash sketch and it reported all were erased to xFF. The dumpflash verified this was true. 

HUNTING FOR A TERMINAL PROGRAM OR WRITING A PYTHON SCRIPT TO LOAD FLASH

Each block of 256 bytes involves sending 32 text lines followed by a checksum line - repeated for the total of 128,000 bytes to be written. It is wholly impossible to hand type all those lines without any errors - not even considering the time it would take to accomplish this. 

The proper method is to have a terminal program that waits for a prompt character from my Arduino, such as a '>' and then sends one line of the text file. It should loop through the entire text file loading it to the sketch as fast as the Arduino completes processing each block of the file. 

Not only do I have to send all those lines, roughly 16,500 lines including checksums, but I have to do it a second time for the verification program that reads the flash and compares the contents to the file results. This underscores the need for a programmatic or application that handles the prompt and file transmission.

FINISHING THE PROBING CABLE AND HOOKING UP LOGIC ANALYZER

I moved the gear over near the logic analyzer and set up everything - the FP6120/SBC6120, the IOB6120, the power supply and the Surface Pro with the USB serial terminal program - to begin the debugging process. 

Connecting the cabling is more troublesome than I expected. Some of the connector ends are rounded on the side and won't fit into a standard 2x25 socket. Often I have two female sockets that must be connected, requiring some form of gender adapter such as a two ended male header. It is frustrating but eventually should be ready to run some debugging sessions.

AIR CONDITIONING OUT, PLUS ASR-33 WORK THIS WEEKEND WILL DISPLACE MY WORK

The air condition on the roof of the workshop gave up the ghost last week. It reaches mid to high eighties inside the shop, bearable but not pleasant. The coil sprang a leak, can't be repaired and must be replaced, thus we need to wait on the parts to arrive before the shop goes back to normal temps.

From Friday through Sunday I will switch over to work on the ASR/33 teletypes with a friend, hopefully getting them working properly so he can take them back to his place and put them to good use. 

GLUING RUBBER SLEEVE ON 1130 EXPANDER BOX OPENING - ROUND TWO

I cut some heavy rubber to fit around the opening of the chassis where the many signal wires run out to the 160 pin connector. I bought fast setting epoxy which I expected to hold it in place but the darned glue never set properly nor held the rubber in place. The flaps of the rubber are bent over 180 degrees around the metal of the chassis opening, which results in a fair amount of unbending force from the rubber. Even with clamps holding it for a week, the epoxy is not doing the job.

I switched over to Gorilla Glue, attempting the first of the four flaps this afternoon. The box claims that it requires 1-2 hours with clamps - I will leave it on overnight and evaluate tomorrow. I sure hope that works as my progress is stalled waiting on this mechanical issue to be resolved. 

Building cable to probe IOB6120, testing eBay 28F400 chip, testing Arduino flash loader device

THE CHALLENGE MONITORING SIGNALS WITH LOGIC ANALYZER

The IOB6120 board plugs onto the rear of the FP6120 front panel board using a 2x25 header plus a 2 pin connector. The male part of the header is on the bottom of the IOB6120 and the female header socket is on the back of the panel. Thus when they are plugged together the connector is hidden in the sandwich of the boards and can't be accessed.

Almost all the parts on the IOB6120 are surface mount and often with very fine pitch pins, making it almost impossible to clip probes onto pins to capture signals. The only practical way to monitor its operation is to capture the signals over the 50 pin header.

Since the male header is on the bottom of a board and plugs into a female below it, the handedness of the pins is reversed between the two headers. That is, pin 1 is in the upper left on one of the connectors and the upper right on the other connector.

This obviates using a simple cable method to probe the signals. If the chirality didn't change, I could have used an internal SCSI cable with three connectors, plugging one onto the FP6120, one onto the IOB6120, the using the third to attach lines to the logic analyzer. However, with the flip of signals, a signal on pin 1 is carried to the wrong pin of the other side. 

internal SCSI cable and breakout for logic analyzer connection

BUILDING THE CABLE

I bought some cables that allow me to cut apart and easily resolder the wires between a pair of 2x25 header connectors such that the pins flip and create true connections between the IOB6120 and FP6120. I carefully checked the new connections before installing this on the FP6120. I could then make use of the three connector internal SCSI cable to plug in the IOB6120 and attach logic analyzer leads.

Starting to flip the pins to cure the mirror image issue

Setup ready to hook to scsi cable and front panel

EBAY FLASH CHIP INSTALLED AND TESTED ON IOB BOARD

I found a seller claiming to have new unused Intel 28F400 chips for sale. They arrived a few days ago and I soldered one down on the IOB board. If it is real and works properly, then I can use the firmware of the SBC6120 to load the flash contents via the FL (flash load) command. This takes the text file on my PC and transfers it over the serial connection to the SBC6120 system.

When I first tested it, the SBC6120 hung during initialization, at the point where it issues a read to the flash chip on the IOB6120. This could be caused by defects in the board I built but more likely was a problem with the newly installed flash chip.

I pulled out the continuity tester and validated the connection between the flash chip pins and the far end of each such signal. This ensured that the solder joints are good and as well I tested for shorts to adjacent pins. I found that address pin A6 and the RD/BY# (ready, not busy) pins didn't have good connections. 

Even with that repaired, however, the startup of the SBC6120 hangs during the testing of memory, thus the board still isn't working properly. There are many things this could be including a fake flash chip, but I really can't proceed further without the logic analyzer capturing state during the startup. 

PUTTING TOGETHER MY ARDUINO SYSTEM TO LOAD 29F400 FLASH

Now that I have a pretty well tested set of Arduino sketches, at least offline on the Wokwi.com simulator, It is time to test with the actual chip. I installed the surface mount chip on an adapter whose DIP 48 pins were plugged into a breadboard. I wired up the 19 address lines, 4 control lines and 8 data lines to the Arduino Mega 2560, having flashed the first program which reads the contents of the 128K where I will store the ROM data. 

setup to load and verify flash chip outside of IOB board

I can monitor key signals with my oscilloscope to ensure proper timing and operation, thus I should be able to test the first of the three sketches to be sure I am able to talk to the chip. I chose the programming sketch, the one that accepts the text file lines over the USB serial link to the Arduino, parses them and writes the contents to flash, with a brief initial use of the verify sketch just to watch my control signals. 

More accurately, writing on a flash is called programming and all it does is set bits to 0 when its input is 0, but ignores 1 bit inputs. Thus, one has to first erase the sector, which sets all bits to xFF, after which you program it to flip the desired bits to 0 and leave the others at 1.

The verify sketch will set up the control lines appropriately and then assert addresses to the flash chip, let them stabilize, then lower CE# followed by OE#. That is held at least 35 ns. It enables the chip and turns the data lines to output. Sometime during the 35 ns the contents of the byte on the chip should appear on the data lines, get captured by my Arduino sketch, after which I drop the two control signals. 

The result, for a factory fresh chip, should be all 1 contents since the sectors are initially erased out of the box. The best I can do to check the chip and my setup is to run this to read out a word of flash which should show up as xFF. If the signals look correct, the minimum times for signal assertion are obeyed and the output looks good, I can move on to program some contents.

I will switch to the programming sketch, write a bit of the file to the flash chip and verify that ti seems to respond properly. Each write is a sequence of four cycles where I assert CE# and WE# sending specific patterns as well as the byte address and data to be written. At the end of the four cycles, the chiip should take some time to accomplish the write, signaling successful completion by raising the RD/BY# output signal. 

TESTING THE ARDUINO LOADER AND FLASH CHIP

When I hooked everything up and ran the first sketch to read byte 0, or any byte, I got xFF which is plausible. However, I then ran the code to program the chip, which seemingly worked correctly as the RD signal was asserted saying the write was complete, but the attempt to read returned the same xFF contents. 

I hooked up my oscilloscope as a first cut at diagnosis. I watched the RD/BY# line from the chip and tried to trigger on it going low - which is what should happen when the write is underway - but it never dropped. I then moved the probes over to the control signals to the chip to observe the waveforms and timing. I expected to see OE# stay high but CE# drop to low for a while with WE# dipping low inside that interval. I found that WE# was low at all times, which is not correct. 

My sketch should drop it for a short period, otherwise it would be high. I disconnected the wir from the flash chip to see what the Arduino is outputting but that still was low. This doesn't make sense. I verified that an Arduino would keep that pin high except for the dip during a write, which isn't happening here.

I need to dig deeper into this result to understand what is happening. If it is low all the time, it will definitely keep the chip from receiving the programming command (write) and should keep it from being read as well since OE and WE should never be asserted at the same time. I suppose I could even have a broken Arduino Mega 2560 board. 

Testing code to load the flash chip without having an Arduino handy

WOKWI.COM ARDUINO SIMULATOR TO THE RESCUE

I don't have any Arduinos at home and, due to family visiting, am not going over to the workshop. I initially thought the best I could do was to desk check my programs, leaving actual execution until the guests have departed.

Fortunately, I discovered the Wokwi effort, an Arduino simulator, which lets me load my sketch (program) and execute it, sending text over the Serial Monitor provided by the simulator. I was able to add in plenty of diagnostic outputs, validate the results, and improve the code quality.

I was even able to wire up some virtual LEDs and slide switches so that I could see signals being asserted and change inputs. The actual chip control signals CE# and WE# are off only on the order of 30 microseconds per access of the chip, essentially they stay lit to the human eye. On the other hand, I could validate the OE# signal when the program switches to read mode for verification of the data we just wrote.

USED MY SPARE TIME AT HOME TO TEST EXHAUSTIVELY

I took advantage of the simulator to verify the operation of the program in depth, assuring me that the edge cases work properly and all the validation ensures that only properly formatted data is accepted over the USB serial link. 

The file provided with the IOB6120 to load the flash ROM does not have a specific delimiter at the end of the file, it just runs out of data, the read times out and the load command is considered complete. I decided I wanted to tailor my program with a more definitive termination, so I went to the last block of data, converted the octal block number to a 19 bit chip address and coded the outer loop to end when we finish that block.

I sent data lines with the next to last block number, which did not terminate the load portion of the program. When I sent data lines with the last block number, the code worked properly, exiting the loop after writing that block to flash.

The checksum verification for each block is just the summation of all the data bytes in the block, trimmed to the low 12 bits. I sent data lines with various values for the bytes and assured that the checksum had to match to successfully accept the block for writing. 

All the numbers must be valid octal digits, only characters '0' through '7' are acceptable. The line has mandatory spaces between the address and between each three character byte value, which I check. Too, the address has a decimal point between the block number of four octal digits and the relative byte start value of three octal digits. The end of the address is terminated by a '/' character. 

Code written to write a PC file to the flash chip for the IOB6120 board

FLASH CONTENTS IN PC FILE IN OCTAL WITH CHECKSUMS

The data to be loaded into the flash chip is in a text file in a specific format designed for the SBC6120. The data is written in octal, three characters per byte, with spaces separating them. Eight bytes of data are on each line, started with an address in octal and terminated by a line end. 

The addresses are of the form xxxx.yyy/ where the xxxx identifies which block of 256 bytes where the data belongs, and the yyy representing the relative address within that block of 256. The xxxx part of the address happens to advance sequentially in the data file I was given. The yyy value runs from 000 to 370 since the last line is for bytes 248 to 255 of the block. 

After each eight lines (one block of 256 bytes) we have a line with a four digit octal number that is the checksum of the preceding 256 bytes. Each byte is added to a running counter that is one PDP-8 word long (12 bits), rolling over as necessary, to form the checksum. 

0000.340/ 074 004 211 306 002 005 143 221 

0000.350/ 003 074 006 012 326 000 377 042 

0000.360/ 300 244 257 325 277 256 205 376 

0000.370/ 274 201 036 174 375 014 162 326 

1363

0001.000/ 014 056 374 373 040 014 372 047 

CODE WRITTEN TO READ THE FILE, CONVERT TO HEX AND VERIFY CHECKSUMS

The file will be read on the PC by the terminal program (PuTTY) and sent over line by line to the program running on the Arduino. In the Arduino sketch I will convert the text into a hex address and hex bytes. The hex bytes are added together in a long integer and then trimmed to 12 bits to verify against the checksum sent on the 9th line of each block in the file.

CODE WRITTEN TO WRITE THE CONTENTS OF THE FILE TO THE FLASH CHIP

The basics of writing to the flash chip involves quite a few steps:

• set up the address field as x00AAA and the data field as xAA
• turning on CE#
• waiting a few microseconds
• turning on WE#
• Hold that state for 35 microseconds
• WE# is turned off
• waiting a few microseconds
• turn off CE#
• wait 35 microseconds
• set up the address field as x00555 and the data field as x55
• turning on CE#
• waiting a few microseconds
• turning on WE#
• Hold that state for 35 microseconds
• WE# is turned off
• waiting a few microseconds
• turn off CE#
• wait 35 microseconds
• set up the address field as x00AAA and the data field as xA0
• turning on CE#
• waiting a few microseconds
• turning on WE#
• Hold that state for 35 microseconds
• WE# is turned off
• waiting a few microseconds
• turn off CE#
• wait 35 microseconds
• setting up the address field for each byte
• setting up the data field
• turning on CE#
• waiting a few microseconds
• turning on WE#
• Hold that state for 35 microseconds
• WE# is turned off
• waiting a few microseconds
• turn off CE#
• wait until the RD/BY# signal goes high before looping again

We loop over the eight bytes of a line coming in over the USB link, first establishing the address field for the new line and then incrementing it as we write each of the eight bytes. The running checksum is updated for each write. When we have reached the end of a block of 256, the next line is going to be a checksum not a data line. We read it, convert to hex, and compare it to the low order 12 bits of our calculated checksum. Assuming it matches, we zero out the running checksum and prepare for the next line from the file.

CODE WRITTEN TO READ BACK AND VERIFY FLASH CONTENTS

To read the contents and verify it, we again send the text file via PuTTY over the USB link. For each data line, convert the address to hex and convert the eight bytes to hex. We won't bother doing checksums just a byte by byte comparison. For this task, WE# remains off.

Each data line has us do the following in a loop:

• set up the address
• turn on CE#
• wait a few microseconds
• turn on OE#
• wait 50 microseconds
• compare the data returned to the byte from the file
• flag errors if they don't match
• drop CE# and OE#
• wait 35 microseconds
• increment the address if still in the loop

For the checksum lines (each ninth line), just ignore the contents and go back to read the next line. When we reach the end of the file and haven't flagged any errors, we have a verified load.

CODE WRITTEN TO ERASE THE SECTORS WHERE OUR CONTENTS WILL BE WRITTEN

The way that flash memory works is a bit odd. The act of writing is actually called programming and all it will do is flip any bit to 0 if the data bit being written is 0, but it does NOT flip bits to 1. Thus, one has to erase the entire sector before writing into it. The act of erasing sets all bits on in the sector - every byte is xFF. 

This chip looks at address lines A17 to A12 as a sector number, not as an address of a byte in the array. There is a command sequence to start a sector erase which sets up the sector number in those address bits at the appropriate cycle of the command sequence. This will run autonomously in the chip, writing the xFF and verifying the correct state, until the entire sector is complete at which time the RD/BY# line goes high to signal completion. 

Our process of erasing a sector is:

• set up the address field as x00AAA and the data field as xAA
• turning on CE#
• waiting a few microseconds
• turning on WE#
• Hold that state for 35 microseconds
• WE# is turned off
• waiting a few microseconds
• turn off CE#
• wait 35 microseconds
• set up the address field as x00555 and the data field as x55
• turning on CE#
• waiting a few microseconds
• turning on WE#
• Hold that state for 35 microseconds
• WE# is turned off
• waiting a few microseconds
• turn off CE#
• wait 35 microseconds
• set up the address field as x00AAA and the data field as x80
• turning on CE#
• waiting a few microseconds
• turning on WE#
• Hold that state for 35 microseconds
• WE# is turned off
• waiting a few microseconds
• turn off CE#
• wait 35 microseconds
• set up the address field as x00AAA and the data field as xAA
• turning on CE#
• waiting a few microseconds
• turning on WE#
• Hold that state for 35 microseconds
• WE# is turned off
• waiting a few microseconds
• turn off CE#
• wait 35 microseconds
• set up the address field as x00555 and the data field as x55
• turning on CE#
• waiting a few microseconds
• turning on WE#
• Hold that state for 35 microseconds
• WE# is turned off
• waiting a few microseconds
• turn off CE#
• wait 35 microseconds
• setting up the address field bits A17 to A12 for each sector
• setting up the data field to x30
• turning on CE#
• waiting a few microseconds
• turning on WE#
• Hold that state for 35 microseconds
• WE# is turned off
• waiting a few microseconds
• turn off CE#
• wait until the RD/BY# signal goes high before looping again

We need five sectors to hold the 128KB of contents going into the flash.

29F400 Chip installed on the DIP-48 adapter board, planning out the breadboard and arduino setup to write data to the chip

ADAPTER BOARD ARRIVED AND CHIP MOUNTED

I bought a board where I can solder down the surface mount flash chip, TSSOP-48 layout, which then has pins soldered to the back side to create a DIP-48 that can be inserted into a breadboard. I assembled everything and now have it inserted into a breadboard.

Surface mount flash chip now hooked to breadboard

Once the chip is programmed with the data for the IOB6120 board, I can use the hot air tool to remove it, then mount it into place on its permanent position. 

PLAN TO WIRE ADAPTER TO ARDUINO

I can load all the data onto the flash chip by using an Arduino Mega 2560 to drive the 19 address pins, 8 data pins, 2 control pins and read the ready status pin. That only requires 30 pins connected to the microcontroller. There are some other control signals on the flash chip which I can permanently wire to the appropriate logic level, because they don't need to change for the purposes of the file load.

Arduino Mega 2560 to drive the flash chip

DESIGNING ARDUINO CODE TO LOAD THE CHIP

I will be doing direct port manipulation for speed and to switch pins nearly simultaneously. The AT MEGA 2560 processor has a number of byte sized registers which directly control input-output pins. For example, the L port register drives pins 42 to 49 on the board. 

The direction of each port is set by writing to the directional  register for the port. In this case, writing B11111111 to DDRL will set all eight of the pins to output mode. The high or low state of that output is controlled by writing to the PORTL register. Thus, writing B00100000 will turn on pin44 (PL5) and turn off the other seven pins. 

If the pin is an input, it is read by accessing PINL to get the values of the eight pins for the L register. As a subtlety, if you set a pin to input (DDRL for PL7 is set to 0 for input direction), then set the PORTL for PL7 to a 1, it turns on a pullup resistor. I need this because the flash chip RD/BY# signal is an open collector output that needs a pullup to work. 

I have address pins A17 to A10 assigned to the C port, with A17 on PC7 and A10 on PC0. I continue with address bits A9 to A0 assigned to the L port, with A9 on PL7 and A2 on PL0. Finally, address bits A1, A0 and A(-1) are on port B, A1 is PB2, A0 is PB1 and A(-1) is PB0. 

To write an address of x00555 in byte mode, I would set port C to B00000001, port L to B01010101 and port B low end to B010. Which is x00AAA if you string all 19 bits together, just to be confusing. 

To write the data value xAA I would simply write B10101010 to port A which is the port which is assigned to data signals Q7 to Q0 on PA7 to PA0. 

Telling the flash chip that we are sending a command is done by first dropping CE# to 0, soon after dropping WE# to 0, leaving both down for a minimum of 35ns, then raising first WE# and then CE# to 1. This is done by doing an OR of B00100000 and PORTB to PORTB, then an OR of B00010000 and PORTB to PORTB, waiting in a loop, then doing an AND of B11101111 then B11011111 with PORTB to flip off the bits. 

EXPECTED TIMING OF OPERATIONS

The sector erase can take up to 8 seconds of real time to complete, per sector. A write of one byte to the flash can take as much as 300 microseconds. These are in addition to the times it takes to issue the sequence of writes to issue the command to erase or write. Each kilobyte is going to take around a third of a second to write and our file to load is around 128KB in size, thus the loading time is expected to be less than a minute. 

Add another minute or so to erase all the sectors and this is going to be limited mainly by the timing of sending the data file from the PC over USB to the Arduino. All in all, not a very long procedure once I have it working. 

Programming requirements for 29F400 flash memory chip

ERASING SECTORS USES SECTOR NUMBERS, NOT BYTE/WORD ADDRESSES

The Sector Erase commands use the high bits of the address, bits A17 down to A12, to specify a sector number. For the larger blocks, those that span 16K, 32K or 64K bytes, the low order bits don't matter. The first block is just 8K, so its sector number in binary is B000000 but the second block, spanning 16KB, responds to either B000010 or B000011, the third responds to B000100 or B000101, and so forth. 

The command sequence sets up the sector number in bits 17 to 12, all others are ignored when the command is executed. For the data I need to load, we will only use five sectors, thus I will issue this just five times using the addresses B000000, B000010, B000011, B000100, and B001000.  After this is complete, the contents of the first 128KB of the flash memory are all set to xFF. 

CHIP AND SECTOR PROTECTION POSSIBILITIES

The chip offers ways to protect sectors or the entire chip so that you can't inadvertently update or erase the contents. There are commands to protect the chip and sequences to remove the protection, but that also requires +12V be applied to the RESET# line which isn't available on the IOB PCB; if the chip is ever protected it cannot be released while on the board. There are protections per sector that can be applied, removed and tested. Fortunately, the chip comes with the protections off and I will leave them that way. 

NAVIGATING OCTAL, HEX, WORD AND BYTE ADDRESSES

In planning and execution of the flash loading project, I will have to deal with some complications related to multiple ways to refer to the same value. The PDP-8 is a 12 bit word machine and the general practice is to represent numbers in base 8 (octal), groups of 3 bits each. On the other hand, the flash memory documentation and the usual practice with the majority of computers is to use groups of four bits to represent values in hexadecimal, base 16. 

Even if we deal exclusively in hex, there is still some duality because the flash chip is inherently a word oriented design, words being 16 bits, but it has a byte mode. The addressing for locations in the chip is done with 18 bits, the most significant being A17 and the least is A0. If only address bit A3 is a 1, this is address x00008 or decimal 8. 

If in byte mode, there is an additional address bit A(-1) that is actually selecting which half of the 16 bit word is being selected. That means that in byte mode, the same word that was x00008 in regular mode is address x00010 in byte mode. This matters because there are times when we are required to set up address x00555 while in word mode, but address x00AAA in byte mode. This is the same location, but in byte mode we are adding in A(-1) to the right side of the address. 

WAKEUP SEQUENCES NEEDED BEFORE COMMANDS TO THE CHIP

For some reason, the controller inside the chip that handles the commands needs to see a special sequence of addresses and data values in order to wake up and accept the actual commands. The first cycle, you have to send address x00AAA and data of xAA (address x00555 on the A17-A0 lines and then a 0 on the A(-1) line. Second cycle gets x00555 and data of x55. For the sector erase command, it also needs the same two cycle sequence after the second command and before the actual sector number is sent. 

INTERROGATING STATUS OF THE OPERATIONS

The data bits from the chip are used to output status during and after these command operations. There is one output signal RD/BY# that goes off when the chip is busy and doesn't go on until the command completes. Too, you can look at the data bits for more information. The particular meaning depends on the command being executed.

COMMAND SEQUENCE TO ERASE A SECTOR

It takes six cycles to send the command sequence, after which you have to keep waiting until the RD/BY# signal goes active when the erase is complete. Here is what is sent on the address and data lines:

    ADDRESS                        DATA

    x00AAA                            xAA

    x00555                               x55

    x00AAA                            x80     (erase sector command)

    x00AAA                            xAA

    x00555                                x55

    sector address A17-A12    x30

COMMAND SEQUENCE TO WRITE A BYTE

It takes four cycles to request that the chip update a byte, after which you have to wait for RD/BY# to go active to signal that the change is complete.

    ADDRESS                        DATA

    x00AAA                            xAA

    x00555                               x55

    x00AAA                            xA0        (write a byte command)

    address of byte                   byte value

Will install a 29F400 flash chip on a breakout board and attempt to program it with an Arduino Mega 2560

29F400 FLASH CHIP VERSUS ORIGINAL DESIGN PART

The IOB6120 was designed around a 28F400 chip, which is a 4Mbit flash chip that can operate in either byte or 16 bit word mode. These chips are extremely rare and can only be sourced from somewhat suspect sites or eBay, but the 29F400 is pin compatible and almost functionally compatible. 

The differences are only in the sequences to erase or write, while reading contents operates exactly the same between the two chips. This means that if I can write the contents to the flash chip, it can then be soldered onto the IOB board and will support its normal operation. What will NOT work is writing to the flash, using the FL (flash load) command since that is designed around the 28F400 protocols. 

USING BREAKOUT BOARD TO DEAL WITH SURFACE MOUNT FLASH CHIP

To write to the chip while it is off the IOB board would normally require a PCB with TSOP-48 pads since this is a surface mount device. I want to avoid the delay of designing and sending a board out to be fabbed simply to load the flash contents. I therefore found a breakout/adapter board which has the TSOP-48 pads on the top and is set up as a DIP-48 on the bottom, suitable to install into a breadboard. 

I can use a breadboard, with this setup, to provide the signals and voltages to the chip, get it programmed and then, using the hot air tool, remove it from the breakout board. The removed chip can be soldered onto the IOB6120 board and it should then work perfectly. 

PROGRAMMING THE FLASH CHIP IS A SEQUENCE OF BLOCK ERASE AND WRITES

In a flash chip, you have to do an erase of an entire block, setting the contents to xFF, then write to each location in the block in order to load your data. One challenge when switching between flash chips is varying block sizes. The 29F00 has a 16K block, two 8K blocks, a 32K block, then the rest in ascending addresses are all 64KB. The 28F00 has the first eight blocks 8K bytes in size, with the remainder in ascending order all 64KB. 

Thus, if you programmed for the 28F400, you would erase the block at address zero, thinking it would erase the bottom 8K, write those bytes, then erase the block starting at address 8K, write the next set of bytes, and so forth. If you did this to the 29F400, after writing the first 8K, when you issued a block erase for address 8K you would wipe out the entire first 16K, including the words you had just finished writing. 

Thus the programming difference for writing to the chips has to take into account the block structure and decide when it has to issue block erase commands to the flash. The FL command, as written, will only work with the block structure of the 28F400 chip and will not give proper data loading on the alternate chip. 

The solutions include rewriting the FL command and rebuilding the ROMs for the SBC6120 computer, but also there is a minimally invasive method where the chip is written outboard, prior to soldering onto the IOB PCB. 

SETTING UP MEGA 2560 TO CONTROL ADDRESS, DATA AND CONTROL LINES

The Arduino Mega has 51 digital pins, sufficient to drive the 8 data lines, 5 control lines and 19 address lines for programming this chip. The programming sequences dictated the order in which signals are set, the minimum time they must be stable, and the timing between control signals. Knowing the speed of execution of the Mega processor I can ensure that delays, hold times and the like are satisfied. 

ALMOST EVERYTHING IS READY EXCEPT THE BREAKOUT/ADAPTER BOARD

I have the 29F400 chips in hand and the Arduino Mega 2560. This, however, depends on the TSOP-48 to DIP 48 Breakout/Adapter part that has not arrived yet. With my visitors coming I expect to have the adapter board but not be able to work further on the project for a number of days. 

Repaired 160 pin connector for 1130 extender, adding cable wiring protection

AMPHENOL TOOL ARRIVED TO REMOVE THE SOCKETS IN THE CONNECTOR

Because I had two wires tear out of the socket crimping on the 160 pin signal Storage Access Channel (SAC) connector, I had bought new sockets and the special tool that removes the pins and sockets. It has a hollow cylinder that fits between the plastic hole in the connector and the body of the socket or pin. 

Amphenol tool

When pushed onto the socket, it displaces some lock tabs on the outside of the socket that lock it into the plastic connector. An inner piston pushes the socket out of the back of the connector once the lock tabs are freed. 

I used the tool to remove the sockets in positions A1 and A2 of the connector, as those had no wires attached. These were thrown out and new sockets were readied to attach to the wires. 

Two broken sockets ready for disposal

NEW SOCKETS CRIMPED TO WIRES AND INSERTED IN CONNECTOR

I put the wire ends in the sockets, crimped them well with my crimping tool, then pushed them into the connector housing until their lock tabs clicked in place. The connector is now repaired and ready for use. 

Two new sockets are the leftmost positions

ADDED HEAVY RUBBER PROTECTION TO KEEP WIRING FROM CHAFING ON CASE

The many wires from the SAC connector pass through the chassis and can rub along the metal edge. This can expose conductors, enable shorts or even break the wires. I am constructing a sleeve of heavy rubber to protect the wires from the lip of the chassis. I will epoxy it into place over the coming days. I have family coming to visit which will keep me out of the shop for some time. 

Working on the rubber protective sleeve

Solder reflow plate project working, still working to hook up logic analyzer to the IOB6120

PROGRAMMING THE ATMEGA328 ON THE REFLOW PLATE

The solder reflow plate has a ICSP connect (3x2) that is used to download code to the ATMEGA microcontroller. I used a spare Arduino Uno as the programmer, hooking up the two ICSP connectors with cables. It completed successfully, after which I used my oscilloscope to verify that the crystal was oscillating at 16MHz driving the controller chip. 

SOLDERED ON THE OLED AND FIRED IT UP

I installed the temperature sensor and the OLED display board to the PCB. The only part I am still waiting for is a good main diode that protects the circuitry from a reversed 12V supply connection. I have a jumper across the diode pads for now.

The OLED lit up with appropriate output and I got it to start heating - the power supply kicked up to the 5A limit I set and the plate began to get toasty. I am satisfied with the outcome of this project, in spite of the hiccups along the way, and will move it into service in my soldering area once I install the diode. 

Reflow plate is operational

GETTING ACCESS TO THE 50 PINS OF THE SBC EXTENSION BUS

The IOB6120 (IOB) board has a 2 x 25 pin header on it that fits into a 50 pin socket on the front panel PCB. This is the extension bus from the SBC6120 (PDP-8 replica). Since most of the parts on the IOB are surface mount, it is very difficult to hook probes to the circuitry. While I have the means to attach up to four, real debugging requires many more signals to be captured.

My first cut at this was to buy a 50 pin ribbon cable, the type that was an internal SCSI cable inside PCs. I would hook the cable to the header pins on the IOB, use a special header with long pins on both sides to connect to the front panel socket, and then use another long pin header on the center socket of the cable to gain access for logic analyzer connections.

Alas, I forgot about chirality, introduced because the header on the IOB extends downward into the socket on the front panel. A cable connected to each will transpose the two columns of 25 pins, while I intend to have the columns connected as they are when the board is directly plugged into the front panel.

I will prevail over the flash memory issues with the IOB6120

 USAGE OF THE FLASH MEMORY ON THE IOB6120

The flash memory on the IOB6120 is used for two purposes, read by the SBC6120 system initialization code, plus it can be loaded by a console monitor command FL. The first part of the flash is treated as EPROM, copied by the initialization code into the panel RAM space and executed.  The second part of the flash is copied over to the FPGA as the bitstream to program it. 

The EPROM code will modify the firmware of the SBC6120 to modify the memory space, add support for various additional devices and take over some IO requests. This happens only if the beginning of the flash has a specific signature and a good checksum, otherwise it is ignored and not copied.

Note that both of those purposes are accessing the flash as static ram reads - put an address on the bus, enable the output and the corresponding data shows up on the bus. That doesn't depend on any commands or specific sequences that differ between flash memory parts. The only case where commands are issued to the flash, such as erasing blocks, writing words, reading and clearing status, is when you reload (or initially load) the flash with the EPROM code and the FPGA bitstream. 

OPENING UP THE WAR ON THE FLASH ON MULTIPLE FRONTS

I found a vendor on eBay that claims to have Intel parts compatible with the Sharp flash chip used in this design. The vendor has thousands of perfect feedback responses and is US based - not an absolute protection against counterfeits as they themselves may have been victimized - which is a drop in and forget it solution that will support the console FL command as well as reading out properly.

I also purchased a 29F400 chip from a reputable distributor, thus probably real. It has a compatible footprint and pin assignments but apparently some of the access details are different for erasing and writing. Thus, use of the FL command may require me to make changes and rebuild the SBC6120 firmware and rewrite its EPROM. 

I have several of the 16M chip that were also footprint and almost pin compatible, although they had the extra two address bits that need to be driven. If I can program that chip, or the 29F400 above, through other means then I don't need the FL command to work. Soldering in a preprogrammed flash will allow it to boot up and work properly. 

I found an adapter board, TSOP-48 to DIP 48, which will let me solder down one of the flash chips then plug it into a breadboard for me to attempt to load the flash before I put it on the IOB board. This will support any of the chips, if need be. 

Replaced parts in solder reflow plate, tested and modified flash on IOB6120

REPLACED BLOWN PARTS ON REFLOW PLATE

The replacement for the parts that were destroyed by the 12V passing through the wrong linear regulator have arrived and today I soldered most of them on. I applied power and was aghast to see the 12V passing right through. 

I looked into this and discovered that the ground plane of the PCB (or the via that connects a group of ground pads) had failed, thus there was no ground at the linear regulator pad vref that should be grounded. I added in a jumper to bridge the group of pads to a known good ground level, at which time I validated that the voltage rails are indeed 5V not the full 12V passing through. 

With that done, I await only the temperature sensor from Mouser before I can complete assembly. Tomorrow I will program the FPGA, assuming it wasn't killed by the overvoltage. Since the ground traces were partially disconnected I am hoping that the FPGA didn't get connected to ground and therefore survived the prior voltage tsunami. 

CHECKED ON VCCW PIN POWER ISSUE ON IOB6120

I tested continuity and resistance for this pin, reflowed the pin contact and carefully inspected the chip under the microscope. It all looked good, which suggests that either I have a chip failure or the problems are deeper than it appears. 

CHECKED COMMANDS AND ADDRESSING BETWEEN REPLACEMENT AND ORIGINAL

One of the tenets of my substitution of the 16M flash chip for the 4M chip on the design is that it be almost a direct drop in replacement. That is, the pin assignments (other than two additional address bits for the larger capacity) should be identical and the functions should compatible enough to work properly.

I pored over the data sheets for the two devices to identify all possible differences after which I could analyze their impact on the substitution. The command codes are identical, the sequences are identical, the differences are minor:

• Manufacturer ID is identical but the device code differs for the Read ID output
• VCCw can be given 12V to do a full chip erase faster, but usually gets 5V
• Two higher order address bits are added, A18 and A19

MODIFIED ADDRESS PIN WIRING FOR THE FLASH CHIP

I realized that since both chips have some low address blocks that are only 4K, intended for boot and parameter storage unlike the 32K word blocks in the bulk of the device, it is not correct to let the two high address bits match the value of adjacent address pins. Instead, these high order bits need to be logical zero, which means they should be tied to ground.

I found access to ground on nearby decoupling capacitor pads, removed the solder bridges I placed on these pins, and added jumpers to give those bits the proper value. This should allow the chip to work properly.

Jumpers to take A18 and A19 to ground

NEW TEST AFTER MODIFYING WIRING

With this change, the board again refuses to pass the memory test at SBC6120 initialization. Drat. I will have to move on to the logic analyzer probing to check things out. In the interim, I did discover that I can find the some new 29F400 chips, known to work on the board with small software modifications because they are quite similar to the 28F400 that was the basis of the original design.

I ordered the chip and removed what I had on the board now. With the ROM missing, the SBC initialization hangs in the memory test section just as before, so no progress will occur until I get the logic analyzer set up and the new flash chip installed.

Flash removed and waiting for the new chip

Decoded the I/O error trying to load the flash of the IOB6120

ERROR 1050 DURING ATTEMPT TO WRITE FIRST BLOCK TO FLASH

When I issued the FL command to load the flash and began feeding it lines of data through the console, at the end of the first block when it compared the checksum successfully, it then failed with an error 1050. I first looked into the source code for the FL command and discovered two things. First, codes of the form 1xxx are failures to do the block erase that occurs before the data write. Second, the three octal characters are the status byte returned. 

SHARP DOCUMENTATION SHOWS THE MEANING OF THE STATUS BYTE

I looked over the documentation on the flash chip I used and found that the error byte 050 octal means two things - block erase failed and the Vccw level was too low. This chip gets two VCC inputs, the regular +5V and a second level which if not at 5V will block any writes/changes. Think of it as the write protect tab of a floppy disk. If I take this at face value, then the failure was due to a low voltage on pin 37 (the Vccw pin). 

LIKELY CAUSES TO BE INVESTIGATED

I checked the gerber files and there is indeed a connection between the VCC pin (13) and the Vccw pin (37), involving a bottom layer trace, two vias and short top layer traces to the pads. 

• One possible failure mode is a break or bad via. 
• Another is an issue with the Vccw pin either not being firmly soldered or being shorted to an adjacent pin. 
• A third area of concern is my modification very near to that pin, where I added a pullup resistor to the continuation of the trace after +5 reaches pin 37, over to the chip enable line for flash. 
• A fourth possibility is that this is indeed a counterfeit chip, being some other similar flash with changed markings
• A fifth possibility is that the chip itself is failing.

When I bought this chip, I received four in the package thus I can deal with the last possibility easily. Some diagnosis is required, plus careful inspection and perhaps a reflow of pin 37 while I am there. 

Another possible issue for me to consider is the solder bridging I added for the two additional address pins that don't exist on the original chip for which the board is designed. Rather than taking them to logic low, I tied them to adjacent address bits. That may, however, cause odd problems so I think I will rework this to use jumpers to ground instead. For example, I see at least one of the bits is used to address 'boot and parameter blocks'. 

IOB6120 is alive and talking to the flash, debugging continues

HI-Z TESTS DON'T SPOT OBVIOUS FAKE CHIPS BUT DOES FIND SHORT ON FLASH

I checked all the data pins of the four SRAM and one flash chips, looking for pins that were near ground or VCC rather than high impedance. The SRAM chips looked fine by this measure, so I moved on to the flash. It was while I checked the data pins that I found one shorted to VCC, which was an adjacent pin. 

I looked under the microscope and really couldn't see the short, which seemed to be a bridge up under the body where I couldn't see it. However, some solder wick to the rescue and soon I had the bridge gone. 

WITH SHORT REMOVED, SBC6120 COMES UP WITH IOB6120 IN PLACE

Previously, with the IOB board installed, the SBC6120 stopped in the memory test phase of initialization. Now, it proceeded through to the end and started up the monitor program that communicates over the console terminal. This is very good news.

ISSUE FLASH LOAD COMMAND AND IT SEES THE CHIP

With the IOB not installed, issuing a FL command receives an immediate response that flash is not installed. Now, when I typed FL the response was a question - "overwrite flash?" Again a very good indication. 

At this point, one would set up the terminal program to send lines of text to the console, waiting for the prompt ':' before sending each line. I don't have a terminal program with this capability, just PuTTY and the Arduino Serial Monitor. 

MANUALLY SENDING LINES TO FLASH LOAD

I decided to do a copy and paste line by line from the text file into the PuTTY window as a workaround. I transmitted each line until I got to the end of one block, where the FL command expects to receive a checksum value which it compares to the calculated checksum of the lines previously sent. If that compares successfully, it writes the block to flash then reads text lines for the next block.

WHEN FIRST BLOCK WRITE IS ATTEMPTED, I/O ERROR 1050 IS REPORTED

As soon as I sent the checksum, the load aborted with a message that it received Input Output Error 1050. I suspect this is a compatibility issue because I am using a different flash chip than originally specified. I will do some research into this error and then figure out how to resolve it. This may involve creating my own method of writing to the flash chip or a modification to the SBC6120 firmware to alter its flash write process. 

Starting the debugging of IOB6120 add on to the SBC6120 PDP-8 replica

NEED TO USE LOGIC ANALYZER TO TRACK ACTIVITY OVER THE BUS

The SBC6120 features a 50 pin expansion connector, carried around through the front panel FP6120 to a connector where the IOB6120 is connected. A few of the pins are power and ground, but most are control signals and the main bus. I want to track these, which will require three pods on my HP logic analyzer, each offers up to 16 probes.

The next channel is mechanical - how to access the various signals. With through hole ICs like DIP chips, I can put a grabber around a chip lead, but with surface mount this is quite difficult or impossible depending upon the pin pitch.

If I can build an extender, something that plugs into the FP6120 connector, has a second end to each signal wire that plugs into the IOB6120, and allows attachment of the logic analyzer probes somewhere, that will let me do the job. I would need a female 50 pin on a cable, like an internal SCSI connector. In addition, a few male-to-male adapters which could simply be 2x25 header strips.

LIKELY CANDIDATES AND FIRST AREA TO CHECK

The likelihood is that I have one or more counterfeit chips on the board. Since they have their outputs tied together on the bus, presumably they sit in high impedance until the chip enable line is asserted. If these are not real chips, they likely won't have high impedance on those pins which will jam the bus. 

The four SRAM chips as well as the Flash memory chip are the ones I suspect the most. All other chips were sourced from Digikey or Mouser, reputable suppliers. 

QUICK CHECKS OF SUSPECT CHIPS

To check the suspect chips, I will measure the impedance of the bus lines which should all be high-Z. I can provide power to the NVRAM battery contact to power the SRAMs and again check the state of the bus lines. Pulling the chip enable low at the PCB activates the outputs; again they should only activate with contents. Finally, I can provide 5V to the board, test the bus to see if the flash is stomping on the bus, then pull the flash enable low at the PCB to check for its outputs.

PLAN B AND C IF CHIPS ARE FAKE

The obvious plan B is to attempt to buy from another eBay source and hope that the results are better this time around. If that doesn't work, I will be forced to a complex alternative wherein I will create small PCBs that match the footprint of the pads on the main PCB, then place some tinier alternative chip that will be functionally and electrically identical albeit with a different assignment of signals to pins. 

For the Flash it also requires me to modify the programming which writes the flash image, or write it myself which is the more straightforward approach. Hopefully the IOB6120 treats the flash as pure SRAM for everything except writing new ROM contents via the FL command. 

Got to the bottom of the serial port issue with SBC6120, added air vents to 1130 Expander box

 AIR VENTS DRILLED INTO THE 1130 EXPANDER BOX CASE

I added side holes to draw in fresh air and top holes above the power supply fan which will exhaust the hot air from the case. Nothing else to do until the tool for extracting and reinserting the Amphenol M series sockets arrives. 

WHIPPED UP TTL TO RS232 LEVEL SHIFTERS FROM SPARE PARTS

Since the SBC6120 makes use of the voltage levels of RS232, the line can swing as high as +12V and as low as -12V, a definite problem when attached to a TTL part that expects voltages in the range of 0 to +5. I had some old chips in my cabinets that I put on a breadboard such that I could convert the transmit output from RS232 and take a TTL receive line and drive it to RS232 levels. 

I used a SN75150 dual driver chip and an MC1489 quad receiver chip to handle the conversions. The first takes +12 and -12 supply rails, the latter uses 5V. I jumpered the SBC6120 lines to the breadboard and then jumpered the TTL side to a USB to TTL adapter I owned. I used a voltmeter and the oscilloscope to confirm the proper levels and encoding of characters.

RS-232 and TTL conversion chips wired to rails

Still, however, I saw nothing but gibberish on the Putty terminal program. I checked with the Arduino serial monitor and the output was the same. Commands keyed in didn't see to be decoded by the SBC6120 nor responded to.

Just to throw in some amusement, one of the ground connections came loose which lead me on a ten minute wild goose chase debugging things until I realized that the RS232 to TTL receiver chip wasn't working because it had nothing on the 5V rail. 

As I looked more carefully at the scope image, the timing of the bit cells looked off so I did some calculations. Aha! The SBC6120 was jumpered for 300 baud but was operating at roughly 110. That triggered a distant memory of my having modified the SBC with a different timing crystal to achieve compatibility with old teletype and typewriter equipment. 

A quick look at the oscillator chip confirmed the issue. It was operating at 1.8432 MHz while the original from the schematic was a 4.9152 MHz oscillator. That gives a ratio of .375 for the serial stream, converting the 300 baud of the design down to 112 baud. 

I changed the oscillator to create 110 baud support

I happened to look in my parts bins and found a bag with an oscillator marked "original 4.9152 crystal". How convenient. I swapped the parts out, configured the jumper for 9600 baud operation, and got clean output on Putty set to that speed. 

I found the old oscillator part!

That is more like it!

IOB6120 HANGING THE SBC6120 STARTUP

Unfortunately, when I add the IOB6120 board, the SBC6120 system hangs in the memory test at startup. I was unable to get it past that point. When I hit the ESC key at startup, the monitor didn't start so that I had no way to enter the FL command to load the flash contents. 

At this point, having checked the soldering very carefully and attempted to move every pad with a dental pick, I will have to move into debugging to figure out what is going wrong. Keep in mind that five of the chips on the board were procured through eBay and thus have a reasonable risk they are counterfeit, which could result in a hang like this if they tie down bus lines or inject spurious outputs. That is, the Flash chip and four SRAM chips are suspect. 

Checkout of IOB6120 and SBC6120 slowed by serial terminal hiccups

POST CODES AND ACTIVITY AS AN INDICATOR OF OPERATION

The SBC6120 has a set of LEDs that show the progress of startup and any problem that is encountered. The goal is to have the four LEDs end with ON-off-off-ON which occurs with the SBC6120 by itself. If the IOB6120 is added but the FPGA is left active, an illogical state since the firmware for the component was not yet loaded, gives us an error status of ON-ON-off-off which is a memory error. The IOB6120 takes part of the memory range for its function but is not responding properly to the SBC6120 given the lack of firmware. This makes sense.

JUMPER TO DISABLE FPGA ON IOB6120 PRIOR TO LOADING FLASH

Adding a jumper to a pair of pins disables the FPGA and now the system starts up to the normal ON-off-off-ON state, indicating the tests are complete and the monitor is running. The next step would be to connect with a serial port and terminal program, to communicate with the monitor on the board. This is a positive sign in the early checkout of the IOB6120 board. 

POWER CABLE INSTALLED TO FLASH CARD EMULATED IDE DISK

The SBC6120 provides an IDE disk interface, to which I have connected a board that uses a CF card to emulate a disk drive. The board needs power from the main SBC6120 board, provided using a PC four pin to mini four pin cable as typically connected to disk, floppy and CDROM drives. 

SIGNS OF LIFE PRIOR TO TERMINAL CONNECTION

With the board powered, I see it flash when I boot the PDP-8, the front panel lights loop for a bit and I take this as an indication that the OS/8 image has been started properly. Again, until I connect with a terminal program this are suggestive but not definitive indications of health.

FIRST GOTCHA FROM ILL CONSIDERED ACCEPTANCE OF MS WINDOWS 11 UPGRADE

Having been cajoled, hounded, beseeched, urged, prompted and pestered by Microsoft to upgrade my Windows 10 system to Windows 11, along with a projection that everything will work fine after an upgrade, I finally in a moment of weakness acceded to the upgrade. In my heart I knew I would pay the price, but all the programs I tried such KiCAD worked properly which lulled me into false confidence.

Alas, when I plugged in my USB to serial adapter, the device manager entry listed the driver as "upgrade to windows 11 version". I downloaded the latest Prolific driver, only to have the driver message change to "HA hardware not supported". Time to buy a replacement that is supported in Windows 11. 

MOVE TO WINDOWS 8 BASED SURFACE PRO TO ATTEMPT TERMINAL CONNECTION

In the interim, I grabbed my Surface Pro, running Windows 8, to attempt the terminal connection. I wired up the connection between the USB adapter and the DB9 connector from the SBC6120, then powered up. 

The screen output was bursts of gibberish, repeatable but not intelligible. I was not able to see valid output from the monitor. 

MAY HAVE TOASTED THE USB TO SERIAL BOARD DUE TO REAL RS232 VOLTAGES

It was then that I realized that the SBC6120 produces real RS232 - meaning voltages in the range of + and -12V - unlike the 0 and 5V used with TTL serial connections. Both make use of a DB9 with the same signal names, but I may have very well have fried the adapter by presenting it with excessive voltages as well as negative excess swings. 

I have a new adapter on order, Windows 11 capable, plus some RS232 to TTL adapter hardware. Hopefully when I have this on hand I can connect to and communicate with the SBC6120. That is essential in order to download the flash data to the IOB6120. 

Modification to SBC6120 sorted out, additional cable signals to 1130 Extender box wired up

MODIFIED HD6402 UART CHIP WITH SWITCHED CONNECTION

The Universal Asynchronous Receiver Transmitter (UART) chip has a number of pins that are used to configure the serial protocol as to the number of data bits, parity and stop bit length. The SBC6120 PCB ties these to VCC or ground as appropriate to select the default of 1-8-N with a single stop bit. 

The change was made by bending up two pins, to disconnect them from the PCB traces. They were wired to a DPDT switch which provides VCC and ground to the pins, alternately. That is, in one position, the first pin is hooked to VCC and the second connects to ground. The other position of the switch ties ground to the first pin and VCC to the second. 

PURPOSE OF THE TWO SWITCH POSITIONS

Based on the pins selected, this switch toggles between two configurations - 1-7-E-1 and 1-8-N-2. These were reasonable values for connection to the ASR-33 teletype I brought to VCF-W that year. As I no longer own a teletype, this is not needed and should be removed. 

REMOVAL OF THE MODIFICATION

I disconnected the wires that had been tacked to the lifted chip pins, then installed jumpers down to the PCB to restore the original functionality. The switch was then discarded.

REPAIR OF 160 PIN CONNECTOR MUST WAIT FOR EXTRACTOR TOOL

The two wires that came loose were at the top two positions, connector sockets A1 and A2, which are routed to FPGA connector pins D5 and D3. I made a try at soldering the wire to the end of the crimp connector as it sat in the connector housing, but it wasn't feasible to accomplish.

Left two openings are sockets A1 and A2

I therefore have to remove the two sockets that came loose, crimp the wires to new sockets, then re-insert. Because of the spring loaded tines that hold a socket in place, a special tool is needed that releases the tines and pushes the socket out of the holder. I purchased that tool plus some spare sockets but have to wait a few days to receive it before I can continue.

ADDITIONAL SIGNALS CABLE WIRED INTO THE 1130 EXTENDER BOX

I constructed an additional cable to sense and drive interrupt levels 0 and 1, for a fully generalized input-output control of the 1130 system. In addition, it carries a signal that triggers the three button press sequence for booting an 1130:

• IMM STOP
• RESET
• PROG LOAD

I brought the five wires from those signals to the screw terminals for the FPGA connector pin associated with each, as well as bonding the grounds together and hooking them to the PCB of the extender box. 

FINAL ASSEMBLY OF POWER SUPPLY INTO CASE

The power supply is installed and wired up, feeding the PCB and the Power Good lamp on the case. The extra wires out of the power supply were clipped off and covered with heat shrink tubing. At this point, once the two sockets are replaced on the 160 pin connector, I only need to drill some air vents for cool air intake and hot air exhaust before closing up the box. 

Progress on IOB6120, 1130 Extender and a few small disasters

IOB6120 ASSEMBLED AND INITIAL TEST SHOWS SBC6120 WORKING

The header strips arrived, I soldered them onto the FP6120 and IOB6120, then put the entire stack together. That is, the large front panel FP6120 has two daughter boards mounted on the rear, the SBC6120 (PDP-8 replica) and the IOB6120 for additional input-output functionality.

I provided power and watched the machine go through its power on self test with blinking lights on the panel. To go any further, I will need to hook up a terminal emulator and see the prompts from the built in monitor. That will allow me to confirm that the IOB6120 is found and eventually, once I flash the firmware onto the board, that the new board is working properly.

I last used the FP6120/SBC6120 for a Vintage Computer Festival West conference when I was showing teletypes. In order to support the teletype interfaces I was using, I had to make modifications to the SBC6120 interface chip. I added a slide switch that would reverse VCC and ground to a couple of pins on the HD6240 UART chip. I don't remember why or what this does. 

Before I proceed, I have to reverse engineer the change, then decide how I put the system back to original condition. Once done, I can try to connect the terminal emulator to the replica.

BUILT IMPROVED MOUNT FOR 160 PIN CONNECTOR FOR 1130 EXTENDER BOX

I made use of some metal standoffs and a plastic project box to hold the 160 pin connector outside of the extender box chassis, allowing room for the wires to run inside and be connected without the connector body getting in the way. I marked off and drilled the holes, cut out the rectangle to clear the connector body and assembled everything. 

New mount for the 160 pin connector

WIRED SIGNAL LINES TO THE PCB INSIDE EXTENDER BOX

I was able to route and screw down the wires from all 76 of the signals that run over the SAC feature cable to the IBM 1130 system. I will lace or add wire ties to make things a bit neater, once I verify that it all operates properly. 

Beginning the connection of all signal wires

MINOR DISASTER - TWO WIRES TORN OFF CONNECTOR REAR

I discovered that two yellow wires from the rear of the 160 pin connector had been torn loose, likely during all the manipulation to wire up and mount everything. I should be able to access the rear of the connector and hopefully make a repair without needing to buy the pin removal/mount tools for the connector. 

One of the wires that was broken off the connector

SOLDER REFLOW PLATE POWER ON TEST - DISASTROUS RESULTS

The solder reflow plate takes 12V as an input and can draw up to 5A when heating for reflow. Its logic is driven through a linear power regulator that produces 5V to feed the ATMEL ATMEGA328P microcontroller and the LMT85LP temperature sensor. 

As you may remember from previous episodes, this version of the board, recommended by the Great Scott youtube channel, came without a bill of materials. The base project that it claims to have tweaked does have a BOM, but as I discovered it is deficient in several ways. First, it points at parts number from a China supplier and not the manufacturers code or other international supplier numbering. Second, it had gross errors, such as specifying 0402 size capacitors to mount on 1206 sized pads. 

Well, when I powered the board up and began checking power supply values, I soon found that 12V was present on the rails that should have been 5V. The cause was quickly found to be a PCB layout that required a special 'reversed' pin version of a chip but the material in the BOM was for the normal layout. This resulted in routing the 12V straight through to the sensitive parts downstream.

I believe that I have fried the ATMEGA328P controller and the temperature sensor. I may have also blown the .91" OLED panel, but I will wait to see that after I get the rest of the board operating. I removed the offending version of the voltage regulator, which you may remember was also the wrong form factor for the PCB pad spacing, but have not yet removed the microcontroller because there are so many tiny parts very close to it. 

I will build a set of diverters to block the hot air from reaching the capacitors and resistors that sit next to the main chip, while still allowing me to melt the bonds and remove it. I have a few days until the replacement parts arrive before I need to remove the old one, so it can be done at my leisure. 

REORDERED PARTS THAT WOULD HAVE FAILED, PLUS PROPER POWER MODULE

I did find the correct part number for a power regulator for reversed layout and that fit the pads on the PCB. I also ordered all the other damaged parts. I should have it all towards the end of next week.