Virtual 1403 testing
Both sides are configured with tools to track the line that the printer believes it has reached - using the LEDs to display the line number and writing out line numbers from the GUI. The first test I ran was with skip to channel 4 requested. The results were erratic, but I spotted a couple of places that could have caused this and modified the GUI.
It will be a bit complicated, because I have two skip mechanisms, one in the FPGA that simulates timing and interrupts, the other in the GUI that adds appropriate blank lines to the PC based "paper" file. Both have to be correct and they need to agree.
Mirror 1053 testing
I cleaned up both sides of the mirror 1053 function. In the fpga, I had logic to save the function code for writes, reads and sense DSW, yet it turns out I won't poll for any of those. I dropped the sense code entirely and just use the write and read to pop in a typed character or grab a keyed character.
The GUI had some funky logic for when it got an 'empty buffer' code up from the fpga which is where I think it was losing characters. I restructured in a more natural way that simply pulls up the buffer contents repeatedly.
The fpga is busy grabbing keyboard characters but my GUI is not processing them at all. No impact on things and perhaps I will expand the mirror 1053 function to also mirror the keyboard, sometime in the future.
I ran another test using DCIP to drive the console printer and it was very solid. I may still be losing about 1% of the typed letters but it is acceptable now.
Test run of DMS2 from virtual 2310 and virtual card reader
I hooked up the 1132 printer again, readied it with paper, brought up the 1130 and attached the virtual 2310 disk drive and virtual 1442 card readers. I booted DMS2 and then ran a job that did 2 Fortran compiles and several DUP actions, then started the game which typed on the console printer.
See my Video of the 1130 running jobstream which is a 5+ minute quick and dirty video of the deck running.
-- Card deck utility program --
The IBM 1130 simulator defined the format for card decks that I also use with the SAC Interface and my devices. There are two general formats - ASCII text and 'binary' - where the latter is actually Hollerith code, the pattern of holes in each of the 80 card columns. My virtual 1442 deals exclusively in the Hollerith or card image format, which is misleadingly named binary format in the simulator.
People who wish to type up card decks for the simulator typically do it in ASCII mode, using a regular text editor such as Notepad on Windows. The choice of which ASCII character stands for each punched card character was set up when Brian Knittel wrote the 1130 simulator in what he called 029 mode. He picked the characters that are on the keyboard of an IBM 029 keypunch, which was the common way to produce cards during the 1130's era, and assigned an ASCII equivalent to each.
For most, ASCII has the same character as the 029, making the assignment obvious. Letters, numbers and many special characters like $ or # are in both ASCII and the 029 keyboard. However, there are some characters that exist only in one or the other. The 029 has a cent sign character but ASCII does not. There is a 'logical not' character which is also found on the 029 but not in ASCII. Plenty of ASCII characters don't have an 029 equivalent either.
Generally, since the overlap between 029 keypunch and ASCII is very high, one just types regular characters from the PC keyboard into a text file and submits it as an 029 format card deck to the IBM 1130 simulator. There is no tool for entering 'binary' or card image files, just a means to view decks and delete or move around entire card images within the deck (Deckview utility from the simulator).
I am designing a simple utility that will take a text file, assume it is in 029 format, and convert it to a card image ('binary') file for use with my system. This will allow visitors to the VCF West show to type up decks and run them on the system.
I had roofers here today to repair some rotted boards on corner of the house, which kept me out of the workshop. A good time to bang together the utility program for converting card decks. I did this as a command line - Python shell - utility rather than a full blown GUI because it doesn't need all that. I leveraged code I had used with my automated 029 keypunch and SAC Interface projects.
After a bit of testing and refinement, it is done. It will pop up a dialog box asking to select the input file, then automatically create an output file of the same name but extension of .bin instead of the .txt or .029 of the input file. It runs through the deck, converting and flags any conversion errors for correction. The output is:
PREPARATION FOR VCF WEST EXHIBITION
I looked over the replica and determined that I need to cut out a MDF plate for the console printer opening on the top, also to act as a base for the the display pedestal downtubes. I also need to reduce the height of the existing memory typewriter mechanism or stick in one of my selectrics. I have an I/O Selectric from an old word processing system that is exactly the right size and height, so that goes in and my working mechanism that is too big will come out for the time being.
The front cover in classic blue needs an IBM logo plate - no time to make one out of metal but I have a similar sized plate from an IBM 3803 control unit. Wrong color scheme and of course the wrong box number, but it will look okay on the quick and dirty covers. I placed the faux covers around the replica in my data center shed and like the way it will look.
Both sides are configured with tools to track the line that the printer believes it has reached - using the LEDs to display the line number and writing out line numbers from the GUI. The first test I ran was with skip to channel 4 requested. The results were erratic, but I spotted a couple of places that could have caused this and modified the GUI.
It will be a bit complicated, because I have two skip mechanisms, one in the FPGA that simulates timing and interrupts, the other in the GUI that adds appropriate blank lines to the PC based "paper" file. Both have to be correct and they need to agree.
Mirror 1053 testing
I cleaned up both sides of the mirror 1053 function. In the fpga, I had logic to save the function code for writes, reads and sense DSW, yet it turns out I won't poll for any of those. I dropped the sense code entirely and just use the write and read to pop in a typed character or grab a keyed character.
The GUI had some funky logic for when it got an 'empty buffer' code up from the fpga which is where I think it was losing characters. I restructured in a more natural way that simply pulls up the buffer contents repeatedly.
The fpga is busy grabbing keyboard characters but my GUI is not processing them at all. No impact on things and perhaps I will expand the mirror 1053 function to also mirror the keyboard, sometime in the future.
I ran another test using DCIP to drive the console printer and it was very solid. I may still be losing about 1% of the typed letters but it is acceptable now.
 |
| Mirror 1053 captured file from DCIP dump sector |
Test run of DMS2 from virtual 2310 and virtual card reader
I hooked up the 1132 printer again, readied it with paper, brought up the 1130 and attached the virtual 2310 disk drive and virtual 1442 card readers. I booted DMS2 and then ran a job that did 2 Fortran compiles and several DUP actions, then started the game which typed on the console printer.
 |
| First page of output of the Lunar Lander deck on the 1130 |
-- Card deck utility program --
The IBM 1130 simulator defined the format for card decks that I also use with the SAC Interface and my devices. There are two general formats - ASCII text and 'binary' - where the latter is actually Hollerith code, the pattern of holes in each of the 80 card columns. My virtual 1442 deals exclusively in the Hollerith or card image format, which is misleadingly named binary format in the simulator.
People who wish to type up card decks for the simulator typically do it in ASCII mode, using a regular text editor such as Notepad on Windows. The choice of which ASCII character stands for each punched card character was set up when Brian Knittel wrote the 1130 simulator in what he called 029 mode. He picked the characters that are on the keyboard of an IBM 029 keypunch, which was the common way to produce cards during the 1130's era, and assigned an ASCII equivalent to each.
For most, ASCII has the same character as the 029, making the assignment obvious. Letters, numbers and many special characters like $ or # are in both ASCII and the 029 keyboard. However, there are some characters that exist only in one or the other. The 029 has a cent sign character but ASCII does not. There is a 'logical not' character which is also found on the 029 but not in ASCII. Plenty of ASCII characters don't have an 029 equivalent either.
Generally, since the overlap between 029 keypunch and ASCII is very high, one just types regular characters from the PC keyboard into a text file and submits it as an 029 format card deck to the IBM 1130 simulator. There is no tool for entering 'binary' or card image files, just a means to view decks and delete or move around entire card images within the deck (Deckview utility from the simulator).
I am designing a simple utility that will take a text file, assume it is in 029 format, and convert it to a card image ('binary') file for use with my system. This will allow visitors to the VCF West show to type up decks and run them on the system.
I had roofers here today to repair some rotted boards on corner of the house, which kept me out of the workshop. A good time to bang together the utility program for converting card decks. I did this as a command line - Python shell - utility rather than a full blown GUI because it doesn't need all that. I leveraged code I had used with my automated 029 keypunch and SAC Interface projects.
After a bit of testing and refinement, it is done. It will pop up a dialog box asking to select the input file, then automatically create an output file of the same name but extension of .bin instead of the .txt or .029 of the input file. It runs through the deck, converting and flags any conversion errors for correction. The output is:
select the 029 or text file to convert
converted 5 cards successfully
PREPARATION FOR VCF WEST EXHIBITION
I looked over the replica and determined that I need to cut out a MDF plate for the console printer opening on the top, also to act as a base for the the display pedestal downtubes. I also need to reduce the height of the existing memory typewriter mechanism or stick in one of my selectrics. I have an I/O Selectric from an old word processing system that is exactly the right size and height, so that goes in and my working mechanism that is too big will come out for the time being.
The front cover in classic blue needs an IBM logo plate - no time to make one out of metal but I have a similar sized plate from an IBM 3803 control unit. Wrong color scheme and of course the wrong box number, but it will look okay on the quick and dirty covers. I placed the faux covers around the replica in my data center shed and like the way it will look.
 |
| Replica ready to install faux covers, then work on top |
No comments:
Post a Comment