PDP11 Values from MFPT

[Jerome H. Fine]

I have an interesting hardware question.

I have been looking at the results for the program RESORC.SAV in RT-11
with respect the MFPT instruction.  When the J11 chip is used, the value
is 5 and the Maintenance Register at 177750 seems to determine what the
rest of the actual hardware supports.

I thought it would also be helpful for the user to know if an emulator is being
used, either software or hardware, or if perhaps some other 3rd party hardware
CPU.  I would probably target the various 3rd party boards as far as hardware
is concerned (such as QED and Mentec).  For software emulators, I would
suggest that only the high end PDP-11 processors be supported (the DEC
CPUs which support the MFPT instruction) in order to keep things simple,
at least initially.

An incomplete list of software emulators is:
SIMH
Ersatz-11

An incomplete list of hardware boards is:
QED - more than 1?
Mentec - at least 3
and I can remember at least 2 others, but not the company names.

Right now the Logical Co. has a combined emulator called a
PDQ-1000 board which actually plugs into a Qbus which takes
only 4 slots, but includes CPU, memory and many controllers.

Thus far, the high order byte of the MFPT instruction always seems
to be zero and is currently ignored by the RESORC.SAV program.
Under SIMH and Ersatz-11, it would be trivial to use the high order
byte of the MFPT instruction to signify which software emulator is
being used.

Can anyone who has a DEC (or non-DEC) PDP-11 system easily
available determine the actual value returned by the MFPT instruction?
As far as I know:

MFPT Value      Hardware
    1                   PDP-11/44
    3                   PDP-11/24 (should be 2)
    3                   PDP-11/23
    4                   SBC-11/21
    5                   All J11 chips including 11/73, 11/83, 11/93

I assume that it would be extremely difficult, probably not worth the
effort, to modify the high order byte of the MFPT instruction at this
point for the 3rd party PDP-11  CPU boards, such as from Mentec.
Can anyone comment on this assumption?  Might there be another
way for hardware to the tell a user which 3rd party board is being
used as a PDP-11?

The other possibility is to use the Maintenance Register at 177750,
although I suspect that there might not be any more bit available.

Jerome Fine

[paramucho]

On Sun, 15 Jan 2012 09:37:21 -0500, "Jerome H. Fine"
<ever...@nospam.com> wrote:

> I have an interesting hardware question.
>
>I have been looking at the results for the program RESORC.SAV in RT-11
>with respect the MFPT instruction. When the J11 chip is used, the value
>is 5 and the Maintenance Register at 177750 seems to determine what the
>rest of the actual hardware supports.
>
>I thought it would also be helpful for the user to know if an emulator
>is being
>used, either software or hardware, or if perhaps some other 3rd party
>hardware
>CPU. I would probably target the various 3rd party boards as far as
>hardware
>is concerned (such as QED and Mentec). For software emulators, I would
>suggest that only the high end PDP-11 processors be supported (the DEC
>CPUs which support the MFPT instruction) in order to keep things simple,
>at least initially.

<snip>

Modifying the MFPT instruction is not the right way to go. CPU
software detection is a delicate business and that process should not
be interfered with directly.

In any case, an emulator is not equivalent to a processor type since
SimH and E11 support a range of PDP-11 CPUs.

Some CPU software detection is handled by examining CPU behavior. The
same process can be used to detect an emulator and to determine which
emulator is being used.

I currently use some of the behavior of the MMU SR0 and SR1 to detect
emulators in RUST. Clearly, these tests only work when E11 and SIMH
are emulating a machine with MMU, but that's their default state and
there's not much point running RUST in other configurations. Here's
some of the code:

bt$emu: call tr$cat ; capture traps

... ; skip V11 checks

mov #m$msr0,r0 ; emulator check
mov #m$msr1,r1 ;
tst (r1) ; got MMU with SR1 etc?
bcs 40$ ; nope
clr (r0)+ ; clear SR0 with increment
bis #160000,-(r0) ; overwrite and freeze

cmpb (r1),#27 ; SIMH magic number
bne 10$ ; not SIMH
btwar$ <Emulator detected: SIMH>;
br 20$ ;
;
10$: mov #340,(r0) ; SR0 = 340
cmpb (r0),#140 ; E11 magic number
bne 30$ ; not E11
btwar$ <Emulator detected: E11>; (misses some read-only bits)
;
20$: inc b$temu ; is emulator
;
30$: clr (r0) ; make them all clean again
clr (r1) ;
40$: call tr$res ; restore traps
return

There is more code which checks for my V11 emulator. That check is
done with a hacked IOT instruction.

The reason I need detection is because emulators lack standard
terminal output behavior which I use during startup to detect the
clock rate of a PDP-11 (I count the number of null characters output
to the console terminal per clock tick and use a table to determine
both the clock rate and the terminal rate). The test doesn't work on
E11, SIMH or V11.

In fact, the V11 emulator has a little API which is used to pass
information between the emulator and the system. It's used to
relinquish control so that the emulator doesn't hog all the CPU time
and for various other functions. It would be great if there was a
common API for PDP-11 emulators for this kind of thing, but I'm not
sure the motivation is there for the effort involved.






Ian

[Johnny Billquist]

I'm not entirely sure what your question is, Jerome...
But I'll make some comments anyway.

On 2012-01-15 15:37, Jerome H. Fine wrote:
> I have an interesting hardware question.
>
> I have been looking at the results for the program RESORC.SAV in RT-11
> with respect the MFPT instruction. When the J11 chip is used, the value
> is 5 and the Maintenance Register at 177750 seems to determine what the
> rest of the actual hardware supports.

Correct.

> I thought it would also be helpful for the user to know if an emulator
> is being
> used, either software or hardware, or if perhaps some other 3rd party
> hardware
> CPU. I would probably target the various 3rd party boards as far as hardware
> is concerned (such as QED and Mentec). For software emulators, I would
> suggest that only the high end PDP-11 processors be supported (the DEC
> CPUs which support the MFPT instruction) in order to keep things simple,
> at least initially.

If an emulator wants to truly emulate a specific CPU, then you cannot
just go and change the behavior of the emulator, since you will break
the basic idea behind it.
As far as different implementations goes, what is the difference between
an emulator and a "real" CPU? Both are running code to implement the
PDP-11 architecture. It's just that if the emulator is running on an x86
(for example), the microcode happens to be identical to x86 assembler,
whilst the J11 (for example) have a microcode CPU which we don't know
much about, but it still executes the microcode instructions...

> An incomplete list of software emulators is:
> SIMH
> Ersatz-11
>
> An incomplete list of hardware boards is:
> QED - more than 1?
> Mentec - at least 3
> and I can remember at least 2 others, but not the company names.

You have Strobe Data, which I'm sure you'll remember now that I mention
them.

> Right now the Logical Co. has a combined emulator called a
> PDQ-1000 board which actually plugs into a Qbus which takes
> only 4 slots, but includes CPU, memory and many controllers.

Yes... And...?

> Thus far, the high order byte of the MFPT instruction always seems
> to be zero and is currently ignored by the RESORC.SAV program.
> Under SIMH and Ersatz-11, it would be trivial to use the high order
> byte of the MFPT instruction to signify which software emulator is
> being used.

Right, except then they wouldn't truthfully emulate a J11.

And basing your design on how one application in RT-11 works seems like
an extremely bad idea.

> Can anyone who has a DEC (or non-DEC) PDP-11 system easily
> available determine the actual value returned by the MFPT instruction?
> As far as I know:
>
> MFPT Value Hardware
> 1 PDP-11/44
> 3 PDP-11/24 (should be 2)
> 3 PDP-11/23
> 4 SBC-11/21
> 5 All J11 chips including 11/73, 11/83, 11/93

That is all the values that MFPT can return. (Or rather - all the values
that were returned by any CPUs designed by DEC.)

> I assume that it would be extremely difficult, probably not worth the
> effort, to modify the high order byte of the MFPT instruction at this
> point for the 3rd party PDP-11 CPU boards, such as from Mentec.

Some Mentec boards use a J11. You can guess what they return. For the
other boards, they also seem to pretend to be J11 CPUs, which is a bit
sad, but that can't be helped.

> Can anyone comment on this assumption? Might there be another
> way for hardware to the tell a user which 3rd party board is being
> used as a PDP-11?

Please differ between which *board* is being used, as opposed to which
CPU. MFPT will only tell you which CPU is used, not which board.

> The other possibility is to use the Maintenance Register at 177750,
> although I suspect that there might not be any more bit available.

That register is specifically designed to tell you which board you have,
as opposed to MFPT, which tells which CPU.
And yes, there are bits left.
In the mainenance register, you have 4 bits allocated to system type.
(Note, not CPU type, system type.)
0 - 11/73
1 - J11-A (M11, N11)
2 - KDJ11-B (11/73, 11/83)
3 - KXJ11 (11/73)
4 - 11/53
5 - 11/93

This I collected from the system identification code in RSX. The 0 is
not explicitly stated to be an 11/73, rather, the code checks for the
values 1-5, and if none of those, it assumes it is an 11/73. I very much
doubt any DEC boards ever used any codes above 5, although you can have
up to 15.

The CPU identification code in RSX is very useful to read on how to
identify what kind of system it is.

Essentially, it goes like this:
1) Check if the SYSID registers exist
1.1) If yes, this is an 11/70 or 11/74.
1.2) Check if high bit of PDR is usable.
1.3) If yes, this is an 11/74. If no, this is an 11/70
2) Try MFPT
2.1) If it worked, we have a basic idea of system
2.2) 1 - 11/44
2.3) 3 - Possibly 11/23B or 11/24
2.3.1) Read maintenance register
2.3.2.1) If that succeded - check if bits 4-7
2.3.2.2) If 4-7 = 0 it is an XT system. Treat as unknown system.
2.3.3) Try writing to SWR
2.3.3.1) If that fails - system is an 11/23B
2.3.3.2) If that succeeds - system is an 11/24
2.4) 5 - J11 Based machine
2.4.1) Read maintenance register, look at bits 4-7
2.4.1.1) If that fails - unknown machine
2.4.1.2) 4 - 11/53
2.4.1.3) 3 - KXJ11 based 11/73
2.4.1.4) 1 - Real J11-A?
2.4.1.4.1) Check if writing to kernel PDR7 change state of W bit of
register to written.
2.4.1.4.1.1) If yes, we have an M11
2.4.1.4.2) Try MED instruction
2.4.1.4.2.1) If it works, we have an N11
2.4.1.4.3) Unknown type of CPU
2.4.1.5) 2 - KDJ11-B type. (11/83, 11/84)
2.4.1.6) 5 - KDJ11-E-type. (11/93, 11/94) (Codenamed Thunderbird apparently)
2.4.1.7) All others are called 11/73 (But the code will actually store
model as 11/9x)
3) If MFPT fails, M+ states that system must be 11/60, 11/34, 11/45,
LSI-11, 11/04, 11/05, 11/10, 11/15, 11/20 or 11/40.
3.1) Check 11/60 MED instruction
3.1.1) If that works, it is an 11/60
3.2) Check 11/34 MFPS instruction
3.2.1) If that works, it is an 11/34
3.3) Check 11/45 PIRQ register
3.3.1) If that exist, it is an 11/45
3.4) Of the rest, RSX-11M-PLUS only works on the 11/40

Also, for the machines which both have Qbus and Unibus variants, the
code then goes on to check if the machine have a Unibus map, and if so,
changes it to the Unibus version of the CPU.

All with the reservation that I might have missed something, written
something down wrong in my transcribing the code into the rules above,
and that this is obviously not enough to actually implement it, since
the details for some of these steps are rather intricate in actual
execution.

Anyway. If you have something that intends to implement a J11, it should
do the same thing a J11 does, which means MFPT should return 5. Anything
else is bad.
The maintenance register is a possible place to put something else in,
if you just want to identify your actual system differently, but once
more, if you really want to emulate an existing system, you cannot touch
that register either.

If you want some "foolproof" way of detecting that you are inside an
emulated machine, I'd say that adding a new instruction from the unused
opcodes is probably a better idea. I wouldn't expect anything to
actually try using an undefined opcode anyway, so no existing code
should be hurt by it. And your "new" code will also work on real
machines, in that you will instead get a trap if you try that instruction.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Johnny Billquist]

On 2012-01-18 07:03, paramucho wrote:
> On Sun, 15 Jan 2012 09:37:21 -0500, "Jerome H. Fine"
> <ever...@nospam.com> wrote:
>
>> I have an interesting hardware question.
>>
>> I have been looking at the results for the program RESORC.SAV in RT-11
>> with respect the MFPT instruction. When the J11 chip is used, the value
>> is 5 and the Maintenance Register at 177750 seems to determine what the
>> rest of the actual hardware supports.
>>
>> I thought it would also be helpful for the user to know if an emulator
>> is being
>> used, either software or hardware, or if perhaps some other 3rd party
>> hardware
>> CPU. I would probably target the various 3rd party boards as far as
>> hardware
>> is concerned (such as QED and Mentec). For software emulators, I would
>> suggest that only the high end PDP-11 processors be supported (the DEC
>> CPUs which support the MFPT instruction) in order to keep things simple,
>> at least initially.
> <snip>
>
> Modifying the MFPT instruction is not the right way to go. CPU
> software detection is a delicate business and that process should not
> be interfered with directly.

Totally agree.

> In any case, an emulator is not equivalent to a processor type since
> SimH and E11 support a range of PDP-11 CPUs.

Also right. And each CPU behaves differently, and the emulator needs to
follow that, or it is broken.

> Some CPU software detection is handled by examining CPU behavior. The
> same process can be used to detect an emulator and to determine which
> emulator is being used.

Right. I just posted an outline of how RSX-11M+ detects system type.
It's a combination of available information as well as CPU behavior in
very weird and possibly not documented ways.

> The reason I need detection is because emulators lack standard
> terminal output behavior which I use during startup to detect the
> clock rate of a PDP-11 (I count the number of null characters output
> to the console terminal per clock tick and use a table to determine
> both the clock rate and the terminal rate). The test doesn't work on
> E11, SIMH or V11.

Timing in general is not a good way to detect systems, but I'm sure you
know that... :-)

You could make the code work (sortof) on emulators by removing the
dependency on the serial port. Just make a spinning loop with increments
and at the next clock interrupt check how far you got.
However, as emulators don't have a fixed speed, your speed detection
will be rather odd on those machines anyway.

> In fact, the V11 emulator has a little API which is used to pass
> information between the emulator and the system. It's used to
> relinquish control so that the emulator doesn't hog all the CPU time
> and for various other functions. It would be great if there was a
> common API for PDP-11 emulators for this kind of thing, but I'm not
> sure the motivation is there for the effort involved.

Hmm. How do you use that API? Is it to tell that the emulator isn't
doing anything extremely important, and can run with less CPU right now
and be happy, or is this just an odd way of doing a WAIT?

[glen herrmannsfeldt]

In vmsnet.pdp-11 paramucho <para...@hotmail.com> wrote:
> On Sun, 15 Jan 2012 09:37:21 -0500, "Jerome H. Fine"

(snip)

>>I have been looking at the results for the program RESORC.SAV in RT-11
>>with respect the MFPT instruction. When the J11 chip is used, the value
>>is 5 and the Maintenance Register at 177750 seems to determine what the
>>rest of the actual hardware supports.

(snip)

> Modifying the MFPT instruction is not the right way to go. CPU
> software detection is a delicate business and that process should not
> be interfered with directly.

> In any case, an emulator is not equivalent to a processor type since
> SimH and E11 support a range of PDP-11 CPUs.

For VM/370, IBM's first try at software emulation (more or less)
of S/370, they use bits from STIDP, which stores the processor serial
number, to identify running under emulation. That is, of course, a
convention as the emulator can return any specified value.
(It also returns the processor model number which, again, can have
any value under emulation.)

In addition, there is one instruction, diagnose (with no assembler
mnemonic) that is defined to be system dependent. That instruction is
then used for communication between guest systems and CP (the emulator).

I don't know if there is anything equivalent for the PDP-11 to either
STIDP or diagnose.

> Some CPU software detection is handled by examining CPU behavior. The
> same process can be used to detect an emulator and to determine which
> emulator is being used.

(snip)

> In fact, the V11 emulator has a little API which is used to pass
> information between the emulator and the system. It's used to
> relinquish control so that the emulator doesn't hog all the CPU time
> and for various other functions.

This is one case where VM has it easy. S/370 processors don't use
an idle loop, but a wait state where they stop executing instructions.

As I understand it, when IBM leased processors, they had a usage meter
such that one would pay based on how much the processor was used.
The usage meter stops in the wait state.

> It would be great if there was a
> common API for PDP-11 emulators for this kind of thing, but I'm not
> sure the motivation is there for the effort involved.

-- glen

[glen herrmannsfeldt]

In vmsnet.pdp-11 Johnny Billquist <b...@softjar.se> wrote:

(snip, someone wrote)

>>> I have been looking at the results for the program RESORC.SAV in RT-11
>>> with respect the MFPT instruction. When the J11 chip is used, the value
>>> is 5 and the Maintenance Register at 177750 seems to determine what the
>>> rest of the actual hardware supports.

(snip, someone else wrote)

>> Modifying the MFPT instruction is not the right way to go. CPU
>> software detection is a delicate business and that process should not
>> be interfered with directly.

>> In any case, an emulator is not equivalent to a processor type since
>> SimH and E11 support a range of PDP-11 CPUs.

> Also right. And each CPU behaves differently, and the emulator needs to
> follow that, or it is broken.

Or, the emulator can emulate a CPU model different from any previously
built. That usually at least happens in that the emulator runs at a
different speed than any real processor.

>> Some CPU software detection is handled by examining CPU behavior. The
>> same process can be used to detect an emulator and to determine which
>> emulator is being used.

> Right. I just posted an outline of how RSX-11M+ detects system type.
> It's a combination of available information as well as CPU behavior in
> very weird and possibly not documented ways.

I have seen the rules for detecting different x86 CPUs, from 8086 and
8088 on up. Some are pretty strange, though usually documented at least
as needed for detection.

-- glen

[Johnny Billquist]

On 2012-01-18 13:41, glen herrmannsfeldt wrote:
> In vmsnet.pdp-11 paramucho<para...@hotmail.com> wrote:
>> On Sun, 15 Jan 2012 09:37:21 -0500, "Jerome H. Fine"
>
> (snip)
>>> I have been looking at the results for the program RESORC.SAV in RT-11
>>> with respect the MFPT instruction. When the J11 chip is used, the value
>>> is 5 and the Maintenance Register at 177750 seems to determine what the
>>> rest of the actual hardware supports.
>
> (snip)
>> Modifying the MFPT instruction is not the right way to go. CPU
>> software detection is a delicate business and that process should not
>> be interfered with directly.
>
>> In any case, an emulator is not equivalent to a processor type since
>> SimH and E11 support a range of PDP-11 CPUs.
>
> For VM/370, IBM's first try at software emulation (more or less)
> of S/370, they use bits from STIDP, which stores the processor serial
> number, to identify running under emulation. That is, of course, a
> convention as the emulator can return any specified value.
> (It also returns the processor model number which, again, can have
> any value under emulation.)

Unfortunately, the PDP-11 never had anything similar globally defined.
The PDP-11/70 is the only model I know which have such a thing, and it's
more or less unused by everything.

> In addition, there is one instruction, diagnose (with no assembler
> mnemonic) that is defined to be system dependent. That instruction is
> then used for communication between guest systems and CP (the emulator).

There are several instructions on various PDP-11 models for this. The
problem being that it is so undefined. Hard to use to identify the type
of system for that exact reason, since existing models sometimes also
might do things...

> I don't know if there is anything equivalent for the PDP-11 to either
> STIDP or diagnose.

Nothing that I would say is usable.

>> In fact, the V11 emulator has a little API which is used to pass
>> information between the emulator and the system. It's used to
>> relinquish control so that the emulator doesn't hog all the CPU time
>> and for various other functions.
>
> This is one case where VM has it easy. S/370 processors don't use
> an idle loop, but a wait state where they stop executing instructions.

So does a PDP-11 normally, which is why I wonder what this API is
expected to be used for.

[Bob Eager]

On Wed, 18 Jan 2012 12:41:06 +0000, glen herrmannsfeldt wrote:


> This is one case where VM has it easy. S/370 processors don't use an
> idle loop, but a wait state where they stop executing instructions.
>
> As I understand it, when IBM leased processors, they had a usage meter
> such that one would pay based on how much the processor was used. The
> usage meter stops in the wait state.

Isn't that true on the PDP-11, with WAIT? And with at least some x86 CPUs
and HLT?



--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org

*lightning protection* - a w_tom conductor

[Johnny Billquist]

On 2012-01-18 14:05, glen herrmannsfeldt wrote:
> In vmsnet.pdp-11 Johnny Billquist<b...@softjar.se> wrote:
>
> (snip, someone wrote)
>>>> I have been looking at the results for the program RESORC.SAV in RT-11
>>>> with respect the MFPT instruction. When the J11 chip is used, the value
>>>> is 5 and the Maintenance Register at 177750 seems to determine what the
>>>> rest of the actual hardware supports.
>
> (snip, someone else wrote)
>>> Modifying the MFPT instruction is not the right way to go. CPU
>>> software detection is a delicate business and that process should not
>>> be interfered with directly.
>
>>> In any case, an emulator is not equivalent to a processor type since
>>> SimH and E11 support a range of PDP-11 CPUs.
>
>> Also right. And each CPU behaves differently, and the emulator needs to
>> follow that, or it is broken.
>
> Or, the emulator can emulate a CPU model different from any previously
> built. That usually at least happens in that the emulator runs at a
> different speed than any real processor.

Right.
And yes, that could definitely be done, at which point I think a new
value returned by MFPT would be reasonable.

>>> Some CPU software detection is handled by examining CPU behavior. The
>>> same process can be used to detect an emulator and to determine which
>>> emulator is being used.
>
>> Right. I just posted an outline of how RSX-11M+ detects system type.
>> It's a combination of available information as well as CPU behavior in
>> very weird and possibly not documented ways.
>
> I have seen the rules for detecting different x86 CPUs, from 8086 and
> 8088 on up. Some are pretty strange, though usually documented at least
> as needed for detection.

The "problem" with the PDP-11 is that they obviously didn't anticipate
this beforehand, and so there are no straight and easy rules for
figuring it out. I wouldn't even be surprised if different DEC OSes use
different tricks to figure it out. Not sure there is a canonical
algorithm. They even use some rather undocumented (atleast to the
outside world) diagnostics instructions to help figure out what CPU is
executing.

Example, the 11/60 check in M+:

;
; TEST FOR 11/60
;
T3: MOV #60.,R4 ;;;ASSUME 11/60
CLC ;;;CLEAR CARRY
.WORD 076600 ;;;FIRST HALF OF AN 11/60 MED
;;;INSTRUCTION. IF THIS IS AN 11/60
;;;PROCESSOR, THEN THIS SUBCODE CAUSES
;;;A CPU INTERNAL REGISTER TO BE READ
;;;INTO R0. IF NOT AN 11/60, THE ILLEGAL
;;;INSTRUCTION TRAP CATCHER WILL RETURN TO
;;;THE SECOND HALF OF THE INSTRUCTION WITH
;;;THE C-BIT SET. THE 400 WILL THEN BE
;;;EXECUTED AS A:
.WORD 000400 ;;; BR .+2
;;;WHICH IS EFFECTIVELY A NOP.
BCC CPOK ;;;IF CC IT'S A 11/60
;

[glen herrmannsfeldt]

In vmsnet.pdp-11 Johnny Billquist <b...@softjar.se> wrote:

(snip on VM/370 and emulation)

>> In addition, there is one instruction, diagnose (with no assembler
>> mnemonic) that is defined to be system dependent. That instruction is
>> then used for communication between guest systems and CP (the emulator).

> There are several instructions on various PDP-11 models for this. The
> problem being that it is so undefined. Hard to use to identify the type
> of system for that exact reason, since existing models sometimes also
> might do things...

In the VM/370 case, you use it only after you know that you are
running under VM.

Rumors are that on real hardware you can do things like write to
memory with the wrong parity, (for testing purpose).

On machines with writable control store, it probably does that.

Other things that could really mess up a machine if you didn't
know what you were doing.

-- glen

[Johnny Billquist]

On 2012-01-18 15:28, glen herrmannsfeldt wrote:
> In vmsnet.pdp-11 Johnny Billquist<b...@softjar.se> wrote:
>
> (snip on VM/370 and emulation)
>>> In addition, there is one instruction, diagnose (with no assembler
>>> mnemonic) that is defined to be system dependent. That instruction is
>>> then used for communication between guest systems and CP (the emulator).
>
>> There are several instructions on various PDP-11 models for this. The
>> problem being that it is so undefined. Hard to use to identify the type
>> of system for that exact reason, since existing models sometimes also
>> might do things...
>
> In the VM/370 case, you use it only after you know that you are
> running under VM.

Ah. I misunderstood you slightly, since I thought you were still talking
about how to identify what (virtual) machine you were running on.
Once such a thing is established, there are all kind of ways you can do
communication with the outside hose. The easiest being to just have a
device for it.

> Rumors are that on real hardware you can do things like write to
> memory with the wrong parity, (for testing purpose).

You can do that on at least some PDP-11s. You can also adjust the
voltage used to write to memory to test the margins, and some other
tricks used by diagnostics. And you can force it to ignore parity and
ECC errors.

> On machines with writable control store, it probably does that.
>
> Other things that could really mess up a machine if you didn't
> know what you were doing.

Yeah, that is another interesting area, where the wrong code can totally
mess up your machine. :-)

[paramucho]

On Wed, 18 Jan 2012 12:28:28 +0100, Johnny Billquist <b...@softjar.se>
wrote:

<snip>

>> The reason I need detection is because emulators lack standard
>> terminal output behavior which I use during startup to detect the
>> clock rate of a PDP-11 (I count the number of null characters output
>> to the console terminal per clock tick and use a table to determine
>> both the clock rate and the terminal rate). The test doesn't work on
>> E11, SIMH or V11.
>
>Timing in general is not a good way to detect systems, but I'm sure you
>know that... :-)

"In general" is right, but in some controlled environments it does
work.

An output serial port is a fairly reliable timing device. You just
send nulls to the port and treat the interrupts as timer events. I
first used this technique when the clock on the PDP-11 I was using at
the Hannover computer show died on me a few hours before the show
started.

The test usually fails benignly. The problem with SimH is that it
outputs a space when you send a null to the terminal. I've not seen a
DEC terminal do that. The test can be disabled with a .INI file
setting. There's a couple of checks which exclude the test.

In any case I think it's great to be able to detect 50 or 60 hertz
automatically (and at the same time determine the baud rate of the
console).

>You could make the code work (sortof) on emulators by removing the
>dependency on the serial port. Just make a spinning loop with increments
>and at the next clock interrupt check how far you got.
>However, as emulators don't have a fixed speed, your speed detection
>will be rather odd on those machines anyway.

I see lots of tiny problems aiming their pointy little arrows at me
down that path.

>> In fact, the V11 emulator has a little API which is used to pass
>> information between the emulator and the system. It's used to
>> relinquish control so that the emulator doesn't hog all the CPU time
>> and for various other functions. It would be great if there was a
>> common API for PDP-11 emulators for this kind of thing, but I'm not
>> sure the motivation is there for the effort involved.
>
>Hmm. How do you use that API? Is it to tell that the emulator isn't
>doing anything extremely important, and can run with less CPU right now
>and be happy, or is this just an odd way of doing a WAIT?

The first. It's called by RUST/SJ when it's waiting for terminal
input, so that only works most of the time. It's called RUST/XM,
multi-process system, whenever it schedules the idle process, which is
much more accurate. The emulator just waits a millisecond and resumes
the RUST system. It doesn't seem to impact RUST performance and it
stops the emulator from acting as an ugly CPU hog.

The API is also used to detect the emulator, get a startup comand and
a few other tasks. It's the sort of thing which could grow and grow...

Here's the autohertz/baud check from the RUST/SJ bootstrap module.
"bnew" and "beqw" combine compare and branch instructions.


map hz.bau 2,0
map hz.htz
map hz.cnt
map hz.bbs

b$thtz: .word 0 ; 0=unknown,

bt$htz: bnew b$tv11,40$ ; VRT is 50hz
bnew b$temu,50$ ; default emulator is 60hz
beqw b$tclk,40$ ; no ticks so far, assume no
clock
btvrb$ <Check clock rate> ;
;
call bt$wai ; wait for silence
;
call hz$cnt ; count them
cmp r3,#hzmax. ; above max?
bhis 40$ ; yep
mov #h$ztab,r1 ;
mov #177777,r2 ;
10$: mov hz.cnt(r1),r0 ;
sub r3,r0 ; get the difference
bpl 20$ ;
neg r0 ;
20$: cmp r0,r2 ; this a better shot?
bhi 30$ ; nope
mov r0,r2 ; remember better
; approximation
mov r1,r4 ; select entry
30$: add #hz.bbs,r1 ; next entry
tst (r1) ; any more?
bne 10$ ; nope
mov hz.htz(r4),b$thtz ; set result
40$: return
50$: mov #60.,b$thtz ; emulator default
return

hz$cnt: mov #-2,b$ttik
clr r3 ;
20$: cmp b$ttik,#10. ; all done?
bge 40$ ; yep
cmp b$ttik,#-1 ; got first one?
bne 30$ ; nope
clr b$ttik ; yep - start counting
clr r3 ; reset counter
30$: tstb @r$mtps ; ready for another?
bpl 30$ ; nope
movb #0,@r$mtpb ; write a null
inc r3 ; count it
tst b$ttik ; waiting for first tick?
bpl 20$ ; nope
cmp r3,#400. ; got a clock?
blo 20$ ; maybe
mov #hzmax.,r3 ; no clock
40$: return

.macro hzbau$ bau
.word bau, 50., bau/5
.word bau, 60., bau/6
.endm

h$ztab: hzbau$ 3840.
hzbau$ 1920.
hzbau$ 960.
hzbau$ 480.
hzbau$ 240.
hzbau$ 120.
hzbau$ 60.
hzbau$ 30.
hzbau$ 15.
.word 0
hzmax. = 3840./5

Ian

[paramucho]

On Wed, 18 Jan 2012 14:18:26 +0100, Johnny Billquist <b...@softjar.se>
wrote:

<snip>

>>> In fact, the V11 emulator has a little API which is used to pass
>>> information between the emulator and the system. It's used to
>>> relinquish control so that the emulator doesn't hog all the CPU time
>>> and for various other functions.
>>
>> This is one case where VM has it easy. S/370 processors don't use
>> an idle loop, but a wait state where they stop executing instructions.
>
>So does a PDP-11 normally, which is why I wonder what this API is
>expected to be used for.

Run RSX under SimH and then look at CPU usage and you'll see why :-)

Under SimH, RSX uses up a full CPU slot, just like RT-11 systems which
don't use the WAIT instruction.

V11 solves the problem for RUST systems, but that doesn't help other
systems.

Ian

[Johnny Billquist]

That is because you need to tell SimH to actually release the machine
when the PDP-11 executes a WAIT... :-)
In SimH: set cpu idle

otherwise, SimH will "emulate" the WAIT instruction by actually doing a
tight loop.

[Johnny Billquist]

On 2012-01-18 17:02, paramucho wrote:
> On Wed, 18 Jan 2012 12:28:28 +0100, Johnny Billquist<b...@softjar.se>
> wrote:
>
> <snip>
>>> The reason I need detection is because emulators lack standard
>>> terminal output behavior which I use during startup to detect the
>>> clock rate of a PDP-11 (I count the number of null characters output
>>> to the console terminal per clock tick and use a table to determine
>>> both the clock rate and the terminal rate). The test doesn't work on
>>> E11, SIMH or V11.
>>
>> Timing in general is not a good way to detect systems, but I'm sure you
>> know that... :-)
>
> "In general" is right, but in some controlled environments it does
> work.
>
> An output serial port is a fairly reliable timing device. You just
> send nulls to the port and treat the interrupts as timer events. I
> first used this technique when the clock on the PDP-11 I was using at
> the Hannover computer show died on me a few hours before the show
> started.

Hum? So what do you detect? 50Hz vs. 60Hz, and the speed of the console
port. Useful, but I would think you'd like to detect more.
Also, this might be messy if someone actually use a clock source with
some other frequency...
(800Hz seems to have been somewhat popular as well).

> The test usually fails benignly. The problem with SimH is that it
> outputs a space when you send a null to the terminal. I've not seen a
> DEC terminal do that. The test can be disabled with a .INI file
> setting. There's a couple of checks which exclude the test.

Hum? First of all, SimH is running inside some terminal window, so I
would suspect that any such behavior should be blamed on that terminal
program and not Simh, unless you really are saying that if you write a 0
to the CSR, Simh really sends out a 32(10) on the port.

What terminal program, if I may ask. It sounds bad enough that I
probably want to avoid it.

Terminal output is good in a way, I agree. They do normally take some
constant time to perform, no matter what speed the CPU have. The problem
obviously being that when you go to virtual serial ports, that is no
longer true, since the serial data can be clocked out at any speed even
thought you might think it is some other, fixed speed.

> In any case I think it's great to be able to detect 50 or 60 hertz
> automatically (and at the same time determine the baud rate of the
> console).

True. Although I think the test is flawed and will only work under some
restricted circumstances. Even if they are pretty common.

>> You could make the code work (sortof) on emulators by removing the
>> dependency on the serial port. Just make a spinning loop with increments
>> and at the next clock interrupt check how far you got.
>> However, as emulators don't have a fixed speed, your speed detection
>> will be rather odd on those machines anyway.
>
> I see lots of tiny problems aiming their pointy little arrows at me
> down that path.

It is just a solution that tells you the speed of the CPU, assuming you
know the clock interrupt frequency. With emulated CPUs running on some
host, this value will actually be variable, which is messy.
And of course, this all have the problem that you might not know the
clock interrupt rate.

>>> In fact, the V11 emulator has a little API which is used to pass
>>> information between the emulator and the system. It's used to
>>> relinquish control so that the emulator doesn't hog all the CPU time
>>> and for various other functions. It would be great if there was a
>>> common API for PDP-11 emulators for this kind of thing, but I'm not
>>> sure the motivation is there for the effort involved.
>>
>> Hmm. How do you use that API? Is it to tell that the emulator isn't
>> doing anything extremely important, and can run with less CPU right now
>> and be happy, or is this just an odd way of doing a WAIT?
>
> The first. It's called by RUST/SJ when it's waiting for terminal
> input, so that only works most of the time. It's called RUST/XM,
> multi-process system, whenever it schedules the idle process, which is
> much more accurate. The emulator just waits a millisecond and resumes
> the RUST system. It doesn't seem to impact RUST performance and it
> stops the emulator from acting as an ugly CPU hog.

Ah. That is what the WAIT instruction is for. And, reading your other
post, it would appear you have drawn some odd conclusion based on the
default settings in Simh, where Simh don't actually release the CPU if
you do a WAIT.

> The API is also used to detect the emulator, get a startup comand and
> a few other tasks. It's the sort of thing which could grow and grow...
>
> Here's the autohertz/baud check from the RUST/SJ bootstrap module.
> "bnew" and "beqw" combine compare and branch instructions.

[...]
The problem being that 50 and 60 Hz are not the only two clock
frequencies you might find on a PDP-11... :-)

[glen herrmannsfeldt]

In vmsnet.pdp-11 Johnny Billquist <b...@softjar.se> wrote:

(snip)

>>> There are several instructions on various PDP-11 models for this. The
>>> problem being that it is so undefined. Hard to use to identify the type
>>> of system for that exact reason, since existing models sometimes also
>>> might do things...

(then I wrote)

>> In the VM/370 case, you use it only after you know that you are
>> running under VM.

> Ah. I misunderstood you slightly, since I thought you were still talking
> about how to identify what (virtual) machine you were running on.
> Once such a thing is established, there are all kind of ways you can do
> communication with the outside hose. The easiest being to just have a
> device for it.

As I understand it, that was done in the very early days, but the
official ruling disallowed it. I suppose if it looked like a real I/O
device then it might have been allowed.

One feature that S/370 has that seems rare on other sytems is the
CTCA, Channel to Channel adaptor. It connects two systems together
such that output on one is input to the other, and vice versa.
Then, VM/370 implements virtual CTCA that allows I/O between
virtual machines, in the same way that it was allowed between
real machines.

Otherwise, all virtual machines have a virtual card reader and virtual
card punch, and one way to move data between them is to punch virtual
cards and send them to another virtual machine card reader.

It would seem that PDP-11 emulators could emulate serial lines
between emulated machines, such that one could communicate with
another. I will guess that card punches were rare on PDP-11s.

-- glen

[Al Kossow]

On 1/18/12 1:54 PM, glen herrmannsfeldt wrote:
> I will guess that card punches were rare on PDP-11s.
>

Cross-coupled DR11-B or DR11-C 16 bit parallel interfaces were commonly
used to connect two machines together. Biggest problem were ground loops
if they were on two different power circuits.

They have the advantage of parallel transfers and hardware handshaking.

[Johnny Billquist]

On 2012-01-18 22:54, glen herrmannsfeldt wrote:
> In vmsnet.pdp-11 Johnny Billquist<b...@softjar.se> wrote:
>
> (snip)
>>>> There are several instructions on various PDP-11 models for this. The
>>>> problem being that it is so undefined. Hard to use to identify the type
>>>> of system for that exact reason, since existing models sometimes also
>>>> might do things...
>
> (then I wrote)
>>> In the VM/370 case, you use it only after you know that you are
>>> running under VM.
>
>> Ah. I misunderstood you slightly, since I thought you were still talking
>> about how to identify what (virtual) machine you were running on.
>> Once such a thing is established, there are all kind of ways you can do
>> communication with the outside hose. The easiest being to just have a
>> device for it.
>
> As I understand it, that was done in the very early days, but the
> official ruling disallowed it. I suppose if it looked like a real I/O
> device then it might have been allowed.

Why not a new I-O device? Why would it have to look like some existing
one? Are no new real I/O devices allowed to be invented either?

> One feature that S/370 has that seems rare on other sytems is the
> CTCA, Channel to Channel adaptor. It connects two systems together
> such that output on one is input to the other, and vice versa.
> Then, VM/370 implements virtual CTCA that allows I/O between
> virtual machines, in the same way that it was allowed between
> real machines.
>
> Otherwise, all virtual machines have a virtual card reader and virtual
> card punch, and one way to move data between them is to punch virtual
> cards and send them to another virtual machine card reader.
>
> It would seem that PDP-11 emulators could emulate serial lines
> between emulated machines, such that one could communicate with
> another. I will guess that card punches were rare on PDP-11s.

You can even attach two virtual ethernet interfaces to each other... ;-)

[glen herrmannsfeldt]

In vmsnet.pdp-11 Johnny Billquist <b...@softjar.se> wrote:

(snip on emulation)

>>> Ah. I misunderstood you slightly, since I thought you were still talking
>>> about how to identify what (virtual) machine you were running on.
>>> Once such a thing is established, there are all kind of ways you can do
>>> communication with the outside hose. The easiest being to just have a
>>> device for it.

>> As I understand it, that was done in the very early days, but the
>> official ruling disallowed it. I suppose if it looked like a real I/O
>> device then it might have been allowed.

> Why not a new I-O device? Why would it have to look like some existing
> one? Are no new real I/O devices allowed to be invented either?

I suppose, but I/O on S/370 isn't so easy as on the PDP-11.
You write a channel program, which could be just one CCW (Channel
Command Word, which is actually a doubleword), put its address
in a specified real storage location, the do SIO with the operand
giving the I/O device address. After the I/O operation, there
is an I/O interrupt indicating that it is done. (And interrupts
should be disabled, so that no other programs try to do I/O
at the same time, using the same low storage address.)

It might have been that someone wanted to simplify that, such as
have the SIO do the whole operation. It could be that was too much
of a stretch, and so diagnose was suggested instead.

(snip)

>> Otherwise, all virtual machines have a virtual card reader and virtual
>> card punch, and one way to move data between them is to punch virtual
>> cards and send them to another virtual machine card reader.

>> It would seem that PDP-11 emulators could emulate serial lines
>> between emulated machines, such that one could communicate with
>> another. I will guess that card punches were rare on PDP-11s.

> You can even attach two virtual ethernet interfaces to each other... ;-)

-- glen

[paramucho]

On Wed, 18 Jan 2012 19:00:03 +0100, Johnny Billquist <b...@softjar.se>

wrote:

>On 2012-01-18 17:25, paramucho wrote:
>> On Wed, 18 Jan 2012 14:18:26 +0100, Johnny Billquist<b...@softjar.se>
>> wrote:
>>
>> <snip>
>>
>>>>> In fact, the V11 emulator has a little API which is used to pass
>>>>> information between the emulator and the system. It's used to
>>>>> relinquish control so that the emulator doesn't hog all the CPU time
>>>>> and for various other functions.
>>>>
>>>> This is one case where VM has it easy. S/370 processors don't use
>>>> an idle loop, but a wait state where they stop executing instructions.
>>>
>>> So does a PDP-11 normally, which is why I wonder what this API is
>>> expected to be used for.
>>
>> Run RSX under SimH and then look at CPU usage and you'll see why :-)
>>
>> Under SimH, RSX uses up a full CPU slot, just like RT-11 systems which
>> don't use the WAIT instruction.
>>
>> V11 solves the problem for RUST systems, but that doesn't help other
>> systems.
>
>That is because you need to tell SimH to actually release the machine
>when the PDP-11 executes a WAIT... :-)
>In SimH: set cpu idle
>
>otherwise, SimH will "emulate" the WAIT instruction by actually doing a
>tight loop.

Yes, I haven't read the SimH documentation for quite some time :-)

From what I can see the SET CPU IDLE code was added in 2006. It
applies to RSX and RSTS, but not RT-11 or Unix because they, like
RUST, don't use the WAIT instruction.




Ian

[Bob Koehler]

In article <9nnv8q...@mid.individual.net>, Bob Eager <news...@eager.cx> writes:
> On Wed, 18 Jan 2012 12:41:06 +0000, glen herrmannsfeldt wrote:
>
>
>> This is one case where VM has it easy. S/370 processors don't use an
>> idle loop, but a wait state where they stop executing instructions.
>>
>> As I understand it, when IBM leased processors, they had a usage meter
>> such that one would pay based on how much the processor was used. The
>> usage meter stops in the wait state.
>
> Isn't that true on the PDP-11, with WAIT? And with at least some x86 CPUs
> and HLT?
>

It can be done on a lot of systems with a HALT instruction. Many CPU
will start up again when receiving an interrupt, which is how most
systems get out of thier idle loops anyhow.

Some systems, however, will take action when the CPU executes a HALT
instruction. Qbus VAX 4000 were often configurable in this reguard.
The default action was to force a system crash. It was because of
this that I stopped using HALT as a kernel debug instruction. Back
on 11/780, you simply got a console prompt and could enter CONTINUE
when done debugging.

It is important to note, that on some architectures, such as VAX,
the program counter (aka instruction pointer, ...), is incremented
by the halt instruction, so simply dismissing the interrupt can cause
the system to move on to the next instruction (which is also why
console CONTINUE worked on an 11/780).

[paramucho]

On Wed, 18 Jan 2012 19:12:24 +0100, Johnny Billquist <b...@softjar.se>
wrote:

<snip>

>> An output serial port is a fairly reliable timing device. You just
>> send nulls to the port and treat the interrupts as timer events. I
>> first used this technique when the clock on the PDP-11 I was using at
>> the Hannover computer show died on me a few hours before the show
>> started.
>
>Hum? So what do you detect? 50Hz vs. 60Hz, and the speed of the console
>port. Useful, but I would think you'd like to detect more.

It sets out to automatically detect the clock speed, and that's what
it does. What more should it detect?

Of course, other conditions are detected, including emulators and the
presence of a DEC programmable clock.

>Also, this might be messy if someone actually use a clock source with
>some other frequency...
>(800Hz seems to have been somewhat popular as well).

It supports the standard DEC configurations. For non-standard hardware
it fails benignly and can be overridden with a bootstrap .INI file
entry or a startup command file. It's not messy at all.

>> The test usually fails benignly. The problem with SimH is that it
>> outputs a space when you send a null to the terminal. I've not seen a
>> DEC terminal do that. The test can be disabled with a .INI file
>> setting. There's a couple of checks which exclude the test.
>
>Hum? First of all, SimH is running inside some terminal window, so I
>would suspect that any such behavior should be blamed on that terminal
>program and not Simh, unless you really are saying that if you write a 0
>to the CSR, Simh really sends out a 32(10) on the port.
>
>What terminal program, if I may ask. It sounds bad enough that I
>probably want to avoid it.

The Windows console program.

Or rather, it was a problem some years ago when I wrote the code. I
retested tonight and the behavior is no longer there.

>Terminal output is good in a way, I agree. They do normally take some
>constant time to perform, no matter what speed the CPU have.

I've used them instead of a line clock to maintain system time.

> The problem
>obviously being that when you go to virtual serial ports, that is no
>longer true, since the serial data can be clocked out at any speed even
>thought you might think it is some other, fixed speed.

That's not a real-world problem. These tests are performed during
bootstrap on the system console.

>> In any case I think it's great to be able to detect 50 or 60 hertz
>> automatically (and at the same time determine the baud rate of the
>> console).
>
>True. Although I think the test is flawed and will only work under some
>restricted circumstances. Even if they are pretty common.

It works on standard configurations, unflawed. Non-standard
configurations revert to INI files or startup command file. That's how
the world works. I wish I'd thought of the technique back in the
eighties.

<snip>

>>> Hmm. How do you use that API? Is it to tell that the emulator isn't
>>> doing anything extremely important, and can run with less CPU right now
>>> and be happy, or is this just an odd way of doing a WAIT?
>>
>> The first. It's called by RUST/SJ when it's waiting for terminal
>> input, so that only works most of the time. It's called RUST/XM,
>> multi-process system, whenever it schedules the idle process, which is
>> much more accurate. The emulator just waits a millisecond and resumes
>> the RUST system. It doesn't seem to impact RUST performance and it
>> stops the emulator from acting as an ugly CPU hog.
>
>Ah. That is what the WAIT instruction is for. And, reading your other
>post, it would appear you have drawn some odd conclusion based on the
>default settings in Simh, where Simh don't actually release the CPU if
>you do a WAIT.

RT-11 doesn't use WAIT and since RUST systems grows out of that
tradition they don't use WAIT either (and by the way, I rarely use
SimH).

>> The API is also used to detect the emulator, get a startup comand and
>> a few other tasks. It's the sort of thing which could grow and grow...
>>
>> Here's the autohertz/baud check from the RUST/SJ bootstrap module.
>> "bnew" and "beqw" combine compare and branch instructions.
>
>[...]
>The problem being that 50 and 60 Hz are not the only two clock
>frequencies you might find on a PDP-11... :-)

They are the only two line clock frequencies supported by RT-11 and
RUST. The test is not performed if a programmable clock is available.
I have never had a request for the support of any other kind of clock
frequency. In any case, as stated a few times, the test can be
overriden. I don't see a real-world problem here at all. It's one of
my favorite little routines.



Ian

[Bob Koehler]

In article <jf7f3j$lq4$1...@speranza.aioe.org>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>
> It would seem that PDP-11 emulators could emulate serial lines
> between emulated machines, such that one could communicate with
> another. I will guess that card punches were rare on PDP-11s.

Never saw a card punch on a DEC machine, although I suspect they
existed. Did see card readers, although not designed for high
volume.

Early PDP-11 were likely to have paper tape punches and readers.
Moving from roll to fan-fold was certianly an improvement.

[Johnny Billquist]

On 2012-01-19 15.30, paramucho wrote:
> On Wed, 18 Jan 2012 19:12:24 +0100, Johnny Billquist<b...@softjar.se>
> wrote:
>
> <snip>
>>> An output serial port is a fairly reliable timing device. You just
>>> send nulls to the port and treat the interrupts as timer events. I
>>> first used this technique when the clock on the PDP-11 I was using at
>>> the Hannover computer show died on me a few hours before the show
>>> started.
>>
>> Hum? So what do you detect? 50Hz vs. 60Hz, and the speed of the console
>> port. Useful, but I would think you'd like to detect more.
>
> It sets out to automatically detect the clock speed, and that's what
> it does. What more should it detect?

Well, this whole thread started out with the question of how to detect
what CPU/machine you are running on. Which seems like a valid thing to
sometimes want to know.

> Of course, other conditions are detected, including emulators and the
> presence of a DEC programmable clock.

How do you detect emulation or a DEC programmable clock this way?

>> Also, this might be messy if someone actually use a clock source with
>> some other frequency...
>> (800Hz seems to have been somewhat popular as well).
>
> It supports the standard DEC configurations. For non-standard hardware
> it fails benignly and can be overridden with a bootstrap .INI file
> entry or a startup command file. It's not messy at all.

Well, any 11/73, 11/83, 11/84, 11/93 or 11/94 have in the setup menu the
option to run the system clock at power line frequency, 50 Hz, 60 Hz or
800 Hz. Seems rather standard hardware to me.
I have not checked if the 11/53 have the same option. For older
machines, you need the programmable clock to select anything but line
frequency.

>>> The test usually fails benignly. The problem with SimH is that it
>>> outputs a space when you send a null to the terminal. I've not seen a
>>> DEC terminal do that. The test can be disabled with a .INI file
>>> setting. There's a couple of checks which exclude the test.
>>
>> Hum? First of all, SimH is running inside some terminal window, so I
>> would suspect that any such behavior should be blamed on that terminal
>> program and not Simh, unless you really are saying that if you write a 0
>> to the CSR, Simh really sends out a 32(10) on the port.
>>
>> What terminal program, if I may ask. It sounds bad enough that I
>> probably want to avoid it.
>
> The Windows console program.
>
> Or rather, it was a problem some years ago when I wrote the code. I
> retested tonight and the behavior is no longer there.

Still probably a terminal program that I will avoid.

>> Terminal output is good in a way, I agree. They do normally take some
>> constant time to perform, no matter what speed the CPU have.
>
> I've used them instead of a line clock to maintain system time.

Works as long as you have a physical serial port.

>> The problem
>> obviously being that when you go to virtual serial ports, that is no
>> longer true, since the serial data can be clocked out at any speed even
>> thought you might think it is some other, fixed speed.
>
> That's not a real-world problem. These tests are performed during
> bootstrap on the system console.

All my emulated machines have a virtual serial port. It does not take
much, or any time at all, to write a byte to the serial console port.
And I think that is very much the real world.
The console lines are in reality telnet ports.

>>> In any case I think it's great to be able to detect 50 or 60 hertz
>>> automatically (and at the same time determine the baud rate of the
>>> console).
>>
>> True. Although I think the test is flawed and will only work under some
>> restricted circumstances. Even if they are pretty common.
>
> It works on standard configurations, unflawed. Non-standard
> configurations revert to INI files or startup command file. That's how
> the world works. I wish I'd thought of the technique back in the
> eighties.

It's a nice enough technique, and it has been used before. It do have
its limits, which is the main reason it's not become so universal.

>>>> Hmm. How do you use that API? Is it to tell that the emulator isn't
>>>> doing anything extremely important, and can run with less CPU right now
>>>> and be happy, or is this just an odd way of doing a WAIT?
>>>
>>> The first. It's called by RUST/SJ when it's waiting for terminal
>>> input, so that only works most of the time. It's called RUST/XM,
>>> multi-process system, whenever it schedules the idle process, which is
>>> much more accurate. The emulator just waits a millisecond and resumes
>>> the RUST system. It doesn't seem to impact RUST performance and it
>>> stops the emulator from acting as an ugly CPU hog.
>>
>> Ah. That is what the WAIT instruction is for. And, reading your other
>> post, it would appear you have drawn some odd conclusion based on the
>> default settings in Simh, where Simh don't actually release the CPU if
>> you do a WAIT.
>
> RT-11 doesn't use WAIT and since RUST systems grows out of that
> tradition they don't use WAIT either (and by the way, I rarely use
> SimH).

Ok. Anyway, WAIT works very nicely, and SimH actually will not hog the
CPU when a WAIT is executed, *if* you tell it not to. But that is a SimH
implementation detail.

And I'm maybe a little surprised that RT-11 don't use WAIT, but then
again, it's a simple single-user system, so it might not be totally
shocking that it don't use WAIT.

Do you know how the idle loop displays anything on the switch register
in RT-11? Does it actually write to the switch register? Do you know
where in the code it is? Trying to look a little at the RT-11 sources...

>>> The API is also used to detect the emulator, get a startup comand and
>>> a few other tasks. It's the sort of thing which could grow and grow...
>>>
>>> Here's the autohertz/baud check from the RUST/SJ bootstrap module.
>>> "bnew" and "beqw" combine compare and branch instructions.
>>
>> [...]
>> The problem being that 50 and 60 Hz are not the only two clock
>> frequencies you might find on a PDP-11... :-)
>
> They are the only two line clock frequencies supported by RT-11 and
> RUST. The test is not performed if a programmable clock is available.
> I have never had a request for the support of any other kind of clock
> frequency. In any case, as stated a few times, the test can be
> overriden. I don't see a real-world problem here at all. It's one of
> my favorite little routines.

Ouch. RSX supports any clock frequency, and you can also change it
dynamically on M+ systems. (Well, more than 65535 Hz is not possible,
and in the old times of real hardware, I think the recommendation was to
not use something higher than 1000 Hz, because the overhead from the
clock interrupts would start to take too much CPU time.)

And even the line clock type can actually give you other frequencies, as
I mentioned above, depending on which machines you have.

Johnny

[Johnny Billquist]

On 2012-01-19 15.32, Bob Koehler wrote:
> In article<jf7f3j$lq4$1...@speranza.aioe.org>, glen herrmannsfeldt<g...@ugcs.caltech.edu> writes:
>>
>> It would seem that PDP-11 emulators could emulate serial lines
>> between emulated machines, such that one could communicate with
>> another. I will guess that card punches were rare on PDP-11s.
>
> Never saw a card punch on a DEC machine, although I suspect they
> existed. Did see card readers, although not designed for high
> volume.

I actually have never seen a card punch interface for a DEC machine. I
assumed it was mostly because card were punched on terminals, and then
loaded into the machine. Cards were not used to store data, as far as I
know, and thus there wasn't much need for a puncher on the machine.

> Early PDP-11 were likely to have paper tape punches and readers.
> Moving from roll to fan-fold was certianly an improvement.

Paper punches/readers were pretty common. I still have one or two around.

Johnny

[Johnny Billquist]

Eh... Unix definitely use WAIT.
Or, what version of Unix are you referring to? I'm looking at (and
using) 2.11BSD. I haven't really checked older versions.

Johnny

[glen herrmannsfeldt]

In vmsnet.pdp-11 Johnny Billquist <b...@softjar.se> wrote:

(snip)

> And I'm maybe a little surprised that RT-11 don't use WAIT, but then
> again, it's a simple single-user system, so it might not be totally
> shocking that it don't use WAIT.

That would be true for SJ, but for FB or, if I remember right, XM,
I would think it might do WAIT.

> Do you know how the idle loop displays anything on the switch register
> in RT-11? Does it actually write to the switch register? Do you know
> where in the code it is? Trying to look a little at the RT-11 sources...

(snip)

-- glen

[paramucho]

On Thu, 19 Jan 2012 17:42:37 +0100, Johnny Billquist <b...@softjar.se>

wrote:

>On 2012-01-19 15.30, paramucho wrote:
>> On Wed, 18 Jan 2012 19:12:24 +0100, Johnny Billquist<b...@softjar.se>
>> wrote:
>>
>> <snip>
>>>> An output serial port is a fairly reliable timing device. You just
>>>> send nulls to the port and treat the interrupts as timer events. I
>>>> first used this technique when the clock on the PDP-11 I was using at
>>>> the Hannover computer show died on me a few hours before the show
>>>> started.
>>>
>>> Hum? So what do you detect? 50Hz vs. 60Hz, and the speed of the console
>>> port. Useful, but I would think you'd like to detect more.
>>
>> It sets out to automatically detect the clock speed, and that's what
>> it does. What more should it detect?
>
>Well, this whole thread started out with the question of how to detect
>what CPU/machine you are running on. Which seems like a valid thing to
>sometimes want to know.

The autohertz feature is just part of a more general bootstrap
detection process. I also have detect the usual things such as
available memory, CPU type, FPU, EIS, LSI and so on. All that code is
pretty straight-forward and carried out by many PDP-11 operating
systems.

The approach I take on RUST/XM is a little bit more interesting though
because I don't assume I'm in kernel mode with access to the I/O page
for a lot of the initial tests. I did that so that I could reuse the
code in a general environment detection utility and so that I act
sensibly if an attempt was made to boot in VAX compatibility mode.

>> Of course, other conditions are detected, including emulators and the
>> presence of a DEC programmable clock.
>
>How do you detect emulation or a DEC programmable clock this way?

The other conditions aren't detected with a timing loop...you seem to
be talking about general detection and timing-loop detection all at
the same time...or are we in alternate universes again...

>>> Also, this might be messy if someone actually use a clock source with
>>> some other frequency...
>>> (800Hz seems to have been somewhat popular as well).
>>
>> It supports the standard DEC configurations. For non-standard hardware
>> it fails benignly and can be overridden with a bootstrap .INI file
>> entry or a startup command file. It's not messy at all.
>
>Well, any 11/73, 11/83, 11/84, 11/93 or 11/94 have in the setup menu the
>option to run the system clock at power line frequency, 50 Hz, 60 Hz or
>800 Hz. Seems rather standard hardware to me.
>I have not checked if the 11/53 have the same option. For older
>machines, you need the programmable clock to select anything but line
>frequency.

The 800hz option isn't present on the 11/73. It's not documented in
the CPU guide and I note that SimH only provides the "JCLK" option for
the 8x and 9x CPUs but not for the 73.

In any case, since the option settings for 50/60/800 hz are visible in
a processor register (xx177520) I don't need to detect the setting in
a timing loop. It's just a matter of a CPU and CSR detect.

At present CPU support for RUST systems hasn't advanced beyond the
11/73. Later stuff is on the TODO list, but until someone who can also
test the code requests the functionality there are better ways to
waste my time.

<snip>

>>> The problem
>>> obviously being that when you go to virtual serial ports, that is no
>>> longer true, since the serial data can be clocked out at any speed even
>>> thought you might think it is some other, fixed speed.
>>
>> That's not a real-world problem. These tests are performed during
>> bootstrap on the system console.
>
>All my emulated machines have a virtual serial port. It does not take
>much, or any time at all, to write a byte to the serial console port.
>And I think that is very much the real world.
>The console lines are in reality telnet ports.

The test is not performed on emulated machines, which is why it's not
a real-world problem for moi. There is no problem to solve.

<snip>

>And I'm maybe a little surprised that RT-11 don't use WAIT, but then
>again, it's a simple single-user system, so it might not be totally
>shocking that it don't use WAIT.

According to SimH documentation the SET CPU IDLE code benefits RSX and
RSTS but not RT-11 or UNIX. Unix is not a single-user operating
system. I'm not sure about the many other operating systems written
for the PDP-11. You note elsewhere that a later version of BSD
supports WAIT, but Bob Supnik is probably talking about "Unix" Unix.

RT-11 is definitely a multi-task/job system. Late versions of the
system support "system jobs" running just about any system program
(I've never actually used the feature though). So, if multi-process is
a reason for WAIT, then it applies equally to RT-11.

In any case, it's more a question of single-CPU than it is single-
user. There's no particular benefit to using WAIT in a single-CPU
configuration. Up until 2006 the instruction was effectively ignored
by SimH and is still ignored out-of-the-box for SimH.

It's not necessary for a system to use every feature provided by the
hardware architecture. For example, the original planned use of
interrupt vectors has essentially been ignored by RT-11 and RSX for
years which uniformly take interrupts at PR7 and then lower priority
to the device level rather than letting the vector do that job as
originally planned. Then there's the PDP-11 virtual memory feature,
not to forget MARK.

>Do you know how the idle loop displays anything on the switch register
>in RT-11? Does it actually write to the switch register? Do you know
>where in the code it is? Trying to look a little at the RT-11 sources...

A long, long time ago, when I was a young coder, I could more-or-less
recite the RT-11 monitor code from memory, and yes, the idle loop code
is still in the sources even though switch registers are long gone.

As discussed in our earlier threads, I usually don't waste my time
presenting details of RT-11 in our discussions since you generally
don't respond (beyond snipping), but since you ask I'll summarise my
fuller response to Glenn here.

No official DEC distribution of RT-11 had a monitor binary with a WAIT
instruction in the idle loop.

Up until V5.4, which was quite late in RT-11's life cycle, there was
no provision at all for WAIT in the loop. A patch point was introduced
late in RT-11's life cycle, around V5.4, which allowed for a WAIT
instruction to be patched in, but that patch point was not used by the
RT-11 bootstrap during startup and was not documented in CUSTOM.TXT
which provides information on monitor patch points. It is essentially
DEC-private.

So the closest you get to WAIT in RT-11 is ";;; WAIT". Indeed, the
commented WAIT shows that the inclusion of the instruction was
considered and rejected.

See my response to Glenn for more details.

(I'm heartened to see that you're finally reading the RT-11 sources.
Welcome to the bright side of the road comrade :-)

>>>> The API is also used to detect the emulator, get a startup comand and
>>>> a few other tasks. It's the sort of thing which could grow and grow...
>>>>
>>>> Here's the autohertz/baud check from the RUST/SJ bootstrap module.
>>>> "bnew" and "beqw" combine compare and branch instructions.
>>>
>>> [...]
>>> The problem being that 50 and 60 Hz are not the only two clock
>>> frequencies you might find on a PDP-11... :-)
>>
>> They are the only two line clock frequencies supported by RT-11 and
>> RUST. The test is not performed if a programmable clock is available.
>> I have never had a request for the support of any other kind of clock
>> frequency. In any case, as stated a few times, the test can be
>> overriden. I don't see a real-world problem here at all. It's one of
>> my favorite little routines.
>
>Ouch. RSX supports any clock frequency, and you can also change it
>dynamically on M+ systems. (Well, more than 65535 Hz is not possible,
>and in the old times of real hardware, I think the recommendation was to
>not use something higher than 1000 Hz, because the overhead from the
>clock interrupts would start to take too much CPU time.)

Once again, the point of the timing loop is to determine the line
clock frequency during *bootstrap*. Dynamic changing of the clock
frequency at runtime is not an issue it attempts to address, could
address or needs to address.

>And even the line clock type can actually give you other frequencies, as
>I mentioned above, depending on which machines you have.

You mentioned one other "line clock" frequency only (800hz), not
plural "frequencies", but it's not necessary to autodetect that
frequency since the information in that case is available in a
processor register.

Indeed, despite your vociferous objections and invented issues there
is *no* problem. For most machines the feature automatically detects
the line frequency. If not, it fails benignly. It doesn't apply to
virtual ports or dynamic runtime changes. It doesn't need to detect
800hz. It can be overriden with a .INI file or the startup command
file.

I know that my European and Australian 50hz customers would have loved
to have had the feature back in the 80s. I only came up with the
feature when I decided to rejuvinate my systems over the last decade
to introduce some of more beneficial recent operating systems ideas,
and one of those good ideas is that systems should figure out for
themselves what hardware they have without bugging users.

Are we done yet? Can we find something else to chew? :-)

Ian

[paramucho]

On Thu, 19 Jan 2012 20:32:25 +0000 (UTC), glen herrmannsfeldt
<g...@ugcs.caltech.edu> wrote:

>In vmsnet.pdp-11 Johnny Billquist <b...@softjar.se> wrote:
>
>(snip)
>> And I'm maybe a little surprised that RT-11 don't use WAIT, but then
>> again, it's a simple single-user system, so it might not be totally
>> shocking that it don't use WAIT.
>
>That would be true for SJ, but for FB or, if I remember right, XM,
>I would think it might do WAIT.

No sign of WAIT at all in RT-11 up to and including V5.3.

In V5.4 a couple of patch points at the end of the idle loop are
introduced which effectively place two NOPs at the end of the loop. A
patch offset, ..NULJ, is also defined, along with conditional code for
RTEM, which entered the sources at the same time. The monitor offset
$NULJB seems to be defined at the same time.

I can't find any BSTRAP.MAC code which would alter the patch points
for an XM monitor. So, I don't think that any RT-11 monitor was
distributed with WAIT in the idle loop. I ran up a couple of XM
monitors today and saw only NOPs

The only code I can find which uses the offset is RTMON, a foreground
program which monitors RT-11's performance. I guess it hooks itself
into the idle loop.

Some late monitor sources show that the patch points had been designed
to optionally use WAIT at the end of the idle loop. The monitor fixed
offset $NULJB has the comment that reads "=> WAIT/NOP" and the first
NOP mentioned above has a WAIT instruction preceded by three
semicolons.

I think this code was either experimental or used by special services
because: (1) it is not enabled/disabled by a conditional, (2) the
offset is not listed in CUSTOM.TXT which describes the monitor patch
points.

Thus, I think that WAIT would have been used only for some specific
customers needs, if anything. It's not unknown for RT-11 developers to
leave hooks to private code in the monitor sources. An examination of
the late sources shows hooks for a disk cache as well.

I doubt that the RT-11 team would have introduced WAIT into the
distribution because (1) it doesn't bring any practical benefit, (2) a
change in the idle loop would almost certainly affect some existing
user applications, and (3) if it's not broken don't fix it.

So the best we can say, at the moment, I think is that the RT-11 team
considered the idea of introducing a WAIT instruction into the idle
loop and rejected the idea.

As to why a customer might have a specific need for WAIT one can only
speculate, however I recall a client I had who built disk testers and
formatters for the large disk pack manufacturers in the early 80s.
They had a custom processor which did the actual work. They called me
in when they had erratic behavior that couldn't explain. To cut a long
story short I found that the noise causing the erratic behavior was
the unibus itself. By inserting a single WAIT instruction I
effectively turned off enough of the electrical behavior of the bus to
remove the problem. But I still didn't need that support in the
monitor.

BTW: One of the companies they worked for, it might have been Nassau,
produced platters for DEC (possibly the RLO1/RLO2). They were the same
specs as used by some other customers and the supplier had worked out
that DEC's quality assurance program was the weakest in the industry
so they sent all their flakiest platters to DEC (who sent them to us).

I was ironic, and rather cruel working for them. I was in a room with
hundreds of thousands of dollars worth of very large disk packs
working on a tiny PDP-11 with single density floppies and one of the
earliers, crudest of the VT52 series.

Ian

[paramucho]

On Thu, 19 Jan 2012 17:50:49 +0100, Johnny Billquist <b...@softjar.se>

From what you write, 2.11 BSD Unix definitely uses WAIT.

>Or, what version of Unix are you referring to? I'm looking at (and
>using) 2.11BSD. I haven't really checked older versions.

I'm quoting from the SimH documentation (that I've very recently found
a reason to reread :-) where Bob Supnik says that the use SET CPU
IDLE "will work for RSTS/E and RSX-11M+ [sic], but not for RT-11 or
UNIX." I assume that that translates to the (correct) use of WAIT
since SET CPU IDLE is hooked to the WAIT instruction.

The sources for the earlier versions of Unix are available on the web
if you want to find more detail about their usage, but I'm sure you
know that :-)


Ian

[Johnny Billquist]

On 2012-01-20 14:29, paramucho wrote:
> On Thu, 19 Jan 2012 17:42:37 +0100, Johnny Billquist<b...@softjar.se>
> wrote:
>
>> On 2012-01-19 15.30, paramucho wrote:
>>> On Wed, 18 Jan 2012 19:12:24 +0100, Johnny Billquist<b...@softjar.se>
>>> wrote:
>>>
>>> <snip>

>>> Of course, other conditions are detected, including emulators and the
>>> presence of a DEC programmable clock.
>>
>> How do you detect emulation or a DEC programmable clock this way?
>
> The other conditions aren't detected with a timing loop...you seem to
> be talking about general detection and timing-loop detection all at
> the same time...or are we in alternate universes again...

I was responding to your comment above, which I did include above my
question. You said you detect other conditions, including emulators and

the presence of a DEC programmable clock.

So I just asked how you detected those ones. I thought that was a very
straight forward question.

>>>> Also, this might be messy if someone actually use a clock source with
>>>> some other frequency...
>>>> (800Hz seems to have been somewhat popular as well).
>>>
>>> It supports the standard DEC configurations. For non-standard hardware
>>> it fails benignly and can be overridden with a bootstrap .INI file
>>> entry or a startup command file. It's not messy at all.
>>
>> Well, any 11/73, 11/83, 11/84, 11/93 or 11/94 have in the setup menu the
>> option to run the system clock at power line frequency, 50 Hz, 60 Hz or
>> 800 Hz. Seems rather standard hardware to me.
>> I have not checked if the 11/53 have the same option. For older
>> machines, you need the programmable clock to select anything but line
>> frequency.
>
> The 800hz option isn't present on the 11/73. It's not documented in
> the CPU guide and I note that SimH only provides the "JCLK" option for
> the 8x and 9x CPUs but not for the 73.

At least some 11/73 machines use the same CPU as the 11/83, so it is
present on some 11/73 machines.

> In any case, since the option settings for 50/60/800 hz are visible in
> a processor register (xx177520) I don't need to detect the setting in
> a timing loop. It's just a matter of a CPU and CSR detect.

Right.

> At present CPU support for RUST systems hasn't advanced beyond the
> 11/73. Later stuff is on the TODO list, but until someone who can also
> test the code requests the functionality there are better ways to
> waste my time.

:-)

>> And I'm maybe a little surprised that RT-11 don't use WAIT, but then
>> again, it's a simple single-user system, so it might not be totally
>> shocking that it don't use WAIT.
>
> According to SimH documentation the SET CPU IDLE code benefits RSX and
> RSTS but not RT-11 or UNIX. Unix is not a single-user operating
> system. I'm not sure about the many other operating systems written
> for the PDP-11. You note elsewhere that a later version of BSD
> supports WAIT, but Bob Supnik is probably talking about "Unix" Unix.

Just checked Unix V7, it also uses WAIT.

> RT-11 is definitely a multi-task/job system. Late versions of the
> system support "system jobs" running just about any system program
> (I've never actually used the feature though). So, if multi-process is
> a reason for WAIT, then it applies equally to RT-11.
>
> In any case, it's more a question of single-CPU than it is single-
> user. There's no particular benefit to using WAIT in a single-CPU
> configuration. Up until 2006 the instruction was effectively ignored
> by SimH and is still ignored out-of-the-box for SimH.

Actually, there is not much of a point for WAIT even in multiprocessor
systems. There is a reason why the VAX don't have a WAIT.
WAIT is actually only really nice to have when you are emulating the
CPU, since at a WAIT, you can stop processing until some external event
happens.
The biggest reason for using WAIT on a real PDP-11 is that when the WAIT
is executing R0 is placed on the data bus, and thus you have a nice and
convenient way of displaying something on the front panel of computers
that have that, and yet have that bludder away as the CPU have more work
to do.
There is even one or two machines that have a display that can show
values, but as far as I can remember, didn't work with a switch register
CSR (the 11/60 being one, if I remember right). So actually writing to
the switch register wasn't possible, but having idle loops on the system
show some pattern on the front panels were rather popular... And I
thought the RT-11 also did, but looking at the code, I'm unclear if
RT-11 did, and if it did, then how...

> It's not necessary for a system to use every feature provided by the
> hardware architecture. For example, the original planned use of
> interrupt vectors has essentially been ignored by RT-11 and RSX for
> years which uniformly take interrupts at PR7 and then lower priority
> to the device level rather than letting the vector do that job as
> originally planned. Then there's the PDP-11 virtual memory feature,
> not to forget MARK.

The PDP-11 virtual memory is extensively used by most OSes on the
PDP-11. Are you thinking of the potential on some machines to implement
demand paging?

And please lets forget the MARK. ;-) It is incompatible with I/D space...

>> Do you know how the idle loop displays anything on the switch register
>> in RT-11? Does it actually write to the switch register? Do you know
>> where in the code it is? Trying to look a little at the RT-11 sources...
>
> A long, long time ago, when I was a young coder, I could more-or-less
> recite the RT-11 monitor code from memory, and yes, the idle loop code
> is still in the sources even though switch registers are long gone.

I hope you understand my question better based on the discussion of the
WAIT instruction above.

> As discussed in our earlier threads, I usually don't waste my time
> presenting details of RT-11 in our discussions since you generally
> don't respond (beyond snipping), but since you ask I'll summarise my
> fuller response to Glenn here.

I usually have very little to contribute on RT-11 specific things. In
this case I was wondering how RT-11 played with idle loop displays on
the front panel, which is (on other systems) based on the behavior of
the WAIT instruction. Since RT-11 appears to not use WAIT, this becomes
a rather relevant question. But it is a small detail, and not bearing
much relevance on RT-11 in a larger picture.
I'm basically curious on how RT-11 does it, if it don't use WAIT. Do it
write to the switch register (well, maybe it is called the display
register, I can't remember and am too lazy to check that one up right
now, I'm sure you know what I'm talking about), or does it have some
other trick?

> (I'm heartened to see that you're finally reading the RT-11 sources.
> Welcome to the bright side of the road comrade :-)

I've read through a bunch of RT-11 before. I don't remember if it was
you or someone else I had a discussion with, where I needed to figure
out how USR and file operations work, in the face of potentially
multiple programs calling it.

Bright side... I don't know. It's always nice to read PDP-11 code, and
you can always learn a trick or two. But I definitely prefer the RSX
code. :-)

>> And even the line clock type can actually give you other frequencies, as
>> I mentioned above, depending on which machines you have.
>
> You mentioned one other "line clock" frequency only (800hz), not
> plural "frequencies", but it's not necessary to autodetect that
> frequency since the information in that case is available in a
> processor register.

Caught me. :-)
I don't know if there are other frequencies that you might hit or not.
My point was that I *know* of at least one other frequency. Actually,
since we're talking line frequency, it can be more or less anything.
Just because Europe use 50 Hz, and the US 60 Hz don't mean we've covered
the whole world on the questions of what line frequencies might exist.

> Indeed, despite your vociferous objections and invented issues there
> is *no* problem. For most machines the feature automatically detects
> the line frequency. If not, it fails benignly. It doesn't apply to
> virtual ports or dynamic runtime changes. It doesn't need to detect
> 800hz. It can be overriden with a .INI file or the startup command
> file.

You might think I'm making up imaginary problems. I (obviously)
disagree. This is not meant as an attack on you, and I hope you don't
take it that way.
I'm pointing out ways your code can fail, and you just say that in real
life you haven't been bitten. Good for you. Does that mean it can't
happen? I think it can.
There are plenty of examples in the real world where designs in code
have suddenly failed because of a scenario that was considered unlikely
enough to be ignored when the code was written.

> I know that my European and Australian 50hz customers would have loved
> to have had the feature back in the 80s. I only came up with the
> feature when I decided to rejuvinate my systems over the last decade
> to introduce some of more beneficial recent operating systems ideas,
> and one of those good ideas is that systems should figure out for
> themselves what hardware they have without bugging users.
>
> Are we done yet? Can we find something else to chew? :-)

I'm almost never done. Haven't you figured that out yet? :-)

[Johnny Billquist]

Right.

>> Or, what version of Unix are you referring to? I'm looking at (and
>> using) 2.11BSD. I haven't really checked older versions.
>
> I'm quoting from the SimH documentation (that I've very recently found
> a reason to reread :-) where Bob Supnik says that the use SET CPU
> IDLE "will work for RSTS/E and RSX-11M+ [sic], but not for RT-11 or
> UNIX." I assume that that translates to the (correct) use of WAIT
> since SET CPU IDLE is hooked to the WAIT instruction.
>
> The sources for the earlier versions of Unix are available on the web
> if you want to find more detail about their usage, but I'm sure you
> know that :-)

Yes. And I decided to do just that, and V7 also uses WAIT. I do not know
why Bob wrote what he did in the documentation.
I figured out the command in Simh because of just the cpu hogging when I
booted 2.11BSD, which is why I knew a little about it already. More
digging have not changed anything so far.
The most interesting tidbit so far have been your information that RT-11
don't use WAIT, and I haven't been able to find any use of WAIT after
searching through RT-11 after you wrote that. Which in turn led me to my
curious question of what RT-11 do to display some idle pattern on the
front panel of machines that have such a thing. Still curious about that
one, and my first searching through the sources didn't find me any idle
pattern display in RT-11 at all.

But on a different take - why don't you patch RT-11 to use WAIT, and
then have RUST use that to release the CPU instead of implementing a
whole new API for this? You still need to patch RT-11 to use that API,
and by using WAIT instead, you also gain the potential of all other
PDP-11 OSes also getting the benefit, without even having to modify the
OSes?

[Bob Koehler]

In article <jf9hac$7ol$2...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>
> I actually have never seen a card punch interface for a DEC machine. I
> assumed it was mostly because card were punched on terminals, and then
> loaded into the machine. Cards were not used to store data, as far as I
> know, and thus there wasn't much need for a puncher on the machine.

CR11 UNIBUS interface card reader, for which VMS had it's only input
symbiont, only supported on VAX, and for which DCL recognized both
LOGIN and PASSWORD as commands.

We had two of these connected to DECSYTSEM 20 systems. The original
contractor had not wanted any, the customer thought all computers
had to have them. "How else are the programmer's going to give
you thier code, on tape?" They agreed to just put them on the two
DECSYSTEMs and see if they were really needed. (Everything else had
been bid as various PDP-11, but on the last round the PDP-11/70 were
respecified as "PDP VAX 11/780".)

We ended up using them on rare occasion to read in 3 card ephemeris
points, supplied by the Navy, for our spacecraft. Normally we read
in ephemeris tapes provided by old IBM mainframes.

[Bill Gunshannon]

In article <FJJw1FEy$A...@eisner.encompasserve.org>,

koe...@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <jf9hac$7ol$2...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>>
>> I actually have never seen a card punch interface for a DEC machine. I
>> assumed it was mostly because card were punched on terminals, and then
>> loaded into the machine. Cards were not used to store data, as far as I
>> know, and thus there wasn't much need for a puncher on the machine.
>
> CR11 UNIBUS interface card reader, for which VMS had it's only input
> symbiont, only supported on VAX, and for which DCL recognized both
> LOGIN and PASSWORD as commands.

That's a reader, not a punch.

>
> We had two of these connected to DECSYTSEM 20 systems. The original
> contractor had not wanted any, the customer thought all computers
> had to have them. "How else are the programmer's going to give
> you thier code, on tape?" They agreed to just put them on the two
> DECSYSTEMs and see if they were really needed. (Everything else had
> been bid as various PDP-11, but on the last round the PDP-11/70 were
> respecified as "PDP VAX 11/780".)
>
> We ended up using them on rare occasion to read in 3 card ephemeris
> points, supplied by the Navy, for our spacecraft. Normally we read
> in ephemeris tapes provided by old IBM mainframes.

I agree with Johnny. I have looked for both a card reader and a card punch
to add to my PDP-11 collection. I have never found a CR-11 that I could
get. And I have never found any reference to a card punch at all.

Of course, I would also love to find an OPSCAN-20. I once wrote software
for that on a PDP-11. :-)

bill


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[paramucho]

On Fri, 20 Jan 2012 17:48:57 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>>> How do you detect emulation or a DEC programmable clock this way?
>>
>> The other conditions aren't detected with a timing loop...you seem to
>> be talking about general detection and timing-loop detection all at
>> the same time...or are we in alternate universes again...
>
>I was responding to your comment above, which I did include above my
>question. You said you detect other conditions, including emulators and
>the presence of a DEC programmable clock.
>So I just asked how you detected those ones. I thought that was a very
>straight forward question.

I was confused because you asked how I detected emulation or a
programmable clock "this way", which sounded like you were asking how
I detected them using a timer loop.

I posted the code for the emulation detection earlier in this thread.
My strategy, from memory, is to write some values into MMU SR0 and
then look at the results. It's not a particularly great test for a
couple of reasons.

(1) it only works if the emulated CPU has memory management. That
doesn't worry me too much because there's no reason to run any RUST
system without the default memory management setting.

(2) E11 doesn't really implement SR0 at the moment, so I'll be screwed
if it ever does so. That doesn't worry me too much because there's no
real reason for JW to add the code.

(3) I don't perform the test if there's a bootstrap module at I/O
pagte 173000. Neither SimH or E11 emulate the device, or at least, not
by default. I don't know why I implemented that restriction. O/S's are
just conservative by nature.

The programmable clock is detected just like all the other system
registers: you look to see if the I/O address of the relevant CSR
answers. There's nothing particularly fancy going on. I managed to put
together some reasonably well-tested detection code back in the 80s
and I still rely on it these days. The good thing about having
customers was that you got a lot of testing done...

RUST/XM has pages and pages of detection routines. It does all the
usual things, as I've stated, but I'd like it to do more in terms of
recognising the available devices. At present I handle device
detection with special routines in each driver.

RUST/XM begins with a general environment scan. The code is
semi-independent and can be compiled as a separate ENV utility. We
sometimes gave potential clients ENV so that could check in advance if
their computer setup was a suitable machine.

ENV attempts to do as many of the checks as possible without accessing
the I/O page or using kernel-only instructions. One of the ways it
does this is by testing for lots of the processor differences listed
at the back of the PDP-11 processor handbooks. It also tests for VAX
compatibility mode.

There are other peculiarities...

<snip>

>> According to SimH documentation the SET CPU IDLE code benefits RSX and
>> RSTS but not RT-11 or UNIX. Unix is not a single-user operating
>> system. I'm not sure about the many other operating systems written
>> for the PDP-11. You note elsewhere that a later version of BSD
>> supports WAIT, but Bob Supnik is probably talking about "Unix" Unix.
>
>Just checked Unix V7, it also uses WAIT.
>

<snip>

>There is even one or two machines that have a display that can show
>values, but as far as I can remember, didn't work with a switch register
>CSR (the 11/60 being one, if I remember right). So actually writing to
>the switch register wasn't possible, but having idle loops on the system
>show some pattern on the front panels were rather popular... And I
>thought the RT-11 also did, but looking at the code, I'm unclear if
>RT-11 did, and if it did, then how...

See my detailed reponse in my other reply.

>> It's not necessary for a system to use every feature provided by the
>> hardware architecture. For example, the original planned use of
>> interrupt vectors has essentially been ignored by RT-11 and RSX for
>> years which uniformly take interrupts at PR7 and then lower priority
>> to the device level rather than letting the vector do that job as
>> originally planned. Then there's the PDP-11 virtual memory feature,
>> not to forget MARK.
>
>The PDP-11 virtual memory is extensively used by most OSes on the
>PDP-11. Are you thinking of the potential on some machines to implement
>demand paging?

Yes, demand paging. There for the taking. Has any system ever used it?
I sometimes think about giving it a shot.

>And please lets forget the MARK. ;-) It is incompatible with I/D space...
>
>>> Do you know how the idle loop displays anything on the switch register
>>> in RT-11? Does it actually write to the switch register? Do you know
>>> where in the code it is? Trying to look a little at the RT-11 sources...
>>
>> A long, long time ago, when I was a young coder, I could more-or-less
>> recite the RT-11 monitor code from memory, and yes, the idle loop code
>> is still in the sources even though switch registers are long gone.
>
>I hope you understand my question better based on the discussion of the
>WAIT instruction above.

Yes.

>> As discussed in our earlier threads, I usually don't waste my time
>> presenting details of RT-11 in our discussions since you generally
>> don't respond (beyond snipping), but since you ask I'll summarise my
>> fuller response to Glenn here.
>
>I usually have very little to contribute on RT-11 specific things. In
>this case I was wondering how RT-11 played with idle loop displays on
>the front panel, which is (on other systems) based on the behavior of
>the WAIT instruction. Since RT-11 appears to not use WAIT, this becomes
>a rather relevant question. But it is a small detail, and not bearing
>much relevance on RT-11 in a larger picture.
>I'm basically curious on how RT-11 does it, if it don't use WAIT. Do it
>write to the switch register (well, maybe it is called the display
>register, I can't remember and am too lazy to check that one up right
>now, I'm sure you know what I'm talking about), or does it have some
>other trick?

See the other detailed response.

<snip>

>Caught me. :-)
>I don't know if there are other frequencies that you might hit or not.
>My point was that I *know* of at least one other frequency. Actually,
>since we're talking line frequency, it can be more or less anything.
>Just because Europe use 50 Hz, and the US 60 Hz don't mean we've covered
>the whole world on the questions of what line frequencies might exist.

Well, there's *only one* other known standard line clock frequency,
and we see that in the systems and the emulators. Non-standard
hardware is always treated differently but I always attempt to fail in
some non-critical manner with work-arounds. If there are problems
beyond that then it's time to debug and redesign.

>> Indeed, despite your vociferous objections and invented issues there
>> is *no* problem. For most machines the feature automatically detects
>> the line frequency. If not, it fails benignly. It doesn't apply to
>> virtual ports or dynamic runtime changes. It doesn't need to detect
>> 800hz. It can be overriden with a .INI file or the startup command
>> file.
>
>You might think I'm making up imaginary problems. I (obviously)
>disagree. This is not meant as an attack on you, and I hope you don't
>take it that way.

I don't take it as an attack at all. I enjoy talking details and don't
mind being hammered for inaccuracies. It keeps the PDP-11 area of my
brain a little sharper. However, I do find there's an excess of
repetition and overstatement at times. It means that responding
becomes a longer, more verbose process. I seem to be retyping the same
things over and over.

>I'm pointing out ways your code can fail, and you just say that in real
>life you haven't been bitten. Good for you. Does that mean it can't
>happen? I think it can.
>There are plenty of examples in the real world where designs in code
>have suddenly failed because of a scenario that was considered unlikely
>enough to be ignored when the code was written.

Of course all new code can fail. But somethings are worth putting out
there. You win some, you lose some, and you patch the rest. My company
always tried to extend the ease-of-use of systems and that involved
taking calculated risks, but those risks were tempered by providing
overrides and workarounds etc.

Back in the eighties I had commercial, competitive goals and full
compatibility with RT-11 was the primary goal. These days I don't have
those pressures and I like to try more innovation. It's not like I
have a thousand customers to deal with. I know that there's a regular
stream of people going to to my download page, but whether anyone is
actually using the systems these days, I have no idea, beyond one or
two.

>> I know that my European and Australian 50hz customers would have loved
>> to have had the feature back in the 80s. I only came up with the
>> feature when I decided to rejuvinate my systems over the last decade
>> to introduce some of more beneficial recent operating systems ideas,
>> and one of those good ideas is that systems should figure out for
>> themselves what hardware they have without bugging users.
>>
>> Are we done yet? Can we find something else to chew? :-)
>
>I'm almost never done. Haven't you figured that out yet? :-)

We definitely need a bigger bone.

Ian

[Tim Shoppa]

On Jan 18, 1:03 am, paramu...@hotmail.com (paramucho) wrote:
> In any case, an emulator is not equivalent to a processor type since
> SimH and E11 support a range of PDP-11 CPUs.

Emulation of interesting (not textbook) machines might be a special
case of Godel's theorem. Working a lot like Hofstader's example of a
record that states "This record cannot be played on record player x"
and Hofstadter's thought of a record-player that has a record-player
emulator inside it. As soon as the emulator author finds out there's a
difference between the real world and emulation, such that software on
the emulated system can know it's not on the real system, the author
can refine the emulator so the software cannot tell anymore.

But without a formal and complete definition of the "real hardware"
that the "real hardware" actually followed, the game can probably be
repeated indefinitely. There will be a corner case of the real machine
not following the textbook architecture spec. In an academic way
that's what makes the whole emulator authoring process so interesting.
(This is something that the seller of commercial emulators could
probably never admit in public!)

[paramucho]

On Fri, 20 Jan 2012 17:54:16 +0100, Johnny Billquist
<b...@softjar.se> wrote:

<snip>

Here's the routine you were looking for, preceded by the quotes AntonC
added when he wrote the FB monitor. Effectively it uses a counter.
Below the lights routine is the patch point (..NULKJ:) where a WAIT
could be patched in. However, as stated variously, the patch point was
never used by the standard distributions or described. The patch point
is used by a performance monitor. The alternate code is for the RT-11
emulator running under RSX, RTEM.

;+
; "A source of innocent merriment!"
; - W.S. Gilbert, "Mikado"
; "Did nothing in particular, and did it very well"
; - W.S. Gilbert, "Iolanthe"
; "To be idle is the ultimate purpose of the busy"
; - Samuel Johnson, "The Idler"
; "I got plenty of nothin', and nothin's plenty fo' me!"
; - George and Ira Gershwin, "Porgy and Bess"
;-
30$:
.IF NE LIGH$T
DEC (PC)+ ;The RT-11 lights routine!
LITECT: .WORD 1
BNE ..NULJ ;Not too often
ADD #<512.>,LITECT ;Reset count, clear carry
40$: ROL 70$ ;Juggle the lights
BNE 50$ ;Not clear yet
COM 70$ ;Turn on lights, set Carry
50$: BCC 60$ ;Nothing fell off, keep moving
ADD #<100>,40$ ;Reverse direction
BIC #<200>,40$ ;ROL/ROR flip
60$: BIT #<LIGHT$>,CONFG2 ;Does CPU have a light register?
BEQ ..NULJ ;No
MOV (PC)+,@(PC)+ ;Put in lights (for 11/45)
70$: .WORD 0, SR
.ENDC ;NE LIGH$T

..NULJ::
.IF EQ RTE$M
;;; WAIT ;Nothin' to do, so don't
NOP ;Nothin' to do, so don't
.IFF ;EQ RTE$M
NOP ;Let the host do the waiting
.ENDC ;EQ RTE$M
NOP ;Second pad instruction
.BR SCNALL ;Drop into ready job scan loop setup
............

;+
; SCNALL (*** RTEM-11 HOOK ***)
; The RTEM-11 bootstrap hooks this location as:
;
; MOVB #<FJOBS!200>,-(SP) ; Job number on top of stack
; CALLR $IDLP ; Enter the RTEM idle loop
;
; The $IDLP routine is located in the RTEM-11 linkage
; routines. This hook allows RTEM-11 to correctly
; become idle, by waiting on the idle loop event flag.
;-

SCNALL:: ;(*** RTEM-11 HOOK ***)
MOVB #<FJOBS!200>,INTACT ;Do a complete scan
BR EXUSLK ;Back into LOOKFOR loop
............

.DSABL LSB



>But on a different take - why don't you patch RT-11 to use WAIT, and
>then have RUST use that to release the CPU instead of implementing a
>whole new API for this? You still need to patch RT-11 to use that API,
>and by using WAIT instead, you also gain the potential of all other
>PDP-11 OSes also getting the benefit, without even having to modify the
>OSes?

There's a fundamental misunderstanding here. The two RUST operating
systems I work on these days do not include any RT-11 source code. The
RUST distribution kits do not include or require any RT-11 binaries.
They are completely separate source and binary systems.

Effectively, they are stand-alone operating systems which happen to
support RT-11 programs with compatible environments, EMTs, disk
structures and the like. The RUST/SJ monitor and RUST/XM kernel
themselves are completely separate source streams as well, so I've
implemented most of the things we've been talking about (interrupt
entry, fork, idle, etc, etc) two or more times.

Now, back in the eighties, when I had a company, the systems we
supplied did rely on RT-11 device drivers and utilities, but even then
they ran with completely separate operating system sources and
kernels. About a decade ago I began the slow process of reimplementing
the drivers and utilities to remove all reliance on RT-11.

Most of the major utilities and drivers have been completed. The
significant exceptions are MACRO, LINK, LIBR, SYSMAC.SML so it's
necessary to copy those components to a RUST system if you want to do
development. I've been planning to do MACRO, LINK and LIBR for years,
but other stuff keeps happening. In fact, the one thing I really don't
want to reimplement is SYSMAC.SML. It's a can of worms inside a can of
worms.

Some of the reimplemented utilities are missing this or that function
or need a bit more work. Most of them also have additional
functionality, and there are additional utilities and drivers. My KED
implementation is a bit weak in the I/O department. I haven't done any
of the magtape drivers ('cos I don't have physical magtapes).

When I talk about DEC RT-11 in these threads I'm in fact going back to
my very early days when I lived and breathed RT-11. But I haven't been
a daily RT-11 user since the early eighties because all my development
etc took place on my own systems (with our own network software etc).
But for over a decade then my daily task consisted of reimplementing
or extending the RT-11 architecture, or, in the case of RUST/XM,
reimplementing RT-11 on a PDP-11 with an kernel architecture based
(loosely) on VMS. Some of the RT-11 architecture is shared with RSX,
such interrupts and forks, and some of it simply copies RSX, such as
the PLAS API.

Now to the actual point you raise. The little API I mentioned does
quite a few other tasks as well. It was a matter of minutes adding the
CPU idle code, and that was the primary reason I chose to use the API
for that task one evening when I got sick of the CPU hogging behavior.

RT-11 programs have an unfortunate habit of sitting in .TTYIN loops
where they just loop looking to see if a character has been typed. So,
in many cases an RT-11 system is simply never idle. This problem can't
be solved for RUST/SJ, the single-user system, because of space, and
in fact the idle routine is called from the terminal input path on
RUST/SJ. It's a hack.

On RUST/XM it's a different story. To obtain effective multi-user
performance RUST/XM examines the .TTYIN behavior of processes,
detects looping apps, and puts them in an event-wait state when
detected (users and programs can override the behavior). It would be
quite possible to add WAIT to RUST/XM as the default NULL process (so
to speak) and I'll put it on my TODO list. I'll probably only switch
that code on if I detected an emulator--and someone else's emulator at
that since my V11 emulator ignores WAIT instructions and I have no
plans to improve it (indeed, I'm thinking about replacing the guts of
my emulator with SimH--it's got so much more functionality and it's
fast enough these days).

Ian

[paramucho]

In another post in this thread I presented the code I use to detect
the SimH and E11 emulators, which I do by examining the behavior of a
wierd little corner of the machine. When I did it I mentally went
through the scenario you outlined. Of course the authors of SimH and
E11 can look at my code and remove the anomalies, or just plain
straight screw me with a different anomaly.

A few years ago I decided implemented RT-11 compatible drivers for my
operating systems. I first got them working on real iron. Later I
tested them on SimH and E11 and found myself altering the drivers to
survive on the emulators. In a sense, I was treating the emulators as
alternate hardware implementations.

The ultimate competitor for PDP-11 emulators is XXDP and it's warrior
diagnostics, which might (if I'm hopeful) explain a little obsession I
have with XXDP. But we can also think of the XXDP test programs as
"emulations" themselves

But you're right. This is a real-world/unreal-world Turing Test living
itself out.


Ian

[Bob Eager]

On Sat, 21 Jan 2012 13:16:47 +0000, paramucho wrote:

> Here's the routine you were looking for, preceded by the quotes AntonC
> added when he wrote the FB monitor. Effectively it uses a counter.

I always did love the wonderful comments in the monitor source; they
encouraged me to do similar in other systems!

--
Use the BIG mirror service in the UK:
http://www.mirrorservice.org

*lightning protection* - a w_tom conductor

[glen herrmannsfeldt]

In vmsnet.pdp-11 Tim Shoppa <tsh...@gmail.com> wrote:
> On Jan 18, 1:03 am, paramu...@hotmail.com (paramucho) wrote:
>> In any case, an emulator is not equivalent to a processor type since
>> SimH and E11 support a range of PDP-11 CPUs.

> Emulation of interesting (not textbook) machines might be a special
> case of Godel's theorem. Working a lot like Hofstader's example of a
> record that states "This record cannot be played on record player x"
> and Hofstadter's thought of a record-player that has a record-player
> emulator inside it. As soon as the emulator author finds out there's a
> difference between the real world and emulation, such that software on
> the emulated system can know it's not on the real system, the author
> can refine the emulator so the software cannot tell anymore.

Emulators are one thing, virtual machines another. At least as I
understand it, the idea of a virtual machine is running on a similar
host, and only emulating the differences, usually the privileged
instructions. I first saw this described in the 68020 days, as the
68020, if I remember right, allows an unprivileged program to see
the privilege flag bit.

The usual exception, both for user programs running on a variety
of systems, and for systems running in a virtual machine, is that
they shouldn't be time dependent.

> But without a formal and complete definition of the "real hardware"
> that the "real hardware" actually followed, the game can probably be
> repeated indefinitely. There will be a corner case of the real machine
> not following the textbook architecture spec. In an academic way
> that's what makes the whole emulator authoring process so interesting.
> (This is something that the seller of commercial emulators could
> probably never admit in public!)

There is an emulator story I remember from 1976, though not at all the
machine that was being discussed, about how the emulator had to emulate
bugs in the original. I believe that has been repeated over and over
again in the emulation world, both hardware (supposedly compatible
processors that weren't) and software emulation.

I seem to remember some clone 8080 that wouldn't run microsoft basic,
which it seems used some undocumented flag bit.

One big problem in modern emulation of older systems is that they
often run too fast. Timing loops run faster than their author ever
imagined, possibly resulting in divide by zero. An I/O device complete
an I/O operation faster than expected. Things like that. (Or just game
programs that run faster than human responses allow for.)

-- glen

[Bob Eager]

On Sat, 21 Jan 2012 14:25:37 +0000, glen herrmannsfeldt wrote:

> One big problem in modern emulation of older systems is that they often
> run too fast. Timing loops run faster than their author ever imagined,
> possibly resulting in divide by zero. An I/O device complete an I/O
> operation faster than expected. Things like that. (Or just game programs
> that run faster than human responses allow for.)

The VAX SIMH is a case in point. The power-on diagnostics in the ROM ran
too fast; it had to be modified so that access to ROM ran more slowly
than to RAM.

[Johnny Billquist]

On 2012-01-21 14:16, paramucho wrote:
> On Fri, 20 Jan 2012 17:54:16 +0100, Johnny Billquist
> <b...@softjar.se> wrote:
>
> <snip>
>

>> The most interesting tidbit so far have been your information that RT-11
>> don't use WAIT, and I haven't been able to find any use of WAIT after
>> searching through RT-11 after you wrote that. Which in turn led me to my
>> curious question of what RT-11 do to display some idle pattern on the
>> front panel of machines that have such a thing. Still curious about that
>> one, and my first searching through the sources didn't find me any idle
>> pattern display in RT-11 at all.
>
> Here's the routine you were looking for, preceded by the quotes AntonC
> added when he wrote the FB monitor. Effectively it uses a counter.

[...]

Ah. Thanks. I now see what they do. RT-11 writes to the switch register.
Cool. That works too, but gives a slightly different view and feel to
the idle pattern display used by other OSes. But it avoids using a WAIT.

Nice.

Also noticed that RTEM have an alternative idle loop, which signals out
to the emulator that it should go idle. Makes sense, as RTEM is not a
CPU emulator...

>> But on a different take - why don't you patch RT-11 to use WAIT, and
>> then have RUST use that to release the CPU instead of implementing a
>> whole new API for this? You still need to patch RT-11 to use that API,
>> and by using WAIT instead, you also gain the potential of all other
>> PDP-11 OSes also getting the benefit, without even having to modify the
>> OSes?
>
> There's a fundamental misunderstanding here. The two RUST operating
> systems I work on these days do not include any RT-11 source code. The
> RUST distribution kits do not include or require any RT-11 binaries.
> They are completely separate source and binary systems.

Ah. My mistake. I was thinking that you patched RT-11 to signal the idle
condition. I must admit that hadn't given RUST much thought, nor do I
know pretty much anything about them, except what you have mentioned a
few times. :-)

[Johnny Billquist]

On 2012-01-21 13:25, paramucho wrote:
> On Fri, 20 Jan 2012 17:48:57 +0100, Johnny Billquist<b...@softjar.se>
> wrote:
>
>
>>>> How do you detect emulation or a DEC programmable clock this way?
>>>
>>> The other conditions aren't detected with a timing loop...you seem to
>>> be talking about general detection and timing-loop detection all at
>>> the same time...or are we in alternate universes again...
>>
>> I was responding to your comment above, which I did include above my
>> question. You said you detect other conditions, including emulators and
>> the presence of a DEC programmable clock.
>> So I just asked how you detected those ones. I thought that was a very
>> straight forward question.
>
> I was confused because you asked how I detected emulation or a
> programmable clock "this way", which sounded like you were asking how
> I detected them using a timer loop.
>
> I posted the code for the emulation detection earlier in this thread.
> My strategy, from memory, is to write some values into MMU SR0 and
> then look at the results. It's not a particularly great test for a
> couple of reasons.

[...]

Gotcha.

> (3) I don't perform the test if there's a bootstrap module at I/O
> pagte 173000. Neither SimH or E11 emulate the device, or at least, not
> by default. I don't know why I implemented that restriction. O/S's are
> just conservative by nature.

Right. However, E11 (or rather JW) did provide me with one, as I had a
customer who had the monitoring code in RSX patched to jump to 173000 if
some component of the system failed in a fatal way, to make the system
reboot. Easiest when we moved them to E11 was to make sure we had a boot
rom which worked in E11 located at that address. So I have a couple of
E11 machines with data in those addresses. :-)

> The programmable clock is detected just like all the other system
> registers: you look to see if the I/O address of the relevant CSR
> answers. There's nothing particularly fancy going on. I managed to put
> together some reasonably well-tested detection code back in the 80s
> and I still rely on it these days. The good thing about having
> customers was that you got a lot of testing done...

Ah! That was too easy. :-)

>> There is even one or two machines that have a display that can show
>> values, but as far as I can remember, didn't work with a switch register
>> CSR (the 11/60 being one, if I remember right). So actually writing to
>> the switch register wasn't possible, but having idle loops on the system
>> show some pattern on the front panels were rather popular... And I
>> thought the RT-11 also did, but looking at the code, I'm unclear if
>> RT-11 did, and if it did, then how...
>
> See my detailed reponse in my other reply.

Yup. And the answer was/is that RT-11 write to the switch register CSR.

>>> It's not necessary for a system to use every feature provided by the
>>> hardware architecture. For example, the original planned use of
>>> interrupt vectors has essentially been ignored by RT-11 and RSX for
>>> years which uniformly take interrupts at PR7 and then lower priority
>>> to the device level rather than letting the vector do that job as
>>> originally planned. Then there's the PDP-11 virtual memory feature,
>>> not to forget MARK.
>>
>> The PDP-11 virtual memory is extensively used by most OSes on the
>> PDP-11. Are you thinking of the potential on some machines to implement
>> demand paging?
>
> Yes, demand paging. There for the taking. Has any system ever used it?

I have never seen any software make use of the possibility of demand
paging. Virtual memory however, is something most of them use. These two
things are not the same, but lots of people (and even Wikipedia) confuse
the two.

> I sometimes think about giving it a shot.

Hehe. Me too... It is tempting. Just as a proof of concept (atleast for me).
But I can't remember straight off my head if I figured this needed all
the access modes provided by the 11/70 MMU, or if you could make do with
the limited functionality of the J11 MMU.
I seem to remember that the 11/70 style was needed, but it might be that
it would just make life much easier.

>>> Are we done yet? Can we find something else to chew? :-)
>>
>> I'm almost never done. Haven't you figured that out yet? :-)
>
> We definitely need a bigger bone.

Point me to it...

[Johnny Billquist]

By the way, a reflection here. I note that the coding style in RT-11 is
rather different than in RSX. They seem much more "hackish" in RT-11.
Making use of all kind of shortcuts and tricky solutions. Lots of mixing
of data and code everywhere. Interesting, and rather different from what
I'm used to.

But it also makes it hopeless to ever have split I/D space. Did anything
in RT-11 ever used split I/D space?

Johnny

[paramucho]

On Sun, 22 Jan 2012 12:59:14 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>By the way, a reflection here. I note that the coding style in RT-11 is
>rather different than in RSX. They seem much more "hackish" in RT-11.
>Making use of all kind of shortcuts and tricky solutions. Lots of mixing
>of data and code everywhere. Interesting, and rather different from what
>I'm used to.
>
>But it also makes it hopeless to ever have split I/D space. Did anything
>in RT-11 ever used split I/D space?

In the unmapped monitors RT-11 programs and the O/S have had to
cohabit the same 28kw address space, so there has been enormous space
pressure on the system. Anything which saves a word of memory goes.
RT-11 developers were often given the job of just saving a few words
so that more functionality could be fitted into a fixed space.

Because of these constraints the code looks "hackish", however, these
hacks are not the result of hasty or sloppy thinking or individual
programmers doing their own thing. The RT-11 team remained fairly
constant over the years and knew the code intimately. I visited
Maynard a couple of times and was given a desk at the Mill and invited
to join some of their regular meetings in which functionality was
proposed, discussed and decided. They weren't cowboys.

The mixture of code and data is not as uncontrolled as it looks. At
one point RT-11 supported a ROMable monitor by using conditionals.

The RT-11 mapped monitor (RT-11/XM) is built on the same code base as
the unmapped montors. The later XM monitors support "virtual jobs"
which allows programs to run in their own full address spaces by
emulating RT-11 within RT-11, and with V5.6 they implemented I/D space
and supported supervisor mode. I can't say much more about it than
that because I have yet to examine the code.
<snip>

Ian

[Johnny Billquist]

On 2012-01-22 15:03, paramucho wrote:
> On Sun, 22 Jan 2012 12:59:14 +0100, Johnny Billquist<b...@softjar.se>
> wrote:
>
>> By the way, a reflection here. I note that the coding style in RT-11 is
>> rather different than in RSX. They seem much more "hackish" in RT-11.
>> Making use of all kind of shortcuts and tricky solutions. Lots of mixing
>> of data and code everywhere. Interesting, and rather different from what
>> I'm used to.
>>
>> But it also makes it hopeless to ever have split I/D space. Did anything
>> in RT-11 ever used split I/D space?
>
> In the unmapped monitors RT-11 programs and the O/S have had to
> cohabit the same 28kw address space, so there has been enormous space
> pressure on the system. Anything which saves a word of memory goes.
> RT-11 developers were often given the job of just saving a few words
> so that more functionality could be fitted into a fixed space.
>
> Because of these constraints the code looks "hackish", however, these
> hacks are not the result of hasty or sloppy thinking or individual
> programmers doing their own thing. The RT-11 team remained fairly
> constant over the years and knew the code intimately. I visited
> Maynard a couple of times and was given a desk at the Mill and invited
> to join some of their regular meetings in which functionality was
> proposed, discussed and decided. They weren't cowboys.

Oh! I didn't want to imply that it was sloppish. My usual experience is
that you need to keep your tongue even more straight in your mouth when
your code is tricky. Becoming sloppy at that point is an almost sure way
of getting into very bad bugs and unusable systems.

But a thing like:

DEC (PC)+ ;The RT-11 lights routine!
LITECT: .WORD 1
BNE ..NULJ ;Not too often
ADD #<512.>,LITECT ;Reset count, clear carry

is both tricky, and totally non-functioning if you have split I/D space.
(Just as one example from the code you posted.)

Neat and efficient, though. But not something you'd see in RSX, and not
something I would write myself.
Different style, as I said.

[Tim Shoppa]

That sort of adversarial mindset is what permeates Hofstadter's "this
record cannot be played on record player X" discussions too.

But just like Hofstadter's examples, I don't think the activity is
actually adversarial, I think it's more exploratory. When we discover
anomalies of a 40 year old machine that had never been documented
before, maybe that's how an archaeologist feels? The folks living in
ancient civilization never had the advantage of our mindset and
perspective, when they looked at their own cultures. That doesn't make
us superior to them but it might give us some context as to what's
going on in today's civiliazations.

Tim.

[glen herrmannsfeldt]

In vmsnet.pdp-11 Tim Shoppa <sho...@trailing-edge.com> wrote:
(snip)

> That sort of adversarial mindset is what permeates Hofstadter's "this
> record cannot be played on record player X" discussions too.

> But just like Hofstadter's examples, I don't think the activity is
> actually adversarial, I think it's more exploratory. When we discover
> anomalies of a 40 year old machine that had never been documented
> before, maybe that's how an archaeologist feels?

The person who gave me my first "System/370 Principles of Operation"
when I was in high school calls what we do compuarchaeology.
(I believe as one word.)

> The folks living in
> ancient civilization never had the advantage of our mindset and
> perspective, when they looked at their own cultures. That doesn't make
> us superior to them but it might give us some context as to what's
> going on in today's civiliazations.

And same for computer architecture.

-- glen

[paramucho]

Combatting that mindset is one reason I posted my "secret" code. I
would have had real difficulties doing that at certain times in the
past.

As another example, in music we think of the progress of a piece as a
kind of competition between opposite poles of the "tonic" and
"dominant", but in another culture the adversarial "dominant" is
thought of as the collegial "companion".

>But just like Hofstadter's examples, I don't think the activity is
>actually adversarial, I think it's more exploratory. When we discover
>anomalies of a 40 year old machine that had never been documented
>before, maybe that's how an archaeologist feels? The folks living in
>ancient civilization never had the advantage of our mindset and
>perspective, when they looked at their own cultures. That doesn't make
>us superior to them but it might give us some context as to what's
>going on in today's civiliazations.

The exploration is mutual. In a sense, an emulator is a program which
runs *on* the systems it emulates.

I think sometimes that the emulation process receives its legitimation
from both the complexity of the emulated process and from the human
effort previously expended on the original objects, i.e. the original
software and hardware. I'm exploring that a little bit, in a sense, by
writing *new* code for the objects: is the new code as valid as the
historic code?


Ian

[paramucho]

On Sun, 22 Jan 2012 17:15:48 +0100, Johnny Billquist <b...@softjar.se>

I mentioned above that a ROM version of RT-11 was released in the 80s.
For that version of the monitor the code would have read:

.ROM DEC LITECT,VALUE=1

Which would have expanded to the inline data for the non-ROM version,
as above,

DEC (PC)+
LITECT: .WORD 1

or to a data area reference for the ROM version, roughly:

.SAVE
.PSECT RTDATA
LITECT: .WORD 1
.RESTORE
DEC LITECT

But somewhere around V5.6 the .ROM macros were removed and the
original non-ROM inline code was reinstated. I/D support was added at
the same time, I think. So, I guess the I/D separation applies only to
user mode applications, not to the kernel. That would make sense
because I can't see how existing RT-11 device drivers could be easily
modified support I/D space.

As I said, I haven't looked at it in detail. Back in the eighties I
would have felt compelled to add compatible I/D space support to
SHAREplus (as RUST/XM was called then), but RT-11 V5.6, which was the
last DEC release, had a very low customer take-up and I don't think
there's more than a handful of apps out there which use the feature.
So, it's way down my TODO list.

Ian

[Tim Shoppa]

On Jan 21, 9:25 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> In vmsnet.pdp-11 Tim Shoppa <tsho...@gmail.com> wrote:
>
> > On Jan 18, 1:03 am, paramu...@hotmail.com (paramucho) wrote:
> >> In any case, an emulator is not equivalent to a processor type since
> >> SimH and E11 support a range of PDP-11 CPUs.
> > Emulation of interesting (not textbook) machines might be a special
> > case of Godel's theorem. Working a lot like Hofstader's example of a
> > record that states "This record cannot be played on record player x"
> > and Hofstadter's thought of a record-player that has a record-player
> > emulator inside it. As soon as the emulator author finds out there's a
> > difference between the real world and emulation, such that software on
> > the emulated system can know it's not on the real system, the author
> > can refine the emulator so the software cannot tell anymore.
>
> Emulators are one thing, virtual machines another.

That's an interesting tack. Hofstadter's analogy was the record player
that had a record player emulator in it, such that any damage a record
might do, can be found before being played on the real machine. You
want the emulated machine inside to be as much like the real one as
possible, but you don't want the real record player to be broken just
because the record broke the emulated record player.

Hofstadter seemed at least a little resigned to how the emulated
record player would never be quite like the real thing. But the
virtual machine seems to erase many lines. If the record breaks the
virtual machine does it also break the real machine (since the virtual
machine is in fact the real machine?)

[Jerome H. Fine]

>Johnny Billquist wrote:

I'm not entirely sure what your question is, Jerome...
But I'll make some comments anyway.

Very much appreciated.  I was away for a week.  I am catching up now.

On 2012-01-15 15:37, Jerome H. Fine wrote:

I have an interesting hardware question.

I have been looking at the results for the program RESORC.SAV in RT-11
with respect the MFPT instruction. When the J11 chip is used, the value
is 5 and the Maintenance Register at 177750 seems to determine what the
rest of the actual hardware supports.

Correct.

I thought it would also be helpful for the user to know if an emulator is being
used, either software or hardware, or if perhaps some other 3rd party hardware
CPU. I would probably target the various 3rd party boards as far as hardware
is concerned (such as QED and Mentec). For software emulators, I would
suggest that only the high end PDP-11 processors be supported (the DEC
CPUs which support the MFPT instruction) in order to keep things simple,
at least initially.

If an emulator wants to truly emulate a specific CPU, then you cannot just go and change the behavior of the emulator, since you will break the basic idea behind it.
As far as different implementations goes, what is the difference between an emulator and a "real" CPU? Both are running code to implement the PDP-11 architecture. It's just that if the emulator is running on an x86 (for example), the microcode happens to be identical to x86 assembler, whilst the J11 (for example) have a microcode CPU which we don't know much about, but it still executes the microcode instructions...

I actually agree with you.  The only reason that I mention the
MFPT instruction is that RT-11 ignores the high order byte
and I thought that I would ask if RSX-11 also ignores the
high order byte, along perhaps with RSTS/E.

An incomplete list of software emulators is:
SIMH
Ersatz-11

An incomplete list of hardware boards is:
QED - more than 1?
Mentec - at least 3
and I can remember at least 2 others, but not the company names.

You have Strobe Data, which I'm sure you'll remember now that I mention them.

Yes.  I seem to remember they were first.  Do you classify them as
a hardware or software emulator?  If my hazy memory is correct,
Strobe Data initially used the J11 chip on a board that plugged
into an ISA slot on a DOS machine.  Later, the J11 chips were
very difficult to obtain, so Strobe Data managed to do something
else.

When I first saw the emulation actually running RT-11, I was very
surprised.

Does anyone know how many boards and the names that
QED and Mentec produced.  Also, does the name Nissho
ring a bell?  I think they were a Unibus hardware emulator
or were they just high speed memory?

Right now the Logical Co. has a combined emulator called a
PDQ-1000 board which actually plugs into a Qbus which takes
only 4 slots, but includes CPU, memory and many controllers.

Yes... And...?

The reason that I specifically mention the PDQ-1000 is that while
it seems like a hardware emulator (since the final result is a Qbus
board), inside the hardware is actually a software emulator.

Thus far, the high order byte of the MFPT instruction always seems
to be zero and is currently ignored by the RESORC.SAV program.
Under SIMH and Ersatz-11, it would be trivial to use the high order
byte of the MFPT instruction to signify which software emulator is
being used.

Right, except then they wouldn't truthfully emulate a J11.

And basing your design on how one application in RT-11 works seems like an extremely bad idea.

I had my doubts as well, so I do agree with you.  But if no one else
uses the high order byte of MFPT, then it might be possible to
set a standard.

Can anyone who has a DEC (or non-DEC) PDP-11 system easily
available determine the actual value returned by the MFPT instruction?
As far as I know:

MFPT Value Hardware
1 PDP-11/44
3 PDP-11/24 (should be 2)
3 PDP-11/23
4 SBC-11/21
5 All J11 chips including 11/73, 11/83, 11/93

That is all the values that MFPT can return. (Or rather - all the values that were returned by any CPUs designed by DEC.)

Understood.  It would have been "nice" if DEC had supported
a more open concept, but since probably at least 50% (maybe
over 90%) of the emulators in use are SIMH and Ersatz-11,
it is probably not all that important any more.

I assume that it would be extremely difficult, probably not worth the
effort, to modify the high order byte of the MFPT instruction at this
point for the 3rd party PDP-11 CPU boards, such as from Mentec.

Some Mentec boards use a J11. You can guess what they return. For the other boards, they also seem to pretend to be J11 CPUs, which is a bit sad, but that can't be helped.

And of course, the result is that they reported a particular DEC
CPU as being used.  What were the names of all of the Mentec
boards and their primary difference from each other?

Can anyone comment on this assumption? Might there be another
way for hardware to the tell a user which 3rd party board is being
used as a PDP-11?

Please differ between which *board* is being used, as opposed to which CPU. MFPT will only tell you which CPU is used, not which board.

Yes, you are correct.  Even DEC used the J11 chip
on many different boards.

I have the impression that it would no longer be either
useful or reasonable to attempt to identify any Mentec
or QED boards at this point.

The other possibility is to use the Maintenance Register at 177750,
although I suspect that there might not be any more bit available.

That register is specifically designed to tell you which board you have, as opposed to MFPT, which tells which CPU.
And yes, there are bits left.
In the mainenance register, you have 4 bits allocated to system type.
(Note, not CPU type, system type.)
0 - 11/73
1 - J11-A (M11, N11)
2 - KDJ11-B (11/73, 11/83)
3 - KXJ11 (11/73)
4 - 11/53
5 - 11/93

This I collected from the system identification code in RSX. The 0 is not explicitly stated to be an 11/73, rather, the code checks for the values 1-5, and if none of those, it assumes it is an 11/73. I very much doubt any DEC boards ever used any codes above 5, although you can have up to 15.

The CPU identification code in RSX is very useful to read on how to identify what kind of system it is.

Essentially, it goes like this:
1) Check if the SYSID registers exist
1.1) If yes, this is an 11/70 or 11/74.
1.2) Check if high bit of PDR is usable.
1.3) If yes, this is an 11/74. If no, this is an 11/70
2) Try MFPT
2.1) If it worked, we have a basic idea of system
2.2) 1 - 11/44
2.3) 3 - Possibly 11/23B or 11/24
2.3.1) Read maintenance register
2.3.2.1) If that succeded - check if bits 4-7
2.3.2.2) If 4-7 = 0 it is an XT system. Treat as unknown system.
2.3.3) Try writing to SWR
2.3.3.1) If that fails - system is an 11/23B
2.3.3.2) If that succeeds - system is an 11/24
2.4) 5 - J11 Based machine
2.4.1) Read maintenance register, look at bits 4-7
2.4.1.1) If that fails - unknown machine
2.4.1.2) 4 - 11/53
2.4.1.3) 3 - KXJ11 based 11/73
2.4.1.4) 1 - Real J11-A?
2.4.1.4.1) Check if writing to kernel PDR7 change state of W bit of register to written.
2.4.1.4.1.1) If yes, we have an M11
2.4.1.4.2) Try MED instruction
2.4.1.4.2.1) If it works, we have an N11
2.4.1.4.3) Unknown type of CPU
2.4.1.5) 2 - KDJ11-B type. (11/83, 11/84)
2.4.1.6) 5 - KDJ11-E-type. (11/93, 11/94) (Codenamed Thunderbird apparently)
2.4.1.7) All others are called 11/73 (But the code will actually store model as 11/9x)
3) If MFPT fails, M+ states that system must be 11/60, 11/34, 11/45, LSI-11, 11/04, 11/05, 11/10, 11/15, 11/20 or 11/40.
3.1) Check 11/60 MED instruction
3.1.1) If that works, it is an 11/60
3.2) Check 11/34 MFPS instruction
3.2.1) If that works, it is an 11/34
3.3) Check 11/45 PIRQ register
3.3.1) If that exist, it is an 11/45
3.4) Of the rest, RSX-11M-PLUS only works on the 11/40

Also, for the machines which both have Qbus and Unibus variants, the code then goes on to check if the machine have a Unibus map, and if so, changes it to the Unibus version of the CPU.

All with the reservation that I might have missed something, written something down wrong in my transcribing the code into the rules above, and that this is obviously not enough to actually implement it, since the details for some of these steps are rather intricate in actual execution.

Anyway. If you have something that intends to implement a J11, it should do the same thing a J11 does, which means MFPT should return 5. Anything else is bad.
The maintenance register is a possible place to put something else in, if you just want to identify your actual system differently, but once more, if you really want to emulate an existing system, you cannot touch that register either.

If you want some "foolproof" way of detecting that you are inside an emulated machine, I'd say that adding a new instruction from the unused opcodes is probably a better idea. I wouldn't expect anything to actually try using an undefined opcode anyway, so no existing code should be hurt by it. And your "new" code will also work on real machines, in that you will instead get a trap if you try that instruction.

Your suggestion to use an instruction code which is presently
illegal is actually almost trivial in Ersatz-11.  John Wilson explicitly
supports adding code for new instructions.  Well, I guess it
is not exactly trivial, but I could probably write and test the
code for the required DLL in less than a week.

I imagine the same would apply to SIMH.  it would be useful
if there could be an agreement on a standard!!!!!!!!!!!!!

Other emulators or 3rd party hardware implementations which
are no longer supported by their original manufacturers would be
much more difficult, if not impossible, at this point.

What about RUST?  Could that support a new instruction as well?

Jerome Fine

[Jerome H. Fine]

>paramucho wrote:

>On Sun, 15 Jan 2012 09:37:21 -0500, "Jerome H. Fine" wrote:

I have an interesting hardware question.

I have been looking at the results for the program RESORC.SAV in RT-11
with respect the MFPT instruction.  When the J11 chip is used, the value
is 5 and the Maintenance Register at 177750 seems to determine what the
rest of the actual hardware supports.

I thought it would also be helpful for the user to know if an emulator 
is being
used, either software or hardware, or if perhaps some other 3rd party 
hardware
CPU.  I would probably target the various 3rd party boards as far as 
hardware
is concerned (such as QED and Mentec).  For software emulators, I would
suggest that only the high end PDP-11 processors be supported (the DEC
CPUs which support the MFPT instruction) in order to keep things simple,
at least initially.
    

<snip>

Modifying the MFPT instruction is not the right way to go. CPU
software detection is a delicate business and that process should not
be interfered with directly.
  

As I already answered with Johnny, I have my own
doubts for using MFPT.  I do like his suggestion of a
currently illegal instruction code (a new hardware
instruction) which an actual DEC  J11 chip would
need to trap.

In any case, an emulator is not equivalent to a processor type since
SimH and E11 support a range of PDP-11 CPUs.
  

And having a new instruction would be very easy
Ersatz-11.  I suspect that SIMH would also be
very easy.  What about RUST?

Some CPU software detection is handled by examining CPU behavior. The
same process can be used to detect an emulator and to determine which
emulator is being used.
  

It would even be possible to tell the user details of
the emulator environment.  There would need to be
some sort of standard.  Any suggestions?

I currently use some of the behavior of the MMU SR0 and SR1 to detect
emulators in RUST. Clearly, these tests only work when E11 and SIMH
are emulating a machine with MMU, but that's their default state and
there's not much point running RUST in other configurations. Here's
some of the code:

bt$emu:	call	tr$cat			; capture traps

	...				; skip V11 checks	
				
	mov	#m$msr0,r0		; emulator check
	mov	#m$msr1,r1		;
	tst	(r1)			; got MMU with SR1 etc?
	bcs	40$			; nope
	clr	(r0)+			; clear SR0 with increment
	bis	#160000,-(r0)		; overwrite and freeze

	cmpb	(r1),#27		; SIMH magic number
	bne	10$			; not SIMH
	btwar$	<Emulator detected: SIMH>;
	br	20$			;
					;
10$:	mov	#340,(r0)		; SR0 = 340
	cmpb	(r0),#140		; E11 magic number
	bne	30$			; not E11
	btwar$	<Emulator detected: E11>; (misses some read-only bits)
					;
20$:	inc	b$temu			; is emulator
					;
30$:	clr	(r0)			; make them all clean again
	clr	(r1)			;
40$:	call	tr$res			; restore traps
	return 

There is more code which checks for my V11 emulator. That check is
done with a hacked IOT instruction. 

The reason I need detection is because emulators lack standard
terminal output behavior which I use during startup to detect the
clock rate of a PDP-11 (I count the number of null characters output
to the console terminal per clock tick and use a table to determine
both the clock rate and the terminal rate). The test doesn't work on
E11, SIMH or V11.

In fact, the V11 emulator has a little API which is used to pass
information between the emulator and the system. It's used to
relinquish control so that the emulator doesn't hog all the CPU time
and for various other functions. It would be great if there was a
common API for PDP-11 emulators for this kind of thing, but I'm not
sure the motivation is there for the effort involved.

I don't think that the about properties (or at least how
the PDP-11 instructions react to the above code) has
been documented under Ersatz-11.  I would imagine
that the source code could be used under SIMH to
figure out why the above code is needed.

I am VERY curious!!!!!!!!!  How did you figure out the
code for Ersatz-11?  Did John Wilson help?  Does the
above code still work with V6.0 of E11?

Jerome Fine

[Jerome H. Fine]

>glen herrmannsfeldt wrote:

(snip, someone wrote)
  

I have been looking at the results for the program RESORC.SAV in RT-11
with respect the MFPT instruction.  When the J11 chip is used, the value
is 5 and the Maintenance Register at 177750 seems to determine what the
rest of the actual hardware supports.

(snip, someone else wrote)
  

Modifying the MFPT instruction is not the right way to go. CPU
software detection is a delicate business and that process should not
be interfered with directly.

In any case, an emulator is not equivalent to a processor type since
SimH and E11 support a range of PDP-11 CPUs.

Also right. And each CPU behaves differently, and the emulator needs to 
follow that, or it is broken.

Or, the emulator can emulate a CPU model different from any previously
built. That usually at least happens in that the emulator runs at a
different speed than any real processor.
  

My suggestion would be to treat the speed difference
separately from the CPU and board being emulated.
NOTE that with Ersatz-11, it is almost trivial to
specify a particular CPU and board which was
NEVER produced.

As for the speed difference, that aspect seems quite
important since it is possible for Ersatz-11 to run
RT-11 at a speed which is more than 100 times
the speed of a DEC  PDP-11/93 and that is just
the CPU speed.  The disk I/O can easily be more
than 200 times the speed of any disk drive which
was available on a real DEC  PDP-11/93.

Some CPU software detection is handled by examining CPU behavior. The
same process can be used to detect an emulator and to determine which
emulator is being used.

Right. I just posted an outline of how RSX-11M+ detects system type. 
It's a combination of available information as well as CPU behavior in 
very weird and possibly not documented ways.

I have seen the rules for detecting different x86 CPUs, from 8086 and
8088 on up. Some are pretty strange, though usually documented at least
as needed for detection.

As has been pointed out, however, an emulator
like Ersatz-11 or SIMH actually emulates MANY
different CPUs and boards.  So the suggestion
that Johnny made to use a new CPU instruction
does seem very helpful.  Does anyone else agree?
What sort of standards might be helpful to use?

Jerome Fine

[Jerome H. Fine]

>Johnny Billquist wrote:

I have been looking at the results for the program RESORC.SAV in RT-11
with respect the MFPT instruction.  When the J11 chip is used, the value
is 5 and the Maintenance Register at 177750 seems to determine what the
rest of the actual hardware supports.

Modifying the MFPT instruction is not the right way to go. CPU

software detection is a delicate business and that process should not
be interfered with directly.

In any case, an emulator is not equivalent to a processor type since
SimH and E11 support a range of PDP-11 CPUs.

Also right. And each CPU behaves differently, and the emulator needs to
follow that, or it is broken.

Or, the emulator can emulate a CPU model different from any previously
built. That usually at least happens in that the emulator runs at a
different speed than any real processor.

Right.
And yes, that could definitely be done, at which point I think a new value returned by MFPT would be reasonable.

We seem to have travelled full circle.  As I mentioned,
Ersatz-11 (under an Intel CPU such as an E8200)
can run RT-11 over 100 times as fast as on a PDP-11/93.

That would certainly qualify as being faster!!!!!!!

But your original suggestion of using a new
CPU instruction actually appeals to me.

Can anyone suggest some standards for which
emulators could be used as well as any additional
information like CPU speed or additional memory?
For example, Ersatz-11 supports direct access to
more than a GB of the memory on the PC via a
PDP-11  IOPAGE register at access speeds only
about 3 times the time to access regular memory.
I even have FORTRAN callable subroutines under
RT-11 which support these memory references.

Jerome Fine

[Jerome H. Fine]

>paramucho wrote:

The 800hz option isn't present on the 11/73. It's not documented in
the CPU guide and I note that SimH only provides the "JCLK" option for
the 8x and 9x CPUs but not for the 73.

In any case, since the option settings for 50/60/800 hz are visible in
a processor register (xx177520) I don't need to detect the setting in
a timing loop. It's just a matter of a CPU and CSR detect.

Do you have a manual name and page number which
specifies 177520 and the name of the register.

I am curious what else might be in that manual
which may have information.

I note that the Page Control Register is at 177520,
so I am extremely curious as to how that register
also holds the clock rate.  Using a PDP-11/83,
177520 is set at 4000 for 60 and 800 Hz and
at 2000 for 50 Hz when I run Ersatz-11.  I don't
have my DEC  PDP-11/83 working at the
moment, so I can't use the real DEC hardware.

Jerome Fine

[paramucho]

I used the 11/94 CPU document below, page 5-27

http://www.bitsavers.org/pdf/dec/pdp11/1194/EK-PDP94-MG-001_Sep90.pdf

Ian

[paramucho]

On Thu, 26 Jan 2012 06:09:33 GMT, para...@hotmail.com (paramucho)
wrote:

BTW: The document above has the Page Control Register at 177522, not
177520. See page 5-29.


Ian

[Johnny Billquist]

Right. No one argued that. Personally, I just don't consider the CPU
speed to be a differentiating factor. Even physical DEC CPUs for the
same model, giving the same identity to various ways of identification,
could be running at different speeds. For example, the 11/83 exists both
with 15 MHz and 18MHz clocks. But they are both 11/83 machines, with the
same values from the MFPT as well as the maintenance register.

> But your original suggestion of using a new
> CPU instruction actually appeals to me.

I think that is a much more sensible way to go.

> Can anyone suggest some standards for which
> emulators could be used as well as any additional
> information like CPU speed or additional memory?
> For example, Ersatz-11 supports direct access to
> more than a GB of the memory on the PC via a
> PDP-11 IOPAGE register at access speeds only
> about 3 times the time to access regular memory.
> I even have FORTRAN callable subroutines under
> RT-11 which support these memory references.

I hope you do understand that this could just as well be done under a
real PDP-11. It's just a device. No different than any other. It's not
that E11 gives any magical extensions by having a new device.
There just don't happen to exist any physical implementation of this
device. But it wouldn't be particularly hard to implement it and plug it
into any Qbus or Unibus.

Additional information - I would say that the sensible way would be to
add a new instruction. There are a few opcodes left unused which could
be allocated for this. It don't make sense to reuse any existing
opcodes, since even though they might not be used normally, instructions
like MED are valid on something like an 11/60, and if your emulator
emulates that CPU, then it should work right, and not do some
emulator-specific thing.

To make something really simple, yet extensible, we could define a
single opcode for calling into the emulator. As a start, it can take a
function specific code in R0, and return a value in R0 as well.

We can then extend on this later by just adding more functions defined
by R0 (and possibly other registers).

Johnny

[Johnny Billquist]

On 2012-01-26 04.25, Jerome H. Fine wrote:
> >paramucho wrote:
>> The 800hz option isn't present on the 11/73. It's not documented in
>> the CPU guide and I note that SimH only provides the "JCLK" option for
>> the 8x and 9x CPUs but not for the 73.
>>
>> In any case, since the option settings for 50/60/800 hz are visible in
>> a processor register (xx177520) I don't need to detect the setting in
>> a timing loop. It's just a matter of a CPU and CSR detect.
> Do you have a manual name and page number which
> specifies 177520 and the name of the register.

Ian already send you the link for the 11/9x systems, where you can see this.

> I am curious what else might be in that manual
> which may have information.
>
> I note that the Page Control Register is at 177520,
> so I am extremely curious as to how that register
> also holds the clock rate. Using a PDP-11/83,
> 177520 is set at 4000 for 60 and 800 Hz and
> at 2000 for 50 Hz when I run Ersatz-11. I don't
> have my DEC PDP-11/83 working at the
> moment, so I can't use the real DEC hardware.

Seems like E11 don't set that register right for 800 Hz then.
It should have been 6000.

Of course, it might be that E11 don't truly set the clock to 800 Hz as
well, or that it emulates a KW11-P in that case...?

Johnny

[paramucho]

On Wed, 25 Jan 2012 22:22:05 -0500, "Jerome H. Fine"
<ever...@nospam.com> wrote:

>
>>Modifying the MFPT instruction is not the right way to go. CPU
>>software detection is a delicate business and that process should not
>>be interfered with directly.
>>
>>
>As I already answered with Johnny, I have my own
>doubts for using MFPT. I do like his suggestion of a
>currently illegal instruction code (a new hardware
>instruction) which an actual DEC J11 chip would
>need to trap.
>
>>In any case, an emulator is not equivalent to a processor type since
>>SimH and E11 support a range of PDP-11 CPUs.
>>
>>
>And having a new instruction would be very easy
>Ersatz-11. I suspect that SIMH would also be
>very easy. What about RUST?

Adding a new instruction is usually trivial.

>>Some CPU software detection is handled by examining CPU behavior. The
>>same process can be used to detect an emulator and to determine which
>>emulator is being used.
>>
>>
>It would even be possible to tell the user details of
>the emulator environment. There would need to be
>some sort of standard. Any suggestions?

I use the API to get the host command, create host directories, define
host logical names, idle and V11 detection. I also use the API to
implement a cheap network connection. I have a list of other general
functions the API could handle, but it's no use just implementing a
general API for a single emulator and I doubt we'll see a generic
standard emerge...

<snip>

>>In fact, the V11 emulator has a little API which is used to pass
>>information between the emulator and the system. It's used to
>>relinquish control so that the emulator doesn't hog all the CPU time
>>and for various other functions. It would be great if there was a
>>common API for PDP-11 emulators for this kind of thing, but I'm not
>>sure the motivation is there for the effort involved.
>>
>I don't think that the about properties (or at least how
>the PDP-11 instructions react to the above code) has
>been documented under Ersatz-11. I would imagine
>that the source code could be used under SIMH to
>figure out why the above code is needed.
>
>I am VERY curious!!!!!!!!! How did you figure out the
>code for Ersatz-11? Did John Wilson help? Does the
>above code still work with V6.0 of E11?

I didn't use the source code for SimH. It's often easier to use a
debugger to "read" the system behavior than it is to hunt through
sources. I just experimented until I found a suitable test. I also
tested on real F11 and J11 systems.

The trick was to find some "undefined" behavior that didn't need
correction. The code above gets different results from an F11 and a
J11 as well as from SimH and E11. The test is far from ideal, but it
works well enough for my purposes.

The test works with V6.0 of E11.

Ian

[Johnny Billquist]

Another option is the 11/8x manual.
http://www.bitsavers.org/pdf/dec/pdp11/1184/EK-1184E-TM-001_Dec87.pdf
page 2-41. Same information as for the 11/9x though.

Johnny

[Johnny Billquist]

Uh. The page control register is indeed at 177522, but that is not the
register holding the information we talk about. (Jerome confused?).
It's the Control/Status register we are talking about, and that is at
177520.

Johnny

[Johnny Billquist]

The fact that some code ignore parts of the returned value is not a good
enough reason to abuse it.
There might be userland code which also use MFPT, and might react badly
if you change this. Not to mention other OSes, all of which we might not
even know of.
If you (supposedly) emulate a J11 CPU, you *must* return the same value
as a real J11, or else you are not in fact emulating a J11 CPU.

Now, admittedly, sometimes it might be necessary to break the mold for
various reasons, but let's do that in a less intrusive way.

>>> An incomplete list of software emulators is:
>>> SIMH
>>> Ersatz-11
>>>
>>> An incomplete list of hardware boards is:
>>> QED - more than 1?
>>> Mentec - at least 3
>>> and I can remember at least 2 others, but not the company names.
>> You have Strobe Data, which I'm sure you'll remember now that I
>> mention them.
> Yes. I seem to remember they were first. Do you classify them as
> a hardware or software emulator? If my hazy memory is correct,
> Strobe Data initially used the J11 chip on a board that plugged
> into an ISA slot on a DOS machine. Later, the J11 chips were
> very difficult to obtain, so Strobe Data managed to do something
> else.

I wouldn't call any of their implementations an emulator. It's a PDP-11.
I'm not even sure what the point is in trying to make the distinction
between a "hardware" and a "software" emulator. As I points out at
another place, all PDP-11s except for the PDP-11/20 are implemented
using microcode. So, in short, it is all done in software. The actual
instructions performed by the hardware have little to no resemblance to
a PDP-11 instruction.
Be that the microcode engine in the J11 CPU, or the x86 underlying the E11.
Try to think of x86 instructions as microcode for the E11 CPU, if that
helps.

> When I first saw the emulation actually running RT-11, I was very
> surprised.
>
> Does anyone know how many boards and the names that
> QED and Mentec produced. Also, does the name Nissho
> ring a bell? I think they were a Unibus hardware emulator
> or were they just high speed memory?

I don't have any complete lists.

>>> Right now the Logical Co. has a combined emulator called a
>>> PDQ-1000 board which actually plugs into a Qbus which takes
>>> only 4 slots, but includes CPU, memory and many controllers.
>> Yes... And...?
> The reason that I specifically mention the PDQ-1000 is that while
> it seems like a hardware emulator (since the final result is a Qbus
> board), inside the hardware is actually a software emulator.

And what is the difference? The J11 is also a software implementation.

>>> Can anyone who has a DEC (or non-DEC) PDP-11 system easily
>>> available determine the actual value returned by the MFPT instruction?
>>> As far as I know:
>>>
>>> MFPT Value Hardware
>>> 1 PDP-11/44
>>> 3 PDP-11/24 (should be 2)
>>> 3 PDP-11/23
>>> 4 SBC-11/21
>>> 5 All J11 chips including 11/73, 11/83, 11/93
>> That is all the values that MFPT can return. (Or rather - all the
>> values that were returned by any CPUs designed by DEC.)
> Understood. It would have been "nice" if DEC had supported
> a more open concept, but since probably at least 50% (maybe
> over 90%) of the emulators in use are SIMH and Ersatz-11,
> it is probably not all that important any more.

It's not that DEC didn't design an open concept. But what is the point
of defining new values for MFPT. We could do that. Let's for instance
say that E11 should return 6 for MFPT.
That would be perfectly valid. We could then decide what CPU options and
capabilities would be implied by this value.
The problem, however, is that no current software will recognize this.
So we need to adjust all OSes, as well as other software that use this
information, to get things right. That is where the problem is. And that
is why E11 instead tries to emulate existing CPUs truthfully, so that
existing software will work right.
That includes implementing all the bugs for the individual CPU as well.
Software might depend on it.

What you then might seek is a middle ground. Let's make the system act
just like an existing machine made by DEC, but let's make additional
features available to code that actually can figure out that this is not
a normal 11/93 (or whatever). That is the point when you hit the problem
that you need to truthfully emulate an 11/93, but still need to do
something that is incompatible with an 11/93. So, what is the least
intrusive incompatibility you can think of.

I say it is having an undefined instruction (which in all likelyhood no
existing program would be using anyway) actually not trap, but instead
do something.

>>> I assume that it would be extremely difficult, probably not worth the
>>> effort, to modify the high order byte of the MFPT instruction at this
>>> point for the 3rd party PDP-11 CPU boards, such as from Mentec.
>> Some Mentec boards use a J11. You can guess what they return. For the
>> other boards, they also seem to pretend to be J11 CPUs, which is a bit
>> sad, but that can't be helped.
> And of course, the result is that they reported a particular DEC
> CPU as being used. What were the names of all of the Mentec
> boards and their primary difference from each other?

The ones I can think off are the M70, M100, M11. M70 uses a J11. M11
uses Mentecs own FPGA implementation. The M11 have a TOY clock, but it
is not compatible with the 11/9x TOY. Also, the M11 adds one more
instruction not existing in the J11, namely MOVR, which is a block move
instruction. Takes three registers as arguments. Source address,
destination address and length.

There are more CPUs by Mentec, and possibly also other
features/differences between them that I don't know of.

>>> Can anyone comment on this assumption? Might there be another
>>> way for hardware to the tell a user which 3rd party board is being
>>> used as a PDP-11?
>> Please differ between which *board* is being used, as opposed to which
>> CPU. MFPT will only tell you which CPU is used, not which board.
> Yes, you are correct. Even DEC used the J11 chip
> on many different boards.
>
> I have the impression that it would no longer be either
> useful or reasonable to attempt to identify any Mentec
> or QED boards at this point.

Existing code already identify Mentec boards. Not surprising,
considering that Mentec owned the major OSes for a while.
QED processors looks like DEC ones as far as OSes are concerned.

>> If you want some "foolproof" way of detecting that you are inside an
>> emulated machine, I'd say that adding a new instruction from the
>> unused opcodes is probably a better idea. I wouldn't expect anything
>> to actually try using an undefined opcode anyway, so no existing code
>> should be hurt by it. And your "new" code will also work on real
>> machines, in that you will instead get a trap if you try that instruction.
> Your suggestion to use an instruction code which is presently
> illegal is actually almost trivial in Ersatz-11. John Wilson explicitly
> supports adding code for new instructions. Well, I guess it
> is not exactly trivial, but I could probably write and test the
> code for the required DLL in less than a week.
>
> I imagine the same would apply to SIMH. it would be useful
> if there could be an agreement on a standard!!!!!!!!!!!!!
>
> Other emulators or 3rd party hardware implementations which
> are no longer supported by their original manufacturers would be
> much more difficult, if not impossible, at this point.
>
> What about RUST? Could that support a new instruction as well?

Already answered by Ian. And yes, in short, adding a new instruction in
any emulator is trivial.
There is no standard. We might try to make a suggestion. But that's all
we could do.

Johnny

[paramucho]

On Thu, 26 Jan 2012 15:12:29 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>> What about RUST? Could that support a new instruction as well?
>
>Already answered by Ian. And yes, in short, adding a new instruction in
>any emulator is trivial.
>There is no standard. We might try to make a suggestion. But that's all
>we could do.

We could do more if we wanted to. SimH is open source, so it is
entirely possible to add private code. E11 supports an extension API
which could be used to implement an API.

The problem is, however, that this kind of thing isn't really worth it
unless it's part of the standard configuration. Perhaps that could
come later...

Ian

[Jerome H. Fine]

>Johnny Billquist wrote:

> Right. No one argued that. Personally, I just don't consider the CPU
> speed to be a differentiating factor. Even physical DEC CPUs for the
> same model, giving the same identity to various ways of
> identification, could be running at different speeds. For example, the
> 11/83 exists both with 15 MHz and 18MHz clocks. But they are both
> 11/83 machines, with the same values from the MFPT as well as the
> maintenance register.

I basically agree with you as well. Functionally should be
the reason for specifying a CPU to be different.

Note that many PDP-11/73 boards (maybe all M8190-BA,
M8190-BB, M8190-BC) also supported the use of PMI
memory, Just needed to place the PMI memory ahead of
the CPU board in the backplane (backplane must be ABCD
of course) and the faster access to memory was then used.

I tried that at one point with my M8190-BB and was surprised
to note that most of the extra speed for the CPU was due to the
faster PMI memory, not the 18 MHz clock. I imagine that
the reason RESORC.SAV reported a PDP-11/83 was that
both the MFPT and maintenance register were correct. But
I would need to check the exact nature of the code in RT-11.

Naturally a floating point intensive application would show
the PDP-11/83 to be significantly faster, but at the moment,
I don't have any such applications.

>> But your original suggestion of using a new
>> CPU instruction actually appeals to me.
>
> I think that is a much more sensible way to go.

AGREED!!!

>> Can anyone suggest some standards for which
>> emulators could be used as well as any additional
>> information like CPU speed or additional memory?
>> For example, Ersatz-11 supports direct access to
>> more than a GB of the memory on the PC via a
>> PDP-11 IOPAGE register at access speeds only
>> about 3 times the time to access regular memory.
>> I even have FORTRAN callable subroutines under
>> RT-11 which support these memory references.
>
>
> I hope you do understand that this could just as well be done under a
> real PDP-11. It's just a device. No different than any other. It's not
> that E11 gives any magical extensions by having a new device.
> There just don't happen to exist any physical implementation of this
> device. But it wouldn't be particularly hard to implement it and plug
> it into any Qbus or Unibus.

These days, it would only need a single stick of memory
from a PC to implement a 4 GB memory device or the
HD: disk that Ersatz-11 supports as in:
MOUNT HDA0: RAM: /SIZE:4096MB

> Additional information - I would say that the sensible way would be to
> add a new instruction. There are a few opcodes left unused which could
> be allocated for this. It don't make sense to reuse any existing
> opcodes, since even though they might not be used normally,
> instructions like MED are valid on something like an 11/60, and if
> your emulator emulates that CPU, then it should work right, and not do
> some emulator-specific thing.
>
> To make something really simple, yet extensible, we could define a
> single opcode for calling into the emulator. As a start, it can take a
> function specific code in R0, and return a value in R0 as well.
>
> We can then extend on this later by just adding more functions defined
> by R0 (and possibly other registers).

I would agree with the above suggestion. If
possible, perhaps Ersatz-11, SIMH and RUST
could all use the same definitions so that there
would need to be only a single instruction used. Do
you have any suggestions as to which instruction
code would be best? Also, there would need to
be common agreement on the value placed into
R0: It is probably too late to support the Mentec
and QED additions, but that could be done by
the user adding code to the trap instructions if
that was desired. So my suggestion would be
to include all of the 3rd party hardware as well
just in case:

Strobe Data - 2
Mentec M70 -3
Mentec M11 -4
Mentec M100 - 5
QED 993 - 6
Nissho?? - 7

RUST - 22
SIMH - 23
Ersatz-11 - 24
Charon - 25

PDQ-1000 - 32

If anyone has any additions or corrections, please
add them. Also, does anyone have any dates when
there were first available? It would seem reasonable
to assign the table of values in the order they first
appeared. I also used two separate lists, one for
what would be hardware and another for software.

The way I distinguish between hardware and software
was that hardware emulation was based on a given
set of hardware components which usually resulted
in a set speed for the CPU while for a software
emulation, a faster CPU could make a huge difference
in the speed of the emulation.

The PDQ-1000 might be in-between since it might
be a software emulator inside, but once the components
have been chosen, the Logical Co. will not want to
frequently change the Intel CPU that is being used
since these days it would also mean changing the
motherboard.

Can anyone else add anything to the discussion?

Jerome Fine

[Jerome H. Fine]

>paramucho wrote:

On Wed, 25 Jan 2012 22:22:05 -0500, "Jerome H. Fine" wrote:

I don't think that the about properties (or at least how
the PDP-11 instructions react to the above code) has
been documented under Ersatz-11.  I would imagine
that the source code could be used under SIMH to
figure out why the above code is needed.

I am VERY curious!!!!!!!!!  How did you figure out the
code for Ersatz-11?  Did John Wilson help?  Does the
above code still work with V6.0 of E11?

I didn't use the source code for SimH. It's often easier to use a
debugger to "read" the system behavior than it is to hunt through
sources. I just experimented until I found a suitable test. I also
tested on real F11 and J11 systems.

The trick was to find some "undefined" behavior that didn't need
correction. The code above gets different results from an F11 and a
J11 as well as from SimH and E11. The test is far from ideal, but it
works well enough for my purposes.

The test works with V6.0 of E11.

After you "found" the way that SIMH can be tested for,
were you able to verify that from the source code.  To
say the least, the activity that you found is VERY
unexpected!!!!!!!!!

Also, what led you to attempt to use the hardware
in that manner.  It does not seem very obvious as
to why the hardware registers (software in the case
of a software emulator as opposed to a real DEC
CPU) would behave in that fashion.

Can anyone else verify what Ian found?

Jerome Fine

[Jerome H. Fine]

>Johnny Billquist wrote:

I note that the Page Control Register is at 177520,
so I am extremely curious as to how that register
also holds the clock rate. Using a PDP-11/83,
177520 is set at 4000 for 60 and 800 Hz and
at 2000 for 50 Hz when I run Ersatz-11. I don't
have my DEC PDP-11/83 working at the
moment, so I can't use the real DEC hardware.

Seems like E11 don't set that register right for 800 Hz then.
It should have been 6000.

Of course, it might be that E11 don't truly set the clock to 800 Hz as well, or that it emulates a KW11-P in that case...?

Some how, when E11 was give the commands:

SET  HERTZ  60

SET  HERTZ  50

the register was set correctly.  But

SET  HERTZ  800

did not result in 6000 as I found 4000 instead.  I will
have to ask John Wilson about this.  I presume that
since SET  HERTZ 800 is not an expected value
to run a PDP-11 that John may not have considered
the value that the register was to be set.

Jerome Fine

[Jerome H. Fine]

>Johnny Billquist wrote:

>On 2012-01-26 04.21, Jerome H. Fine wrote:

You have Strobe Data, which I'm sure you'll remember now that I
mention them.

Yes. I seem to remember they were first. Do you classify them as
a hardware or software emulator? If my hazy memory is correct,
Strobe Data initially used the J11 chip on a board that plugged
into an ISA slot on a DOS machine. Later, the J11 chips were
very difficult to obtain, so Strobe Data managed to do something
else.

I wouldn't call any of their implementations an emulator. It's a PDP-11. I'm not even sure what the point is in trying to make the distinction between a "hardware" and a "software" emulator. As I points out at another place, all PDP-11s except for the PDP-11/20 are implemented using microcode. So, in short, it is all done in software. The actual instructions performed by the hardware have little to no resemblance to a PDP-11 instruction.
Be that the microcode engine in the J11 CPU, or the x86 underlying the E11.
Try to think of x86 instructions as microcode for the E11 CPU, if that helps.

I agree completely.  To be even more specific, the microcode
could be considered to be contained in a number of layers
with x86 instructions being the layer just before the PDP-11
instructions.  The other layers of microcode would be hidden
even from the x86 instructions.

Right now the Logical Co. has a combined emulator called a
PDQ-1000 board which actually plugs into a Qbus which takes
only 4 slots, but includes CPU, memory and many controllers.

Yes... And...?

The reason that I specifically mention the PDQ-1000 is that while
it seems like a hardware emulator (since the final result is a Qbus
board), inside the hardware is actually a software emulator.

And what is the difference? The J11 is also a software implementation.

The difference for the PDQ-1000 is that the implementation
is a specific Qbus board as opposed to a software program
which runs on many different hardware systems.  In this one very
specific case, it would seem to deserve a separate number to
identify it.

What you then might seek is a middle ground. Let's make the system act just like an existing machine made by DEC, but let's make additional features available to code that actually can figure out that this is not a normal 11/93 (or whatever). That is the point when you hit the problem that you need to truthfully emulate an 11/93, but still need to do something that is incompatible with an 11/93. So, what is the least intrusive incompatibility you can think of.

I say it is having an undefined instruction (which in all likelyhood no existing program would be using anyway) actually not trap, but instead do something.

I also agree now that this certainly is the best method.

And of course, the result is that they reported a particular DEC
CPU as being used. What were the names of all of the Mentec
boards and their primary difference from each other?

The ones I can think off are the M70, M100, M11. M70 uses a J11. M11 uses Mentecs own FPGA implementation. The M11 have a TOY clock, but it is not compatible with the 11/9x TOY. Also, the M11 adds one more instruction not existing in the J11, namely MOVR, which is a block move instruction. Takes three registers as arguments. Source address, destination address and length.

There are more CPUs by Mentec, and possibly also other features/differences between them that I don't know of.

Thank you for the list of Mentec CPUs.  I added them to my
other response.  Can anyone else who remembers other Mentec
CPUs add to my list?

Existing code already identify Mentec boards. Not surprising, considering that Mentec owned the major OSes for a while.
QED processors looks like DEC ones as far as OSes are concerned.

I am not familiar with, nor have I observed any code to
identify a Mentec board within RT-11.  Does RSX-11
have any such code?

Jerome Fine

[Jerome H. Fine]

>paramucho wrote:

>On Thu, 26 Jan 2012 15:12:29 +0100, Johnny Billquist wrote:

What about RUST? Could that support a new instruction as well?
      

Already answered by Ian. And yes, in short, adding a new instruction in 
any emulator is trivial.
There is no standard. We might try to make a suggestion. But that's all 
we could do.

We could do more if we wanted to. SimH is open source, so it is
entirely possible to add private code. E11 supports an extension API
which could be used to implement an API. 

The problem is, however, that this kind of thing isn't really worth it
unless it's part of the standard configuration. Perhaps that could
come later...

I was hoping to add code to RESORC.SAV in RT-11
to support the ability to determine which, if any, emulator
was running.  Johnny's preference to use an instruction
code which is presently NOT defined and in use seems
the best solution and is easily implemented for both SIMH
and Ersatz-11.  Since RUST can support that as well, then
the opcode needs to be specified along with the values
to be used for the different emulators.  Then as it becomes
reasonable, the extra code can be included.

However, if no one can agree on a standard, it becomes
much less likely for this to eventually take place.  It would
be helpful, therefore, if as many individuals could comment
on at least the concept, if not the actual details.  I would think
that only the very few individuals who were going to actually
implement the concept need to be concerned with the details
like which instruction code is used, the table of values and
how the value is provided to the PDP-11 program.

At the very least, is there anyone who objects or who thinks
this would be a bad idea?

Jerome Fine

[Johnny Billquist]

On 2012-01-29 02:32, Jerome H. Fine wrote:
> >Johnny Billquist wrote:
>
>> Right. No one argued that. Personally, I just don't consider the CPU
>> speed to be a differentiating factor. Even physical DEC CPUs for the
>> same model, giving the same identity to various ways of
>> identification, could be running at different speeds. For example, the
>> 11/83 exists both with 15 MHz and 18MHz clocks. But they are both
>> 11/83 machines, with the same values from the MFPT as well as the
>> maintenance register.
>
> I basically agree with you as well. Functionally should be
> the reason for specifying a CPU to be different.

[...]

Didn't realize that Jerome had written this both to me in person as well
as a post here, so my response only got sent to him.

Oh well, I disagree with most of the actual implementation he suggests,
since I think it is messy, inflexible and makes irrelevant distinctions
between "hardware" and "software".

I think we first should ask what we actually want to find out, and then
we could continue designing something of an API once we've figured that out.

And I actually am not really sure what Jerome wants to know/find out
here. So it's hard to talk about the API in much more detail...

[Johnny Billquist]

On 2012-01-29 02:39, Jerome H. Fine wrote:
> >Johnny Billquist wrote:

>> Existing code already identify Mentec boards. Not surprising,
>> considering that Mentec owned the major OSes for a while.
>> QED processors looks like DEC ones as far as OSes are concerned.
> I am not familiar with, nor have I observed any code to
> identify a Mentec board within RT-11. Does RSX-11
> have any such code?

Yes. I just told you.

[Jerome H. Fine]

>Johnny Billquist wrote:

>On Wed, 25 Jan 2012 22:25:11 -0500, "Jerome H. Fine" wrote:

I note that the Page Control Register is at 177520,
so I am extremely curious as to how that register
also holds the clock rate.  Using a PDP-11/83,
177520 is set at 4000 for 60 and 800 Hz and
at 2000 for 50 Hz when I run Ersatz-11.  I don't
have my DEC  PDP-11/83 working at the
moment, so I can't use the real DEC hardware.

I used the 11/94 CPU document below, page 5-27

http://www.bitsavers.org/pdf/dec/pdp11/1194/EK-PDP94-MG-001_Sep90.pdf

BTW: The document above has the Page Control Register at 177522, not
177520. See page 5-29.

Uh. The page control register is indeed at 177522, but that is not the register holding the information we talk about. (Jerome confused?).
It's the Control/Status register we are talking about, and that is at 177520.

I am confused.

The Ersatz-11 manual lists the PCR at 177520, but does
not provide any more details as to how it is used.  In
every case, John Wilson has attempted to duplicate
how actual real DEC PDP-11 hardware functions.

But, since the PCR (as far as I can remember) is
rarely used except when performing a hardware boot
of the operating system, it is possible that John did
not attempt to duplicate the functions exactly, in
particular since the EPROMs which held the code
for booting would probably be considered as being
copyright.

On the other hand, maybe the confusion is how John
specified the register at 177520, not how it is used.

If anyone has a copy of the Ersatz-11 manual, please
check under SET  CPU options and provide your
interpretation.  There is also a copy of the PDF on
the dbit site.

Jerome Fine

[Johnny Billquist]

Ok. Here is a short suggestion for you, then:

Opcode 7 is, as far as I can tell, unused. (Someone correct me if I'm
wrong).

I suggest we adopt this opcode as CEM (Call EMulator).

It might use any registers for input and/or output, all defined by the
actual function requested.

When the instruction is executed on any machine not having this
function, it will trap as an illegal instruction, same as always.
If the machine actually understands CEM, it will start by looking at the
function code in R0. If the function code is not understood, nothing
will be done, and the carry will be set.
If the function code is understood, the instruction will perform some
action, and possibly return values in registers. The carry will be clear
in this case. Other condition code flags can be used to indicate
possible other errors or conditions. They will be defined for those
specific functions at a later time.

For now, the only defined function is:

R0 = 0 - Get emulator system.

If the emulator understands this instruction, it will place a code in R0
that reflects which emulator is being used.

Currently defined values:
0 - Undefined
1 - SimH
2 - E11
3 - Rust

There. Now all we need is for everyone to actually implement it.

[Johnny Billquist]

This has little to do with E11.

The register at 177520 is the Control/Status register, according to DEC
documentation. The Page Control Register is at 177522. What is there to
argue about?

E11 documentation might, at the most, have put the wrong name on the
register in its documentation. In this case I prefer to use the DEC
documentation for the actual systems... I have not even looked at the
E11 documentation.

[Johnny Billquist]

Argh! Looking at an old document. Opcode 7 is in fact MFPT.
However, I can't find that opcode 10 is used. So let's go for that then.

[paramucho]

The source code isn't really relevant. Just the behavior.

>Also, what led you to attempt to use the hardware
>in that manner. It does not seem very obvious as
>to why the hardware registers (software in the case
>of a software emulator as opposed to a real DEC
>CPU) would behave in that fashion.

I spent the first year or so of my PDP-11 career working almost
entirely at the switch register of an 11/20. You learn to read the
binary state of the machine as "source code". I remember once during a
switch register session looking at the clock and noticing it was
twelve midnight. The next time I looked it was eight in the morning. I
still enjoy reading binary and making sense of it. I guess others here
have had similar experiences.

Selecting the MMU registers was initially process of elimination.
Following that, I knew that E11 doesn't actually attempt to fully
implement MMU register SR1. I started playing around on a J11 and F11
to see what happened when I jammed those registers in an illogical
manner. After a little experimentation I found a test which came out
differently on the F11 to the J11. Then I played around with E11 and
SimH. It's not that hard, and it's not the ideal test either.

>Can anyone else verify what Ian found?

RUST/SJ runs the test everytime it boots. It currently issues a
message when its booted under SimH or E11. Actually, the message is a
bit annoying and needs to be muted except in verbose boot mode.

I also have a little ENV.SAV utility which runs the test. I'll try to
find the time to put it on my upload site (where I still have to find
the time to package and upload the RUST driver sources).

Ian

[Bob Supnik]

No. Just no. SimH will never add "features" that didn't exist in the
real hardware.

The maintenance register (MAINT) is already read/write. After it has
been initialized, you can set arbitrary values in it to create "new"
models, at least for processors (like the J-11) that implement it.

The model emulation in SimH is not perfect, which is why clever
software can detect it. But the intent is to mimic real systems. SimH
is not a "different" PDP11.

/Bob Supnik

On Sun, 15 Jan 2012 09:37:21 -0500, "Jerome H. Fine"
<ever...@nospam.com> wrote:

> I have an interesting hardware question.
>
>I have been looking at the results for the program RESORC.SAV in RT-11
>with respect the MFPT instruction. When the J11 chip is used, the value
>is 5 and the Maintenance Register at 177750 seems to determine what the
>rest of the actual hardware supports.
>

>I thought it would also be helpful for the user to know if an emulator
>is being
>used, either software or hardware, or if perhaps some other 3rd party
>hardware
>CPU. I would probably target the various 3rd party boards as far as
>hardware
>is concerned (such as QED and Mentec). For software emulators, I would
>suggest that only the high end PDP-11 processors be supported (the DEC
>CPUs which support the MFPT instruction) in order to keep things simple,
>at least initially.
>

>An incomplete list of software emulators is:
>SIMH
>Ersatz-11
>
>An incomplete list of hardware boards is:
>QED - more than 1?
>Mentec - at least 3
>and I can remember at least 2 others, but not the company names.
>

>Right now the Logical Co. has a combined emulator called a
>PDQ-1000 board which actually plugs into a Qbus which takes
>only 4 slots, but includes CPU, memory and many controllers.
>

>Thus far, the high order byte of the MFPT instruction always seems
>to be zero and is currently ignored by the RESORC.SAV program.
>Under SIMH and Ersatz-11, it would be trivial to use the high order
>byte of the MFPT instruction to signify which software emulator is
>being used.

>
>Can anyone who has a DEC (or non-DEC) PDP-11 system easily
>available determine the actual value returned by the MFPT instruction?
>As far as I know:
>
>MFPT Value Hardware
> 1 PDP-11/44
> 3 PDP-11/24 (should be 2)
> 3 PDP-11/23
> 4 SBC-11/21
> 5 All J11 chips including 11/73, 11/83, 11/93
>

>I assume that it would be extremely difficult, probably not worth the
>effort, to modify the high order byte of the MFPT instruction at this
>point for the 3rd party PDP-11 CPU boards, such as from Mentec.

>Can anyone comment on this assumption? Might there be another
>way for hardware to the tell a user which 3rd party board is being
>used as a PDP-11?
>

>The other possibility is to use the Maintenance Register at 177750,
>although I suspect that there might not be any more bit available.
>
>Jerome Fine

[paramucho]

On Sun, 29 Jan 2012 21:21:04 -0500, Bob Supnik <bob AT supnik DOT org>
wrote:

>No. Just no. SimH will never add "features" that didn't exist in the
>real hardware.
>
>The maintenance register (MAINT) is already read/write. After it has
>been initialized, you can set arbitrary values in it to create "new"
>models, at least for processors (like the J-11) that implement it.
>
>The model emulation in SimH is not perfect, which is why clever
>software can detect it. But the intent is to mimic real systems. SimH
>is not a "different" PDP11.
>
>/Bob Supnik
>On Sun, 15 Jan 2012 09:37:21 -0500, "Jerome H. Fine"
><ever...@nospam.com> wrote:
>
>> I have an interesting hardware question.

<snip>

>>Thus far, the high order byte of the MFPT instruction always seems
>>to be zero and is currently ignored by the RESORC.SAV program.
>>Under SIMH and Ersatz-11, it would be trivial to use the high order
>>byte of the MFPT instruction to signify which software emulator is
>>being used.
>>
>>Can anyone who has a DEC (or non-DEC) PDP-11 system easily
>>available determine the actual value returned by the MFPT instruction?
>>As far as I know:
>>
>>MFPT Value Hardware
>> 1 PDP-11/44
>> 3 PDP-11/24 (should be 2)
>> 3 PDP-11/23
>> 4 SBC-11/21
>> 5 All J11 chips including 11/73, 11/83, 11/93
>>
>>I assume that it would be extremely difficult, probably not worth the
>>effort, to modify the high order byte of the MFPT instruction at this
>>point for the 3rd party PDP-11 CPU boards, such as from Mentec.
>>Can anyone comment on this assumption? Might there be another
>>way for hardware to the tell a user which 3rd party board is being
>>used as a PDP-11?
>>
>>The other possibility is to use the Maintenance Register at 177750,
>>although I suspect that there might not be any more bit available.
>>
>>Jerome Fine

Perhaps a better way to implement this functionality, if it is worth
implementing at all, is in the form of a new custom device, freeing it
from any dependency on a particular CPU's facilities. The same psuedo-
device could be implemented for E11 using the E11 plug-in facilities.
V11 would just add a code module.

Going back to Bob Supnik's comments, the implementation of a new
"different" device doesn't materially alter the CPU architecture of
"real" PDP-11 systems. PDP-11s have always supported custom devices.
Clearly, one would not expect the standard SimH deliverable to include
this custom device, but there are already specialized versions of SimH
such as the Pro version.

The PDP-11 client-side interface to the device could be direct
addressing for bootstrap/kernel code, or via a driver to provide
access for user-mode processes.

Implementing an emulator device is not as trivial as inserting a new
instruction for something as simple as a Move-From-Emulator-Type
instruction. However, a device is a more convenient way of packaging
the functionality if you want to implement a more complex API (which
is what I have).

All that said, we need to ask: Do We Really Need This Functionality?
If we don't, the idea will merely live and flourish for a few months
only to later wither on the vine... It's a nice idea, but there are
lots of nice ideas...

Ian

[Johnny Billquist]

I don't particularly feel we need this at all, but since Jerome asked, I
(and you, and others...) answered.
If one absolutely do want a way, then I still think that a new
instruction is the right way to go. Adding a device is both problematic
since it could very well be implemented in a real machine, and also
because if you are to do it properly, it needs to be defined in the
order of floating CSR space, and adopted properly, or else all kind of
autodetection of devices will fail in spectacular ways. I'm not sure any
room is left around in the fixed CSR space...
And that would mean it needs to move around depending on what other
hardware you have, which in turn will make it very hard for any software
to actually use unless they implement the whole autodetection algorithm,
which in turn also might make it difficult to use under a running OS,
not to mention the fact that if you configure things wrong, it will not
work right at all.

But, to reiterate my stand, I don't particularly feel the need for this
at all. And I am unclear on what Jerome needs, and why.

Johnny

[Bill Gunshannon]

In article <jg8d26$a1d$1...@iltempo.update.uu.se>,

Let me throw a couple comments out in regards this latest discussion.
First, on Bob's comment about what will or will not go into SIMH, I
totally agree that the base SIMH needs to remain just what it is, an
emulator of real hardware. But I would be in favor of a fork of SIMH
for experimenters where the internal engine was used to add or change
features of the hardware for the pure academic sake of seeing if the
architecture was really at a dead end or if one could have done things
with the PDP-11 (and the VAX, for that matter) to extend the architecture
while remaining compatable with the old architecture, much like what
IBM dod with the 360 <-> 390.

On, on this latest piece, I agree with Johnny that creating a bogus
device to identify what the processor is is more work than needed
and because such a device would never exist anyway, kind of meaningless.
Assuming that there is a serious need/desire to be able to identify a
processor using some external means provided by the operator, why
not create a pseudo-dongle that can hang off of an unused (or even a
used one with a little more work) serial port that can be queried to
identify the processor? Advantage is it requires no architectural
change to the underlying hardware, emulated or real. It could also
be created in real hardware with out too much difficulty if one wanted
to move this from the emulated PDP world to real hardware.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Johnny Billquist]

Hmm. That is a totally different question. It might be worth playing
with in its own right, but I doubt there will much point, unless you
also could modify all software to actually use this. That might be hard,
so I'm not sure it would lead anywhere.
Anyway, for such a thing a proper fork would be right. It's not
emulating any existing machine.

> On, on this latest piece, I agree with Johnny that creating a bogus
> device to identify what the processor is is more work than needed
> and because such a device would never exist anyway, kind of meaningless.
> Assuming that there is a serious need/desire to be able to identify a
> processor using some external means provided by the operator, why
> not create a pseudo-dongle that can hang off of an unused (or even a
> used one with a little more work) serial port that can be queried to
> identify the processor? Advantage is it requires no architectural
> change to the underlying hardware, emulated or real. It could also
> be created in real hardware with out too much difficulty if one wanted
> to move this from the emulated PDP world to real hardware.

Oh! Yuck! But I guess it depends on what the purpose of that thing
should be. Just a way to identify a machine, or a way to identify a
machine running under E11/Simh/whatever. In the latter case, a serial
dongle would definitely be wrong. In the former case, what would it be
used for at all?

I can, just for curiositys sake, understand that you might want to find
out if you are running under Simh or whatever. But then you need to do
something in Simh which is not possibly under any existing other machine.

As an extension to this, you could also add new features, which would be
used when identified as such a machine, but this seems unlikely in general.

As I said from the start, I'm not sure what the point of all this is. :-)

Johnny

[Bill Gunshannon]

In article <jg9i9n$n3i$1...@iltempo.update.uu.se>,

Yeah, I know...

> But I guess it depends on what the purpose of that thing
> should be. Just a way to identify a machine,

Maybe I just came in late, but that's what I thought people wanted.

> or a way to identify a
> machine running under E11/Simh/whatever.

But isn't the inability to tell you are running on an emulator the
true proof that the emulator works?

> In the latter case, a serial
> dongle would definitely be wrong. In the former case, what would it be
> used for at all?

Again, I think I came in late but I thought someone was looking for
a way to query a machine about what processor it had. Ah for the
days of having software accesable front panel switches. :-)

>
> I can, just for curiositys sake, understand that you might want to find
> out if you are running under Simh or whatever. But then you need to do
> something in Simh which is not possibly under any existing other machine.

See my comment above!! If there is anythjing in the emulator that is not
the same as the real thing, then the emulator needs to be fixed.

>
> As an extension to this, you could also add new features, which would be
> used when identified as such a machine, but this seems unlikely in general.

But I think new features belongs in the fork mentioned above.

>
> As I said from the start, I'm not sure what the point of all this is. :-)
>

Me neither. Maybe I should have stayed out of it. :-)

[glen herrmannsfeldt]

In vmsnet.pdp-11 Bill Gunshannon <bill...@cs.uofs.edu> wrote:
> In article <jg9i9n$n3i$1...@iltempo.update.uu.se>,
> Johnny Billquist <b...@softjar.se> writes:

(snip)

> Yeah, I know...

>> But I guess it depends on what the purpose of that thing
>> should be. Just a way to identify a machine,

> Maybe I just came in late, but that's what I thought people wanted.

>> or a way to identify a
>> machine running under E11/Simh/whatever.

> But isn't the inability to tell you are running on an emulator the
> true proof that the emulator works?

I suppose, but even in real processors there are leaks.

Maybe instead, doing things that you would normally do on a real
processor, you shouldn't be able to tell. I haven't followed the PDP-11
differences so well, but I remember some of the intel ones.

The 8086 has a six-byte prefetch queue, such that self modifying code
must modify far enough ahead that it hasn't been fetched yet. That is
part of the 8086 definition. The 8088, which came later, only has a four
byte prefetch queue. By careful self-modification, I believe using a
sequence defined by intel, one can tell them apart. If intel was careful
to leave such modification undefined for the 8086, then legal 8086 code,
expecting a specific result, could never execute that sequence.

On the other hand, there is a mistake in the 68020, preventing one from
generating virtual machines. That is, running virtual machines in user
mode, while trapping and simulating privileged instructions. In the
68020 user mode, one can examine the flag bit indicating user/supervisor
mode, such that it would give the wrong value. The flag bit is defined
to be user readable, such that legal programs could depend on it.
(An OS might use it to check what mode a routine is being executed in.)

(snip)

> Again, I think I came in late but I thought someone was looking for
> a way to query a machine about what processor it had. Ah for the
> days of having software accesable front panel switches. :-)

>> I can, just for curiositys sake, understand that you might want to find
>> out if you are running under Simh or whatever. But then you need to do
>> something in Simh which is not possibly under any existing other machine.

> See my comment above!! If there is anythjing in the emulator that is not
> the same as the real thing, then the emulator needs to be fixed.

So the 8088 is a broken 8086? Again, if anything is not the same, and is
defined to be legal on the real machine, then it needs to be fixed.

>> As an extension to this, you could also add new features, which would be
>> used when identified as such a machine, but this seems unlikely in general.

> But I think new features belongs in the fork mentioned above.

The OS/2 emulation of DOS (in 1.0) and Windows (in later versions)
allowed for some specific differences. One of the favorite things to do
in emulated systems is allow I/O outside the emulation. OS/2, at some
point, allowed for a special device driver that would only run in
virtual machines. That allows, at least, faster I/O instead of complete
emulation of the I/O sequence. It also allows, if I remember, long file
names that DOS otherwise wouldn't allow. Exactly what would happen if
you ran that outside OS/2, I don't know.

-- glen

[Jerome H. Fine]

>paramucho wrote:

I guess that finding the difference on the F11 and J11 systems
was the key.

Also, what led you to attempt to use the hardware
in that manner.  It does not seem very obvious as
to why the hardware registers (software in the case
of a software emulator as opposed to a real DEC
CPU) would behave in that fashion.

I spent the first year or so of my PDP-11 career working almost
entirely at the switch register of an 11/20. You learn to read the
binary state of the machine as "source code". I remember once during a
switch register session looking at the clock and noticing it was
twelve midnight. The next time I looked it was eight in the morning. I
still enjoy reading binary and making sense of it. I guess others here
have had similar experiences.

Selecting the MMU registers was initially process of elimination.
Following that, I knew that E11 doesn't actually attempt to fully
implement MMU register SR1. I started playing around on a J11 and F11
to see what happened when I jammed those registers in an illogical
manner. After a little experimentation I found a test which came out
differently on the F11 to the J11. Then I played around with E11 and
SimH. It's not that hard, and it's not the ideal test either.
  

While I agree it is not the ideal test, the
fact that it works and is actually quite
simple is what is important.

Can anyone else verify what Ian found?
    

RUST/SJ runs the test everytime it boots. It currently issues a
message when its booted under SimH or E11. Actually, the message is a
bit annoying and needs to be muted except in verbose boot mode.

I also have a little ENV.SAV utility which runs the test. I'll try to
find the time to put it on my upload site (where I still have to find
the time to package and upload the RUST driver sources).

Ian

Thank you very much for sharing the code
for SIMH and E11.  While I agree with
Johnny that using an instruction code which
is presently unused would be a clean solution,
the code which you show is certainly a good
substitute.

Jerome Fine

[Jerome H. Fine]

>Bob Supnik wrote:

No. Just no. SimH will never add "features" that didn't exist in the
real hardware.

I understand and I agree that SimH should conform to that
goal.

However, I do have a question about a real hardware
CPU from Mentec?  The M11 and N11 are capable
of being detected under RSX-11 and have the code
to display that CPU type as PDP-11/95 and PDP-11/97,
respectively - if I understand the code from RSX-11
correctly which does the identification.

Does SimH presently emulate these two Mentec boards
and if not, might that be a future addition to the code?
If the goal is to emulate only DEC  PDP-11 CPUs,
then it would be reasonable to ignore the Mentec
CPUs.  Otherwise, since Mentec seems to have sold
many such CPUs, it would seem reasonable to
include them.  However, it might not be possible
given that it does not seem possible to locate any
manuals for the Mentec CPUs.  bitsavers was negative
and a Google search was equally unproductive.

Google Search

http://www.google.ca/search?q=mentec+CPU+manuals&hl=en&source=hp&gbv=2&gs_sm=e&gs_upl=1219l16860l0l17063l30l30l0l21l21l0l250l1545l0.5.4l9l0&oq=mentec+CPU+manuals&aq=f&aqi=&aql=

 

Mentec CPUs

http://en.wikipedia.org/wiki/Mentec_PDP-11

 

Sales Figures

http://www.fuse-network.com/fuse/demonstration/30/24675/24675.pdf

 Jerome Fine

[Jerome H. Fine]

>Johnny Billquist wrote:

But, to reiterate my stand, I don't particularly feel the need for this at all. And I am unclear on what Jerome needs, and why.

Actually, it was because I have always wanted
to run RESORC.SAV as a virtual system job
so that I could see the memory being used
by the background job under RT-11.  I initially
found a difficult way to do this until I stumbled
on a very easy method that only depended on
some initialization code when RESORC.SAV
was being initialized for the first time after which
that code was no longer needed.

Of course, one thing tends to lead to another
and I finally wondered about the hardware
environment.  It seemed reasonable to find
out if RT-11 was running under an emulator,
so I decided to ask my question on usenet.

I agree that my initial suggestion of using the
value returned by MFPT is definitely not the
way to go.

And this has been one of the longer threads at
this point.  Thank you everyone who has responded
and especially those who have offered their
help and advice.

Jerome Fine

[Jerome H. Fine]

>Bill Gunshannon wrote:

As an extension to this, you could also add new features, which would be 
used when identified as such a machine, but this seems unlikely in general.

But I think new features belongs in the fork mentioned above.

Actually, there is one feature that is in E11 which might
be interesting enough to use as an additional device, as
Johnny has mentioned, which is entirely compatible
with all real and other emulated PDP-11s if anyone
wants to write the code for SimH or produce the
actual hardware for a real DEC  PDP-11.

I think I have mentioned what E11 uses as EMEM.DLL
which provides direct access to extremely large numbers
of bytes of PC memory.  The DLL activates 4 IOPAGE
registers and when the user program references those
registers (or uses a device driver to reference them), E11
allows the user program to read and write the words.

Under Windows 98SE, I only have 768 MB of memory
on the system, but EMEM.DLL (I modified my version
supplied by John Wilson) allows me to allocate and access
up to 600 MB of PC memory.  When I tested E11 on
a Windows XP system with 3 GB of physical memory,
EMEM.DLL allows me to access 1280 MB of PC
memory.

Since accessing the memory needed assembler subroutines
when I used FORTRAN 77, I wrote some that changed
to code the first time each subroutine was used to be inline
code instead of having the overhead of the CALL.

For those interested in the details, the 4 IOPAGE registers
are used as follows:
CSR+0:  Read or Write the word - Mov  @#CSR,R0  //  Mov R0,@#CSR
CSR+2:  Read or Write the word, then auto-increment 32 bit address
CSR+4:  low order 16 bits of byte offset of PC memory - read/write
CSR+6:  high order 16 bits of byte offset of PC memory- read/write

One additional question.  E11 has a device called HD: or Hypothetical Disk.
It is very simple and supports GB of disk files as a device.  Would anyone
be interested in supporting this hardware under SimH?  It is just
as simple as the RK05, probably more so, but I don't use SimH
enough to want to spend the time.  Is anyone interested?

Jerome Fine

[Charles Richmond]

"Bill Gunshannon" <bill...@cs.uofs.edu> wrote in message
news:9oqbt8...@mid.individual.net...
>
> [snip...] [snip...]
> [snip...]

>
> Let me throw a couple comments out in regards this latest discussion.
> First, on Bob's comment about what will or will not go into SIMH, I
> totally agree that the base SIMH needs to remain just what it is, an
> emulator of real hardware. But I would be in favor of a fork of SIMH
> for experimenters where the internal engine was used to add or change
> features of the hardware for the pure academic sake of seeing if the
> architecture was really at a dead end or if one could have done things
> with the PDP-11 (and the VAX, for that matter) to extend the architecture
> while remaining compatable with the old architecture, much like what
> IBM dod with the 360 <-> 390.
>

Although I have been aware of the existance of SIMH for a long time, I plead
ignorance about the details.

Isn't SIMH released under the GPL or similar license??? I know that anyone
has access to the source. So if a (very) interested party wanted to start
an off-shoot project based on the SIMH code, it seems like anyone could
legally and morally do that. Perhaps it would be called SIM-exp or
something... and *not* advertise or pretend to be a simulation of the real
hardware, but just an experimental platform to see what pie-in-the-sky
things could be built on top of what *was* the original hardware.

Could everyone (even Bob Supnik) be happy with such an off-shoot??? (*Not*
that Bob Supnik would want to contribute to the development of the SIM-exp
directly.)


--
+<><><><><><><><><><><><><><><><><><><>+
| Charles Richmond nume...@aquaporin4.com |
+<><><><><><><><><><><><><><><><><><><>+

[paramucho]

On Tue, 31 Jan 2012 10:42:30 +0100, Johnny Billquist <b...@softjar.se>
wrote:

<snip>

It's a jungle out there :-)

Any general purpose PDP-11 system should be able to support custom
devices, and what we are adding is "custom" functionality. In the real
world we'd use a device (mainly because, with a couple of exceptions,
we can't alter the architecture of a real PDP-11). That doesn't mean
we can't go into the custom CPU business, but the analogy does hold.

I suppose we could use a hidden register, like the TOY clock, but I
guess that would have it's own emulator nasties.

It occurs to me that I don't know if there is a definitive listing of
the fixed addresses... I guess there has to be a list somewhere???

<snip>

Ian

[paramucho]

On Tue, 31 Jan 2012 22:53:32 -0500, "Jerome H. Fine"
<ever...@nospam.com> wrote:

<snip>

>>
>>Selecting the MMU registers was initially process of elimination.
>>Following that, I knew that E11 doesn't actually attempt to fully
>>implement MMU register SR1. I started playing around on a J11 and F11
>>to see what happened when I jammed those registers in an illogical
>>manner. After a little experimentation I found a test which came out
>>differently on the F11 to the J11. Then I played around with E11 and
>>SimH. It's not that hard, and it's not the ideal test either.
>>
>>
>While I agree it is not the ideal test, the
>fact that it works and is actually quite
>simple is what is important.

The reason that it's not ideal is that it doesn't handle CPU
configurations that don't have memory management, e.g. LSI's and early
unmapped PDP-11s. I haven't tested it on all the different MMU
configurations either.

However, these days I could probably use the clock/terminal timing
loop to detect an emulator more generally (it used to fail in the past
because nulls were output as spaces on SimH). Once I knew I was on an
emulator I might be able to come up with some basic difference between
SimH and E11.

I'm not sure what else is available however. Early PDP-11s leave
little which is undefined (mostly because there's very little in the
way of CPU registers). One might look at the handling of double bus
errors, stack underflow, trace traps and the like, but all of these
tests have a higher risk of ending in a pile of goo with a halted CPU.

(Aside: I was checking out some potential tests tonight and noticed
that SimH seems to read Ctrl-H as octal 127. I'm not sure where the
conversion takes place though).

<snip>

>Thank you very much for sharing the code
>for SIMH and E11. While I agree with
>Johnny that using an instruction code which
>is presently unused would be a clean solution,
>the code which you show is certainly a good
>substitute.

The advantage of the register behavior test is that it tests SimH and
E11 out-of-the-box, as delivered. Any test which is based on custom
versions of SimH and E11 has exactly the disadvantage that it won't
test the standard deliverables, which is what most people use. Thus,
it makes sense to use my register test, or something equivalent when
the custom instruction/device is not present.

Ian

[Johnny Billquist]

On 2012-02-01 12:22, paramucho wrote:
> On Tue, 31 Jan 2012 22:53:32 -0500, "Jerome H. Fine"
> <ever...@nospam.com> wrote:
>
> <snip>
>>>
>>> Selecting the MMU registers was initially process of elimination.
>>> Following that, I knew that E11 doesn't actually attempt to fully
>>> implement MMU register SR1. I started playing around on a J11 and F11
>>> to see what happened when I jammed those registers in an illogical
>>> manner. After a little experimentation I found a test which came out
>>> differently on the F11 to the J11. Then I played around with E11 and
>>> SimH. It's not that hard, and it's not the ideal test either.
>>>
>>>
>> While I agree it is not the ideal test, the
>> fact that it works and is actually quite
>> simple is what is important.
>
> The reason that it's not ideal is that it doesn't handle CPU
> configurations that don't have memory management, e.g. LSI's and early
> unmapped PDP-11s. I haven't tested it on all the different MMU
> configurations either.

I think a bigger reason that it's not ideal is that at least Bob Supnik
have the explicitly stated goal that it should not work. Any current
differences from the real machine are bugs, and are subject to be fixed
at any time, at which point the test wont work anymore.

> However, these days I could probably use the clock/terminal timing
> loop to detect an emulator more generally (it used to fail in the past
> because nulls were output as spaces on SimH). Once I knew I was on an
> emulator I might be able to come up with some basic difference between
> SimH and E11.

Timing might be the only thing that Simh in general will have a hard
time hiding.

> (Aside: I was checking out some potential tests tonight and noticed
> that SimH seems to read Ctrl-H as octal 127. I'm not sure where the
> conversion takes place though).

That could a whole number of different places. Most common is that
terminal emulators actually mess with this. (I hate this, and go to
great lengths to make stuff behave the way I want, which seems to be
very different from what most people nowadays think is right.)

> <snip>
>> Thank you very much for sharing the code
>> for SIMH and E11. While I agree with
>> Johnny that using an instruction code which
>> is presently unused would be a clean solution,
>> the code which you show is certainly a good
>> substitute.
>
> The advantage of the register behavior test is that it tests SimH and
> E11 out-of-the-box, as delivered. Any test which is based on custom
> versions of SimH and E11 has exactly the disadvantage that it won't
> test the standard deliverables, which is what most people use. Thus,
> it makes sense to use my register test, or something equivalent when
> the custom instruction/device is not present.

Right. The only addition being that at least SimH should not be
identifiable this way either. It's a bug that you are using at the
moment. Expect it to go away sooner or later.

[Johnny Billquist]

But this is not E11 specific. It's a device. You just need to inform the
system if this device exist or not, no matter what machine you have.
It's not an E11-unique thing.

This is my objection. You are assuming that a device that you
(currently) have on an E11 for some reason must be an E11-specific
thing, and thus you are willing to jump to the conclusion that you can
figure out if this device exist on the basis of if you are running under
E11 or not. I think this is totally wrong.

[Johnny Billquist]

Yeah. SimH is available with source, and yes, you could definitely fork
it off and do other stuff in there.

[Johnny Billquist]

On 2012-02-01 12:22, paramucho wrote:

> It's a jungle out there :-)

Indeed. :-)

> Any general purpose PDP-11 system should be able to support custom
> devices, and what we are adding is "custom" functionality. In the real
> world we'd use a device (mainly because, with a couple of exceptions,
> we can't alter the architecture of a real PDP-11). That doesn't mean
> we can't go into the custom CPU business, but the analogy does hold.

Right. But if the purpose is just to identify which machine you are
running on, the a device is not a good solution. A device is basically
never specific to one machine.

> I suppose we could use a hidden register, like the TOY clock, but I
> guess that would have it's own emulator nasties.

Apart from still not being a good way to identify a machine.

> It occurs to me that I don't know if there is a definitive listing of
> the fixed addresses... I guess there has to be a list somewhere???

I actually don't know. I know of lots of sources, but I have not seen a
definitive list, as far as I know.

[Johnny Billquist]

On 2012-02-01 04:54, Jerome H. Fine wrote:
> >Bob Supnik wrote:
>> No. Just no. SimH will never add "features" that didn't exist in the
>> real hardware.
> I understand and I agree that SimH should conform to that
> goal.
>
> However, I do have a question about a real hardware
> CPU from Mentec? The M11 and N11 are capable
> of being detected under RSX-11 and have the code
> to display that CPU type as PDP-11/95 and PDP-11/97,
> respectively - if I understand the code from RSX-11
> correctly which does the identification.

Note that 11/95 and 11/97 are not "official" designations. It's just
that RSX stores the system model number in core, and since it's an
integer, M11 and N11 are not possible to store as such. So developers
chose to call the M11 the 11/95 and N11 the 11/97 pretty arbitrary.

> Does SimH presently emulate these two Mentec boards
> and if not, might that be a future addition to the code?

Without being Bob, I'd say that yes, it might very well be an addition
in the future. SimH aims to emulate existing machines. I don't see a
problem with adding a few more models to the (already) long list of
machines emulated.

Going even further, I'd say that adding another CPU, which does not even
exist as a physical product, would not be against SimH either (even if
it isn't exactly within the goal either). If you decide to emulate a
machine that does not currently exist, there is nothing preventing SimH
from, for this machine, have new features and possibilities.

> If the goal is to emulate only DEC PDP-11 CPUs,
> then it would be reasonable to ignore the Mentec
> CPUs. Otherwise, since Mentec seems to have sold
> many such CPUs, it would seem reasonable to
> include them. However, it might not be possible
> given that it does not seem possible to locate any
> manuals for the Mentec CPUs. bitsavers was negative
> and a Google search was equally unproductive.

SimH does not only emulate DEC machines in general. So I fail to see
that it should restrict itself to only DEC models of the PDP-11 out of
some principle.

[Johnny Billquist]

On 2012-01-31 22:39, Bill Gunshannon wrote:
> In article<jg9i9n$n3i$1...@iltempo.update.uu.se>,

Not totally clear, and I actually think Jerome was looking for something
else...

>> or a way to identify a
>> machine running under E11/Simh/whatever.
>
> But isn't the inability to tell you are running on an emulator the
> true proof that the emulator works?

Right. But Jerome, for some reason, wants to do just this, if I
understand him correctly.

>> In the latter case, a serial
>> dongle would definitely be wrong. In the former case, what would it be
>> used for at all?
>
> Again, I think I came in late but I thought someone was looking for
> a way to query a machine about what processor it had. Ah for the
> days of having software accesable front panel switches. :-)

Jerome want SimH, setup to emulate an 11/93, to still be identifiable as
a SimH emulated 11/93, as opposed to a real 11/93.

Don't ask me why. I'm trying to figure out what he wants... I have no
idea why.

>> I can, just for curiositys sake, understand that you might want to find
>> out if you are running under Simh or whatever. But then you need to do
>> something in Simh which is not possibly under any existing other machine.
>
> See my comment above!! If there is anythjing in the emulator that is not
> the same as the real thing, then the emulator needs to be fixed.

Right. I agree.

>> As an extension to this, you could also add new features, which would be
>> used when identified as such a machine, but this seems unlikely in general.
>
> But I think new features belongs in the fork mentioned above.

I would agree with that. If we want new features or whatever, we should
really design/designate a new system, and not try to piggyback it on an
existing model.

>> As I said from the start, I'm not sure what the point of all this is. :-)
>>
>
> Me neither. Maybe I should have stayed out of it. :-)

No. It's more fun with you in it. :-)

[paramucho]

On Wed, 01 Feb 2012 12:48:42 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>On 2012-02-01 12:22, paramucho wrote:
>> On Tue, 31 Jan 2012 22:53:32 -0500, "Jerome H. Fine"
>> <ever...@nospam.com> wrote:
>>
>> <snip>
>>>>
>>>> Selecting the MMU registers was initially process of elimination.
>>>> Following that, I knew that E11 doesn't actually attempt to fully
>>>> implement MMU register SR1. I started playing around on a J11 and F11
>>>> to see what happened when I jammed those registers in an illogical
>>>> manner. After a little experimentation I found a test which came out
>>>> differently on the F11 to the J11. Then I played around with E11 and
>>>> SimH. It's not that hard, and it's not the ideal test either.
>>>>
>>>>
>>> While I agree it is not the ideal test, the
>>> fact that it works and is actually quite
>>> simple is what is important.
>>
>> The reason that it's not ideal is that it doesn't handle CPU
>> configurations that don't have memory management, e.g. LSI's and early
>> unmapped PDP-11s. I haven't tested it on all the different MMU
>> configurations either.
>
>I think a bigger reason that it's not ideal is that at least Bob Supnik
>have the explicitly stated goal that it should not work. Any current
>differences from the real machine are bugs, and are subject to be fixed
>at any time, at which point the test wont work anymore.

That's not exactly what was stated. Without wishing to put words into
anyone's mouth, BobS wrote this:

The model emulation in SimH is not perfect, which is why clever
software can detect it. But the intent is to mimic real systems.
SimH is not a "different" PDP11.

And what I wrote earlier was this:

The trick was to find some "undefined" behavior that didn't need
correction. The code above gets different results from an F11 and a
J11 as well as from SimH and E11. The test is far from ideal, but it
works well enough for my purposes.

My point being, that I'm not sure that the behavior I'm using needs to
be "corrected" in the sense that I'm not sure it's actually "defined".
I'm not even sure that the behavior I'm using can be corrected without
a considerable effort. (One reason I'm not sure is that I wrote the
code years ago and I've forgotten whether the result values could be
computed or would need to be (at least partially) enumerated).

>> However, these days I could probably use the clock/terminal timing
>> loop to detect an emulator more generally (it used to fail in the past
>> because nulls were output as spaces on SimH). Once I knew I was on an
>> emulator I might be able to come up with some basic difference between
>> SimH and E11.
>
>Timing might be the only thing that Simh in general will have a hard
>time hiding.

The problem is that timing is hard to measure in an emulated machine
because one doesn't know how busy the machine is. An emulated machine
might be getting anywhere between 1% and 100% of the hosts actual CPU
time. That variability itself could be measured in some, but not all
circumstances.

Disk I/O provides another opportunity for testing. I guess that SimH
disk I/O is synchronous, i.e. is always actually completed before
control is returned to the emulated CPU after the interrupt servicve
routine delay cycles. But to test that you'd probably need to use
direct access to the device registers and that in turn would require
per-device tests. I'm likewise not sure if E11 is synchronous. V11
certainly is.

<snip>

>> The advantage of the register behavior test is that it tests SimH and
>> E11 out-of-the-box, as delivered. Any test which is based on custom
>> versions of SimH and E11 has exactly the disadvantage that it won't
>> test the standard deliverables, which is what most people use. Thus,
>> it makes sense to use my register test, or something equivalent when
>> the custom instruction/device is not present.
>
>Right. The only addition being that at least SimH should not be
>identifiable this way either. It's a bug that you are using at the
>moment. Expect it to go away sooner or later.

See above. It may go away, but not necessarily. It would be fun if it
did 'cos I'd have to scratch my head and look for something else.



Ian

[paramucho]

On Wed, 01 Feb 2012 12:53:17 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>> One additional question. E11 has a device called HD: or Hypothetical Disk.
>> It is very simple and supports GB of disk files as a device. Would anyone
>> be interested in supporting this hardware under SimH? It is just
>> as simple as the RK05, probably more so, but I don't use SimH
>> enough to want to spend the time. Is anyone interested?
>
>But this is not E11 specific. It's a device. You just need to inform the
>system if this device exist or not, no matter what machine you have.
>It's not an E11-unique thing.

If you're talking about HD: then you've lost me. There is no HD:
emulation under SimH.

John Wilson implemented his "hypothetical disk" (aka russian disk) in
the early days of E11 before he'd done his MSCP code IIRC because it
gave him a variable size disk. He also supplied an RT-11 driver for
HD:. I did a compatible implementation of HD: along with a driver for
V11 for exactly the same reason. But there is no HD: emulation for
SimH. That's what Jerome is looking for.

<snip>



Ian

[stan]

paramucho wrote:
> On Wed, 01 Feb 2012 12:48:42 +0100, Johnny Billquist <b...@softjar.se>
> wrote:
>>On 2012-02-01 12:22, paramucho wrote:
>>> On Tue, 31 Jan 2012 22:53:32 -0500, "Jerome H. Fine"
>>> <ever...@nospam.com> wrote:
>>>
>>> <snip>

>>I think a bigger reason that it's not ideal is that at least Bob Supnik
>>have the explicitly stated goal that it should not work. Any current
>>differences from the real machine are bugs, and are subject to be fixed
>>at any time, at which point the test wont work anymore.
>
> That's not exactly what was stated. Without wishing to put words into
> anyone's mouth, BobS wrote this:
>
> The model emulation in SimH is not perfect, which is why clever
> software can detect it. But the intent is to mimic real systems.
> SimH is not a "different" PDP11.
>
> And what I wrote earlier was this:
>
> The trick was to find some "undefined" behavior that didn't need
> correction. The code above gets different results from an F11 and a
> J11 as well as from SimH and E11. The test is far from ideal, but it
> works well enough for my purposes.
>
> My point being, that I'm not sure that the behavior I'm using needs to
> be "corrected" in the sense that I'm not sure it's actually "defined".
> I'm not even sure that the behavior I'm using can be corrected without
> a considerable effort. (One reason I'm not sure is that I wrote the
> code years ago and I've forgotten whether the result values could be
> computed or would need to be (at least partially) enumerated).

Seems like a distinction without a difference. Changing behavior with
a purpose (correcting) and changing undefined behavior with or without
a purpose seems to have the same result. I would agree the risk of a
relatively mature simulator changing significantly seems acceptable,
but relying on undefined behavior is still building your house on
sand.

In the back of my mind I have warning bells going off screaming "how
hard will this be to debug if the undefined behavior changes?"