-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathNOTES
99 lines (72 loc) · 3.83 KB
/
NOTES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
Miscellaneous notes about the emulation
******************
ABOUT PDPASMHELPER
******************
This started as a way to make it easier for me to write simple
assembly-language test programs. I really wanted to avoid reimplementing
a full-blown assembler, so it was mostly about opcodes and addr modes.
Then I got tired of hand-calculating labels for simple jumps/loops.
So the InstructionBlock was born, and the label support, including
forward references.
The whole implementation of that is, in my opinion, a ridiculous hack and
it has a lot of rough-edges and surprising semantics.
It is what it is; it works good enough for the pdptests and the
occasional hack/test program. The whole thing should probably just be
chucked out the window as I am not super-interested in turning
the "assembly helper" into a full-featured bug-free assembler...
It really should just be replaced with a real assembler/toolchain.
****************************
RUNNING OTHER LEGACY SYSTEMS
****************************
I have tried to boot unixv6, but it requires an RK emulation. Emulating
those drives should not be difficult but I just haven't gotten to it.
I tried to boot sysIII unix. Amusingly, it has a bug (I think this is
a bug) ... it won't boot on an 11/70-compatible system that lacks the
floating point option (this is a weird dependency!)
The reason is that if there is split instruction and data space, the
boot code (reasonably and what you want it to do) separates out the
instruction and data segments of the kernel and then marks the instruction
segment read-only. This is all good stuff.
THEN, in the boot sequence before main() of UNIX kernel is invoked, it
does this:
[ this code in start.s in /usr/src/uts/pdp11/ml/mch_id in a sysiii system ]
/ test for floating point hardware
setd
nofpp:
The way this "tests" for floating point hardware is quite obscure.
If there is not floating point hardware, setd is an illegal instruction.
Going to the trap handler (trap.s in same directory) the code for
illegal instruction traps does this:
bit $20000,PS
bne 2f
cmp (sp),$nofpp
bne 2f
mov $PRSUPR,PS
mov $RTSPC,-(sp)
mtpi _savfp
mov $RTSPC,-(sp)
mtpi _restfp
This is awesome. It looks to see if executing in kernel mode, then it
looks to see if the illegal instruction occurred at 'nofpp' (the pc is
always PAST the illegal instruction when the trap occurs), and if so,
then it... PATCHES an "rts PC" instruction into the instruction space
at the start of savfp() and restfp(), turning them into no-ops.
Unfortunately, this code executes after the boot process has turned on
separation of I and D spaces and marked the I space read-only. So it crashes.
I have to assume that either there is no such thing as an 11/70 without
floating point, or that "out in the wild" no one ever ordered an 11/70
without floating point.
Either way, sysIII won't boot because of this.
I did try an ungodly hack in mmu.py to (wait for the amazingness of this)...
ALLOW the first two writes into instruction space if they occur in kernel
mode (that was a temporary alteration, I took the code back out of course).
This allowed sysIII to get past this problem, but it still wouldn't boot.
I'm not sure why; I have a guess it might not like my disk driver emulation
details (as I only emulate a subset of total functionality, which was enough
to get unixv7 going). But I have not analyzed this any further.
At some point "why aren't you just using SIMH" becomes the right answer.
But it would have been nice to get another unix system going just as further
validation of the emulation fidelity.
OTHER SYSTEMS: I tried a few of the RT/RSX/etc DEC-native systems but
couldn't get them to boot. I did not analyze why. I imagine, of course,
there are more fidelity issues with this emulation.