Part 3 - Loading and Running Binaries
Any real further progress depends on loading some software into the computer. The first steps are to load and run some of DECs diagnostic programs to verify or otherwise that the machine is working properly. For this as mentioned earlier I generally use (Bray's) Terminal. A small advantage of using the 2 different terminal emulators is that one can be left set up to suit normal terminal I/O and the other to suit binary I/O when loading (paper-tape) software. The previous tests showed that the asynchronous interface was working properly (well I suppose the parity bit and some of the I/O instructions (IOTs) weren't verified but it's an lower likelihood failure). I loaded Bray's Terminal and set it to the appropriate COM port, 38400 baud, 8 data bits, no parity, 1 stop bit and no handshaking.
For the PDP8 to be able to input any software it needs to be running some sort of program already which can interrogate the input line, accept the software frame by frame, assemble it and load it into the correct memory locations. There is a standard DEC way of doing this which is that a short program called the RIM (Read In Mode) Loader is first entered by hand from the front panel and then this program is used to load another one called the Binary Loader. Both of these programs are loaded into the top 'page' (the last 128 decimal, 200 octal words) in field 0 of memory. Normally DEC programs do not use this page and this means that the loaders are always available for use, one exception being if memory test are run in this area. The RIM program comes in 2 variants - 1 each for the low- and high-speed readers and since our emulator is pretending to be the console reader we need to use the low-speed one. The low-speed RIM listing is as follows:
|7756||6032||KCC||Clear low-speed reader flag|
|7757||6031||KSF||Check for incoming character received|
|7760||5357||JMP 7757||Not there yet, wait for it|
|7761||6036||KRB||Read character into accumulator bits 4-11 and ask for next|
|7762||7106||CLL RTL||Clear the link and rotate 2 left|
|7763||7006||RTL||And another two, tape character is now in bits 0-7|
|7764||7510||SPA||Is most significant bit set (ie channel 8)?|
|7765||5357||JMP 7757||Yes - this is leader/trailer, just ignore it and loop round|
|7766||7006||RTL||No - we now have channels 6-1 in accumulator bits 0-5 and channel 7 in the link|
|7767||6031||KSF||Check for the next character received|
|7770||5367||JMP 7767||Not there yet, wait for it|
|7771||6034||KRS||And OR it into accumulator bits 4-11 (we only expect channels 6-1 to have data)|
|7772||7420||SNL||Was channel 7 set at instruction 7766?|
|7773||3776||DCA I 7776||No, this is program data, store it at the indicated address|
|7774||3376||DCA 7776||Yes, this is an address, store it at the address pointer store|
|7775||5356||JMP 7756||Return and do it again|
|7776||0000||don't care||Temporary location used to store the address pointer|
|This is the shortest practical program to perform a
low-speed reader tape load, and RIM format tapes have a very specific
format to be used with it as shown opposite.
The format uses the least significant 6
columns 6-1 of consecutive frames of tape (characters) to represent
12-bit words which may be either an address or data.
RIM can only handle program loading into a single field but by setting the Extended address appropriately it can run in any field and load into the same field or any other.
The RIM loader program is toggled into the machine from the front panel and started. The program is now waiting for data from the emulator. We click 'Send File' on the emulator and in the pop-up window select the binary of the Binary Loader program (naturally this is provided in RIM format). The Binary Loader is read into memory and since RIM format has no way of recognising the end of the input tape the machine must be HALTed manually. The Binary Loader should now be available in memory. A quick way to check that at least something has happened is to EXAM address 7777 which should contain a JMP instruction. If so, the chances are that the Binary Loader has been loaded. There is no practical way to verify this except by trying to run it. The Binary Loader uses a slightly different, slightly more compact format of input tape and can also handle tapes which load into more than one memory field.
As a by-the-way, some of DEC's and other binary tapes have more than one section separated by leader tape. The Binary Loader will halt after each section and normally the user will restart the computer to read the next tape section; however in this case since there is no handshake the emulator will continue to send the remainder of the binary file whether or not the computer is listening so the second and subsequent sections will not be loaded. Aaron Nabil has suggested a modification to the M8655 (a more modern version of the M8650) to add flow control but I have preferred to write a short program on the PC to break such binary files into separate sections for individual loading.
|The Binary Loader tape format is similar to RIM format but has the
A punch in channel 8 only is leader/trailer code
and is ignored by the program.
As a flyer I decided to try to load FOCAL, DEC's interactive algebraic programming language. Start the Binary Loader at address 7777. Use the emulator to 'Send File' the binary file for Focal. After a few seconds the computer should halt automatically and if the front panel display function switch is set to display the accumulator it should show zero. If this happens it demonstrates that the tape was loaded correctly and the tape checksum validated OK. The Focal tape I used was in two parts - the main program and the initialisation routine - so it required two separate loading sequences as above. Again rather surprisingly this worked fine so I closed the Bray's terminal and opened Hyperterminal and set it to the appropriate COM port, 38400 baud, 7 data bits, parity forced on, 1 stop bit and no handshaking.
To run Focal I loaded address 0200 (Focal's starting address) and pressed
Clear and Continue and was rewarded with the following output:
YOU HAVE SUCCESSFULLY LOADED 'FOCAL,1969' ON A PDP-8 COMPUTER.
SHALL I RETAIN EXP, LOG, ATN ?:
and waited for further instructions. This is Focal's initialisation routine which allows trading off of functionality and program space.
|maindec-8e-d0ab-pb||PDP-8/E Instruction Test 1||Tests the AND, TAD, Operate and basic MQ instructions|
|maindec-8e-d0bb-pb||PDP-8/E Instruction Test 2||Tests autoindexing, indirect addressing and DCA instructions plus basic interrupt handling etc.|
|maindec-8e-d0cc-pb||PDP-8/E Adder Tests||Tests the adder circuitry|
|maindec-8e-d0db-pb||PDP-8/E Random AND Test||Thorough test of the ADD instruction with random addresses and data|
|maindec-8e-d0eb-pb||PDP-8/E Random TAD Test||Thorough test of the TAD instruction with random addresses and data|
|maindec-8e-d0fc-pb||PDP-8/E Random ISZ Test||Thorough test of the ISZ instruction with random addresses and data|
|maindec-8e-d0gc-pb||PDP-8/E Random DCA Test||Thorough test of the DCA instruction with random addresses and data|
|maindec-8e-d0hc-pb||PDP-8/E Random JMP Test||Thorough test of the JMP instruction with random addresses|
|maindec-8e-d0ib-pb||PDP-8/E Random JMS Test||Thorough test of the JMS instruction with random addresses|
|maindec-8e-d0jc-pb||PDP-8/E Basic JMP/JMS Test||Basic test of the JMP & JMS instructions with random addresses|
|maindec-8e-d1aa-pb||PDP-8/E MM8-E 4k Memory Checkerboard||Intended to test a 4k core memory stack under worst-case access conditions|
|maindec-8e-d1bb-pb||PDP-8/E KM8-E Extended Memory Checkerboard||Similar to above but able to access up to 8 memory fields|
|maindec-8e-d1ea-pm||PDP-8/E 4k Memory Address Test||Checks for proper memory addressing on a 4k memory (N.B. RIM Format)|
|maindec-8e-d1fb-pb||PDP-8/E Extended Memory Address Test||Similar to above but able to access up to 8 memory fields|
|maindec-8e-d1gb-pb||PDP-8/E Memory Power Off/On test||Verifies that memory corruption does not occur due to (simulated) power failure|
|maindec-8e-d1ha-pb||PDP-8/E Memory and Timeshare Control Test||Tests all IOTs and function for extended memory addressing and timeshare control|
|maindec-8e-d2aa-pb||PDP-8/E Teletype Control test||Tests all IOTs and data flow associated with the teletype control KL-8/E|
Together these diagnostics virtually guarantee that the PDP-8/E is functioning faultlessly. Listings of most of them are available giving operating instructions and hints for faultfinding. There was a number of versions of the various diagnostics - generally the later the better I suppose (?) but it is not always possible to find either the latest or a corresponding version of the source or listing (though usually the most important part is the operating instructions!). Just a question of doing the best we can. I have had a number of failures where a basic instruction appeared to work properly during initial routines toggled in by hand but failed during a diagnostic. Naturally there are just too many possible combinations to be able to exhaustively test from the front panel. So far though I've been able to reduce a failing diagnostic to a simpler loop for single-stepping or probing.
The memory tests are designed to test DEC's core memory stacks and are less relevant for a home-made semiconductor memory however they will still verify correct operation, just not under the kinds of worst-case patterns which might affect RAM matrices. During testing all of the main diagnostics were passed successfully apart from some 'soft' memory errors in the core stack. Since this is likely the most difficult area to diagnose and work on I decided to take the core stack out meantime and run with only the 32k RAM card. The 32k RAM card itself initially threw up a number of memory errors which is a known problem with the design and is associated with the much higher speed of modern ICs. There are a number of solutions from using slower ICs to slugging some of the signals with small capacitors but I found that if the board was placed close to the processor cards at the front of the omnibus it ran reliably so meantime at least that is a workaround. I have a number of other core stacks to worry about later too!
Running the diagnostics occupied many hours and during this the processor suffered another couple of IC failures, 1 in the major registers board and 1 in the extended memory address board (which had not been used up until then). These were easily identified and repaired thanks to DEC's detailed documentation and circuit diagrams.
Page last updated by on 16th January 2015