PDP-8 Programming Challenges

[Vincent Slyngstad]

I was inspired by Warren's post at 

https://groups.google.com/forum/#!topic/pidp-8/OQ0LzyQ94QI

I often enjoy exercises like these, both for the challenge of thinking 

about the problem, and for the challenge of how to tackle them in 

the environment of a PDP-8.  Toward that end, I have attached my 

takes on the problem.

One just codes the problem for the PDP-8 in what seemed like the 

most efficient way -- bearing in mind that space efficiency is usually 

much more important than time for on PDP-8.  The "f" variant 

on the other hand, recognizes that even for the PDP-8 the problem 

isn't really space constrained, and so tries to be a little more clever 

and a little faster.

I've tried to keep both "Family of 8", and avoided things that would 

not necessarily have been widely available, like an EAE, or even 

that it was a good idea to blindly leap with the assumption of an OS 

in the last page of memory.  (The machines I learned on were 4K, 

no EAE, and no mass storage unless paper tape counts.)

The hardest part (which I knew to expect) was getting the decimal 

output routine to work.

These are fun, even the classic ones like the efficient implementation 

of XOR (relatively easy), or the harder "set all of memory to zero, 

including the space occupied by your program".

    Vince

[clasystems]

Just a few comments on some of these implementations.

Some of these programs will not work.  This is only focusing on the console output aspect of things.

1) The "safe" method is also the one that wastes the most time.  Since most PDP-8 programming is done with interrupts off, what is wrong here is not all that apparent.  The real problem is that by nature, the serial interface goes busy when you send a character out.  Waiting for the flag means there is no overlap with processing.  Some programs of this caliber when run even on an actual teletype, you can hear the jitter in the output due to failure to keep up with the limitations of the teletype!

By reorganizing the output routine to output and NOT wait, you are then overlapping processing and printout.  Instead of waiting the guaranteed worst case it takes for the character to actually print and THEN start additional process, you only have to wait for the REMNANT of that time, and, depending on processing in the rest of the program, the flag could already be up when you get there!

Thus, this is the issue of using the form

TSF
JMP .-1
TLS

as opposed to

TLS
TSF
JMP .-1

The two are not interchangeable and at least one of these programs fell into the trap of ASSUMING they are.

The second method is the guaranteed time-inefficient one, but it [nearly] always works.  [More later on the "nearly" part].

The first ONLY works if it is properly initialized OR is loaded by an operating system that handles that before hand.

The reason is there is the requirement of "priming the pump" regarding the output.  It must be bullet-proof and have a proper right to wait for the flag to come up, only if it is a GIVEN the flag WILL come up.

OS/8 is the wild,wild west.  There is no discipline and you cannot have any expectations.  Thus, most code written [by head count, not by cleverness; my Kermit-12 is clever] does the safe method.  And that will work nearly all the time, and always the poor performing way.

P?S/8 enforces a discipline.  You can be GUARANTEED the flag is already raised or in the process of raising.  Rest assured, it will come up; the pump was primed for you.  Thus, if P/S/8 loads your program, you don't have to include that function, unless you want to stop the machine and start it manually.

P?S/8 is strictly Family of 8, so you cannot depend on the extension instruction of the KL8E and up.  Force the flag to set.  And even that has the problem of the "nearly always" mentioned above; it may simply be the wrong thing to do and the output might garble.

On fast devices, it is totally reasonable that the program is loaded into memory and started in much less than 1/10th of a second.  Thus, a reasonable expectation is the program has started and the flag MIGHT be coming up [or maybe not if the O/S is unreliable, such as OS/8 where there is no enforced method, thus it's pot luck].

And that's why if you use OS/8 and ASSUME you can blindly just start with a TLS without waiting, you will sometimes splat the terminal.  You are depending on the erratic notion that the flag is already done.  [Note:  If it actually was clear, you don't actually have to clear it again, and using the safe method, it's OK if it is already still up, but it must be true that there is currently no character print going on.  But strictly speaking this is not the case in OS/8.  You MIGHT find the clever mode works, but you cannot depend on it.  You MIGHT be able to use the safe mode but you cannot depend on that either.  Most people who haven't studied this and only use OS/8 of course use the safe mode, and they didn't see it on their particular system because the device they used was SLOW enough that as a practical matter, enough time had passed, especially if internal program housekeeping before the output commences helps to waste a few more milliseconds.  And then in later configurations, they used faster terminals that made it less likely to happen [but not guaranteed] and that the potential splat didn't actually print anything [fortunately, at least on their machine, but in general, it won't work].

Earlier I mentioned that Kermit-12 is clever, even though it is an OS/8 program.  Here's why:

Kermit-12 works like nay P?S/8 program that allows for MANUAL restart which clears the flag.  It assumes NOTHING and does a worst-case fixup.  The program starts with an initialization section that times out the flag.  Rash assumptions are merely that for actual machines, the timeout period is hopefully at most just over a second, or less, waiting for a flag that may not come up. Software timing is used and why the variability and intentional overkill.  We give the flag all the chances it needs to either come up or not.  Then we output a <NUL> character without waiting; the pump is now primed.

Once this is done, because all the output of the program is of the overlap type, the overlap method is always used consistently.  It will always work and there never will be a garble.  Kermit-12 is NOT manually restartable; most O/S-loaded programs are not meant for manual restart unless that's part of the design.  [Which really means this is a paper-tape environment program such as FOCAL, 1969 unmodified.]

P?S/8 enforces the discipline in more ways than this:

1) The output of ALL conforming programs is regulated by the use of Control-S/Control-Q protocol.  Unlike OS/8, there is no such thing as a too-fast terminal. Many users of the era-specific configurations such as when they bought an actual VT-100 were quite disappointed to find the incredible tons of splat garbage that spews out of PAL8 because ALL OS/8 programs [other than Kermit-12 to my knowledge) fail to support the protocol.  Their band-aid was to slow down the terminal by compromise.  Slower than they expected gets a handle on the splat problem.  slowing the VT100 down to 1200 baud and it all works fine - but did you pay all that money for that slow a terminal?

By then, all the new terminals had a PAUSE key which was literally a Control-S/Control-Q flip-flopper that outputted the characters alternately.  And of course OS/8 couldn't support it.  [P?S/8 handles it find.]

2) P?S/8 has a protocol to work with the incompatible DECmate output.  No OS/8 variant actually works on the DECmates.  It's just a matter of how much is broken.  OS/78 V4 is a good example.  It equally fails on the 8/E as it does on the DECmates.  Program features such as control-C checking in handlers is just plain removed.  If the rest of the program doesn't know how to abort, you are SOL.  [And that also means no checking for family of -8.  the worst of all worlds.  A broken subset of OS/8 that only has what was not removed equally working on an 8/E or a DECmate.  It foes downhill from there, and on OS/278 V2 there are scary bugs such as the <LF> command in ODT doesn't work!  It makes the machine hang!  You have to power down and power up the machine to get out of this; and of course the <LF> command is one of the 3-4 mostly used commands of ODT.]

P?S/8 works completely because it was modified when the DECmate I  came out to support the notion of a software abort.  Programs that were guarnateed to be family of 8 ONLY don't require the additional conformance code.  But anything that MIGHT run anywhere must include the code to check for Control-C and NOT assume that KSF will skip again on Control-C [because the KRS instruction doesn't work].  Instead, if a program wants to indicate this is an abortive exit [as opposed to a clean normal exit] the instruction ISZ I (7611) is performed just before exit to 07600.  The keyboard monitor checks both ways when it is reloaded, etc.  You will always get the ^C message and BATCH will always abort correctly, etc.  [All of that doesn't work in OS/78 V4.  You shouldn't use OS/78 V4 programs with SIMH because of the otherwise needless excision of code that works perfectly fine on SIMH including the PiDP-8.]

Thus, P?S/8 is strictly Family of 8 AND all DECmates as well.

And of course, OS/8 can never do this; simply no extra bits to fix anything in their 256 word kernel!  [If there had been any, the date problem wouldn't have existed.  that failed in 1978; DECmates would not come for another two more years.]

Software written for a fully compatible machine ALMOST works on a machine that is only ALMOST compatible.

cjl

ps:  That set the AC to 3 instruction is NOT family of -8.  Glad it was removed.

[Vincent Slyngstad]

On Thursday, October 5, 2017 at 1:07:41 AM UTC-7, clasystems wrote:

Just a few comments on some of these implementations.

Some of these programs will not work.  This is only focusing on the console output aspect of things.

The two I posted should work, as well as can be expected. 

Thus, this is the issue of using the form

TSF
JMP .-1
TLS

as opposed to

TLS
TSF
JMP .-1

TLDR: This is a bit of a red herring, since all stand-alone programs must be of the latter form, even if the 

code is re-ordered to look like the former and to allow overlapped processing.

Here's the long version:

It is a fundamental botch on essentially all of the serial interfaces across the PDP-8 line, that the serial 

line initializes to the "not ready" state, which cannot generally be told from the "busy" state.  Normally 

the ready flag for serial output should be set if the device is finished shifting out the character, but the 

initial state is ready to begin shifting, but the flag is clear.  This state follows the use of the "START" 

key, and also after CAF, on machines that support CAF.  It can also be re-created by waiting for the 

output ready flag to come up, then clearing it with TCF.  (Programs that use interrupts want to 

do this to clear the interrupt request.)

Since this is the case, the initial TLS must always be done without waiting for the TSF flag.  This 

could be done by the operating system, if it were known that there was an operating system, and 

all output was known to use operating system services.  That might be true in P?S/8, but is *not* 

true anywhere else in the PDP-8 universe.

The typical practice, therefore, is to include a TLS near the beginning of one's program, usually 

outputting a NUL character.  As Charles points out, this "primes the pump" by setting the output 

ready flag when the NUL has finished shifting out the serial line.  (The console interface is either 

a serial line or an emulation of one.)  This allows the later use of code like

    TSF
    JMP .-1
    TLS

to wait for the flag, then initiate the next character.  It also allows processing to overlap the 

character in transit.

It also means a NUL was output at the beginning, quite likely "splatting" whatever output 

character the operating system (if there was one) was sending, and introducing a 

delay of one character time before meaningful output.

The programs I posted skip the NUL, and don't bother to overlap computation with 

output.  Like all other programs written to work stand-alone, they also risk corrupting 

any character that was previously in transit.  The OS should make a sensible effort to 

complete it's output before transferring control to my program.  That correctness would 

also have an efficiency cost, and as Charles says, is a dicey assumption for OS/8.

In a perfect world, all programs would also ensure output complete before returning 

to the operating system, or would simply use OS services for their I/O.  That ship 

has sailed, however, for these legacy systems.

I'm not much of a pedant when it comes to whether the output overlap justifies the 

initial output character.  Nor about the details of the I/O hand-off with a host OS 

that may or may not be there, or may or may not work "right".

I'd just love to see more folks try to write some PDP-8 code :-).

    Vince

[CLASystems]

On Thu, Oct 5, 2017 at 10:33 AM, Vincent Slyngstad
<v.sly...@frontier.com> wrote:
>
>
> On Thursday, October 5, 2017 at 1:07:41 AM UTC-7, clasystems wrote:
>>
>> Just a few comments on some of these implementations.
>>
>> Some of these programs will not work. This is only focusing on the
>> console output aspect of things.
>
>
> The two I posted should work, as well as can be expected.
>
>> Thus, this is the issue of using the form
>>
>> TSF
>> JMP .-1
>> TLS
>>
>> as opposed to
>>
>> TLS
>> TSF
>> JMP .-1
>
>
> TLDR:

Neither of us are particularly short, as this does take more words to
explain to a beginner regardless :-)

This is a bit of a red herring, since all stand-alone programs must be
> of the latter form, even if the
> code is re-ordered to look like the former and to allow overlapped
> processing.

I fully explained what each has to do or not do. Full disclosure,
thus no herrings of any color or smell.

>
> Here's the long version:
>
> It is a fundamental botch on essentially all of the serial interfaces across
> the PDP-8 line

That's decades long on hindsight. It is what it is.

, that the serial
> line initializes to the "not ready" state, which cannot generally be told
> from the "busy" state. Normally
> the ready flag for serial output should be set if the device is finished
> shifting out the character, but the
> initial state is ready to begin shifting, but the flag is clear. This state
> follows the use of the "START"
> key, and also after CAF, on machines that support CAF. It can also be
> re-created by waiting for the
> output ready flag to come up, then clearing it with TCF. (Programs that use
> interrupts want to
> do this to clear the interrupt request.)

Correct, and that is a don't care for non-interrupt programming.

>
> Since this is the case, the initial TLS must always be done without waiting
> for the TSF flag. This
> could be done by the operating system, if it were known that there was an
> operating system, and
> all output was known to use operating system services. That might be true
> in P?S/8, but is *not*
> true anywhere else in the PDP-8 universe.

Correct. P?S/8 is the only non-interrupt system that gets it right.
But OS/8 COULD have been done correctly [unfortunately, it wasn't,
thus most programs [even OS/8 system programs] just did it pot luck
and mostly the "safe" way [which is not necessarily safe].

>
> The typical practice, therefore, is to include a TLS near the beginning of
> one's program, usually
> outputting a NUL character. As Charles points out, this "primes the pump"
> by setting the output
> ready flag when the NUL has finished shifting out the serial line. (The
> console interface is either
> a serial line or an emulation of one.) This allows the later use of code
> like
> TSF
> JMP .-1
> TLS
> to wait for the flag, then initiate the next character. It also allows
> processing to overlap the
> character in transit.

Exactly. One of the examples [apparently not yours] failed to prime
the pump thus cannot work in general.

>
> It also means a NUL was output at the beginning, quite likely "splatting"
> whatever output
> character the operating system (if there was one) was sending, and
> introducing a
> delay of one character time before meaningful output.

Exactly, OS/8 is typical. You can't know and the only truly safe way
is to wait for a predictable reasonable character time. However, if
you have gone through the trouble, it then makes no sense to have
"wasted" the effort to not overlap, etc.

>
> The programs I posted skip the NUL, and don't bother to overlap computation
> with
> output. Like all other programs written to work stand-alone, they also risk
> corrupting
> any character that was previously in transit. The OS should make a sensible
> effort to
> complete it's output before transferring control to my program. That
> correctness would
> also have an efficiency cost, and as Charles says, is a dicey assumption for
> OS/8.

I'll go one further with OS/8. The prime the pump method might not
work in OS/8 when the program exits, since it is likely one of the
next pieces of code that come in use the "safe" method, so unless you
also wait at the end, you might make OS/8 itself splat.

Again, since P?S/8 has a hard and fast convention, there is never a
problem. This is the most desirable way to go about it. Your program
and the operating system are in a mutual cooperation and you have the
least amount of housekeeping to do. [I've had a lot of practice
ranting against OS/8, this is merely the least problem it has because
it COULD be solved just by undoing sloppiness. Most of the other
problems are flawed fundamental design born of management interference
[for those who know how it hatched].

>
> In a perfect world, all programs would also ensure output complete before
> returning
> to the operating system, or would simply use OS services for their I/O.
> That ship
> has sailed, however, for these legacy systems.

P?S/8 predates OS/8, and is still "sailing". Remember, the PDP-8
programming staff encouraged them to take on P/S/8, which when fully
complete, thoroughly and completely obsoletes OS/8 in every sense of
the word. Had the managers been more than profoundly ignorant fools,
all of us [most of us were friends from college] would have made it
happen; all of us started on Richard Lary's excellent system The R-L
Monitor System and were thoroughly familiar with how it worked. P/S/8
is just the more "polished " version but mostly done by me alone.
Imagine if instead we were all working on it together back in the day?

>
> I'm not much of a pedant when it comes to whether the output overlap
> justifies the
> initial output character. Nor about the details of the I/O hand-off with a
> host OS
> that may or may not be there, or may or may not work "right".

I think the only ship that has long sailed is the notion of the might
not be there part. P?S/8 can run on a 4K family of 8 machine with a
storage device interface. With some work, the Kyle Owen serialdisk
handler and server [I heavily modified the latest version to be family
of 8 for OS/8] can make it work on just a CPU and an extra serial
port. There is virtually no reason today to be playing with
paper-tape. For us, that was true in 1967.

>
> I'd just love to see more folks try to write some PDP-8 code :-).

We all agree with that.

I might add, to a beginner, P?S/8 is far more easy to start learning
on, less things to really screw up,and you don't have to learn a whole
lot of htings just to write your first program. [Not to mention that
it lacks the requirement of all we discussed above].

P?S/8 is generally configured to run on TC08 DECtape and can be quite
inter-cooperative with OS/8 in the same SIMH session. This makes it
erasier to have a more complete environment without having to have the
notion of yet another choice of something different from the
standpoint of intrusion into the PiDP-8 environment. It all comes
down to merely the initial boot choice with all other SIMH parameters
the same. In theory, P/S/8 can also run on RK8E/RK05 [and in at least
one configuration better handling of the storage than OS/8] and RX01
and TD8E. However, the first is complicated by "intruding" on the
OS/8 normal environment, and the latter two are just too limiting.
[And you wouldn't want OS/8 booting on them either in SIMH other than
to make a smaller configuration to do less with].

cjl

>
> Vince
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "PiDP-8" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/pidp-8/h7AKaN-hvEI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> pidp-8+un...@googlegroups.com.
> To post to this group, send email to pid...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-8/1ceffbb1-1d23-4395-95e9-a1ede068290c%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--
"In the future, OS/2 will be on everyone's desktop"

Bill Gates, 1992<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>

[CLASystems]

I've attached a logged session I ran about 20 minutes ago.

It shows how you can create a "HELLO WORLD" program in P?S/8 in about
three minutes or less from scratch.

This is an actual log fragment from a SIMH session [with a couple of
minor edits].

I pressed Control-E after the last command prompt after the program
output. Then I exited the SIMH session.

The commands used are a compatible subset of COS-300/310
[documentation is available on-line].



HISTORY of PDP-8 keyboard monitors.

1) The R-L Monitor came first. It was later known as MS/8.

2) DIBOL-8 was the R-L Monitor hacked up to have the same commands
that would be in the next release [COS-300). This was done by Hank
Maurer, who wrote the DIBOL compiler. [Note: DEC management was not
only ignorant of R-L at the conceptual [or any other] level because
they were just total jackasses, but also they never actually knew they
SOLD it!]

3) The earliest P?S/8 was command-identical to R-L This all happened
several years before there was PS/8 [later OS/8].

4) When we found out about DIBOL-8, we changed the commands to be
compatible with COS. [essentially mimicking what Hank had done].

5) DIBOL-8 is a hacked-up keyboard monitor on top of the R-L Monitor.
P?S/8 is command-compatible on a totally rewritten 4K system largely
based on the concepts in the R-L Monitor, but with 100% new code..
COS-300/310 is a DIBOL-8-compatible keyboard monitor on top of an OS/8
system innards

Any suggestion of "incest" is purely coincidental :-)

cjl
.

> lot of things just to write your first program. [Not to mention that

> it lacks the requirement of all we discussed above].
>
> P?S/8 is generally configured to run on TC08 DECtape and can be quite
> inter-cooperative with OS/8 in the same SIMH session. This makes it

> easier to have a more complete environment without having to have the

[Vincent Slyngstad]

On Thursday, October 5, 2017 at 9:50:52 AM UTC-7, clasystems wrote:

On Thu, Oct 5, 2017 at 10:33 AM, Vincent Slyngstad

> That ship
> has sailed, however, for these legacy systems.

P?S/8 predates OS/8, and is still "sailing".

I don't think of  P?S/8 as legacy code.  In part because it is still being 

developed/maintained, and in part because I have never seen it.  It 

has been "coming soon" for pretty much all of the 4+ decades I've 

been doing PDP-8 stuff.

I think the only ship that has long sailed is the notion of the might
not be there part.  P?S/8 can run on a 4K family of 8 machine with a
storage device interface.  With some work, the Kyle Owen serialdisk
handler and server [I heavily modified the latest version to be family
of 8 for OS/8] can make it work on just a CPU and an extra serial
port.  There is virtually no reason today to be playing with
paper-tape.  For us, that was true in 1967.

That's a valid point.  Though I also think it slightly distorts our historical 

perspective on the PDP-8, since for most of it's lifespan, mass storage 

(and the operating system that goes with it) has been very much a 

luxury item.  (Likewise extended memory; hence the push to keep 

P?S/8 runable in 4K.)

    Vince

[CLASystems]

On Thu, Oct 5, 2017 at 2:17 PM, Vincent Slyngstad
<v.sly...@frontier.com> wrote:
>
>
> On Thursday, October 5, 2017 at 9:50:52 AM UTC-7, clasystems wrote:
>>
>> On Thu, Oct 5, 2017 at 10:33 AM, Vincent Slyngstad
>> > That ship
>> > has sailed, however, for these legacy systems.
>>
>> P?S/8 predates OS/8, and is still "sailing".
>
>
> I don't think of P?S/8 as legacy code. In part because it is still being
> developed/maintained, and in part because I have never seen it. It
> has been "coming soon" for pretty much all of the 4+ decades I've
> been doing PDP-8 stuff.

I can't help it if so many people were so foolhardly they refused to
even look at it because of their base prejudices and expectations of
it being "difficult" merely because to them OS/8 was so.

Your own statement proves you are wrong. You know it as being nearly
as old as OS/8 [and in fact it is older]. It's not my fault two
different total morons at DEC rejected it over all technical expertise
present at the time. [which is way we are hear and DEC isn't].

What is being developed is delayed but had always been planned. And
that's the part that makes OS/8 into the proper joke it always was.
The part that you've now had a glimpse into was completely functional
BEFORE they rejected it 40 years ago for no sound technical [or
business] reason. What you are saying is just implying that you
aren't open to it, and that's the typical response I got from others
as far back as 1972. Which applies more, I cannot say: Pearls before
swine, or you can lead a horse to water...

In the early days, I was under contract with Intersil to not release
it. These days are long over. If I had requested they allow me to
back then, I suspect they would have. But few would meet me half way.
And I will name names right now. The main force in "reigning in" the
user community was Bob Hassinger, a total OS/8 bigot. Behind his
back, my friends would laugh at him when he came to the mill acting
like a privileged character because he lived in Framingham, and had a
job where he didn't have to report in much. He was "played" quite a
few times with elaborate ridicule plays announcing BS that never
happened, etc.

I fail to understand the notion of something being maintained doesn't
make it legacy in any sense of the word. Is it "better" that by bad
design OS/8 craps out totally on the date handling in 1977, and a faux
kludge that dies in 2001, while from the getgo P?S/8 could handle the
date until 2099?

>
>> I think the only ship that has long sailed is the notion of the might
>> not be there part. P?S/8 can run on a 4K family of 8 machine with a
>> storage device interface. With some work, the Kyle Owen serialdisk
>> handler and server [I heavily modified the latest version to be family
>> of 8 for OS/8] can make it work on just a CPU and an extra serial
>> port. There is virtually no reason today to be playing with
>> paper-tape. For us, that was true in 1967.
>
>
> That's a valid point. Though I also think it slightly distorts our
> historical
> perspective on the PDP-8, since for most of it's lifespan, mass storage
> (and the operating system that goes with it) has been very much a
> luxury item. (Likewise extended memory; hence the push to keep
> P?S/8 runable in 4K.)
>
> Vince
>

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "PiDP-8" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/pidp-8/h7AKaN-hvEI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> pidp-8+un...@googlegroups.com.
> To post to this group, send email to pid...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-8/91330673-67fd-4a75-9580-773a7598d20b%40googlegroups.com.

[CLASystems]

I find your remark totally bizarre. The PDP-8 was sans mass storage
for about 1.5 years; then DECtape camed out. Few if any machines past
that LACKED mass storage. Go check the sales figures; I think Doug
Jones has all of the statistics.

40 years ago few people failed to have contact with an operating
system. I can't help if if your perspective was from an atypical
economy system that was not mainstream to PDP-8 sales for years by
then.

There was a small insincere effort when the 8/A came out to have an
"embedded system" kind of an 8/A. It was not successful while
virtually ALL other systems could run some form of operating system.
By then few people even knew what PAL III even was, much less used it!

cjl

[William Cattey]

Whenever I wrote TTY output code, I would organize my output to have once-only code that would take the first character I was sending and feed it to TLS.

I'd never seen code that would do pre-initialization with a NUL. Interesting approach, but

my personal taste would be to avoid such a thing.

I didn't, until this thread, take extra time to think about how the hardware must have been implemented to require this. I just sort of accepted it.

I also never thought about what the ramifications would be in switching between TTY I/O provided by the OS and that provided in-line from a hard-coded program.  Although.. Truth be told, I pretty much avoided using OS/8 for TTY I/O because I felt more comfortable doing my own in-line organizing.

I never spent any time trying to write interrupt driven code, leaving that for those with far pointier hats than I.

[Gordon Henderson]

On Thu, 5 Oct 2017, William Cattey wrote:

> Whenever I wrote TTY output code, I would organize my output to have
> once-only code that would take the first character I was sending and feed
> it to TLS.
>
> I'd never seen code that would do pre-initialization with a NUL.
> Interesting approach, but
> my personal taste would be to avoid such a thing.

Doug Jones pages have been a good source of knowledge for me and here:

http://homepage.divms.uiowa.edu/~jones/pdp8/man/tty.html

he makes mention of it - at the bottom of the page he says:

One problem with the design of the TTY interface is that the
teleprinter flag, like all device flags, is cleared on reset and
powerup, but for many purposes, it would be better to have this flag
set, indicating that, at startup time, the teleprinter buffer register
is ready to receive one character of output. The traditional startup
code accomplishes this by outputting a null:

/ initialize the teletype for output
CLA
TLS / output null

The PDP-8/E seems to not require it though, but there must have been
enough pre E machines out there for people to not use the extra
instructions, I suspect.

Cheers,

Gordon

[CLASystems]

On Thu, Oct 5, 2017 at 5:17 PM, Gordon Henderson
<gordon...@drogon.net> wrote:
> On Thu, 5 Oct 2017, William Cattey wrote:
>
>> Whenever I wrote TTY output code, I would organize my output to have
>> once-only code that would take the first character I was sending and feed
>> it to TLS.

That is not always easy to do. Especially in P?S/8 where you also
have to initialize in case it's a DECmate and/or dealing with
Control-S/Control-Q.



Also, you can't just do that in OS/8. Depending on what came before,
the flag may be in the process of coming up while a character is being
sent out and printed.

But since P?S/8 waits to make sure the flag might come up, it is in a
better position to do what you are doing. By the time the program is
initialized, you can do that with impunity.

However, I will take a look at it for the next clean release. Enough
is changing here and there it be doable. The most crucially tight
code is getting some free space!

One of the problems with a modular operating system is that the
modules can get screwed up, Consider that the Logical Console Overlay
is enabled on a DECtape-based system configured for the VT8E and you
forget to disable it and then take the DECtape to another system that
lacks the VT8E hardware! [Major OOPS. I had to know where in memory
to get around it manually. Fortunately I got away with it most of the
time, etc.

So, a new feature will be implemented. If you press a special escape
character on the real 03 keyboard while the system is booting, the
normal sequence will be broken and the new low-level monitor will be
brought in. That can force off any of the modules [P?S/8 SHELL or the
Logical Console Overlay] so the system can clean-boot. Then any of the
options can be reconfigured to work with the hardware at hand, etc.

I may have yet another problem with the PiDP-8 SIMH which is already a
minor PITA now. Unlike the standard SIMH, there is no way to get
Control-D to the PDP-8. [Presumably this could be fixed.] This is
not thought-through design. You have to assume that SIMH will not
easily crash and SIMH already reserves a character now [defaults to
Control-E] Just about every other character has some pre-existing
software implication including Control-D is one of the P?S/8 ED{it}
commands special features.[it is patterned after the FOCAL, 1969
MOdify command.]

My point is here that the use of the escape character must be
something like Control-D also because this code has to be super-tight.
Once implemented, it means other things that were in the other code
are moved to something that now only conditionally comes in, thus the
norm is not changed, etc. [And of course, none of this is a
consideration on the PEPS package using the original SIMH].

>>
>> I'd never seen code that would do pre-initialization with a NUL.
>> Interesting approach, but
>> my personal taste would be to avoid such a thing.

Understand. It's been in use now for about 48 years now.

>
>
> Doug Jones pages have been a good source of knowledge for me and here:
>
> http://homepage.divms.uiowa.edu/~jones/pdp8/man/tty.html
>
> he makes mention of it - at the bottom of the page he says:
>
> One problem with the design of the TTY interface is that the
> teleprinter flag, like all device flags, is cleared on reset and
> powerup, but for many purposes, it would be better to have this flag
> set, indicating that, at startup time, the teleprinter buffer register
> is ready to receive one character of output. The traditional startup
> code accomplishes this by outputting a null:
>
> / initialize the teletype for output
> CLA
> TLS / output null

Full disclosure: I explained this to Doug over 30 years ago when he
incorporated much of my ideas into his WHAT-IS-A-PDP-8 documents. He
fully understands the interface and I also explained the DECmate
"almost compatible" problem to him, but he never personally used one
[I perfectly understand why].

>
> The PDP-8/E seems to not require it though, but there must have been enough
> pre E machines out there for people to not use the extra instructions, I
> suspect.

The KL8 interfaces that came in with the 8/E have a SET FLAG
instruction. IOT0 or TFL. If you are sure you are on an 8/E or VT78
you can just set the flag and you are done with initializing it. But
then you are not Family of 8 compatible! OS/8 and P?S/8 are.





>
> Cheers,
>
> Gordon

cjl

[Vincent Slyngstad]

On Thursday, October 5, 2017 at 12:53:11 PM UTC-7, clasystems wrote:

On Thu, Oct 5, 2017 at 2:17 PM, Vincent Slyngstad wrote:
> I don't think of  P?S/8 as legacy code.  In part because it is still being
> developed/maintained, and in part because I have never seen it.  It
> has been "coming soon" for pretty much all of the 4+ decades I've
> been doing PDP-8 stuff.

 

The part that you've now had a glimpse into was completely functional

BEFORE they rejected it 40 years ago for no sound technical [or
business] reason.  What you are saying is just implying that you
aren't open to it, and that's the typical response I got from others
as far back as 1972.  Which applies more, I cannot say:  Pearls before
swine, or you can lead a horse to water...

I fail to understand the notion of something being maintained doesn't
make it legacy in any sense of the word.  Is it "better" that by bad
design OS/8 craps out totally on the date handling in 1977, and a faux
kludge that dies in 2001, while from the getgo P?S/8 could handle the
date until 2099? 

I'm using "legacy" here to specifically connote code and situations that 

cannot be changed or fixed.  "Legacy" code is the code that's broken 

that we are having to live with.  Since P?S/8 is being still under 

development, there exist opportunities to fix stuff.

I'm certainly open to P?S/8.  I try to keep track of events in the PDP-8 

universe, though, and to my knowledge, there are *four* extant copies/

users of P?S/8, including you.  That hardly counts as making it available 

for any kind of wide acceptance.

    Vince

[Vincent Slyngstad]

On Thursday, October 5, 2017 at 12:59:03 PM UTC-7, clasystems wrote:

On Thu, Oct 5, 2017 at 3:53 PM, CLASystems wrote:

> On Thu, Oct 5, 2017 at 2:17 PM, Vincent Slyngstad  wrote:
>> That's a valid point.  Though I also think it slightly distorts our
>> historical
>> perspective on the PDP-8, since for most of it's lifespan, mass storage
>> (and the operating system that goes with it) has been very much a
>> luxury item.  (Likewise extended memory; hence the push to keep
>> P?S/8 runable in 4K.)

I find your remark totally bizarre.  The PDP-8 was sans mass storage
for about 1.5 years; then DECtape camed out.  Few if any machines past
that LACKED mass storage.  Go check the sales figures; I think Doug
Jones has all of the statistics.

Perhaps it's a regional difference.  Here on the west coast perhaps one 

in ten or so systems could afford DECtape.  Certainly none of the high 

schools in my city had it.  My school got mass storage after I graduated, 

when the RX01 became readily available.  (In 1976, I believe, in their case).

 

    Vince

[CLASystems]

On Thu, Oct 5, 2017 at 8:29 PM, Vincent Slyngstad
<v.sly...@frontier.com> wrote:
>
>
> On Thursday, October 5, 2017 at 12:53:11 PM UTC-7, clasystems wrote:
>>
>> On Thu, Oct 5, 2017 at 2:17 PM, Vincent Slyngstad wrote:
>> > I don't think of P?S/8 as legacy code. In part because it is still
>> > being
>> > developed/maintained, and in part because I have never seen it. It
>> > has been "coming soon" for pretty much all of the 4+ decades I've
>> > been doing PDP-8 stuff.
>
>
>>
>> The part that you've now had a glimpse into was completely functional
>> BEFORE they rejected it 40 years ago for no sound technical [or
>> business] reason. What you are saying is just implying that you
>> aren't open to it, and that's the typical response I got from others
>> as far back as 1972. Which applies more, I cannot say: Pearls before
>> swine, or you can lead a horse to water...
>> I fail to understand the notion of something being maintained doesn't
>> make it legacy in any sense of the word. Is it "better" that by bad
>> design OS/8 craps out totally on the date handling in 1977, and a faux
>> kludge that dies in 2001, while from the getgo P?S/8 could handle the
>> date until 2099?
>
>
> I'm using "legacy" here to specifically connote code and situations that
> cannot be changed or fixed. "Legacy" code is the code that's broken
> that we are having to live with. Since P?S/8 is being still under
> development, there exist opportunities to fix stuff.

Then we'll just forever have a semantic argument. By that notion, we
should all run the even more broken PS/8 code that took days to come
up with a system that usually never worked.

That's not legacy, that's temperocentrism of what subset if things you
happen to prefer and also what is generally referred to as "not
invented here" syndrome.

Some people use the words "I was there" and on the PDP-8 software [and
to an extent hardware" scale, few were more "there" than I was. I
will borrow some things you mention below because I have already read
it. The PDP-8 is very much a product of the Northeast US. Things
only slowly meander to other areas.

Let me give you a valid analogy on an alternate subject:

When I was a kid, growing up in the NYC area, I was at the business
"center": of the popular music industry. The top ten [or 20 or 40
whatever] songs were a tight group of competitive works works vying
for airplay and the right to be called "#1" etc. Some of us would
literally laugh at the rest of the country because eventually there
were regional "hits" that were already passe in the Northeast. Today
we live in a faster-paced knowledge-spreading world. This effect no
longer exists [which is a good thing[. But to a large extent, this is
the true history of computing, especially DEC-centric computing..

the absolute original PDP-8 programming was done by some people who
were really not very talented.. We can give them credit only to the
extent that you had to start somewhere.. But to tell the absolute
truth, you had a bunch of NE "hicks" who had no idea what software
actually was, especially for the PDP-8, a machine they barely
understood what it both could do and would do later. Their
"productivity tools" were at first pathetic, then "graduated to
"poor".

During this time, the so-called "paper-tape software" was developed,
chief among these products was PAL III. I am only guessing, but I
thing PAL I was essentially a forerunner of DDT. Also, it had to run
on a 1K PDP-5. At that time, a 4K machine was considered "luxurious"
[and it certainly cost a fortune; that's why so few of the few that
sold were 4K. Theoretically the design could support more memory
fields; I doubt if ANY were evern built, even in house. the entire
PDP-5 project was a total disaster in every sense, and almost doomed
the PDP-8 even before it had started.

Fortunately, the hardware got better with the arrival of R-series and
related modules, replacing the dreadful "System Modules" that were so
expensive and a leader, Edson De Castro, who went on to design the
PDP-8/I [and then when DEC was to make the Nova, a jealous Gorgon Bell
pushed for the PDP-11 design that wasn't even vetted. This is well
known to many who were "there" at the time, and I personally know some
of the people, but regardless, De Castro went on to start Data General
and took with him 200 DEC employees with the notions of what was to
become the Nova in their heads and started DG down the road a piece
from Maynard, etc.

PAL II was so primitive an assembler [it ran in 1K] that it could not
properly create binary functional code without help from the user.
Ever wonder what the Z directive is used for [note: defective in PAL8;
it is merely ignored there; P?S/8 PAL fully supports it and has since
1968]. On PAL ii, the only binary created by itself was a current
page instruction. The concept of page 0 was literally impossible. If
you used literally DCA I 17 it generated 3617 instead of 3417. Such
is the limitation of a 1K program in memory and that includes the
space for the symbols. So how did they get PDP-8 code from this
feeble a program" Enter the Z directive.

Z forces the overall removal of the current page bit from the
improperly parsed output too feeble to know to not set it, and instead
always forces the bit off trusting the programmer knows better [and
never screws up!].

From this primitive environment [and in one of the very few in-house
4K PDP-5s] was developed what was to become PAL III, except of course
it was in the PAL II language. It doesn't take much to understand
that the code quality of that turkey had to be pretty bad, because if
nothing else, it was such a handicap to write code at all.

Some of you may know of the sometimes famous Ed Yourdon. If you check
him out, his first "credit" for his resume is "developer of the PAL
III assembler". I guess that will hold up in court legally on some
basis, but to anyone who understands anything about the PDP-8, it is
just something to ridicule. What Ed really did was he was the
"scutwork" guy on the project. What he did was he hand edited out all
of the Z directives in the code so now it was "bootstrapped". You now
required a binary running copy of PAL III to be able to assemble the
source code of PAL III and pretty much everything else. While of
course this was all welcome, it doesn't change the fact that the
actual code was putrid. Out of sheer expediency, the R-L Monitor used
PAL III with modifications to input and output to DECtape. [[Note: The
R-L Monitor only supports ONE DRIVE of a TC01 or TC08 DECtape, and
that's all. But you had to start somewhere. Moreover, the source code
of R-L was created by hand mostly on paper napkins from a local NY
restaurant in Chinatown frequented by pretty much all of the PDP-8
programmers from Brooklyn Poiy. [A tradition that continued until the
place closed many years later.]

The entire operating system was HAND-TOGGLED IN on a specific machine:
4K with a KSR-35 teletype, EAE, AF01, AA01A three-channel D-A
convertor and eventually the home made "music register" that is used
in some famous games such as POLY SPACEWAR, etc. [for sound effects].

The larger point here is that pretty much what MATTERED to the PDP-8
software universe started at my school. And I am NOT referring to
myself. Some point out that figuratively, I "stand on the shoulders
of giants" or the "2nd generation" because we were the first USERS of
what the original five wrote while at the school, who then went to
work for DEC the summer just before I got there, and fortunately,
stumbled on this curious machine and was literally handed a working
DECtape system. All of us learned how to program -in the 12-bit
sense] on that machine on that system while they went on to work for
DEC.

But unfortunately, when they got there, the "powers-that-be" were
rather pathetic, ignorant and totally dictatorial. When shown the R-L
Monitor, they literally could not understand it conceptually.
Perchance in the early '70s I had the dubious dinstinction of meeting
one of these "brains" at a DECUs symposium. I was trying to point out
that we were really doing great things to the R-L Monitor, assuming
they would be interested, etc. This chance meeting left me
dumb-founded. It quickly became clear that this person's ability to
comprehend what PDP-8 software even was was quite over his head. I
won't go into the details, don't need to needlessly embarrass the
fool, etc. But it became clear to me that no one there at the top had
a clue.

Only later did I find out exactly how what became OS/8 was "hatched".

Why didn't they "like" the R-L Monitor" Because they had already made
up their minds that it HAD to have 8K!

Now, without going into great software details, one of the chief
limitations of R-L had to do with it's one internal ugly kludge at the
time, the "hand-off" code that was how a program that could be as much
as 00000-07577 was loaded into memory while maintaining only the
kernel in 07600-07777. It was solvable, but they wanted something
quickly and had no interest in the implied precision of development
effort.

I should stop at this point and explain something about PDP-8
programming in general. It's pretty much the only machine where you
can get a reasonable amount of functioning outcome where you also have
to be wary of the SIZE of the program as well as the 128-word paging
of memory. Certain people "spoiled" by other machines literally
couldn't do the proverbial "program their way out of a paper-bag" on a
PDP-8. It's not for everyone to be sure. But if you truly understand
it, you can do quite a lot.

thus, the only way to get across to these idiots was to shove
something in their face they could relate to -simplistically at least.

Thus, what was suggested by the original five PDP-8 "super-heroes" was
a DEMO program that had the user interface in the style of a TOPS-10
time-sharing user. The key word is DEMO as in "this is not real; we
will start over again and write the real thing if you approve the
demo".

And 48 hours later, they did produce this hasty demo [with all sorts
of things internally not ever implemented; after all, it's a demo,
right?

While this was going on, the "2nd generation" people [including me and
eventually only me] were taking the R-L Monitor System to the next
level. After all, we had the R-L Monitor to develop code ON. [Thus,
we didn't have to toggle the code in by hand after hand assembling
it!.]

What we achieved was among other things, solving the hand-off problem:
Within the last page of memory in 4K 07600-07777, we created an
embedded call to the system device handler itself. By plugging in
parameters, it was now possible to load 00000-07577 and then start
anywhere in memory. It took awhile, and clearly in consort, a few of
us could [and did] solve this problem] which is sometimes known as
being "device-independent".

But for the demo, especially since the "suits" insisted that it
REQUIRE 8K, they just did a cop-out. They co-opted 17600-17777 as
part of an extended kernel, where the utility gained is really rather
minimal, but a demo could be done as part of the 48 hours work. To
this day, the last thing done to run a core-image is to plug into this
embedded call IN FIELD 1 the loading of the last section of the
program and then start it up. It cannot work in 4K because they
literally never tried to.

The problem is that these idiot managers insisted on using the demo as
the basis of the product! As a result, the other four people
literally walked out on the project. One quit and went to an early
PDP-11 project [also run by a dictatorial manager with notions. He
quite telling that fool he was an idiot. And if course that was true;
soon thereafter that entire project was canned]. The other three
never worked on OS/8 ever again [although two of them later worked on
OS/8 BASIC, but as consultants, not employees.]

This unfortunately, is the "legacy" some refer to, while I refer to
the real legacy as the R-L Monitor which was far better and the
product of the best 12-bit minds in the world at the time. It needed
a lot of work of course. What was done was accomplished over a 4
month period just before I came to the school, etc. [but the rate of
development when you have to HAND-TOGGLE in hand-assembled code is a
slow process even for people that good].

Thus, what we did in upgrading the true original system is the true
and proper lagacy and not what "festered" in DEC. Another way to look
at this is that since the OS/8 kernel was stagnated, it was doomed to
mediocrity and a management attitude of the tyranny of low
expectations, which appears to be a common trait of MANAGERS, not
programmers.

Thus, later, when I approached DEC with a P/S/8 DEMO, I was not
prepared for the profound arrogance the first time around. The
programmers lobbied for P/S/8 [or actually just their guess as to what
we did to R-L knowing it was a true upgrade to the original] and what
I showed them was quite impressive to all but the idiot manager.

He deigned to ask me a SINGLE question: What was the MINIMUM memory
requirement to run P?S/8. I honestly answered "4K". His snap answer
is "that's no good because it COULD discourage memory sales". [I
think I have that quoted accurately. [Remember, I didn't know about
the original management edict before the poor demo was even written by
the five of them in 48 hours..

I guess in hindsight, I should have lied. OS/.8 can run in 8K. Many
programs really need more memory to do anything more than simplistic.
P/S/8 PAL needs 20K to do what PAL8 can do [that is a rough
approximation and quite generous; P?S/8 PAL is a large superset of
PAL8] in 24K.

In other words, the minimum memory to boot a kernel is a MEANINGLESS STATISTIC.

One of the most important aspects of P?S/8 is the memory model which
is 32K-oriented. OS/8 ruins memory because it occupies field 1,
ruining the memory layout for programs that need a clean 15-bit
addressing space such as OS/8 BASIC and Fortran IV. [which perform
kludges to badly carry out what P?S/8 does naturally; I explained this
to my friends and they agreed it was superior, but they were lazy and
besides, you could snowjob the managers. They were very creative in
spending their spare-time hobbies as much as possible, but were quite
unmotivated to do better. The more peripheral programmers in the
programming group perfectly fulfilled their tiny assignments taking
the absurd amounts of time allocated to them. to accomplish very
little. I could never have worked there! [P?S/8 always occupies the
first 4K of memory, meaning the only permanent kernel is in
07600-07777. Optional or mandatory additional components, if any are
loaded into the highest field of memory. User extended memory is
defines as 100% of the space above field 0 but less than the highest
field should portions of it [as much as all of the top field] be
occupied. For certain systems that cannot be accomplished in 4K [and
roughly analogous to why OS/8 needs 12K instead of 8K] the top 1K of
actual extended memory will be reserved. Conforming programs can use
the other 3K if available even in that situation. If the machine
happens to be 8Km then the two systems are roughly analogous. But in
32K there is just no similarity at all. This is what good design is
all about, not a stunted design born of management's ignorant edicts,
etc.

It's not my fault that DEC never took over P?S/8 from me [and I also
showed it to them again a couple years later; that time, the arrogant
manager ignored everyone totally; he just pretended to be "too busy"
to even have paid attention. this despite the reaction of everyone
else who was there.

I wasn't going to be part of this insane asylum and instead I sold a
limited license of P/S/8 to Intersil for use on their OWN IM6100-based
machine called the Intercept I. It is essentially an "industrial
strength" super-set of the VT78 [which also used the same chip -
poorly].

During the years up until them, there were several "colonies" of P/S/8
users, some in Syracuse University as well as many I had personal
contact with in my gainful employment as a PDP-8 programmer, primarily
in the New York area. especially as a consultant for many users. Some
may have heard of the PR Newswire System, a 40-task cooperative
multi-tasking system written by me and two others. This was developed
using P?S/8 PAL because it has important features unavailable in PAL8
[or any other assembler] particularly the conditional literal literal
feature. When you write a huge project, you cannot go back and help
out ignorant PAL8 with placing literals for you. If the code needs to
be somewhat tighter, you have to waste many hours poring over large
listing files to squeeze out a few words. Conditional literals does
that for you automatically. [Note: Neither OS/8 nor P?S/8 can run
that system, it is a stand-alone bootable system out of necessity. i
did several other systems with differing requirements in the same
general conceptual way. All of them were interrupt-driven systems and
as such had to be standalone by nature. The PR-Newswire system kernel
was about 16K.] But these are special-purpose systems incapable of
PDP-8 development. A good programmer starts with a clean slate and no
preconceived notions, etc.

But the people there were by any definition P?S/8 "users" because
that's the only way to make changes to the source code that has to be
assembled into the binary that becomes the stand-alone bootable
system. [The concept is not profound. That's why there was WPS-8
from DEC.] the key point is OS/8 is not the be-all/end-all system
some people think it is. That severely short-changes just what a
PDP-8 actually is.

>
> I'm certainly open to P?S/8. I try to keep track of events in the PDP-8
> universe, though, and to my knowledge, there are *four* extant copies/
> users of P?S/8, including you. That hardly counts as making it available
> for any kind of wide acceptance.

I cannot help how much, or how many of anything. It appears that
where you come from, there wasn't wide acceptance of OS/8 either.

Thus suggests that all you should use the PiDP-8 for is "legacy"
paper-tape programs including PAL III

cjl

>
> Vince
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "PiDP-8" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/pidp-8/h7AKaN-hvEI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> pidp-8+un...@googlegroups.com.
> To post to this group, send email to pid...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-8/f980314e-6f02-4479-8092-edf70469ea41%40googlegroups.com.

[CLASystems]

On Thu, Oct 5, 2017 at 8:35 PM, Vincent Slyngstad
<v.sly...@frontier.com> wrote:
>
>
> On Thursday, October 5, 2017 at 12:59:03 PM UTC-7, clasystems wrote:
>>
>> On Thu, Oct 5, 2017 at 3:53 PM, CLASystems wrote:
>> > On Thu, Oct 5, 2017 at 2:17 PM, Vincent Slyngstad wrote:
>> >> That's a valid point. Though I also think it slightly distorts our
>> >> historical
>> >> perspective on the PDP-8, since for most of it's lifespan, mass storage
>> >> (and the operating system that goes with it) has been very much a
>> >> luxury item. (Likewise extended memory; hence the push to keep
>> >> P?S/8 runable in 4K.)

That is at best a crock. How is it an issue that it CAN run in 4K?
Few machines made after the PDP-8/E came out were as small as 4K. 8K
was pretty much in vogue everywhere, and then likely more. so what?
It just means that P?S/8 manages available memory better, which is the
case.

there are many OS/8 programs that have no need for extended memory;
it's just necessary because of the inefficient kernel design which I
touched on earlier; they let it fester while we fixed the problem.
Their way isn't any better, it just requires 8K while we perfected the
R-L original while maintaining the minimum memory requirement.

If the programmers had their way, there never would have been an OS/8
as we know it today; it would have been dropped when me and my
friends/colleagues had perfected what P?S/8 is on course to becoming.
The P?S/8 SHELL barely crawls in 4K. But it does and if that's all
you need, it is barely adequate. Someone else might need 32K. It all
depends upon exactly what is needed to be done. the system has
dynamic memory allocation, etc. As soon as the group had written
enough code, OS/8 would have been dropped. [But of course i speak to
a fantasy. Of course in DEC managers and marketroids made all the
decisions. no one ever asked a programmer what they ought to have
done.] [And that is just a small part of the larger problem of bad
management, which is why we are speaking to this today, and DEC has
been out of business for quite a long time. The interest in the
machine survives all of the fools who made all of the bad decisions,
etc.

You speak of mass storage and extended memory as "luxury items? This
simply was never the case after 1967, the year the BIN loader was
modified to not be corrupted by the presence of TC01 DECtape. It is
curious that the EARLY PDP-8 market was for machines without storage
devices, but that quickly changed once that was no longer the case.
During most of its lifespan, the opposite of your claim is easily
proven.

>>
>> I find your remark totally bizarre. The PDP-8 was sans mass storage
>> for about 1.5 years; then DECtape camed out. Few if any machines past
>> that LACKED mass storage. Go check the sales figures; I think Doug
>> Jones has all of the statistics.
>
>
> Perhaps it's a regional difference. Here on the west coast perhaps one
> in ten or so systems could afford DECtape. Certainly none of the high
> schools in my city had it. My school got mass storage after I graduated,
> when the RX01 became readily available. (In 1976, I believe, in their
> case).

Then it is unfortunate for you your schools got the short end of
things. But it was hardly what anyone could call "typical" in any
sense of the word. They who configured those machines weren't even
swayed by DEC's marketing apparently.

In any case, you have a fundamental disconnect here. You equate your
miserable high-school experience with the mainstream of PDP-8 systems
during the economic lifetime of the PDP-8. Yes, it is clearly a
regional issue. But most of us never lived in your "region".

cjl


>
> Vince
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "PiDP-8" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/pidp-8/h7AKaN-hvEI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> pidp-8+un...@googlegroups.com.
> To post to this group, send email to pid...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-8/dbd51971-54bd-45ed-91d3-d800a5d29efe%40googlegroups.com.

[Paul Birkel]

-----Original Message-----
From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of CLASystems
Sent: Friday, October 06, 2017 2:42 AM
To: Vincent Slyngstad
Cc: PiDP-8
Subject: Re: [pidp8] Re: PDP-8 Programming Challenges

On Thu, Oct 5, 2017 at 8:35 PM, Vincent Slyngstad
<v.sly...@frontier.com> wrote:
>
> Perhaps it's a regional difference. Here on the west coast perhaps one
> in ten or so systems could afford DECtape. Certainly none of the high
> schools in my city had it. My school got mass storage after I graduated,
> when the RX01 became readily available. (In 1976, I believe, in their
> case).

Then it is unfortunate for you your schools got the short end of
things. But it was hardly what anyone could call "typical" in any
sense of the word. They who configured those machines weren't even
swayed by DEC's marketing apparently.

In any case, you have a fundamental disconnect here. You equate your
miserable high-school experience with the mainstream of PDP-8 systems
during the economic lifetime of the PDP-8. Yes, it is clearly a
regional issue. But most of us never lived in your "region".

cjl

-----

FWIW, a neurophysiology lab at an Ivy League university in 1972 could only afford a PDP-8/L, 4Kw memory, high-speed PTR/PTP, AX08, and M33 ASR. Perhaps we *were* atypical, as the lab a floor below us had an 8/I, 32Kw memory, dual DF32, dual TU56, at least two AX08 and a bunch of specialized equipment (including CRT displays). I knew what I was missing, but only by word-of-mouth -- never had the opportunity to work on that machine, alas.

We used the three-pass assembler and high-speed paper-tape for program development, execution, and lots of fan-fold paper-tape for data storage/retrieval.

I'll never forget that big SOLA constant-voltage transformer humming away.

There simply wasn't research funding to buy better hardware. We (actually, I) did our own hardware maintenance. And when it became imperative that we acquire additional memory to hold real-time-acquired signals preparatory to statistical analysis we replicated the 8/I memory controller using wire-wrap and then drove an S100 bus loaded with standard 4K-byte 2102A-based (1K x1 -bit SRAM) boards. (I believe these: http://www.s100computers.com/Hardware%20Folder/Processor%20Technology/4K%20RAM/4K%20RAM.htm)

By piggybacking the memory ICs we were able to get a full expansion crammed into 6 memory boards plus one for the controller. It ran stably for years, until the entire system was retired in the early 80's.

Anyway, just wanted to point out that there were "miserable" college experiences as well :->.

Fortunately, I guess, I didn't know any better ...

-----

[Vincent Slyngstad]

On Thursday, October 5, 2017 at 11:23:37 PM UTC-7, clasystems wrote:

On Thu, Oct 5, 2017 at 8:29 PM, Vincent Slyngstad wrote:
> I'm using "legacy" here to specifically connote code and situations that
> cannot be changed or fixed.  "Legacy" code is the code that's broken
> that we are having to live with.  Since P?S/8 is being still under
> development, there exist opportunities to fix stuff.

Then we'll just forever have a semantic argument.   By that notion, we
should all run the even more broken PS/8 code that took days to come
up with a system that usually never worked.

Well, yes, if our goal is to learn about and re-create the experience of using PS/8.

Likewise, if we want to learn what the PDP-8 was like for most people, we'd use 

paper tape or OS/8 or whatever the relevant "most people" used.

When our goal is to sharpen our PDP-8 coding skills, we'd probably use P?S/8.  

If we could get it.  Believe it or not, I do follow your technical discussions of 

the shortcomings of other systems and agree that P?S/8 would be better.

 

It's not my fault that DEC never took over P?S/8 from me [and I also
showed it to them again a couple years later; that time, the arrogant
manager ignored everyone totally; he just pretended to be "too busy"
to even have paid attention.  this despite the reaction of everyone
else who was there.

This may be so, and it is interesting as a history lesson, but it's also 

just not relevant to current PDP-8 practices.  I say this because 

you've had 40+ years to rectify the situation.  It seems to me that 

even back in the day, you could have just contributed your work to 

DECUS or whatever.  You did in fact, licence the code for a time to 

another company, though that doesn't seem to have been all that 

successful at encouraging widespread use.

Certainly, in this internet age, there is plenty of opportunity for you 

to get P?S/8 into the hands of folks who'd like to try it out.  I'm 

aware that you're working on it, and eager to see the results.

    Vince

[Vincent Slyngstad]

On Friday, October 6, 2017 at 5:56:24 AM UTC-7, Paul Birkel wrote:

FWIW, a neurophysiology lab at an Ivy League university in 1972 could only afford a PDP-8/L, 4Kw memory, high-speed PTR/PTP, AX08, and M33 ASR.  Perhaps we *were* atypical, as the lab a floor below us had an 8/I, 32Kw memory, dual DF32, dual TU56, at least two AX08 and a bunch of specialized equipment (including CRT displays).  I knew what I was missing, but only by word-of-mouth -- never had the opportunity to work on that machine, alas.

We used the three-pass assembler and high-speed paper-tape for program development, execution, and lots of fan-fold paper-tape for data storage/retrieval.

Actually, re-reading Doug Jones' FAQ, it seems our experience was not 

that atypical.  I didn't find numbers for DECtape systems, but there is 

text there that implies that many systems prior to the mid 1970s had 

limited memory and no mass storage.

Certainly the Omnibus machines were a much different price point, and 

did often come with more memory and mass storage.  Those machines 

also sold in much higher volumes, so I have to concede that numerically, 

the majority of PDP-8s sold probably had mass storage (but not as nice 

blinkenlights).

 

Hey, you at least had high speed paper tape :-).

 

There simply wasn't research funding to buy better hardware.  We (actually, I) did our own hardware maintenance.  And when it became imperative that we acquire additional memory to hold real-time-acquired signals preparatory to statistical analysis we replicated the 8/I memory controller using wire-wrap and then drove an S100 bus loaded with standard 4K-byte 2102A-based (1K x1 -bit SRAM) boards.  (I believe these: http://www.s100computers.com/Hardware%20Folder/Processor%20Technology/4K%20RAM/4K%20RAM.htm)

Now that sounds like a fun hardware kludge :-).

 

    Vince

[Paul Birkel]

 

 

From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Vincent Slyngstad
Sent: Friday, October 06, 2017 10:00 AM
To: PiDP-8
Subject: Re: [pidp8] Re: PDP-8 Programming Challenges

 

On Friday, October 6, 2017 at 5:56:24 AM UTC-7, Paul Birkel wrote:

FWIW, a neurophysiology lab at an Ivy League university in 1972 could only afford a PDP-8/L, 4Kw memory, high-speed PTR/PTP, AX08, and M33 ASR.  Perhaps we *were* atypical, as the lab a floor below us had an 8/I, 32Kw memory, dual DF32, dual TU56, at least two AX08 and a bunch of specialized equipment (including CRT displays).  I knew what I was missing, but only by word-of-mouth -- never had the opportunity to work on that machine, alas.

We used the three-pass assembler and high-speed paper-tape for program development, execution, and lots of fan-fold paper-tape for data storage/retrieval.

 

Actually, re-reading Doug Jones' FAQ, it seems our experience was not 

that atypical.  I didn't find numbers for DECtape systems, but there is 

text there that implies that many systems prior to the mid 1970s had 

limited memory and no mass storage.

 

[PAB] I don’t recall any “inclination” towards mass-storage on our part.  We needed more memory, full stop.  Unfortunately the lab being that of a relatively new junior faculty member we were poor-as-church-mice.  Which is why they let a freshman undergraduate (not even an EE Major) “take charge”.  Over in EECS (just EE at the time) if you were a *lucky* _graduate_ student you got to share some time on a PDP-11/20 or -11/10.

 

Certainly the Omnibus machines were a much different price point, and 

did often come with more memory and mass storage.  Those machines 

also sold in much higher volumes, so I have to concede that numerically, 

the majority of PDP-8s sold probably had mass storage (but not as nice 

blinkenlights).

 

Hey, you at least had high speed paper tape :-).

[PAB] Yes.  Oh yes …  The basic lab-work would have been effectively impossible without it, even if we were to have tried to tough-it-out using the low-speed ASR for compiling.

 

There simply wasn't research funding to buy better hardware.  We (actually, I) did our own hardware maintenance.  And when it became imperative that we acquire additional memory to hold real-time-acquired signals preparatory to statistical analysis we replicated the 8/I memory controller using wire-wrap and then drove an S100 bus loaded with standard 4K-byte 2102A-based (1K x1 -bit SRAM) boards.  (I believe these: http://www.s100computers.com/Hardware%20Folder/Processor%20Technology/4K%20RAM/4K%20RAM.htm)

 

Now that sounds like a fun hardware kludge :-).

 

[PAB] I thought that it was :->.  All of those stacked 2102As certainly looked … kludgy.  I had to hand-wire the S100 backplane in order to separate the boards for increased accessibility and air-flow (1” centers, maybe more).  In retrospect it probably only worked because the 8/I memory controller was a sound design with good safety margins which I followed scrupulously.  Apparently the noise tolerance/immunity on the cables that I hand-built from the accessory-chassis to the 8/L was acceptable; they were just standard IDC-ribbons with alternating ground lines.  I scavenged a lot of the controller ICs; the S100-stuff was possible to mail-order.  It was all pretty inexpensive, using a lot of surplus this-n-that that I scrounged.  Parts ended up in the low hundred$.  Labor was free.  I am forever grateful to “my” professor for deciding to accept the proposal (which was unsolicited), and trusting that I could execute it.  I still don’t know what possessed him.  Wish that I had a few pictures :-<.

 

    Vince

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/6d86ae96-bb71-4a46-a16e-3a01a5a53d98%40googlegroups.com.

[Vincent Slyngstad]

On Friday, October 6, 2017 at 5:56:24 AM UTC-7, Paul Birkel wrote:

FWIW, a neurophysiology lab at an Ivy League university in 1972 could only afford a PDP-8/L, 4Kw memory, high-speed PTR/PTP, AX08, and M33 ASR.  Perhaps we *were* atypical, as the lab a floor below us had an 8/I, 32Kw memory, dual DF32, dual TU56, at least two AX08 and a bunch of specialized equipment (including CRT displays).  I knew what I was missing, but only by word-of-mouth -- never had the opportunity to work on that machine, alas.

Did you have the EAE option?  Most machines I've seen don't have it, though it seems 

more prevalent on Omnibus machines.  I know it was popular with the Fortran folks,

The floating point options seem quite rare outside of the PDP-12 and a few 8/A systems.

    Vince

[Paul Birkel]

I didn’t, just an 8/L.  However, I *think* that the 8/I did.  Aside from the fact that they had just about everything excepting facilities for handling cards (yes they had a plotter set up; I believe a CalComp), I did on an occasion or two get to peek inside the racks – there were 5 pretty full ones – and my recollection is that the 8/I was fully stuffed with modules.

 

You might have guessed that there was a (soon to be, if he wasn’t already) Full Professor involved :->.

 

From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of Vincent Slyngstad
Sent: Friday, October 06, 2017 1:22 PM
To: PiDP-8
Subject: Re: [pidp8] Re: PDP-8 Programming Challenges

 

--

You received this message because you are subscribed to the Google Groups "PiDP-8" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/c04d9ce2-44cf-4ac4-9471-8f9993ccbe60%40googlegroups.com.

[Vincent Slyngstad]

On Friday, October 6, 2017 at 10:41:44 AM UTC-7, Paul Birkel wrote:

I didn’t, just an 8/L.

Sorry.  My eye skimmed right over the 8/L bit, which had already answered 

my question.  

I'll write Doug and see if he has any data about how common the options were.

    Vince

[Gordon Henderson]

On Wed, 4 Oct 2017, Vincent Slyngstad wrote:

> I was inspired by Warren's post at
> https://groups.google.com/forum/#!topic/pidp-8/OQ0LzyQ94QI

Me too..

What I've done recently is to write my own PDP-8 emulator - primarily with
the aim to learn more about the PDP-8 instruction set...

... and what I've ended up with is a good knowledge of the instructions
but not how to actually write programs with them...

An analogy might be knowing 100,000 French words but not knowing the right
order to put them together...

Anyway for your entertainment, a quick stab at a solution can be seen
here:

http://unicorn.drogon.net/pdp8/e1.pal

Seems to work fine, but prints the answer in Octal (I ought to steal
Vincents print decimal code :)

It's somewhat convoluted - not efficient nor elegant - not because I
couldn't think of anything better (my initial solution was more like
Vincents) but because I'd already started to write a program to solve the
Sieve of Eratosthenes and had been playing with an array and loops and
deliberately wanted to make it different from the others.

(also; I've got 4K of expensive core, if I'm not using it, it's money
wasted, dammit! :-)

And I know there are code optimisations to be made, coding styles to be
critical of, or to marvel at, but it'll do for now.

So as a learning exercise, it was fun - and going back to the "knowing the
word but not the order" idea - things I'm starting to appreciate are
having an "eye" for knowing the size of routines, variable/temp storage
placement and maybe wondering if avoiding "links generated" is some form
of machismo or masochism... Especially as I'm sitting here with palbart on
my PiDP-8 with the ability to do an edit/assemble cycle in seconds rather
than actually feed a real PDP-8 with paper tape and go through the
punch/edit/assemble/run cycle via tape... (Which I have done for real, but
on an Eliot 903 rather than a PDP-8 - that was an interesting summer job
many decades ago)

Cheers,

Gordon

[CLASystems]

Interesting and remotely familiar.

When I started working at Mount Sinai Hospital [a teaching hospital]
in late 970, we started with an 8K PDP-8/L TC08 with a dual TU56
[single pair] and an AX08.

Using paper-tape would be incredibly frustrating. Fortunately, it
never came to that since I came with the R-L Monitor System, quickly
developed the first generation of real-time and analysis programs.
The limiting factor was the ASR-33 teletype. Fortunately, I also had
access to another machine that had a line-printer on it and could
sneakernet my files to that other machine [both had DECtape]. Within
about 9 months, we were already using P?S/8. Researchers were able to
do their work on the machine [we had to schedule time on the machine;
I mostly used it at night and the entire weekends].

If this had been a paper-tape environment, program development would
be at a snail's pace. I guess that's the difference between a working
hospital where you actuallly have to produce something, as opposed to
just writing research papers that can include in the subject matter a
well-crated complaint about lack of proper tools [so you could get
more grant money].

>
> We used the three-pass assembler and high-speed paper-tape for program development, execution, and lots of fan-fold paper-tape for data storage/retrieval.
>
> I'll never forget that big SOLA constant-voltage transformer humming away.

I can relate to that as well.

>
> There simply wasn't research funding to buy better hardware. We (actually, I) did our own hardware maintenance. And when it became imperative that we acquire additional memory to hold real-time-acquired signals preparatory to statistical analysis we replicated the 8/I memory controller using wire-wrap and then drove an S100 bus loaded with standard 4K-byte 2102A-based (1K x1 -bit SRAM) boards. (I believe these: http://www.s100computers.com/Hardware%20Folder/Processor%20Technology/4K%20RAM/4K%20RAM.htm)
>
> By piggybacking the memory ICs we were able to get a full expansion crammed into 6 memory boards plus one for the controller. It ran stably for years, until the entire system was retired in the early 80's.
>
> Anyway, just wanted to point out that there were "miserable" college experiences as well :->.

No doubt!

>
> Fortunately, I guess, I didn't know any better ...

Indeed.

cjl

>
> -----

>
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/h7AKaN-hvEI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
> To post to this group, send email to pid...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/092b01d33ea2%248c29f3a0%24a47ddae0%24%40gmail.com.

[CLASystems]

On Fri, Oct 6, 2017 at 10:59 AM, Paul Birkel <pbi...@gmail.com> wrote:
>
>
>
>
> From: pid...@googlegroups.com [mailto:pid...@googlegroups.com] On Behalf Of
> Vincent Slyngstad
> Sent: Friday, October 06, 2017 10:00 AM
> To: PiDP-8
> Subject: Re: [pidp8] Re: PDP-8 Programming Challenges
>
>
>
>
>
> On Friday, October 6, 2017 at 5:56:24 AM UTC-7, Paul Birkel wrote:
>
> FWIW, a neurophysiology lab at an Ivy League university in 1972 could only
> afford a PDP-8/L, 4Kw memory, high-speed PTR/PTP, AX08, and M33 ASR.
> Perhaps we *were* atypical, as the lab a floor below us had an 8/I, 32Kw
> memory, dual DF32, dual TU56, at least two AX08 and a bunch of specialized
> equipment (including CRT displays). I knew what I was missing, but only by
> word-of-mouth -- never had the opportunity to work on that machine, alas.
>
> We used the three-pass assembler and high-speed paper-tape for program
> development, execution, and lots of fan-fold paper-tape for data
> storage/retrieval.
>
>
>
> Actually, re-reading Doug Jones' FAQ, it seems our experience was not
>
> that atypical. I didn't find numbers for DECtape systems, but there is
>
> text there that implies that many systems prior to the mid 1970s had
>
> limited memory and no mass storage.

Since I was a party to Doug's documents, I can assure you that your
year reckoning is way off.

By 1972, all sales of other than Omnibus -based PDP-8 systems were negligible.

You cannot really draw any inferences to missing data.

The TC08 era starts pretty much with the middle of the PDP-8/L era
because the TC08 is positive bus, not negative bus. The PDP-8/I being
negative typically had the TC01 with predominantly TU55 single-drives
[usually a pair]..

Thus, your conclusion below is perfectly correct, but the applicable
years are wrong. By that time, DEC was peddling TD8E-based systems
then RX01 diskette drive pairs.

cjl

> You received this message because you are subscribed to a topic in the
> Google Groups "PiDP-8" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/pidp-8/h7AKaN-hvEI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> pidp-8+un...@googlegroups.com.
> To post to this group, send email to pid...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-8/096101d33eb3%24c008b2e0%24401a18a0%24%40gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.

[CLASystems]

On Fri, Oct 6, 2017 at 1:21 PM, Vincent Slyngstad
<v.sly...@frontier.com> wrote:
>
>
> On Friday, October 6, 2017 at 5:56:24 AM UTC-7, Paul Birkel wrote:
>>
>> FWIW, a neurophysiology lab at an Ivy League university in 1972 could only
>> afford a PDP-8/L, 4Kw memory, high-speed PTR/PTP, AX08, and M33 ASR.
>> Perhaps we *were* atypical, as the lab a floor below us had an 8/I, 32Kw
>> memory, dual DF32, dual TU56, at least two AX08 and a bunch of specialized
>> equipment (including CRT displays). I knew what I was missing, but only by
>> word-of-mouth -- never had the opportunity to work on that machine, alas.
>
>
> Did you have the EAE option? Most machines I've seen don't have it, though
> it seems
> more prevalent on Omnibus machines. I know it was popular with the Fortran
> folks,

Trivial to add on a PDP-8/I or PDP-12. Not possible on the 8/L by design.

Two extra cards on the 8/E processor, but you get double-precision
instructions as well [MODE B].

>
> The floating point options seem quite rare outside of the PDP-12 and a few
> 8/A systems.

Very, very rare. I do have the FPP-8/A cards [someone sent them to me
as a present :-).

cjl

>
> Vince
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "PiDP-8" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/pidp-8/h7AKaN-hvEI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> pidp-8+un...@googlegroups.com.
> To post to this group, send email to pid...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-8/c04d9ce2-44cf-4ac4-9471-8f9993ccbe60%40googlegroups.com.

[Vincent Slyngstad]

On Friday, October 6, 2017 at 12:01:53 PM UTC-7, Gordon Henderson wrote:

What I've done recently is to write my own PDP-8 emulator - primarily with
the aim to learn more about the PDP-8 instruction set...

... and what I've ended up with is a good knowledge of the instructions
but not how to actually write programs with them...

That's not surprising.  It takes some practice to get the hang of using them well.

 

Anyway for your entertainment, a quick stab at a solution can be seen
here:

http://unicorn.drogon.net/pdp8/e1.pal

Cool!  I went to https://github.com/pa28/PiDP-8-sim/blob/master/asm/palbart.c

and got a copy of palbart, since the cross assembler that I am using on my PC 

doesn't support the ASCII pseudo-op.  Then I was able to assemble your code, 

but I got an "undefined" error on the line:

	decimal

because that version of palbart doesn't truncate at 6 characters.

Changing the line to 

	decima

allowed the program to compile (and run) just fine.

 

Seems to work fine, but prints the answer in Octal (I ought to steal
Vincents print decimal code :)

Feel free to improve on it :-).  I feel it is actually kind of clunky.

And I know there are code optimisations to be made, coding styles to be
critical of, or to marvel at, but it'll do for now.

There's some interesting idiomatic code in there, which suggests you've

been reading the code of others, since you say this is an early effort for 

you.

I see "hlt" used at subroutine entries, for instance, whereas I use ".-." sort 

of generically for data whose compile time value is unimportant.

I also see the hack of putting an origin at the starting address last, which 

there was a DECUS self-starting loader or some such that used to encourage.

So as a learning exercise, it was fun - and going back to the "knowing the
word but not the order" idea - things I'm starting to appreciate are
having an "eye" for knowing the size of routines, variable/temp storage
placement

I do see coding the equivalent of 

        for (num=0; num < 1000; num++)

instead of 

        for (num=-1000; num; num++)

which has a much more efficient implementation.

I also try to leave out the NOP after ISZ if I know the ISZ can't skip.

All the skip OPRs can also be combined with CLA, and often should be.

As you point out, those optimizations aren't really important for something 

this simple (except as exercise toward better habits).

and maybe wondering if avoiding "links generated" is some form 
of machismo or masochism... Especially as I'm sitting here with palbart on
my PiDP-8 with the ability to do an edit/assemble cycle in seconds rather
than actually feed a real PDP-8 with paper tape and go through the
punch/edit/assemble/run cycle via tape...

I don't think palbart is doing you any favors there.  It makes generated links 

much too easy, in my opinion.  The assembler I use does generate the links, 

but also flags each generated link as an error (like palbart -e).  Generally, it 

is easy enough to change each

        mri foo

into

        mri I (foo)

if that's really the best thing to do about the cross-page reference.  Thinking

about cross-page references is important to writing good PDP-8 code, though, 

when the code gets larger than a page or two.

    Vince

[CLASystems]

On Sat, Oct 7, 2017 at 2:32 AM, Vincent Slyngstad <v.sly...@frontier.com> wrote:

On Friday, October 6, 2017 at 12:01:53 PM UTC-7, Gordon Henderson wrote:

What I've done recently is to write my own PDP-8 emulator - primarily with
the aim to learn more about the PDP-8 instruction set...

... and what I've ended up with is a good knowledge of the instructions
but not how to actually write programs with them...

That's not surprising.  It takes some practice to get the hang of using them well.

 

Anyway for your entertainment, a quick stab at a solution can be seen
here:

http://unicorn.drogon.net/pdp8/e1.pal

Cool!  I went to https://github.com/pa28/PiDP-8-sim/blob/master/asm/palbart.c

and got a copy of palbart, since the cross assembler that I am using on my PC 

doesn't support the ASCII pseudo-op.  Then I was able to assemble your code, 

but I got an "undefined" error on the line:

	decimal

because that version of palbart doesn't truncate at 6 characters.

Changing the line to 

	decima

allowed the program to compile (and run) just fine.

​Just yet another reason to not use an incompatible assembler.  You find out every day just how incompatible it really is.​

 

 

Seems to work fine, but prints the answer in Octal (I ought to steal
Vincents print decimal code :)

Feel free to improve on it :-).  I feel it is actually kind of clunky.

And I know there are code optimisations to be made, coding styles to be
critical of, or to marvel at, but it'll do for now.

There's some interesting idiomatic code in there, which suggests you've

been reading the code of others, since you say this is an early effort for 

you.

I see "hlt" used at subroutine entries, for instance, whereas I use ".-." sort 

of generically for data whose compile time value is unimportant.

​I have seen using HLT on subroutine headers in the hope it will snag an out of control program gone amok.

However, the notion of .-. and all the variations has its roots in older machines; IBMESQUE would be *-* in their world.  Some want to get fancy and use other arithmetic operators but the result is always the same.  Don't care upon load is important so needed zero values use either 0 or perhaps ZBLOCK followed by the appropriate count.

ZBLOCK has an additional usage.  If you must start something that follows on a good boundary or other such condition, you can use ZBLOCK X-. where you must be at boundary X.  A ZBLOCK statement is thus conditional and may generate no words.  In which case it might merely be a form of immediate documentation emphasizing the required alignment [with the knowledge and intent of not actually generating any words at all].

This is one of the things they screwed up in PAL10 when last worked on by some PDP-10 people who were misinformed as to what PAL10 was supposed to implement.

It is illegal to redefine a symbol using the , construct even if it generates the identical value.  This is a really bad problem because data can be require multiple definitions for very local purpose.  They must agree and we depend on the assembler pointing out when this not the case.  But PAL10 flags all attempts whether correct or not.

FOO=.
FOO,

Is the shortest way to illustrate this misimplementation.

In PAL10 only, ZBLOCK 4000 or more is an error! [Why, just arbitrary and incompatible].

Often I want "clean" core images of the saved results of loading my binary.  This makes it easier to look at octal dumps and if the file ever gets compresses [such as with the Kermit-12 ENCODE/DECODE utilities] the run-length encoding makes the result markedly smaller.

Thus, I cannot use statements such as

*0

ZBLOCK 7600-.

And still be PAL10 compatible.

[There are about a dozen or less features missing or misimplemented in PAL10​

 

​compared to PAL8 and P?S/8 PAL; talk about for want of a nail!]

​

I also see the hack of putting an origin at the starting address last, which 

there was a DECUS self-starting loader or some such that used to encourage.

​No, that's an official [and broken] DEC product.

That's why we added the /0 switch to P?S/8 PAL and the /O switch to PAL8.  I pointed this out and we both fixed it simultaneously.

The bug in the self-starting loader is that a field setting is applied too soon!  They who didn't quite understand how the BIN loader works tried to short-change the buffered 12-bit value.  It's there for two reasons: a) So you can determine you do NOT want to load the checksum [because it turns out it is the checksum] and if a FIELD setting is in tbe binary, it has to have been executed inline as a CDF instruction and then process what is next.

Thus, since they released it and it winds up loading the last word of the previous field erroneously as first word in the new field [!] the fix is to force an automatic *200 after every explicit FIELD directive statement.  [The switches allow you to turn it off, etc.]

On the same subject, there are some nasty programs that ASSUME which version of BIN is loading the tape, and as such patch the BIN loader itself.  If there is no problem, the program has already usurped the loader no longer original code.  If an error, at least some of then restore the original and then JMP to the HLT instruction.

While many use the LBAA release from 1967, there is no guaranty whatsoever that you can do that!  There are at least three DEC implementations of BIN and two P?S/8 ones.  [One of the DEC releases was needed because DECtape came out and running a program that accesses the TC01 hardware breaks the code in BIN.  But this still could be ruined by the DF32 or RF08 and maybe the TC58.  The earlier P?S/8 one was still theoretically prone to destruction loading a TC58 program.  The latest one is 100% bulletproof with regard to 3-cycle data break devices.]  This is why the self-starting loader was written.  Too bad it doesn't fully work.

 ​

 

So as a learning exercise, it was fun - and going back to the "knowing the
word but not the order" idea - things I'm starting to appreciate are
having an "eye" for knowing the size of routines, variable/temp storage
placement

I do see coding the equivalent of 

        for (num=0; num < 1000; num++)

instead of 

        for (num=-1000; num; num++)

which has a much more efficient implementation.

I also try to leave out the NOP after ISZ if I know the ISZ can't skip.

​​

​You can also put a handy ​

 

​constant that looks like an AND instruction after it; then you don't care.

In situations where you KNOW it won't skip, some people define FIXMRI INC=2000

And use that so anyone reading the code knows the intention is to never skip.
​

All the skip OPRs can also be combined with CLA, and often should be.

​
And some are contrived to form needed constants.  You have to learn the art of when you can add superfluous conditions to a skip test that don't change the logic, but form that nice constant you need elsewhere on the page.

The entry point into the P?S/8 system device handler is not some pointless address like 7607. Instead it is 7640.  If you take the trouble to do a little hand optimization, it is totally reasonable that everywhere you need to call the handler you will effectively optimize out the constant 760 needed to point to the handler because generally you can always have or contrive an SZA CLA instruction nearby.

In fact, I use the syntax

JMS I L7640/[SYSIO]

and then another normal / to the nominal comment.  LSYSIO is of course a local SZA CLA instruction.  You of course have to get all of them with each their own,m so on another page it might be P7640 or A7640, etc.  But by eliminating all of them, you can claim it is the logical equivalent of as if you used the page zero literal [without actually having to].

[And of course there are lesser cases where the comment before the comment is a current page literal using the same reasoning with different specifics.

Most situations can be changed from SNA CLA to SPA SNA CLA if you completely know what your code will encounter under all possible circumstances, etc.  But the constant 7750 may be more important than the constant 7650.  [That actually comes up in device handlers.]
​

 

As you point out, those optimizations aren't really important for something 

this simple (except as exercise toward better habits).

​True, and eventually it may be the difference between a working system and useless assembly that violates established rules.
​

 

and maybe wondering if avoiding "links generated" is some form 
of machismo or masochism... Especially as I'm sitting here with palbart on
my PiDP-8 with the ability to do an edit/assemble cycle in seconds rather
than actually feed a real PDP-8 with paper tape and go through the
punch/edit/assemble/run cycle via tape...

I don't think palbart is doing you any favors there.  It makes generated links 

much too easy, in my opinion.  The assembler I use does generate the links, 

but also flags each generated link as an error (like palbart -e).  Generally, it 

is easy enough to change each

        mri foo

into

        mri I (foo)

if that's really the best thing to do about the cross-page reference.  Thinking

about cross-page references is important to writing good PDP-8 code, though, 

when the code gets larger than a page or two.

​

This is probably so important about the time you realize there is extended memory and learn that it is not merely a syntax situation.  The hardware works differently than a generalized usage allowed to be mechanically generated.  Especially when it is not a JMP or JMS type because the data field is dynamic and can come out of seemingly nowhere to break the logic.  Especially when the fledgling programmer is now ​trying to expand a "working" program to work with extended memory considerations.  That way, if you get a new error, you can consider your options and rewrite perhaps.  Just changing to an indirect may literally not work.

From my vantage point, if using "higher-level languages" is sooo much better, then why, to date, NO ONE has gotten a working PDP-8 assembler other than these lame subsets?  In a world with SIMH available, you just don't even need to bother.

cjl

 

    Vince

--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/h7AKaN-hvEI/unsubscribe.

To unsubscribe from this group and all its topics, send an email to pidp-8+unsubscribe@googlegroups.com.

To post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/31aa9572-7bf6-4d7b-8a13-e6b94db11bbb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Paul Birkel]

[PAB] My impression is that our lab arrangement was purchased in 1970 as part of the arrival of the new faculty. It was never formally upgraded; we made do and everyone agreed that providing a decent graduate student stipend was important, too. Zero sum. You were fortunate to start with significantly a more capable system :->.

Using paper-tape would be incredibly frustrating. Fortunately, it
never came to that since I came with the R-L Monitor System, quickly
developed the first generation of real-time and analysis programs.
The limiting factor was the ASR-33 teletype. Fortunately, I also had
access to another machine that had a line-printer on it and could
sneakernet my files to that other machine [both had DECtape]. Within
about 9 months, we were already using P?S/8. Researchers were able to
do their work on the machine [we had to schedule time on the machine;
I mostly used it at night and the entire weekends].

If this had been a paper-tape environment, program development would
be at a snail's pace. I guess that's the difference between a working
hospital where you actuallly have to produce something, as opposed to
just writing research papers that can include in the subject matter a
well-crated complaint about lack of proper tools [so you could get
more grant money].

[PAB] I suppose that observation regarding research papers is true in some environments. We didn't have that luxury as the research involved operant conditioning, which required training sessions 7 days a week for 6-8 weeks (no interruptions!), followed by a week or so break before starting a new test-scenario. Spouses and significant-others were not amused!

[PAB] More memory meant that we could train multiple subjects simultaneously and therefore accumulate data much more quickly. Spouses were definitely more pleased with that concept :->.

[PAB] I was involved in authoring some of those papers, and we never thought of complaining about lack of equipment (personal dreams aside!). The funding constraints were-what-they-were. What we most desired was more training-throughput and better S/N ratio on the bio-amplifiers. The former was accomplished by adding the additional memory to the 8/L to allow for more parallelism in training and then by building more experimental apparatus (and acquiring more test subjects). The latter was improved by shifting to increasingly improved analog ICs coming onto the market at that time. I think that we all would have liked a digital plotter, but we made do with an old analog plotter that we carefully RC-tweaked in order to get good plots of continuous curves (1K sample points) with superimposition that we could then use directly in publications after trimming and post-up.

-----
paul

[Ian Schofield]

Dear All,

 Delighted to read this thread as it echoes even today. Also being a Neurophysiologist (!), I received a hand me down 8/L in 1975 to perform some realtime analysis of ECG. The initial development was using paper-tape and it absolutely concentrates the mind such that you really have to plan the programme and with only 4K, think about the logic in terms of the instruction set. The  8x set and the Von Neuman architecture allow for quite a bit of imaginatve coding. But, using a high level language is so much more convenient and practical provided a dev system in available. As luck would have it an 8/e+RK05 turned up and we switched to FORTRAN II + embedded SABR. At this point, I am a bit torn as to the way things have evolved. 1. I despair about X86! 2. I only love C because the PDP-11 is my favourite machine. The implication of these comments is encapsulated in the attached picture which is part of the single chip PDP8 project but could be anything. Embedded processors have become very complex such that the CPU bit is only a small part of the chip. So, a bit full circle in that programming the peripherals in this AVR chip is a real exercise in logic and that actual app becomes a small element. With this in mind, I would reiterate a thread of this discussion in regard of the fact that a firm understanding of the way the 8x logic works is as relevant today as it always was.

Regards, Ian.

[higgins...@gmail.com]

1. I feel your pain. I think the PDP-11 is the most elegant machine I have ever encountered, but in this day and age, what can you do with 16 bits and 64kb? One has to move on ... As for x86, it's an example of commercial success, not elegance. Somehow it survived the A20 debacle and the floating point debacle, and it still flourishes.

2. There's a pun in their somewhere about neurophysiologists, PDP-8s and brains, but I can't quite put it together :-)

[Gordon Henderson]

On Fri, 6 Oct 2017, Vincent Slyngstad wrote:

> On Friday, October 6, 2017 at 12:01:53 PM UTC-7, Gordon Henderson wrote:
>>
>> What I've done recently is to write my own PDP-8 emulator - primarily with
>> the aim to learn more about the PDP-8 instruction set...
>>
>> ... and what I've ended up with is a good knowledge of the instructions
>> but not how to actually write programs with them...
>>
>
> That's not surprising. It takes some practice to get the hang of using
> them well.
>
>
>> Anyway for your entertainment, a quick stab at a solution can be seen
>> here:
>>
>> http://unicorn.drogon.net/pdp8/e1.pal
>>
>
> Cool! I went
> to https://github.com/pa28/PiDP-8-sim/blob/master/asm/palbart.c
> and got a copy of palbart, since the cross assembler that I am using on my
> PC
> doesn't support the ASCII pseudo-op. Then I was able to assemble your
> code,
> but I got an "undefined" error on the line:
>
> decimal
>
> because that version of palbart doesn't truncate at 6 characters.
>
> Changing the line to
>
> decima
>
> allowed the program to compile (and run) just fine.

Thanks for the feedback.

The version of palbart I'm using is the one included in Warrens
pidp8i-v20170404 distribution - it appears to be

gordon@pidp8:~/pidp8i-v20170404/palbart$ palbart -v
pal-2.13, 03 May 2015

>> Seems to work fine, but prints the answer in Octal (I ought to steal
>> Vincents print decimal code :)
>
> Feel free to improve on it :-). I feel it is actually kind of clunky.

Curiously... many years ago I was asked to write a "print decimal" routine
in 8080 assembler - part of a job interview! (I got the job fwiw)

Looking at the DEC one (12-bit unsigned) - self modifying code. Seems to
be popular in the PDP-8...

> And I know there are code optimisations to be made, coding styles to be
>> critical of, or to marvel at, but it'll do for now.
>
> There's some interesting idiomatic code in there, which suggests you've
> been reading the code of others, since you say this is an early effort for
> you.

I've not really found a lot of well documented source code out there, so
yes, I've looked at various sources - but there's seems to be a few
different styles, etc.

> I see "hlt" used at subroutine entries, for instance, whereas I use ".-."
> sort
> of generically for data whose compile time value is unimportant.

I thought it might be a good idea if I accidentally JMPed to it. Of-course
it gets overwritten on the first go, however...

(And similarly I gave my emulator the ability to fill core with HLTs too,
in-case that helped with some errant jumps - not sure it does, but hey)

> I also see the hack of putting an origin at the starting address last,
> which
> there was a DECUS self-starting loader or some such that used to encourage.

A recent addition to my emulator is a tape loader - mostly because I did
get bored with loading the RIM loader, using that to load the BIN loader
then using that to load a BIN file, so I coded a direct BIN loader -
although I have to do some searching for BIN file format and I eventually
found a document called DEC-8E-XBINA-A-A - "Self-Starting Binary Loader"
which I used - and in there, I noted that if a BIN file had an origin
change instruction immediately before the checksum it was to instruct the
loader to start the code at that address - so I implemneted it in my
loader. That document is dated 1972, so somewhat "late" in terms of PDP-8,
however it was the first thing I found and certianly decodes tapes
correctly. (or at least all the ones I've been able to throw at it - 8K
basic, chess, focal, etc. however most don't have the auto-start trick as
I suspect these programs came before the SS Loader)

There is a lot of documentation out there - it's just a matter of finding
it.

> So as a learning exercise, it was fun - and going back to the "knowing the
>> word but not the order" idea - things I'm starting to appreciate are
>> having an "eye" for knowing the size of routines, variable/temp storage
>> placement
>
> I do see coding the equivalent of
> for (num=0; num < 1000; num++)
> instead of
> for (num=-1000; num; num++)
> which has a much more efficient implementation.
>
> I also try to leave out the NOP after ISZ if I know the ISZ can't skip.

Indeed - I'm used to todays "defensive" programming though and have worked
in places where making assumptions was not allowed. I did think that
simply doubling up the JMP instruction (that's after the skp/nop in a few
of my cases here) might save a cycle in execution speed though.

> All the skip OPRs can also be combined with CLA, and often should be.

A good tip to remember, thanks.

> As you point out, those optimizations aren't really important for
> something this simple (except as exercise toward better habits).
>
> and maybe wondering if avoiding "links generated" is some form
>> of machismo or masochism... Especially as I'm sitting here with palbart on
>> my PiDP-8 with the ability to do an edit/assemble cycle in seconds rather
>> than actually feed a real PDP-8 with paper tape and go through the
>> punch/edit/assemble/run cycle via tape...
>>
>
> I don't think palbart is doing you any favors there. It makes generated
> links
> much too easy, in my opinion. The assembler I use does generate the links,
> but also flags each generated link as an error (like palbart -e).
> Generally, it
> is easy enough to change each
> mri foo
> into
> mri I (foo)
> if that's really the best thing to do about the cross-page reference.
> Thinking
> about cross-page references is important to writing good PDP-8 code,
> though,
> when the code gets larger than a page or two.

Yes - another thing to look into, although I'm all for having the machine
make life easier when it can. Some of this is simply not knowing the
correct assembler syntax. I only picked up the () thing from looking at
someone else's code and then trying to find an assembler manual to work
out what that was doing...

And as I mentioned; having an eye for where things lie in memory, routine
sizes, etc. that just takes time & practice.

Cheers,

Gordon

[CLASystems]

​"Computer scientists" taught many to program ineffectively be declaring that evil.  Even when the architecture required the ability to modify the in-line code, a basic premise of the PDP-8.  Sure, it isn't that easy to put into a ROM if you are a simplistic newbie, but they act like there is some "sacred" line to have been crossed.  [By and large they have no idea what a co-routine is either, so much for their detestably ​educated opinions.]

 

And I know there are code optimisations to be made, coding styles to be

critical of, or to marvel at, but it'll do for now.

There's some interesting idiomatic code in there, which suggests you've
been reading the code of others, since you say this is an early effort for
you.

I've not really found a lot of well documented source code out there, so yes, I've looked at various sources - but there's seems to be a few different styles, etc.

I see "hlt" used at subroutine entries, for instance, whereas I use ".-."
sort
of generically for data whose compile time value is unimportant.

I thought it might be a good idea if I accidentally JMPed to it. Of-course it gets overwritten on the first go, however...

(And similarly I gave my emulator the ability to fill core with HLTs too, in-case that helped with some errant jumps - not sure it does, but hey)

​Thanks.  A standard option of the P?S/8 BIN loader program.  It can also pre-load all of memory with 0000 which for the LINC-8 and PDP-12 is the LINC mode HLT.
​

 

I also see the hack of putting an origin at the starting address last,
which
there was a DECUS self-starting loader or some such that used to encourage.

A recent addition to my emulator is a tape loader - mostly because I did get bored with loading the RIM loader, using that to load the BIN loader then using that to load a BIN file, so I coded a direct BIN loader - although I have to do some searching for BIN file format and I eventually found a document called DEC-8E-XBINA-A-A - "Self-Starting Binary Loader" which I used - and in there, I noted that if a BIN file had an origin change instruction immediately before the checksum it was to instruct the loader to start the code at that address - so I implemneted it in my loader. That document is dated 1972, so somewhat "late" in terms of PDP-8, however it was the first thing I found and certianly decodes tapes correctly. (or at least all the ones I've been able to throw at it - 8K basic, chess, focal, etc. however most don't have the auto-start trick as I suspect these programs came before the SS Loader)

​As I said, a DEC program, not DECUS.  A few words to the wide:  A few errant programs attempted to pre-invent that wheel.  this made them dependent on one particular release of the BIN loader [there's nearly a half dozen].  They patch the loader and when logical end of the tape happens, they pass judgement on the checksum [and maybe restore the loader!] and then self-start.

And this is the official DEC release of the BIN loader that is hopelessly broken and was never fixed.  It will encounter a FIELD setting in the binary and improperly process the word just next to the FIELD directive in the wrong field!

​

 

There is a lot of documentation out there - it's just a matter of finding it.

So as a learning exercise, it was fun - and going back to the "knowing the

word but not the order" idea - things I'm starting to appreciate are
having an "eye" for knowing the size of routines, variable/temp storage
placement

I do see coding the equivalent of
       for (num=0; num < 1000; num++)
instead of
       for (num=-1000; num; num++)
which has a much more efficient implementation.

I also try to leave out the NOP after ISZ if I know the ISZ can't skip.

​You should define FIXMRI INC=2000 for use when you are sure ISZ cannot skip [which is nearly all usage when not uses as a counter].​

​cjl​

 

[Peter Willard]

Why do we keep getting comparisons to vaporware? (referring to P?S/8) That's not very helpful

[CLASystems]

On Mon, Oct 16, 2017 at 11:16 AM, Peter Willard <petew...@gmail.com> wrote:

Why do we keep getting comparisons to vaporware? (referring to P?S/8) That's not very helpful

​Why do we get remarks from the peanut gallery; that's not helpful to anyone.

If you've  been following any relevant discussion you would realize just how inappropriate your insulting remarks are.  [Contrary to ignorant opinion, my work is not a free service to be scheduled at the whim of a bored individual who refers to himself as "we".

cjl [Working every day on the realistic endeavors it takes to support an operating system; we have no entertainment division]
​

 

--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/h7AKaN-hvEI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/52a5d28f-3c97-4ecf-8ee3-0278092a4b48%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

"In the future, OS/2 will be on everyone's desktop"

Bill Gates, 1992

Virus-free. www.avast.com