21 Mar
2021
21 Mar
'21
6:45 a.m.
thanks, came through to ENDB here! great explanation!
bb
On Sun, Mar 21, 2021 at 9:35 AM Rick Murphy via cctalk
<cctalk at classiccmp.org> wrote:
On 3/20/2021 8:51 PM, Kyle Owen via cctalk wrote:
On Sat, Mar 20, 2021 at 7:19 PM Kyle Owen
<kylevowen at gmail.com> wrote:
Trying again - my reply got chopped off for some reason.
You have to read the bootstrap code in the TC0x driver to understand this.
What happens is that the code watches the buffer pointer (7755) and when
it hits 7642, the remaining read is directed to field 1. The boot is
looping on 7616/DTSF and 7617/JMP .-1 when it's overwritten by the boot
(the NOP below overwrites the DTSF).
The other weirdness is that a Read Data operation sets the done flag at
the end of the block, so reading a single block means that the WC is
unimportant. (Continuous mode reads multiple blocks as controlled by the
WC).
Lowercase comments below are mine.
-Rick
BOOT1, TAD 7755 /this gets the buffer pointer
TAD BM7642 /and checks if it's at 7642
SNA CLA /WATCH THE PROGRESS OF THE READ
JMP BOOT2 /WHEN IT GETS PAST 7643, SWITCH TO FIELD 1
NOP /LOADS OVER DTSF IN 7616
JMP BOOT1 /LOADS OVER JMP .-1 IN 7617 - STARTS BOOTSTRAP
BOOT2, TAD B10
DTLB /ZAP A 10 INTO STATUS REG B TO LOAD INTO FIELD 1
DTSF /FROM HERE ON - LOAD THE FIELD 1 RESIDENT INTO
FIELD 1
JMP .-1
BOOT3, DTXA /CONTINUE READING NEXT RECORD(ALSO SEE CODE AT
7600)
DTLB /INTO FIELD 0
TAD B7577
DCA 7755 /PAGE 7600
DCA 7754 /here's where your zero gets set for the WC.
BOOTX, CDF CIF 10
JMP 7642 /JUMP INTO WAIT LOOP IN FIELD 1
JMP BOOT1 /DISK MONITOR FUDGE - JUMP INTO WAITING LOOP
B7577, 7577
B10, 10
B600, 600
B620, 620
ZBLOCK 7642-. /this gets loaded into field 1.
DCA 7744
DTSF /THIS IS LOADED INTO FIELD 1 WITH MONITOR RESIDENT
JMP .-1 /IT IS IN THE CD OUTPUT AREA AND SO WILL BE ZAPPED
CDF CIF 0 /BY THE KEYBOARD MONITOR
ENDB, JMP 7605 /OK, FIELD 0 RESIDENT READ IN, START UP MONITOR
However, it appears as though word count will be
hit by the loading of the
first block. In fact, my instrumented version of SimH says it's overwritten
with a zero. If that's the case, it would seem as though the word count
overflow flag will never get set. Not to mention, the current address will
be updated next, causing data to be redirected to yet another position.
To continue this thought, it appears as though SimH does the following for
a read data break:
0. Increment WC
1. Increment CA
2. Compute memory address from the extended memory bits from the TC08 and CA
3. Store the data from the tape at the memory address specified from 2.
4. Check if WC equals zero, and handle that accordingly
From what I can tell, both the PDP-8/E and the
PDP-8/I set the WC overflow
based on the carry out from the adders...so if WC
happens to be overwritten
with a zero, a carry out will never happen in the real hardware. In SimH,
the entire WC is tested and compared to zero. This behavior seems different.
Kyle