Restructuring the GUI
-- virtual 2310 disk drive --
I had discovered a problem with the way I was modeling the busy bit for the DSW. It led to an error stop in the DMS Cold Start card program. I worked out a more faithful method and implemented it, ready for testing this morning. The virtual device will go busy as soon as it sees a seek, initiate read or initiate write command and will switch off when the operation complete status is triggered.
I had also switched around the diagnostic signals on the LED to the most useful ones related to the virtual 2310. My first attempt I found the sporadic bug where Vivado leaves me with bit 4 of the USB not working, but a new pass of the same logic through the toolchain should clear it up (wasting 15 minutes). Alas, same problem so trivial change and ran it again. Still bad. Made a more substantive change and tried that.
Finally I was free of the phantom missing bit 4 problem and could resume testing. I made it quite a bit further past the earlier point in the boot card sequence, with the system stopping at location 0x01FE which I think is somewhere in the boot sequence. As well as this problem, I noticed that if I attempt an XIO to the disk drive when it is not ready, it still kicks off the state machines or tries to perform the action. I need to make it obey the not ready condition more fully.
With those changes in place, I went out in the afternoon for more testing. First, I wanted to verify that it was inert as far as XIO when the device is not ready. Then, I wanted to investigate the behavior of the boot sequence more fully.
I had closed up the SAC Interface box, in order to have it ready for transport and exhibition. I don't know if I dislodged some wiring or whether this is a random Vivado corruption of the bitstream, but when I turn on the 1130 the SAC box is commanding interrupts on IL3 and IL4. I attempted a change to the logic and a new bitstream generation just to rule this out. If it is not the toolchain, then I have a hardware problem in my interface box.
Another idea came to mind. I had a highspeed link between an auxiliary fpga and the main one, in order to handle physical peripherals such as the 1627 plotter and 1134/1055 paper tape devices. I removed it, taped it over and put it inside the SAC unit.
However, if spurious signals on the line are interpreted as device signals, they could be generating interrupts. The devices just mention happen to interrupt on IL3 and IL4, which does match the symptoms. I blocked the interrupt requests for those devices and resynthesized.
I still have hot requests for interrupt levels 3 and 4. I decided to work on eliminating the devices in swathes until the IL level is gone, then reintroduce until I figure out what device is giving me the problem. At least the testing is quick - power up the fpga and the LED goes on right away if the problem persists.
With only eight of the 20 devices left, I still had a hot IL4 signal. I moved to the extreme, removing all of them so that the line is held low. Now I have seen everything. I have a signal, IntReqLvl4, which is set to '0' yet the diagnostic LED shows it '1'. This makes no sense. I am spreading the signals to other LEDs as well, for no better reason than to insist on corroboration.
With the signals spread over the LEDs, I could see that only the one I 'thought' was IL4 is still lit. I powered up the 1131 to verify and indeed there are no interrupt requests presented. I then went back and reset all the twenty devices back into the IL4 chain and resynthesized.
Every device back in, yet no interrupts being requested. It was one of two causes - either the high speed link issue for plotter and paper tape was bad but I fixed it earlier, or the toolchain is at it again. At this point, as long as it works properly I will get back to testing the disk after four hours of frittered time.
Something is not quite right, yet, although it may have worked. I saw the boot program read from disk into 0x00d0, the read the next sector into 0x0122, and finally read sector 2 into 0x0004. This is when the look sat at 0x01F4, possibly waiting to print to the 1132 line printer. I should do this test with the printer powered up and ready, just to see what happens.
I am not entirely sure if the disk image was set up for a 16K machine. If configured for a different memory size, it may not work properly even if my disk emulation is perfect.
I took the opportunity to load the keyboard/console diagnostic, which worked well. The 1053 types great, although its carrier return is still defective. It needs a helping hand to move it back to the left. The keyboard worked right, also.
I need to do some investigation of the boot sequence and of the disk image whose PC file I am using, to determine whether things are working okay or not. I may have some timing related problems in the virtual disk, particularly if it is too quick on the read.
The sectors being read are the correct ones for a boot. I need to do more testing of my disk device to ensure it is really working properly. After closely examining my GUI code, I think I see a flaw that might have caused some of the problems. It is changed and I am back out to test.
Success! DCIP began typing out the sector I chose on the console printer. It looked really nice, so time to bring up a test boot of the DMS disk once again. This time, it flew through quite a few fetches until the full DMS2 was up and waiting on device 6 - the 1132 printer - to become ready so that the DMS banner could be printed.
-- mirror 1053 console printer --
The next device to work on is the mirror 1053 function, which should capture a replica image of what is typing on the console, placing the contents in a PC file. This uses the FIFO, the remaining Xilinx IP unit that is giving me the obscure 'black box' error messages. I will begin debugging this tomorrow, while I work on the remaining cosmetic and testing items for the real 1130. When that is done, I will move on to the 1130 replica and its readying for the exhibition.
PREPARING FOR VCF WEST EXHIBITION
I have a few tasks to prepare the 1131 - the main unit of an 1130 system, consisting of the central processor, console printer, keyboard, internal disk drive, display pedestal and other controls:
Link to video of 1130 replica running (viewing display pedestal)
The pedestal with the blinking lights and rotary control is temporarily mounted on wooden stands which need changing to set the unit firmly at the right height and position. I have an IBM Memory typewriter sitting on the metal to serve as a 1053 console printer, but I don't have the cover manufactured for it yet. Similarly, I have the console bit switches on a mounting plate but not the final plate that sits in front of the 1053.
Today I tried to buy the hardboard panels and get them cut to serve as the 1131 covers. The first Home Depot had the hardboard sheet but their panel saw was out of service. The second Home Depot a few miles away also had the hardboard sheet and also had an out of service panel saw. The Lowes a few miles further had a working panel saw, but zero hardboard panels in stock. At that point, I gave up for the day and went back to testing on the 1130.
I closed up my SAC Interface box for transport and use over the next few weeks. I have the temporary diagnostic LED outputs emerging from the front of the case along with the USB cable although eventually I intend to install a more secure USB connector and the LEDs will be replaced with links to various FPGA boards such as disk drive controllers and I/O fanout units.
-- virtual 2310 disk drive --
I had discovered a problem with the way I was modeling the busy bit for the DSW. It led to an error stop in the DMS Cold Start card program. I worked out a more faithful method and implemented it, ready for testing this morning. The virtual device will go busy as soon as it sees a seek, initiate read or initiate write command and will switch off when the operation complete status is triggered.
I had also switched around the diagnostic signals on the LED to the most useful ones related to the virtual 2310. My first attempt I found the sporadic bug where Vivado leaves me with bit 4 of the USB not working, but a new pass of the same logic through the toolchain should clear it up (wasting 15 minutes). Alas, same problem so trivial change and ran it again. Still bad. Made a more substantive change and tried that.
Finally I was free of the phantom missing bit 4 problem and could resume testing. I made it quite a bit further past the earlier point in the boot card sequence, with the system stopping at location 0x01FE which I think is somewhere in the boot sequence. As well as this problem, I noticed that if I attempt an XIO to the disk drive when it is not ready, it still kicks off the state machines or tries to perform the action. I need to make it obey the not ready condition more fully.
With those changes in place, I went out in the afternoon for more testing. First, I wanted to verify that it was inert as far as XIO when the device is not ready. Then, I wanted to investigate the behavior of the boot sequence more fully.
I had closed up the SAC Interface box, in order to have it ready for transport and exhibition. I don't know if I dislodged some wiring or whether this is a random Vivado corruption of the bitstream, but when I turn on the 1130 the SAC box is commanding interrupts on IL3 and IL4. I attempted a change to the logic and a new bitstream generation just to rule this out. If it is not the toolchain, then I have a hardware problem in my interface box.
Another idea came to mind. I had a highspeed link between an auxiliary fpga and the main one, in order to handle physical peripherals such as the 1627 plotter and 1134/1055 paper tape devices. I removed it, taped it over and put it inside the SAC unit.
However, if spurious signals on the line are interpreted as device signals, they could be generating interrupts. The devices just mention happen to interrupt on IL3 and IL4, which does match the symptoms. I blocked the interrupt requests for those devices and resynthesized.
I still have hot requests for interrupt levels 3 and 4. I decided to work on eliminating the devices in swathes until the IL level is gone, then reintroduce until I figure out what device is giving me the problem. At least the testing is quick - power up the fpga and the LED goes on right away if the problem persists.
With only eight of the 20 devices left, I still had a hot IL4 signal. I moved to the extreme, removing all of them so that the line is held low. Now I have seen everything. I have a signal, IntReqLvl4, which is set to '0' yet the diagnostic LED shows it '1'. This makes no sense. I am spreading the signals to other LEDs as well, for no better reason than to insist on corroboration.
With the signals spread over the LEDs, I could see that only the one I 'thought' was IL4 is still lit. I powered up the 1131 to verify and indeed there are no interrupt requests presented. I then went back and reset all the twenty devices back into the IL4 chain and resynthesized.
Every device back in, yet no interrupts being requested. It was one of two causes - either the high speed link issue for plotter and paper tape was bad but I fixed it earlier, or the toolchain is at it again. At this point, as long as it works properly I will get back to testing the disk after four hours of frittered time.
Something is not quite right, yet, although it may have worked. I saw the boot program read from disk into 0x00d0, the read the next sector into 0x0122, and finally read sector 2 into 0x0004. This is when the look sat at 0x01F4, possibly waiting to print to the 1132 line printer. I should do this test with the printer powered up and ready, just to see what happens.
I am not entirely sure if the disk image was set up for a 16K machine. If configured for a different memory size, it may not work properly even if my disk emulation is perfect.
I took the opportunity to load the keyboard/console diagnostic, which worked well. The 1053 types great, although its carrier return is still defective. It needs a helping hand to move it back to the left. The keyboard worked right, also.
I need to do some investigation of the boot sequence and of the disk image whose PC file I am using, to determine whether things are working okay or not. I may have some timing related problems in the virtual disk, particularly if it is too quick on the read.
The sectors being read are the correct ones for a boot. I need to do more testing of my disk device to ensure it is really working properly. After closely examining my GUI code, I think I see a flaw that might have caused some of the problems. It is changed and I am back out to test.
Success! DCIP began typing out the sector I chose on the console printer. It looked really nice, so time to bring up a test boot of the DMS disk once again. This time, it flew through quite a few fetches until the full DMS2 was up and waiting on device 6 - the 1132 printer - to become ready so that the DMS banner could be printed.
-- mirror 1053 console printer --
The next device to work on is the mirror 1053 function, which should capture a replica image of what is typing on the console, placing the contents in a PC file. This uses the FIFO, the remaining Xilinx IP unit that is giving me the obscure 'black box' error messages. I will begin debugging this tomorrow, while I work on the remaining cosmetic and testing items for the real 1130. When that is done, I will move on to the 1130 replica and its readying for the exhibition.
PREPARING FOR VCF WEST EXHIBITION
I have a few tasks to prepare the 1131 - the main unit of an 1130 system, consisting of the central processor, console printer, keyboard, internal disk drive, display pedestal and other controls:
- Attach cable holder and route the cables from the processor gates (A and B) to the 'blister', the expansion frame to the left of the keyboard where the memory sits in larger configuration machines.
- Refasten the clamp holding the 1053 console printer power cable to the power connection point inside the 1131
- Replace the front facing machine cover that sits under the desk
- Work on replacement threaded screw for 1132 power cable where it attaches to the rear of the 1132
- hardboard panels cut and painted to fit on frame in place of metal covers
- prime and paint metal top of replica to pebble gray IBM color and texture
- reload fpga and reconnect cabling to pedestal, keyboard, other controls
- shorten pedestal stand and anchor in place for show
- decide on appropriate printer mechanism for show
Link to video of 1130 replica running (viewing display pedestal)
 |
| Keyboard and control panel before mounting on frame |
Today I tried to buy the hardboard panels and get them cut to serve as the 1131 covers. The first Home Depot had the hardboard sheet but their panel saw was out of service. The second Home Depot a few miles away also had the hardboard sheet and also had an out of service panel saw. The Lowes a few miles further had a working panel saw, but zero hardboard panels in stock. At that point, I gave up for the day and went back to testing on the 1130.
I closed up my SAC Interface box for transport and use over the next few weeks. I have the temporary diagnostic LED outputs emerging from the front of the case along with the USB cable although eventually I intend to install a more secure USB connector and the LEDs will be replaced with links to various FPGA boards such as disk drive controllers and I/O fanout units.
No comments:
Post a Comment