I have not downloaded or installed mingw (yet) though, but Multics seems to run fine without it.
I have used many other emulators (SIMH, Hercules, WinVice), and with SIMH / Hercules in particular I've been interested in the "bare metal" (emulation of course) operation of the "machine", i.e. without any O.S.
So similarly, I've tried to run some the tests from svn repo for dps8.
I.e. "load xxx.oct"
g 0
Or where there are "loader do files" (like Test3), I have run : "do Test3"
g (when not present in the 'do' file).
The few I've tried so far, that should generate output to the console, are in fact not generating any output to the console, nor to any debug file that I set with "set debug debug-file.txt"
The debug file does show that "Illegal Procedure faults ARE generated" e.g. :
------------ debug-out.txt ------------
Debug output to "debug-t3" at Fri Dec 15 11:07:54 2017
DPS8M simulator V4.0-0 Beta git commit id: c420925a
Got <sim stop=""></sim>
attach -r tape0 12.6eMULTICS.tap
set tape0 rewind
; attach disk0 root.dsk
fnpload Devices.txt
fnpserverport 6180
; set debug stdout
set debug -N -P debug-new
clrautoinput
autoinput rpv a11 ipc 3381 0a\n
autoinput bce\n
autoinput \z
set opcon config=attn_hack=1
; boot iom0 <<<< I tried this enabled, then CTR-E to continue
do t3 ; copy of test3
------------- t3 --------------
dep dsbr.u 1
dep dsbr.addr 1000
dep ppr.ic 0
dep ppr.prr 0
dep ppr.psr 0
dep ppr.p 1
load t3.oct
;set debug stderr
set debug -N -P debug-t3
set cpu debug=trace;regdumpaqi;regdumpflt;regdumpidx
g 0
From reading dps8_ins.c, I see that an 'emcal 1' "instruction" triggered by an "illegal" 420 code.
If I start dps8, then do the following, should I see some output on the console ? :
echo TRA 050
dep 0 000050710000
echo EMCALL 1
dep 50 000001420400
echo NOP
dep 51 011000
echo 'Z' into A reg
dep a
dep a 030124150151 ;msgHello: acc "This is TestFP ...^g^g\r\n"
break 51
g 0
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The goal of the emualtor project has been to revive Multics, so 'bare metal' support has been minimal, if not non-existent.
The "load" code was used early on to test the bare metal, but has not been maintained for a long time; no knows if it still works.
"Writing to the console" is a non-trivial task for bare-metal programming; you would need to construct a channel control program for execution by the FNP emulation, pass it to the FNP with a CIOC instruction, and install some kind of rudimentary interrupt handling code to the catch the I/O complete interrupt. To work around this, a few unused intruction opcodes were repurposed to do simple output, allowing small tests to be written in assembly and run on the "bare metal".
Once the emulator got to the point where Multics was booting (at least partially), the need for those support instructions ceased, and were the code for them was surrounded by '#ifdef EMULATOR_ONLY" clauses; the prebuilt executables do not have that code enabled; thus the example test code has no way to display the test results.
I would guess that no additional ".ini" files should be need to run bare metal, but I would have to experiment to be sure.
The is a cross-assembler available in the dps8m_devel_tools repository ([https://sourceforge.net/p/dps8m/dps8m_devel_tools/ci/master/tree/)
under src/as8+; it should be portable C, but I don't know if it has ever been used under Windows.
Under 'tests' in that repository are examples of .as8 files that can be assembled into .oct files with the as8+ assembler. Under tests/Unit-Tests is the collection of regression tests that we were using to test emulator changes; DoTests is the script that runs them; its last modification date is 2014-08-16, so it
s been a long time since tests have seen the light of day.
I just looked at the source; it looks like the examine and deposit to registers code is still in place (it's gone in the bleeding-edge code). It should be possible to assemble and run programs and look at the registers to see results.
One of the odd architectural features of the CPU is no halt instruction. I think that if you use the simh command "set cpu config=dis_enable=disable", the DIS instruction will cause a CPU halt, but again I haven't tested that code for years.
Hope that helps,
-- Charles
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have uploaded a cross-built as8+.exe which should run under Windows, but is completely untested.... [https://sourceforge.net/projects/dps8m/files/as8%2B.exe]
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) Re as8+, I also have a Linux box, and was able to easily build as8+.
But that only allowed me to generate the same xx.oct files from xx.as8 files that were already in the test directory.
The Linux binary for dps8 I downloaded from the wiki, seems to have the same disabled '#ifdef EMULATOR_ONLY" (illegal / support instructions).
And re: the "support instructions" vs the "real" I/O. :
When I read / discovered the "emcall" "instruction", I was curious if that was how the real hardware did I/O (through "fault vectors / illegal instructions"). Apparently, as you've said, that was only temporary / a "simulator utility"
I'm more interested in the "real" way, that the "hardware" is doing the I/O.
Thanks to your "buzzword" of the CIOC instruction, I've found a few more documents :
The best example of bare-metal code is in src/dps8/listings/MR12_5/bootload_tape_label.list
It is the equivalent of the MBR; it is the first record of the boot tape.
Booting is particularily arcane process; it is done by the IOM rather then the CPU.
When the CPU is powered on, it starts running immediatly, executing the instruction at address 0, which will zeros, an illegal instruction, causing a fault. The CPU loads the fault pair at the illegal instruction fault vector and tries to execute them. Again, they are zeros, causing an illegal instruction fault; but the case of a fault while executing a fault pair is to esculate to a 'trouble fault'. The CPU loads the fault pair from the trouble fault vector, zeros again, causing a trouble fault..... So the CPU churns away at that.
The operator pushes the BOOT button on the IOM. The IOM loads a channel control program (a couple of words) that instructs a tape drive to read a record into memory starting at a specified location, and then fakes a CIOC instruction. The IOM reads the channel control program, forwards the read commaand to the tape controller; and interrupts the CPU when the read is done.
The tape record (bootload_tape_label) has been loaded into memory locations such that it has written a valid fault pair into the interrupt vector; the interrupted CPU loads the fault pair and executes it, they transfer to the start of the boot code.
The early boot code writes to the console in non-interrupt style; see src/dps8/listings/MR12_5/bootload_console.list
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The FNP is an 18-bit computer, more or less a DPS8 sawn in half. They are used to manage serial communications (but not the console). We emulate the FNPs at an API level (write (), read ()) instead of instruction level emulation. (src/dps8/dps8_fnp2.c, fnpuv.c, fnptelnet.c).
We don't have any documentation on the console device; it's emulation is based on the reading the Multics source code to see how Multics thinks it works, and tweaking it until it seemed to work right.
src/dps8/dps8_console.c
Multics supports up to 8 FNPs; each FNP supports up to 96 serial lines, so 768 lines....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I remembered that at one point I had a console output unit test...
Look at dps8m_devel_tools/Tests/Unit-Tests/TestConsole.as8
Edit it and comment out all of the 'emcall' lines; after the last one (emcall 18) add a line:
dis *
./as8+ TestConsole.as8 -o TestConsole.oct
./dps8
simh> load TestConsole.oct
simh> set cpu config=dis_enable=disable
simh> g 0
The code cheats: it does not wait for I/O to complete. It gets away with this because the emulator does not correctly implement I/O timing; all I/O is completed before the CIOC instructions finishes.
In real life, the code should either loop on the status word, or on a flag set by an interrupt handler.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I have downloaded the mingw dps8.exe (git b7a50ffc)),from https://sourceforge.net/projects/dps8m/files/Release%201.0/MinGW_dps8.zip and have it working with the Multics QuickStart_MR12.6f on Windows 7.
I have not downloaded or installed mingw (yet) though, but Multics seems to run fine without it.
I have used many other emulators (SIMH, Hercules, WinVice), and with SIMH / Hercules in particular I've been interested in the "bare metal" (emulation of course) operation of the "machine", i.e. without any O.S.
So similarly, I've tried to run some the tests from svn repo for dps8.
I.e. "load xxx.oct"
g 0
Or where there are "loader do files" (like Test3), I have run : "do Test3"
g (when not present in the 'do' file).
The few I've tried so far, that should generate output to the console, are in fact not generating any output to the console, nor to any debug file that I set with "set debug debug-file.txt"
The debug file does show that "Illegal Procedure faults ARE generated" e.g. :
------------ debug-out.txt ------------
Debug output to "debug-t3" at Fri Dec 15 11:07:54 2017
DPS8M simulator V4.0-0 Beta git commit id: c420925a
Got <sim stop=""></sim>
simCycles = 61030584
cpuCycles = 30515292
Illegal procedure faults = 517207
Simulation stop, IC: 003537 (002524457000)
Is there some other setup / ini files etc, that I need to load to run the tests ?
I tried using the ini file from https://sourceforge.net/p/dps8m/mailman/message/35691270/
but still no output
attach -r tape0 12.6eMULTICS.tap
set tape0 rewind
; attach disk0 root.dsk
fnpload Devices.txt
fnpserverport 6180
; set debug stdout
set debug -N -P debug-new
clrautoinput
autoinput rpv a11 ipc 3381 0a\n
autoinput bce\n
autoinput \z
set opcon config=attn_hack=1
; boot iom0 <<<< I tried this enabled, then CTR-E to continue
do t3 ; copy of test3
------------- t3 --------------
dep dsbr.u 1
dep dsbr.addr 1000
dep ppr.ic 0
dep ppr.prr 0
dep ppr.psr 0
dep ppr.p 1
load t3.oct
;set debug stderr
set debug -N -P debug-t3
set cpu debug=trace;regdumpaqi;regdumpflt;regdumpidx
g 0
From reading dps8_ins.c, I see that an 'emcal 1' "instruction" triggered by an "illegal" 420 code.
If I start dps8, then do the following, should I see some output on the console ? :
echo TRA 050
dep 0 000050710000
echo EMCALL 1
dep 50 000001420400
echo NOP
dep 51 011000
echo 'Z' into A reg
dep a
dep a 030124150151 ;msgHello: acc "This is TestFP ...^g^g\r\n"
break 51
g 0
Mike
The goal of the emualtor project has been to revive Multics, so 'bare metal' support has been minimal, if not non-existent.
The "load" code was used early on to test the bare metal, but has not been maintained for a long time; no knows if it still works.
"Writing to the console" is a non-trivial task for bare-metal programming; you would need to construct a channel control program for execution by the FNP emulation, pass it to the FNP with a CIOC instruction, and install some kind of rudimentary interrupt handling code to the catch the I/O complete interrupt. To work around this, a few unused intruction opcodes were repurposed to do simple output, allowing small tests to be written in assembly and run on the "bare metal".
Once the emulator got to the point where Multics was booting (at least partially), the need for those support instructions ceased, and were the code for them was surrounded by '#ifdef EMULATOR_ONLY" clauses; the prebuilt executables do not have that code enabled; thus the example test code has no way to display the test results.
I would guess that no additional ".ini" files should be need to run bare metal, but I would have to experiment to be sure.
The is a cross-assembler available in the dps8m_devel_tools repository ([https://sourceforge.net/p/dps8m/dps8m_devel_tools/ci/master/tree/)
under src/as8+; it should be portable C, but I don't know if it has ever been used under Windows.
Under 'tests' in that repository are examples of .as8 files that can be assembled into .oct files with the as8+ assembler. Under tests/Unit-Tests is the collection of regression tests that we were using to test emulator changes; DoTests is the script that runs them; its last modification date is 2014-08-16, so it
s been a long time since tests have seen the light of day.
I just looked at the source; it looks like the examine and deposit to registers code is still in place (it's gone in the bleeding-edge code). It should be possible to assemble and run programs and look at the registers to see results.
One of the odd architectural features of the CPU is no halt instruction. I think that if you use the simh command "set cpu config=dis_enable=disable", the DIS instruction will cause a CPU halt, but again I haven't tested that code for years.
Hope that helps,
-- Charles
I tried to cross-build as8+; it is not as portable as I assumed. Working on it....
I have uploaded a cross-built as8+.exe which should run under Windows, but is completely untested....
[https://sourceforge.net/projects/dps8m/files/as8%2B.exe]
Tested .. seems to be working.
Thanks
Hi Charles,
Thanks for that informative post !
1) Re as8+, I also have a Linux box, and was able to easily build as8+.
But that only allowed me to generate the same xx.oct files from xx.as8 files that were already in the test directory.
The Linux binary for dps8 I downloaded from the wiki, seems to have the same disabled '#ifdef EMULATOR_ONLY" (illegal / support instructions).
And re: the "support instructions" vs the "real" I/O. :
When I read / discovered the "emcall" "instruction", I was curious if that was how the real hardware did I/O (through "fault vectors / illegal instructions"). Apparently, as you've said, that was only temporary / a "simulator utility"
I'm more interested in the "real" way, that the "hardware" is doing the I/O.
Thanks to your "buzzword" of the CIOC instruction, I've found a few more documents :
http://multicians.org/mx-net.html has a brief discussion of the " memory mailbox " and CIOC / interrupt.
That article has links to the Multics Programmers Manual(s) series of PDF's ,
Reading through dc88-01.790300.DC88-01.dn6600-fnp.88.pdf, is talking about the Control Console Adapter and a PCW (Peripheral Control Word)
And I see in dps8_console.c / con_cmd where the PCW is getting executed.
Now reading lots of PDFS's, searching source code for CIOC / channel program examples.
Mike
Last edit: mstram2 2017-12-18
The manual for I/O is '43A239854 6000B Engineering Product Specification, Part 1_ 6000B I_O Multiplexer'
http://www.bitsavers.org/pdf/honeywell/series6000/periph/43A239854_600B_IOM_Spec_Jul75.pdf
The best example of bare-metal code is in src/dps8/listings/MR12_5/bootload_tape_label.list
It is the equivalent of the MBR; it is the first record of the boot tape.
Booting is particularily arcane process; it is done by the IOM rather then the CPU.
When the CPU is powered on, it starts running immediatly, executing the instruction at address 0, which will zeros, an illegal instruction, causing a fault. The CPU loads the fault pair at the illegal instruction fault vector and tries to execute them. Again, they are zeros, causing an illegal instruction fault; but the case of a fault while executing a fault pair is to esculate to a 'trouble fault'. The CPU loads the fault pair from the trouble fault vector, zeros again, causing a trouble fault..... So the CPU churns away at that.
The operator pushes the BOOT button on the IOM. The IOM loads a channel control program (a couple of words) that instructs a tape drive to read a record into memory starting at a specified location, and then fakes a CIOC instruction. The IOM reads the channel control program, forwards the read commaand to the tape controller; and interrupts the CPU when the read is done.
The tape record (bootload_tape_label) has been loaded into memory locations such that it has written a valid fault pair into the interrupt vector; the interrupted CPU loads the fault pair and executes it, they transfer to the start of the boot code.
The early boot code writes to the console in non-interrupt style; see src/dps8/listings/MR12_5/bootload_console.list
re DC88 FNP.
The FNP is an 18-bit computer, more or less a DPS8 sawn in half. They are used to manage serial communications (but not the console). We emulate the FNPs at an API level (write (), read ()) instead of instruction level emulation. (src/dps8/dps8_fnp2.c, fnpuv.c, fnptelnet.c).
We don't have any documentation on the console device; it's emulation is based on the reading the Multics source code to see how Multics thinks it works, and tweaking it until it seemed to work right.
src/dps8/dps8_console.c
Multics supports up to 8 FNPs; each FNP supports up to 96 serial lines, so 768 lines....
I remembered that at one point I had a console output unit test...
Look at dps8m_devel_tools/Tests/Unit-Tests/TestConsole.as8
Edit it and comment out all of the 'emcall' lines; after the last one (emcall 18) add a line:
dis *
./as8+ TestConsole.as8 -o TestConsole.oct
./dps8
simh> load TestConsole.oct
simh> set cpu config=dis_enable=disable
simh> g 0
The code cheats: it does not wait for I/O to complete. It gets away with this because the emulator does not correctly implement I/O timing; all I/O is completed before the CIOC instructions finishes.
In real life, the code should either loop on the status word, or on a flag set by an interrupt handler.