- Cleanup tape debug options and internal usage
- Add MTSE_DBG_INT for internal API activities
- Make sure SCSI uses the correct debug value for tape debug
Accept devices mapped at IOPAGEBASE -- text buffer/character generator
memory on video board starts at 160000.
Clear invalid PSW bits in trap handler -- system acceptance test writes
PSW 113705 to vector 34 (TRAP instruction).
Only the string instructions document the registers used by the
register-form instructions. Also document the BCD register-form
instructions. Although, the operands have already been loaded into the
special-purpose instructions before the op switch, I think this
documentation is useful.
These instructions are referred to as L2Dr and L3Dr in the PDP-11/24
System Technical Manual (https://www.vt100.net/manx/details/1,23) and
their opcode strings call them L2DR and L3DR. These comments seem to be
a simple typo.
Problem reported in https://github.com/open-simh/simh/issues/409
There are key differences between the MicroVAX I and MicroVAX II.
Specifically, the MicroVAX I is a machine with direct Qbus memory and
no QBA (Qbus Adapter) which is part of all later MicroVAXen and
corresponds to the UBA (Unibus Adapter) on systems with Unibuxes.
Among possibly other things, these Adapters primarily provide the
translation between the CPU's system memory and addresses on the
respective bus (Qbus or Unibus). These Adapters provide a set of
mapping registers which map the respective bus addresses to desired
locations in CPU memory which allows for "Scatter/Gather" memory
transfers. The MicroVAX I, having its memory directly on the Qbus,
has no CPU specific way to implement "Scatter/Gather" for I/O device
for memory transfers very much needed in systems with virtual memory.
On this system, the Scatter/Gather functionality is provided directly
within the MSCP controller which is simulated by the pdp11_rq.c
module.
On Qbus MicroVAXen with Qbus Adapters, the boot rom initializes all
the Qbus mapping registers such that Qbus addresses map directly to
CPU RAM addresses. This simplifies boot code which don't turn on
Virtual Memory (and thus the need for Scatter/Gather) until later stages
of the operating system boot. The Ultrix boot we're dealing with plays
games with the mapping registers somewhat early in the boot, and
requests a transfer of 0x2000 bytes (words maybe) to an address of
0x010000c8. Note that this would be the address from the point of
view of the controller on the Qbus. This value is actually beyond the
end of the 22bit Qbus address space (0x003fffff). The controller
therefore previously returned a non-existent memory error.
It would seem that instructions performing this I/O request are ones
which were loaded by an earlier read and thus the bug really should
be there, but since this code actually worked on real hardware,
accomodating that behavior belongs in the simulator. Meanwhile,
when this transfer has happened, the QBA Mapping registers have
been changed from their initial values that mapped 1-1 Qbus addresses
to RAM. The proper approach is therefore merely to ignore any bits
in the transfer address beyond the 22bits of the Qbus address space.
Interesting that all other operating systems (or boot code) never
presented a buffer address beyond the maximum 22bit Qbus address.
PDP11: RP11: Interrupt on IE+RESET+GO
Recent analysis of the 2.9BSD kernel revealed that RP11 was
expected to interrupt on control RESET function if IE bit was
also set. Documentation was not very clear of the fact, saying
in one place that RESET+GO does not interrupt (which is not
contradictory with the above because it does not mention IE).
In other place, however, it says that IE always causes interrupt
when DONE is asserted. Thus, since RESET does assert DONE, an
interrupt should be posted if IE is set. The autoconfig binary
from 2.9BSD uses this feature of RP11 to check the presence
of the controller.
Formerly RESET was always clearing RPCS with DONE unconditionally,
and that reset IE as well. This patch makes sure that the IE bit
is preserved, and if set, it posts an interrupt when RESET asserts
DONE.
PDP11: RP11: Make sure to advance DA after every I/O
It looks like disk controllers, which automatically update
disk address (DA) after completion of I/O, are expected to do
so even if there was no data transfer because of I/O errors.
I was studying RSX-11's Error Logger documentation and
examples are clearly offsetting disk addresses backwards
by one when I/O errors are reported by the controller.
Since once the controller has found the DA-specified sector,
the I/O begins regardless of the condition of the sector (bad
or good data) or ability to transfer the contents between the
disk and the memory. If an error occurs (NXM, for instance)
the operation would stop (with the error reported) at the end
of the sector. So if, for example, the bus address register
had a bad address from the get-go, no data would be able to
transfer at all, yet DA should still be updated with DA + 1
once the controller asserts the DONE bit.
This patch makes sure that DA is always advanced when I/O has
actually been commenced.
PDP11: RP11: Remove duplicate checks (now only done in svc routine)
PDP11: RP11: Implement delayed CS_DONE for "initiation" commands (SEEK/HOME)
Running earlier XXDP tests revealed that a technique of concurrent command
initiation and continued housekeeping for the command completion was used in
the old code.
For example, code could initiate a SEEK command for a drive, and knowing that
CS_DONE (and thus, an interrupt) is coming in about 16us, it would then go
ahead and clear a flag, which registers that the interrupt has occurred
(expected to be set to 1 by the ISR). If CS_DONE is set by the implementation
at the function initiation immediately, that would mean that the interrupt
could be triggered before the next instruction, and the flag would be set by
the ISR right away. The main code, however, would proceed with the the flag
clear as the following instruction, thus, never detecting the interrupt down
the road.
Since this technique was in existence, it is better to introduce a delay for
setting CS_DONE in the "fast" initiation commands like SEEK and HOME, to
accommodate the software that was relying on it.
So far, however, no issues were encountered in testing (except one), where
this delay mattered, but it's hard to tell if it would not be needed at all.
All I/O commands always delay CS_DONE already because they were never supposed
to be immediate.
Since the time for CS_DONE in initiation commands was documented at 16us, the
introduced delay is set to 10 instructions, which usually took more than that
to execute. But the interrupt flag clear case would be covered, as well as
the counted waits, which used some 25+-iteration tight loops for "drive ready",
before flagging a time-out (so the delay cannot be longer, either).
It also looks like more modern code never used any such tricks, so for it, it
should not matter if CS_DONE was slightly delayed or not.
PDP11: RP11: Major update after XXDP
Having run the device code thru XXDP and some other OS's and scenarios
rigorously, a bunch of discrepancies were found, which need to be addressed
by this rather extensive patch.
1. Each unit must implement its own "drive status" register, to be able to
track per-drive errors / conditions correctly;
2. Fixed INT_SET() / INT_CLR() in RPCS write function (wrong order of the "if"
conditions);
3. Some behavior was implemented not exactly how it was expected from the real
hardware, such as:
a. Post-I/O register values in RPDA and RPCA (including the corner case of
pack overflow);
b. I/O stacking, which wasn't mentioned in any available documentation, but
only XXDP listings;
c. RESET/IDLE function must be accepted for a "busy" controller;
d. HOME function must always execute, even when "device ready" is not set
(e.g. when SEEK error detected);
e. SEEK incomplete should not respond with "device ready" (however, the
condition can be cleared by HOME, d.);
f. WLOA-induced write-lock violation wasn't reflected in "device status".
4. Some timing was off so that the device worked "too fast" -- this was fixed
(except for the pathological cases when the races are in the actual test
code, and cannot be logically fixed);
5. WLOA setup command bug was fixed;
6. Added more code comments found per the above peculiarities.
A user observed that the TS11 would not run XXDP+, even though it ran
fine with the PDP11 operating systems, VMS, and XXDP V2. I traced this
back to a conceptual error in the implementation of some magtapes,
specifically the TS11, RH11/TM02-3, and the PDP10 TU45.
The issues is that beginning of tape, and being positioned in front of
the first record, are not necessarily the same. Following BOT, tape
drives record a ID burst If high density and an inter-record gap before
the first record. When the first record is read backwards or backspaced
over, the tape ends up at position 0 but should not show BOT. Most
simulated tape drives did this correctly, but a few used sim_tape_bot()
as a shortcut for BOT, and it's simply not correct.
BOT should be set at ATTACH, by a successful rewind, and by any reverse
operation when the tape is positioned in front of the first record.
BOT should be cleared by any successful movement operation, except
rewind.
17 777 740 - 17 777 742, read-only error address registers,
and 17 777 764, a read-only System ID register,
and are not handled in the CPU70_wr() routine, which means for these
addresses the routine returns NXM, which then translates to "bus timeout"
(no response to address), and then, as a result, trap to vector 4.
That is incorrect, IMO.
These locations are read-only yet the address gets decoded, and even
though writing does not have any effect, the write routine for these
addresses should return SCPE_OK.
The BOOT command for this device was not correctly documented in HELP
(appearing both supported and not) for PDP-11.
This change fixes the issue and syncs HELP output with the actual code
(by using the same #if conditional).
- Display Media-ID and Geometry info for all SHOW <unit> output when attached
- Use real drive Geometry info for all disk types
- Fix RA80 cylinders copied from RM80
- Fix RZ23 cylinders to reflect disk size
- Return correct cylinder info on MSCP error path
The first ROM included will be defined with names:
BOOT_CODE_SIZE
BOOT_CODE_CHECKSUM
BOOT_CODE_FILENAME
BOOT_CODE_FILEPATH
BOOT_CODE_ARRAY
and BOOT_CODE_URL
That first ROM will also have names:
BOOT_CODE_SIZE_1
BOOT_CODE_CHECKSUM_1
BOOT_CODE_FILENAME_1
BOOT_CODE_FILEPATH_1
BOOT_CODE_ARRAY_1
and BOOT_CODE_URL_1
Subsequent included ROM's will have names
BOOT_CODE_SIZE_n
BOOT_CODE_CHECKSUM_n
BOOT_CODE_FILENAME_n
BOOT_CODE_FILEPATH_n
BOOT_CODE_ARRAY_n
and BOOT_CODE_URL_n
where n is 2 thru the max number of supported ROM includes.
Leverage drive type flag DETAUTO which defers meta data addition to
happen at detach time. This allows pre-existing containers to be attached
to larger drives (with more platters) with autosize disabled and then if
autosizing is subsequently enabled before detaching, will thus add correct
meta data when the unit is detached.
Newly created containers will have meta data added at creation time and
updated to reflect data written beyond the original data in the container.
Note: To avoid potential breakage of existing PDP11 configurations in
the wild, which may expect RP on RHA, TU on RHB and RS on RHC,
RPB is connected to RHD Massbus adapter.
- More robust recovery when Massbus configuration errors occur
- More complete RH{A,B,C,D} help
Peter Allan analyzed the source code for the VAX780 simulator and
came up with a somewhat simple strategy to replicate the RP device
source code and to add another controller on an additional Massbus.
That initial strategy includes: Copying the pdp11_rp.c source module to
pdp11_rpb.c and making almost all global variables static as well as all
internal functions used in the RP device. All but the "DEVICE rp_dev",
that is, which now becomes "DEVICE rpb_dev" with a name of "RPB".
The change process was relatively simple although somewhat tedious and
wouldn't easily lend itself to manage future changes that might happen to
pdp11_rp.c.
The changes in this commit cleanup pdp11_rp.c so that changing it to
pdp11_rpb.c only need to affect 3 lines of code which will simplify
future maintenance of these modules.
In https:://github.com/open-simh/simh PR number 154 nickd4 that 2 argument
floating point instructions were displayed with the wrong argument order.
This change fixes BOTH the instruction display and the input activities for
these floating point instructions.
