Disk emulation work week ending May 4th

DISK DRIVE EMULATION DEBUGGING

Hooked up the fpga and Arduino to begin shaking out the link and protocol between them. First step was getting them seeing each others bytes, which took a short bit of time. Immediately it was clear that the SPI slave logic I leveraged from the web didn't simply swap bytes as I wished, it had some bells and whistles to allow the two sides to sent status to each other. It sent a byte of addressing (user data or status) in front of a byte of actual data, thus cutting the bit transfer rate in half. Secondly, the user can only add the next byte when the master has dropped the select line, thus every transaction is an individual byte that consumes 16 bits.

Totally wrong for my purposes. SPI allows the slave to be selected for the duration of a transaction, with the clock stopped between bytes until the master has loaded the next byte to ship over the link, however my code and protocol requires the slave select to be dropped between every byte.

I have two choices - I can hack up the code I have, look for an alternative SPI slave logic module, or write my own. Rolling my own will introduce quite a bit of testing time, yet it has no upside over leverage of existing code. The middle choice will be easiest, if I can find a better existing open source module, because I will be starting with logic that works properly. If, however, I can't locate such a module, I will have to hack apart and debug the slave logic I already have.

Fortunately, I found a slave in VHDL on OpenCore that fit the bill and have installed it in the project. The only downside is that it doesn't free up the MISO line when it is not selected; other slaves are on the same line and when they are driving the MISO line, the fpga should put it into high impedance mode, not drive it with a steady 1 or 0. This was easy to spot, because the Arduino could no longer talk to the other boards - CF card and ramboard - with the fpga jamming the MISO line.

That was easy to fix with a quick change to the fpga, setting the IO port as tristate and driving it with a 'Z' value when we are not selected by the Arduino. However, the slave module is never raising the signal to show it received a complete byte - even though it is seeing all the SPI signals. Not sure what is happening but it could be yet another analog issue.

Just to be sure, I coded my own SPI slave module, something that seemed straightforward for my very specific needs. The results were the same - pointing me at an analog examination of the signals arriving at the fpga. I have already tested that the signals are changing state inside the fpga but I never see any value but zeroes coming in and nothing valid goes back to the Arduino.

I was not seeing a good SPI clock coming out of the Arduino, which led me to look closer at how I am writing from the Arduino. I found some initializations of control registers that didn't seem necessary but I added them into my access routines. My guess is that something is turning these bits off after a prolonged period without SPI activity, but I still don't know. What I found, however, is that issuing these again ensures that the clock will be emitted when we select the fpga for a new transaction.

My use of SPI is complicated by the fact that I have just one hardware SPI unit available in the Mega 1280 board; the AVR chip itself has four SPI units but not all signals are routed from the chip out to pins on the Arduino leaving them useless. Since the SD Card shield has a software library to provide the functions of reading and writing to the card, it sets up and drives the SPI link. My use of the same link for the ramboard and fpga are a back door use of the link, something that is not considered in the design of the SD Card library.

The library for the SD Card sets the hardware SPI port data register directly with any outbound bytes and loops waiting for the completion flag in the status register - I did the same to write to the ramboard and to the fpga. I found in the spots where the library first selects its shield (setting the slave select bit to 0 for the shield), it sets the SPI control registers with the data rate and enables SPI. That meant that repeating the initialization of those bits does not cause a problem. I did the same initialization every time I set the slave select bit for the fpga to 0 but still not seeing good clocking out of the Arduino.

I had cleanup to do on my homegrown spi slave module, which I could do faster on the simulator before returning to run on real hardware, and then I could resume testing. The Arduino failure to toggle the clock or MOSI lines is a show stopper.  I will try several things but may have to start from scratch with my own SPI controlling code if I can't get this to work better.

SBC6120/FP6120 DIVERSIONS

I took a couple of short breaks to write some machine language code, toggle it in and step through the execution to get familiar with PDP-8 systems. As well, I have several virtual disk drives of OS/8 that I can boot and learn the OS and the compilers/tools. Definitely only for when I need a change of pace.Physically, I moved the CF card board to a more convenient location behind the panel and have started looking for or thinking about a cabinet to house my PDP-8 replica.

PROOF OF MY INSANITY, IF ANYONE WAS STILL IN DOUBT

A friend, Doug Martin, is thinning out his collection of computer artifacts; the IBM 029 keypunch I have bought is from his collection. Pictures when I get it moved into my garage workspace. Doug keeps his items in excellent condition but even with that, some items like the keypunch have not operated for decades. That means I have to proceed carefully to relubricate, check it out, and carefully bring up power.I expect it will take hours of time and some careful study, but that it will work just fine after the bringup.

You might think that buying a keypunch just to punch cards for a replica computer like my 1130 is insane - but it gets worse. Doug also had an "Itel word processor" that he agreed to sell, the first product that made use of the term word processor incidentally. It is built around IBM I/O Selectric typewriter technology, looking vaguely like a wider IBM 2741, the Selectric based terminal used with the earliest timesharing systems on IBM mainframes. I bought it, because it is closer still to the console printer of the 1130 than the Memory 50 unit I am currently using, which I converted to replace the Electronic Typewriter 50 that I first interfaced. Slivers of additional realism and fidelity, but a ton of work to get these working and then interfaced to the 1130.

Cover of the terminal

The left and right side of the terminal has a paper tape reader and punch, used to store and retrieve documents. Inside the terminal they packed about a dozen circuit boards, allowing this to operate independently as well as being linked to other terminals and devices for larger installation. It has one flaw - the bar with a few small rollers across it, that holds a sheet of paper down onto the platen, has snapped at one end. While I have several Selectric type machines with perfectly good bars, their shape is different than the part used with this terminal. I will need to repair the bar rather than replace it, I suspect.

It is based on the IBM I/O Selectric, the heavy duty version used as the console of the IBM 1130, the 1052 consoles of S/360 mainframes, and a number of specialized terminal used by airlines and financial services firms. However, it is not a stock I/O Selectric. Some modifications are very understandable - they arranged pulleys and gears on the two sides so that the motor driving the Selectric mechanism could also spin the paper tape reader and punch units. However, they chose to replace quite a few switches that are core to the I/O Selectric, substituting reed switches for the multiple layer arms and contacts that IBM uses.

Underside with key decoding reed switches on left, seven typeball solenoids in center

The solenoids hidden under plate drive carrier return, tab and other actions, with status sensed by switches at bottom

I can rationalize this as a good change to reduce the service requirements of the terminal - mechanical contact switches are more likely to drift out of adjustment or need service than magnetically switched reeds. Unfortunately, it means I can't simply wire this into the IBM 1130 logic that was designed to control an I/O Selectric. The I/O Selectric only has switches and solenoids, no logic, but this terminal I bought probably will need some logic to yield the correct results. Until I can hand-cycle the mechanism and check the switch opening and closing points, I won't know if it is an easy interface or not.

I began building up the wiring diagram for this, also reformed the electrolytic capacitors for the logic power supply. The huge transformer delivers 10+ and 26+ VAC to rectifiers, hooked to large filter capacitors and then through a regulator board. Assuming one side becomes 5VDC for logic, the other must be used for the solenoids on the typewriter.

I can use the solenoid driving power, and there is always room for more quality 5VDC inside the project, so I kept on cleaning this up. If I use the unit as a 2741 terminal, it can definitely benefit from the standalone capability that this power will provide. I have good filtered 5.3VDC and 28V DC with only a couple of millivolts of high frequency noise.

The ribbon mechanism had some corrosion, but I had a replacement for all the parts. Two ebay auctions last year had piles of parts for memory, electronic and other Selectric type machines and I got them for a very modest amount. The carrier is stuck to the left seemingly in CR or backspace mode, which may be dried grease although I gave the machine one round of cleaning already.

The unit is correspondence mode, not BCD mode, which has some implications for the keyboard, the typeball and even the use of low versus normal velocity to strike certain characters. This may not work out for the APL typeball or the system console.

I may just build this as a IBM 2741 terminal replica, using it with APL/1130 or other systems but as a secondary terminal not the main console. That assumes I can configure APL/1130 to use one mode for the console printer and another for this terminal. More investigation will be needed.

. As you can tell, this buy was driven more by the availability of the mechanism than by a concrete need. More on this later, but first I need to finish up the disk drive, card reader and line printer testing.