As discussed in #378
The fixes include:
1. Tightening up the "magic" code so that it can now tell EXE, SAV, and RIM
formats apart.
2. Skipping the loader itself for both RIM10B and ITS RIM. (PDP10 Macro manual
says that RIM10B always includes the loader.) 3. Distinguishing ITS RIM from
RIM10B by the length of the loader block.
4. Adding the slight differences in processing between ITS RIM and RIM10B.
There is no documentation change. -R or the extension .RIM still invoke the
RIM loader, and the code tells ITS and RIM10B apart.
As reported by Josh Dersch in #358
Read hardware notes:
- While the TCCM error bit is a real flop, it is supposed to reflect
the OR of the TCST error bits at all time, so it is updated on read.
- A read of TCDT while the function is RALL clears DONE.
Write hardware notes:
- The TC11 behaves much more like a traditional DECtape controller
than a typical PDP11 peripheral. In particular, execution is
initiated/controlled by any write to TCCM, rather than setting
the GO (DO) bit. Unless the function is STOP or STOP ALL, writing
TCCM will put the selected tape in motion.
- Writing GO (DO) clears DONE (READY) and the error flops in TCST.
- Writing a 0 to ERROR clears the error flops in TCST. Because it
is write 0 to clear (later controllers used write 1 to clear),
the simulator has to know whether ERROR is actually written.
- STOP ALL ignores select errors. Every other function is rejected
if there is a select error.
- An illegal operation (setting ILO) will stop the selected tape.
- A write of TCDT while the function is RALL, WALL, or WTMK clears
DONE (READY). RALL should not be included, but it saved a gate
not to prevent it.
- Because DONE (READY) may not be clear when an operation completes
and DONE (READY) is set, the DT_SETDONE must test for DONE (READY)
not being already set.
ASCII mode for the paper tape reader and punch didn't <quite> work.
In ASCII mode, the <simulator> must create the leader and trailer. The
leader was already there. There shouldn't be nulls in an ASCII file. The
whole point is to be able to prepare and look at input and output files
with a normal text editor.
So this version should work right. It "autogens" trailer more or less
forever. It doesn't really need to return a STOP code on EOF, but users
would probably forget to put form feed at the end, so it doesn't hurt.
1. Implemented Expensive Typewriter mode for TTO.
2. Added ASCII conversion on paper tape punch as well as reader.
3. Changed conversion tables to recognize form feed (014) as FIODEC STOP.
simh.doc Writing a Simulator for the SIMH System
sim_breakpoints.doc The SIMH Breakpoint Subsystem
sim_vmio.doc Adding An I/O Device To A SIMH Virtual Machine
1. Added RP03 support and supporting "SET" commands.
2. Fixed implementation of DPCF (it's a full reset and not blocked by BUSY).
3. Fixed handling of JOB DONE flag (not touched by NOP, SEEK, or RECAL).
The terminal service (in the ISR) forces a CR to be output IMMEDIATELY (before anything in the output queue) when 0212 is seen on input, so it needs to echo as a LF.
I hadn't seen any (other) echo support, so I had assumed the interface was half-duplex, which of course means passwords would appear on the paper!
- Added unix v0 terminal support
- Added 3-cycle databreak set/show entries
- Revised for dynamically allocated memory
- Added support for -u modifier (UC15 and Unix v0)
These changes are to support the Unix v0 bringup and to implement a
"Unix input" mode on the console terminal. In Unix mode, CR and LF are
swapped (so that a modern terminal can use 'enter' instead of CTRK-J to
create the newline Unix expects), escape is mapped to altmode (175),
upper and lower case are enabled and the parity bit is forced to 1. This
most closely matches the characteristics of the KSR-37, but there is no
definitive evidence of the terminal that was actually used.
The problem has to do with the difference in how the PSW is stored when
the simulator is running (it's all in pieces) or stopped (it's collected in PSW).
cpu_ex is a console routine and expects the PSW to be stored in PSW, but
when history is collected, it's not. In particular, cm (current mode) is in local
variable cm.
cpu_ex with /v calls relocC, which derives the current mode from the
switches:
- if /ksup, use kernel/supervisor/user/previous mode (from PSW); otherwise,
use current mode from PSW
- if /d, use data space; otherwise, use instruction space
relocC is doing current mode i-space, which is what's wanted... except that
it's deriving current mode from PSW, rather than cm, which is where it's stored
while the simulator is running. It's fairly likely that PSW is long obsolete by the
time the history is invoked.
If the nested indirect/execute limit (INDMAX, XCTMAX) is set to 0, the simulator will loop indefinitely in an indirect address or execute loop, testing for interrupts before each memory reference. Thus, on an infinite loop, the simulator will never complete the instruction, but the instruction is interruptible. So for example, under TOPS-10:
.r ddt
1/ 0 jrstf @1
1$g
^C
^C
.
The JRSTF will never finish, but it can be interrupted by any device, and double ^C will return control to the command line.
If INDMAX or XCTMAX is non-zero, the previous behavior of limiting loops to a specific depth is retained. However, the default value is now 0.
This closes issue #218.
We're not absolutely sure that all of the changes are correct - in particular the treatment of record marks in add/compare - but they do make the diagnostics pass, which they didn't before.
Bob asked for variable tab stops on the typewriter, and those are implemented as well. The routines were general enough that I put the SET/SHOW processors in sim_console.c, so I'm enclosing that and its header file.
Design Notes for Fixing VAX Unaligned Access to IO and Register Space
Problem Statement: VAX unaligned accesses are handled by reading the
surrounding longword (or longwords) and
a) for reads, extracting the addressed addressed word or longword
b) for writes, inserting the addressed word or longword and then
writing the surrounding longword (or longwords) back
This is correct for all memory cases. On the 11/780, the unaligned
access to register or IO space causes an error, as it should. On
CVAX, it causes incorrect behavior, by either performing too many
QBus references, or performing read-modify-writes instead of pure
writes, or accessing the wrong Qbus locations.
The problem cannot be trivially solved with address manipulation.
The core issues is that on CVAX, unaligned access is done to
exactly as many bytes as are required, using a base longword
address and a byte mask. There are five cases, corresponding to
word and longword lengths, and byte offsets 1, 2 (longword only),
and 3. Further, behavior is different for reads and writes, because
the Qbus always performs word operations on reads, leaving it to
the processor to extract a byte if needed.
Conceptual design: Changes in vax_mmu.c:
Unaligned access is done with two separate physical addresses, pa
and pa1, because if the access crosses a page boundary, pa1 may
not be contiguous with pa. It's worth noting that in an unaligned
access, the low part of the data begins at pa (complete with byte
offset), but the high parts begins at pa1 & ~03 (always in the
low-order end of the second longword).
To handle unaligned data, we will add two routines for read and
write unaligned:
data = ReadU (pa, len);
WriteU (pa, len, val);
Note that the length can be 1, 2, or 3 bytes. For ReadU, data is
return right-aligned and masked. For WriteU, val is expected to
be right-aligned and masked.
The read-unaligned flows are changed as follows:
if (mapen && ((off + lnt) > VA_PAGSIZE)) { /* cross page? */
vpn = VA_GETVPN (va + lnt); /* vpn 2nd page */
tbi = VA_GETTBI (vpn);
xpte = (va & VA_S0)? stlb[tbi]: ptlb[tbi]; /* access tlb */
if (((xpte.pte & acc) == 0) || (xpte.tag != vpn) ||
((acc & TLB_WACC) && ((xpte.pte & TLB_M) == 0)))
xpte = fill (va + lnt, lnt, acc, NULL); /* fill if needed */
pa1 = ((xpte.pte & TLB_PFN) | VA_GETOFF (va + 4)) & ~03;
}
else pa1 = ((pa + 4) & PAMASK) & ~03; /* not cross page */
bo = pa & 3;
if (lnt >= L_LONG) { /* lw unaligned? */
sc = bo << 3;
wl = ReadU (pa, L_LONG - bo); /* read both fragments */
wh = ReadU (pa1, bo); /* extract */
return ((wl | (wh << (32 - sc))) & LMASK);
}
else if (bo == 1) /* read within lw */
return ReadU (pa, L_WORD);
else {
wl = ReadU (pa, L_BYTE); /* word cross lw */
wh = ReadU (pa1, L_BYTE); /* read, extract */
return (wl | (wh << 8));
}
These are not very different, but they do reflect that ReadU returns
right-aligned and properly masked data, rather than the encapsulating
longword.
The write-unaligned flows change rather more drastically:
if (mapen && ((off + lnt) > VA_PAGSIZE)) {
vpn = VA_GETVPN (va + 4);
tbi = VA_GETTBI (vpn);
xpte = (va & VA_S0)? stlb[tbi]: ptlb[tbi]; /* access tlb */
if (((xpte.pte & acc) == 0) || (xpte.tag != vpn) ||
((xpte.pte & TLB_M) == 0))
xpte = fill (va + lnt, lnt, acc, NULL);
pa1 = ((xpte.pte & TLB_PFN) | VA_GETOFF (va + 4)) & ~03;
}
else pa1 = ((pa + 4) & PAMASK) & ~03;
bo = pa & 3;
if (lnt >= L_LONG) {
sc = bo << 3;
WriteU (pa, L_LONG - bo, val & insert[L_LONG - bo]);
WriteU (pa, bo, (val >> (32 - sc)) & insert[bo]);
}
else if (bo == 1) /* read within lw */
WriteU (pa, L_WORD, val & WMASK);
else { /* word cross lw */
WriteU (pa, L_BYTE, val & BMASK);
WriteU (pa, L_BYTE, (val >> 8) & BMASK);
}
return;
}
Note that all the burden here has been thrown on the WriteU routine.
-------------
ReadU is the simpler of the two routines that needs to be written.
It will handle memory reads and defer register and IO space to
model-specific unaligned handlers.
int32 ReadU (uint32 pa, int32 lnt)
{
int32 dat;
int32 sc = (pa & 3) << 3;
if (ADDR_IS_MEM (pa))
dat = M[pa >> 2];
else {
mchk = REF_V;
if (ADDR_IS_IO (pa))
dat = ReadIOU (pa, lnt);
else dat = ReadRegU (pa, lnt);
}
return ((dat >> sc) & insert[lnt]);
}
Note that the ReadIOU and ReadRegU return a "full longword," just
like their aligned counterparts, and ReadU right-aligns the result,
just as ReadB, ReadW, and ReadL do.
WriteU must handle the memory read-modify-write sequence. However,
it defers register and IO space to model-specific unaligned handlers.
void WriteU (uint32 pa, int32 lnt, int32 val)
{
if (ADDR_IS_MEM (pa)) {
int32 bo = pa & 3;
int32 sc = bo << 3;
M[pa >> 2] = (M[pa >> 2] & ~(insert[len] << sc) | (val << sc);
}
else if ADDR_IS_IO (pa)
WriteIOU (pa, lnt, val);
else WriteRegU (pa, lnt, val);
return;
}
--------------
For the 11/780, ReadIOU, ReadRegU, WriteIOU, and WriteRegU all do the
same thing: they throw an SBI machine check. We can write explicit
routines to do this (and remove the unaligned checks from all the
normal adapter flows), or leave things as they are and simply define
the four routines as macros that go to the normal routines. So there's
very little to do.
On CVAX, I suspect that ReadRegU and WriteRegU behave like the
normal routines. The CVAX specs don't say much, but CMCTL (the memory
controller) notes that it ignores the byte mask and treats every
access as an aligned longword access. I suspect this is true for
the other CVAX support chips, but I no longer have chip specs.
The Qbus, on the other hand... that's a fun one. Note that all of
these cases are presented to the existing aligned IO routine:
bo = 0, byte, word, or longword length
bo = 2, word
bo = 1, 2, 3, byte length
All the other cases are going to end up at ReadIOU and WriteIOU,
and they must turn the request into the exactly correct number of
Qbus accesses AND NO MORE, because Qbus reads can have side-effects,
and word read-modify-write is NOT the same as a byte write.
The read cases are:
bo = 0, byte or word - read one word
bo = 1, byte - read one word
bo = 2, byte or word - read one word
bo = 3, byte - read one word
bo = 0, triword - read two words
bo = 1, word or triword - read two words
ReadIOU is very similar to the existing ReadIO:
int32 ReadIOU (uint32 pa, int32 lnt)
{
int32 iod;
iod = ReadQb (pa); /* wd from Qbus */
if ((lnt + (pa & 1)) <= 2) /* byte or word & even */
iod = iod << ((pa & 2)? 16: 0); /* one op */
else iod = (ReadQb (pa + 2) << 16) | iod; /* two ops, get 2nd wd */
SET_IRQL;
return iod;
}
The write cases are:
bo = x, lnt = byte - write one byte
bo = 0 or 2, lnt = word - write one word
bo = 1, lnt = word - write two bytes
bo = 0, lnt = triword - write word, byte
bo = 1, lnt = triword - write byte, word
WriteIOU is similar to the existing WriteIO:
void WriteIO (uint32 pa, int32 val, int32 lnt)
{
switch (lnt) {
case L_BYTE: /* byte */
WriteQb (pa, val & BMASK, WRITEB);
break;
case L_WORD: /* word */
if (pa & 1) { /* odd addr? */
WriteQb (pa, val & BMASK, WRITEB);
WriteQb (pa + 1, (val >> 8) & BMASK, WRITEB);
}
else WriteQb (pa, val, WRITE);
break;
case 3: /* triword */
if (pa & 1) { /* odd addr? */
WriteQb (pa, val & BMASK, WRITEB);
WriteQb (pa + 1, (val >> 8) & WMASK, WRITE);
}
else {
WriteQb (pa, val & WMASK, WRITE);
WriteQb (pa + 2, (val >> 16) & BMASK, WRITEB);
}
break;
}
SET_IRQL;
return;
}
-----------------
I think this handles all the cases.
/Bob Supnik
