A simulator is a nice tool to illustrate the possibilities of a computer design. But as a computer, also a computer simulator needs programs to do something meaningful. For the P800 there still exists some documentation to start building a simulator, but software is limited to only a few listings at this moment (at least that is what I still have). So when building a simulator for an antique computer without having any standard software for that computer available anymore, some additional tooling must be added to make test programs for the simulator. In an attempt to create substance in the context of the objective of these pages, I started to build a P860 simulator. To fill the gap of lacking software and being able to make test programs for the simulator, also a cross assembler and linking loader are built, to obtain a workable solution.

The three programs are at a stage that they can be shared with other, hopefully interested people. I would call the programs in a prototype state, not only because the concise documentation on which they are based, but also because they are all three written in Perl. Not every thing is clear and well defined, so it must be easy to make changes and to test alternatives. Perl provides an excellent prototyping environment, while it still results in a simulator with an acceptable performance (the simulator on my PC is only 2 to 3 times slower than the original P860). At a later stage the simulator can still be converted to C, e.g. to run in the SIMH frame. The Perl based simulator is based already on some of the SIMH concepts (e.g. the event mechanism; also the control commands mirror part of the SCP functionality).

The P855/P860 simulator and its tooling can be downloaded from the P855-P860 directory. A few demo programs written in assembly language are also available in this directory. The remaining part of this page explains some more detail about this simulation program and its tooling. The program sources provide next levels of detail.

Note: Windows users who want to display the listings (.lst files) directly in Internet Explorer, have to associate the .lst file type to Wordpad (File Explorer => Extra/Tools => Folder Options => File Types). 

For another member of the P800 minicomputer family, the P856, the situation is different. For this machine some of its original software became available. The P856 is for 95% compatible with the P855/P860, but certainly system software, like an operating system generated for the P856, does not run on a P855. So in parallel with the P855/P860 simulator a P856 simulator is made. This simulator can be operated now with at least part of the original software being available. For some other software, investigation about what it is and testing is still required. Published items can be found in the P856 directory and details can be found on the P856 page. Being able to run original software makes the P856 simulator of more interest at this moment than the P855/P860 simulator. For the P855/P860 simulator, compatibility with original software must still be proven

As mentioned above, the simulator is currently implemented in Perl as a P855/P860 simulator with 32k words. Added to the default Perl installation are three CPAN modules:

• Term::ReadKey (for TTY keyboard input handling)
• Time::HiRes (for Real Time Clock synchronization)
• IO::Handle (for TTY output handling; autoflush)

The simulator (as well as the other programs) are developed and tested under Linux, but (should) run under Windows as well in case a proper Perl is installed (since version 0.6 the simulator is adapted for Windows and runs with ActiveState Perl version 5.8.8, build 822).

The following devices are currently are supported (version 0.91):

• TTY - keyboard/printer
• High speed paper tape reader (PTR) - Digitronics 25540EP, 333/600 cps
• High speed paper tape punch (PTP) - Facit 4070, 75 cps
• Real time clock (RTC) - 10 Hz clock
• Line printer (LPT) - Data products, 132col, 245/670 lpm
• Card Reader (CRD) - Documation M200, 285 cpm
• Moving Head Disk (2 spindles MD0, MD1) - Philips X1210, 2,7 Mb per spindle

Limitations:

• The memory protection option is not implemented, so there is no "user mode" (LKM does not switch to system mode, and the SMD operation acts as a no operation. The cpu is always in system mode; no checking on illegal use of registers and instructions in user mode)
• Only the high speed arithmetic option and the multiplex channels are implemented (no DMA channels)

Usage: p860-xx.pl [<do-script-name>]

• run [<address>] (includes reset-all = reset cpu+tty+rtc+ptr+ptp+lpt+crd+md0+md1)
• go [<address>] (like run, but no reset)
• continue|c
• step|s [<nbr of instructions to execute>] (no argument = execute 1 instruction)
• do <filename> (filename is name of the do-script)
• breakpoint|bp set|s <breakpoint address>
• breakpoint|bp clear|c <breakpoint address>|all|a
• breakpoint|bp print|p
• examine|ex <register>
• examine|ex m <address> (interactively shows content of <address>, <address>+2, .. until s is replied)
• deposit|de <register> [<16 bit hex value>] (in case no content specified, then it is requested from the keyboard)
• deposit|de m <address> (interactively changes content of <address>, <address>+2, .. until s is replied)
• deposit|de m <address> <16 bit value>
• reset [cpu|tty|rtc|ptr|ptp|lpt|crd|md0|md1|mem|power] (no argument = reset-all; reset power = reset-all + reset-mem + P=0)
• trace [on|off] (no argument = on)
• load <filename>.abs (load an absolute (8+8 format) load module with an .abs extension)
• load <filename>.rel <address> (load a relocatable executable with a .rel extension at <address>)
• boot ptr [h|r] (h=halt, r=run after load; no argument = run, starting at 1st address)
• boot md0 [p] (ipl's from md0; p requests the in the ipl embedded papertape bootstrap)
• attach|att ptr|ptp|lpt|crd|md0|md1 <filename>
• detach|det ptr|ptp|lpt|crd|md0|md1
• state [cpu|tty|rtc|ptr|ptp|lpt|crd|md0|md1] (no argument = state cpu+tty+rtc+ptr+ptp+lpt+md0+md1)
• queue|q (show content of the event queue)
• echo <string> (character string is displayed on console)
• dump|du <ba> <ea> (dump in hex a memory area on screen)
• console 64|128 (select ASCII 64 or 128 character set for the console/tty)
• exit

| means logical OR
[..] means OPTIONAL argument
<address> is hexadecimal number 0 .. FFFF
<register> is P,A0 .. A15
<string> is a double quoted character string and may include codes like \n
The key combination CntrE stops the emulation
The key combination CntrP simulates a Panel interrupt
do-scripts do not support arguments

Disk organization and support is further explained on the page X1210 moving head disk support

The assembler operates on the PC as a cross assembler for the P855/P860 (and for the P856 as well). The generated object programs (extension .obj) are relocatable by default and must be linked, possibly with other modules, with p8ldr, which produces an absolute binary (8+8 paper tape format with an .abs extension) or a relocatable binary in disk load module format (.rel extension when punched on "papertape"). The binary can then be loaded as an absolute or relocatable load module into a P800 simulator for execution. Loading into the simulator can be done with the simulator 'load' command, or (for the absolute binary) by booting the simulated P800 with that binary from the papertape reader.

1. If the source program has the .s.. extension, the 1st pass performs tab expansion; the .s.. file is expanded into a text file (with .txt extension) with the statement fields in fixed columns. In case the source file provided to the assembler already has the .txt extension, the source is assumed to be in the fixed column format and the 1st pass is skipped.
2. This pass scans the source file with the .txt extension and builds a symbol table for the module.
3. The last pass scans the .txt source file again, checks the syntax of each statement and generates code. Syntax checking and code generation is table driven; both the syntax is scanned and the code is generated with the help of a template available for each operation in the table. Additional operations (e.g. of the later P800 models) can easily added to the assembler by adding templates for those operations in the table.

1. No conditional assembly
2. No FORM, XFORM, STAB, LIST and NLIST pseudo operations.
3. Only assembles a single module (argument 1), so does not assemble a file with multiple segments separated by :EOS, or multiple files referenced by multiple arguments.
4. DATA pseudo operation can only generate a single 16 bit data word or (since version 0.4) a single character string of 1..n characters (in case more sequential data words or character strings are required, then multiple DATA statements must be written).
5. Character strings can only be 1 or 2 characters long. (this restriction is removed in version 0.4 and with that, character string handling is equivalent with the original P800 assembler)
6. ENTRY and EXTRN pseudo operations can have only a single name in the operand field. (in case multiple entry points or externals are required in a module, the multiple ENTRY/EXTRN statements must be written).
7. Register names are not in the symbol table; so a name can not be equated with one of the predefined register names P,A0..A15. (this restriction is removed in since version 0.4 and with that, this feature is equivalent now with the original P800 assembler).

Links an object program generated by the cross assembler and punches an absolute binary tape in 8+8 paper tape format. This linker operates as the cross assembler on the PC and can only be used to link/load object output of the p8asm cross assembler, which is not object code format compatible with the output of the original P800 assembler. The linker output is an absolute binary tape in 8+8 format (compatible with the original absolute format), which can be loaded into the P800 simulator with the 'load' control command or by starting the paper tape bootstrap of the P800 simulator. Added since version 0.5 is the option to generate a relocatable load module in the original disk load module format, but punched on a papertape (.rel extension).

Added since version 0.5 are the possibilities to:
- load multiple modules (.obj or .lib) from the command line;
- link modules from object libraries.

1. Link object modules provided to p8ldr as argument 2,3,..n. Currently only the main object module is provided as argument 1. The linker currently asks via the console for a next module as long as externals are left to be resolved.
   <<== restriction removed since version 0.7
2. Currently only an absolute load module is generated. A linker extension will be able to generate a relocatable load module as an alternative (extension .rel).
   <<== restriction removed since version 0.5
3. No multi segment object files are supported (object libraries) yet as linker input. When implemented as an extension, the linker will have the possibility to select object modules for linking with entry points for which externals have to be resolved.
   <<== restriction removed since version 0.7

Usage: p8ldr.pl -[a|r] mainobjectprogram.obj [mod.obj|library.lib]...

Option -a for the generation of an absolute, -r for a relocatable load module (default option is absolute)
Libraries must have a .lib extension; when a library is linked, only object modules are selected from the library with entry points for which externals exists. When all arguments on the command line are processed, additional modules will be requested interactively, as long as externals are to be resolved.

Object Libraries
These libraries are composed of multiple assembled modules. Libraries are prepared with the utility makelib.pl and this utility uses the file <libname>.lib.spec to compose the library <libname>.lib from the object modules. <libname>.lib.spec contains the names of the object modules to include in the library and also defines the order in which the modules must be included in the library. This order must be in such a way that a module with one or more entry points must be after all modules in the library that use those entry points as externals. The file <libname>.lib.spec is generated by the utility makelibspec.pl and uses for this generation the file <libname>.lib.def. The <libname>.lib.def file must contain all the names of the object modules to include in the library, but these names can be in any order in this file.
makelib.pl, provided with the file <libname>.lib.def, calls makelibspec.pl to generate <libname>.lib.spec and after that composes the requested library.

Usage: makelib.pl [-sd=<sourcedir>] [-td=<targetdir>] <libname>
output: <libname>.lib
uses: the file <libname>.lib.def to compose the library (and makelibspec.pl to produce <libname>.lib.spec)

The .def file is assumed in the <sourcedir>; the .spec file will also be stored in <sourcedir>. The object modules for the library are assumed to be in the <targetdir> and the resulting library will also be stored in the <targetdir>. When either the <sourcedir> or <targetdir> are not specified, the current directory is assumed. Makelibspec.pl can be used standalone as well, in the same way as makelib.pl, and only generates the .lib.spec file from the .lib.def file.

Example: makelib.pl -sd=bio -td=bio/object sio

This example composes the small example object library sio.lib, which is included in the archive.
It works under the conditions that:
- directory bio (and directory bio/object) are subdirectories of the working directory,
- both makelib.pl and makelibspec.pl are in the working directory,
- the source of the bio modules and bio.lib.def are in subdirectory bio,
- the translated object modules are in the directory bio/object.
The produced object library is stored in the directory bio/object.

Two demo/test programs are available in the P800 directory: a record oriented text editor (ledit) and a real time clock test program (testrtc). Originally the editor was written for the DDP-516 somewhere back in 1968. In 1971 I rewrote it for the P860 as an exercise to learn the P860 instruction set. The editor was written for use with one of the P860 monitors. Lacking a monitor now, it is rewritten again as a stand alone program. With the editor many of the simulators' functions are used, and with that tested. All currently implemented devices have a function within this program, except the real time clock. The second demo program uses the real time clock mechanism in combination with the interrupt system.