How to rebuild TOPS10.REL
ger...@no.spam.mail.com
what follows was written about two and a half years ago, but was never
posted here because I hadn't any more time to play with TOPS-10. Now I'm
still struggling to find some spare time for it, but in the mean time...
Here it is:
I do need to rebuild TOPS10.REL because I've modified CLOCK1.MAC in
order to idle the KLH10 emulator when the TOPS-10 monitor is executing
the null job loop, as per other messages in this group (CONO 740,1).
At first I thought that a MONGEN and subsequent compile and link
phases would be enough, then I discovered that I need to entirely
rebuild TOPS10.REL (Am I right?). The Software Installation Guide (MIG
704) directs to Appendix B where it is suggested that, for more
information about building the monitor library file, I should read the
batch control file COMPIL.CTL.
Unfortunately COMPIL.CTL does NOT contain any comment or explanation.
I think it is intended for somebody with a previous somewhat deep
knowledge about such tasks, which I do not have. BTW even the relevant
manuals are not overly clear about this topic, and many little details
are left to immagination (or knowledge, as said).
Please, could you tell me, step by step, what I have to do to achieve
my final goal (idling the KLH10 emulator)? I'm using a quite standard
installation so common defaults should be fine, but there are anyway
lots of totally obscure files to customize (BUILDS.MIC, BUILDS.PTH,
GEN.MIC, ...).
If I recall correctly, the problem was that MONGEN and such would just
assemble some minor code and link a new monitor against the existing
TOPS10.REL without rebuilding everything from scratch, which is indeed what
I need to accomplish in order to have my modified CLOCK1.MAC considered (?).
Thank you,
G.
jmfbahciv
> Hello everyone,
>
> what follows was written about two and a half years ago, but was never
> posted here because I hadn't any more time to play with TOPS-10. Now I'm
> still struggling to find some spare time for it, but in the mean time...
>
> Here it is:
>
> I do need to rebuild TOPS10.REL because I've modified CLOCK1.MAC in
> order to idle the KLH10 emulator when the TOPS-10 monitor is executing
> the null job loop, as per other messages in this group (CONO 740,1).
>
> At first I thought that a MONGEN and subsequent compile and link
> phases would be enough, then I discovered that I need to entirely
> rebuild TOPS10.REL (Am I right?).
That depends on whether the changes to CLOCK1 affect the code in the
other modules. If all changes are local, including references, you
can replace the old CLOCK1.REL with the new CLOCK1.REL with MAKLIB.
> The Software Installation Guide (MIG
> 704) directs to Appendix B where it is suggested that, for more
> information about building the monitor library file, I should read the
> batch control file COMPIL.CTL.
>
> Unfortunately COMPIL.CTL does NOT contain any comment or explanation.
> I think it is intended for somebody with a previous somewhat deep
> knowledge about such tasks, which I do not have. BTW even the relevant
> manuals are not overly clear about this topic, and many little details
> are left to immagination (or knowledge, as said).
See the line in the control file which uses MAKLIB. That's probably how
TOPS10.REL gets put together. One can also PIP the files together but
they do have to be done in a particular order. Are you sure they called
that thing COMPIL.CTL? It's a stupid choice of filename.
>
> Please, could you tell me, step by step, what I have to do to achieve
> my final goal (idling the KLH10 emulator)? I'm using a quite standard
> installation so common defaults should be fine, but there are anyway
> lots of totally obscure files to customize (BUILDS.MIC, BUILDS.PTH,
> GEN.MIC, ...).
>
> If I recall correctly, the problem was that MONGEN and such would just
> assemble some minor code
Ah, not minor code. S.MAC, F.MAC, COMMON.MAC, COMDEV.MAC and COMMOD.MAC
had to be built for each site. they're the basis of the monitor's database
and hardware configurations.
>and link a new monitor against the existing
> TOPS10.REL without rebuilding everything from scratch, which is indeed what
> I need to accomplish in order to have my modified CLOCK1.MAC considered (?).
>
How many changes did you make? If they fit in PAT.. address space, you can
always make a patch file and apply it to the field image monitor :-).
I don't know what the jerks did for making the 7.04 ship. You might
try looking at 7.03's monitor tape and see if the documentation is the same
as 7.04's. I don't remember putting any MICs on those tapes.
/BAH
jmfbahciv
> ger...@no.spam.mail.com wrote:
I looked my Software Notebook set and found more big chunks of documentation
missing (fucking Perk).
Anyway, the MIG in that set refers to a Chapter 8 (which is missing
in my set). so I can't tell if it would help you. This is
a MIG which includes the October 1981 update. SEe if you can find
order numbers
AA-5056B-TB
AD-5056B-T1
AD-5056B-T2
Building the monitor hasn't really changed other than what's
on first and other required orderings of files.
/BAH
ger...@no.spam.mail.com
> > At first I thought that a MONGEN and subsequent compile and link
> > phases would be enough, then I discovered that I need to entirely
> > rebuild TOPS10.REL (Am I right?).
>
> That depends on whether the changes to CLOCK1 affect the code in the
> other modules. If all changes are local, including references, you
> can replace the old CLOCK1.REL with the new CLOCK1.REL with MAKLIB.
So, are you saying that TOPS10.REL is so-to-speak a "collection" of other
*.REL files? I really didn't understand that! Changes in CLOCK1 are actually
just one line, from "SOJG 6,1" to "CONO 740,1", which appears to be only a
local change, including references.
I wonder how much difficult would be to assemble just CLOCK1...
> See the line in the control file which uses MAKLIB. That's probably how
> TOPS10.REL gets put together. One can also PIP the files together but
> they do have to be done in a particular order. Are you sure they called
> that thing COMPIL.CTL? It's a stupid choice of filename.
Well, I wrote those things more than two years ago, but yes: I think they
called it COMPIL.CTL, and yes: I was already bitten more than once by that
name which is used somewhere else on the TOPS-10 distribution.
> > If I recall correctly, the problem was that MONGEN and such would just
> > assemble some minor code
>
> Ah, not minor code. S.MAC, F.MAC, COMMON.MAC, COMDEV.MAC and COMMOD.MAC
> had to be built for each site. they're the basis of the monitor's database
> and hardware configurations.
Ops, sorry! :-) I didn't fully realize that. Anyway I was somewhat thinking
about quantity more than quality: if we just consider that they are five
files out of dozens, they could be seen as a minor part of the monitor.
> How many changes did you make? If they fit in PAT.. address space, you can
> always make a patch file and apply it to the field image monitor :-).
See above. But maybe patching existing binary code is more difficult that
editing a single .MAC file and reassembling it. Or at least I think that
finding the right binary code to patch would be more complex, wouldn't it?
Thanks for your answer,
G.
Rich Alderson
Given what yo want to accomplish, I'd start out even more simply.
Boot Tops-10 on KLH10. Make a copy of DSKB:SYSTEM.EXE[1,4] as any other name,
such as TOPS10.EXE. Run FILDDT, and change the single location you want to
patch:
.copy tops10.exe=dskb:system.exe[1,4]
.r filddt
File name: tops10.exe/p
<now do your patching>
^Z
.rename [1,4]*.*=tops10.exe
At your next boot, type TOPS10.EXE at the BOOT> prompt, and you;ll be running
your patched monitor. That will let you test your change without all this
schratzing around.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless
jmfbahciv
> On 7 Jun 2010 11:06:32 GMT, jmfbahciv <See....@aol.com> wrote:
>
>> > At first I thought that a MONGEN and subsequent compile and link
>> > phases would be enough, then I discovered that I need to entirely
>> > rebuild TOPS10.REL (Am I right?).
>>
>> That depends on whether the changes to CLOCK1 affect the code in the
>> other modules. If all changes are local, including references, you
>> can replace the old CLOCK1.REL with the new CLOCK1.REL with MAKLIB.
>
> So, are you saying that TOPS10.REL is so-to-speak a "collection" of other
> *.REL files?
Yep. They're just PIPed together.
> I really didn't understand that! Changes in CLOCK1 are actually
> just one line, from "SOJG 6,1" to "CONO 740,1", which appears to be only a
> local change, including references.
I'd simply do what Rich suggested then. Patch the monitor exe file. It's
easy (well, for those of us who have DDT knowledge in our fingers :-)) to
do and you can test your code before messing with rel files.
>
> I wonder how much difficult would be to assemble just CLOCK1...
IIRC (and that's a big IF because I no longer remember the "newish"
parameter files for comm) F+S+CLOCK1
is the line you feed MACRO.
>
>> See the line in the control file which uses MAKLIB. That's probably how
>> TOPS10.REL gets put together. One can also PIP the files together but
>> they do have to be done in a particular order. Are you sure they called
>> that thing COMPIL.CTL? It's a stupid choice of filename.
>
> Well, I wrote those things more than two years ago, but yes: I think they
> called it COMPIL.CTL, and yes: I was already bitten more than once by that
> name which is used somewhere else on the TOPS-10 distribution.
>
Yes, it's a very stupid choice of filename. I'd rename it on my system
to monitr.ctl or gerrmn.ctl. Using the word COMPIL is extremely risky
because it's a magic incantation on TOPS-10 software systems.
>> > If I recall correctly, the problem was that MONGEN and such would just
>> > assemble some minor code
>>
>> Ah, not minor code. S.MAC, F.MAC, COMMON.MAC, COMDEV.MAC and COMMOD.MAC
>> had to be built for each site. they're the basis of the monitor's database
>> and hardware configurations.
>
> Ops, sorry! :-) I didn't fully realize that. Anyway I was somewhat thinking
> about quantity more than quality: if we just consider that they are five
> files out of dozens, they could be seen as a minor part of the monitor.
OH, that kind of minor :-)
>
>> How many changes did you make? If they fit in PAT.. address space, you can
>> always make a patch file and apply it to the field image monitor :-).
>
> See above. But maybe patching existing binary code is more difficult that
> editing a single .MAC file and reassembling it.
Not if you're replacing one instruction.
> Or at least I think that
> finding the right binary code to patch would be more complex, wouldn't it?
>
No. Symbols are already in the monitor's exe file. We used to patch
the monitor while it was running, sometimes with spectacular, unintended
results :-).
/BAH
ger...@no.spam.mail.com
wrote:
> Given what yo want to accomplish, I'd start out even more simply.
>
> Boot Tops-10 on KLH10. Make a copy of DSKB:SYSTEM.EXE[1,4] as any other name,
> such as TOPS10.EXE. Run FILDDT, and change the single location you want to
> patch:
>
> .copy tops10.exe=dskb:system.exe[1,4]
> .r filddt
> File name: tops10.exe/p
> <now do your patching>
> ^Z
> .rename [1,4]*.*=tops10.exe
That's a very interesting approach! :-)
Following the manual, FILDDT does not seem so difficult to use. I've just
played a bit with it and I was able to actually see the code I'm interested
in. But when I try to modify it, FILDDT says that it "can't patch across
sections", so I'm stuck again. Here is the exact output:
NULCOD+1/ SOJG W,P $<?CAN'T PATCH ACROSS SECTIONS
1. What does it mean?
2. It's my understanding that FILDDT would place a jump to a patch area in
place of the old instruction, and then the manual describes various options
and caveats I'm not sure to understand. Given that I have to substitute ONE
instruction with ONE other instruction, is there a way to replace that
instruction in place (sorry for the play on words) without jumps around? Are
all the instructions the same length? In particular, I have to exchange that
"SOJG W,P" with a "CONO 740,1" so if they would be the same length...
3. Again on the same subject: the actual source of that piece of code reads
"SOJG 6,1", so why does FILDDT shows "SOJG W,P"? I would have sworn that 6
and 1 were two constants. If I will ever able to patch that code, shall I
type "CONO 740,1" or I'll have to translate it to some other form, e.g. by
replacing 740 and 1 with some symbolic constant? And which one?
The following two links point to the actual piece of code I need to modify,
and the DDT manual I was reading, respectively:
http://pdp-10.trailing-edge.com/BB-JR93N-BB_1990/01/10,7/mon/clock1.mac.html
http://pdp-10.trailing-edge.com/tops10v704_docc/01/10,7/docupd/ddt.mem.html
Thank you very much for your support! :-)
G.
Rich Alderson
> On 07 Jun 2010 23:04:22 -0400, Rich Alderson <ne...@alderson.users.panix.com>
> wrote:
>> Given what yo want to accomplish, I'd start out even more simply.
>> Boot Tops-10 on KLH10. Make a copy of DSKB:SYSTEM.EXE[1,4] as any other
>> name, such as TOPS10.EXE. Run FILDDT, and change the single location you
>> want to patch:
>> .copy tops10.exe=dskb:system.exe[1,4]
>> .r filddt
>> File name: tops10.exe/p
>> <now do your patching>
>> ^Z
>> .rename [1,4]*.*=tops10.exe
> That's a very interesting approach! :-)
> Following the manual, FILDDT does not seem so difficult to use. I've just
> played a bit with it and I was able to actually see the code I'm interested
> in. But when I try to modify it, FILDDT says that it "can't patch across
> sections", so I'm stuck again. Here is the exact output:
> NULCOD+1/ SOJG W,P $<?CAN'T PATCH ACROSS SECTIONS
> 1. What does it mean?
It means that I wasn't as clear as I should have been, because I never imagined
that someone would be rebuilding a monitor who did not have minimal experience
with DDT. :-( Please accept my apologies for an unwarranted assumption.
You only use the patching construct $< when you need to insert multiple words
(instructions) in place of or in addition to existing code.
To replace a single word with another single word, just type the replacement
word at the desired location and hit one of the closing keystrokes, such as
<CR> or <LF> or <TAB>.
The monitor uses more than one section (512 page unit of addressing); DDT
predates the use of multiple sections in programs, and cannot do the required
cross-section manipulations for a simplistic patch.
Read the Hardware Reference Manual for a description of single- vs. multi-
section programming. Available at http://bitsavers.org/pdf/dec/pdp-10
> 2. It's my understanding that FILDDT would place a jump to a patch area in
> place of the old instruction, and then the manual describes various options
> and caveats I'm not sure to understand. Given that I have to substitute ONE
> instruction with ONE other instruction, is there a way to replace that
> instruction in place (sorry for the play on words) without jumps around? Are
> all the instructions the same length? In particular, I have to exchange that
> "SOJG W,P" with a "CONO 740,1" so if they would be the same length...
All instructions are one word long. Read the HRM.
> 3. Again on the same subject: the actual source of that piece of code reads
> "SOJG 6,1", so why does FILDDT shows "SOJG W,P"? I would have sworn that 6
> and 1 were two constants. If I will ever able to patch that code, shall I
> type "CONO 740,1" or I'll have to translate it to some other form, e.g. by
> replacing 740 and 1 with some symbolic constant? And which one?
W and P are present in the Tops-10 monitor as globally defined symbols for
certain ACs. DDT is simply picking up those symbols from the monitor's symbol
table. You should take a look at the DDT manual to learn about $A (absolute
address typeout mode) and/or = (type out numeric value of word).
> The following two links point to the actual piece of code I need to modify,
> and the DDT manual I was reading, respectively:
> http://pdp-10.trailing-edge.com/BB-JR93N-BB_1990/01/10,7/mon/clock1.mac.html
> http://pdp-10.trailing-edge.com/tops10v704_docc/01/10,7/docupd/ddt.mem.html
> Thank you very much for your support! :-)
You're welcome. Least I can do for an intrepid beginner!
ger...@no.spam.mail.com
wrote:
> It means that I wasn't as clear as I should have been, because I never imagined
> that someone would be rebuilding a monitor who did not have minimal experience
> with DDT. :-( Please accept my apologies for an unwarranted assumption.
Don't blame yourself. Without your suggestion I'd be still here hopelessly
staring at the Monitor Installation Guide. :P
> To replace a single word with another single word, just type the replacement
> word at the desired location and hit one of the closing keystrokes, such as
> <CR> or <LF> or <TAB>.
Wow, it works! Now the KLH10 emulator is idling at just 0.5% host CPU! :)
> Read the Hardware Reference Manual for a description of single- vs. multi-
> section programming. Available at http://bitsavers.org/pdf/dec/pdp-10
I'll do. And I'll ask here about many other software-related questions. Now
that I have a system that does not fry my CPU. :P
> You're welcome. Least I can do for an intrepid beginner!
:-)
G.
Muddlehead
> On 07 Jun 2010 23:04:22 -0400, Rich Alderson <n...@alderson.users.panix.com> wrote:
> > .copy tops10.exe=dskb:system.exe[1,4]
> > .r filddt
> > File name: tops10.exe/p
> > <now do your patching>
> > ^Z
> > .rename [1,4]*.*=tops10.exe
>
> That's a very interesting approach! :-)
Very efficient, too.
Back in the days when it used to take a very long time to rebuild a
Unix kernel, I'd quite often use adb to patch a copy of the system
image to test out little changes such as this. I only once in
desperation had to patch a running kernel - I'm obviously not as brave
as Barb! Fortunately the patch worked, and I was spared the prospect
of spending several hours stitching back together broken file systems.
Kay
jmfbahciv
If he's that new, perhaps he doesn't have a symbol table of the monitor
built with DDT.
I don't remember how to do it.
R FILDDT
SYSTEM.EXE/S
^C
SAVE FSYSTE
Then you RUN FSYSTE for your DDT.
Or am I confusing memories again?
/BAH
>
jmfbahciv
> In article <PM0004888...@ac81d95e.ipt.aol.com>,
> see on a linux system. Some of us have actually written programs
> entirely in that debugger.
I used to edit mixed data mode data files with FILDDT.
>
>>> Or at least I think that
>>> finding the right binary code to patch would be more complex, wouldn't it?
>>>
>>No. Symbols are already in the monitor's exe file. We used to patch
>>the monitor while it was running, sometimes with spectacular, unintended
>>results :-).
>
> Especially patching interrupt handlers while they were servicing 1k+
> interrupts per second was fun.
Yea. You had to type in the patch at PAT.. then open the location
which will contain the JRST PAT.. One had to make sure that the
instruction replaced was also (usually) in location PAT..
/BAH
jmfbahciv
<GRIN> It wasn't bravery; it was necessity. Some times, in a development
environment, you have jump into the deep dodo. :-)
/BAH
jmfbahciv
Yes, you are confused but I'm not anymore. [yes, I'm talking to
myself.] The F[monitor-file-name].EXE was the DDT used to look
at crash dumps. Since we had a new monitor edit every week,
we had to to have a DDT on disk with the symbol table of each monitor
built.
So RS276.EXE (KS monitor, load 276) had FRS276.EXE as the DDT to use
to look at RS276.EXE's crashes. RS276A.EXE had patches applied in
order run (fixes plus our local patches). RS276B.EXE was A plus
some more patches.
/BAH