Prep for VCF West, testing, boot up and running DMS2 from virtual 2310, virtual 1422 and real 1132 peripherals, bad memory card

DIGITAL GAME MUSEUM TIME

I am a board member of this museum and visited today to talk with another board member and restoration staff. Recently the interior was reorganized to make the collection more space efficient, using rolling shelving, and to establish a playable game space in the back. It looks great and should make for a more enjoyable time for visitors to the museum. I was back by mid-afternoon and working on my 1130 systems.

1053 CONSOLE PRINTER RESTORATION

I ran the keyboard/typewriter diagnostics a few times, which helps loosen up the machine and make it type more accurately. Already the carrier return is more dependable, although I still have erratic line advancement due to goopy adhesive in the mechanism. Typing itself looks pretty good now.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Restructuring the GUI

-- mirror 1053 console printer and 1131 keyboard --

First up was the fpga engineered with appropriate diagnostic LEDs for the state of the mirror 1053 driver. It exhibited the special USB bit rot, dropping bit 6 this time, rather than bit 4. I made some other changes to set up arming and disarming of the 1627, 1134 and 1055 real devices from the GUI. Unarmed devices can't trigger interrupts.

The changed code went through - no spurious interrupts and no dropped USB bits. My test, however, uncovered a flaw in my GUI code in the sequence in which I look to see if I should arm or disarm the device. I moved the code up to the right place. Too, I found a few places where the state machines for the mirror driver would take action, yet they should be inert if the driver isn't armed. .

My next test resulted in a hung transaction engine, perhaps when I was firing off the arm and disarm codes. I needed to look over this part of the fpga carefully, then spotted that I wasn't ending the write special data transaction.

I fixed the problem and saw that the device armed properly. However, it didn't disarm when it should have. Further, when I tried to load core I had the bad bit problem over the USB so had to rebuild to clear up the spurious error. I did spot the problem with the disarming, which is only in the GUI so I have to make some change to the fpga just to force a good synthesis.

The mirror device worked pretty well. It missed about one character in 30 when the program was typing at full speed. I need to look for a flaw that will lose a character sporadically. Otherwise it looks good, except for an error check issue on the arm and disarm push transactions.

-- virtual 1403 printer --

The next device I debugged was the virtual line printer. It will be helpful if this is working for the exhibition, to give attendees a PC file with the printout of whatever they run on the real 1130. Also, it will free the 1130 from the heavy CPU load required to drive the 1132 printer.

I set up a print line and test program to print a line and space, over and over. It appears to be going to the next page, not skipping a single line. There is also a small flaw with the error check on DSW pushes. I will set up 1403 oriented diagnostics

PREPARING FOR VCF WEST EXHIBITION AUG 6-7

I had listed work to do on both the real and replica 1130 systems in yesterday's post. Today I worked on the cable holder for the memory ribbon cables and replacing the front plate in the kickspace below the keyboard. The cable holder had been glued to the underside of the typewriter pan, above the logic gates, but had come loose. The pan is a very glossy and slick enamel, not very suitable for adhesion.

Instead, I cleaned, roughed up and prepared the inside of the kickplate then epoxied the holder there. The memory cables will hook into the holder there and be out of the way. Once it was very solid, about an hour after gluing, it was ready for the kickplate to be reattached. This plate does in the footwell under the keyboard and typewriter, forming the visible cover when someone looks in from the front.

I couldn't find three of the four original bolts that held the kickplate on, so it was off to a hardware store to get what I needed. While I was there, I bought a 4 x 8 sheet and had it cut into the five covers that will go on my 1130 replica. These will be painted - four in medium-dark gray pebble finish and one in either garnet rose or classic blue, whichever of those colors looks more authentic.

The painting will take place tomorrow, first a sand texture coat and then the color coats. I will leave the backsides plain in order to glue mounting brackets onto them. I have a notion for how to mount the panels on my metal frame.

The kickplate is in place and the memory ribbon cables securely engaged in the holder that I epoxied to the plate. I used a couple of rubber bands to keep the cables from slipping out of the holder. The plate is solidly in place and cables routed properly.

The remaining two tasks on the cosmetics list are to secure the 1053 power connector to the SMS connection panel deep inside the 1130, and to repair the mounting screw for the power connector from the 1132 printer.  The SMS connector panel is now buttoned up nicely, so all that remains is to figure out what parts I need for the female power connection on the 1131, so that the male power connector from the 1132 will mate with it.

I powered up the 1132 in order to check out its operation, booting DMS2 from a virtual disk cartridge and running jobs from the virtual 1442. It booted fine, printed the welcome banner on the 1132 and I fed in a deck of cards with a job to compile some fortran code. The machine was in the midst of the fortran compilation when it stopped with a parity error. Up until that point, all was going well.

running a job from virtual 1442 on system booted from virtual 2310

This could be an issue I have to deal with concerning my virtual devices,although more likely this was residual junk in high storage and a flaw in some software since the address being referenced was up above the 8K line. The DMS2 disk pack for the 1130 simulator was built for a 16K machine which should mean no addresses beyond 0x3fff will be generated. I will clear memory so that it writes correct parity everywhere and try this again later.

To check out the memory, I made use of the CE Switches built into the 1131, specifically the Storage Load and the Storage Display switches. These will cycle continuously through all memory addresses, writing the console bit switch values into memory, or cycle continuously reading memory. Even when good data is supposedly written into memory, the Storage Display runs into a parity error when it reaches a memory address in the second 8K.

So this is good - I don't have a flaw in my SAC Interface or virtual devices that causes parity errors - but bad - because there is a hardware problem I need to fix. As a safety measure, I will generate a virtual DMS2 system with 8K of memory that can run at the show without touching the upper 8K. I will make sure that this 8K system boots up and runs several jobs to completion on my system.

The 8K system boots, confirms it is 8K, but something branches up to 0x3xxx and hits the parity error. At first I though it was a problem with the Fortran compiler, so I set up a deck to execute DUP but that had the same failure. This needs investigation.  See section of memory failure.

I have a few advertisements for the 1130 and some textbooks, which I will bring to add to the flavor of the exhibit. I need to figure out how to display them, secure and protect them, and keep track of them during the show.

1131 CORE MEMORY FAILURES

I walked through memory addresses and determined that the parity errors happen for specific ranges of addresses in the second memory compartment (addresses 0x2000 to 0x3fff). Any address in that compartment that has address bits 9 to 11 is 0b011 will fail. 203x or 20Bx, 283x, or 28Bx, 303x or 30Bx, and 383x or 38Bx. I have to find a card related to decoding 011 for drive lines and figure out what is wrong with it.