SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Device adapter code additions
I added in the logic to handle the IBM 1134 paper tape reader and IBM 1055 paper tape punch devices - although the actual devices will be different, they will operate the same way. I didn't include the logic to handle program load although as this wouldn't work on my system unless I switch some jumpers which currently set the 1442 as the program load device. I can use my virtual program load function from the PC to force in the boot stream if needed.
I improved the python code that loads core from a simulator out file, causing it to go back after loading core and fetch all the locations to compare them to the intended result. This way I can be warned if any data isn't stored properly.
My first virtual device will be a 2501 card reader allowing me to read card decks which are files stored on the PC in IBM 1130 simulator format. Program Load mode will be accomplished by the PC program using cycle steal to load the first card in PL mode into core and asking the operator to start at IAR 0000, after which normal reading occurs from the device.
Testing of 1627 plotter device adapter
Instrumentation to debug the plotter adapter was changed before I went out at lunchtime to run some tests. I found that my timer was giving me a clean 3 ms delay, which is what I targeted. I then moved the instrumentation to watch the output signals that should be driving the plotter.
My shadowing logic to mark when I was in various XIO phases didn't clear the XIO E3 status until the next instruction T0, which left it incorrectly active even when at the end of a single instruction mode. I adjusted it to work better.
I am clearly seeing the output line change so I need to move on to look inside my 1627 hardware emulation box. I did verify that the pen up and pen down commands work properly, but I don't seem to be getting any movement for the drum up, drum down, carriage left or carriage right commands. I did notice that my fpga pin is at ground level even though it should be at 3.3V, which drives the carriage to the right continually.
Until I am sure what is going on with the Carr Right pin from the fpga, which could be a shorted wire or other problem inside the interface box, it doesn't make sense to shoot problems any further. Since the day was ending, I shut down the testing for the evening and went on to other tasks.
All in all, I had progress validating the adapter. It is possible that I need to tweak the timer to accommodate the speed of the strobe plotter, although there is no point touching anything until I find out what is going on with the Carriage Right line.
Study of connectivity to physical devices
I am leaning to using SPI to link to various physical peripherals from the fpga, in order to conserve the limited remaining I/O pins. Theoretically I have 30 available if I reorganize my connectors and cabling, but I could readily get 20 or more.
For the highest speed devices, I want an SPI bus operating at full 48MHz fpga clock speed, which is just possible using the clock modules on the Spartan chip to give me the clock phases necessary for SPI operation. Using the fpga as a master on a bidirectional bus, I would need 3 wires plus 1 per slave that shares this high speed bus.
A high speed SPI link would typically talk to FPGA boards as the slaves and should give me a bus that is well north of a megabyte per second transfer rate. Since the memory of the 1131 has a peak transfer rate of 277,777 words per second if it did nothing but cycle steal transfers, That means the high speed SPI link can fully saturate the 1131.
For Arduino hosted devices, I would only be able to safely operate at about 2MHz and may shift down to 1MHz to allow the processor time to do other work, since the boards are typically 16Mhz processors which would have trouble keeping up with the incoming data at higher speeds.
The Arduino libraries only offer master mode, but examples exists of ways to force the Arduino to act as an SPI slave. As slaves, this would require 3 wires plus 1 per slave for the medium speed bus to Arduinos. Raspberry Pi is an alternative to the Arduino, if I can set up an SPI slave link.
The Arduino is limited in its performance, although I could move to a faster ATMEL processor via the Chipkit Uno32 or similar variant of the Arduino. Still, none of them could keep up with the high speed SPI bus. Having a medium speed bus at 1MHz is good enough to provide about 50KB/s of data movement, which would still drive the 1130 to almost 10% of its memory bandwidth.
If necessary, I could also host slower speed links but those would demand 3+X wires for X slaves at the lower speed. I believe it better to spray out slow speed SPI from one of the slave FPGA boards connected by the 48Mhz link, rather than implement them on the main board. The only reason to build a low speed link would be specific peripherals or very long distances where noise might impair a faster link.
I will tentatively reserve space for 7 high speed and 7 medium speed slaves, making use of the 20 signals that are easily reached on the board. Many of these are currently used with my diagnostic lights, buttons and the current plotter connections. I will need to grab four wires to test one of the links, these will use the four lines I temporarily use for pushbutton inputs. That still leaves the sixteen lines currently used for LEDs and the plotter.
The initial assignments for medium speed are:
Testing of 1627 plotter device adapter
Instrumentation to debug the plotter adapter was changed before I went out at lunchtime to run some tests. I found that my timer was giving me a clean 3 ms delay, which is what I targeted. I then moved the instrumentation to watch the output signals that should be driving the plotter.
My shadowing logic to mark when I was in various XIO phases didn't clear the XIO E3 status until the next instruction T0, which left it incorrectly active even when at the end of a single instruction mode. I adjusted it to work better.
I am clearly seeing the output line change so I need to move on to look inside my 1627 hardware emulation box. I did verify that the pen up and pen down commands work properly, but I don't seem to be getting any movement for the drum up, drum down, carriage left or carriage right commands. I did notice that my fpga pin is at ground level even though it should be at 3.3V, which drives the carriage to the right continually.
Until I am sure what is going on with the Carr Right pin from the fpga, which could be a shorted wire or other problem inside the interface box, it doesn't make sense to shoot problems any further. Since the day was ending, I shut down the testing for the evening and went on to other tasks.
All in all, I had progress validating the adapter. It is possible that I need to tweak the timer to accommodate the speed of the strobe plotter, although there is no point touching anything until I find out what is going on with the Carriage Right line.
Study of connectivity to physical devices
I am leaning to using SPI to link to various physical peripherals from the fpga, in order to conserve the limited remaining I/O pins. Theoretically I have 30 available if I reorganize my connectors and cabling, but I could readily get 20 or more.
For the highest speed devices, I want an SPI bus operating at full 48MHz fpga clock speed, which is just possible using the clock modules on the Spartan chip to give me the clock phases necessary for SPI operation. Using the fpga as a master on a bidirectional bus, I would need 3 wires plus 1 per slave that shares this high speed bus.
A high speed SPI link would typically talk to FPGA boards as the slaves and should give me a bus that is well north of a megabyte per second transfer rate. Since the memory of the 1131 has a peak transfer rate of 277,777 words per second if it did nothing but cycle steal transfers, That means the high speed SPI link can fully saturate the 1131.
For Arduino hosted devices, I would only be able to safely operate at about 2MHz and may shift down to 1MHz to allow the processor time to do other work, since the boards are typically 16Mhz processors which would have trouble keeping up with the incoming data at higher speeds.
The Arduino libraries only offer master mode, but examples exists of ways to force the Arduino to act as an SPI slave. As slaves, this would require 3 wires plus 1 per slave for the medium speed bus to Arduinos. Raspberry Pi is an alternative to the Arduino, if I can set up an SPI slave link.
The Arduino is limited in its performance, although I could move to a faster ATMEL processor via the Chipkit Uno32 or similar variant of the Arduino. Still, none of them could keep up with the high speed SPI bus. Having a medium speed bus at 1MHz is good enough to provide about 50KB/s of data movement, which would still drive the 1130 to almost 10% of its memory bandwidth.
If necessary, I could also host slower speed links but those would demand 3+X wires for X slaves at the lower speed. I believe it better to spray out slow speed SPI from one of the slave FPGA boards connected by the 48Mhz link, rather than implement them on the main board. The only reason to build a low speed link would be specific peripherals or very long distances where noise might impair a faster link.
I will tentatively reserve space for 7 high speed and 7 medium speed slaves, making use of the 20 signals that are easily reached on the board. Many of these are currently used with my diagnostic lights, buttons and the current plotter connections. I will need to grab four wires to test one of the links, these will use the four lines I temporarily use for pushbutton inputs. That still leaves the sixteen lines currently used for LEDs and the plotter.
The initial assignments for medium speed are:
- Paper tape read and punch handler board
- Documation card reader handler board
- HP line printer handler board
- Plotter handler board
- Selectric based 2741 replica APL terminal
The assignments for high speed links are:
- DEC RK05 disk drive 1 handler board
- DEC RK05 disk drive 2 handler board
- DEC RK05 disk drive 3 handler board
- Pertec '2310' disk drive handler board
- IBM 9 track tape drive handler board
No comments:
Post a Comment