- Without regard to whether the circular buffer data is otherwise in
use while instructions are executing.
- When a circular debug buffer is in use, avoid writing out the contents
with the periodic open file flushes and only do so on returns to the
sim> prompt and when debug is closed
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.
- On MacOS, avoid Homebrew updating other pre-installed packages.
Autoupdating packages that aren't needed or referenced by the build
can take a very long time and cause the build timeout to be exceeded.
- Be sure to only save build results for changes to the master branch
of simh/simh
- Avoid saving binaries when one has been saved within the last week
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.
sim_instr does not completely follow the outline in the SIMH v3
developer docs. It does not decrease sim_interval in readin mode.
Fixing this, I cleaned up some other things:
- Move the decrease of sim_interval to after the check for breakpoints,
but before the check for ios. This ensures that sim_interval will
decrease any time an instruction executes in normal mode, or readin
mode executes, or ios is set and the CPU is waiting for ios to clear.
(Except the CPU should be clearing ios itself, not waiting for ios to
clear, but that fix requires a complete redesign of the I/O routines
and belongs in another branch.)
- Correctly handle all four combinations of mod_tst and mod_rdin.
- When changing from readin mode to normal mode, if cpu_set_mode returns
an error, stop with the same error. If cpu_set_mode returns SCPE_OK,
either stop or continue execution, depending on the word read from tape.
- In petr_boot and in the readin mode code in sim_instr, if the
PETR is not attached to a file, return SCPE_UNATT. Never try to read
from an unattached unit; I believe this reads standard input and
prevents ^E from working.
Overall control structure inside the while (reason == 0) loop:
- When stopping due to an error, break out of the while loop where
possible.
- After handling "ios is set", continue, don't run readin/test/normal-
mode code.
- After handling one readin operation, if the code didn't break out
of the while loop, continue, don't run normal-mode code.
sim_instr never clears it and simulation loops.
The CPU-to-device routines and device service routines need a redesign.
In the meantime, this quick patch makes tape punching possible.
Before, when the simulator decoded pad, it handled pad without cry
and pad with cry. When it decoded cry, it printed a "TO DO" message.
http://bitsavers.org/pdf/mit/tx-0/memos/M-5001-19_macros_Apr60.pdf
derives a simple algorithm for cry. Implement that, remove the test
for cry from the pad code, and reformat the debug messages.
The same change appears in sim_instr and sim_opr_orig.
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).
Adds 6850 DCD status latch to M2SIO devices.
Adds vector interrupt support to M2SIO devices.
Removes CTS inactive transmit disable from PMMI device.
Adds IMSAI-style programmed output to CPU/SIO devices.
SET CPU PO will display "PO: AREG" upon an "OUT 0FFH"
instruction.
SET CPU NOPO will disable the function (default).
Corrects problem with Mode 0 interrupts.
When the CPU receives an interrupt, it pushes the current
program counter on the stack. The current implementation
of Mode 0 was performing interrupt processing after fetching
the next opcode from RAM, which also increases the PC by 1.
This caused PC+1 to be pushed on the stack. The interrupt
processing is now done prior to fetching the next opcode,
preserving the correct program counter.
build_vstudio.bat converts the .vcproj files from Visual Studio 2008 to
.vcxproj when used with newer versions of Visual Studio and configures
it to build XP-compatible binaries using the v141_xp toolset. However,
this toolset is deprecated and may not be present when using Visual
Studio 2022. The script intends to edit the .vcxproj files only in the
case where it exists; however, due to a logic error it actually does
this unconditionally. This causes the build to fail on VS2022 when
the XP toolset is not present.
- 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
If the total sectors exceeds 127Gb this is not possible, but normal
simh disks are smaller and the largest user settable size via RAUSER
is just under 1Tb. The excessive size case (>127Gb) will have a CHS
of 0xFFFF10FF.
simh never cares about the CHS Disk Geometry value in the VHD footer
data structure, but other applications which do care about the CHS
value using the previously incorrect value as the capacity of the disk
even though the Current Size indicated in the footer may have been
larger.
