When testing the 2310 adapter logic, it is increasingly difficult to tell when the system is locked up due to an error in my adapter and when it is just the damned typewriter, since it sprung the return/forward movement cable yesterday. I have to either get this fixed or get my mirror driver working so I can see what it thinks has been typed and detect stalls.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
My 2310 adapter logic works up until the point where the diagnostic utility issues the XIO Init Read with check for the first sector of the disk. I post the operation complete status, my adapter triggers IL2, but then it doesn't try any XIO Sense Device commands.
This suggested that I should look at my ILSW posting to verify that the interrupt routine is getting the proper response. If it doesn't recognize the interrupt as coming from my drive, it won't issue the sense command. That didn't seem to be a problem, but when I looked at the saved DSW I realized I was returning 0x4880 for the operation complete sense word, when it should have been 0x4800.
This wasn't caused by any of my logic for the adapter, which meant that some other logic in the fpga was raising bit 8, thus being ORed into the response word when my code processed the XIO Sense Device. This will take a bit of time to find. What I discovered when researching this was that my logic for handling the XIO Sense ILSW was not sound.
When in an interrupt routine, software can issue an XIO Sense ILSW which returns the bit-OR of all devices which have asked for an interrupt on that level. My logic returned the bit-OR of any request but if a device in IL2 issued the command, they got the bits back for all interrupt levels, not just 2. Thus, I need to condition my status bits on both IL request and which IL is active, since that is the only when which will receive a response to the XIO.
For XIO sense ILSW, I have a process responding for each device, adding its bits if any into the ILSW. The process will run anytime an XIO Sense ILSW is executed, but I have to gate its input so that it only sees the bits appropriate to the interrupt level which is currently active.
I made the change to my ILSW logic across all devices in the SAC box. This isn't the answer to why I am seeing the extraneous bit in the DSW - that has to be yet another defect in the logic somewhere.
The 1053 mirroring code instrumentation does not show any action when I am requesting the retrieval of buffered characters. I needed to figure out why this isn't occurring. It appears to be because I was using a signal (armed1) in a process but left it out of the process sensitivity list. Yes, there is a warning message about this, but buried in almost a thousand other messages.
Almost all the messages that come out are irrelevant, but can't be shut off or eliminated through coding changes - a really annoying aspect of the Xilinx toolchain. I suppose I could write programs to capture the warnings, save them with a flag i can set, then filter the warnings out of the subsequent reports for all those I marked as "hide". Seems to be a lot of work to overcome a clear flaw in the toolkit - anything that produces huge numbers of non-warnings is going to lead to problems because no sane person will put in twenty minutes checking the messages on every run of the toolchain. This can occur dozens of times an hour.
My change for the 1053 and ILSW routines were made, but I wasn't sure exactly how the 2310 was misbehaving, but when I came to realize the defect that was impacting the 1053 function, it appeared likely to impact the 2310 as well.
As I pondered the behavior of the 1053, I realized that I am not trying to fetch the data words because I am not seeing the completion of an XIO Write from the typewriter. This means I was looking at the wrong part of the circuitry in my debugging. After I realized this, I could see it was caused by changes I made earlier when I was flailing around looking at the incorrect use of device numbers (when I intended UCW numbers). I was resetting the last XIO function code before it was being sent to the PC, so that the mirror device ALWAYS received a function of 000.
Almost all the messages that come out are irrelevant, but can't be shut off or eliminated through coding changes - a really annoying aspect of the Xilinx toolchain. I suppose I could write programs to capture the warnings, save them with a flag i can set, then filter the warnings out of the subsequent reports for all those I marked as "hide". Seems to be a lot of work to overcome a clear flaw in the toolkit - anything that produces huge numbers of non-warnings is going to lead to problems because no sane person will put in twenty minutes checking the messages on every run of the toolchain. This can occur dozens of times an hour.
My change for the 1053 and ILSW routines were made, but I wasn't sure exactly how the 2310 was misbehaving, but when I came to realize the defect that was impacting the 1053 function, it appeared likely to impact the 2310 as well.
As I pondered the behavior of the 1053, I realized that I am not trying to fetch the data words because I am not seeing the completion of an XIO Write from the typewriter. This means I was looking at the wrong part of the circuitry in my debugging. After I realized this, I could see it was caused by changes I made earlier when I was flailing around looking at the incorrect use of device numbers (when I intended UCW numbers). I was resetting the last XIO function code before it was being sent to the PC, so that the mirror device ALWAYS received a function of 000.
No comments:
Post a Comment