OS/8 & page 0

[David Gesswein]

Where are the rules on what memory and how to use it under OS/8 documented?
I have some programs that use page 0 and if you do
load file/g
then they run fine
if you load then start or save them then the page 0 values aren't correct.

[Klemens Krause]

David Gesswein wrote:
> Where are the rules on what memory and how to use it under OS/8 documented?
> I have some programs that use page 0 and if you do
> load file/g
> then they run fine

OS/8 memory usage is transparent for user programs. All of the memory inclusive
page 0 is swapped out and reloaded as needed.

> if you load then start or save them then the page 0 values aren't correct.
>

But you have to tell the system which parts of the memory you want to be saved:
.SAVE def file a-b,c,...;s=n

where a-b,c are addresses of areas and locations in core to be saved. So if you
want to preset locations in page 0 you have to give the respective arguments:

.SAVE SYS FOO 0-177,200-377
or
.SAVE SYS FOO 0-377

If I understand the OS/8 manual correct, then omitting the address arguments
don't give an error messages. I then simply uses the core control block from
the last .SV-program. And if this didn't contain the zero page you get funny
results with your newly saved program.
Since most OS/8-programs begin with 0200 and if you used a large program, for
example PAL8 to assemble your own program, the there is a real chance that the
CCB from PAL8 works for your program too, even if you give no address arguments.

Klemens

[Klemens Krause]

Klemens Krause wrote:
...

> OS/8 memory usage is transparent for user programs. All of the memory
> inclusive page 0 is swapped out and reloaded as needed.
>

Sorry, to be exact:

All of memory except the last page of memory field 0
and the last page of memory field 1.

>
> Klemens

[Johnny Billquist]

All correct. However, the CCB would come from ABSLDR, and not PAL8.
But I don't remember exactly what the CCB looks like when you load the
program in. If ABSLDR tries to make it "sane", or it it just hangs
around from ABSLDR itself.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Klemens Krause]

Johnny Billquist wrote:
> On 2012-11-26 11:24, Klemens Krause wrote:

...

>> If I understand the OS/8 manual correct, then omitting the address

...

>
> All correct. However, the CCB would come from ABSLDR, and not PAL8.

...
No. On page 1-38 of the OS/8 handbook it is mentioned:
"A core control block is created for each core-image file is created by the
Linking Loader, ABSLDR, or the SAVE command."

This seems a little bit confusing: The core control block is created by
SAVEing a file from the "hand-given" parameters, or from the CCB in core
when no parameters are given. Or from the Linking Loader.
It is stored in the first block of the .SV-file.
And it is reloaded from the .SV-file if you load a .SV-file from disk.
It would be useless for OS/8 to have the CCB from ABSLDR in core. ABSLDR
first loads the CCB from the first block of the file in core, to determine
the addresses to which the file is to be loaded. There are other
informations in the CCB, for example if it is allowed to restart a program
without reloading it, or if it is outside the area which OS/8 occupies
for it self and which in this case has to be swapped out.
Both features are important if you run the system from slow periperals,
for example DEC-tapes.

Klemens

[Johnny Billquist]

On 2012-11-26 14:24, Klemens Krause wrote:
> Johnny Billquist wrote:
>> On 2012-11-26 11:24, Klemens Krause wrote:
> ...
>>> If I understand the OS/8 manual correct, then omitting the address
> ...
>>
>> All correct. However, the CCB would come from ABSLDR, and not PAL8.
> ...
> No. On page 1-38 of the OS/8 handbook it is mentioned:
> "A core control block is created for each core-image file is created by the
> Linking Loader, ABSLDR, or the SAVE command."

Yes...

> This seems a little bit confusing: The core control block is created by
> SAVEing a file from the "hand-given" parameters, or from the CCB in core
> when no parameters are given. Or from the Linking Loader.
> It is stored in the first block of the .SV-file.
> And it is reloaded from the .SV-file if you load a .SV-file from disk.

Yes...

> It would be useless for OS/8 to have the CCB from ABSLDR in core. ABSLDR
> first loads the CCB from the first block of the file in core, to determine
> the addresses to which the file is to be loaded. There are other
> informations in the CCB, for example if it is allowed to restart a program
> without reloading it, or if it is outside the area which OS/8 occupies
> for it self and which in this case has to be swapped out.
> Both features are important if you run the system from slow periperals,
> for example DEC-tapes.

No.
When you "load" a program, you are not reading in a .SV file. The LOAD
command (which is a CCL command), will run ABSLDR for you, to load the
program into memory.
Thus, ABSLDR is relevant here, while there is no CCB from the .BN file,
which ABSLDR reads in.

The linking loader mentioned is something that SABR uses (which
implicitly also means that FORTRAN II uses). That part is irrelevant
here, unless he actually is using the output from SABR or FORTRAN II, in
which case the file loaded should be a .RL file.

Put everything in another way: RUN and R will load in a .SV file, and
use the CCB from that file. LOAD will load in a .BN file, create a CCB
by some heuristics, and leave it all in memory. LOAD /G will execute
whatever is in memory.
So a LOAD might read in a binary file, which contains stuff in field 0.
The saved image (.SV) might not have page 0 saved, which causes it to fail.
Do a LOAD again, and then save *that*. Possibly with relevant arguments
to make sure that all the relevant sections of memory is saved.

Johnny

[Johnny Billquist]

On 2012-11-26 15:53, Johnny Billquist wrote:
> The linking loader mentioned is something that SABR uses (which
> implicitly also means that FORTRAN II uses). That part is irrelevant
> here, unless he actually is using the output from SABR or FORTRAN II, in
> which case the file loaded should be a .RL file.

La la la... I need to get my head checked... The linking loader is for
FORTRAN IV, not FORTRAN II.
The SABR comment was correct, though.

Johnny

[Klemens Krause]

Johnny Billquist wrote:
> On 2012-11-26 14:24, Klemens Krause wrote:
>> Johnny Billquist wrote:
>>> On 2012-11-26 11:24, Klemens Krause wrote:
>> ...
>>>> If I understand the OS/8 manual correct, then omitting the address
>> ...
>>>
>>> All correct. However, the CCB would come from ABSLDR, and not PAL8.
>> ...
>> No. On page 1-38 of the OS/8 handbook it is mentioned:
>> "A core control block is created for each core-image file is created
>> by the
>> Linking Loader, ABSLDR, or the SAVE command."
>
> Yes...

...

>
> No.
> When you "load" a program, you are not reading in a .SV file. The LOAD
> command (which is a CCL command), will run ABSLDR for you, to load the
> program into memory.
> Thus, ABSLDR is relevant here, while there is no CCB from the .BN file,
> which ABSLDR reads in.
>

>> "A core control block is created for each core-image file is created

Have a look to my posting: A core-image file is everytimes a .SV-file.


If you use ABSLDR with the option /I then it expects a .SV-file, and according
to the OS/8 manual it will extract the CCB from it.
OS/8 without the CCL doesn't need the ABSLDR. The bare Key Board Monitor (KBM)
is able to load and start .SV-files with the GET an R command. And it has to
extract the CCB too. And from that it gets also the Job Staus Word (JSW), to
know how to handle swapping and where to start the program.

...

>
> Put everything in another way: RUN and R will load in a .SV file, and
> use the CCB from that file. LOAD will load in a .BN file, create a CCB
> by some heuristics, and leave it all in memory. LOAD /G will execute
> whatever is in memory.

No. According to the OS/8 manual ABSLDR doesn't construct a CCB if you load
a .BN-file, even it could do that partially. It doesn't know the starting
address of the program, even it will mostly be 0200.
If you use ABSLDR with the /I option it reads a .SV-file and extracts the
CCB and JSW.

> So a LOAD might read in a binary file, which contains stuff in field 0.
> The saved image (.SV) might not have page 0 saved, which causes it to fail.
> Do a LOAD again, and then save *that*. Possibly with relevant arguments
> to make sure that all the relevant sections of memory is saved.

That's what I said. The problem is, that reading a .BN-file with ABSLDR
does NOT construct a matching CCB, even an existing CCB could occasionally
work with the loaded program after SAVEing it as .SV.
So not "Possibly", you have to provide the correct arguments to SAVE to get
reliable working .SVs.



Klemens

[Johnny Billquist]

And the OP used "LOAD /G"...

> OS/8 without the CCL doesn't need the ABSLDR. The bare Key Board Monitor
> (KBM)
> is able to load and start .SV-files with the GET an R command. And it
> has to
> extract the CCB too. And from that it gets also the Job Staus Word
> (JSW), to
> know how to handle swapping and where to start the program.

Yes. I never said that RUN uses CCL. RUN is a KBM command.

However, "LOAD" *is* a CCL command, and the OP noted that using "LOAD
/G" worked, while RUN did not.

Also, OS/8 as such don't ever need ABSLDR, but you need it if you ever
want to compile and run a program (unless it is FORTRAN IV).

You then made comments about the CCB, and how it would be the last run
programs CCB that would be used when you do a save, and that the CCB
from PAL8 would work for most programs.

I pointed out that the CCB from PAL8 is not relevant, but the CCB from
ABSLDR would have been, since it is ABSLDR which is the program in
effect before you do a SAVE. PAL8 creates a .BN file. You then need to
read that .BN file into memory, and for that you need ABSLDR. At no
point will PAL8 be the previously running program.

However, you are also wrong in your assumptions about ABSLDR. It *do*
create a CCB based on what addesses your .BN file uses.

>> Put everything in another way: RUN and R will load in a .SV file, and
>> use the CCB from that file. LOAD will load in a .BN file, create a CCB
>> by some heuristics, and leave it all in memory. LOAD /G will execute
>> whatever is in memory.
>
> No. According to the OS/8 manual ABSLDR doesn't construct a CCB if you load
> a .BN-file, even it could do that partially. It doesn't know the starting
> address of the program, even it will mostly be 0200.

You are wrong. I don't know what you are reading, but check the OS/8
handbook, page 1-108, second sentence from the start of the section
about ABSLDR.

The one thing you did get right is that ABSLDR will just guess that the
start address is 0200, since the start address is not a piece of
information that exists explicitly in a .BN file.

> If you use ABSLDR with the /I option it reads a .SV-file and extracts the
> CCB and JSW.

I actually can't find any support for that claim in the manuals I'm
checking right now, but I think that this is a fair assumption.

>> So a LOAD might read in a binary file, which contains stuff in field
>> 0. The saved image (.SV) might not have page 0 saved, which causes it
>> to fail.
>> Do a LOAD again, and then save *that*. Possibly with relevant
>> arguments to make sure that all the relevant sections of memory is saved.
>
> That's what I said. The problem is, that reading a .BN-file with ABSLDR
> does NOT construct a matching CCB, even an existing CCB could occasionally
> work with the loaded program after SAVEing it as .SV.
> So not "Possibly", you have to provide the correct arguments to SAVE to get
> reliable working .SVs.

No, that is not what you said.
Go back and reread what you wrote.
And yes, ABSLDR will create a correct CCB for you, with the exception if
you have a different starting address.
But as the OP said that "LOAD /G" works, he is obviously using the
standard starting address, so just doing a "LOAD" followed by a "SAVE"
should fix his problem.

At no time will the CCB from PAL8 be relevant in this discussion.

Johnny

[Johnny Billquist]

I should probably point out that I was giving the explanation for why
the OP succeeded running his program when using "LOAD /G", but not run.

And to make the explanation overly clear - he is not running the same
file in the two scenarios.

RUN <filnam> will load and run a .SV file.
LOAD /G <filenam> will load and run a .BN file.

RUN is a KBM command, which reads the .SV file into memory, and then
starts executing it.
LOAD is a CCL command, which will invoke ABSLDR for you. ABSLDR in turn
understands the /G which, which means it will start executing whatever
it just loaded into memory after the loading.

Johnny

[David Gesswein]

Like peope said it should have worked. The real problem seems to be a bad
copy of OS/8. On a different copy this works fine.

.LOAD EDU25R.BN

.SAVE SYS EDU25R ;20200

.R EDU25R

LLEGAL OS/8 DEVICE FOUND
NO BOOTSTRAP POSSIBLE!



EDUSYSTEM 25-F BASIC


NUMBER OF USERS (1 TO 5)?1
IS THE ABOVE CORRECT (Y OR N)?Y

END OF DIALOGUE

READY

On the bad copy of OS/8 the page zero locations are messed up with the
same commands. I also tested with a short program and sometimes the were
ok and sometimes they were messed up.

Without specifying other than the start address it filled in the correct
core locations.
(From my decoder of the .SV file)
Start Address 0200 in field 2. Job status word 0000
Memory blocks used:
20000-24600 27400-27600 10000-15200 00000-07600


These commands also failed on the bad copy of OS/8

.LOAD EDU25R.BN

.START 20200

This worked

.LOAD EDU25R.BIN/G=20200

It appears that if it has to write out and read back in the page contents
it doesn't do it correctly.

Also with my simple program that uses a few zero page locations and has a
halt at 00200 and 20200 and the following commands
.LOAD TEST.BN
.SAVE SYS TEST

I get the following set automatically
Start Address 0200 in field 0. Job status word 2000
Memory blocks used:
20000-20400 00000-00400
It set the job status word also based on the locations used.

[Klemens Krause]

Johnny Billquist wrote:
> On 2012-11-27 14:52, Johnny Billquist wrote:
>> On 2012-11-27 14:13, Klemens Krause wrote:
>>> Johnny Billquist wrote:
>>>> On 2012-11-26 14:24, Klemens Krause wrote:
>>>>> Johnny Billquist wrote:
>>>>>> On 2012-11-26 11:24, Klemens Krause wrote:
>>>>> ...

and so on...

Nitpicking discussions about inaccurate or misunderstandable manuals
do not obligatory helpful to find solutions for some problems.

Yesterday in the evening I had a look into the "ps/8 software support
manual" in which the file structures and also the construction of the
CCB is described in detail.
The CCB stores core origin addresses as multiple of 400 (octal). This
means, that if you have one word in address 0200, then the whole address
range from 0000 to 0377 is saved in the resp. .SV-file.

They also write very clear:

"The Core Control Block for the program at the time it is loaded
intoo core is always saved in words 200 trough 377 of block 37
... on the system device. It is placed ther by the GET and RUN operations
or by the ABSLDR or LOADER programs. The Core Control Block is used when
performing a SAVE without arguments.

NOTE
The R command differs from the RUN command in that
the program's Core Control Block is _not_ written onto the
scratch area when using the R command. In order to SAVE a program
that has been loaded by the R command all of the arguments of the
SAVE command _must_ be explicitly stated."
(All numbers in this citation had a subscripetd 8, to indicate octal
base).

I made a test:
I PAL8ed a short program JB.PA:

*100
SOME
CODE
/
*200
SOME
MORE
CODE
/
*1000
ONEWORD
$

Then I loaded this:
LO JB

and saved it without arguments:
SA DSK:JB

This indeed gave the expected results. A look inside the three blocks
of the resulting JB.SV showed a correct CCB in the first block, generated
by the LOAD-command and a complete dump of addresses 0000 to 0377, as
well as the saved address range 1000 to 1177.

Note: Core Origin in the CCB is a multiple of 400, whereas "number of
pages to load" refers to single pages. So one word in page 0200 lends
to 2 pages to be SAVEd and LOADed, and one word in page 1000 lends to
one page to be SAVEd and LOADed.



Klemens

[Johnny Billquist]

On 2012-11-28 09:53, Klemens Krause wrote:
> Johnny Billquist wrote:
>> On 2012-11-27 14:52, Johnny Billquist wrote:
>>> On 2012-11-27 14:13, Klemens Krause wrote:
>>>> Johnny Billquist wrote:
>>>>> On 2012-11-26 14:24, Klemens Krause wrote:
>>>>>> Johnny Billquist wrote:
>>>>>>> On 2012-11-26 11:24, Klemens Krause wrote:
>>>>>> ...
> and so on...
>
> Nitpicking discussions about inaccurate or misunderstandable manuals
> do not obligatory helpful to find solutions for some problems.

Neither is posting bad information.
It looks better just admitting when you are wrong instead of becoming
aggressive.

Johnny

[Johnny Billquist]

On 2012-11-28 03:51, David Gesswein wrote:
> Like peope said it should have worked. The real problem seems to be a bad
> copy of OS/8. On a different copy this works fine.

Hmmm... Weird stuff. I wonder what the difference is. This is not
something I can obviously point a finger in any direction. ABSLDR is an
obviously potential candidate. But I don't understand how it could mess
up just the page 0 usage in the CCB.

> .LOAD EDU25R.BN
>
> .SAVE SYS EDU25R ;20200
>
> .R EDU25R

So you are saying that this exact sequence produce different .SV files...
I assume (I don't remember if you said so or not) that you are running
on an emulator. I think we can more or less rule out hardware problems
in that case.
Is it the same version of OS/8?

Interesting and weird anyway.

Johnny

[David Gesswein]

In article <k9icks$o1g$1...@Iltempo.Update.UU.SE>,

Yes they are different and yes it is under an emulator. I also tried on
my real PDP-8. It appears that 1024 words starting at 00000 are wrong in
the SV file.

Using the ccl and absldr from the good image doesn't fix it.

>Is it the same version of OS/8?
>

Bad OS/8 - KBM V3Q - CCL V1F
Good OS/8 - KBM V3T - CCL V3E

[Johnny Billquist]

On 2012-12-11 03:10, David Gesswein wrote:
> In article <k9icks$o1g$1...@Iltempo.Update.UU.SE>,
> Johnny Billquist <b...@softjar.se> wrote:
>> On 2012-11-28 03:51, David Gesswein wrote:
>>> Like peope said it should have worked. The real problem seems to be a bad
>>> copy of OS/8. On a different copy this works fine.
>>
>> Hmmm... Weird stuff. I wonder what the difference is. This is not
>> something I can obviously point a finger in any direction. ABSLDR is an
>> obviously potential candidate. But I don't understand how it could mess
>> up just the page 0 usage in the CCB.
>>
>>> .LOAD EDU25R.BN
>>>
>>> .SAVE SYS EDU25R ;20200
>>>
>>> .R EDU25R
>>
>> So you are saying that this exact sequence produce different .SV files...
>> I assume (I don't remember if you said so or not) that you are running
>> on an emulator. I think we can more or less rule out hardware problems
>> in that case.
>>
> Yes they are different and yes it is under an emulator. I also tried on
> my real PDP-8. It appears that 1024 words starting at 00000 are wrong in
> the SV file.

Now, hang on. Are you saying that all 1024 words starting from 0000 are
wrong? That sounds very suspicious. I wonder if your ABSLDR might
actually have a bad JSW, since there is one bit in there which tells if
0-2000 in field 0 are used or not. Trying to reason through things here,
but if ABSLDR have said that 00000-02000 do not need to be saved, I
wonder if it gets overwritten by the KBM before the save command is
executed.
On the other hand, I would think that when ABSLDR exits, the JSW should
already have been set up for the loaded program, which means that it
should be swapped out, as needed. But then again, I'm not sure if ABSLDR
actually writes to the disk if the program specifies data in addresses
00000-02000, since it otherwise might overwrite itself, in which case
ABSLDR needs to fake OS/8 to not save the memory contents on exit to the
KBM, since the memory has already been "saved".

Oh well. Needs to look at the sources of ABSLDR for that one, I guess.
But it definitely seems as you have a bug, or something wrong in your
bad system. But it might just be a combination of small obscure things
set wrong, since I can't imagine a plain simple bug would cause this
exact effect.

But I'm just guessing a lot here.

> Using the ccl and absldr from the good image doesn't fix it.

Well, CCL is not really a part of this, so that was to be expected.
However, ABSLDR definitely is. It might be that ABSLDR needs to match
the OS version, in which case having the same ABSLDR would not solve the
problem. But once more, I'm just guessing. But it seems that (as far as
I can guess) ABSLDR has some rather intimate knowledge of the system,
and is not a program that can be fooled around with much without
breaking things.

>> Is it the same version of OS/8?
>>
> Bad OS/8 - KBM V3Q - CCL V1F
> Good OS/8 - KBM V3T - CCL V3E

Cool. So there is definitely a difference in here.

[cjl]

Got a few milliseconds:

1) Bad info all around. If you save a location in 07400-07577, that does NOT save anything from 07600-07777. Each page is on its own. Your confusion is that OS/8 handlers have to load from bounded double-pages, but you cannot just load a second page. Thus, it matters which page you specify as to exactly what happens.

2) R program name is the only execute form without a dev construction. RUn dev: program name always needs one.

3) You CANNOT just switch ABSLDR.SV from one OS/8 version to another; guaranteed fail.

The reason is bad maintenance, yet another of the thousands of problems I have with OS/8. Sloppy code in the OS/8 keyboard monitor was allowed to be written by clueless newbies who used page zero literals. ABSLDR is created from the same assembly and shares the exact same definition of that particular page zero code set. Since literal generation is a moving target, the separate executable from one version has no chance to work with one from another system build, etc.

I have little time to shepard this group these days. However, on a need-to-know basis, various people who post here regularly have volunteered to get to me issues that rise above the revisionism, guesswork, etc. to get a proper answer on a worthy question. I leave it to their good judgement to get me into any particular loop.

Rumors of my untimely death are highly exaggerated. I have a health problem which is totally under control, but it does give me a few limitations, none of which effect my PDP-8 skills in any way. In fact, I have been "sighted" in various haunts of some of the readership here; I give any of them permission to confirm when and where I was, etc.

Otherwise, I am quite busy writing and designing code, and new data structures for a PDP-8 project a few know about, and not ready for general announcement. I will say this, unlike certain software systems some blindly use and assume is authoritative instead of merely defacto, this will be effective and extremely well designed. No guarantees on any form of time-table as "I have a life" which quite often interferes with scheduling things. All of us face the "gotta do" instead of the "wanna do" sometimes; let's just say for the present the latter is more in control that I would be happy with, etc.

I will be releasing some specific documents when I get them to 100%; it is irritating that some are as much as 98% done, but not 100%, but yet I must hold them back until that elusive additional 2% gets its proper place in my existence.

cjl [personal creator of this group way back when]