20 Mar
2021
20 Mar
'21
5:19 p.m.
My understanding of the OS/8 TC08 bootloader (MI8-EC) is as follows:
0. Rewind tape
1. Set current address (07755) to 07600
2. Set word count (07754) to -0200
3. Read block 0 and wait for flag
4. Continue executing at 07600
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.
But according to SimH, a write to the current address, 07755, never
happens. How can this be?
Any help would be appreciated!
Kyle
20 Mar
20 Mar
5:51 p.m.
On Sat, Mar 20, 2021 at 7:19 PM Kyle Owen <kylevowen at gmail.com> wrote:
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
21 Mar
21 Mar
5:24 a.m.
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:
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.
6:35 a.m.
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 
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
7:05 a.m.
On Sun, Mar 21, 2021, 09:35 Rick Murphy via cctalk <cctalk at classiccmp.org wrote:
You have to read the bootstrap code in the TC0x driver to understand this.
I agree with your assessments, but I'm referring to the first stage
bootloader: either your toggle-in or MI8E-based ROM bootstrap. In the case
of that, the PDP-8 is in a spin loop waiting for the first load of block 0
into 07600; the rest of the bootstrap in the driver isn't yet loaded in
core.
But you did answer the question that was bugging me, and that's the end
error flag getting set at the end of a block in single read mode. Nice,
thank you!
I'm still a bit suspicious of the handling of WC overflow in SimH, even
though, as you point out, it does not matter here. The difference it makes
for the toggle-in boot process is whether or not it loads unnecessary code
at 1, after WC and CA both are overwritten with zeros. Either way, the
first read will terminate, but with default SimH behavior, the read
terminates early, after writing a zero to WC.
In the 3-cycle break, WC is incremented in the first cycle. If a carry was
generated, the WC overflow flop is set. CA is incremented in the second
cycle. The actual data transfer happens in the third. Hence, overwriting
either WC or CA cannot affect either until the following cycle. So, writing
a zero to WC should not cause an overflow until 4096 breaks later.
Am I looking at this correctly?
Kyle
11:28 a.m.
On Mar 21, 2021, at 9:35 AM, Rick Murphy via cctalk
<cctalk at classiccmp.org> 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 details are different, but it reminds me a bit of the magic used in the bootstrap on
the CDC 6000 mainframes. The "deadstart panel" (boot rom implemented as 12 rows
of 12 toggle switches) does a rewind followed by reading the first tape block into the top
of memory. During a read (or write) instruction, the program counter is temporarily
stored in location 0 so it can be put to work as a buffer pointer instead. The starting
address of the read is arranged so the block read wraps around into location zero, the
last word of the block overwrites the saved PC and causes execution to continue at that
address. Saves two words in the boot ROM.
paul
2:14 p.m.
On Mar 21, 2021, at 2:28 PM, Paul Koning
<paulkoning at comcast.net> wrote:
Another example and a more significant one of a self modifying boot loading process is the
"emulator IPL" on the IBM 360 model 44. The "emulator" is a chunk of
separate memory and control used to emulate the SS instructions not implemented in the
hardware. I used such a machine in college and looked at the card deck for the emulator.
IPL ("initial program load") reads a record from the boot device -- the card
reader in this case -- which is a channel program that is then executed to read the actual
initial code. In the emulator case, the rest of the card deck is a standard binary output
file from the assembler -- think LDA format on a PDP-11. The first card is a nice
concoction of several channel commands that read another card, drop the load address and
byte count fields for that card into another channel command word, then executes that CCW
to send the data on the card to the right memory location. It then loops back (CCW
"command chaining") to do the same with the next card. So the entire deck load
is executed by the channel, no CPU involvement at all, transfering the right number of
bytes from each card to the location it asked for.
I don't have any of this preserved, but it wouldn't be too hard to reconstruct the
details from that description. An exercise for the student... :-)
paul
On Mar 21, 2021, at 9:35 AM, Rick Murphy via
cctalk <cctalk at classiccmp.org> 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 details are different, but it reminds me a bit of the magic used in the bootstrap on
the CDC 6000 mainframes.
3:06 p.m.
On 3/21/2021 10:05 AM, Kyle Owen via cctalk wrote:
On Sun, Mar 21, 2021, 09:35 Rick Murphy via cctalk
<cctalk at classiccmp.org>
wrote:
The instruction that's waiting on the done bit to be set is overwritten
with a NOP while the bootstrap is being read.? This is common for
bootstraps: minimal user-entered code that gets overwritten by the boot
when it's being loaded into memory.
You have to read the bootstrap code in the TC0x
driver to understand this.
I agree with your assessments, but I'm referring to the first stage
bootloader: either your toggle-in or MI8E-based ROM bootstrap. In the case
of that, the PDP-8 is in a spin loop waiting for the first load of block 0
into 07600; the rest of the bootstrap in the driver isn't yet loaded in
core. But you did answer the question that was bugging me,
and that's the end
error flag getting set at the end of a block in single read mode. Nice,
thank you!
I'm still a bit suspicious of the handling of WC overflow in SimH, even
though, as you point out, it does not matter here. The difference it makes
for the toggle-in boot process is whether or not it loads unnecessary code
at 1, after WC and CA both are overwritten with zeros. Either way, the
first read will terminate, but with default SimH behavior, the read
terminates early, after writing a zero to WC.
In the 3-cycle break, WC is incremented in the first cycle. If a carry was
generated, the WC overflow flop is set. CA is incremented in the second
cycle. The actual data transfer happens in the third. Hence, overwriting
either WC or CA cannot affect either until the following cycle. So, writing
a zero to WC should not cause an overflow until 4096 breaks later.
Am I looking at this correctly?
You have to read the code to understand this. :)
The setting of the WC to zero happens in the code I posted.
"BOOT3", after the first read is completed into field 1 (skip loop just
above BOOT3) to read block 1 into memory starting at 7600. It deposits
7577 (7600 minus 1) into the address field (7755) and zero into WC
(7754) because the DCA of the address pointer zeroed the AC.? Once block
1 is read in, the boot jumps to OS/8 (7605 in field 0).
??? -Rick
Kyle
4:01 p.m.
On Sun, Mar 21, 2021, 18:07 Rick Murphy via cctalk <cctalk at classiccmp.org wrote:
The instruction that's waiting on the done bit to
be set is overwritten
with a NOP while the bootstrap is being read. This is common for
bootstraps: minimal user-entered code that gets overwritten by the boot
when it's being loaded into memory.
You have to read the code to understand this. :)
The setting of the WC to zero happens in the code I posted.
Rick, I think we're talking about two different bits of code.
The code I am referring to is here:
http://svn.so-much-stuff.com/svn/trunk/Eagle/projects/DEC/Mxxx/M847/m847/m8…
It does not get rewritten, at least not right away. It's at 07554, and the
first load happens at 07600, to get the rest of the bootloader code you're
referring to. There's another almost identical loader I've seen used by the
PDP-8/E Simulator for macOS, which is loaded at 0200 instead.
The handler makes some comments:
/BOOTSTRAP FOR DECTAPE MONITOR IS THE SAME AS FOR THE
/DEC LIBRARY SYSTEM, RL MONITOR AND POLY BASIC - OR JUST
/READ RECORD 0 INTO 7600 AND TRANSFER TO 7600 A LA DISK
/MONITOR SYSTEM ON DECTAPE
The code you're referring to has to get into memory somehow, and my
question involves this process, not afterward.
So, I think you're a step ahead here! :) I don't disagree with anything
you've said regarding the rest of the boot process, though.
Thanks,
Kyle
1154
days inactive
1154
days old
9 comments
4 participants
participants (4)
-
bobsmithofd＠gmail.com -
kylevowen＠gmail.com -
paulkoning＠comcast.net -
rick＠rickmurphy.net