• Please review our updated Terms and Rules here

Omnibus Peripheral Emulator

These days with solder masks we've got used to PCBs which tend not to pick up much solder residue, but on the older bare PCB material I've often found it quite difficult to scrape off thin solder smears left over from desoldering operations. Not suggesting this is a problem here of course(after all this fault appeared without any work going on so much more likely a component failure) but not uncommon during IC replacement.
 
I replaced the LM723 VR5 but left R56 that feeds transistor Q10 disconnected. I kept the same setup with the lab supply feeding current into Q10 and adjusted the power supply output to be 5.0V. The voltage on pin 2 was only about 340mV below the 5.0V from the power supply so the regulator input was consuming 0.13 mW. Much better!. I fiddled with the lab supply output to change the power supply output. The voltage on pin-6, the output of the regulator changed 6.9V to 15V. The voltage change as the power supply voltage crossed the voltage on pin-2 was very dramatic.

I reconnected R56, reinstalled the Omnibus boards that I had removed, reconnected the power supply, and adjusted the outputs to +5.0 and -15V. There is no adjustment for +15V. I was surprised to see that the front panel was dark, but then remembered that the +8V output feeds the front panel lamps and it was not connected.

I reassembled everything and was rewarded with a fully functional system. The FPGA board still works too.

Thanks for everyone's help and suggestions fixing the power supply. Now I can go back to working on the FPGA and the embedded Linus software.
 
m_thompson said:
i replaced the lm723 vr5 but left r56 that feeds transistor q10 disconnected. I kept the same setup with the lab supply feeding current into q10 and adjusted the power supply output to be 5.0v. The voltage on pin 2 was only about 340mv below the 5.0v from the power supply so the regulator input was consuming 0.13 mw. Much better!. I fiddled with the lab supply output to change the power supply output. The voltage on pin-6, the output of the regulator changed 6.9v to 15v. The voltage change as the power supply voltage crossed the voltage on pin-2 was very dramatic.


I reconnected r56, reinstalled the omnibus boards that i had removed, reconnected the power supply, and adjusted the outputs to +5.0 and -15v. There is no adjustment for +15v. I was surprised to see that the front panel was dark, but then remembered that the +8v output feeds the front panel lamps and it was not connected.

I reassembled everything and was rewarded with a fully functional system. The fpga board still works too.

Thanks for everyone's help and suggestions fixing the power supply. Now i can go back to working on the fpga and the embedded linus software.
Click to expand...


excellent!
 
I am back working on the FPGA and the embedded Linux firmware.
I have the Linux development environment setup to cross-compile for the ARM Cortex-M3 in the FPGA.
I can mount an NFS export from the Linux development system on the Embedded Linux in the FPGA. This lets me test new firmware without programming the flash for the embedded Linux system.
I can build the embedded Linux, FPGA device driver, and utilities.
I am working on the paper tape reader/punch flag and interrupt logic in the FPGA, the device driver for the logic in the FPGA, and a utility that lets me set/clear/get the state of the reader/punch flags in the FPGA.
There are two LEDs connected to the FPGA, so I am using them to indicate the state of the flags.
I need to wire the SKIP and INT RQST signals from the FPGA to the Omnibus drivers so I see if the state of the flags modifies the 8/e processor behavior correctly.
Then I need to wire up DATA[0..11] between the FPGA and the Omnibus. Once that works I will have a very fast paper tape reader.
I need to add code to the app to read data from the punch buffer and write it to a file in flash memory.
 
A lot of time spent and not much progress. I have all of the reader/punch flag and interrupt enable logic in the FPGA. There are two LEDs on the development board that I use to show the state of things in the FPGA. I just connect a wire in the FPGA schematic from the LED to the signal that I want to see, reprogram the FPGA, and test. The 6010 and 6020 IOTs will turn the interrupt enable on and off. The Initialize signal will turn interrupt enable on.

A partial schematic is here.

I added a 32-bit GPIO device to the ARM's I/O bus to use as the interface between the ARM and the FPGA logic. This has a 12-bit output for the reader data and a 12-bit input for the punch data. I also added bits that let me set/clear the flip-flops and see their state. At this point I am getting unpredictable results. I have a Linux device drive and Linux application to look at and fiddle with the GPIO bits. Sometimes an FPGA program will let me look at and set/clear the reader flag flip-flop, sometime not, and never the punch flag or the interrupt enable. Last night the FPGA programming tool decided that two of the GPIO parts needed to be clocks and made a mess. Warren suggested that the FPGA tools might be "helping" me with the design, and deleting parts or connections in the FPGA during optimization.

Tonight I will wire the set/clear inputs and the Q output from the punch flag to wires that I already have connected to the FPGA. That way I can connect a 'scope to the signals and see if they are really behaving as expected.
 
I had some interesting challenges with the FPGA tools that wasted quite a few hours. The DEC schematic for the PC8-E shows a D-Type flip-flop for the reader flag. The PRE/ input is not used, the CLR/, CLK, and D inputs, and the Q output are used. I tried to make the logic in the FPGA as close as possible to the real board. To set the flag with the Linux application, an ARM GPIO was connected to the CLK input and D was tied high. The FPGA tool thinks that the CLK input is a clock, and tries to configure the output pin of the ARM GPIO device as an 80 MHz clock. This completely messes up the Verilog that gets created for the GPIO part and then it will not work at all. I ended up just connecting GPIO pins to PRE/ and CLR/, and tying D and CLK low. The Verilog outout works OK now, and I can set, clear, and check the state of the reader and punch flags, and the interrupt enable. Tonight I will wire up the SKIP and INT RQST signals from the FPGA to the Omnibus and see if they affect the processor correctly.
 
The SKIP and INT RQST signals from the "paper tape reader" from the FPGA cause the correct response from the processor.

The AM26S10 really drives the Omnibus signals hard. The 100mA sink capability is probably overkill.

The next step is to wire up the DATA[0..11] signals and see if it will read a "paper tape". I don't need to wire all of the signals for the paper tape reader, but I will need them all for other peripherals, so I might as well wire them all now. The AM26S10 splits the receive and transmit signals on the FPGA side of the transceiver, so I will need to wire a read and a write set of DATA[0..11] signals. The paper tape punch hardware emulation is ready to test. That will be next after the paper taper reader.
 
I got an RK8-E disk controller board set, but it will need to be repaired. I have an offer of an RK05 disk drive, and have two of the PDP-8 disk packs for it. I need to find or make a set of cables to connect the drive to the controller.
 
I wired data[0..3] to see if I could transfer some bits from the ARM to the 8/e AC. I didn't see any data from the FPGA, and it took me a few minutes for me to realize that the paper tape reader only uses the lower 8 bits, so data[0..3] were being masked off by the Linux device driver.

I wired data[10..11], but now these bits always get copied into the AC, even if the processor is not running! I had the "S" bus driver enable signal for the 26S10 bus transceiver with the wrong polarity, so the bus driver was enabled except when the IOT was decoded. I swapped an OR gate for a NOR gate in the FPGA and now the bus driver enable signal has the correct polarity. That is one of the really nice things about using an FPGA for this project. I can just change the schematic and reprogram the FPGA to get different behavior. No wiring changes needed!

One of the menu items in the test software running on the ARM in the FPGA will let me write arbitrary data to the paper tape reader buffer. Now I can transfer data from the ARM to the AC in the PDP-8/e. I need to wire data[4..9] so I can test the remaining data bits. A project for tonight.

Another option in the test software lets me send a paper tape image file to the PDP-8/e. This worked great with the Posibus Peripheral Emulator, but the ARM is not waiting for the 8/e to read a character before sending another to the paper tape reader buffer. The Linux application writes a character to the /dev/pc8 device, the device driver writes the character to the paper tape reader buffer and sets the flag, the device driver gets another character from the Linux application, and then blocks the I/O and goes to sleep. This causes the Linux application to go to sleep too. When the reader flag is cleared it generates and ARM interrupt. The device driver handles the interrupt, and wakes up the reader driver, the driver writes another character to the paper tape reader buffer and sets the flag again. This double buffering decouples the paper tape reader buffer from reading the paper tape image file in flash memory.

This could be a hardware or a device driver problem. I will debug this after I test the rest of the data bits.
 
The problem with the interrupt/sleep/get character was an easy fix. I recycled code from the Posibus Peripheral Emulator, and had hard coded the GPIO bit location for the reader flag state. I changed the hardware design in the FPGA, so the code was looking at the wrong GPIO bit and was not sleeping. I changed the code so that it uses the same "defines" that tell the rest of the code which GPIO bits to use.

I wired the remaining data[4..9] data bits. The paper tape reader code was masking off all but the lower 7 bits. I am not sure why I did that in the Posibus Peripheral Emulator, so I changed the code to mask off all but the lower 8 bits.

If I manually put a single character in the reader buffer and set the reader flag, the 8/e will see the flag go on, skip, OR the buffer into the AC, and clear the flag. All of that works perfectly.

I tried to read a complete MAINDEC file in BIN format with the high-speed binary loader, but all it put in memory was zeros. This should be easy to debug.

I connected the 'scope to the data bus enable signal from the FPGA to see how fast the 8/e was reading characters from the emulator. It was running about 4,700 cps. At that rate, FOCAL would load in about 2 seconds. The reader flag was not on for very long before the 8/e read a character and turned it off. That means that I need to improve the code in the Linux device driver and the Linux app to improve the emulator performance.

Update...

I forgot to implement the C1 signal, so the transfers to the AC are not working correctly. That is just an FPGA programming fix, plus adding two wires to the bus interface logic.

I am looking at the IOT implementation in the FPGA again. The PC8-E schematic, and the behavior description in the Maintenance Manual look a little different. I will look a the RIM and BIN loader source and the OS/8 handler source to see what they expect for behavior.
 
Last edited:
Wiring the C1 signal, and fixing a logic issue in the IOT decoding in the FPGA fixed the problem with the emulated paper tape reader.

The BIN loader loaded the 5,449 byte MAINDEC-8E-D0CC Adder test in about 2 seconds. I put a 'scope on the INTERNAL IO signal and the C1 signal so I could see the ratio of RSF to RRB-RFC instructions. It is a little embarrassing to see lots of RSF instructions and only see the RRB-RFC instruction once every 150 us. The 'scope says that the frequency of the RSF instructions is 416 kHz, and the frequency of the RRB-RFC instructions is 4,762 kHz. I really need to clean up the device driver code, and improve the app that reads a paper tape image from flash and writes it to the Linux paper tape reader device.
 
I installed the M8340 EAE board so I could determine why interrupts don't work with it installed. I pulled the M8340 and ran MAINDEC-8E-D0AB-D Instruction Test 1 to make sure that everything else was OK. I was surprised to see that it failed with an unexpected interrupt after executing a CAF instruction. The front panel showed that there was an active interrupt, and it didn't take long to see that it came from the paper tape reader/punch emulator. The app running under Linux on the FPGA said that the reader flag was on, as well as the LED that was connected for debugging. A quick check of the PC8-E schematics showed that the INITIALIZE signal cleared both the reader and punch flags. I forgot to add that feature in the FPGA logic. It took just a few minutes to replace the 4-input OR gates for flag clearing with 5-input OR gates so I could include the INITIALIZE signal in flag clearing duties. Instruction Test 1 runs OK now, so I can go back to the M8340.

I really like working with FPGAs. No rewiring, no added chips, no soldering, just fix the schematic and reprogram the FPGA.
 
MattisLind said:
What design software are you using?
Click to expand...

Oops, that probably wasn't what you asked.

I am using DesignSpark for the adapter board schematic and prototype board layout. Eventually I will use this to make a real PCB.
I am using MicroSemi Libero SoC for the FPGA design and programming. Its free and made to work with the SmartFusion SoC.
The Linux port and SoC board came from Emcraft. http://www.emcraft.com/products/133

I could port SimH to the ARm Cortex-M3 in the FPGA, and just emulate the 8/e, but that isn't the point. ;-)
 
You must log in or register to reply here.
Back
Top