Re: ODE 2.1.1 documentation

[Tony Aiuto via cctalk]

It looks like I have the ODE source (with doc sources) for 2.3.4 and 2.3.6

2.3.4 is from 1997, 2.3.6 from 1998.  Is that old enough for you?

IANAL, but the copyright doc looks good

Copyright (c), 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998

The Open Group Research Institute ("TOG RI"),

Permission is hereby granted to use, copy, modify and freely distribute
the software in these files and their documentation for any purpose without
fee, provided that the above copyright notice appears in all copies and
that both the copyright notice and this permission notice appear in
supporting documentation.  Further, provided that the name of The Open
Group Research Institute TOG RI not be used in advertising or
publicity pertaining to distribution of the software without prior
written permission from TOG RI.  TOG RI makes no representations
about the suitability of this software for any purpose.  It is provided
"as is" without express or implied warranty.

RE: VAXstation 2000 network & hardware guides (English & German)

[Maciej W. Rozycki via cctalk]

On Sat, 20 Mar 2021, Dave Wade G4UGM via cctalk wrote:

> These arrived this morning and they are scanned and OCR'd here:-
> 
> https://1drv.ms/u/s!Ag4BJfE5B3onlY9td7hHhHPnUKV2bA?e=hDKwES
> 
> I think I can scan at lower resolution and/or grey scale as these are a 
> bit on the huge side

 Storage is cheap nowadays so I'd keep whatever the master copy is at good 
quality.  You can always convert to a lower resolution or a lossy format 
later on if you need to save space, but you can't recover lost fidelity 
once you've done so.

  Maciej

Re: ODE 2.1.1 documentation

[Tony Aiuto via cctalk]

On Sat, Mar 20, 2021 at 2:16 PM Ben Huntsman via cctalk <
cctalk@classiccmp.org> wrote:

> Hello!
>Does anyone have any old documentation for ODE 2.1.1, or relatively
> close versions?  I know "newer" versions have been released and have
> documentation available, but there are some changes in some of the config
> files that are very different from older versions.
>

ODE the OSF Development Environment?


> For example when creating a sandbox, in the sandbox directory there is a
> subdirectory called rc_files, that is supposed to have two files, "local"
> and "shared", but they don't work the same way that rc_files/Buildconf and
> Buildconf.exp work in newer versions...
>
>  Anyone on here know anything about ODE, or any other sources of
> information?
>



> Many thanks!
>
>

Re: TC08 DECtape bootloader question

[Kyle Owen via cctalk]

On Sun, Mar 21, 2021, 18:07 Rick Murphy via cctalk 
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/m847yc.pal

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

>

Re: TC08 DECtape bootloader question

[Rick Murphy via cctalk]

On 3/21/2021 10:05 AM, Kyle Owen via cctalk wrote:

On Sun, Mar 21, 2021, 09:35 Rick Murphy via cctalk 
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.


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.



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

Re: TC08 DECtape bootloader question

[Paul Koning via cctalk]

> On Mar 21, 2021, at 2:28 PM, Paul Koning  wrote:
> 
> 
> 
>> On Mar 21, 2021, at 9:35 AM, Rick Murphy via cctalk  
>> 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. 

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

Re: DECtape ancestry (Kyle Owen)

[Lars Brinkhoff via cctalk]

Michael Thompson wrote:
> Kyle Owen wrote:
>> What systems took advantage of the bidirectional nature?
>
> ADSS on the PDP-9 does an interleave of 6 when reading/writing to the
> DECtape. If it runs off the end it reverses direction and keeps going.

MIT's MACDMP (and by extension, ITS) does this too.  I think some DEC
format as well, right?

Re: DECtape ancestry (Kyle Owen)

[Michael Thompson via cctalk]

>
> Date: Sat, 20 Mar 2021 16:21:44 -0400
> From: Kyle Owen 
> Subject: Re: DECtape ancestry
>
> What systems took advantage of the bidirectional nature?
>
> Kyle
>

ADSS on the PDP-9 does an interleave of 6 when reading/writing to the
DECtape. If it runs off the end it reverses direction and keeps going. I
have seen some library files take three passes of the DECtape to fully
search.

-- 
Michael Thompson

Re: VCF Swap Meet in Wall, NJ

[Richard Pope via cctalk]

Jeffery,
Yep! All of the states have this provision. It isn't being told to 
the general public but it is there.

GOD Bless and Thanks,
rich!

On 3/21/2021 1:29 PM, Jeffrey Brace via cctalk wrote:

Just responding to Richard:
The current guidelines for New Jersey allow exceptions to mask where
wearing a mask would endanger one's health.

Jeff Brace


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: VCF Swap Meet in Wall, NJ

[Jeffrey Brace via cctalk]

Just responding to Richard:
The current guidelines for New Jersey allow exceptions to mask where
wearing a mask would endanger one's health.

Jeff Brace


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: TC08 DECtape bootloader question

[Paul Koning via cctalk]

> On Mar 21, 2021, at 9:35 AM, Rick Murphy via cctalk  
> 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

Re: VCF Swap Meet in Wall, NJ

[Jeffrey Brace via cctalk]

On Fri, Mar 19, 2021 at 9:54 PM Tony Aiuto  wrote:

> I don't think giant squids would be safe in the parking lot. Without a lot
> of water, they would dry out. We could continuously hose them down, but
> that might damage vintage hardware. Nothing is simple.
>

Although we do occasionally get giant squid coming up from the nearby Shark
River, they never make it too far inland because of the hill and forested
area. They usually get stuck in trees or hit by cars or attacked by the
giant bald eagles who like to eat them for snacks. There is little chance
for them to make it down the road to the large parking lot. If they do
possibly make it to the parking lot, then I will take out my Mega Charizard
from my poké bag and fry the sucker which will provide everyone with a nice
snack during lunchtime.


>
> RIchard: I'm curious, what form of disability prevents someone from
> wearing a mask, yet they are still mobile enough to attend an event?
>
> On Fri, Mar 19, 2021 at 9:33 PM Bill Degnan via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> What about giant squid?  You dont think it can happen to you and then...
>>
>> On Fri, Mar 19, 2021, 8:47 PM Jeffrey Brace via cctalk <
>> cctalk@classiccmp.org> wrote:
>>
>> > On Fri, Mar 19, 2021 at 7:58 PM Tony Aiuto 
>> wrote:
>> >
>> > > Nice. I have a lot of stuff I want to clean out of my basement.
>> > >
>> > > Will you be requiring masks for all attendees? Not doing so is a
>> > > deal breaker for me.
>> > >
>> >
>> > Yes. Everyone will need to wear a mask and follow all guidelines for NJ.
>> > Also keep in mind that this is an outdoor event so the risk is reduced.
>> >
>> >
>> > >
>> > > On Fri, Mar 19, 2021 at 6:50 PM Jeffrey Brace via cctalk <
>> > > cctalk@classiccmp.org> wrote:
>> > >
>> > >> Announcing our second Annual Vintage Computer Federation Swap Meet!
>> > >> Last year's Swap Meet was very successful so ... we are doing it
>> again!
>> > >>
>> > >> *DATE*: April 24, 2021 (RAIN DATE: April 25, 2021)
>> > >> *TIME*: 8AM to 2PM
>> > >> *ADDRESS*:
>> > >> Parking Lot on Monmouth Boulevard, Wall, NJ
>> > >> Across from Infoage Museum and Brookdale College
>> > >> *GPS location*: https://goo.gl/maps/m1AAS4UUziGXnoPeA
>> > >>  (40.1848793,-74.0630848)
>> > >> *WEBSITE*: http://vcfed.org/wp/vcf-swap-meet
>> > >> *EMAIL*: swapm...@vcfed.org
>> > >> *PHONE*: 732-722-5015
>> > >>
>> > >> Free to buyers.
>> > >>
>> > >> Vendor cost is per space. First space is $20, each additional space
>> is
>> > >> $10.
>> > >> You can park in your space and sell out of your vehicle.
>> > >>
>> > >> *SEND PAYMENT TO*: pay...@vcfed.org (FRIENDS AND FAMILY OPTION)
>> > >> Write in the note section:
>> > >> [your name]
>> > >> VCF Swap Meet 4/24/2021
>> > >> Number of spaces:
>> > >>
>> > >> *SWAP MEET SIGNUP*: https://forms.gle/kNCL8WVxTQcnw5nA6
>> > >>
>> > >> * Reservation doesn't guarantee sales.
>> > >> * The Vintage Computer Federation is only providing a space, vendors
>> > must
>> > >> bring their own tables, tents, cars.
>> > >> * In case of inclement weather, money paid will be refunded.
>> > >> * All items that you bring must be taken with you. No items are to be
>> > left
>> > >> behind.
>> > >> * Port-o-potty on site.
>> > >>
>> > >> Jeff Brace
>> > >> =
>> > >> Vice President & Board Member
>> > >> Vintage Computer Festival East Show-runner
>> > >> Vintage Computer Federation is a 501c3 charity
>> > >> http://www.vcfed.org/
>> > >>
>> > >
>> >
>>
>

Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: TC08 DECtape bootloader question

[Kyle Owen via cctalk]

On Sun, Mar 21, 2021, 09:35 Rick Murphy via cctalk 
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

>

Re: TC08 DECtape bootloader question

[Bob Smith via cctalk]

thanks, came through to ENDB here! great explanation!
bb

On Sun, Mar 21, 2021 at 9:35 AM Rick Murphy via cctalk
 wrote:
>
> On 3/20/2021 8:51 PM, Kyle Owen via cctalk wrote:
> > On Sat, Mar 20, 2021 at 7:19 PM Kyle Owen  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
>
> 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
>

Re: TC08 DECtape bootloader question

[Rick Murphy via cctalk]

On 3/20/2021 8:51 PM, Kyle Owen via cctalk wrote:

On Sat, Mar 20, 2021 at 7:19 PM Kyle Owen  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


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

Re: TC08 DECtape bootloader question

[Rick Murphy via cctalk]

On 3/20/2021 8:51 PM, Kyle Owen via cctalk wrote:

On Sat, Mar 20, 2021 at 7:19 PM Kyle Owen  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.


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