Setting up testbed to exercise the user interface for debugging

MISSING A FEW BITS TO DO FULL OUT TESTING

This unit is in my home not at the workshop and therefore is not wired to an IBM 1130 disk. I have a bit of work to finish wiring the cables from disk controller to my level shifter, then from the level shifter to the DE10-Nano board.

The rocker and pushbutton switches won't arrive until tonight and then will need to be wired to the rest of the gear. 

HIGH LEVEL OUTLINE OF THE USER INTERFACE LOOP

Once the system has been initialized, the UI loop begins. It starts by drawing the interface screen with the first 13 file names discovered on the SC card and with the first filename highlighted but not selected.

The loop watches for one of five signals to be activated. These are:

• Power Failure
• Heads Loaded
• Rocker Switch UP pushed
• Rocker Switch DOWN pushed
• Selection Toggle button pushed

A power failure signal will tell us that we have lost the 12V line from the IBM 1130 and are running on our battery backup. We will break out of the interface loop which eventually will close down the bridge and other interfaces. Meanwhile a subtask monitoring the power failure signal gives us a few minutes before it commands Linux to do an immediate graceful shutdown. 

When the Heads Loaded signal goes on, we are being told that the physical disk drive was switched on, the dummy cartridge inside is spinning, and the controller attempted to command a solenoid to force the heads down onto the disk surface. If we have a selected filename, then we have already loaded the contents of that virtual cartridge onto the reserved RAM through the FPGA side of the system. In this case, we set the FPGA logic to emulate disk operation by sending a disk run command over the bridge and we send a signal to the disk controller that causes it to go into Ready state. Once it is ready we display a cartridge image on the screen and go into an inner Disk Operating loop.

When the Rocker UP or Rocker DOWN signal arrives, we move the highlighting up or down in the last of filenames from the SC card. If needed we scroll the screen as we can only show a max of 13 at one time. If a file is selected, we don't move off the screen but we can move the highlighted/selected entry upwards and downwards among the 13 spaces on the screen, exposing 0 to 12 filenames on either side of the selected one. 

When the Selection Toggle signal arrives, if we had previously selected one of the filenames then this just switches off that state, going back to showing it with simple highlighting. If the filename is highlighted but not already selected, we complete that action. This involves opening that virtual cartridge file, then sending a load command over the bridge and passing the contents of the file down to the FPGA to be written into the spare RAM. Once done, we show the filename with the selection formatting. 

Once we complete acting on one of these signals, except when we go into the inner Disk Operating loop, we redraw the screen are begin again at the top of the loop. Thus we are spinning around looking for one of those signals to take action. 

The Disk Operating inner loop is in control when we have the drive activated using one of our virtual cartridge images. In the inner loop we look at only two signals:

• Power Failure
• Head Loaded off

When Power Fail happens or the Head Loaded signal becomes false, if there had been a virtual cartridge loaded we have to perform an unload. We first send a disk off and then an unload command over the bridge and our FPGA logic will retrieve the cartridge information from RAM including any changes made by write operations from the IBM 1130. This is written back into the SD card file whenever we have had a change in contents - rather than replacing the entire contents. 

Thus the inner loop ends with either of those signals being detected and acted upon. If it was a release of the Head Loaded signal, we go back to the top of the interface loop, drawing the user interface screen and waiting for one or more of the five signals. If it was a Power Failure, that main loop then will end as well and we go through the graceful shutdown of the system, closing files, releasing memory and stopping the bridge. Meanwhile a subtask monitoring the power failure signal gives us a few minutes before it commands Linux to do an immediate graceful shutdown. 

TESTBED IDEA

I intend to redirect the points where the program will test the five signals, instead pointing at variables in the program that I can control. I can set these to act like button pushes, head loads, head load deactivation and power fail signals. 

At the bottom of the interface loop, where it would be returning to the top to start again, I will have a counter and some automation based on the value attained in the counter. We also slow this down with a 2 second pause for each pass of the loop which allows me to watch it in operation. 

I will be moving the highlight up and down, ensuring that it displays properly and handles all the edge cases. I will then toggle on selection and watch to see it request a load. 

I will deselect and move to a different file, again doing a selection. This will verify that we properly release the first file. 

Then I will turn on the Head Load signal to see that it drops into the proper Disk Operation loop. I can bring it out later by removing the Head Load and watch it request an unload. 

Finally I can test by having no file selected, asserting Head Load then later raising power fail which should not try the unload but still end the program.

TESTING BEGINNING

I am slogging my way through integrating and testing all of this, so that I can get into the core of the user interface and test it our as detailed above.