XXDP BASIC???

[paramucho]

I found a wikipedia discussion where someone recalls using "XXDP
BASIC". That sounds to be most unlikely to me, but I've been wrong
often enough to ask if anyone has ever heard of such a beast.

Here's the reference:

I once tried a basic, which was probably BASIC-11 on one XXDP
diagnostic disk, and found it to be something completely different
and much more primitive.
http://en.wikipedia.org/wiki/Talk%3AHP_BASIC_for_OpenVMS



Ian

[Johnny Billquist]

Yeah, unlikely to say the least. Me things he either remember wrong, or
is totally confused.

XXDP don't even provide much of an environment for any layered products.
It's more or less a program loader to make loading and running paper
tape diagnostics easier.

Johnny

[Michael Moroney]

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

>> Here's the reference:
>>
>> I once tried a basic, which was probably BASIC-11 on one XXDP
>> diagnostic disk, and found it to be something completely different
>> and much more primitive.
>> http://en.wikipedia.org/wiki/Talk%3AHP_BASIC_for_OpenVMS

>Yeah, unlikely to say the least. Me things he either remember wrong, or
>is totally confused.

>XXDP don't even provide much of an environment for any layered products.
>It's more or less a program loader to make loading and running paper
>tape diagnostics easier.

I used to develop diagnostics for the PDP-11 on XXDP. I never encountered
any compiler or assembler for XXDP. It was little more than a way to
load and run the diagnostics. The diagnostics were assembled on a PDP
running RSX, a VAX or a TOPS system with a cross assembler.

[Bill Gunshannon]

In article <jbisio$9am$2...@iltempo.update.uu.se>,

I thought XXDP ran on top of DOS? I guess not...

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Bill Pechter]

In article <4edec52b...@nntp.aioe.org>,

Must've been basic11 on an old version of RT11.
Never saw a basic under XXDP through v2.5 (IIRC it was 2.5).
I left DEC Field Service in '86 -- so it would have to be
much newer than that.

There was a diagnostic chain facility and DecX11 could do multiple
diagnostic load tests at once... but Basic. Nope.

Bill
--
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org

[Johnny Billquist]

On 2011-12-05 23.12, Bill Pechter wrote:
> In article<4edec52b...@nntp.aioe.org>,
> paramucho<para...@hotmail.com> wrote:
>> I found a wikipedia discussion where someone recalls using "XXDP
>> BASIC". That sounds to be most unlikely to me, but I've been wrong
>> often enough to ask if anyone has ever heard of such a beast.
>>
>> Here's the reference:
>>
>> I once tried a basic, which was probably BASIC-11 on one XXDP
>> diagnostic disk, and found it to be something completely different
>> and much more primitive.
>> http://en.wikipedia.org/wiki/Talk%3AHP_BASIC_for_OpenVMS
>>
>>
>>
>> Ian
>
> Must've been basic11 on an old version of RT11.
> Never saw a basic under XXDP through v2.5 (IIRC it was 2.5).
> I left DEC Field Service in '86 -- so it would have to be
> much newer than that.
>
> There was a diagnostic chain facility and DecX11 could do multiple
> diagnostic load tests at once... but Basic. Nope.

Well, there was xteco... :-)

Johnny

[John Wallace]

On Dec 5, 10:12 pm, pech...@pechter.dyndns.org (Bill Pechter) wrote:
> In article <4edec52b.46693...@nntp.aioe.org>,

I don't suppose there's any chance of it having been MINC BASIC?

SPD is at http://www.bitsavers.org/pdf/dec/spd/14.47.03_8006_MINC_BASIC.pdf

I had a MINC on eval for a week or three a few decades ago. Seemed
neat enough, but my employers back then didn't understand the value of
having productive software people writing code to run the business,
rather than faffing around for weeks with code to drive instruments
and measuring devices before even getting started on the application
code.

Some companies (suppliers and users) understand this; National
Instruments seem to have made a succesful business out of having
"expensive" hardware and software that is actually good value for the
end business because it gets results quickly. A bit like DEC used to,
in fact, till DEC's PCI systems came along and DEC actually started
competing on price too.

Some folk still insist on buying cheap kit on the basis that staff
time apparently comes for free.

[Johnny Billquist]

On 2011-12-05 20.31, Bill Gunshannon wrote:
> In article<jbisio$9am$2...@iltempo.update.uu.se>,
> Johnny Billquist<b...@softjar.se> writes:
>> On 2011-12-05 14.20, paramucho wrote:
>>> I found a wikipedia discussion where someone recalls using "XXDP
>>> BASIC". That sounds to be most unlikely to me, but I've been wrong
>>> often enough to ask if anyone has ever heard of such a beast.
>>>
>>> Here's the reference:
>>>
>>> I once tried a basic, which was probably BASIC-11 on one XXDP
>>> diagnostic disk, and found it to be something completely different
>>> and much more primitive.
>>> http://en.wikipedia.org/wiki/Talk%3AHP_BASIC_for_OpenVMS
>>
>> Yeah, unlikely to say the least. Me things he either remember wrong, or
>> is totally confused.
>>
>> XXDP don't even provide much of an environment for any layered products.
>> It's more or less a program loader to make loading and running paper
>> tape diagnostics easier.
>>
>
> I thought XXDP ran on top of DOS? I guess not...

Right. Not... :-)
However, the filesystem used if you run XXDP from tape is half
compatible with DOS-11 tape format.
Not sure about the disk format, as I have no clue what, if any, disk
format DOS-11 used.

Johnny

[Fiona Shoppa]

Later versions of XXDP (like 2.2 and 2.5) had batch facilities which
had some scripting commands (including GOTO, PRINT, IF...THEN) that
someone might think was a primitive version of BASIC I suppose.

Tim.

[Tim Shoppa]

On Dec 5, 8:20 am, paramu...@hotmail.com (paramucho) wrote:

Later versions of XXDP (like 2.2 and 2.5) had batch facilities which
had some scripting commands (including GOTO, PRINT, IF...THEN) that

someone might think was a primitive version of BASIC.

Tim.

[Scott Dorsey]

>>I found a wikipedia discussion where someone recalls using "XXDP
>>BASIC". That sounds to be most unlikely to me, but I've been wrong
>>often enough to ask if anyone has ever heard of such a beast.

I have never heard of this.

BUT.... if I were going to write a standalone BASIC interpreter that
loaded from tape and ran entirely in memory and gave a BASIC prompt
on the console.... I would seriously consider using XXDP as a booting
framework to load it. Which someone may have done.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[paramucho]

On 5 Dec 2011 21:47:21 -0500, klu...@panix.com (Scott Dorsey) wrote:

>>>I found a wikipedia discussion where someone recalls using "XXDP
>>>BASIC". That sounds to be most unlikely to me, but I've been wrong
>>>often enough to ask if anyone has ever heard of such a beast.
>
>I have never heard of this.
>
>BUT.... if I were going to write a standalone BASIC interpreter that
>loaded from tape and ran entirely in memory and gave a BASIC prompt
>on the console.... I would seriously consider using XXDP as a booting
>framework to load it. Which someone may have done.
>--scott

You're right, and since XXDP loads Absolute Loader format files it
would be trivial to load DEC's papertape BASIC under XXDP. You could
reboot XXDP to exit BASIC or easily patch BASIC to conform to the XXDP
conventions for diagnostics (i.e. issue an RTS PC against entry-point
stack pointer).

In fact, one of the first things I did with a computer was to patch
papertape BASIC to load it directly from DECtape. I did the same for
PAL, EDIT etc. Loading papertapes by hand was mind-bogglingly tedious
affair.

So that may well be what happened: some bright spark decided to use
XXDP as a papertape loader for BASIC/PTS.



Ian

[paramucho]

The early diagnostic listings show the TOPS10/20 MACY11 as the
assembler. Around 1977 it looks a like an RSX assembler, but I
sometimes thought it might be a RSX-11D assembler.

The diagnostics themselves seem to make no use whatsover of XXDP's
system service EMTS. Only the XXDP utilities such as UPDAT, XTECO and
the like use the EMTS.

Don't ask me why (because I don't have any good answers!), but I've
been reverse-engineering the XXDP monitor. Could you shed some light
on how development of XXDP itself took place?

Ian




Ian

[Michael Moroney]

para...@hotmail.com (paramucho) writes:

>>I used to develop diagnostics for the PDP-11 on XXDP. I never encountered
>>any compiler or assembler for XXDP. It was little more than a way to
>>load and run the diagnostics. The diagnostics were assembled on a PDP
>>running RSX, a VAX or a TOPS system with a cross assembler.

>The diagnostics themselves seem to make no use whatsover of XXDP's
>system service EMTS. Only the XXDP utilities such as UPDAT, XTECO and
>the like use the EMTS.

There was a very limited amount of system functions available via the EMT
calls. Many of the diagnostics simply took over the system, never using
these EMTs, and after running them you'd have to reboot the system.

>Don't ask me why (because I don't have any good answers!), but I've
>been reverse-engineering the XXDP monitor.

Weird hobby!

>Could you shed some light
>on how development of XXDP itself took place?

I wasn't involved in the development of XXDP itself.

[paramucho]

On Tue, 6 Dec 2011 20:09:47 +0000 (UTC),
mor...@world.std.spaamtrap.com (Michael Moroney) wrote:

>para...@hotmail.com (paramucho) writes:
>
>>>I used to develop diagnostics for the PDP-11 on XXDP. I never encountered
>>>any compiler or assembler for XXDP. It was little more than a way to
>>>load and run the diagnostics. The diagnostics were assembled on a PDP
>>>running RSX, a VAX or a TOPS system with a cross assembler.
>
>>The diagnostics themselves seem to make no use whatsover of XXDP's
>>system service EMTS. Only the XXDP utilities such as UPDAT, XTECO and
>>the like use the EMTS.
>
>There was a very limited amount of system functions available via the EMT
>calls. Many of the diagnostics simply took over the system, never using
>these EMTs, and after running them you'd have to reboot the system.
>
>>Don't ask me why (because I don't have any good answers!), but I've
>>been reverse-engineering the XXDP monitor.
>
>Weird hobby!

It's a bit like a computer detective game. The long-term goal is a
retrospective of PDP-11 operating systems and XXDP happens to be the
system for which no sources or internal documentation at all have
survived. But the sleuthing itself is a lot of fun at times.

I do have one more stupid question. I guess you must have had some
kind of utility to transfer the cross-assembled files to XXDP media
(and I guess that had to be ported too as development moved from TOPS
to VMS and RSX). Can you remember anything about that process and the
name of the utility?


Ian

[Johnny Billquist]

FYI: In RSX, you can access XXDP tapes using FLX. That would mean that
EXCHANGE under VMS should also work.
Don't know about disks though. Haven't tried.

Like I said before: XXDP tapes use more or less the normal DOS-11 format.

Johnny

[paramucho]

On Fri, 09 Dec 2011 10:04:20 +0100, Johnny Billquist <b...@softjar.se>
wrote:

That's right. But I'm thinking more of the production process in terms
of writing and testing new diagnostics. That's mostly going to be done
on disks. I know it sounds like a no-brainer question...but it really
is like a detective game and the smallest clues can resolve issues. I
got hold of the cassette TADP from Wolfgang and have been chewing on
that the past few days.




Ian

[Michael Moroney]

para...@hotmail.com (paramucho) writes:

>I do have one more stupid question.

It's not stupid if you're trying to document something.

> I guess you must have had some
>kind of utility to transfer the cross-assembled files to XXDP media
>(and I guess that had to be ported too as development moved from TOPS
>to VMS and RSX). Can you remember anything about that process and the
>name of the utility?

We had something called Charon which I believe was a PDP emulator. I
only used it to transfer files to the XXDP disk, which I think was the
same or similar format as RSTS used (I know nothing of RSTS).

Before that I think we used a PIP variant.

Before executables could be used on XXDP they had to be converted to
.BIN/.BIC format by a tool. I'll look through old files to see what
I have, if anything.

[paramucho]

On Fri, 9 Dec 2011 18:57:16 +0000 (UTC),
mor...@world.std.spaamtrap.com (Michael Moroney) wrote:

>para...@hotmail.com (paramucho) writes:
>
>>I do have one more stupid question.
>
>It's not stupid if you're trying to document something.
>
>> I guess you must have had some
>>kind of utility to transfer the cross-assembled files to XXDP media
>>(and I guess that had to be ported too as development moved from TOPS
>>to VMS and RSX). Can you remember anything about that process and the
>>name of the utility?
>
>We had something called Charon which I believe was a PDP emulator. I
>only used it to transfer files to the XXDP disk, which I think was the
>same or similar format as RSTS used (I know nothing of RSTS).

That's interesting. I thought for a moment that you might be thinking
about the commercial CHARON-11 emulator which was produced in the late
90s. However, a little Googling shows that the company involved was
formed by a bunch of ex-Deccies buying out DEC's "European Migration
and Porting Center". So their later commercial emulator was probably
based on original DEC code. The software PDP-11 emulation for VMS
systems (which was considerably simpler) may have come from the same
code base.

http://en.wikipedia.org/wiki/Charon_(software)

The XXDP disk format is pretty close to the early PDP-11 DOS/BATCH
system.

>Before that I think we used a PIP variant.
>
>Before executables could be used on XXDP they had to be converted to
>.BIN/.BIC format by a tool. I'll look through old files to see what
>I have, if anything.

"Old files" sounds interesting indeed.

Some of the executables have been handled by UPD1/UPD2/UPDAT DUMP or
SAVE commands (the DUMP/SAVE commands copy out uninitialized memory if
the user forgets to CLR memory first), but I have no idea if that was
always the case.


Ian

[Johnny Billquist]

On 2011-12-10 07.44, paramucho wrote:
> On Fri, 9 Dec 2011 18:57:16 +0000 (UTC),
> mor...@world.std.spaamtrap.com (Michael Moroney) wrote:
>
>> para...@hotmail.com (paramucho) writes:
>>
>>> I do have one more stupid question.
>>
>> It's not stupid if you're trying to document something.
>>
>>> I guess you must have had some
>>> kind of utility to transfer the cross-assembled files to XXDP media
>>> (and I guess that had to be ported too as development moved from TOPS
>>> to VMS and RSX). Can you remember anything about that process and the
>>> name of the utility?
>>
>> We had something called Charon which I believe was a PDP emulator. I
>> only used it to transfer files to the XXDP disk, which I think was the
>> same or similar format as RSTS used (I know nothing of RSTS).
>
> That's interesting. I thought for a moment that you might be thinking
> about the commercial CHARON-11 emulator which was produced in the late
> 90s. However, a little Googling shows that the company involved was
> formed by a bunch of ex-Deccies buying out DEC's "European Migration
> and Porting Center". So their later commercial emulator was probably
> based on original DEC code. The software PDP-11 emulation for VMS
> systems (which was considerably simpler) may have come from the same
> code base.
>
> http://en.wikipedia.org/wiki/Charon_(software)

Right.
And actually, Charon was even a product that DEC had and sold for a while.
I was at a DECUS meeting at DEC in Sweden in the late 90s, where DEC
demonstrated Charon for us, running RSX on Charon, which was running on
an Alpha running VMS. (If I remember right.)
But this must have been pretty close to when Compaq took over DEC.

Charon was later split off from DEC/Compaq (as just about everything).
The company was called SRI, but changed its name to Stromasys. I see
that the Wikipedia article mentions all this... :-)

I can also tell that I've used Charon-11, for a commercial customer, but
had to give up on it because of some problems, and in the end went with
E11 instead.

> The XXDP disk format is pretty close to the early PDP-11 DOS/BATCH
> system.

Cool. And not surprising.

>> Before that I think we used a PIP variant.
>>
>> Before executables could be used on XXDP they had to be converted to
>> .BIN/.BIC format by a tool. I'll look through old files to see what
>> I have, if anything.
>
> "Old files" sounds interesting indeed.
>
> Some of the executables have been handled by UPD1/UPD2/UPDAT DUMP or
> SAVE commands (the DUMP/SAVE commands copy out uninitialized memory if
> the user forgets to CLR memory first), but I have no idea if that was
> always the case.

That is tools you use inside XXDP. I wonder if they were that helpful in
the development cycle of diagnostics.

Johnny

[Rich Alderson]

para...@hotmail.com (paramucho) writes:

> (and I guess that had to be ported too as development moved from TOPS
> to VMS and RSX)

Just let me step in here to point out that there is, and never was, such a
thing as "TOPS" in this context. Tops-10 and TOPS-20 are entirely separate
operating systems with no shared code base whatsoever. Nada. Zilch. Zip.

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

[Michael Moroney]

para...@hotmail.com (paramucho) writes:

>That's right. But I'm thinking more of the production process in terms
>of writing and testing new diagnostics. That's mostly going to be done
>on disks. I know it sounds like a no-brainer question...but it really
>is like a detective game and the smallest clues can resolve issues. I
>got hold of the cassette TADP from Wolfgang and have been chewing on
>that the past few days.

I found an old .com file I used to transfer stuff using CHARON, dated
24-JUL-1986:

$ MOUNT/FOREIGN DUC0:
$ CHARON
DELETE DUC0:DEMPR.BIN
COPY DUC0:DEMPR.BIN=DEMPR.OBJ
DIR DUC0:
$ DISMOUNT DUC0:

I don't remember what kind of drive DUC0 was, probably a 5 1/4" floppy.
DUC0: was VMS's name for it on a VAX 785.

Aside: DEMPR.BIN was an informal tool I wrote to exercise the DEMPR, an 8
port thinwire repeater. It needed multiple copies running on multiple
systems to run on all 9 ports (8 thinwire plus an upstream). Since XXDP
was a pain in the butt I added code where one copy would respond to MOP
"bootme" requests and download itself to the other systems. (It didn't
use any XXDP services whatsover) I once warned someone using it not to
connect it to the DEC-internal Enet since it would try to boot anything
and everything in the DEC Mill complex. I just now realized I "invented"
a computer worm with this thing, since each booted copy would try to boot
others. It never would have gotten very far since it would have only
run on PDP-11s with a DEQNA trying to boot from the network.

[Michael Moroney]

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

>> Some of the executables have been handled by UPD1/UPD2/UPDAT DUMP or
>> SAVE commands (the DUMP/SAVE commands copy out uninitialized memory if
>> the user forgets to CLR memory first), but I have no idea if that was
>> always the case.

>That is tools you use inside XXDP. I wonder if they were that helpful in
>the development cycle of diagnostics.

I remember running UPDAT or UPD2, but I can't remember what they did.

I have MACROM.MAC which was used by many diagnostics to define the simple
XXDP EMT functions as macros. Many diagnostics were assembled with
"foo,foo=macrom,foo". As I mentioned, many diagnostics didn't even use
these.

[Johnny Billquist]

On 2011-12-10 16.43, Rich Alderson wrote:
> para...@hotmail.com (paramucho) writes:
>
>> (and I guess that had to be ported too as development moved from TOPS
>> to VMS and RSX)
>
> Just let me step in here to point out that there is, and never was, such a
> thing as "TOPS" in this context. Tops-10 and TOPS-20 are entirely separate
> operating systems with no shared code base whatsoever. Nada. Zilch. Zip.

A bit touchy today are we, Rich? ;-)

You are totally right, though. By the way, I would assume that cross
development for PDP-11 took place on Tops-10, but don't know for sure.
Did the PDP-11 cross assembler work on both Tops-10 and TOPS-20?

Johnny

[paramucho]

On Sun, 11 Dec 2011 03:33:17 +0100, Johnny Billquist <b...@softjar.se>
wrote:

Apparently there was an emulation layer allowing TOPS-10 software to
run on the "TWENEX". If that's the case then MACY11 would not have
required "porting" between TOPS-10 and TOPS-20.

http://en.wikipedia.org/wiki/TOPS-20

Ian

[Johnny Billquist]

Yes, you have something called PA1050, which allowed users on TOPS-20 to
run some Tops-10 programs. It wasn't a complete Tops-10 "emulation", but
good enough for many things.

Johnny

[paramucho]

On Sat, 10 Dec 2011 17:22:54 +0000 (UTC),
mor...@world.std.spaamtrap.com (Michael Moroney) wrote:

>Johnny Billquist <b...@softjar.se> writes:
>
>>> Some of the executables have been handled by UPD1/UPD2/UPDAT DUMP or
>>> SAVE commands (the DUMP/SAVE commands copy out uninitialized memory if
>>> the user forgets to CLR memory first), but I have no idea if that was
>>> always the case.
>
>>That is tools you use inside XXDP. I wonder if they were that helpful in
>>the development cycle of diagnostics.
>
>I remember running UPDAT or UPD2, but I can't remember what they did.

UPD2/UPDAT supply the PIP and PATCH functionality. You can load a BIC
or BIS file and convert it to an image file and vice versa. You can
change the transfer address.

>I have MACROM.MAC which was used by many diagnostics to define the simple
>XXDP EMT functions as macros. Many diagnostics were assembled with
>"foo,foo=macrom,foo". As I mentioned, many diagnostics didn't even use
>these.

I'd be interested to see MACROM.MAC. I've decoded the EMT functions
for one of the monitors and added a trace facility to my emulator.
Here's a bit of XTECO parsing a file name and loading a driver:

6002 emt=6 GetChk r0=2450 r1=4075 r5=155626
TECO A.A

5426 emt=1 ParFld r0=0 r1=0 r5=155626
7434 emt=1 ParFld r0=4101 r1=4700 r5=4354
7446 emt=32 SetFld r0=4102 r1=0 r5=4354
7466 emt=31 DevNam r0=4102 r1=0 r5=4354
7576 emt=14 LoaLDA r0=7750 r1=20572 r5=4354 spc=[HDDL??.SYS]
155714 emt=12 OpnFil r0=7750 r1=20572 r5=4354 spc=[HDDL??.SYS]
157616 emt=21 ReaBlk r0=7762 r1=155640 r5=155626
157444 emt=21 ReaBlk r0=154534 r1=155640 r5=155626
10710 emt=1 ParFld r0=4400 r1=40 r5=4354
WRITE-ENABLE OUTPUT UNIT, THEN TYPE <CR>.
6002 emt=6 GetChk r0=4535 r1=4075 r5=4354

But it would be neater if I used the original EMT function names and
were able to reflect the other details of the EMT calls.

Ian

[paramucho]

On Sat, 10 Dec 2011 16:15:29 +0000 (UTC),
mor...@world.std.spaamtrap.com (Michael Moroney) wrote:

>para...@hotmail.com (paramucho) writes:
>
>>That's right. But I'm thinking more of the production process in terms
>>of writing and testing new diagnostics. That's mostly going to be done
>>on disks. I know it sounds like a no-brainer question...but it really
>>is like a detective game and the smallest clues can resolve issues. I
>>got hold of the cassette TADP from Wolfgang and have been chewing on
>>that the past few days.
>
>I found an old .com file I used to transfer stuff using CHARON, dated
>24-JUL-1986:
>
>$ MOUNT/FOREIGN DUC0:
>$ CHARON
>DELETE DUC0:DEMPR.BIN
>COPY DUC0:DEMPR.BIN=DEMPR.OBJ
>DIR DUC0:
>$ DISMOUNT DUC0:
>
>I don't remember what kind of drive DUC0 was, probably a 5 1/4" floppy.
>DUC0: was VMS's name for it on a VAX 785.

The CHARON command would have run up the emulator and started a
specific app. The syntax of the COPY command with the equals-sign
looks like old-style PIP, but must have been some kind of file
exchange utility.

I wonder where the conversion from .OBJ object format to absolute
loader format took place. A dedicated transfer utility could have
performed that task for a single object module I guess, but it would
usually be separate.

>Aside: DEMPR.BIN was an informal tool I wrote to exercise the DEMPR, an 8
>port thinwire repeater. It needed multiple copies running on multiple
>systems to run on all 9 ports (8 thinwire plus an upstream). Since XXDP
>was a pain in the butt I added code where one copy would respond to MOP
>"bootme" requests and download itself to the other systems. (It didn't
>use any XXDP services whatsover) I once warned someone using it not to
>connect it to the DEC-internal Enet since it would try to boot anything
>and everything in the DEC Mill complex. I just now realized I "invented"
>a computer worm with this thing, since each booted copy would try to boot
>others. It never would have gotten very far since it would have only
>run on PDP-11s with a DEQNA trying to boot from the network.

So, the upsides of the job were playing around with hardware, and new
hardware at that, and probably not having much to do with stressed
customers.

I'd be interested to know at what point maintenance apps were started
in the hardware development cycle.





Ian

[Charles Richmond]

"Johnny Billquist" <b...@softjar.se> wrote in message
news:jc1aep$575$1...@Iltempo.Update.UU.SE...

> On 2011-12-11 05.01, paramucho wrote:
>>

>> [snip...] [snip...]
>> [snip...]

>>
>> Apparently there was an emulation layer allowing TOPS-10 software to
>> run on the "TWENEX". If that's the case then MACY11 would not have
>> required "porting" between TOPS-10 and TOPS-20.
>>
>> http://en.wikipedia.org/wiki/TOPS-20
>
> Yes, you have something called PA1050, which allowed users on TOPS-20 to
> run some Tops-10 programs. It wasn't a complete Tops-10 "emulation", but
> good enough for many things.
>

I always thought PA1050 just translated the operating system calls from
TOPS-10 to TOPS-20 calls. I know that Tops-10 SNOBOL would run under
TOPS-20 using PA1050, because I've been there and done that...


--
+<><><><><><><><><><><><><><><><><><><>+
| Charles Richmond nume...@aquaporin4.com |
+<><><><><><><><><><><><><><><><><><><>+

[Charles Richmond]

"Johnny Billquist" <b...@softjar.se> wrote in message
news:jc1aep$575$1...@Iltempo.Update.UU.SE...

> On 2011-12-11 05.01, paramucho wrote:
>>

>> [snip...] [snip...]
>> [snip...]

>>
>> Apparently there was an emulation layer allowing TOPS-10 software to
>> run on the "TWENEX". If that's the case then MACY11 would not have
>> required "porting" between TOPS-10 and TOPS-20.
>>
>> http://en.wikipedia.org/wiki/TOPS-20
>
> Yes, you have something called PA1050, which allowed users on TOPS-20 to
> run some Tops-10 programs. It wasn't a complete Tops-10 "emulation", but
> good enough for many things.
>

[Johnny Billquist]

On 2011-12-12 07.28, Charles Richmond wrote:
> "Johnny Billquist" <b...@softjar.se> wrote in message
> news:jc1aep$575$1...@Iltempo.Update.UU.SE...
>> On 2011-12-11 05.01, paramucho wrote:
>>>
>>> [snip...] [snip...] [snip...]
>>>
>>> Apparently there was an emulation layer allowing TOPS-10 software to
>>> run on the "TWENEX". If that's the case then MACY11 would not have
>>> required "porting" between TOPS-10 and TOPS-20.
>>>
>>> http://en.wikipedia.org/wiki/TOPS-20
>>
>> Yes, you have something called PA1050, which allowed users on TOPS-20
>> to run some Tops-10 programs. It wasn't a complete Tops-10
>> "emulation", but good enough for many things.
>>
>
> I always thought PA1050 just translated the operating system calls from
> TOPS-10 to TOPS-20 calls. I know that Tops-10 SNOBOL would run under
> TOPS-20 using PA1050, because I've been there and done that...

Well, what else is there than translating systems calls in order to have
"emulation" in this case?

Of course, some system calls don't have a direct mapping to TOPS-20.
Meaning that either PA1050 needs to do more, or else that system call
can't be implemented.

Things that comes to mind that are difficult are things like the shared
hiseg memory in Tops-10.

Johnny

[Bob Koehler]

Just about everything from TOPS-10 would run on TOPS-20. TOPS-20
included simulation of the TOPS-10 environment, including the UUOs.

For years I used the BLISS-10 compiler off the freeware tape under
TOPS-20, the BLISS-16 cross compiler was advertized as running under
TOPS-10, TOPS-20, and VMS (different image for VMS), and I would be
suprized if a Macro-11 cross compiler for TOPS-10 wouldn't run on
TOPS-20.

[Michael Moroney]

para...@hotmail.com (paramucho) writes:

>The CHARON command would have run up the emulator and started a
>specific app. The syntax of the COPY command with the equals-sign
>looks like old-style PIP, but must have been some kind of file
>exchange utility.

It may have been that CHARON was a DCL symbol or another .COM file
that ran something else. I do remember what we used before this
CHARON tool also had a PIP-like syntax.

>I wonder where the conversion from .OBJ object format to absolute
>loader format took place. A dedicated transfer utility could have
>performed that task for a single object module I guess, but it would
>usually be separate.

I was wondering about it myself. I don't remember. I think that if
the program was completely absolute based that could be done.

>So, the upsides of the job were playing around with hardware, and new
>hardware at that, and probably not having much to do with stressed
>customers.

I didn't deal with customers.

>I'd be interested to know at what point maintenance apps were started
>in the hardware development cycle.

Generally diagnostic development started once there was a sufficiently
developed functional spec. Usually the hardware and diagnostic people
worked together using each other's prototypes debugging each other's
and their own stuff.

I'll forward the MACROM.MAC file to you shortly.

[Rich Alderson]

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

> By the way, I would assume that cross
> development for PDP-11 took place on Tops-10, but don't know for sure.
> Did the PDP-11 cross assembler work on both Tops-10 and TOPS-20?

It does work. I used it to compile an enhanced version of the LP20 diagnostic
a few months back to improve the testing we were doing on our implementation of
the M8571 card. (Turns out that the maintenance schematic is incomplete. We
were lucky enough to borrow a real M8571 to check out the missing pieces.)

I did the compile on the Toad-1, since that's where my tools for dealing with
tape images live, and used Kermit to move the result over to the 2065 (our
Tops-10 platform).

[paramucho]

On Tue, 13 Dec 2011 17:18:03 +0000 (UTC),
mor...@world.std.spaamtrap.com (Michael Moroney) wrote:

>para...@hotmail.com (paramucho) writes:
>
>>The CHARON command would have run up the emulator and started a
>>specific app. The syntax of the COPY command with the equals-sign
>>looks like old-style PIP, but must have been some kind of file
>>exchange utility.
>
>It may have been that CHARON was a DCL symbol or another .COM file
>that ran something else. I do remember what we used before this
>CHARON tool also had a PIP-like syntax.
>
>>I wonder where the conversion from .OBJ object format to absolute
>>loader format took place. A dedicated transfer utility could have
>>performed that task for a single object module I guess, but it would
>>usually be separate.
>
>I was wondering about it myself. I don't remember. I think that if
>the program was completely absolute based that could be done.

It would be almost just a matter of converting headers. The other
possibility is that the .OBJ was in fact an absolute loader format
file. I've seen diagnostic listings where the command at the end of
the listing reads something like "foo.bin=foo..."

>>So, the upsides of the job were playing around with hardware, and new
>>hardware at that, and probably not having much to do with stressed
>>customers.
>
>I didn't deal with customers.
>
>>I'd be interested to know at what point maintenance apps were started
>>in the hardware development cycle.
>
>Generally diagnostic development started once there was a sufficiently
>developed functional spec. Usually the hardware and diagnostic people
>worked together using each other's prototypes debugging each other's
>and their own stuff.
>
>I'll forward the MACROM.MAC file to you shortly.

Many thanks...

Ian

[Bill Pechter]

In article <4ee18a66...@nntp.aioe.org>,

I believe the easy way to put stuff on XXDP tape was with flx to
put the stuff to Dos-11 media.

Bill

--
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org

[paramucho]

I believe you're right! Using SimH I created an XXDP volume which I
could access and modify with XXDP UPD2, DOSbatch PIP and RSX FLX.

I'm not an RSX-person, but using UIC [1,1] seemed to work under FLX.
Creating a file with UIC [200,200] seemed to corrupt the directory,
although XXDP didn't seem to mind much and DOS just listed a lot of
rubbish after the valid directory entries.

Early attempts with RSX FLX failed, probably because the volume
structure wasn't perfect. Creating a new RK05 volume using SimH solved
whatever that problem was.

I had thought that there were minor differences between the DOSbatch
and XXDP volume structures, but I guess DOSbatch must simply be a
compatible superset of XXDP. I haven't checked whether that's true for
DECtape which places the MFDs and UFDs etc differently.

FLX would not have been available when diagnostics and XXDP were
developed under TOPS.


Ian

[Johnny Billquist]

Wow. I only told you that FLX works fine a couple of weeks ago... :-)

However, there are differences, which is why FLX is not a perfect match.

These are the first and last few lines from an

FLX MU1:[*,*]/DO/DI in RSX...

Directory MU1:[0,0]
20-DEC-11

XXBOOT 2.MON 32.C 38--19 <0> [2,2]
XXBOOT 2.MON 32.C 97--21 <0> [2,2]
XXDPXM 2.SYS 39. 01-MAR-89 <0> [2,2]
XXDPSM A1.SYS 29. 01-MAR-89 <0> [2,2]
DRSXM BT.SYS 48. 01-MAR-89 <0> [2,2]
DRSSM C..SYS 24. 01-MAR-89 <0> [2,2]
[...]
S1B48D.BIN 24. 27-NOV-90 <233> [2,74]
S1B48B.BIN 23. 27-NOV-90 <233> [2,74]
S1C19A.BIN 58. 27-NOV-90 <233> [2,74]
S1C18A.BIN 44. 27-NOV-90 <233> [2,74]

Total of 20593. blocks in 790. files

.

Notice the extra three characters at the end of the filenames, before
the extensions. They are not really a part of the filename, but is used
by something in XXDP, while they are normally always zero on DOS tapes.

But apart from that discrepancy of file names, the tape is perfectly
accessible using FLX.

This is an XXDP V2.5 tape, by the way, which is later than when you had
UPD2 and so on, so it might have been a late addition to XXDP tapes. I
wouldn't be surprised to hear that older versions of XXDP were more in
line with the DOS-11 format.

DECtape, as well as disks, have a different format altogether compared
to tapes, so do not expect any kind of similarity or equal
functionality. FLX cannot read or write XXDP disks.

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

[Don North]

See:
http://www.bitsavers.org/pdf/dec/pdp11/xxdp/fiche/AH-S867A-MC_XXDP+_fileStruct_Apr81.pdf

[paramucho]

On Tue, 20 Dec 2011 21:50:10 +0100, Johnny Billquist <b...@softjar.se>
wrote:

>On 2011-12-20 14:51, paramucho wrote:
>> On Mon, 19 Dec 2011 15:32:55 +0000 (UTC), pec...@pechter.dyndns.org
>> (Bill Pechter) wrote:

<SNIP>

>>> I believe the easy way to put stuff on XXDP tape was with flx to
>>> put the stuff to Dos-11 media.
>>
>> I believe you're right! Using SimH I created an XXDP volume which I
>> could access and modify with XXDP UPD2, DOSbatch PIP and RSX FLX.
>>
>> I'm not an RSX-person, but using UIC [1,1] seemed to work under FLX.
>> Creating a file with UIC [200,200] seemed to corrupt the directory,
>> although XXDP didn't seem to mind much and DOS just listed a lot of
>> rubbish after the valid directory entries.
>>
>> Early attempts with RSX FLX failed, probably because the volume
>> structure wasn't perfect. Creating a new RK05 volume using SimH solved
>> whatever that problem was.
>>
>> I had thought that there were minor differences between the DOSbatch
>> and XXDP volume structures, but I guess DOSbatch must simply be a
>> compatible superset of XXDP. I haven't checked whether that's true for
>> DECtape which places the MFDs and UFDs etc differently.
>>
>> FLX would not have been available when diagnostics and XXDP were
>> developed under TOPS.
>
>Wow. I only told you that FLX works fine a couple of weeks ago... :-)

You were talking about magtape and I agreed with you on that. However,
I was thinking about disk-to-disk transfers in a production
environment.

>However, there are differences, which is why FLX is not a perfect match.
>
>These are the first and last few lines from an
>
>FLX MU1:[*,*]/DO/DI in RSX...
>
>Directory MU1:[0,0]
>20-DEC-11
>
>XXBOOT 2.MON 32.C 38--19 <0> [2,2]
>XXBOOT 2.MON 32.C 97--21 <0> [2,2]
>XXDPXM 2.SYS 39. 01-MAR-89 <0> [2,2]
>XXDPSM A1.SYS 29. 01-MAR-89 <0> [2,2]
>DRSXM BT.SYS 48. 01-MAR-89 <0> [2,2]
>DRSSM C..SYS 24. 01-MAR-89 <0> [2,2]
>[...]
>S1B48D.BIN 24. 27-NOV-90 <233> [2,74]
>S1B48B.BIN 23. 27-NOV-90 <233> [2,74]
>S1C19A.BIN 58. 27-NOV-90 <233> [2,74]
>S1C18A.BIN 44. 27-NOV-90 <233> [2,74]
>
> Total of 20593. blocks in 790. files
>
>.
>
>Notice the extra three characters at the end of the filenames, before
>the extensions. They are not really a part of the filename, but is used
>by something in XXDP, while they are normally always zero on DOS tapes.

XXDP stores the file size in the last word of the 7-word file header.
DOS leaves it zero. RSX must be putting the remainder of their
9-character filenames there. Now, that actually works for the first
two entries above, i.e. rad50 " 2" == 32 decimal. But not for the
rest.

>But apart from that discrepancy of file names, the tape is perfectly
>accessible using FLX.
>
>This is an XXDP V2.5 tape, by the way, which is later than when you had
>UPD2 and so on, so it might have been a late addition to XXDP tapes. I
>wouldn't be surprised to hear that older versions of XXDP were more in
>line with the DOS-11 format.

I haven't used any tapes...only disks.

>DECtape, as well as disks, have a different format altogether compared
>to tapes, so do not expect any kind of similarity or equal
>functionality. FLX cannot read or write XXDP disks.

Yikes! The tests I was doing were with emulated RK05 disks. I read and
write the same RK05 using XXDP+ UPD2, DOS PIP and RSX V3.1 FLX.

Here's some of the XXDP init and copy listing:

CHUP2D0 XXDP+ UPD2 UTILITY
RESTART: 003714

*ZERO DK1:
USER DATA ON DK1 WILL BE DESTROYED!
PROCEED?(Y/N/CR=N)Y

*PIP DK1:=*.SYS
HSAAD0.SYS
HSABC0.SYS
HSACC0.SYS
...

Here's some of the FLX listing:

FLX>DK1:[1,1]/LI/DO

DIRECTORY DK1:[1,1]
15-DEC-77

HSAAD0.SYS 24. 03-MAR-83 <0>
HSABC0.SYS 28. 03-MAR-83 <0>
HSACC0.SYS 27. 03-MAR-83 <0>
HSADB0.SYS 25. 03-MAR-83 <0>
...

TOTAL OF 372. BLOCKS IN 44. FILES

In fact, XXPD disk-like devices before the RL01/RL02 have a DOS-11
on-disk structure. That includes RX01s and RX02s. However, the FLX
documentation describes its DOS-11 disk-like support to the RK05/DK:
and TU56/DT:.

So, yes, FLX does support DOS-11 disks, but really only the RK05, and
that was hardly the transport-medium-of-choice. So, the transport
question for XXDP remains open. It would have been trivial to extend
FLX to support RX01s and RXO2s and not much more than a day's work to
support the modifications made for the XXDP+ on-disk structure.
Perhaps there was an extended in-house version of FLX.

Ian

[Johnny Billquist]

Aha. Missed that you talked about tape. However, I also have example
disks where FLX cannot read the XXDP disk.

Interesting. It obviously is a bit more complex than that, but file size
is definitely a good suggestion. I should really check FLX, but anyway,
there is no way for RSX to "preserve" charactes 7-9 of a file name when
storing to DOS-11 tapes with FLX. Also, file sizes don't at all seem to
match up apart from the first two files. I'm curious is DEC might have
started using word 5 for something in later XXDP. Anyone have any ideas?

>> DECtape, as well as disks, have a different format altogether compared
>> to tapes, so do not expect any kind of similarity or equal
>> functionality. FLX cannot read or write XXDP disks.
>
> Yikes! The tests I was doing were with emulated RK05 disks. I read and
> write the same RK05 using XXDP+ UPD2, DOS PIP and RSX V3.1 FLX.

I have a XXDP V2.5 disk, which is an RL02. FLX totally refuse to touch it.

Could be changes in the newer XXDP, or it could be something specific
about RL02 disks then.

> So, yes, FLX does support DOS-11 disks, but really only the RK05, and
> that was hardly the transport-medium-of-choice. So, the transport
> question for XXDP remains open. It would have been trivial to extend
> FLX to support RX01s and RXO2s and not much more than a day's work to
> support the modifications made for the XXDP+ on-disk structure.
> Perhaps there was an extended in-house version of FLX.

Well, I didn't say that FLX didn't support DOS-11 format disks, just
that my XXDP disk is not accessible by FLX. I do not know what format my
XXDP disk is in. It boots, and XXDP have no problems understanding it.
FLX do not understand it.

Johnny

[paramucho]

On Sat, 24 Dec 2011 00:46:57 +0100, Johnny Billquist <b...@softjar.se>
wrote:


>

The FLX listing above shows them as part of a 9-character filename.

>>> XXDPSM A1.SYS 29. 01-MAR-89<0> [2,2]

123456789

> Also, file sizes don't at all seem to
>match up apart from the first two files. I'm curious is DEC might have
>started using word 5 for something in later XXDP. Anyone have any ideas?

I tried to produce an MT: magtape using FLX under SimH, but the
behavior I got was really flakey and all the files ended up with the
same name.

I created an XXDP MT: with SimH which I then examined with PATCH. The
files, their lengths and the content of the 7th word of the header are
shown in octal below. The 7th word just seems to be a running total of
the number of data blocks written.

File Len 7th
HSAAD0.SYS 30 0
HSABC0.SYS 34 30 0+30->30
HSACC0.SYS 33 64 30+34->64
HSADB0.SYS 31 117 ...
HUDIB0.SYS 5 150
HDMMB0.SYS 3 155

And apart from a couple of anomolies on the first two files that also
works for your listing. The running totals are, in decimal this time,
0, 32., 71., 100., 148. which produces the rad50 series: __2, _A1,
_BT, _C.

>>> XXBOOT 2.MON 32.C 38--19<0> [2,2]
>>> XXBOOT 2.MON 32.C 97--21<0> [2,2]
>>> XXDPXM 2.SYS 39. 01-MAR-89<0> [2,2]
>>> XXDPSM A1.SYS 29. 01-MAR-89<0> [2,2]
>>> DRSXM BT.SYS 48. 01-MAR-89<0> [2,2]
>>> DRSSM C..SYS 24. 01-MAR-89<0> [2,2]
>>> [...]

Why it cuts out later on is left as an exercise for the reader:

>>> S1B48D.BIN 24. 27-NOV-90<233> [2,74]
>>> S1B48B.BIN 23. 27-NOV-90<233> [2,74]
>>> S1C19A.BIN 58. 27-NOV-90<233> [2,74]
>>> S1C18A.BIN 44. 27-NOV-90<233> [2,74]

I'm not sure what use the running total is. It might help the monitor
to know approximately where it is on a magtape. It might just be
noise.

Note: I'm not sure how an XXDP magtape gets to have any UIC other than
[1,1], so I'm wondering whether these files, with UICs [2,2] and
[2,74], have been transferred to and from disk?

<snip>

>Well, I didn't say that FLX didn't support DOS-11 format disks, just
>that my XXDP disk is not accessible by FLX. I do not know what format my
>XXDP disk is in. It boots, and XXDP have no problems understanding it.
>FLX do not understand it.

As stated in the RSX-11M etc documentation kits, FLX supports exactly
two DOS-11 format disk-like devices: DK: and DT:. DOS-11 and XXDP have
exactly the same on-disk structure on these devices (because they grew
up together).

There is no other DOS-11 disk-like support in FLX. DOS-11 and XXDP
have the same file structure on DD, DX and DY, but FLX doesn't access
them. The XXDP file structure changed slightly around the time of the
RL01/02, but there's no FLX support for DOS-11 DL: either (and it's
unclear that DOS-11 ever supported DL:).

Ian

[paramucho]

On Sat, 24 Dec 2011 14:27:02 GMT, para...@hotmail.com (paramucho)
wrote:

See below...

>>>> S1B48D.BIN 24. 27-NOV-90<233> [2,74]
>>>> S1B48B.BIN 23. 27-NOV-90<233> [2,74]
>>>> S1C19A.BIN 58. 27-NOV-90<233> [2,74]
>>>> S1C18A.BIN 44. 27-NOV-90<233> [2,74]

>I'm not sure what use the running total is. It might help the monitor
>to know approximately where it is on a magtape. It might just be
>noise.
>
>Note: I'm not sure how an XXDP magtape gets to have any UIC other than
>[1,1], so I'm wondering whether these files, with UICs [2,2] and
>[2,74], have been transferred to and from disk?

It occurred to me just after I posted that the [2,2] files would have
come from an XXDP tape, and thus have the extra word/characters, and
that [2,74] files would have come from another source, such as a disk
or original DEC distribution tape, and thus do not have the extra
word/characters.

><snip>
>>Well, I didn't say that FLX didn't support DOS-11 format disks, just
>>that my XXDP disk is not accessible by FLX. I do not know what format my
>>XXDP disk is in. It boots, and XXDP have no problems understanding it.
>>FLX do not understand it.
>
>As stated in the RSX-11M etc documentation kits, FLX supports exactly
>two DOS-11 format disk-like devices: DK: and DT:. DOS-11 and XXDP have
>exactly the same on-disk structure on these devices (because they grew
>up together).
>
>There is no other DOS-11 disk-like support in FLX. DOS-11 and XXDP
>have the same file structure on DD, DX and DY, but FLX doesn't access
>them. The XXDP file structure changed slightly around the time of the
>RL01/02, but there's no FLX support for DOS-11 DL: either (and it's
>unclear that DOS-11 ever supported DL:).
>
>Ian

Ian

[Dennis Boone]

> I believe the easy way to put stuff on XXDP tape was with flx to
> put the stuff to Dos-11 media.

Picking a random place in the thread to inject this comment...

PUTR apparently supports both DOSBATCH and XXDP+ file systems.
Its documentation states that early versions of XXDB used the DOSBATCH
file system, and that later versions used an enhanced variant of it.

For those trying to shovel stuff around today, PUTR would be
one option. (Clearly it's not how DEC did it, which is also an
interesting question.)

De