The goals here being to simplify calling code while getting consistent output delivered everywhere it may be useful.
Modified most places which explicitly used sim_log or merely called printf to now avoid doing that and merely call sim_printf().
Instead of conditionally compiling in bootstrap support depending upon attached channel, determine dynamically based on RAD's current assignment to channel W or channel E. This allows using "set rad channel=W" for purposes of bootstrapping, and then relocating the RAD with "set rad channel=E" for running a TSS monitor that expects to find the RAD on channel E.
Normally the RAD is connected to the E channel and there is no bootstrap capability (because of hardwired WIM instruction). However, for completeness, add code to allow booting from the RAD if it is connected to the W channel. Add RAD_CHAN definition to define which controller the RAD is connected to.
Improve parentheses in bootstrap code that allows an optional word count (while also permitting the canonical bootstrap sequence).
The canonical boot sequence uses WIM 0,2 in location 5 and an initial load address in location 11 (and in the X register). This is limiting for devices like RAD that do not report an end-of-file, or for paper tape that report EOF too late and cause the WIM to fail. A simple load address in location 11, with bit 9 set to satisfy the BRX, doesn't do any word counting. The BRX always branches back to location 5.
This change allows a true negative word count to be placed in location 11 to work with a WIM XXXXX,2 where XXXXX is one location past the region to be loaded by the boot sequence. XXXXX plus the negative count in location 11 (buf[3]+buf[7]) initially points to the first location to be loaded, and the BRX will not branch when the word count is exhausted (register X=0) allowing the branch to the start address to be executed.
Old allowable boot sequence:
location 2 = WIM 12,2
location 3 = BRX 2
location 4 = LDX 11
location 5 = WIM 0,2
location 6 = SKS 21000
location 7 = BRX 5
location 10 = BRU Transfer Address
location 11 = Load address with bit 9 set to force BRX to branch
New allowable boot sequence:
location 2 = WIM 12,2
location 3 = BRX 2
location 4 = LDX 11
location 5 = WIM [end load address + 1],2
location 6 = SKS 21000
location 7 = BRX 5
location 10 = BRU Transfer Address
location 11 = Negative count to number of words to load
Received better fix from Mark Pizzolato for the problem of having 120 clock interrupts per second instead of 60. Tested for several hours and verified that wall-clock time matches TSS monitor time.
Document new breakpoint types and display and input of packed SDS internal ASCII characters. Add note describing memory map options for display and input discovered in code. Word change tracking enabled.
Clock is running twice as fast as it should -- 120 interrupts per second instead of 60. Cannot find problem in initialization or calibration or count-down code, so for now, divide rtc_tps by 2 prior to invoking sim_rtcn_calb. Now 940 Executive reports wall-clock time advancing at proper rate.
Breakpoint logic now allows four execution-type breakpoints:
-E as before, break if PC equals address, unqualified by mode
-M break if PC equals address and machine is in monitor mode
-N break if PC equals address and machine is in normal (SDS 930) mode
-U break if PC equals address and machine is in user mode
SDS internal ASCII differs from standard external ASCII. Alter the examine and deposit functions with -A switch to properly adjust between the two forms. Also allow strings rather than one-character per word as was in the original code. Clean up six-bit character display logic to use a loop.
Remove superfluous trailing blanks from lines in file.
rad_adjda was setting sba=0 at a sector boundary, which did not reflect that the first 12-bits of the sector have already be read or written. Must set sba=1 for proper addressing.
Removed superfluous end-of-line spaces from file.
1. In pot_fork, the permanently asserted interrupt, the interrupt bits were assigned in the wrong order -- bit 8 is interrupt 0 and bit 23 is interrupt 017 in each group of 16. Also, the group number was incorrectly calculated -- need to subtract 0200 before dividing by 020.
2. In case 3 of EOM and SKS when in SDS mode, it does not dispatch properly. The device table is set for Genie mode. Add test for device 077 in SDS mode and switch to device 1, which is Mux in Genie mode.
3. Add test to PIN to verify that scanner is locked before returning PIN data.
4. Mux should not queue a new interrupt for a flag type if it is already queued and pending for a different channel. If do so, when the CPU clears the interrupt, the second interrupt is lost.
5. If POT specifies interrupt but no Tx character present, queue a Tx interrupt immediately if the transmitter is not active. This technique is used by the 940 monitor to start output of the transmit character buffer.
6. Per the 940 reference manual, after servicing the highest priority interrupt on a particular channel, the scanner should look at all other channels before looking for additional interrupt types on the first channel. Change scanner to always resume scan with the Rx interrupt on the next channel from where the scanner paused.
Also removed superfluous trailing blanks from lines in file.
From actual monitor code, sequence used to read drum:
EOD* 10000B Alert Interlace
GDAC3: EOD 14202 I/O control mode EOD (mode 1)
A=0 High order memory address bits
Hicount=2 (Word count=04000=2KW)
POT GDBCL+2 Low-order memory address bits.
RRF (EOD 2226) Read RAD file (mode 0)
Problem is that RRF is clearing the interlace information saved by the previous POT and sets up for a new POT. That is, in sds_io.c, mod 0 of op_eomd always assumes that a POT will follow if the channel is C or greater. Have to add tests of chan_flag. If interlace is active, do not capture new information from this EOM/EOD.
Also removed superfluous trailing blanks from lines in file.
The single-instruction Clock Pulse interrupt (75 octal) may be a MIN or SKR instruction. The function rtc_inst increments (MIN) or decrements (SKR) the operand and tests for zero and generates a Clock Sync interrupt (74 octal) if so. However, the SDS 940 reference manual is incorrect; in the SKR case, the test should be if the result is negative.
1. When transitioning from monitor to user mode with the trap enabled, the trap was latching the monitor address of the transferring branch rather than the user-mode address of the branch target.
2. When executing a BRU, BRX or BRM in monitor mode, if the effective address was in user mode, the code neglected to transition the machine to user mode. And after doing so, it is necessary to check for an armed monitor-to-user trap.
Also removed superfluous trailing blanks from lines in file.
