• Please review our updated Terms and Rules here

Extended M847 board on pdp-8/a

MattisLind

Veteran Member
Joined
Sep 30, 2013
Messages
1,185
Location
Stockholm, Sweden
I built an extended M847 designed by Roland and tried it on my pdp-8/a. But I couldn't get it to work. It would deposit into memory, but load address didn't work for some reason.
So I attached my logic analyzer and read schematics and manuals. After a day of head scratching and reading manuals and schematics I recognised that something was wrong with the signal BRK DATA.

From a sequence diagram in the schematic I got that this line has to be high when loading the address. But I saw a low signal. I made a quick change in the design to make the BRK DATA controlled directly by the micro-controller. Then I could load address as expected!

A simple cut of the signal between U7 and U8 before it reaches pin 2 of U8 and then a wire from pin 1 of U7 to pin 16 of U1.

2ZsWpfol.jpg


Then I also had to fix the wires that was cut by the ejector holes that my board had.

While debugging the board I made a quick and dirty tool I called PDP8CONSOLE. Unfortunately there is no support in the hardware to read back data from the memory so examine is not possible. It can probably be fixed by additional chips to gate them to the MCP23017 chip.

YOpf1co.png


I also made a small fix to the original program that Roland designed so that it would work with the patch wire change I did. Now I could load all sorts of programs!

Here is a link to my fork of of the design by Roland: https://github.com/MattisLind/M847-extended-version-V1.1. I will probably continue working a bit to add support for storing bigger and more programs in the onboard 1024 kbit EEPROM memory. It should be possible to have almost all pdp-8 diagnostics in there!

Thanks Roland for this project!
 
Cool!

What do the "Trace" do? Is it single step?

With Examine of memory and possibility to fetch register values this could be a supertool!
 
I've had out-of-the-box success with both the original (short board) and 32KMem Combo board versions of Roland's card. What am I missing here?

Have you set up PDP8CONSOLE as one of the options on the boot board? Looks very useful!

 
Hello Jack!

What type of CPU do you use? My machine has a M8315 board. I think that could be the reason. It works on KK8-E but not on KK8-A.

The symtom I had when not working was that it rather than loading the CPMA it incremented the CPMA.

No. PDP8CONSOLE is a firmware on the extended M847 board. Downloaded using the Arduino environment.
 
Last edited:
Use the memory for the bootloader. Implement a possibility to receive RIM/BIN papertaper image over the serial port instead. Then you can load any software lightning fast (depending on the baudrate of the serial port) from the host machine.
 
I think I see what you mean. Probably a very good idea.

What about this: Implement a simple binary protocol with some level of robustness that allow for commands like, deposit, load address, run etc. This tool executes in the AVR chip on the extended M847 board. Then create a command line tool to be used on the PC that reads a file, either RIM or BIN, parses it and then downloads it into the pdp8 using the binary protocol.
 
I think I see what you mean. Probably a very good idea.

What about this: Implement a simple binary protocol with some level of robustness that allow for commands like, deposit, load address, run etc. This tool executes in the AVR chip on the extended M847 board. Then create a command line tool to be used on the PC that reads a file, either RIM or BIN, parses it and then downloads it into the pdp8 using the binary protocol.

How fast is the serial port?

I have a implementation that parses binary format (and RIM) that I used when I dumped paper tapes from PDP-8. I can send it if you're interested in it.
 
From a sequence diagram in the schematic I got that this line has to be high when loading the address. But I saw a low signal. I made a quick change in the design to make the BRK DATA controlled directly by the micro-controller. Then I could load address as expected!
Is the behavior of the BRK_DATA line with your modification and firmware patch compatible with both the 8/a and 8/e?
 
I don't really know because I haven't been able to test yet. My guess is that it would work on the KK8-E as well.

According to the Omnibus Spec there is a difference in how the BRK DATA signal is interpreted between the 8/e and 8/a. If this has relevance here is not that I can tell for sure.

I checked the engineering drawings and maintenance manual for the M847 board but couldn't find anything mentioning the BRK DATA CTRL line. But the scan of the schematic is really hard to read so I might be mistaken.

Maybe Roland has more input on the significance of the BRK DATA CTRL line in the 8/e?

If someone would like to test, a simple test is to pull out pin 3 of U7 so that it doesn't drive the bus and see what the difference is.
 
Last edited:
How fast is the serial port?

I have a implementation that parses binary format (and RIM) that I used when I dumped paper tapes from PDP-8. I can send it if you're interested in it.

The ATmega328 runs at 16 Mhz. At 115200 bps it gives a 3% speed error and at 230400 the error is around 8%. I have been running at 115200. But a better matching crystal would probably allow higher rates. Or use non-standard baud rates. Like 1mbps or so.

Yes, that code could indeed be useful.
 

I made a small firmware for the M847 board by Roland and a piece of client software to allow direct download of BIN and RIM files into a PDP-8. I call it PDP8Remote.

It basically remote controls the frontpanel commands issued by the M847 board. For each 12 bit word in the file it will issue a LOAD or DEPOSIT operation. Since each operation is acknowledged and there are no buffering of operations in the ATmega chip it will take a bit of a time. Especially since USB dongles are not the best for quick turnaround time operation.

But it works and can of course be improved by some buffering. The software implementation has a quite generic protocol used to shuffle data back and forth with simple checksum and timeouts. Not a big deal to increase the packet size a bit for higher efficiency.

The code is in the repo: https://github.com/MattisLind/M847-extended-version-V1.1 in the folder PDP8Remote

It is still Work In Progress so the code need some cleaning up and more thorough checking. I managed to download both a memory test and an instruction test successfully using PDP8Remote. The loading of extended address fields are not tested yet since my M8317 is not working fully.
 
Back
Top