Saturday, October 30, 2021

Debugging new Documation card reader controller, also debugging P390 system

 P390 STATUS

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.

ARDUINO BASED CARD READER CONTROLLER DEBUGGING

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.

ENHANCEMENTS PLANNED FOR READER CONTROLLER

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. 

No comments:

Post a Comment