🚀 go-pugleaf

On 2018-07-13, Stephen M. Jones <mart...@sdf.lonestar.org> wrote:
> Has anyone created a definitive timeline for the PDP-6 monitor that 
> became  TOPS-10 as well as showing modifications that Tymshare, SAIl,
> Compuserve and others made to the code?
>
> Does version 2.18 exist? Is 4.5 sources the earliest out there at the
> moment?  

Earth calling /BAH


-- 
greymaus.ireland.ie
Will Rant for Food.

On 14/07/2018 07:51, ma...@mail.com wrote:
> On 2018-07-13, Stephen M. Jones <mart...@sdf.lonestar.org> wrote:
>> Has anyone created a definitive timeline for the PDP-6 monitor that
>> became  TOPS-10 as well as showing modifications that Tymshare, SAIl,
>> Compuserve and others made to the code?
>>
>> Does version 2.18 exist? Is 4.5 sources the earliest out there at the
>> moment?
> 
> Earth calling /BAH
> 
> 

One tended to be overawed by the PDP10 series, but I wonder if
its operating systems would seem rather infra dig compared to Linux
today?

On 2018-07-14, Gareth's Downstairs Computer <headstone255.but.n...@yahoo.com> wrote:
> On 14/07/2018 07:51, ma...@mail.com wrote:
>> On 2018-07-13, Stephen M. Jones <mart...@sdf.lonestar.org> wrote:
>>> Has anyone created a definitive timeline for the PDP-6 monitor that
>>> became  TOPS-10 as well as showing modifications that Tymshare, SAIl,
>>> Compuserve and others made to the code?
>>>
>>> Does version 2.18 exist? Is 4.5 sources the earliest out there at the
>>> moment?
>> 
>> Earth calling /BAH
>> 
>> 
>
> One tended to be overawed by the PDP10 series, but I wonder if
> its operating systems would seem rather infra dig compared to Linux
> today?
>

It wwould have been upgraded too. (never, (knowingly) used it.)


-- 
greymaus.ireland.ie
Will Rant for Food.

In article <picc8e$360$2...@dont-email.me> you write:
>One tended to be overawed by the PDP10 series, but I wonder if
>its operating systems would seem rather infra dig compared to Linux
>today?

In terms of number of features, linux wins by a parsec.

In terms of getting useful work out of a computer that ran at about
5MHz (yes, I know the KA was async) and had 1MB of core, TOPS-10 wins
just as much.  It had features that mattered then but don't any more
like doing disk I/O directly in and out of buffers in user space
without an extra copy.  I could have done without the sequence numbers
with the flag in the low bit of the word, though.

Of course, even TOPS-10 was a pig compared to DTSS which ran on a GE
635, about the same speed as a KA-10, with a very slow front end
terminal mux (sort of like a 680) and provided good performance to 100
users.




-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 2018-07-14 16:45, John Levine wrote:
> In article <picc8e$360$2...@dont-email.me> you write:
>> One tended to be overawed by the PDP10 series, but I wonder if
>> its operating systems would seem rather infra dig compared to Linux
>> today?
> 
> In terms of number of features, linux wins by a parsec.

Not so sure. If we talk about the OS as such, there are a couple of 
things Linux has that TOPS-20 don't. But that is true in the other 
direction as well.

Now, if you instead were to talk about useful applications, then sure, 
Linux have way more of that.

> In terms of getting useful work out of a computer that ran at about
> 5MHz (yes, I know the KA was async) and had 1MB of core, TOPS-10 wins
> just as much.  It had features that mattered then but don't any more
> like doing disk I/O directly in and out of buffers in user space
> without an extra copy.  I could have done without the sequence numbers
> with the flag in the low bit of the word, though.

Disk directly to buffers in user space in Linux? Sure, it's called mmap. 
Which, by the way, is more or less a direct ripoff from TOPS-20.

> Of course, even TOPS-10 was a pig compared to DTSS which ran on a GE
> 635, about the same speed as a KA-10, with a very slow front end
> terminal mux (sort of like a 680) and provided good performance to 100
> users.

One of the more interesting features I remember from Tops-10 was that 
you could have a daemon that kicked in when files were accessed that you 
did not have access rights to. And that went though a script, which 
could modify the rules for access to the file arbitrarily. I remember it 
being very cool, and I don't know of anything similar today.

   Johnny

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

John Levine <jo...@taugh.com> Wrote in message:
> 
> I could have done without the sequence numbers
> with the flag in the low bit of the word, though.

That was a convention of some apps, eg BASIC and the line editor
 whose name I can't remember. TOPS-10 neither new or
 cared.

> Of course, even TOPS-10 was a pig compared to DTSS which ran on a GE
> 635, about the same speed as a KA-10, with a very slow front end
> terminal mux (sort of like a 680) and provided good performance to 100
> users.

The 635 was a piece of junk, but it was much faster than the KA.
 And the campus environment was very forgiving. We got good
 performance with 40 users on the 265; twice what it could manage
 in commercial environments. Dartmouth users were doing simpler
 things. And they could sit and think because they didn't get
 bills.

Comparing the Datanet 30 to a 680 is an arcane argument that I'm
 not qualified to get into.


Sarr

-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On 2018-07-14 21:45, Sarr Blumson wrote:
> John Levine <jo...@taugh.com> Wrote in message:
>>
>> I could have done without the sequence numbers
>> with the flag in the low bit of the word, though.
> 
> That was a convention of some apps, eg BASIC and the line editor
>   whose name I can't remember. TOPS-10 neither new or
>   cared.

The line numbers in BASIC I think was separate from this, but I might be 
mistaken.
The editor was most certainly SOS.

   Johnny

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

In article <pidjtj$mh2$1...@dont-email.me>,
Sarr Blumson  <sarr.blumson@alum.dartmouth.orgq> wrote:
>The 635 was a piece of junk, but it was much faster than the KA.

Really?  They were both 36 bit machines with memory with about a 1us
cycle time.  For most instructions the memory was the limiting thing.

> And the campus environment was very forgiving.

Partly that, partly DTSS was designed more like a transaction monitor
than a timesharing system.  User input was buffered in a the
transaction monitor which I think was called SIMON until the user
typed a command (as opposed to a program line that started with a
digit), then it started whatever program handled the input and ran it.


>Comparing the Datanet 30 to a 680 is an arcane argument that I'm
> not qualified to get into.

They did the same thing, sweep a lot of one-bit tty interfaces and
assemble and disassemble characters in real time.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Sat, 14 Jul 2018 21:22:17 +0200, Johnny Billquist wrote:

> Disk directly to buffers in user space in Linux? Sure, it's called mmap.
> Which, by the way, is more or less a direct ripoff from TOPS-20.

Which was a ripoff from MULTICS and EMAS.

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

Johnny Billquist  <b...@softjar.se> wrote:
+---------------
| John Levine wrote:
| > In terms of getting useful work out of a computer that ran at about
| > 5MHz (yes, I know the KA was async) and had 1MB of core, TOPS-10 wins
| > just as much.  It had features that mattered then but don't any more
| > like doing disk I/O directly in and out of buffers in user space
| > without an extra copy.  I could have done without the sequence numbers
| > with the flag in the low bit of the word, though.
| 
| Disk directly to buffers in user space in Linux? Sure, it's called mmap. 
| Which, by the way, is more or less a direct ripoff from TOPS-20.
+---------------

Actually, TOPS-10 user-space buffered I/O was closer to Linux/Unix's
DIRECT_IO mode than to mmap(), except it was naturally multi-buffered.

That is, you had a *ring* of user-space buffers, with ownership flags
so both the kernel and the user program could see who was working
on a given buffer. This quite naturally allowed kernel I/O and the
user program to work asynchronously, as long as neither side caught
up to the portion of the ring owned by the other side. [And if that
happens, the faster side simply stopped until there was a free (or full)
buffer available for it.]

Plus, you could have *multiple* devices sharing the same user-space
buffer ring, such as disk I/O and magtape I/O, allowing the data to
be streamed continuously from one device through the buffers to the
other device. [In this case the ring was paritioned into *four* areas:
device #1, user area #1, device #2, user area #2.] This is how the
BACKUP program managed to keep the magtapes writing at full speed
[if you had fast-enough disks].


-Rob

-----
Rob Warnock		<rp...@rpw3.org>
627 26th Avenue		<http://rpw3.org/>
San Mateo, CA 94403

On 2018-07-15 01:59, Bob Eager wrote:
> On Sat, 14 Jul 2018 21:22:17 +0200, Johnny Billquist wrote:
> 
>> Disk directly to buffers in user space in Linux? Sure, it's called mmap.
>> Which, by the way, is more or less a direct ripoff from TOPS-20.
> 
> Which was a ripoff from MULTICS and EMAS.

I'm not sure about that. Multics, from what I read, considered memory 
and files to be the same thing. This is sort of a different idea than 
saying that you can map a file into a specific part of your memory. I 
have no idea how or what EMAS is. :-)

But the comment about the ripoff goes as far as the Unix mmap API being 
pretty much a copy of TOPS-20.

   Johnny

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

On 2018-07-15 08:37, Rob Warnock wrote:
> Johnny Billquist  <b...@softjar.se> wrote:
> +---------------
> | John Levine wrote:
> | > In terms of getting useful work out of a computer that ran at about
> | > 5MHz (yes, I know the KA was async) and had 1MB of core, TOPS-10 wins
> | > just as much.  It had features that mattered then but don't any more
> | > like doing disk I/O directly in and out of buffers in user space
> | > without an extra copy.  I could have done without the sequence numbers
> | > with the flag in the low bit of the word, though.
> |
> | Disk directly to buffers in user space in Linux? Sure, it's called mmap.
> | Which, by the way, is more or less a direct ripoff from TOPS-20.
> +---------------
> 
> Actually, TOPS-10 user-space buffered I/O was closer to Linux/Unix's
> DIRECT_IO mode than to mmap(), except it was naturally multi-buffered.

You are most probably absolutely right. But I talked about Tops-20, not 
TOPS-10. :-)

   Johnny

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

On 2018-07-15 12:03, Huge wrote:
> On 2018-07-15, Johnny Billquist <b...@softjar.se> wrote:
>> On 2018-07-15 01:59, Bob Eager wrote:
>>> On Sat, 14 Jul 2018 21:22:17 +0200, Johnny Billquist wrote:
>>>
>>>> Disk directly to buffers in user space in Linux? Sure, it's called mmap.
>>>> Which, by the way, is more or less a direct ripoff from TOPS-20.
>>>
>>> Which was a ripoff from MULTICS and EMAS.
>>
>> I'm not sure about that. Multics, from what I read, considered memory
>> and files to be the same thing. This is sort of a different idea than
>> saying that you can map a file into a specific part of your memory. I
>> have no idea how or what EMAS is. :-)
>>
>> But the comment about the ripoff goes as far as the Unix mmap API being
>> pretty much a copy of TOPS-20.
> 
> I find the word "ripoff" problematical. Virtually everything in computer
> science is based on something else. Thinking "that's a good idea" and
> re-using it in a new and interesting way is hardly "ripping off".

If you take the concept *and* API and copy it verbatim, I think calling 
it a ripoff is not so wrong.
Had they just taken the concept, then I'd say inspired by, or something 
similar. But this one goes a bit further. I remember back when Sun 
introduced mmap, that I heard (don't remember from where), that they had 
looked at TOPS-20 when they did the implementation for SunOS.

   Johnny

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

On 2018-07-15 12:17, Johnny Billquist wrote:
> On 2018-07-15 12:03, Huge wrote:
>> On 2018-07-15, Johnny Billquist <b...@softjar.se> wrote:
>>> On 2018-07-15 01:59, Bob Eager wrote:
>>>> On Sat, 14 Jul 2018 21:22:17 +0200, Johnny Billquist wrote:
>>>>
>>>>> Disk directly to buffers in user space in Linux? Sure, it's called 
>>>>> mmap.
>>>>> Which, by the way, is more or less a direct ripoff from TOPS-20.
>>>>
>>>> Which was a ripoff from MULTICS and EMAS.
>>>
>>> I'm not sure about that. Multics, from what I read, considered memory
>>> and files to be the same thing. This is sort of a different idea than
>>> saying that you can map a file into a specific part of your memory. I
>>> have no idea how or what EMAS is. :-)
>>>
>>> But the comment about the ripoff goes as far as the Unix mmap API being
>>> pretty much a copy of TOPS-20.
>>
>> I find the word "ripoff" problematical. Virtually everything in computer
>> science is based on something else. Thinking "that's a good idea" and
>> re-using it in a new and interesting way is hardly "ripping off".
> 
> If you take the concept *and* API and copy it verbatim, I think calling 
> it a ripoff is not so wrong.
> Had they just taken the concept, then I'd say inspired by, or something 
> similar. But this one goes a bit further. I remember back when Sun 
> introduced mmap, that I heard (don't remember from where), that they had 
> looked at TOPS-20 when they did the implementation for SunOS.

I should probably modify my language.
For many, "verbatim" is probably hard to justify here. After all, the 
TOPS-20 PMAP% system call is an API from assembly language, while the 
Unix mmap() system call is an API from C.

Also, PMAP% have some additional features and functions that mmap() does 
not.
mmap() is maybe more properly described as a subset of PMAP% in one way.

But mmap() is essentially exactly the same as PMAP%.

   Johnny

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

In article <pieq2s$ctl$1...@dont-email.me>, Rob Warnock <rp...@rpw3.org> wrote:
>Actually, TOPS-10 user-space buffered I/O was closer to Linux/Unix's
>DIRECT_IO mode than to mmap(), except it was naturally multi-buffered.
>
>That is, you had a *ring* of user-space buffers, with ownership flags
>so both the kernel and the user program could see who was working
>on a given buffer. This quite naturally allowed kernel I/O and the
>user program to work asynchronously, as long as neither side caught
>up to the portion of the ring owned by the other side. [And if that
>happens, the faster side simply stopped until there was a free (or full)
>buffer available for it.]

OS/360 QSAM worked pretty much the same way, device I/O in and out of
a ring of user space buffers.  This shows up in the PL/I LOCATE mode
for file I/O, where it gives you a pointer to the record it just read
or that you are about to write.

I suppose it still does in z/OS although these days it's likely all
faked with copies from memory mapped buffers since modern disks don't
have variable sized records like CKD disks did.

R's,
John
-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

In article <pif63v$4av$2...@Iltempo.Update.UU.SE>,
>You are most probably absolutely right. But I talked about Tops-20, not 
>TOPS-10. :-)

How many ways can there be to say that this block of memory corresponds to
that file, and use the pager to move it back and forth?

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

In article <pidigf$p59$1...@Iltempo.Update.UU.SE>,
Johnny Billquist  <b...@softjar.se> wrote:
>On 2018-07-14 16:45, John Levine wrote:
>> In article <picc8e$360$2...@dont-email.me> you write:
>>> One tended to be overawed by the PDP10 series, but I wonder if
>>> its operating systems would seem rather infra dig compared to Linux
>>> today?
>> 
>> In terms of number of features, linux wins by a parsec.
>
>Not so sure. If we talk about the OS as such, there are a couple of 
>things Linux has that TOPS-20 don't. But that is true in the other 
>direction as well.
>
>Now, if you instead were to talk about useful applications, then sure, 
>Linux have way more of that.
>
>> In terms of getting useful work out of a computer that ran at about
>> 5MHz (yes, I know the KA was async) and had 1MB of core, TOPS-10 wins
>> just as much.  It had features that mattered then but don't any more
>> like doing disk I/O directly in and out of buffers in user space
>> without an extra copy.  I could have done without the sequence numbers
>> with the flag in the low bit of the word, though.
>
>Disk directly to buffers in user space in Linux? Sure, it's called mmap. 
>Which, by the way, is more or less a direct ripoff from TOPS-20.
>
>> Of course, even TOPS-10 was a pig compared to DTSS which ran on a GE
>> 635, about the same speed as a KA-10, with a very slow front end
>> terminal mux (sort of like a 680) and provided good performance to 100
>> users.
>
>One of the more interesting features I remember from Tops-10 was that 
>you could have a daemon that kicked in when files were accessed that you 
>did not have access rights to. And that went though a script, which 
>could modify the rules for access to the file arbitrarily. I remember it 
>being very cool, and I don't know of anything similar today.

[smw] You are talking about FILDAE (file daemon.)  See the TOPS-10
Operating System Commands manual for more information.

Sam

On 15/07/2018 11:03, Huge wrote:
> 
> I find the word "ripoff" problematical. Virtually everything in computer
> science is based on something else. Thinking "that's a good idea" and
> re-using it in a new and interesting way is hardly "ripping off".
> 

ISTR that it was Isaac Newton who said that we stand on the shoulders
of giants.

Johnny Billquist <b...@softjar.se> wrote:
> On 2018-07-15 12:17, Johnny Billquist wrote:
>> On 2018-07-15 12:03, Huge wrote:
>>> On 2018-07-15, Johnny Billquist <b...@softjar.se> wrote:
>>>> On 2018-07-15 01:59, Bob Eager wrote:
>>>>> On Sat, 14 Jul 2018 21:22:17 +0200, Johnny Billquist wrote:
>>>>> 
>>>>>> Disk directly to buffers in user space in Linux? Sure, it's called 
>>>>>> mmap.
>>>>>> Which, by the way, is more or less a direct ripoff from TOPS-20.
>>>>> 
>>>>> Which was a ripoff from MULTICS and EMAS.
>>>> 
>>>> I'm not sure about that. Multics, from what I read, considered memory
>>>> and files to be the same thing. This is sort of a different idea than
>>>> saying that you can map a file into a specific part of your memory. I
>>>> have no idea how or what EMAS is. :-)
>>>> 
>>>> But the comment about the ripoff goes as far as the Unix mmap API being
>>>> pretty much a copy of TOPS-20.
>>> 
>>> I find the word "ripoff" problematical. Virtually everything in computer
>>> science is based on something else. Thinking "that's a good idea" and
>>> re-using it in a new and interesting way is hardly "ripping off".
>> 
>> If you take the concept *and* API and copy it verbatim, I think calling 
>> it a ripoff is not so wrong.
>> Had they just taken the concept, then I'd say inspired by, or something 
>> similar. But this one goes a bit further. I remember back when Sun 
>> introduced mmap, that I heard (don't remember from where), that they had 
>> looked at TOPS-20 when they did the implementation for SunOS.
> 
> I should probably modify my language.
> For many, "verbatim" is probably hard to justify here. After all, the 
> TOPS-20 PMAP% system call is an API from assembly language, while the 
> Unix mmap() system call is an API from C.

Which, I believe, is just a wrapper for the corresponding Linux SYSCALL.


-- 
Pete

Gareth's Downstairs Computer
<headstone255.but.n...@yahoo.com> wrote:
> On 15/07/2018 11:03, Huge wrote:
>> 
>> I find the word "ripoff" problematical. Virtually everything in computer
>> science is based on something else. Thinking "that's a good idea" and
>> re-using it in a new and interesting way is hardly "ripping off".
>> 
> 
> ISTR that it was Isaac Newton who said that we stand on the shoulders
> of giants.
> 

Or, midgets are standing on my shoulders.

-- 
Pete

On 2018-07-15 21:00, Peter Flass wrote:
> Johnny Billquist <b...@softjar.se> wrote:
>> On 2018-07-15 12:17, Johnny Billquist wrote:
>>> On 2018-07-15 12:03, Huge wrote:
>>>> On 2018-07-15, Johnny Billquist <b...@softjar.se> wrote:
>>>>> On 2018-07-15 01:59, Bob Eager wrote:
>>>>>> On Sat, 14 Jul 2018 21:22:17 +0200, Johnny Billquist wrote:
>>>>>>
>>>>>>> Disk directly to buffers in user space in Linux? Sure, it's called
>>>>>>> mmap.
>>>>>>> Which, by the way, is more or less a direct ripoff from TOPS-20.
>>>>>>
>>>>>> Which was a ripoff from MULTICS and EMAS.
>>>>>
>>>>> I'm not sure about that. Multics, from what I read, considered memory
>>>>> and files to be the same thing. This is sort of a different idea than
>>>>> saying that you can map a file into a specific part of your memory. I
>>>>> have no idea how or what EMAS is. :-)
>>>>>
>>>>> But the comment about the ripoff goes as far as the Unix mmap API being
>>>>> pretty much a copy of TOPS-20.
>>>>
>>>> I find the word "ripoff" problematical. Virtually everything in computer
>>>> science is based on something else. Thinking "that's a good idea" and
>>>> re-using it in a new and interesting way is hardly "ripping off".
>>>
>>> If you take the concept *and* API and copy it verbatim, I think calling
>>> it a ripoff is not so wrong.
>>> Had they just taken the concept, then I'd say inspired by, or something
>>> similar. But this one goes a bit further. I remember back when Sun
>>> introduced mmap, that I heard (don't remember from where), that they had
>>> looked at TOPS-20 when they did the implementation for SunOS.
>>
>> I should probably modify my language.
>> For many, "verbatim" is probably hard to justify here. After all, the
>> TOPS-20 PMAP% system call is an API from assembly language, while the
>> Unix mmap() system call is an API from C.
> 
> Which, I believe, is just a wrapper for the corresponding Linux SYSCALL.

Oh, sure. But I guess it does appear different in the details from the 
TOPS-20 system call, so "verbatim" can be viewed as incorrect.
After all, the system calls in TOPS-20 places the arguments in AC1-AC4, 
while I think Linux places them on the stack, for example. But it's 
essentially only different at that level.

   Johnny

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

On 2018-07-15 14:58, John Levine wrote:
> In article <pif63v$4av$2...@Iltempo.Update.UU.SE>,
>> You are most probably absolutely right. But I talked about Tops-20, not
>> TOPS-10. :-)
> 
> How many ways can there be to say that this block of memory corresponds to
> that file, and use the pager to move it back and forth?

Not sure. But I know many systems don't even have the concept. And on 
some systems transfers to/from files are done through system calls with 
DMA running directly to user buffers without going through the whole VM 
system, which might be argued is even more efficient.
So, even the idea to use the VM subsystem for file access is not 
something that is that universal.

And then you have the question of details of implementation and API. I 
bet there might be some creative solutions out there, if you start 
searching.

   Johnny

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

On 2018-07-15 19:20, Sam Weiner wrote:
> In article <pidigf$p59$1...@Iltempo.Update.UU.SE>,
> Johnny Billquist  <b...@softjar.se> wrote:
>> One of the more interesting features I remember from Tops-10 was that
>> you could have a daemon that kicked in when files were accessed that you
>> did not have access rights to. And that went though a script, which
>> could modify the rules for access to the file arbitrarily. I remember it
>> being very cool, and I don't know of anything similar today.
> 
> [smw] You are talking about FILDAE (file daemon.)  See the TOPS-10
> Operating System Commands manual for more information.

Right! The name was escaping me. Thanks for reminding. It was a very 
cool feature, me brain keeps telling me. But oh so long ago now since I 
even touched Tops-10.

   Johnny

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

On 2018-07-15, Peter Flass <peter...@yahoo.com> wrote:
> Gareth's Downstairs Computer
><headstone255.but.n...@yahoo.com> wrote:
>> On 15/07/2018 11:03, Huge wrote:
>>> 
>>> I find the word "ripoff" problematical. Virtually everything in computer
>>> science is based on something else. Thinking "that's a good idea" and
>>> re-using it in a new and interesting way is hardly "ripping off".
>>> 
>> 
>> ISTR that it was Isaac Newton who said that we stand on the shoulders
>> of giants.
>> 
>
> Or, midgets are standing on my shoulders.
>

Hey, good!.. Newton was also an alchemist. 



-- 
greymaus.ireland.ie
Will Rant for Food.

On 15/07/2018 20:00, Peter Flass wrote:
> Gareth's Downstairs Computer
> <headstone255.but.n...@yahoo.com> wrote:
>> On 15/07/2018 11:03, Huge wrote:
>>>
>>> I find the word "ripoff" problematical. Virtually everything in computer
>>> science is based on something else. Thinking "that's a good idea" and
>>> re-using it in a new and interesting way is hardly "ripping off".
>>>
>>
>> ISTR that it was Isaac Newton who said that we stand on the shoulders
>> of giants.
>>
> 
> Or, midgets are standing on my shoulders.
> 

Larger fleas have smaller fleas
Upon their backs to bite 'em.
Smaller fleas have lesser fleas,
And so ad infinitum.

John Levine <jo...@taugh.com> writes:
> OS/360 QSAM worked pretty much the same way, device I/O in and out of
> a ring of user space buffers.  This shows up in the PL/I LOCATE mode
> for file I/O, where it gives you a pointer to the record it just read
> or that you are about to write.
>
> I suppose it still does in z/OS although these days it's likely all
> faked with copies from memory mapped buffers since modern disks don't
> have variable sized records like CKD disks did.

z/OS still requires CKD disks ... even tho they haven't been made for
decades, emulated (out in the hardware, not back in the system software)
on industry standard fixed block disks. Array/disk controllers have CKD
configuration setups as to simulated disks specified as some variation
on 3380CKD and/or 3390CKD ... simulate 3380 or 3390 track size, simulate
3380 or 3390 tracks per cylinder ... but are allowed to specify number
of cylinders (from much less than any real 3380/3390 to significantly
more than any real 3380/3390).

Even when there were real disks that claimed to be CKD ... there were
already moving to fixed-sized cells (as part of CRC) and number of
records/track calculations included rouding record size up to cell size.

significantly cutting storage requirements, os/360 i/o applications
libraries included building channel programs in user space ...  and then
passing pointer to the (application built) channel program via
EXCP/SVC0. when os/360 moved to virtual memory, EXCP processing faced
the same problem that virtual machine cp67/vm370 faced ... channel
programs required real addresses ... and the application channel
programs were all virtual addresses. The initial OS360 EXCP
implementation for virtual memory borrowed CP67's CCWTRANS which builds
copy of the passed channel program, substituting real addresses for the
virtaul (and some fiddling when buffer crosses non-contiguous page
boundary).

-- 
virtualization experience starting Jan1968, online at home since Mar1970

On Fri, 13 Jul 2018 21:32:56 +0000 (UTC), mart...@sdf.lonestar.org (Stephen M.
Jones) wrote:
>Has anyone created a definitive timeline for the PDP-6 monitor that 
>became  TOPS-10 as well as showing modifications that Tymshare, SAIl,
>Compuserve and others made to the code?

You might want to narrow your target.  TOPS-10 was shipped with complete
sources, and nearly every site, including inside DEC, made modifications -- some
minor, some major.  You'd have to start a separate code fork for nearly every
TOPS-10 machine ever sold.  Most, if not all of those changes were probably lost
when the machines were scrapped, as they were the property of the companies
that bought those systems.


>Does version 2.18 exist? Is 4.5 sources the earliest out there at the
>moment?  

On 14 Jul 2018 06:51:12 GMT, ma...@mail.com wrote:
>On 2018-07-13, Stephen M. Jones <mart...@sdf.lonestar.org> wrote:
>> Has anyone created a definitive timeline for the PDP-6 monitor that 
>> became  TOPS-10 as well as showing modifications that Tymshare, SAIl,
>> Compuserve and others made to the code?
>>
>> Does version 2.18 exist? Is 4.5 sources the earliest out there at the
>> moment?  
>
>Earth calling /BAH

Don't overestimate her knowledge.  She wasn't around for the first few years of
TOPS-10, and she would know little or nothing about the changes customers made
to their systems.

On Sat, 14 Jul 2018 21:22:17 +0200, Johnny Billquist <b...@softjar.se> wrote:
>One of the more interesting features I remember from Tops-10 was that 
>you could have a daemon that kicked in when files were accessed that you 
>did not have access rights to. And that went though a script, which 
>could modify the rules for access to the file arbitrarily. I remember it 
>being very cool, and I don't know of anything similar today.

The file daemon (FILDAE).  That was an add-on that was bolted onto TOPS-10
later.  It was possible, through injudicious settings in the control file
(ACCESS.USR?), to deny even a privileged user access to a file, including
ACCESS.USR.  If you painted yourself into that corner, the only way out was to
either kill FILDAE or directly edit the file protection codes on disk.

Johnny Billquist <b...@softjar.se> writes:

> On 2018-07-15 12:17, Johnny Billquist wrote:
>> On 2018-07-15 12:03, Huge wrote:
>>> On 2018-07-15, Johnny Billquist <b...@softjar.se> wrote:
>>>> On 2018-07-15 01:59, Bob Eager wrote:
>>>>> On Sat, 14 Jul 2018 21:22:17 +0200, Johnny Billquist wrote:
>>>>>
>>>>>> Disk directly to buffers in user space in Linux? Sure, it's
>>>>>> called mmap.
>>>>>> Which, by the way, is more or less a direct ripoff from TOPS-20.
>>>>>
>>>>> Which was a ripoff from MULTICS and EMAS.
>>>>
>>>> I'm not sure about that. Multics, from what I read, considered memory
>>>> and files to be the same thing. This is sort of a different idea than
>>>> saying that you can map a file into a specific part of your memory. I
>>>> have no idea how or what EMAS is. :-)
>>>>
>>>> But the comment about the ripoff goes as far as the Unix mmap API being
>>>> pretty much a copy of TOPS-20.
>>>
>>> I find the word "ripoff" problematical. Virtually everything in computer
>>> science is based on something else. Thinking "that's a good idea" and
>>> re-using it in a new and interesting way is hardly "ripping off".
>>
>> If you take the concept *and* API and copy it verbatim, I think
>> calling it a ripoff is not so wrong.
>> Had they just taken the concept, then I'd say inspired by, or
>> something similar. But this one goes a bit further. I remember back
>> when Sun introduced mmap, that I heard (don't remember from where),
>> that they had looked at TOPS-20 when they did the implementation for
>> SunOS.
>
> I should probably modify my language.
> For many, "verbatim" is probably hard to justify here. After all, the
> TOPS-20 PMAP% system call is an API from assembly language, while the
> Unix mmap() system call is an API from C.
>
> Also, PMAP% have some additional features and functions that mmap()
> does not.
> mmap() is maybe more properly described as a subset of PMAP% in one way.
>
> But mmap() is essentially exactly the same as PMAP%.

This may be due to my lack of experience (pretty much all I've ever
programmed for once past toy student projects has been either Unix
derivatives or bare metal) and imagination, but I'm having a hard time
imagining an API for an mmap()-like function that looks substantially
different from mmap().

Questor <usenet@only.tnx> wrote:
> On Fri, 13 Jul 2018 21:32:56 +0000 (UTC), mart...@sdf.lonestar.org (Stephen M.
> Jones) wrote:
>> Has anyone created a definitive timeline for the PDP-6 monitor that 
>> became  TOPS-10 as well as showing modifications that Tymshare, SAIl,
>> Compuserve and others made to the code?
> 
> You might want to narrow your target.  TOPS-10 was shipped with complete
> sources, and nearly every site, including inside DEC, made modifications -- some
> minor, some major.  You'd have to start a separate code fork for nearly every
> TOPS-10 machine ever sold.  Most, if not all of those changes were probably lost
> when the machines were scrapped, as they were the property of the companies
> that bought those systems.
> 
> 
>> Does version 2.18 exist? Is 4.5 sources the earliest out there at the
>> moment?  
> 
> 

Wouldn't many of these made it onto the DECUS tape?

-- 
Pete

John Levine <jo...@taugh.com> writes:
>In article <pieq2s$ctl$1...@dont-email.me>, Rob Warnock <rp...@rpw3.org> wrote:
>>Actually, TOPS-10 user-space buffered I/O was closer to Linux/Unix's
>>DIRECT_IO mode than to mmap(), except it was naturally multi-buffered.
>>
>>That is, you had a *ring* of user-space buffers, with ownership flags
>>so both the kernel and the user program could see who was working
>>on a given buffer. This quite naturally allowed kernel I/O and the
>>user program to work asynchronously, as long as neither side caught
>>up to the portion of the ring owned by the other side. [And if that
>>happens, the faster side simply stopped until there was a free (or full)
>>buffer available for it.]
>
>OS/360 QSAM worked pretty much the same way, device I/O in and out of
>a ring of user space buffers. 

Burroughs MCP I/O worked the same way, where the user-space buffers were
sized for one block (record size * records-per-block).   The application
code (generated by the compiler) handled the unblocking/blocking.

On 2018-07-15, Gareth's Downstairs Computer
<headstone255.but.n...@yahoo.com> wrote:

> On 15/07/2018 11:03, Huge wrote:
> 
>> I find the word "ripoff" problematical. Virtually everything in computer
>> science is based on something else. Thinking "that's a good idea" and
>> re-using it in a new and interesting way is hardly "ripping off".
>
> ISTR that it was Isaac Newton who said that we stand on the shoulders
> of giants.

"If I haven't seen farther, it's because I'm standing in the footprints
of giants."

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

On Saturday, July 14, 2018 at 8:45:41 AM UTC-6, John Levine wrote:

> Of course, even TOPS-10 was a pig compared to DTSS which ran on a GE
> 635,

Whereas, these days, OS/360, considered to be a pig in its day, is lean and mean 
compared to Windows.

I suppose that if the software on our computers was actually efficient, too many 
people would be building H-bombs in their backyards or something.

John Savard

On Mon, 16 Jul 2018 06:12:29 -0400, Peter Flass <peter...@yahoo.com> wrote:
>Questor <usenet@only.tnx> wrote:
>> On Fri, 13 Jul 2018 21:32:56 +0000 (UTC), mart...@sdf.lonestar.org (Stephen M.
>> Jones) wrote:
>>> Has anyone created a definitive timeline for the PDP-6 monitor that 
>>> became  TOPS-10 as well as showing modifications that Tymshare, SAIl,
>>> Compuserve and others made to the code?
>> 
>> You might want to narrow your target.  TOPS-10 was shipped with complete
>> sources, and nearly every site, including inside DEC, made modifications -- some
>> minor, some major.  You'd have to start a separate code fork for nearly every
>> TOPS-10 machine ever sold.  Most, if not all of those changes were probably lost
>> when the machines were scrapped, as they were the property of the companies
>> that bought those systems.
>> 
>>> Does version 2.18 exist? Is 4.5 sources the earliest out there at the
>>> moment?  
>> 
>
>Wouldn't many of these made it onto the DECUS tape?

I think you mean "a" DECUS tape, since AFAIK there isn't "the" DECUS tape.

I can't speak authoritatively on every turn in DECUS history, but generally it
was a way for customers to share software/tools with each other, and perhaps for
DEC to give away some unsupported extras.  The official, supported release
software, even for older superceded versions, would not have been distributed
through DECUS.

On Mon, 16 Jul 2018 11:34:02 -0700 (PDT)
Quadibloc <jsa...@ecn.ab.ca> wrote:

> I suppose that if the software on our computers was actually efficient,
> too many people would be building H-bombs in their backyards or something.

	Probably not, but people wouldn't buy so many new computers in
search of something fast enough to type a letter on.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

John Levine <jo...@taugh.com> Wrote in message:
> In article <pidjtj$mh2$1...@dont-email.me>,
> Sarr Blumson  <sarr.blumson@alum.dartmouth.orgq> wrote:
>>The 635 was a piece of junk, but it was much faster than the KA.

Well the 635 had 72 bit internal data paths and could actually
 overlap pairs of instructions. Which is why "repeat double"
 worked. But the main difference was that it had a real mainframe
 IO structure. The KAs was cheap and made it easy to attach home
 built stuff. Which was the market DEC was in before they got the
 idea they were competing with IBM.

sarr


-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

Gareth's Downstairs Computer   <headstone255.but.n...@yahoo.com> writes:

> On 15/07/2018 20:00, Peter Flass wrote:
>> Gareth's Downstairs Computer
>> <headstone255.but.n...@yahoo.com> wrote:
>>> On 15/07/2018 11:03, Huge wrote:

>>>> I find the word "ripoff" problematical. Virtually everything in computer
>>>> science is based on something else. Thinking "that's a good idea" and
>>>> re-using it in a new and interesting way is hardly "ripping off".

>>> ISTR that it was Isaac Newton who said that we stand on the shoulders
>>> of giants.

>> Or, midgets are standing on my shoulders.

> Larger fleas have smaller fleas
> Upon their backs to bite 'em.
> Smaller fleas have lesser fleas,
> And so ad infinitum.

Swift.

IIRC.

-- 
Rich Alderson					  ne...@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

On 17 Jul 2018 16:11:11 -0400
Rich Alderson <ne...@alderson.users.panix.com> wrote:

> Gareth's Downstairs Computer
> <headstone255.but.n...@yahoo.com> writes:
> 
> > On 15/07/2018 20:00, Peter Flass wrote:
> >> Gareth's Downstairs Computer
> >> <headstone255.but.n...@yahoo.com> wrote:
> >>> On 15/07/2018 11:03, Huge wrote:
> 
> >>>> I find the word "ripoff" problematical. Virtually everything in
> >>>> computer science is based on something else. Thinking "that's a good
> >>>> idea" and re-using it in a new and interesting way is hardly
> >>>> "ripping off".
> 
> >>> ISTR that it was Isaac Newton who said that we stand on the shoulders
> >>> of giants.
> 
> >> Or, midgets are standing on my shoulders.
> 
> > Larger fleas have smaller fleas
> > Upon their backs to bite 'em.
> > Smaller fleas have lesser fleas,
> > And so ad infinitum.
> 
> Swift.

That they are, and they jump a lot.


-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On 2018-07-17, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On 17 Jul 2018 16:11:11 -0400
> Rich Alderson <ne...@alderson.users.panix.com> wrote:
>
>> Gareth's Downstairs Computer
>> <headstone255.but.n...@yahoo.com> writes:
>> 
>> > On 15/07/2018 20:00, Peter Flass wrote:
>> >> Gareth's Downstairs Computer
>> >> <headstone255.but.n...@yahoo.com> wrote:
>> >>> On 15/07/2018 11:03, Huge wrote:
>> 
>> >>>> I find the word "ripoff" problematical. Virtually everything in
>> >>>> computer science is based on something else. Thinking "that's a good
>> >>>> idea" and re-using it in a new and interesting way is hardly
>> >>>> "ripping off".
>> 
>> >>> ISTR that it was Isaac Newton who said that we stand on the shoulders
>> >>> of giants.
>> 
>> >> Or, midgets are standing on my shoulders.
>> 
>> > Larger fleas have smaller fleas
>> > Upon their backs to bite 'em.
>> > Smaller fleas have lesser fleas,
>> > And so ad infinitum.
>> 
>> Swift.
>
> That they are, and they jump a lot.
>
>

Brownian motion?

Hey, driving through Newbridge yesterday evening, very good looking
lady on pavement, walking along, it was the second glance when I
noticed that she was talking into a Gemini.


-- 
greymaus.ireland.ie
Will Rant for Food.

In article <9776793f-9ef9-4448...@googlegroups.com>,
fishtoprecords  <pat2...@gmail.com> wrote:
>The mapping of C from PDP-11 machine instructions is pretty obvious if you look at the early PDP-11
>hardware documentation and your basic K&R
>
>I am pretty sure that one of the early papers also mentions it.

Indeed it does.  From Dennis Ritchie's paper "The Development of the C Language"

 Thompson went a step further by inventing the ++ and -- operators,
 which increment or decrement; their prefix or postfix position
 determines whether the alteration occurs before or after noting the
 value of the operand. They were not in the earliest versions of B, but
 appeared along the way. People often guess that they were created to
 use the auto-increment and auto-decrement address modes provided by
 the DEC PDP-11 on which C and Unix first became popular. This is
 historically impossible, since there was no PDP-11 when B was
 developed. The PDP-7, however, did have a few "auto-increment" memory
 cells, with the property that an indirect memory reference through
 them incremented the cell. This feature probably suggested such
 operators to Thompson; the generalization to make them both prefix and
 postfix was his own. Indeed, the auto-increment cells were not used
 directly in implementation of the operators, and a stronger motivation
 for the innovation was probably his observation that the translation
 of ++x was smaller than that of x=x+1.

https://www.bell-labs.com/usr/dmr/www/chist.pdf

The myth that the PDP-11 inspired the C ++ and -- operators is
completely false.  Can we put it to bed now, please?  

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

The CDC 6x00 machines also used a circular buffer scheme; it worked very well.  When you opened a file, you defined the start and end of a buffer, and an IN and OUT pointer, initially the same as the start.   When reading from a tape or disk, the peripheral processor (think of it as a channel..) moved the IN pointer as it filled the buffer, and as the program reading the data took data out, it moved the OUT pointer.   So you could initiate an operation and as long as you kept up with the speed of the I/O, it would go on indefinitely at device speed.

The HARVEST computer which IBM built for NSA had tape drives (automated tape library) whose speed, including for switching tapes, was balanced exactly to the speed of the streaming unit, so it, too, could run for hours at tape speed.   The chief engineer was very proud of that.