The cables for the 1053 printer and console bitswitches had been pulled out to allow repositioning of the units for service, but needed to be pulled back inside the 1131 frame so the printer could sit nicely on its base in the recess.
XEROX ALTO DISK QUESTIONS
There are a number of discussions arising about whether to use a disk emulator with the Alto and whether such an emulator exists. This pushes us into a murky area, because you can have an emulator that connects to the Diablo connector to the disk controller card yet it now work with a given system.
I could take a Diablo 31 drive that is hooked to one kind of system, assuming it has the same options installed, move it over to an Alto and it will read and write to disk cartridges for an Alto. However, if I take a cartridge written on an Alto, put it in an identical Diablo 31 that is hooked to a different system, the format may be unintelligible. Some of the format decisions for data on the disk are made in the disk controller card, not done in the drive.
The serial bit stream coming in to a disk controller card from the Diablo 31 drive, or an emulator for the drive, must be in the format and with the timing of gaps that are expected by the Alto controller card. A controller card for a different minicomputer may have a very different format for the serial stream that produces the same data words.
One may write the least significant bit of a word first on the serial stream, while the other writes from most significant to least. The CRC algorithm and the scope of what is covered in the checksum can vary.
Basic patterns that allow the controller card to sync up to the first bit of the first word of a field may be different between controller designs, thus if the emulator emits a serial stream with the wrong pattern, the controller card won't be able to interpret it.
One system may choose to write a single field in the sector, while another system may have a controller card that writes separate header and data fields (or a header, a label and a data field as the Alto does). The serial bit stream from an emulator hooked to the Diablo interface cable will be quite different.
Thus, we need an emulator for a Diablo 31 drive hooked to an Alto disk controller card, not just an emulator for a Diablo 31 that works with a different system. If we decide to find a Trident emulator instead, since we have the Trident controller cards also, it would need to emulate the Trident serial bit stream formatted as the Alto Trident card expects. Not any old Trident or Diablo emulator will work.
Building one would be very easy, once we knew all the details of what the serial stream looks like on a disk. Might be possible to drive a read and scope the output to determine some of the choices, augmenting it with the controller card schematics and whatever microcode listings we have for the part of the controller behavior that is performed in software (sector task and controller task) rather than in hardware on the card.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Restructuring the GUI
I updated the FPGA to detect whether the new GUI attempts a transaction, but also moved my new GUI code over to the Linux PC which I had previously used with the old GUI. Unfortunately, some of my code is too Windows specific, particularly the bitmap manipulating code that puts nice icons and images on the screen. I will either have to get the Windows based PC working properly or make further modifications to the GUI to allow it to work on a Linux version of wxPython.
The new GUI does not send a transaction to the board, as far as the FPGA is concerned. It times out trying to read the results after it failed to send the transaction, but it opens the USB link just fine with the same results as seen in the original GUI.
When I went back to the original GUI on the Linux machine, it began failing to see the board. I discovered that permissions to the usb directory with the device list had been changed by a recent Ubuntu update to block user mode access, thus my code couldn't find the board when it was able to yesterday.
I updated permissions and was able to open the old GUI just fine, but I suspect other parts of the pyUSB library and interface to the USB device is malfunctioning. The good news is that I don't care about the Linux machine for the GUI, since the new one will run on the Windows laptop. I was able to validate that the Windows machine received reasonable information from the USB library.
Knowing that the problem is on the PC side, I looked over my code and found an embarrassing error that was causing my code to skip writing transactions to the USB link. I quickly fixed it and was talking correctly to my FPGA again.
One of my changes to the code was intended to make it more robust, so that it could come up even if the link (and FPGA on the far side) isn't operational. I check to see if there is a good link, otherwise I skip writing and reading transactions. I factored this out into a function 'checkstatus' which returns True or False depending on whether we have a good link operating.
My error was in the line that begin "if self.checkstatus == True" which conditioned the write of the transaction. This fetches the address of the object checkstatus, returning the fact that it is a function. It does not execute the function and check its return value. It looks at the address of the function.
The address will never be True, so the condition always fails and I don't write to the USB link. It should have been "if self.checkstatus() == True", asking to locate the object checkstatus, execute it with no parameters, and compare its return value to True.
If I had erred the same way in the read side, this would have been a silent failure since the read would also be skipped. However, I wrote the 'if' statement correctly in the read function, so it tried to read the response to a transaction which had never been sent. Thus, the timeout errors I experienced.
I moved on to debugging the display logic for the state of the machine, which parses the responses from the USB link and stores them as state in the 1131 controller module, for eventual display by the 1131 view module. I had one bad line in the code to root out and then moved forward to some timeout issue that is being experienced with the stream of transactions going from PC to FPGA.
I decided that diagnostic outputs should be added to the GUI, as well as slowing down the status display task, allowing me to check for programming problems on my end. I will roll this into the code tonight but the testing will wait until tomorrow morning (Wednesday).
I updated the FPGA to detect whether the new GUI attempts a transaction, but also moved my new GUI code over to the Linux PC which I had previously used with the old GUI. Unfortunately, some of my code is too Windows specific, particularly the bitmap manipulating code that puts nice icons and images on the screen. I will either have to get the Windows based PC working properly or make further modifications to the GUI to allow it to work on a Linux version of wxPython.
The new GUI does not send a transaction to the board, as far as the FPGA is concerned. It times out trying to read the results after it failed to send the transaction, but it opens the USB link just fine with the same results as seen in the original GUI.
When I went back to the original GUI on the Linux machine, it began failing to see the board. I discovered that permissions to the usb directory with the device list had been changed by a recent Ubuntu update to block user mode access, thus my code couldn't find the board when it was able to yesterday.
I updated permissions and was able to open the old GUI just fine, but I suspect other parts of the pyUSB library and interface to the USB device is malfunctioning. The good news is that I don't care about the Linux machine for the GUI, since the new one will run on the Windows laptop. I was able to validate that the Windows machine received reasonable information from the USB library.
Knowing that the problem is on the PC side, I looked over my code and found an embarrassing error that was causing my code to skip writing transactions to the USB link. I quickly fixed it and was talking correctly to my FPGA again.
One of my changes to the code was intended to make it more robust, so that it could come up even if the link (and FPGA on the far side) isn't operational. I check to see if there is a good link, otherwise I skip writing and reading transactions. I factored this out into a function 'checkstatus' which returns True or False depending on whether we have a good link operating.
My error was in the line that begin "if self.checkstatus == True" which conditioned the write of the transaction. This fetches the address of the object checkstatus, returning the fact that it is a function. It does not execute the function and check its return value. It looks at the address of the function.
The address will never be True, so the condition always fails and I don't write to the USB link. It should have been "if self.checkstatus() == True", asking to locate the object checkstatus, execute it with no parameters, and compare its return value to True.
If I had erred the same way in the read side, this would have been a silent failure since the read would also be skipped. However, I wrote the 'if' statement correctly in the read function, so it tried to read the response to a transaction which had never been sent. Thus, the timeout errors I experienced.
I moved on to debugging the display logic for the state of the machine, which parses the responses from the USB link and stores them as state in the 1131 controller module, for eventual display by the 1131 view module. I had one bad line in the code to root out and then moved forward to some timeout issue that is being experienced with the stream of transactions going from PC to FPGA.
I decided that diagnostic outputs should be added to the GUI, as well as slowing down the status display task, allowing me to check for programming problems on my end. I will roll this into the code tonight but the testing will wait until tomorrow morning (Wednesday).
Welcome back. Hope you had a great trip!
ReplyDeleteBob