Saturday, October 30, 2021

P390 is working! Two small issues to chase down with the new Documation interface


I first made the changes from last post - switching to direct port access for the LED and PICK signals as well as collecting all eighty card columns before sending the data up the USB cable to the host computer. Once those changes were working, I began the exhaustive testing of the various machine status indications. I see that most are working properly but the ERROR state is always on even when the machine has no error conditions active. 

I don't yet know if that is coming from the Documation M600 reader, representing some failure inside that machine, or whether my connector, cabling, connections to the Arduino or other issue is responsible. Will probe the signal where it exits the M600 PCB and go from there.

I then tried to connect with Brian Knittel's cardread.exe program but it fails to connect. I can use the Arduino serial monitor or a serial terminal program like PUTTY just fine. At this point, my working hypothesis is that the error condition being reported is triggering the program's code to conclude it isn't talking to a real card reader. The error message is not clear, other than iterating on an attempt to connect and a report that the effort tailed. 

Finally, I put in some diagnostic output so that I can verify that I am reading the cards correctly. I discovered that the interface is not seeing row 9 holes. Again, that could be a flaw in the machine itself, a cabling/connection issue or something else. Probing at the machine will direct me appropriately. 


I first swapped out the CR2032 battery with the new one I bought and validated that the holder is reliably connecting it to the planar. I then brought up the system, cleaned up the configuration corruption and set the date/time properly. 

My boot up of the OS/2 instance worked - the P390 panel showed up with all the programs ready to use. I configure it for an MVS 3.8 and a VM/370 instance at different times and started up the systems. I ran far enough with those to feel comfortable with the state of my P390 system. 

Later I will make use of the Diagnostic diskette and fully check out the card, but for now my working assumption is that I survived the tipover with no lasting damage other than to sheet metal. 

Eventually, I want to enhance this system with other cards to broaden its functionality. I have a WAN card that I hope will give me an SDLC link to my 3174 controller and 3178/3179 glass terminals. I also have a 390 channel card that would give me bus and tag connectivity to real 360/370 style peripherals. Finally, I need to get my SCSI 9 track tape drive connected and working as a pretend 3420 drive. 

Debugging new Documation card reader controller, also debugging P390 system


I was able to start up an instance of OS/2 on the server, although not the version that had the P390 software installed. Still, it gives me the tools to get to the other instance where everything is set up. Before I fix this, I have to deal with lost or corrupted configuration due to expired backup batteries.

The motherboard CMOS battery is a CR 2032, a 3V coin style battery. I had replaced it but still get 'bad CMOS battery' errors and decaying information on the server CMOS configuration RAM. There are a few possibilities for this. The new battery could be bad, the contacts could be poor in the holder, or there may be damage to the planar (motherboard) and its traces due to the mechanical trauma this server suffered when it fell over during packing back in California.

I tested the battery and found it to register at 2.9V. I also bought a new battery and will substitute it into the server. While I do that, I will work on the contacts in the holder to be sure I get good connectivity. I sure hope I don't need to swap out the planar for the backup I bought.

This server has a RAID set with six SCSI drives, attached to an Adaptec SCSI card and controlled by an Adaptec ServeRAID 6i card. The latter card carries a LiION battery to preserve the RAID configuration data during power-off periods, but that battery is dead as a doornail. As a result, each time I try a boot the card has to access the disk drives and extract the configuration information from disk to rebuild the controller data. This takes a few minutes and is annoying.

A new battery is about $160 and refurbished batteries sell for around $45 but I can get a new in box 6i card for $49 including shipping that comes with a battery. I chose that option and once it arrives, I can swap the battery then carefully open and reverse engineer the dead battery pack to figure out how I can replace it for a more reasonable cost in the future.


I have the code triggering reads and properly extracting the data from punched cards on my M600 card reader, but I still have a few items to finalize to be sure it is ready for production card reading. First, I want it to read just one card and wait for the next command before reading subsequent cards. I also need to exhaustively test all the status signals to be sure they are properly captured and match the machine state.

Unfortunately, my first cut at stopping the PICK command didn't work. I dropped the request at column 80 but the reader had already dropping the BUSY status line and thus had triggered the next PICK cycle based on my command line still being asserted. I moved the deactivation of PICK to the time when I am reading column 1 and will verify that this works properly.


I have been using digitalWrite to toggle the PICK command line on and off, but want to switch over to direct port access to lessen the load on the processor handling the columns since they come quite rapidly while a card moves at up to 16.67 per second, generating impulses about every half millisecond.

Second, I set up the serial interface to 115,200 baud in order to stream the two bytes per column during that half millisecond interface without risk of dropping characters. I will change the routine to store all eighty columns in an array during card reading, then dump the results at whatever speed the serial link uses. This eliminates the risk of overruns to the serial link. The downside of a slower link is that the next PICK command is issued later and the reader drops below its nominal card per minute rate. 

Thursday, October 28, 2021

Finally getting back to the shop


I have finally completed the majority of the tasks and shopping for my new home, allowing me to return to the workshop and restart my projects. There are still jobs at home and still decorating to accomplish, so my time will be divided for a bit more but at least I can give due time to my hobbies now.


Because of the short time I had to pack up for my move to the east coast and the dispersion of my parts and equipment across multiple sheds and rooms in the old home, I have many components such as transistors spread across many different boxes. 

I decided to go through the boxes and extract some common components into buckets, which I can later winnow down and sort into specific bins for quicker access. This took quite some time but will contribute to the gradual organization of my workshop.


I put in about 30 minutes drilling and mounting stands and inserting switches and an LED on the aluminum box for the new controller. I have a bit of wiring to do before I close up the box and begin testing.