A couple of signals were misconnected, but quickly set right, then I confirmed that this was very solid, no glitches, nothing flaky on signals, however in the midst of verifying the signals I broke off one of the leads from the ribbon cable I use to connect the boards together.
While the ribbon cable is very clean, color coded and seemed like a good idea, in practice the small stranded leads would break off either where they were soldered to pins on most boards or where they were inserted in clamp blocks on the latch board. I decided I had to rewire this with solid wire but didn't want a rats nest of individual leads. I chose a four conductor phone line cable for the work.
With the new wiring, I shouldn't have any breakage whenever I have to check signals inside or even move the boards around. Getting this bulletproof is important to long term reliability of the system. It took some time to replace the ribbon cables with the new cables, up until the end of Saturday when I resumed testing of the reader adapter logic. I am very pleased to be able to finalize the reader logic, with the interface issues fully resolved.
Adapter problems behind me, it is back to testing the fpga logic - my adapter module - to work on its error handling and verify all the corner conditions. It is reading the data into memory perfectly and successfully boots from boot mode cards. The test program ran through a deck of cards, keeping itself exactly in sync and not dropping any columns.
I have a couple of problems I will be tracing tomorrow. On startup, the documation state machine is not in its idle state and not in any of the states I happened to instrument for. I need to understand what is happening and how to ensure it is idle at startup. Finally, when I am reading cards in a loop and the hopper goes empty, the reader is hanging in an adapter reading loop. I should be entering the last card state where the user either hits start to signify last card or reloads cards before hitting start to continue on reading the deck.
The first problem was actually not an issue at all. My instrumentation was not what I thought, thus I was misinterpreting a status displayed on the fpga board. The state machine starts correctly.
The second issue involves the relative timing of the signals from the card reader, further complicated by the tight serial link reading loop I use during the time I am transferring column data from the reader. My adapter does not notice that the hopper empty situation occurred (reported by the hock signal).
The hock signal, hopper empty, arrives 5.5 milliseconds after the reader drops the busy signal, and about 8.5 ms after I come out of the tight scan loop and first see that ready has dropped. Because the order of signals is
ready drops -> busy drops -> hock rises
my state machines move forward without having seen the hock condition in time. Further, the someone decoupled read of the Documation reading has been requested but can't complete until the physical reader comes ready again.
Looking closer at the traces, I found a couple of design flaws. First, the way I handled the hopper empty state would cause it to be reset prematurely. Second, the documation state machine would go to its idle position too early, right after I stopped reading the 80th column but while the mechanism was still moving the card. Since we are tightly focused only on input chip 1 during the columnar read, the busy signal is not detected until we come out of the focused loop, well after the state machine has moved forward.
I added a new state, which means that from column 80, it advanced when busy goes high (because we came out of the tight loop) then advances to the end state once busy again drops. This worked perfectly.
It is in a state where every time I ready the reader with new cards, it continually reads them - thus the DoRead state is stuck on when it shouldn't be. I suspect it is a problem in my logic handling the hopper check error condition.
This is exactly where I expect my remaining debugging to concentrate - error and edge conditions. I am using the hopper check error as a way to know that the hopper is empty, but the time sequence for presenting the error is after requesting a read which fails. I want to know the hopper is empty before I request the read. It will require me to wire up an additional signal, similar to the stacker select switch I did earlier. I do have a spare signal line, as I can use the original IM signal pin now that the timer chip is delivering the extended IM pulse on another pin.
Wiring to be done and testing continues next week. It is now end of day Sunday. Still very very happy because the interface is totally solid now.
APL TYPEBALL TO RUN APL/1130 USING THE 1130 CONSOLE
I posted inquiries on several forums including the MidAtlantic Retro Computing Hobbyist (MARCH) list and received a response within a day from Rolf Levenbach, an owner of a 988 typeball who is willing to sell it to me. As this is the right ball type for the 1130, it will be the cleanest and most elegant implementation. This is excellent news indeed. Further, his price was more than fair, especially when he could have commanded more on ebay. Fellow enthusiasts like Rolf have made this project easier and more comprehensive, through their generosity and helpfulness; I salute them.
Here are a few examples of APL statements (picked up from wikipedia and other web posts) - quite terse and uses a special set of characters thus the need for the typeball:
life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}
⎕←{⍵/⍨~{⍵∨≠\⍵}⍵∊'<>'}txt
(~R∊R∘.×R)/R←1↓ιR
The 1130 implementation uses the console keyboard and typewriter; after installing the APL typeball, the APL system disk pack is inserted into a drive and booted. To support all the characters used in APL, the keyboard operates in a unique three-case mode, not just upper-case and lower-case. Shift keys move the keyboard between the three 'cases', with the value displayed in one register on the console pedestal indicating which case is currently active.
Each keyboard key has three characters assigned to it, one for each 'case'. On the IBM 2741 terminal (also based on selectric typewriters), special keycaps can be installed on the keyboard, but that was not available for the 1130. One could put stickers on the keys or refer to a diagram that showed the characters for each key.
Here is what a user would see on the typewriter paper when starting up APL and running a trivial program:
Here are the 987 and 988 typeballs from a blog entry photograph http://www.computerculture.org/wp-content/uploads/2012/03/APL-Fig10-APLballs.jpg
LINE PRINTER INTERFACE AND ADAPTER
This week also involved business travel, where I was out of state most of the week and catching up with other obligations on Monday and Friday, instead of working in the garage. It did give me a chance to build more of the adapter logic for the fpga side during long flights, but it wasn't until Friday afternoon that I could even open the door to the garage.
I am currently using the ISE simulator to debug the serial link control module and move outward, before I begin driving the printer with 1130 programming. I also have quite a bit of code to complete, particularly the SAC emulator, before the 1130 adapter itself could interface to the processor.
TEMPORARY DISK DRIVE
For convenience, I decided adapt the SD card 'disk drive' designed by Richard Stofer for his fpga based 1130 emulator, to use to run DMS2 and APL/1130 on my hardware while I work on the other peripherals and then adapting the RK-05 drives to appear to be IBM 2310s.
It uses the FX2 connector, which I also need to use, and it requires far too many IO lines to the fpga. Fortunately, I have a few ways I can proceed. There is an Arduino shield I own for use with an SD card, I have a second fpga board that could operate with Richard Stofer's board and link to the main fpga, Finally, I have a different fgpa board that supports disk drives, which could be linked to the primary 1130 fpga. Further, I have a Raspberry PI that could also fill in.
The SD card interface is SPI and can operate fast enough to deliver data fast enough to match the 1130's disk transfer rates. I will make use of the Arduino to host the shield, with the shield in place, then operate a separate link to the fpga using SPI - taking just four signal lines - and a very simple protocol I will design.
More on this next week. Here is the shield. http://www.seeedstudio.com/wiki/SD_Card_Shield_V3.0
No comments:
Post a Comment