Re: [Simh] pdp11 - console input with high bit set

[Clem Cole]

On Fri, Jul 24, 2020 at 4:18 PM Paul Koning  wrote:

> Parity is something that comes in addition to the data.  DEC UARTS (and
> many others, I think)
>
Appendix D of McNamara's book, *a.k.a.* the 40-pin WD1402 and 1402A :-)  I
once knew it well and at one time had an official WD manual for it (I may
still in a filing cabinet)  I believe the chip was added to IEEE's hall of
fame.  In those days, but I've long forgotten the difference between the
original and the "A" version, I think it had to do with the second stop bit
getting being the wrong size when 2 stop bits were defined. IIRC: Getting
the framing right was a common issue with a number of early UARTs
cause shorter chars (5 bits) used 1.5 stop bits, not a full 2.   Sadly
there was a time when I could probably have quoted stuff from that and the
EIA RS-232 >>B<< specs, much less my copy of his now, dog eared book.



> would let you set the data length (5, 6, 7, 8 bits) and the parity setting
> (none, even, odd).  So what you called "8 bits including parity" is
> technically "7 bits with parity".
>
absolutely.  The WD chip could not do space or mark parity.  It was either
none or even/odd.  There were two pins on the chip, one that said to use it
or not, and the other if in used which of the two types.

Which comes back to the OP's question is why I think Tim's comment is the
correct one, you don't want 'mark' parity, if you need parity I would think
that you want to set it to 'even' (see Table D-1 on page 288 of the book)
since I don't think the UART in the KL11 could generate anything but these
three options.




>  If you set your UART for 8 bits with parity, it would send 11 bits total:
> start, 8 data, parity, stop.
>
Yep ...  you are correct that is exactly how the hardware works. mei
culpa.   Although, if we are going to get specific.   There could also
optionally be 2 stop bits.  As I said, the Model 33 used 2 but either 5-bit
gear used either 1 or 1.5.  I think I remember with 5-bit plus parity the A
version generated 1.5 stop bits when the chip was programmed for 2 and the
original sent a full 2 bits.

You are right that I should have been more specific but in all fairness, I
don't know of a DEC OS that supported that setup.  But I'm sure it was
possible and probably for people running PDP-11's as communications
'front-ends' it was done.  The fact is if you ran 8 bits back in the day,
it was usually without parity.  Instead, some other protection was done in
a higher level protocol to protect and/or correct for transmission errors.

If I remember McNamara's book he had a whole chapter on errors and
suggested that parity was popular (almost always used) in early devices,
like the 5-bit Baudot based equipment like Teletypes model 28 and Friden
Flexowriter, and of course as you pointed out the infamous 7-bit Model 33
and 37.  But by the mid to late 70s, i.e. with the glass TTY it started to
fall from favor.   I don't know why, but I would suspect this was because
dedicated lines started to supplant telephone circuit-based connections and
single-bit error detect was not useful.  It did not happen that often.



>
> I've even run into 10-bit UARTs (on PLATO terminals).  But that's not DEC
> stuff.
>
Not surprised, CDC did some very strange things with characters ;-)

Clem
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 - console input with high bit set

[Clem Cole]

On Fri, Jul 24, 2020 at 2:37 PM Paul Koning  wrote:

> The right answer would be a tweak to the console emulation in SIMH pdp11.

Mumble... Paul - I'm not so sure.  While DEC used MARK a lot, there were
places that used EVEN parity a lot also on PDP-11's (Lord how, I hated 20
mA current loop ;-) at least by the time of widespread RS-232C interfaces
it was glass ttys and usually a full 8-bit data path.   7-bit with odd/even
is defined this way:

 bits of data
(count of 1-bits)8 bits including parity
evenodd
000 0 *0*000 *1*000
1010001 3 *1*1010001 *0*1010001
1101001 4 *0*1101001 *1*1101001
111 7 *1*111 *0*111FWIW:  I'm on a Mac and I run a program
called 'Serial' that can do that; but  I thought most of the programs that
simulate a serial connection for the different PC/Windows system have
similar options.  Certainly that was true when I did it with DOS.

Anyway, I think the 'right' answer for simh is to ask the user to use a
serial emulation program that can generate any of: 8-bit no parity, 7-bit
no parity, or 7-bits of data plus an 8th parity bit with any of the 4
parity options:  odd, even, mark (aways 1) or space (always 0).   Seems to
me, simh should bring 8 bits into the simulated serial port and let the SW
running on the system decide what it's going to do with it.

I'm curious to hear what Bob thinks?
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Imlac simulator

[Clem Cole]

On Fri, Jun 5, 2020 at 1:41 AM Lars Brinkhoff  wrote:

> I have been working on an Imlac simulator.

This is so cool.  That's a system I read about but never saw!!
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Earlyish UNIX for the VAX

[Clem Cole]

Please go to: The Unix Heritage Society   (*a.k.a.*
TUHS) and look in the Unix Archives.
All of the sources you are interested in are there, some was raw tapes,
other as distribution kits.
It is organized by the organization that released the distribution.  You
will find most everything there from Unix V0 to 10th Edition including
32V.  We are missing something like MERT and a few of the intermediate
releases such as UNIX/TS; but I think you will find it useful and fairly
complete.  We often have the documentation (such as Mini-UNIX's creator,
Heinz Lacklama donated the the original docs [and all his papers], but he
lacks the original distribution tape).

Note the TUHS mailing list is very active with many of us original folks
that were there at the time (and are still with us)
contributing, correcting history when it sometimes deviates from reality to
legend.  Note there is a companion mailing list (also pretty active) called
COFF - Computer Old F*ts Followers which is supposed to take up the
discussion when it deviates from UNIX specifically.

Have fun...
Clem


On Fri, May 8, 2020 at 4:26 AM  wrote:

> I’ve been doing a little research on versions of UNIX for the VAX
> architecture.
>
>
>
> In the SIMH Software Kits archive there is 4.3-Quasijarus BSD for the VAX.
>
> I also noted the Bell Labs paper here:
> https://www.bell-labs.com/usr/dmr/www/otherports/32v.pdf which I think
> refers to UNIX 32V https://en.wikipedia.org/wiki/UNIX/32V.
>
>
>
> Does this software survive – I appreciate if it was a Bell Labs release
> then it may never have seen the light of day?
>
> Are there any other surviving editions of UNIX that have been successfully
> resurrected using SIMH?
>
>
>
> Many thanks, Mark.
>
> M0NOM 
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Is it possible to simulate the first Vaxen I ever used?

[Clem Cole]

On Mon, Mar 23, 2020 at 3:57 PM Johnny Billquist  wrote:

> The VAX-11/750 used 2901 though...
>
750 was made out of custom CMOS gate arrays.  The main adder was analyzed
as part of my thesis [long story - not for here, but a very clever
circuit.  I would later get to know the guy that did it]. Paul Gilbeau
and Dick Monroe were the main microcoders on the 750.  I'm pretty sure that
Paul was also one of the 780 microcode folks.   Very interesting guy. I
used to say he had a worm's eye view of the world -- perfect for his job as
lead microcoder; but trying to get up a level could be difficult.  I've
lost track of them both, although I still talk to Dave Cane a couple of
times a year and I think he knows how to find most of the HW team.

I'm fairly sure that the 750 used te BLISS based Micro2 tools as Tim
suggested and as I said, we cloned them at Masscomp in C (which later it
went west). Tim, you tell me, I thought the Masscomp version got sent to
the Jupiter team, but I'm pretty sure it was used for Prism.  I remember us
getting a 'bug report' because VAX-11/C didn't like something BSD's yacc
had generated at one of the Hatfield/McCoy parties. I remember changing
what it was and email it the next day.

FWIW:   All of the Masscomp FP/AP and the DACP used that set of microcode
tools since they were all AMD 29xx based.   IIRC, Chuck Palmer overhauled
the original hack we did for Paul and Dick because a few Masscomp customers
wanted to write custom DACP microcode and originally it was not too easy.
 I probably have a manual for that still around and maybe even the tools. But,
since I don't have a DACP on the MC500 I still have,  I never bother
scooping up the tools.

Also, I know that there was an Intel 808x processor (85 I think) that
shipped in the 750, but it was not an FEP.  It was limited to running the
cartridge tape controller.  I don't remember how the console serial port
was done (the 780 it was part of the FEP).  The 750 microcode did the boot
as someone else pointed out.  I've forgotten how the microcode was loaded
on a cold start.   I thought there was something in a ROM/EPROM, but I've
forgotten.  I do know the cartridge tape unit was needed to update the
microcode and that was the only way to do it.  But I don't remember you
need to have the tape on a cold reboot the like floppies on a 780, but I
could have forgotten.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Is it possible to simulate the first Vaxen I ever used?

[Clem Cole]

On Mon, Mar 23, 2020 at 9:33 AM Robert Armstrong  wrote:

>   The 730 was interesting in that ALL of the CPU microcode was in RAM and
> was loaded by the CFE at boot time.  It was possible to locally modify the
> 730 microcode, and DEC even had a set of microcode development tools for
> the 730.


One of my favorite underground engineering stories.

Masscomp forked from DEC and number the folks on the HW and microcode teams
that had worked on the 750/730 ended up Masscomp.  They wanted that set
same set of tools, but it required VMS which were did not have (and we were
not going to run in our 750 and were in BLISS of course).   As a compromise
to the HW team, a couple of us (Terry Hayes, tjt and I IIRC) got a manual
for those tools and with some oral directions from Dick Monroe and some of
the other microcode guys, using awk/lex/yacc *et al* - we cons'ed up a
replacement fairly quickly, of course, running on our 750/BSD and then
later self-hosted on the Masscomps running RTU.

Around the same time, Widdoes *et al* spun SCALD CAD tools out of Livermore
and Stanford creating Valid Logic design (which was a UNIX flavor under the
covers).   Both DEC West in particular and Masscomp started to use Valid
boxes for HW support.   DEC West had written a bunch of macros and tools
that made the Valid easier to use. And our HW guys knew about them.  DEC
West had heard we had new versions of the DEC tools in C and on UNIX.

So one night the Maui Kia parking lot (this is now Yankzee River in
Littleton), a tape swap was arranged.   We gave them our Unix based version
of the microcode tools and we got their additions/updates to Valid.
Management of neither company never knew the difference.

FWIW: I went looking for the tapes of both a couple of years ago, and sadly
I can not find either.  But its one my keep looking list when I get around
to cataloging some of the old SW from those days.

Clem
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] hp alternatives

[Clem Cole]

Here is a pointer to a number of different basics.
https://www.thefreecountry.com/compilers/basic.shtml
It has been a while, but accept for the issue that Kevin mentioned of
lacking the VMS (or TOPS) system services, I have used a couple of these
run some old Vax/PDP-10/RSTS DEC Basic codes.   Vintage and Bywater were
the two that I remember I had to the most success in understanding files
from DEC versions.   I had some programs (games) from a Dad that before he
died I got running on his Mac so he could play them/mess around a little.
 He had dementia at the time but for some reason, he could remember his
running (and teaching) Basic which he learned in the late 50s/early 60s.
He had a hard time with the GUI and I would explain it.   So I got a couple
do them running at the time, and it was good enough for that task.  But
  I have not messed with any of that in 5+ years.

The one thing from my todo list of that time, which I started but never
completed was trying to get a ASR-33 emulator running for him.   I still
want that for simh reasons (like my PiDP-8 and PiDP-11).

On Thu, Mar 19, 2020 at 6:21 PM Kevin Handy  wrote:

> Porting VAX Basic... Sort of...
>
> I have a program that does a bunch of the work to conovert VaxBasic to
> C++, but it doesn't do everything.  There's a lot of stuff that just
> doesn't exist on other OS's, like the SMG, RMS, LBR, etc.
>
> https://github.com/khandy21yo/btran.git
>
> there are probably lots of bugs, and you may need to reformat your source
> slightly (add some spaces in confusing parsing conditions for example). You
> may also need to edit the generated C++ to get it right.
>
>
>
>
> On Thu, Mar 19, 2020 at 8:20 AM E J Jaquay  wrote:
>
>> I have been able to replace RMS indexed files with BerkelyDB without many
>> issues so that is one alternative.  Just have to replace I/O statements
>> with functions that do the appropriate calls.
>>
>> On Wed, Mar 18, 2020, 20:10 Dan Gahlinger  wrote:
>>
>>> is there a way to port vax basic?
>>> please dont say visual basic, it's awful.
>>>
>>> heck even vax Pascal is vastly different from free Pascal.
>>>
>>> dcl? nothing remotely like it really, bash?
>>>
>>> how about indexed files?
>>> rdbms is a poor man's alternative.
>>>
>>> vax vms is truly unique.
>>> and will always be my favorite.
>>>
>>> Dan
>>>
>>> Try: https://www.grammarly.com
>>>
>>> --
>>> *From:* Simh  on behalf of Kevin Handy <
>>> khandy2...@gmail.com>
>>> *Sent:* Wednesday, March 18, 2020 6:44:53 PM
>>> *To:* Simh 
>>> *Subject:* [Simh] hp alternatives
>>>
>>> Since GP is exiting the VMS arena, and dropping the hobbyist licenses, I
>>> was wondering about alternatives for running old VMS code.
>>>
>>> There are plenty of C, FORTRAN, etc compilers on Linux/etc, but if there
>>> were comparable VMS libraries (open source) for things like RMS, SMG, LBR,
>>> etc, then many programs culd be run on other platforms.
>>>
>>> I know there are commercial products like these, BUT The licensing
>>> doesn't help hobbyist who want to share code.
>>>
>>> Are there any of these available? I've done a few functions to convert
>>> VMS calls to Linux calls before, but only for a few functions.
>>>
>>> I just thought it would be another way to simulate some of VMS st
>>> another level than simh/vax/vms.
>>> ___
>>> Simh mailing list
>>> Simh@trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Of DEC and cards

[Clem Cole]

One last reply here, but CCing COFF where this thread really belongs...

On Thu, Feb 13, 2020 at 12:34 PM Timothe Litt  wrote:

> OTOH, and probably more consistent with your experience, card equipment was
>
> almost unheard of when the DEC HW ran Unix...
>
You're probably right about that Tim, but DEC world was mostly
TOPS/TENEX/ITS and UNIX.  But you would think that since a huge usage of
UNIX systems were as RJE for IBM gear at AT  In fact, that was one of
the 'justifications' if PWB.  I'm thinking of the machine rooms I saw in
MH, WH and IH, much less DEC, Tektronix or my university time.  It's funny,
I do remember a lot of work to emulate card images and arguments between
the proper character set conversions, but  I just don't remember seeing actual
card readers or punches on the PDP-11s, only on the IBM, Univac and CDC
systems.

As other people have pointed out, I'm sure they must have been around, but
my world did not have them.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Various

[Clem Cole]

On Thu, Feb 13, 2020 at 11:38 AM Clem Cole  wrote:

> I think I saw a card read/punch only once on a PDP-6 IIRC, but it might
> have been a KA10.   I don't think I ever saw one on a PDP-8/11 or Vaxen.
>
The more I think about it, there must have been one or two in the mill or
the machine room in MRO, but I just can not picture them.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Various

[Clem Cole]

On Thu, Feb 13, 2020 at 10:50 AM Timothe Litt  wrote:

> Among others, DEC OEM'd Documation card readers.
>
> https://www.youtube.com/watch?v=se0F1bLfFKY
>
Mark - sorry to go a little direct (simh) topic here [this sort of belongs
on Warren's COFF mailing list), but since the Card discussion started here
as I'm kinda curious and will ask it.

Did DEC actually sell that many?   In my years of working around DEC gear
starting in the late 1960s, I think I saw a card read/punch only once on a
PDP-6 IIRC, but it might have been a KA10.   I don't think I ever saw one
on a PDP-8/11 or Vaxen.

I certainly saw and used them on IBM 1401/360 systems, the Univac 1100s and
CDC's.  I have not so fond memories of the IBM 1442, much less a 26 and 29
keypunch (and a couple of great stories too).

That said, when I think of DEC gear, my memories are of paper tape or
either the original DEC-Tape units or a couple of cases the old
cassette tape units DEC had on some of the laboratory PDP 11/05s.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] load

[Clem Cole]

One other thought - it will likely take a little work, by years ago Jim
Reeds of UCB took the old Harvard Macro11 and Link11 tools from the
original 1977 USENIX distribution tape and hacked on them/updated them for
2BSD.   The important thing for you is he rewrote the linker into C (the
originals were in Macro11).   IIRC, his linker takes DEC PDP-11 *objs and
creates a.out.   You have to look at the sources for yourself, but that
might be a starting point for something like what you want.   For the
linker check out:
https://github.com/eunuchs/unix-archive/tree/master/PDP-11/Trees/2.11BSD/usr/src/new/l11
The assembler is called m11 is ../m11

Clem

On Fri, Jan 24, 2020 at 6:27 PM Kevin Handy  wrote:

> I was watching some youtube videos about the PiDP-11, and they all seemed
> to end up typing in a hand-assembled program into the emulator.
>
> It got me  to thinking about the macro11 assembler in simtools, however
> that program only appears to output object files, not binary ones. simh
> appears to only accept binary filesm not object files.
>
> Is there some way to bridge the gap? Is there some method to bridge he
> gap? marco11 to output binary files, a linker to convert object files to
> binary ones, or simh to accept object files.
>
> For the PiDP-11 users, they could prooblbly work from a listing where a
> hard-coded base address is given, but others might want to try something
> that is too long to want to key it in.
>
> If this is already possible, some documentation on the process would be
> useful. This would also make simtools more useful.
>
> This applies to all the other emulations that have assemblers available
> also.
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] XKCD!

[Clem Cole]


ᐧ

On Tue, Oct 29, 2019 at 3:16 PM Larry Stewart  wrote:

> https://xkcd.com/2221/
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] tty magic(?) for talking to bootloaders?

[Clem Cole]

Using it as you have is very cool; but as Lars mentioned, the other
important point is that using expect(1) framework outside of simh, means it
will work for other emulators and other things.

FYI: the idea of 'expect' was first part of the UNIX uucico program to do
the 'chat' portion of scripting needed to 'login' into a remote site.  By
1990,  Don Libes of NIST realized it was a pretty cool and general idea,
and broke it out to an external program (IIRC he used tcl under the covers
and parroted the code from uucico in his new tool): "expect: Curing Those
Uncontrollable Fits of Interactivity" by Don Libes, Proceedings of the
Summer 1990 USENIX Conference, Anaheim, California, June 11-15, 1990

I had not realized that Mark had brought the idea into simh as
sub-system/command until this exchange (which is cool.  A great idea, great
use - kudos!!).  In any case, now that you understand the idea for simh,
you can also use the general tool for other things.   There is even an ORA
book on writing expect(1) scripts.  FWIW: I have a few expect(1) scripts
for some of the more mundane things that need to be automated from time to
time.  But thanks to a real command system and tools like expect, it is
possible to automate them, which reminds me why I hate often hate GUIs
which can be tougher to automate.   FWIW: I'm pretty sure expect(1) has
been moved off of UNIX to some other platforms like VMS and DOS/Windows;
but I have not tried using it there.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] tty magic(?) for talking to bootloaders?

[Clem Cole]

Try using expect(1).   Write an expect script to do the basic boot.  That
will no matter the os or simulator.   Once you get to the point you want
you can give control back to the terminal.

On Sat, Sep 21, 2019 at 7:03 PM Tom Perrine  wrote:

> Hi all,
>
> So far I've got Multics, V7 and BSD4 running on SIMH in Google Cloud
> Platform (GCP). I'm packaging some of these up into more turnkey images and
> scripts so that more people can easily play with these Grand Olde Operating
> Systemes.
>
> My end goal is a script that can be run on your local computer that
> creates the cloud instance, installs and upgrades the OS, compiles SIMH for
> the target HW, and boots the guest OS, all without any needed input. I've
> got everything EXCEPT how to kick the OS boot in the OS bootloader(s).
>
> My problem is that I probably haven't spent enough time with the docs to
> figure out how to feed scripts "past" SIMH and into the bootloaders.
>
> I'd also love to be able to inject commands into the SIMH process through
> the API, but that's a different story.
>
> For example, the PDP-11 V6 boot looks like this:
>
> test-pdp11:~$ !80simh-master/BIN/pdp11 dboot.ini PDP-11 simulator V4.0-0
> Current git commit id: d40268d1Disabling XQ@
> Now how do I get scripted input into the simulator so that I can give the
> bootloader the "unix" filename at the @ prompt? I have the same problem
> with the Multics bootloader, too.
> Clearly I'm not being smart this week.
> Ideas?
> --tep
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-- 
Sent from a handheld expect more typos than usual
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Fwd: VAX + Spectre

[Clem Cole]

Paul - be careful.  All CPU's post the IBM AGS that used branch prediction
are suspect.   Russ Robelen (who was the 360/50 lead, worked on 360/90 and
lead AGS) has the speculative executing patent.   I tweaked him when it all
came out and said - look at what you did.

What Russ and team are great ideas and we all have used them since they
first published about it.   And the fact is that it took 40 years before
someone even proposed that it was an issue and could become security
exploit (by some folks in German at a security conference) and it Google 18
months to reduce it to practice.
ᐧ

On Tue, Sep 17, 2019 at 9:55 AM Paul Koning  wrote:

> "Spectre" is one of two notorious bugs of modern CPUs involving
> speculative execution.  I rather doubt that VAX is affected by this but I
> suspect others here have a lot more knowledge.
>
> paul
>
> Begin forwarded message:
>
> *From: *co...@sdf.org
> *Subject: **VAX + Spectre*
> *Date: *September 17, 2019 at 5:32:42 AM EDT
> *To: *port-...@netbsd.org
>
> So, this is a bug report:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811
>
> GCC would like to know if VAX needs Spectre-related work.
> Are any of the VAXes ever made capable of speculative execution? the
> first tech for doing it was in 1967, so not entirely far-fetched.
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] going back to the VAX console with CTRL P

[Clem Cole]

Nelson (and Mark),

IMO, this is the issue with in-band systems.  No matter what you pick, it
is going to conflict with something.  ^P was an issue on the vax console.
Hey ^S/^Q being 'in-band' has always been an issue for lots of things
(which is why us UNIX types used DH11's with RTS/CTS handshaking for our HS
modems - particularly the Able versions that did the handshake with an AND
gate for you and avoid DZ's which can do it].

I don't have an issue with Mark's basic default choice, given that 780
grabbed ^P in the PDP-11 front-end SW.  He can support switching to ^P.
It's not really the vax console, it's simh's console mind you; but that
because we are not 100% simulating the vax console since most of its
features are handled by simh itself [which is in practice, ok, but it is
actually differ].


So  [mind you I'm not complaining - just noting how this could be even
better] 

What I would like to see at some point is to have simh move to a 'simh
console' which is 100% separate from the simulated system console [*i.e*.
moving simulator's console port a TELNET session with the command:
sim> SET *SIMH**CONSOLE *TELNET=listenportnumber
] *as the default*.   Then what is currently the console port becomes the
host console and the simulation is of whatever the HW did on that console
port.

Then when you start you, say make the default port 3030, the simh command
forks off a new shell/terminal window/etc with the connection [since, I'm
dreaming, I'd like to see that be sshd(1) style connection not telnet, but
I digress]. FWIW: this is a little different from what Mark does now BTW -
I believe he moves the simulated host's console to the telnet port.  By
switching, you set setting up a means to set up an optional programatic way
to control simh - which I will explain in a minute].

If start up like this were a tad more automatic, everything on that path is
'out of band' to the simulated system and only commands to control simh go
down it (like Mark's current scheme with SET CONSOLE). The simulated hosts
'system console' is a different connection (the original tty connection).
In this case, if the simulation is 780, the connection to the 780's real
console has ^P is simulated the way the original VAX did it, which would
take you a simulation of the original  >>vax<< console commands since it is
not the simh console. It works 'just like the 780' did.

But if you move the simh console it means eventually you can more easily
build a 'lights and switches' ('blinkenlights') without have to hack simh.
You can use that simh 'console' by typing, or as real console *ala* PiDP-x,
or create an X-windows simulation of the lights/switches.  The cool part is
that simh - wouldn't care if a human is typing or the if the simh 'control
commands' are coming from a program [I believe that Oscar has some of this
in his stuff, but its not all there yet].

I also think if such a scheme were the 'default' and people though in those
terms, we might be able to get more and more "front console" simulators of
the old systems created.

Anyway - its a thought ...  as I said, not a complaint, but it seems like
switching it around offers easier options for more of the different
simulators.

My 2 cents...

Clem
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Disk Technology was Which PDP-11 to choose

[Clem Cole]

We really should take this off-list if you want to continue the discussion
as it has little to do with simh and more history (so I'm CCing the TUHS
COFF list.  I'll include simh for now, but if you reply please kill the
simh part).

 An Eagle or Eagle-II was a whole lot lighter (and physically smaller) than
an RP06 or RP07 (or an RM series drive for that matter). It is interesting
to hear you had problems with the Eagles.   They were generally considered
the best/most reliable of the day.   The SI controller on the Vax was less
so, although many of us in the UNIX community used them.

FWIW: I was accused of jinxing the 19" SMD Ampex drive by Masscomp's field
service team.   The story is we could never make the Ampex drives work
reliably at UCB (they were cheaper in bytes/$ than the Eagles at the
time).   When I was being recruited to Masscomp as I was leaving UCB, they
were trying to use Ampex as their high-end SMD drive with the Xylogic 440
controller, but had not (yet) had a failure. [Xylogic, like Masscomp, was
ex-DEC folks]. Anyway, I had mentioned @ UCB we had given up on the Ampex
drive on our Vaxen, and within 2 weeks of my starting to work darned near
all of them that Masscomp owned had failed.

PC (Paul Cantrell), tjt and I did eventually make them work but only after
we got Xylogic to redesign the 440 to be the 450 controllers and PC spend
hours with the microcode team on the error recovery logic.  Funny, the
450/Eagle combination (and later Xylogic 472 tape)  became the de rigor in
the UNIX community.

BTW: if Mark and the simh team is to ever to create a solid
Sun/Masscomp/Apollo simulator, they will need to emulate the Xylogic
controller family.   One more thing for the forever growing list of things
I'd like to do when I retire, but I think I still have the engineering
specs for them and PC and tjt are still to be found ;-)

On Mon, Jul 1, 2019 at 9:19 AM Tim Wilkinson  wrote:

> Back in 85 have had applications to purchase a 785 – 780-750-730 then 725
> rejected, we were fortunately given a 750 by a sister company who were
> upgrading to a 785, but they took their disks. So we had to buy for
> ourselves.
>
>
>
> To keep the bean counter happy we went for a System Industries controller
> and 4 super Eagles.
>
>
>
> But back then there was a problem with the eagles and all 4 had to be
> swapped out 4 times.
>
>
>
> Carrying them up stairs to the computer room was not fun. The platter size
> may have been reduced. But the weight!!!
>
>
>
> Tim
>
> *From:* Simh [mailto:simh-boun...@trailing-edge.com] *On Behalf Of *Clem
> Cole
> *Sent:* 01 July 2019 14:08
> *To:* Patrick Finnegan 
> *Cc:* SIMH 
> *Subject:* Re: [Simh] Which PDP-11 to choose
>
>
>
> I can not say why it followed that naming convention, but it did.   The
> drives of that day were referred to as 19" technology since that's how they
> mounted.   FWIW:   Most manufacturers at the time used the same platter
> size as the original IBM 1311 (which as you pointed out was 14"), but not
> everyone, for instance, the Fujitsu Eagle used 10.5-inch platter.   FWIW:
> I answered a bunch of this in:
> https://www.quora.com/How-do-hard-drives-get-smaller-and-smaller-in-size-bigger-and-bigger-in-capacity-every-year-when-the-fundamental-physical-processes-behind-them-do-not-change/answer/Clem-Cole
>
>
>
>
> On Mon, Jul 1, 2019 at 8:52 AM Patrick Finnegan 
> wrote:
>
>
>
>
>
> On Mon, Jul 1, 2019 at 7:32 AM Clem cole  wrote:
>
> 19” form factor for the disks drive fir the space in the 19” relay rack.
> You’re right the platters themselves were smaller.  The disks were referred
> too by the mechanical FF.  19, 8, 5.25 etc.
>
>
>
> But, 8" hard drives have 8" platters, and 5.25" hard drives have 5.25"
> platters. The casing on a the 5.25" drive in front of me is almost 6" wide.
>
>
>
> Pat
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
> <#m_1729574511750107707_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Which PDP-11 to choose

[Clem Cole]

I can not say why it followed that naming convention, but it did.   The
drives of that day were referred to as 19" technology since that's how they
mounted.   FWIW:   Most manufacturers at the time used the same platter
size as the original IBM 1311 (which as you pointed out was 14"), but not
everyone, for instance, the Fujitsu Eagle used 10.5-inch platter.   FWIW:
I answered a bunch of this in:
https://www.quora.com/How-do-hard-drives-get-smaller-and-smaller-in-size-bigger-and-bigger-in-capacity-every-year-when-the-fundamental-physical-processes-behind-them-do-not-change/answer/Clem-Cole


On Mon, Jul 1, 2019 at 8:52 AM Patrick Finnegan 
wrote:

>
>
> On Mon, Jul 1, 2019 at 7:32 AM Clem cole  wrote:
>
>> 19” form factor for the disks drive fir the space in the 19” relay rack.
>> You’re right the platters themselves were smaller.  The disks were referred
>> too by the mechanical FF.  19, 8, 5.25 etc.
>>
>>
> But, 8" hard drives have 8" platters, and 5.25" hard drives have 5.25"
> platters. The casing on a the 5.25" drive in front of me is almost 6" wide.
>
> Pat
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Which PDP-11 to choose

[Clem cole]

19” form factor for the disks drive fir the space in the 19” relay rack.  
You’re right the platters themselves were smaller.  The disks were referred too 
by the mechanical FF.  19, 8, 5.25 etc.   

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Jul 1, 2019, at 12:07 AM, Eric Smith  wrote:
> 
>> On Sun, Jun 30, 2019, 19:37 Clem cole  wrote:
>> You can use RH70 (massbus controllers) and just use the larger (originally 
>> expensive) 19” disks from the early days. 
> 
> 
> 14 inch, but who's counting.  :-)
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Which PDP-11 to choose

[Clem cole]

Btw.  The biggest advantage of the later model qbus systems is some larger but 
cheaper scsi options  that dec released later in life but none of that has ever 
mattered to me in practice when running simh.  You can use RH70 (massbus 
controllers) and just use the larger (originally expensive) 19” disks from the 
early days. 

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Jun 30, 2019, at 8:52 PM, Will Senn  wrote:
> 
> All,
> 
> Is there any particular reason to choose one model of PDP-11 over another in 
> the sim? I am a user who is usually only interested in using one of the 
> various programming languages available on the dec oses - I frequently use 
> RT-11 for BASIC or ASSEMBLY and Unix V6 and V7 for C and for fun, as well as 
> an occasional foray into RSTS-E and lately RSX 11-M Plus to try and find the 
> perfect OS for as many programming languages as I can get in one place. In my 
> language/os explorations, I generally just grab somebody's example ini file 
> or take a default machine 11/40 or 11/94, but it's been pretty will-nilly on 
> my part. I'd like to have some kind of rationale related to necessity, but it 
> doesn't really seem to make much difference. I know the 11/45 had split I/D, 
> making it 'better' than the 11/40 and that the unibus is different than the 
> q-bus and I'm sure the hardware support is different between the models, but 
> I haven't really been prevented from running anything that is runnable... but 
> of course, if I was prevented, I just chalked it up to who knows why that 
> didn't work, so I might never know if I'm missing out on the El Dorado of 
> ancient OSes. Does anyone have some guidelines to help choose which model 
> configuration is appropriate for various needs? Or, in this day and age of 
> endless supplies of ram and memory, should I just load it up to the biggest, 
> baddest, pdp-11 of all time and leave it at that (and if so, which one is 
> that?).
> 
> Thanks for the assist.
> 
> Regards,
> 
> Will
> 
> -- 
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
> 
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Which PDP-11 to choose

[Clem cole]

IMO if you want to program the system split ID is helpful as 64k is very small. 
 Thus the 11/70 or 11/44 are my go to systems.  Your call.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Jun 30, 2019, at 8:52 PM, Will Senn  wrote:
> 
> All,
> 
> Is there any particular reason to choose one model of PDP-11 over another in 
> the sim? I am a user who is usually only interested in using one of the 
> various programming languages available on the dec oses - I frequently use 
> RT-11 for BASIC or ASSEMBLY and Unix V6 and V7 for C and for fun, as well as 
> an occasional foray into RSTS-E and lately RSX 11-M Plus to try and find the 
> perfect OS for as many programming languages as I can get in one place. In my 
> language/os explorations, I generally just grab somebody's example ini file 
> or take a default machine 11/40 or 11/94, but it's been pretty will-nilly on 
> my part. I'd like to have some kind of rationale related to necessity, but it 
> doesn't really seem to make much difference. I know the 11/45 had split I/D, 
> making it 'better' than the 11/40 and that the unibus is different than the 
> q-bus and I'm sure the hardware support is different between the models, but 
> I haven't really been prevented from running anything that is runnable... but 
> of course, if I was prevented, I just chalked it up to who knows why that 
> didn't work, so I might never know if I'm missing out on the El Dorado of 
> ancient OSes. Does anyone have some guidelines to help choose which model 
> configuration is appropriate for various needs? Or, in this day and age of 
> endless supplies of ram and memory, should I just load it up to the biggest, 
> baddest, pdp-11 of all time and leave it at that (and if so, which one is 
> that?).
> 
> Thanks for the assist.
> 
> Regards,
> 
> Will
> 
> -- 
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
> 
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RP/RM differences in header commands (for ITS, salvager)

[Clem Cole]

FWIW:   When Ted and I wrote fcsk in the mid 1970s, (after some arguing
about assuming perfect media) we added the notion of a bad block list to
the assign to the bad block file (it was not in the original code), but we
knew nothing about BAD144 at the time since we both were students.   Ultrix
[and Tru64] was later fixed (early 80s) to obey BAD144 (thank you, Fred
Canter).   IIRC, that part of the Ultrix code got sent back to UCB and
showed up in some later versions, but I've forgotten.   As I recall, the
Unix driver was modified after getting a bad block error from the
controller, to mark the block as bad and pick a replacement from BAD144.
 The problem was that the caused stray seeks under the covers after the
reformat.

I remember having a conversation with Fred at one time approx 1981-2 ish,
about not doing the replacement at all if the block was in the free list,
then assigning to the bad file so the seeks never occurred (*i.e.* creating
perfect media - which is what UNIX assumed).  I've forgotten the result of
that conversation.
ᐧ

On Fri, Jun 28, 2019 at 9:46 AM Paul Koning  wrote:

>
>
> > On Jun 28, 2019, at 3:07 AM, Johnny Billquist  wrote:
> >
> >> From a hardware point of view, sector header "Word 3" and "Word 4" have
> >> no particular meaning.  Just for completeness, can you point me to a
> >> reference where "pack number" is defined or used by the software?
> >
> > Search for DEC standard 144. If nothing else, I think there is a
> description in the RL11 documentation. (Me trusting my memory once more...)
>
> That's different, though.  It describes the bad block table, which
> includes a pack serial number in its header.  Some device types use 144,
> some do not (in particular, on RP/RM there is a mix -- RP04/5/6 do not,
> RP07 and RM02/3/5/80 do).  The 144 table is purely a software construct, a
> bit of data placed by convention in the last few sectors of the drive and
> interpreted by the OS.  For example, in RSTS the bad block table is read to
> mark those blocks as unavailable, and the serial number is read and
> displayed during formatting but not otherwise used for anything.
>
> paul
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Limits on MSCP controllers

[Clem Cole]

On Mon, Jun 24, 2019 at 2:13 AM Timothe Litt  wrote:

>
>
> MSCP is basically an evolution of the Massbus protocol, on a different
> PHY, and informed by the TOPS-10/20 experiences with high-end  (large,
> redundant, on-line serviceable) configurations.
>
That was certainly my impression/memory.



> ...
>
> SimH is really about preserving the ability to run legacy software, not
> slavishly implementing hardware.  As Bob has documented, there are
> certainly cases where an OS depends on low-level hardware design.  In those
> cases, strict fidelity matters.
>
Amen

>
>
> Note also that as a rule, SimH does not implement hardware features unless
> some OS requires them - this is especially true of maintenance/diagnostic
> features.  There are also subtle differences - e.g. an OS under SimH may
> carefully order & fence disk writes to ensure file system consistency in
> failure cases.  But while SimH will present them in order to the host OS,
> the host OS and/or hardware may not have the desired semantics.  (E.g. due
> to caching, position optimization.)  Bob & I had many discussions (and
> differing opinions) about how important these effects are in the very early
> days of SimH.  (While we were still at DEC...)  The decision was to ignore
> these issues - even with host OS support, there's no good way to divine the
> legacy OSs' intent and pass it on to the host.  Here SimH performance
> trumps fidelity.
>
And I for one admire how well you (Mark, Bob, Tim et al) have done over the
years.   It's a tough thing .. but I think the high order bit for design is
to ensure legacy SW keeps running.  Additions to the simh kit seem like it
should be to support real HW and real SW from the past.   This means is VMS
or UNIX or whatever supported it, simh needs to try to provide support for
it.   The issue, of course, as Bob pointed out, is 3rd party much less CSS
HW.   Many legacy systems did support both, but often neither was well
documented.  If adding things like a KS-11 (CSS) or support for an
ENABLE-11 (Able computer) can be done, that's a good thing, provided it can
be well documented.  Then standard distributions can run.

Adding support for HW that never existed I have a harder time with
frankly.   The argument in favor is to allow native support for more modern
HW without having to map if >>if<< someone can write the support for both
simh and the OS in question.  But that strikes me as a 'nice to have' and
not something I worry too much about personally.

Anyway - my thoughts..
Clem

ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Creating a blank (NOVA) disk image

[Clem Cole]

Stephen,

You did not ask how to create a larger file or if you want to know how to
format a DG disk for the OS like RDOS.   You also did not say what system
you are using to run simh.   The reality is that I would not think that
simh would care, as traditional C semantics on the 'create' system call
will make the entry for the disk in the file system, but until writes are
performed, the size is not determined.   The seek system call allows you to
seek beyond the end of the file and extended the size of the file as
needed.  I say this because simh, which is a C program, should behave that
way and thus not care.

If however, you think this is a problem, with any UNIX flavor (or if you
are using Win-10, WSL includes the standard UNIX utilities), if you type:
dd if=/dev/zero of=disk0.6103 bs=1M count=25
This will create a 25M file and zero fill it (according to the
http://simh.trailing-edge.com/nova.html the DG 6103 is a 25M file, you
could also make it larger or small as appropriate, but I think you get the
idea).

How to create a DG file system on it, will take booting the simh, Nova
emulator and running the DG utilities on that file after it was created.
ᐧ

On Mon, May 20, 2019 at 5:26 AM Stephen Merrony  wrote:

> Can someone remind me how to create a blank disk image file for use with
> SimH?
>
>
>
> I tried the following…
>
>
>
> set DKP0 6103
>
> attach -n DKP0 disk0.6103
>
>
>
> …but it just creates a zero-length file which is no use.
>
>
>
> Thanks,
>
>
>
> Steve
>
>
>
> *---*
>
> *Steve MERRONY*
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Imaging SCSI HD's

[Clem Cole]

I love Mark's solution in the theory, but the systems I have that continue
to have solid SCSI support don't have a copy of simh, nor enough local disk
for the output.   What I have done in the past is something on the order of:

dd if=/dev/RSCSI_DISK ibs=VERY_LARGE obs=4k conv=sync | ssh
remote_sys dd of=/tmp/vdisk.dsk ibs=4k obs=VERY_LARGE

The reason for the obs=4k is to keep the network block size under control.
 Depending on source and destination.   Blocking then becomes what is right
for the system (on something like a Vax or early x86 based bus maps, they
can only do 64K bytes of DMA at a time even if the host has more memory, so
even if you put a larger block, it's not clear you will get much more speed
up, and the OS how to clear our memory for the I/O, so it becomes a trade
off -- i.e. YMMV)

Now I have a/couple of different version(s) of dd I dug up/rewrote years
ago called ddd - double dd  (before gnu's Debugger existed BTW).  The
original ddd used to UNIX processes the swap back and forth controlled via
a pipe (you can find it in the UUNET archives I want to say around 1985),
but my newer versions used can use threads of some sort if the local UNIX
supports MxN user mode threading, or async I/O is that was supported as the
threading overlap tends to be more efficient in the kernel itself, but the
idea is the same - you want as much I/O overlapped as possible.   [I
originally did this to fully stream tape drives in the bad old days of a
10Mhz 68000 are the processor.  We ran:  dump -f - | ddd of=/dev/rmt0
ibs=20b obs=64k ].


ᐧ

On Sun, Apr 21, 2019 at 5:37 PM Mark Pizzolato  wrote:

> On Sunday, April 21, 2019 at 11:28 AM, Zane Healy wrote:
> > I have a DL380 on the way to add to my ESXI cluster here at home.  As a
> result
> > I’m looking to finish virtualizing my DEC HW.  What is the best way to
> convert
> > a physical SCSI HD to a disk image for SIMH?  I need to do this for both
> VAX
> > and PDP-11.
>
> If these are SCSI disks, AND you have a host system with a SCSI host
> adapter
> that can connect to these disks (i.e. it is the correct SCSI width, and
> type),
> then you can do this directly using simh from the host system.
>
> Warning: If  you try to do this under some complicated set of layered
> virtual systems, then you are on your own (recall your VNC experience).
>
> Depending on your host system the OS will have some name for the
> above mentioned SCSI disk(s) which you've connected.
> When you connect these disks to the host system, BE SURE not to
> perform any action on these drives BEFORE you let simh see them.
> Be sure you identify the raw device name that the OS sees the newly
> connected SCSI disks as.  Knowing that name the following should work
> with a VAX or PDP11 simulator.  Note that this will probably have to
> be done as root in order to access the physical devices.
>
># vax
>sim> ATTACH RQ0 -c  disk1.vhd
>sim> DETACH RQ0
>
> This will produce a "disk1.vhd" container file with all of the bits that
> can be read from the original SCSI disk.
> Repeat as necessary for each original disk.
>
> > One of the main systems that I want to Virtualize is a VAXstation 4000/60
> > with a BA350 shelf.  The only HD connected to the system is a RZ28-VA SBB
> > (2GB) as DKA200:, so yesterday I added a RZ29-VA SBB (4GB) as DKA100:.  I
> > setup Standalone Backup on the RZ29 and booted into Standalone backup.
> >
> > I tried to run the following:
> > backup/image/verify dka200: dka100:[00]20190420-system.sav/sav
> >
> > I ended up with a very strange “No valid storage bitmap found” error,
> and it
> > failed to copy anything.
> >
> > Facility: BACKUP, Backup Utility
> > Explanation: Software bad block data is not present on the volume. The
> > volume has been initialized with no bad blocks.
> > User Action: Execute the Bad Block Locator utility before using the
> volume.
> > NOBITMAP, no valid storage bitmap found on 'device-name’
> >
> > I tried ANALYZE/MEDIA, but may not have been doing things right.  This
> is a
> > Genuine RZ29-VA, but it was originally used as part of a disk array for
> a Sun
> > Sparc system.
>
> This exercise will merely put a backup saveset on another disk which I
> don't
> see getting you very far towards making it accessible from simh.
>
> Meanwhile, I suspect you are seeing a failure under standalone backup due
> to the fact that after you added the DKA100 disk drive to the system you
> didn't initialize the disk.  You can't initialize a target disk under
> standalone
> backup, so you'll have to do that with full VMS running before you attempt
> the backup again.
>
> - Mark
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Help with loading vax82b zip file into simh/vms

[Clem cole]

Phil,

The terms originated in the IBM 360 “principles of operation” book which I have 
here for the model 67. To wit: “instructions operate on units called 
halfword (2 bytes), fullword(4 bytes), doubleword (8 bytes), quad word (16 
bytes).  FWIW The IBM ‘storage block’ was 2048 bytes which was different 
from what DEC and much of the rest of the world used.  Also the 67 used a 2 
block (4096) byte page size.  

Also, my friend Russ Robelen (360/50 hw lead) says we can credit the 8 bit byte 
to Fred Brooks.  According to Russ, Amdahl wanted a 6 bit byte (like Cray was 
using at CDC) but Brooks kept throwing out of  his office and told him not to 
come back until ‘everything was a power of 2.’   Supposedly Amdahl thought it 
was a waste of HW but Brooks told him unless it was a power of 2 he couldn’t 
program it.  Amdahl did get a 24 bit address size but Brooks made him store it 
in a ‘full word’ which Gordon Bell later has been said to have been what saved 
the 360 architecture.  

Clem
 
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Apr 5, 2019, at 6:33 PM, Phil Budne  wrote:
> 
> Johnny Billquist  wrote:
>> In DEC terminology those are words.
>> It goes: byte, word, longword, quadword, octaword. (8, 16, 32, 64, 128 
>> bits.)
>> Halfword is something that I first saw on Motorola 68K, but maybe it's 
>> been used elsewhere as well. But it feels wrong to use that terminology 
>> on DEC systems.
> 
> Well, in the DEC VAX world!
> 
> I came from the DEC world of 36 bit words, and 18 bit halfwords.
> 
> I was a member of of the SAFE project, a 64-bit VAX datatype
> compatible RISC machine led by Alan Kotok (the KA10 designer).
> Instructions were named by how many bits they operated on.  When
> Cutler absconded with the project and renamed it PRISM, they replaced
> 8/16/32/64 with B/W/L/Q.
> 
> Morons.
> 
> Phil
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Clem Cole]

Will here is your answer:

*... I also put together a bunch of games I had written and collected from
others and put them into a book, 101 Basic Computer Games. Six years later,
in 1979, this became the first million-selling computer book ever."*

ᐧ

On Mon, Jan 21, 2019 at 6:09 PM Al Kossow  wrote:

>
>
> On 1/21/19 2:51 PM, Tim Shoppa wrote:
>
> > As to which came first, the book or the tape
> Some background on Ahl and where this comes from is here:
>
>
> https://www.atarimagazines.com/creative/v10n11/66_Dave_tells_Ahl__the_hist.php
>
>
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Clem Cole]

On Sun, Jan 20, 2019 at 6:46 PM Will Senn  wrote:

> Sorry to dredge up an old thread, but I’m curious as to the provenance of
> the tape.
>
An interesting question that I think that is going to be very hard because
of time and what we now call 'Open Source.'   I personally consider Ahl as
the editor and collector of those games; not the author as the fact is
versions of many of them ran of non-DEC systems before he wrote the book.
My first introduction to computers was in my father's office running
Darthmouth BASIC under GE Mark III on an ASR33 in the later 60s.   Dad was
teaching Math and a intro to computer course at a prep-school in LA and
then in a different school outside of Philadelphia starting in 67.

The game I personally liked the most was the Horse Racing game on the GE
Mark III.  We played a number of them when we were allowed too, as a 12
year old those games were magical.  It is also what got me interesting in
computing and how a computer worked.   I must have studied the sources to
'Races' for hours, asking my dad questions.   I was so proud when I wrote
my first ( BASIC ) program; shortly there after.

Another data point, a year or so later, to save money my Dad switched the
school in Philly from GE  to an HP2000 timesharing system from a local
provider (who's name I do not remember). One reason, I remember is that he
was able to increase our access to three ASR33's instead of one (110 baud,
dial-up with an accostic coupler for the phone) for the same budget.

But to your question, pretty much the same games from the Mark III were on
the HP system too, definitely Races, Blackjack and a Poker game too (there
were others too but those where what stuck in the brain of the 12 yr old
me).   I also remember Dad had an account on a PDP-10 of some type which we
could use for special project that did not work well on the HP.  I was
starting to try actually to do real math on the computer and was trying to
write an root solver using newton's method (in BASIC and later HP2000
assembler).  But along the way, I saw the first versions of the DEC BASIC
on the PDP-10.

The DEC version of Basic was different/more advanced then Dartmouth Basic
of the HP 2000 and GE -- DEC had added some level of typing, i.e. 26
integer variables and number of other extensions, maybe more dimensions for
arrays (I've forgotten the details) than the original Dartmouth Basic had.
But when Dad got me my first PDP-10 account, I remember one of the first
things I looked for was the games directory, and most of what I had seen
before on the GE and HP systems was there also.

FWIW: I later saw Ahl's book from Digital Press in college and thought it
was pretty nifty.  It was eventually republished by someone else (maybe
even number of times), but I did not buy a copy of it until much later and
was from one of those editions.   In fact, I may have still have my old
copy; although the version was after it had been translated to the
Microsoft Basic for the Apple and CP/M systems on the early 1980s (which
were all based on the DEC dialects with their extensions, not the simplier
pure Darthmouth - 'Kemeny and Kurtz version
' of
the 1960s).   As other have pointed out, even DEC the dialects were
sometimes a little different between each other - that was normal in those
days.Funny, by the time I had the money to be able to buy the book, I
had started to lose interesting in playing games on the computer, or for
that matter writting them and I had definitely drifted from BASIC.  But
running BDS C on a CP/M machine was harder and so many things just used
basic at that point; plus I did not yet an C compiler for my Apple II which
I was then using more as a terminal to remote UNIX boxes.

Anyway, the point is that simple computer games in BASIC were being passed
around between people (as paper tapes), particularly if you had acccess to
multiple different brands of computers.You always had the source code,
in those days so it was really not big deal.  In fact, my memory is that
one of the new things that you could do on the PDP-10 was >>compile<< your
basic program, or at least leave it in some form that some one could not
see what you had done.   But the HP and GE system, you just loaded the
program and typed 'list' - often after turning on the paper tape punch the
ASR33.

Clem





ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Historical gaming devices

[Clem Cole]

Right, the 12 had A/D and joystick - the later is actually why the original
Masscomp system had a joystick, not a mouse (a separate story - WRT's the
12's HW lead, the late Lorin Gale).   There might be an ISPS description of
it somewhere.
ᐧ

On Mon, Jan 14, 2019 at 5:17 AM Pontus Pihlgren  wrote:

> Hi
>
> It has been discussed before, but the PDP-12 had one or two ports of
> Spacewar as well. While there is no support for the PDP-12 in simh, I
> think similar A/D equipment was available for the PDP-8 to attach
> controllers.
>
> Perhaps something to look into?
>
> Regards,
> Pontus.
>
> On Mon, Jan 14, 2019 at 09:05:59AM +, Lars Brinkhoff wrote:
> > Hello,
> >
> > I'm adding simulations of some historical gaming devices to SIMH:
> >
> > - PDP-6/10 Spacewar consoles.  Five switches, times four players.
> > - PDP-6/10 A/D converter.  Not really gaming, but used for games.
> > - PDP-11 Dazzle Dart boxes.  Eight switches, times four players.
> > - PDP-11 Galaxy Game?  I haven't looked at this yet.
> >
> > The SDL2 library used by sim_video provides inputs from USB joysticks
> > and game controllers.
> >
> > If anyone knows about any other similar devices, I'd like to take those
> > into consideration.
> >
> > ___
> > Simh mailing list
> > Simh@trailing-edge.com
> > http://mailman.trailing-edge.com/mailman/listinfo/simh
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating Fortran

[Clem cole]

Will

Let’s take this offline.  I think I can talk you through this.  Clem

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Dec 29, 2018, at 6:51 PM, Will Senn  wrote:
> 
> Hi all,
> 
> I’m looking for a good lead on two things - 1. A fortran environment for 
> learning the language as it existed in the  research unix v6/v7 era (roughly 
> late ‘70’s). 2. A good text/book to guide the way toward building and running 
> fortran programs successfully.
> 
> I’m a little lost in the sea of possibilities- v6’s fortran however good that 
> is... v7’s, rt-11’s, etc.  etc. 
> 
> My bonus question is, was there a point of time in the late 70’s where a 
> stable situation existed and most folks used system X with FXX? If so what 
> system with which dialect, and is it accessible as a simh environment?
> 
> Regards,
> 
> Will
> 
> Sent from my iPhone
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Systems Engineering Labs (SEL) simh simulator available

[Clem Cole]

On Wed, Dec 26, 2018 at 7:03 PM David Brownlee  wrote:

> Well, Joyent also makes binary pkgsrc packages for SmartOS, macOS, and
> CentOS/REL :) https://pkgsrc.joyent.com/
>

xkcd on standards   sigh.

Note: I have lived this issue at Intel for +10 years BTW [we make a very
slick set of development tools that are compatible across different
OS's]

So I will step on top of Soap Box 

As I often have to remind some of our more our engineers at work *installs,
particularly binary installs, must be socially compliant with the OS* - *i.e.
what the customer expects.  This is the 'least astonishment principle.'*

That means custom installers that are common for the tool, but different
from the native OS are a no-no if you really want someone to use the tool
as a binary. [And that's expensive and hard to do well BTW].

Yup, custom installers makes it easier for >>you<< but not for the person
doing the installs.   So if you make the choice to support an OS,
particularly as a binary, then the install needs to be for that OS --- for
winders its a different  installer than from DOS which is different than VMS.
  For VMS its the DEC Installer.  For, the UNIX family Solaris is different
from the loathsome DEC setld(8) of Ultrix and Tru64, which is different
from IBM AIX which is different from HP-UX, etc  Linux gets really
strange on the binary front.   The good news is the commerical folks using
Linux it is primarily rpm and there are tools the convert from tools that
convert from rpm to yum/getapt etc., but generally Linux folks generally do
not want a binary installer ;-)  But there are N different Linux package
managers and each one is 'better' than the other?   If you have a binary
distribution for your tool, which do you use?

That said 

simh is a wonderful tool and the fruits of the labor of many people.  But I
see it as primarily a github (source) release.   When Mark graceously does
make a binary, he seems to follow least astonishment.   But since he has
made the sources available and some distro's have picked it up and created
binaries of their own, many have done a poor job of following up with the
source distribution.   Which of course, fails the least astonishment
principle also (because it's easier for the distro maintainers of course).
They can claim they have 'simh' but because they made it eaiser for
themselves, they are in effect an older (unmaintained) 'fork' or the tree.

And this is the of course is a flaw in FOSS.   The economics don't follow.
 Ecomonically, you want to make it as easy on the builder of the tool if
your 'product' is the sources.  Which is what Mark does (an excellent job
IMO as its pretty impressive the number of OS's that can build it).

But if you take the sources and package it and create an installer ... well
Mark and Bob should speak for themselves  but I think that is you own
problem; not simh's

Stepping down from Soap Box ...

I will grant you that the users of simh are likely to be a tad more techie
than 'the average bear.'   But to me that says, you can trust them to go to
github, do a 'clone' and then build it themselves.

My thinking at least 

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Transferring the licence file to the VAX emulator

[Clem Cole]

I try one more time on list, but if you want to discuss more, let's go
off-list.

On Mon, Dec 17, 2018 at 2:56 PM Paul Koning  wrote:

>
> Not unique to VMS nor even to DEC.

I agree - that is exactly what I was saying.  It was the way I/O was done
in the 60s - which seems to have had a rebirth as part of modern Frameworks.
   And if you are programmer that grew up with I/O byte streams, then you
think in terms of line terminators for text files; not variable length
records.

As Dennis Ritchie once said to me, the whole idea behind a byte stream was
for the OS to just get the bits and then user code do the interpretation
(which of course can be in a library).  But don't make the OS need to know
much -- just get the bits from storage and shove it into memory and let
user interrept them.

My guess is this is one of those cyclical arguments.   Before the OSses of
the 60s, when code ran raw on the HW, a programmer needed to add those
libraries in your runtime deck.   Putting 'record management' into the OS
was seen as easier and made progammng simplier and fast.  The problem of
course is it was different for different systems and languages. So one
person's easy, became another person's burden.

By the time of Dennis and Ken are doing their thing -- they are fighting
the native system I/O.   Streams was a lot easier in Dennis's mind (and I
tend to agree - I came up on IBM systems from the 60s, then PDP-10's, and
VMS before UNIX).   Eventually, as C and UNIX spread, what OSses followed
and languages made easy followed that vision.  And today most programmers
have not seen the 'old ways.'

FWIW: Years later, we start creating all these different ways of packaging
up libraries and methods (a.k.a. programming frameworks) to hide the byte
structure of files.  So instead of learning ISAM/VSAM etc... you used some
different set if API's that called sql-lite, *etc.*..  Who knows what will
be 'natural' in the future.

Clem

ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Transferring the licence file to the VAX emulator

[Clem Cole]

The problem is the license manager code you are running into is expecting
an RMS file, not a Stream I/O.  In the old days, the idea of 'access
methods' was the natural ways OS's did I/O and RMS was VMS's answer.
 Since today's programmers tend to have grown up with C/C++/Java and stream
I/O, you need to think in terms of a programming 'Framework' that is
inflicting some level structure on the file.  FWIW: Stream style I/O and
the STREAM-LF file format was added to VMS to support VAX11/C, and normal
programmers (correctly) started to avoid RMS (it was funny how quickly the
compiler runtime teams abandoned RMS, but I digress).  But if the code was
written assuming RMS (which was all VMS had for many years), the files need
RMS.

[As my old friend and officemate Tom Teixera once said so wisely, it was
not so bad that RMS had thousands of options, but the OS had to check every
one of them on each operation].

Anyway, if you can, you might try:  dir/full filespec command on another
license file, looking at 'Record format' and 'Record attributes' fields  in
the results to give you a hint.

On Mon, Dec 17, 2018 at 10:18 AM dave porter 
wrote:

>
> Probably nothing. The 'natural' format would have been
> RMS VAR-CR records (if I recall the terminology) where
> the line termination character is implicit rather than
> being in the record data.
>
Pulling very old bits from the my brain's 'deep-freeze' memory, that sounds
close - 'RMS VAR records',  if the 'format' is 'Variable Length' I believe
that there was originally a of 255 IIRC, becauses it stuffs a Pascal String
(IBM 360 style) one byte record length before start of the data, but that
may have been relaxed in later versions after I stopped dealing with VMS.
If 'attributes' is 'Carriage return' then RMS will add the  from
earlier DEC OS's output, although it will not store them on disk like some
systems did.

>
> STREAM-LF may work, but I assume the trick is to get
> the record-type for the file to match what you've put
> in the file.
>

Check out http://neilrieck.net/docs/openvms_notes_text_files.html




ᐧ
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] TINTE is not TECO either

[Clem Cole]

BTW: My old friend and college, Paul Cantrell's Video Teco is still one the
best and most portable:  Video Teco Manual
Video Teco Sources

Also, Ward has a notice description/history of Teco in his pages: Tape
Editor and COrrector Teco was later
renamed 'Text Editor', but it started as a tape editor.

ᐧ

On Mon, Nov 12, 2018 at 9:41 AM Paul Koning  wrote:

>
>
> > On Nov 10, 2018, at 8:12 AM, Lars Brinkhoff  wrote:
> >
> > TECO for RT-11 and SITS.  (SITS was a timesharing system for the MIT
> > Logo PDP-11/45.)
>
> Regular TECO also exists for RT-11.  Is this one better?  Or just
> different?
>
> paul
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] PDP10: KS10 console lights?

[Clem Cole]

On Fri, Sep 7, 2018 at 1:52 AM Lars Brinkhoff  wrote:

> Timothe Litt wrote:
> > > I have checked the KS10 instruction set.  It doesn't have a DATAO
> > > PI, instruction.  However that particular opcode isn't in used, so
> > > it's just a UUO.  This is also the case for ITS microcode.  Before I
> > > start working on anything, I'd like to ask if it would be OK to
> > > repurpose this opcode for its traditional use?
> >
> > Neither the KL nor the KS use DATAO PI,. I don't have a problem with
> > implementing it for the KS. It would need to act like any IO
> > instruction - MUUO in user mode, functional in Exec and with
> > User-In-Out.
>
> Of course.
>
> The next problem is, how to access USB from SIMH?  I have something that
> works in Linux.  I checked SIMH to see if there's a built in USB API
> that works across operating system, but I didn't see any.

I believe that device is using an FTDI chip set, which Linux/MacOS/Winders
etc will see as a dynamic serial port that appears at attach time.   You
use open it and used traditional read and write.  FWIW:  If you grab the
sources to the Arduino IDE and look at the interface code in there - it
knows rules on how the port names will be generated in the different OSses
which will be thr one tricky part, since the rules.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulated PDP-7 Unix V0?

[Clem Cole]

Before I begin.. I need to warn you. I'm not a lawyer, although I have been
trained in a bunch of this specific topic from my days as an expert
witness, working with the both the LCC Lawyers, the DEC Lawyers and now I
actually am trained and teach the internal required course of all SW
engineers at Intel:  Copyright, GPL et al...

On Wed, Sep 5, 2018 at 11:20 AM Paul Koning  wrote:

>
>
> Note that copyright and license are two separate topics.
>
> A license is a grant of permission to do specific things with an item of
> property (such as a copyrighted work).

Indeed - although copyright has either an explicit license associated with
it (usual and what the UNIX words used) or an implied license (book
publishing).
If you add the words 'all rights reserved' or register the copyright, the
implied license is made explicit.



>
>
> If Unix V0 is in the public domain for the reasons Al mentioned (published
> without copyright notice prior to 1 Jan 1978) then you can do with it what
> you want, and the license is not relevant (since it isn't anyone's
> property).  If that code is *not* in the public domain for some reason,
> then a license from its owners would come into play.
>
The owners (Novell in this case) *have relaxed the license associoated with
the copyright *via the ancient UNIX license. V0 is covered under that
license specifically - I'm at work, do I can not check the specific words
on my copy of the document.  But the effect of the words is all versions
developed by AT (BTL Research).  FYI:   Dennis was instrumential in
creating this license a number of years ago when AT owned the rights and
SCO was the primary distributed (i.e. SRV4 times).  Novell would come in
the play later.As I say, I have one of these licenses specifically, as
does Warren and many others.   Eventually, during the SCO/IBM suite, it was
all reexamined and you did not need to execute it yourself.

As I have been told by lawyers whom I trust, *the Ancient UNIX licebsed
does not put the code in 'the public domain.' * But, it does allow us all
to use it.   Use and origin should be atributed ( which Warren did on the
V0 project ).

Simply you just need to declare that the work is based on original AT
release and you are done.

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulated PDP-7 Unix V0?

[Clem Cole]

gad dyslexia sucks... the sentence was supposed to say:   This is true for
all UNIX implementations, including the UNIX-like/work alikes from Idris,
Coherent, Sol, and Linux
ᐧ

On Wed, Sep 5, 2018 at 10:38 AM Clem Cole  wrote:

> below...
>
> On Wed, Sep 5, 2018 at 7:36 AM Al Kossow  wrote:
>
>> On 9/5/18 4:24 AM, Al Kossow wrote:
>> >
>>
>> > So the newer UNIXes are in the clear.  I doubt anyone actually cares
>> about
>> > version 0 either, but technically it's still under copyright.
>>
>> http://digital-law-online.info/lpdi1.0/treatise17.html
>>
>> I don't think that is true since it predates the 1976 removal of the
>> requirement
>> for computer programs having to be registered with the Copyright office,
>> and
>> we know Unix didn't even have WE copyrights on the code until much later.
>>
>> Anything he created as replacements are, though.
>>
>> Hopefully, those are appropriately licensed.
>
>
> Anything before and including V7 is covered by the Ancient UNIX license.
> At one time you needed to get you own and a number fo us have them, but at
> one point Novell (the eventual legal owner of the IP and the copyrights)
> removed that restriction and the original code is availble (although it
> should be attributed). I probably can dig up all this from email et
> al.. If Warren does not have a section "Front and Center" on TUHS web site,
> I'll work with him. The PWB world (PWB 1.0- SRV4) was ittle different BTW.
>  PWB 1.0 and 2.0 kernals were based on V6 and V7 and AT (before Novell)
> has agreed that they were covered under the original Ancient license.
> PWB 3.0 aka System III and later were released as part of the IBM/Linux law
> suite when it was discovered that Novell owned the IP rights.
>
> One more thing, which is off topic for simh, which I'll add before some
> gets all worked up (and again, take it off list), the intellectual property
> (IP) and the code itself are different.   AT owned the IP, which was
> described in the code, which had a copyright.   They published *the IP in
> the open literature*.   In the AT vs. UCB/BSDi cash the courts were
> clear -- AT owned the IP but ... they could not claim trade secret on it
> because they published it (the case was a trade secret case not a copyright
> case).  The different code bases (the implementations) are covered by the
> licenses associated with their copyrights, but are under the rules of IP
> ownership.   This is true for all UNIX implementations, including the
> UNIX-like/work alikes from Idris, Coherent, Sol, UNIX.  Thus the provenance
> of the code itself is only interesting as to which copyrights it covered.
> The courts were clear: the UNIX IP (the core ideas) are 100% 'free'
> (open/libre) since AT published it opennling starting in the early 1970s.
>
> I have a fairly long treastise on much of this in a paper I published last
> fall at History of Unix symposium - Paris, France, October 19th 2017
> http://technique-societe.cnam.fr/colloque-international-unix-en-france-et-aux-etats-unis-innovation-diffusion-et-appropriation--945215.kjsp
> [note the web site is in french.  my paper is not, althought some of them
> are].  Send me email off line if you want a copy of the PDF.
>
> Been there, lived it, and have the tee shirts to prove it - at least ones
> by wife has not thrown out as too ratty ;-)
> Clem
>
> ᐧ
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulated PDP-7 Unix V0?

[Clem Cole]

below...

On Wed, Sep 5, 2018 at 7:36 AM Al Kossow  wrote:

> On 9/5/18 4:24 AM, Al Kossow wrote:
> >
>
> > So the newer UNIXes are in the clear.  I doubt anyone actually cares
> about
> > version 0 either, but technically it's still under copyright.
>
> http://digital-law-online.info/lpdi1.0/treatise17.html
>
> I don't think that is true since it predates the 1976 removal of the
> requirement
> for computer programs having to be registered with the Copyright office,
> and
> we know Unix didn't even have WE copyrights on the code until much later.
>
> Anything he created as replacements are, though.
>
> Hopefully, those are appropriately licensed.


Anything before and including V7 is covered by the Ancient UNIX license.
At one time you needed to get you own and a number fo us have them, but at
one point Novell (the eventual legal owner of the IP and the copyrights)
removed that restriction and the original code is availble (although it
should be attributed). I probably can dig up all this from email et
al.. If Warren does not have a section "Front and Center" on TUHS web site,
I'll work with him. The PWB world (PWB 1.0- SRV4) was ittle different BTW.
 PWB 1.0 and 2.0 kernals were based on V6 and V7 and AT (before Novell)
has agreed that they were covered under the original Ancient license.
PWB 3.0 aka System III and later were released as part of the IBM/Linux law
suite when it was discovered that Novell owned the IP rights.

One more thing, which is off topic for simh, which I'll add before some
gets all worked up (and again, take it off list), the intellectual property
(IP) and the code itself are different.   AT owned the IP, which was
described in the code, which had a copyright.   They published *the IP in
the open literature*.   In the AT vs. UCB/BSDi cash the courts were clear
-- AT owned the IP but ... they could not claim trade secret on it
because they published it (the case was a trade secret case not a copyright
case).  The different code bases (the implementations) are covered by the
licenses associated with their copyrights, but are under the rules of IP
ownership.   This is true for all UNIX implementations, including the
UNIX-like/work alikes from Idris, Coherent, Sol, UNIX.  Thus the provenance
of the code itself is only interesting as to which copyrights it covered.
The courts were clear: the UNIX IP (the core ideas) are 100% 'free'
(open/libre) since AT published it opennling starting in the early 1970s.

I have a fairly long treastise on much of this in a paper I published last
fall at History of Unix symposium - Paris, France, October 19th 2017
http://technique-societe.cnam.fr/colloque-international-unix-en-france-et-aux-etats-unis-innovation-diffusion-et-appropriation--945215.kjsp
[note the web site is in french.  my paper is not, althought some of them
are].  Send me email off line if you want a copy of the PDF.

Been there, lived it, and have the tee shirts to prove it - at least ones
by wife has not thrown out as too ratty ;-)
Clem

ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating a GT40

[Clem Cole]

below...

On Tue, Sep 4, 2018 at 10:26 AM Al Kossow  wrote:

>
> Eventually Valid switched to Sun.
>
Makes sense...



>
> They started out with their own 68010 multibus hardware

which was licensed from Stanford - this is Andy Bechtolsheim masters
project design (originally 68000 then after some PALs were replace,
upgraded to 68010).   How Valid's version differed I do not know, but it
would have been very small.   That basic design, was very popular in the
valley.   A lot of vendors used it.  When Vinod formed VLSI technologies,
he got a license.  The rest is history as they say.

No doubt, it would not have made sense for Valid to keep making it
themselves

and switched to Sun based HW.

I can only say, the original Valid boxes we had at Masscomp (and DEC which
should have been identical as we ordered exactly the same thing at the
time); we definitely based on the Stanford design.   We had them appart in
the lab and looked at every aspect of them and they pretty much matched -
the drawings Andy used were freely available (IIRC they were in SUDS
originally) and many of us had them (I may still for all I know) [we also
analized the Imagen and Cisco AGS CPU boards whiich were all based on the
same original Stanford design].
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulating a GT40

[Clem Cole]

minor nit/detail ...

On Mon, Sep 3, 2018 at 2:05 PM Timothe Litt  wrote:

> Once our CAD group moved off the -10s, the next step was Sun
> workstations for schematic capture (VALID).
>
> Valid was not Sun Micro Systems.  The were Stanford University Network
Termnal (aka SUN), that were linesed by VLSI Technology (later renamed
SMI); as were a number of other forms such as Imagen.

Little known details... Masscomp (as ex-DEC HW folks) used the Valid
systems also.  tjt and I hacked together a microcode assembler in lex/yacc
over the course of a few days/weeks that was the same syntax and features
of the old DEC internal microcode assembler Paul Gaulbau and teams had used
on the Vax et al. (I might even have it somewhere - Clem-isms - spelling
errors/dyslexia in the comment headers)  DEC-West had a number of
macro/library files they had developed for the Valid.   One night mag tapes
of each mysteriuslly appeared at the other firm. ;-)


ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] SCSI-Interface for simh-vax?

[Clem Cole]

below...

On Sat, Sep 1, 2018 at 2:39 PM Zane Healy  wrote:

> Create a virtual disk in SIMH the size of the CD-R blank.  Prep the disk,
> then burn it to CD-R.  This is how I created my bootable CD’s for RT-11 and
> RSX-11M+.  I’ve then used those CD’s to do installs on my PDP-11/73.  I
> wasn’t able to figure out how to make it work in RSTS/E.  I could create
> the CD-R, but not boot and install RSTS/E from it.


Just curious ... aren't there funnies because CD's are normally 1024 byte
blocks and disks are usually 512?IIRC, there are places that store
numbers of blocks (not bytes), and you have to be careful.I have
>>not<< played in any of that in years.

IIRC one of things  we might have done at DEC was mess with the block size
on a CD -- that's a Tim Litt type question.   Those bits are so long ago
depreciated/garbage collected in my acitve brain cells. ;-)
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX emulation issues on Raspberry Pi

[Clem Cole]

I'm going to send this once here -- please take any follow up off line to
me privately.  I don't want to seed a discussion of goodness or badness of
different compilers.  This is purely as an FYI for those that may not be
aware.

*Comments are my own and do not neccessarily represent official policy.
This is all based on my observation as a user and consumer, and friend of
the developers.*

On Tue, Jul 31, 2018 at 11:49 AM, Timothe Litt  wrote:

>  Don't forget to try ICC if you want Intel's take on optimized code for
> their CPUs.
>
right.

FWIW:  The intention of the icc (Intel C Compiler) team is to try really
hard to be the 'best' compiler for Intel's chips and targets the compilers
for ISV and high-end users that care about performance [example ISV is
Apple's "Final Cut", most CAD vendors like Abacus, Ansys and the like].
So much effort is spent by the team to try to know where the compiler
deviates from gcc (and LLVM and a number of other commercial compilers such
a MSFT, Cray and IBM).  If you find something that might seem
strange please know that while I do not work on that team, I do each lunch
with those folks quite often/many are in the same building as me.

I can and have filed a bug reports so someone in the icc backend team looks
at it.  Also, I note that icc/ifort *et al* are available for free for
personal/research use (and for FOSS projects like simh in fact - send me
info offline if you want to know more).  That said, it does not always mean
the team will change the code generator when we file a report - as there
are some cases where icc prefers some optimizations over some taken by gcc
[sometimes it seems like taste - but their choices are based on
architectural differences where Intel has chosen one way to generate code
that makes more sense to their engineers  for 'Genuine Intel' processors
that match the INTEL*64 definition, and not on other implementations of
that same architecture that Intel does not manufacture ... while gcc might
use a different scheme with different trade offs].


But so far in all cases, but one that I know about where we found a place
where gcc generated 'better' code for simh (*i.e.* a benchmark ran faster)
and I reported it.  The icc team dug into why and icc was changed to do as
well or better.   The one case where it was not (which was about 36 months
ago), it depended on the processor as it turns out and the Intel
optimization make more sense for the current or future 'big core' chips,
and they chose to keep that sequence.I have not re-run that sequence in
a while on my current i7 based Mac so I'm sure who it matches to be honest.





> And Clang is coming along.
>
Indeed, in fact Intel compiler team has people that work on both gcc and
LLVM and very much want them to generate the best code they can.Clang
is an interesting compiler, particularly for the 'C Family' - [the LLVM
Fortran has a ways to go, but Intel is actually spending a lot of money to
help that team also as Intel's compiler folks really want to see an FOSS
'production quality 'modern' Fortran besides their own.
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Install VAX/VMS 4.4 on a simulated VAX-11/780

[Clem Cole]

below...

On Thu, Mar 29, 2018 at 7:51 AM, Henk van de Kamer <s...@vandekamer.com>
wrote:

> Clem Cole schreef op 25-3-2018 om 23:23:
>
>> A small suggestion...   while you can probably get the 780 to recognize
>>> and support a TU58, booting from it may be difficult (I did not find it
>>> mentioned in any SDP or other doc).
>>>
>>
> In another post I gave a link which suggested that it could be present.


​Yeah, Mark has it in the simh configuration.  But be careful, there are
lots of the things you can do with the simulator that was never done in
real life.   Also there may be 'latent' support in the OS for some things.
For instance, Tru64 will boot and operate just fine with an Adaptec SCSI
controller ​in it.   That actually the configuration I ran in my office at
DEC, but it is not official in the 'Software Product Description' (*a.k.a.*
SPD)  because it will screw up (in that case an Adaptec can not support
fail-over so it was only officially support on Alpha/NT systems - but we
ran engineering systems with them all the time).

So you need to check the SPD for the specific release.  That will tell you
what DEC tested and supported in the field.  Anything else, you are in the
ocean without a life preserver -- you can swim and you might be safe, but
don't bank on it either.



>
>
> The 780 family has a dedicated PDP-11 with RX floppy drives that runs as
>>> the 'front end' for it and boots it. The PDP-11 run an small OS RSX-11/S (I
>>> think - but man those bit in my brain are long
>>> lost) and can reach in the SMI to load the OS image into memory
>>> from the disk and then points the system at it.
>>>
>>
> I searched what the TU58 exactly was and found [1]. They say it could be
> used to bootstrap the RT-11 [2] operating system on a PDP-11. That seems
> to be the one :-)

​Could be - as I said, those bits in my brain have long ago rotted.   The
780 and the KL10 both had a PDP-11 spliced into them to boot them up as a
front end.   The system console (which was typically a DECwritter-II) is
connect to a DL-11 on the PDP-11.   When typing to something on the main
computer the local OS on the front-end reads the uart on the DL-11 and
passes the characters to/from the host.I thought I remembered that it
was a modified RSX-11 called RSX-11S that ran on the front-end, but I could
be confusing with another application.

The key point for you is that the 780 when it turns on is a bunch of hot
rocks.   It needs to have its microcode loaded before it can do anything,
as its microcode is stored in ram, not rom.  The system microcode lives on
the floppy disk in the front-end​.   Once the microcode is loaded, a vax
bootstrap can begin.

As a cost reduction on the 750, Dave Cane (HW design lead) developed it
without PDP-11 front-end (which was probably a marketing requirement).
 I've forgotten the complete sequence, since the 750 also had microstore.
IIRC: the front panel on the 750 (and the 11/34 and few other systems) is
an microprocessor.   The 11/34 used a i8008.   I think the 750 its was an
i8085, but I do not remember.   I think one thing is does is load the
microcode, but that's stored in the micro's rom's not on a floppy like the
780 and KL10.  But the microcode might be in ROM, I just don't remember
(I'll ask Dave if he does next time I see him).

The TU58 and the DECwriter might actually be directly connected to the
microprocessor, but again I've forgotten the details (look at the prints),
but there is some way they are available to the Vax directly, which is a
difference than the 780.

The point being that the TU58 driver in the host OS has to know how to
interface to the device.  Again IIRC, the HW design of the the TU58, as you
noted is an RS-232C serial device (basically predated the current USB idea
by about 25-30 years).


> In another post the same was suggested. However I only found three TU58
> tape files with the standalone backup 4.0.

However, I bet they that was only tested on a 750 and only on specific
configs as defined in the SPD.

The trick if you are really trying to be period relevant is get a copy of
the SPD and make sure vax750.ini file you create is actually one that
defines hardware that was tested and released for that version of the OS.

Anything else, might work, but you could be running into a number of ways
that things are almost but not quite.

If you can find something like Will Senn's Installing and Using Research
Unix Version 7 In the SimH PDP-11/45 and 11/70
<https://drive.google.com/file/d/0B1_Jn6Hlzym-Zmx1TjR3TENDQTA/view> for VMS
and the 750 and 780, I think you'll find like Will did, that he needed to
have a tape.ini file (which is on page 4 of his document) that was exactly
what Ken and Dennis described in their release.   The same will be true for
the Vax and VMS.

FWIW: If you are asking questions, please list as Will doe

Re: [Simh] Install VAX/VMS 4.4 on a simulated VAX-11/780

[Clem Cole]

A small suggestion...   while you can probably get the 780 to recognize and
support a TU58, booting from it may be difficult (I did not find it
mentioned in any SDP or other doc).   The 780 family has a dedicated PDP-11
with RX floppy drives that runs as the 'front end' for it and boots it.
 The PDP-11 run an small OS RSX-11/S (I think - but man those bit in my
brain are long lost) and can reach in the SMI to load the OS image into
memory from the disk and then points the system at it.  The 750 and 730
have boot roms for he VAX itself that know how to talk to the peripherals
such as the TU58 .

IIRC, the TU58 controller is sitting on the UBA and I really don't think
the code in the PDP-11 knows how to get to them.   The path to make that
all would be a tad convoluted and I suspect no one bothered to write for
the TU58  it back in the day because everything for the VAX was based on
either the RX floppies, 9-track tape or the disk itself.

That said, in theory, a 750 should be able to create a disk image that
contains an OS that could be booted on a 750 and a 780.

So...


What you might consider, is setting simh4.x up as a 750 and read those
tapes, set up the system and create RP06/07 or RM05/06 etc. disk images.
 Then reconfigure the simulator as a 780, and attach that disk image.  Then
use the standard 780 boot via the RX floppies and the PDP-11, you should be
all set.

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Install VAX/VMS 4.4 on a simulated VAX-11/780

[Clem Cole]

Before you go too much farther, I would recommend that you get the latest
version of simh:   https://github.com/simh/simh
A great deal has changed since simh 3 and you are likely to run into few
issues.

Once you have that working, I would suggest you search the archives of the
info-vax mailing lists: Info-vax Archives
<http://rbnsn.com/pipermail/info-vax_rbnsn.com/> and maybe subscribe to
their mailing list  http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com

Best wishes,
Clem Cole
ᐧ

On Fri, Mar 23, 2018 at 10:45 AM, Henk van de Kamer <s...@vandekamer.com>
wrote:

> Hi,
>
> I'm new to this list, so forgive me if I do things wrong...
>
> For an article about the history of prompts I want to make screendumps of
> all systems I worked on. In 1986 (may be 1987) I learned Pascal on the
> VAX-11/785 (I think) on the university.
>
> So two days ago I started a journey to install VAX/VMS 4.4 -- because that
> is the most probable version used -- on a VAX-11/780 using the Simh
> emulator under Debian Stretch. That was the first problem because the man
> page of the vax780 command said that ka655.bin was not included. I found
> the ka655x.bin in the Simh git. Later I discovered that the man page is
> probably wrong and I must use vmb.exe instead.
>
> After searching I found the bb-bt05c-be tape [1] which contains DEC
> VAX/VMS V4.4 BIN 16MT9 (C)1986 [2]. After a lot of trial, problems and
> searching I finally discovered that I need the Standalone Backup and a
> procedure for v3.0 [3]. Another searched and I got three tapes [4]:
>
> BE-CT97A-BE - VAX/VMS V4.0 STANDALONE BACKUP 1 OF 3
> BE-CT98A-BE - VAX/VMS V4.0 STANDALONE BACKUP 2 OF 3
> BE-CT99A-BE - VAX/VMS V4.0 STANDALONE BACKUP 3 OF 3
>
> I adapted the given ini to the following -- the complete ini with the same
> adaptions don't give any difference:
>
> load vmb.exe
> set rp0 rp06
> set rp1 rp06
> attach rp0 stb40.rp6
> set console log=logs/vms44.log
>
> Then the procedure:
>
> hvdkamer@obelix:~/vax$ vax780 vax780.ini
>
> VAX780 simulator V3.8-1
> Overwrite last track? [N]
> Logging to file "logs/vms44.log"
> sim> boot rp1
> Loading boot code from vmb.exe
>
> [ctrl-E]
> Simulation stopped, PC: 0E8D (BITL #1000,4(R7))
> sim> attach ts bb-bt05c-be.tap
> sim> cont
> [Enter]
>
>
> And there it hangs. I downloaded the v3.0 tape used in the example, but
> that results in the same.
>
> The above looks the most promising of all examples I tried. Most used
> options which didn't work or crashed the emulator. Can someone point me in
> the right direction to install the operating system. Thanks for any help.
>
>
>
> [1] ftp://ftp.informatik.uni-stuttgart.de/pub/cm/dec/vax/sw/magtapes/
> [2] ftp://ftp.informatik.uni-stuttgart.de/pub/cm/dec/vax/sw/magt
> apes/labels.txt
> [3] http://simh.trailing-edge.narkive.com/P8L1m0CF/problem-booti
> ng-vms-1-5#post7
> [4] http://iamvirtual.ca/VAX11/VAX-11-software.html
>
> --
>
> Henk van de Kamer
> http://www.vandekamer.com/
> http://www.hetlab.tk/
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] IMP interfaces

[Clem cole]

IIRC the imp11-a is built from a dr11-b with some custom interface logic to 
talk to the 1822  (thinking about it it was maybe 2 back to back I’ve 
forgotten) but from a SW stand point the registers are what is exposed by the 
dr11.  Although the CSS folks may moved the default addresses.At one time I 
had small document from css on it.  Ill have to do digging.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Mar 7, 2018, at 6:13 PM, Henry Bent  wrote:
> 
>> On 7 March 2018 at 14:30, Phil Budne  wrote:
>> > >Can the IMP software and the H316 simulator talk TCP/IP to an ehernet 
>> > >card?
>> 
>> If we had TCP-era IMP code, one could, in theory, but as I recall the
>> structure of the TCP ARPAnet (net 10) address was that one octet was
>> the IMP number, and another the port on the IMP, which was severly
>> limited (four host ports?), and if that limitation was "well known"
>> you might only be able to attach to four hosts over Ethernet.
>> 
>> Most often, the system attached to the IMP acted as a router, and
>> connected to the local internet.
> 
> There are drivers in 4.2BSD for IMP interfaces, the ACC LH/DH and the DEC 
> IMP11-A.  These are set up to use TCP/IP but it is unclear to me how much 
> work the board does vs. what is expected of the IMP itself.  As far as I am 
> aware there is not technical documentation for either of these boards, but if 
> that turned up I imagine they could in theory be added to SIMH for the VAX 
> and PDP-11.
> 
> -Henry
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] IMP interfaces

[Clem Cole]

On Wed, Mar 7, 2018 at 2:30 PM, Phil Budne  wrote:

> > >Can the IMP software and the H316 simulator talk TCP/IP to an ehernet
> card?
>
> If we had TCP-era IMP code, one could, in theory, but as I recall the
> structure of the TCP ARPAnet (net 10) address was that one octet was
> the IMP number, and another the port on the IMP, which was severly
> limited (four host ports?),

​Exactly...   up to 4 hosts per IMP on the original Honeywell - each
supporting a single 1822 interface, which might or might not be local using
a 'very-distance-host' interface - i.e. was not in the same room as the IMP.

Berkeley's original connection was via the LBL IMP using the VDH​

Noel Chiappa might remember more of the TAC details, I personally never saw
one - although I did use one or two on occaison.   IIRC they could handle
??32?? lines maybe, but there were for terminals (and a lot of modems).
 The whole reason for building the ARPAnet was to allow sharing of
expensive mainframes (of course what it did was actually cause people to
want more systems).   But until the TAC's show up, 'remote sharing' was
less than might have been hoped by the funding masters ;-)

More details of all this is can be found in Katie Hafner's 'Where Wizards
Stay Up Late'




> and if that limitation was "well known"
> ​ ​
> you might only be able to attach to four hosts over Ethernet.
>
​Mumble...  it was certain 'well known' the question is was it screwed down
into SW.   Which is likely.​



>
> Most often, the system attached to the IMP acted as a router, and
> ​ ​
> connected to the local internet.
>
​Actually that's quite right if my memory serves me.​


The original​ idea of the original (Honeywell) IMP was to keep the host
from having to do any protocol work.  The host SW was left as an exercise
for the user by BBN [again see Katie's book - the details are
fascinating].   Until TCP was thought about (which was before IP BTW); the
host was supposed to be very dumb and the IMP terminates the network and do
all the 'hard work.'   I think BBN looked at the 1822 as a way to add a
peripheral to the host in the key of a terminal more than anything else.

In fact the host SW, was not even started until pretty near the time that
the first IMP was delivered.   There was not specs for it for a long time.
That said, as
 time went by and the host SW got more and more sophisticated and
​ eventually​
the need for TCP arose, the IMP was a
​protocol terminator/​
converter more than a router.  With the advent of IP and then running the
​network ​
protocol in the host itself (TCP), BBN created the C30 IMP (20 bit
microcoded UNIX system, they later sold as a UNIX system called the C70).
 That would be more like a router.

I'm drawing on very old memories here...   you'd need to ask some one like
Al Nemeth who managed the project at BBN, but I don't think the C30's ever
ran the NCP code.

In UCB's case when we finally got our own IMP (82/83ish I think) it was a
C30 and that was all post NCP turn off date.I'm also not sure of the 4
hosts 1822 limit was removed.  I don't remember anyone having used 1822
with them, but I'm fairly sure their had to be because Ethernet interfaces
did not yet exist for many of the original ARPAnet hosts.  My memory is
that the C30's supported native ethernet, so they really did become a
router and people stopped needing to use an 1822 with them.

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 i/o addressing

[Clem Cole]

On Fri, Feb 16, 2018 at 4:35 PM, Larry Baker  wrote:

> In a true VM architecture, different objects can be distinguished by their
> program addresses.  This is a key distinction between memory mapping and
> virtual memory
>

​Larry - I 100-% agree with you.   My point was that from a programmer's
standpoint, I can (and have as Tim describes, I used those maps too),
remember pushing past the address space limits on our PDP-8 which was were
I first messed with manual overlays.​   But we had real VM (as described by
Denning) in the IBM 360/67 running TSS at the same time.   Our first
PDP-10's did not and of course the 11's did not either.

So I just remind folks that programming in a memory constrained environment
can be done by an application program to get around the limits of the
number of address bits that the HW supplies.   VM is supported by the OS,
without application programmer intervention - which certainly makes it
desirable.   As Tim pointed 32 bits was both 'not enough' and the memory
scheme could be abused.   It's not a universal solution to all memory
issues.  It is handy, but we lost something too.

I was suggesting that not enough programmers are taught about overlays.
Frankly they should be before they learn about VM; IMO. Learning how your
program lays out in memory and how it is going to perform, what it is call
graph look like etc...   these are skills that you acquired naturally in
the old days and much hard to understand, but less realize why they are
important.

BTW:  a similar lost art of that of mathematical interpolation and
'significant digits.'   I'm the last of a breed of engineer that learned on
a slide rule too; which is where you quickly get an understanding of those
two concepts.   That said, just as I'd rather not go back to having to do
manual overlays; I did love my TI-50 (first calculator that have
transcendental functions) when I got it in the early 1970s.
:-)

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 169, Issue 53

[Clem Cole]

Strange:

% brew list sdl2
/usr/local/Cellar/sdl2/2.0.7/bin/sdl2-config
/usr/local/Cellar/sdl2/2.0.7/include/SDL2/ (72 files)
/usr/local/Cellar/sdl2/2.0.7/lib/libSDL2-2.0.0.dylib
/usr/local/Cellar/sdl2/2.0.7/lib/cmake/SDL2/sdl2-config.cmake
/usr/local/Cellar/sdl2/2.0.7/lib/pkgconfig/sdl2.pc
/usr/local/Cellar/sdl2/2.0.7/lib/ (4 other files)
/usr/local/Cellar/sdl2/2.0.7/share/aclocal/sdl2.m4
[ctcole-mac07:~] ctcole% brew --version
Homebrew 1.5.2-3-g0f44937
Homebrew/homebrew-core (git revision f4db43; last commit 2018-01-25)
ᐧ

On Fri, Feb 16, 2018 at 3:57 PM, Larry Baker  wrote:

> Rob,
>
> I don't understand why you need sdl2.  I recently built SIMH on my El
> Capitan Mac at work and my Sierra Mac at home and had no need to install
> sdl2.  In fact, my brew does not even know about it:
>
> savaii:Earthworm baker$ brew list sdl2
> Error: No such keg: /usr/local/Cellar/sdl2
>
>
> savaii:Earthworm baker$ brew list sdl
> Error: No such keg: /usr/local/Cellar/sdl
>
>
> savaii:Earthworm baker$ brew list libsdl
> Error: No such keg: /usr/local/Cellar/libsdl
>
>
> savaii:Earthworm baker$ brew list libsdl2
> Error: No such keg: /usr/local/Cellar/libsdl2
>
>
> savaii:Earthworm baker$ find /usr -name libsdl\*
> find: /usr/sbin/authserver: Permission denied
>
>
> As I recall, I did not have to change anything in the most recent SIMH
> build procedure on a Mac.
>
> Larry Baker
> US Geological Survey
> 650-329-5608 <(650)%20329-5608>
> ba...@usgs.gov
>
>
>
> On 16 Feb 2018, at 12:32:08 PM, simh-requ...@trailing-edge.com wrote:
>
> Date: Fri, 16 Feb 2018 20:23:22 -
> From: "Rob Jarratt" 
> To: 
> Subject: [Simh] Installing SDL2 on Mac To Build SIMH
> Message-ID: <004b01d3a763$fdcfc7d0$f96f5770$@ntlworld.com>
> Content-Type: text/plain; charset="utf-8"
>
> I don't have a Mac but I need someone to be able to build SIMH on his Mac
> and be able to link SDL2. I have looked at this page:
> https://www.libsdl.org/download-2.0.php
>
>
>
> I don't understand if you need runtime or dev libraries, I have tried
> opening both dmg files with 7Zip and I can't find anything in either that
> looks like a libsdl2.a file. What am I looking for and where would I put
> the
> file to be able to link it? Compile already works.
>
>
>
> Regards
>
>
>
> Rob
>
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Installing SDL2 on Mac To Build SIMH

[Clem Cole]

If you have brew installed try:   brew install sdl2


ᐧ

On Fri, Feb 16, 2018 at 3:23 PM, Rob Jarratt 
wrote:

> I don’t have a Mac but I need someone to be able to build SIMH on his Mac
> and be able to link SDL2. I have looked at this page:
> https://www.libsdl.org/download-2.0.php
>
>
>
> I don’t understand if you need runtime or dev libraries, I have tried
> opening both dmg files with 7Zip and I can’t find anything in either that
> looks like a libsdl2.a file. What am I looking for and where would I put
> the file to be able to link it? Compile already works.
>
>
>
> Regards
>
>
>
> Rob
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] pdp11 i/o addressing

[Clem Cole]

+1 Paul's comments

some resources - cut and pasted from a message to a young
engineer/mentee/student I have at the moment ;-)

PDP11 Processor Handbook 1979


AA-5075A-TC PDP-11 MACRO-11 Language Reference Manual (RT-11)


$5 used on Amazon:  https://www.amazon.com/Introduction-Assembly-
Language-Prentice-Hall-software/dp/0134917049



ᐧ

On Fri, Feb 16, 2018 at 10:15 AM, Paul Koning 
wrote:

> Mike,
>
> You should get yourself a good intro to the PDP-11, for example one of the
> PDP-11 Processor Handbook copies you can find on Bitsavers.  It answers
> that question and many others.
>
> The key point is that you have to distinguish virtual addresses from
> physical ones.  The I/O device addresses are physical addresses.  The
> program uses virtual addresses.  Physical addresses can be 16, 18, or 22
> bits depending on the model; virtual addresses are always 16 bits.
>
> The power on default mapping is that physical addresses 0-15 map to
> physical addresses with leading zeroes; virtual addresses 16 and up map
> to physical adddresses with leading ones.  So, for example,
>
> mov #101, @#177566
>
> moves the value 0101 (decimal 65, the ASCII code for "A") to physical
> address 17 777 566 which should result in A appearing on the console output.
>
> On machines with an MMU (which is most of them) the mapping from virtual
> to physical can be changed, and for example the "I/O page" (top 4kW of
> physical memory) might not be accessible.  But by universal software
> convention, in kernel mode 16 and up (MMU page 7) are always mapped to
> the physical I/O page address range.
>
> paul
>
>
> > On Feb 16, 2018, at 10:05 AM, Mike Stramba 
> wrote:
> >
> > Greetings,
> >
> > I'm trying to figure out how console I/O works with the PD11.
> >
> > Or more generally I/O addressing
> >
> > E.g.
> > A  "sh TTO"  gives :
> >
> > TTO, address=1564-1567, vector=64, 7p
> >
> > And 1564 (octal) is 4,194,164 dec, which is obviously out of range
> > of the 64K addressable by any MOV instruction.
> >
> > But various diagnostic routines, e.g. below, are using
> > movb rX,@#177566   ; output to console
> >
> > https://www.ak6dn.com/PDP-11/M9312/23-248F1/23-248F1.mac
> >
> > Are I/O devices always at the "top 64k" of memory ?
> >
> > If so, why doesn't  SH DEV display :
> >
> > xxx xxx-177 777  ?
> >
> > Mike
> > ___
> > Simh mailing list
> > Simh@trailing-edge.com
> > http://mailman.trailing-edge.com/mailman/listinfo/simh
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
PDP-11 Instruction Set

We are to admit no more causes of natural things than such as
are both true and sufficient to explain their appearances.
  Isaac Newton, Principles: A System of the World

This paper describes the PDP-11/40 Instruction Set, including the
Extended Instruction Set (EIS) and the Memory Management Unit (MMU).
This particular configuration is similar to the machine John Lions used
during his studies of Unix Version 6 at the University of New South
Wales in 1976/1977. Features of the more powerful models PDP-11/45 and
PDP-11/70 are appended since on these machines Ken Thompson and Dennis
Ritchie developed Unix V6 and V7 in the 1970s.

Notation: The contents of registers, memory and addresses are
represented as nonnegative integers. Leading zero indicates octal and
leading "0x" indicates hexadecimal notation.  The (horizontal or
vertical) sequence of digits starts always with the most significant
one. "Low memory" are cells with low addresses. "K" equals 2^10.
Integer ranges "[i, k)" include i and exclude k if i < k and are empty
otherwise. The C language is employed for expressions.

0 Registers

All registers are 16-bit wide.

0.0 General Registers R0, R1, R2, R3, R4, R5 (FP), R6 (SP), R7 (PC)

The PDP-11 has eight general registers. They are addressed explicitly
by a 3-bit register number which is encoded in instruction words. In
addition to this, three registers are used implicitly, namely:

R7, the program counter (PC), points to the instruction to be executed
next.  After each fetch of a word addressed implicitly by the PC, the PC is
incremented by 2, before being used in address calculations.

R6, the stack pointer (SP), supports subroutine, trap and interrupt
linkage by employing a "last in/first out" memory allocation scheme. It
is used implicitly among others by jsr, rts, mark, sys and rtt. There
are two SPs, one active in user mode (USP), the other active in kernel
mode (KSP). "Push x" allocates memory and saves the value x, 

Re: [Simh] anyone know how to convert/translate turbo pascal to vax pascal?

[Clem cole]

FWIW if you get a hold of K’s “SW tools in Pascal” I think I remember that 
they created a small portable IO library. That is described in a chapter or the 
appendix I forget which.  But the library was ported and tested on VMS.  If you 
switch your IO to it then you can (in theory) — isolate the VMSisms in one 
place.  

Further if you just stare at the library sources it should give you a hint at 
what’s different between most implementations.  If you google around the 
sources for same is generally available.

Also Johnny is spot on.   IO was always the weak link and source of the most 
frustration.  Next was how external libraries were supported. As I said before 
the unit idea became persuasive but the syntax like IO varies. As Johnny also 
warned, and ad you just learned you need to be real careful of data types too 
since different implementations used similar or the same name for some routines 
but the types and parameters were all over the map.  This is why Brian and Dave 
chose to hide the IO in a private library that could be rewritten on a per 
system basis. 



> On Feb 8, 2018, at 5:38 PM, Dan Gahlinger <dgahl...@hotmail.com> wrote:
> 
> yes I'm reading it, and making some progress.
> I have a program that can read a file and display the contents to screen.
> 
> this is going to be quite a learning curve. but fun!
> 
> thanks guys!
> 
> Dan.
>  
> From: Simh <simh-boun...@trailing-edge.com> on behalf of Johnny Billquist 
> <b...@softjar.se>
> Sent: February 8, 2018 5:33 PM
> To: simh@trailing-edge.com
> Subject: Re: [Simh] anyone know how to convert/translate turbo pascal to vax 
> pascal?
>  
> Like I said, you cannot just replace "assign" with "open". The number, 
> types, and exact arguments are not the same between assign in 
> Turbo-Pascal and open in VMS Pascal. You need to read the manual!
> 
>Johnny
> 
> On 2018-02-08 21:18, Dan Gahlinger wrote:
> > So I tried this but the output file is empty. first.txt contains "text' 
> > and second.txt contains "not test":
> > 
> > Program fcomp(input,output);
> > var
> >f, g, h : text;
> >s, t, u : varying [255] of char;
> >c, d : char;
> >i : integer;
> > begin
> >s := 'first.txt';
> >t := 'second.txt';
> >u := 'output.txt';
> >i := 0;
> >open(f,s,old);
> >open(g,t,old);
> >open(h,u,new);
> >while (not(eof(f))) do
> >  begin
> >read(f,c);
> >read(g,d);
> >i := i + 1;
> >    if (c <> d) then
> >  writeln(h,i,' = 1:[',c,']/',ord(c),' 2:[',d,']/',ord(d));
> >  end;
> >close(f);
> >close(g);
> >close(h);
> > end.
> > 
> > 
> > *From:* Clem Cole <cl...@ccc.com>
> > *Sent:* February 8, 2018 12:44 PM
> > *To:* Dan Gahlinger
> > *Cc:* Gary Lee Phillips; Tim Shoppa; simh@trailing-edge.com
> > *Subject:* Re: [Simh] anyone know how to convert/translate turbo pascal 
> > to vax pascal?
> > Yup - traditional Pascal (lack of) portability due to the report having 
> > been silent.   Associating files with file descriptors could never be 
> > agreed so ISO never defined how to do.  Every OS does it differently.  
> > Since Wirth was silent on it, if they picked one scheme over another the 
> > Pascal committee was favoring that implementation [Kernighan may have 
> > even pointed this out in his paper they wrote after writing the software 
> > tools in Pascal - Why Pascal is Not My Favorite Programming Language 
> > <http://wiki.lazarus.freepascal.org/Why_Pascal_is_Not_My_Favorite_Programming_Language>
> >  ].**
> > 
> > Go google the two document I mentioned previously and it should be a 
> > fairly simply change.  Look up file I/O and then read how VMS 
> > implemented the association of  name.
> > 
> > I'm now going by memory, but a number of Pascal's did that in the 
> > reset() function.   A number created a new function as Turbo did 
> > (assign() in this case, but I think open() was used by a couple of other 
> > Pascals. I think a couple of other pass it in via the Program function 
> > and style other that supported separate libraries (usually called units) 
> > did it other ways still.
> > 
> > For grins, in the late 1970s at an HP/Tektronix  'Hatfield/McCoy' style 
> > party - in those days HP in particular was Basic happy and Tek was 
> > mostly Pascal.   We counted over 25 different incompatible 'HP Basic' 
> > implementations, and over 10 different Tek Pascal

Re: [Simh] anyone know how to convert/translate turbo pascal to vax pascal?

[Clem Cole]

I'm at the airport so I do not have a manual -- again please, please
download

On Thu, Feb 8, 2018 at 12:21 PM, Dan Gahlinger  wrote:

>
>
>   f, g, h : text;
>

​I think the VMS syntax is something like...



f : FILE OF TEXT;

  then later

OPEN( File_Variable := f,

File_Name := *’* sample.dat*’* ,

History := OLD,

Organization := Sequential,

Access_Method := Direct; );



ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] anyone know how to convert/translate turbo pascal to vax pascal?

[Clem Cole]

Yup - traditional Pascal (lack of) portability due to the report having
been silent.   Associating files with file descriptors could never be
agreed so ISO never defined how to do.  Every OS does it differently.
Since Wirth was silent on it, if they picked one scheme over another the
Pascal committee was favoring that implementation [Kernighan may have even
pointed this out in his paper they wrote after writing the software tools
in Pascal - Why Pascal is Not My Favorite Programming Language
<http://wiki.lazarus.freepascal.org/Why_Pascal_is_Not_My_Favorite_Programming_Language>
 ].**

Go google the two document I mentioned previously and it should be a fairly
simply change.  Look up file I/O and then read how VMS implemented the
association of  name.

I'm now going by memory, but a number of Pascal's did that in the reset()
function.   A number created a new function as Turbo did (assign() in this
case, but I think open() was used by a couple of other Pascals. I think a
couple of other pass it in via the Program function and style other that
supported separate libraries (usually called units) did it other ways still.

For grins, in the late 1970s at an HP/Tektronix  'Hatfield/McCoy' style
party - in those days HP in particular was Basic happy and Tek was mostly
Pascal.   We counted over 25 different incompatible 'HP Basic'
implementations, and over 10 different Tek Pascals.

These are just the sorts of things you need the Turbo Pascal manual in one
had if that is were you are coming from and in this case the VMS Pascal
manual in the other.  Look up assign() in the first and the read how
perform the same action in the other.

Good Luck,
Clem

** IMHO: This is a good example of where C 'beat' Pascal - the I/O was
defined by UNIX and when it came time to create a standard, C mostly kept
the UNIX semantics and was able to keep many/most of the OS-ism from other
systems out.
ᐧ

On Thu, Feb 8, 2018 at 12:21 PM, Dan Gahlinger <dgahl...@hotmail.com> wrote:

> so here you go, a simple file compare I wrote using "freepascal" (
> freepascal.org) and I've done what I can to convert it to vms pascal
> but it doesn't compile.
>
> code:
> Program fcomp(input,output);
> var
>   f, g, h : text;
>   s, t, u : varying [255] of char;
>   c, d : char;
>   i : integer;
> begin
>   s := 'first.txt';
>   t := 'second.txt';
>   u := 'output.txt';
>   i := 0;
>   assign(f,s);
>   reset(f);
>   assign(g,t);
>   reset(g);
>   assign(h,u);
>   rewrite(h);
>   while (not(eof(f))) do
> begin
>   read(f,c);
>   read(g,d);
>   i := i + 1;
>   if (c <> d) then
> writeln(h,i,' = 1:[',c,']/',ord(c),' 2:[',d,']/',ord(d));
> end;
>   close(f);
>   close(g);
>   close(h);
> end.
>
> errors:
>  pas fcomp.pas
> 00016  0  1   assign(f,s);
>   1
> %PASCAL-E-UNDECLID, (1) Undeclared identifier ASSIGN
> at line number 16 in file DUA1:[DAN]FCOMP.PAS;4
> %PASCAL-E-ENDDIAGS, PASCAL completed with 1 diagnostic
>
> --
> *From:* Clem Cole <cl...@ccc.com>
> *Sent:* February 8, 2018 10:58 AM
> *To:* Dan Gahlinger
> *Cc:* Gary Lee Phillips; Tim Shoppa; simh@trailing-edge.com
> *Subject:* Re: [Simh] anyone know how to convert/translate turbo pascal
> to vax pascal?
>
> Dan,
>
> As others have said something smells wrong here.  It's true the original
> '71 report from Wirth did not defined I/O and '72 revised report only
> defined write.  By the time of the Jensen & Wirth book from Springer-Verlag
> in the mid-late '70s writeln is there.  And by the time of the first
> standard efforts @ IEEE and ANSI it very much in the language.  I do have
> an old copy ANSI/IEEE770X3.97-1983 "American National Standard Pascal
> Computer Programming Language" which on page 93 (Section 6.9.3) defines the
> required standard Pascal function writeln:
>
> *6.9.4 The Procedure Writeln.*
>
> The syntax of the parameter list of writeln shall be:
>
> writeln-parameter-list = [ "(" ( file-variable | write-parameter )
>   | "," write-parameter | ")" ] .
>
> *Writeln* shall only be applied to textfiles. If the file-variable or the
> writeln-parameter-list is omitted, the procedure shall be applied to the
> required textfile output.
>
>
> From a quick search on the HP web site (http://h41379.www4.hpe.com/
> commercial/pascal/pascal_index.html ) I found reference to the SPD and
> the site says:  :
>
> HP Pascal (formerly known as Compaq Pascal and DEC Pascal) runs on OpenVMS
> for VAX systems, OpenVMS for AlphaServer systems, and OpenVMS for Integrity
> servers. With HP Pascal, your source code investment is not only protected,
> it is extended.
>
> HP Pasca

Re: [Simh] anyone know how to convert/translate turbo pascal to vax pascal?

[Clem Cole]

Dan,

As others have said something smells wrong here.  It's true the original
'71 report from Wirth did not defined I/O and '72 revised report only
defined write.  By the time of the Jensen & Wirth book from Springer-Verlag
in the mid-late '70s writeln is there.  And by the time of the first
standard efforts @ IEEE and ANSI it very much in the language.  I do have
an old copy ANSI/IEEE770X3.97-1983 "American National Standard Pascal
Computer Programming Language" which on page 93 (Section 6.9.3) defines the
required standard Pascal function writeln:

*6.9.4 The Procedure Writeln.*

The syntax of the parameter list of writeln shall be:

writeln-parameter-list = [ "(" ( file-variable | write-parameter )
  | "," write-parameter | ")" ] .

*Writeln* shall only be applied to textfiles. If the file-variable or the
writeln-parameter-list is omitted, the procedure shall be applied to the
required textfile output.


>From a quick search on the HP web site (
http://h41379.www4.hpe.com/commercial/pascal/pascal_index.html ) I found
reference to the SPD and the site says:  :

HP Pascal (formerly known as Compaq Pascal and DEC Pascal) runs on OpenVMS
for VAX systems, OpenVMS for AlphaServer systems, and OpenVMS for Integrity
servers. With HP Pascal, your source code investment is not only protected,
it is extended.

HP Pascal supports code compatible with either level of the ISO
specification, meets Federal Information Processing Standard Publications
(FIPS-109) requirements, and supports many features from the Extended
Pascal Standard. HP Pascal has a solid reputation as a robust,
production-quality, high-performance compiler. It is a full compiler, not
an interpretive one. Tightly integrated wit

While I do not have FIPS 109 on my system, FIPS was based on ANSI/IEEE770X3.97,
and I do have a copy of the an old DEC pascal manual so I'm 100% sure
writeln is there.  I also believe that Turbo Pascal was developed
after the ANSI/IEEE770X3.97
was published so the Turbo extension to writeln and any VMS ones should be
able to puzzled out.

Here is a pointer to Pascal for OpenVMS - User Manual Order Number:
AA-PXSND-TK

 This may give you hints.

That said, I have a PDF of the VMS Pascal Reference, but lord knows where
it came from; probably my time at DEC.   I have to believe its on bitsavers
or the like.   But when I look on page 9-67, Section 9.8.26 defines the
WRITELN procedure as defined in the standard with the one DEC extension of
supporting that last optional parameter to be: [, ERROR := error-recovery]
where error-recovery  is defined as the action to be taken when an error
occurs.

 As other have said maybe its something silly from file format conversion
like  processing as VMS record oriented I/O is different than
DOS/Windows.  But I suspect you are running into a difference in how I/O is
declared and bound to files on the disk.   My experience with a number of
different Pascal compilers 'back in the day' was this was an area for wide
variation.   This is what I would look up in the HP/Compaq/DEC user manuals
I just pointed you too.  I suspect that the 'VMS Pascal Language' manual
should help you through the DEC variant, so google is your friend to try
find a PDF.  With that open and a Turbo Pascal manual I think you'll be
fine (and if you cannot find a Turbo manual, I have to believe the
freepascal.org docs will get you a long way since they claim to be 100%
Turbo Pascal and Delphi compatible).

BTW:  One other though/place where Pascal I/O can differ is character sets,
although I don't think it a problem because PCs and Vaxen never had this
issue, if you read any the reports or "Jensen and Wirth" you will notice
that Pascal was defined for a 6-bit byte on a CDC-6600 system (SCOPE was
the OS IIRC).As I have said elsewhere, a 6-bit character was not
unusual on earlier systems -> today, we can thank Fred Brooks for the 8-bit
byte (Gene Amdahl wanted it to be 6 bits but Brooks kicked him out of his
office until he had something that could easily be handled by SW - *i.e*. a
power of 2, which Amdahl thought was wasteful for the HW).

Anyway, characters can be an issue when moving Pascal code because original
Pascal was defined with some CDC isms and in those days, CDC had as number
of different character sets.I note that if look at the ANSI standard
you'll noted the definition of all identifiers is just the lower case
[english] chars a-z for letters, the traditional digits 0-9 and very
limited number of special-symbols ( + - * / = < > [ ] . , : ' | ( ) ).
They do say:

The representation of any letter (upper-case or lower-case, differences of
font, *etc*.) occurring anywhere outside of a character-string (see 6.1.7)
shall be insignificant in that occurrence to the meaning of the program.

Because of the '6-bit ness' of some systems, the standard even provides for
alternative tokens to do things like square braces 

Re: [Simh] Crowther's Adventure game

[Clem Cole]

Again speaking for myself ... not Intel...

On Mon, Feb 5, 2018 at 4:27 PM, Kenneth Seefried 
wrote:

>
> Have you looked at the Intel Fortran compiler (https://software.intel.com/
> en-us/fortran-compilers)?  Intel/AMD-only, of course.  Supports
> Fortran-IV/77 through at least FTN2003 with 2008 bits, plus a bunch of SIMD
> & multicore stuff (SEE, AVX, Phi esp).  Free-ish download for Linux
> (non-commercial use license, mostly).  No idea how good it would do on this
> particular application, but it did a pretty good job on some crufty old
> code when I tried it.
>
>
​Indeed and it has the added advantage of 'having the DEC compiler DNA
ground up and injected back in' to quote a retired Intel Fellow (Rich Grove
- who had lead the Gem compiler at DEC).  A number of the same people are
still developing it (*i.e*. those that have not yet retired).

It is the most popular of the Fortran compilers for the HPC community and
the commercial ISV's that still have code in Fortran.  There is great care
to try to ensure old code from old systems 'just work' as well as bring in
modern Fortran features.  i.e. FORTRAN IV (such as Adventure), FORTRAN77
and VAX Fortran code should pretty much just work (I can say the last time
I tried to recompile adven.f with it - which was FORTRAN IV,  a few years
ago it recompiled and worked with out any changes).  I have personally put
VAX Fortran code through it with much success before I worked for Intel
(when I was an independent consultant).  I have been told by people that I
trust about a number of customers/ISVs that continue to do this regularly.

I do not know how much success FORTRAN-II code has had, but I did help an
old friend from IBM (one of the ASC and 360/90 designers) a few years back,
so at one point, something worked; although I have not idea how much he had
to hack his code to make ti work.

It also is modern compiler conforming to Fortran 2003, 2008, and
the initial draft Fortran 2015 standard - including features such a Cray's
Co-Arrays, parallel code generation et al. * I have not looked* at the
'SPD' nor personally tied it, but I believe it will also fully conform to
the FORTRAN90 and FORTRAN95.   Modern Fortran BTW, is from a syntax stand
point, nothing like what I was taught in the late 60s/early 70s.

Kenneth points out for noncommercial Linux use, it is available at no
charge (and it is the same bits that people pay large sums).   That
download is the same compiler as that for MacOS and Windows and uses a
common back-end/optimizer as that if Intel C/C++ (i.e. nothing has been
disabled).

I have personally brought up a plead for years  to make it available for
non-commercial use on any platform (actually, I >>personally<< believe it
should be free no matter what but that's a different story -- I understand
the reasons why it is not, I personally do not agree with them, but I'm an
OS guy not a compiler person - I used to kid Dr. Gove with the line:  "Rich
are their more developers of your compiler or developers that use your
compiler" - which was not fair, but a fun thing to do).

The point is that Intel takes Fortran seriously, since the codes that come
out of the compiler sells real silicon,  which of course is what Intel
fundamentally does - sell expensive, hot rocks to run real codes.

That all said, there is also gfortran (the GNU compiler) and translators
such as NetLIB's f2c.   Although, I do not know of anyone that uses truly
use  either for real work.  I know people that test with gfortran and check
things out; but all the serious Fortran types in the HPC world that I
am familar use either Intel, Cray or PGC compilers or some mix.   Many
sites have more than one compiler.
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT :Re: DEC Alpha Emulation

[Clem Cole]

My apologies to the list -- I did a reply all - I had intended that last
message to be sent only to Tim.
Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT :Re: DEC Alpha Emulation

[Clem Cole]

I hear you.  My point was it only failed the corner cases of failover, so I
think it would have made it to logs.  And that should have been good
enough.   Not perfect, but in practice it would have worked and it would
have simplified things immensely.

And not having the Adaptec support was in fact a real problem to added cost
and really did not add value.   My last act, I was trying too build the $1K
Alpha at the time (which I did prototype until Jessie kill it, buts that's
another story).  Folks said the cheapest Alpha was $5K -- well there was a
reason.  When we took a $799 [end user Radio Shack priced] Compaq K7 based
system and spliced a $200 EV6 into and got Tru64 working (with an Adapter
chipset on the motherboard BTW), it worked and people wanted it!!!  [I
still have the the motherboard at home and EV6 from it is on my desk at
Intel].

Look I tend to be a practical engineer.   I always felt that DEC's building
things 100% fool proof, everything had to be perfect was really what killed
the golden goose - not palmer et al.  Not being able to understand what did
needed to be "you bet the company/farm/your life" and what could be "good
enough for now and move to the next problem".  I always thought that was
one of the things Roger Gourd taught me -- how to differentiate between the
two.   I think DEC had that when the PDP-8 and PDP-11 was done and in the
early development of the Vax (hey I programmed Vax serial #1 -- VMS V1.0
was buggy as could be).   But with Vax becoming supreme, DEC lost its
way/believed its own hype.

Alpha and Tru64 are great examples of the problem.  BTW: I loved Alpha,
bleed for it etc..  Tru64 was the best UNIX implementation I have ever
used, and am proud to be a developer of TruClusters.  But it took 3 extra
years to get Tru64 out the door because it had to be perfect (and nobody
got fired for it either).

I never understood that.   Every subsystem that needed to be rewritten (TTY
handler, memory, bulk I/O) did need to be do over from the original code
from OSF for the 386 and PMAX.  But I always felt, DEC could have shipped
OSF/1 on the Alpha pretty much as is, and started to get revenue and move
the installed base.  Then subsystem by subsystem, replaced them with
something better.I also argued with Supnik BTW (whom I adore and think
the world of), the lack of 32 bits certainly made the engineering support
easier, but again it cost us.   We also basically paid the ISVs to fix
their code so it would run on 64 bit SPARC (Judy Ward's errors are still
the best I know for cleaning up 32 bit-isms.  If I have old code, I'm about
to port, I often run it through my Alpha with Judy's compiler to tell me is
going to be troublesome).

Yup 32 bit support would have been messy and we would have had to have 4
versions of the libraries just like MIPS, SPARC et al.  It would have been
a little ugly and not 'perfect' ...  but it would have worked and been
faster to market.  And ISV's would started to get some revenue.   By the
time we were 'done' - it was too little to late and folks hard already
started to look for an alternative - and guess what Winders on a 386 was
'good enough.'

As I said to Jessie et al, SW is not written on $1M computers - its written
on the cheapest thing that gets the job done.  Then moved upstream if it is
valuable.

By the time the Sr Managers took the 'cut a deal with Microsoft and get
their SW' strategy, the death spiral was well underway. And they
misunderstood, they were never going to get 'big bucks' for 'commodity sw.'
 [Intel suffered that also with Itanium].

BTW: I'm watching Intel make more of the same mistakes   sigh.  As I
say to folks here, I have those tee shirts,   I know how this movie ends.


Clem

BTW: the best people in Intel IT are the Macs@Intel folks.They listen
and understand I can help them.  So they try to help me.   Its a good
arrangement.  When they send me a note, I do try to help.  I'm one of the
few folks in lingering that 'update access' to their tools library (biggest
issue is its all written in VB  -- seriously for Mac's -- don't ask).
 But when I find something, I do try to help.   In return, I ran into an
issue last Tues with my keyboard and called them that PM.  I missed the
Fedex time for Folsom, but on Thursday an new Mac was on my doorstep.
 Only reason I have not switched is because I had to travel Thursday for
work - so I took them both.   Got my job done and will switch systems
completely tonight (I hope).

Anyway -- back to work
ᐧ

On Mon, Feb 5, 2018 at 3:10 PM, Timothe Litt <l...@ieee.org> wrote:

> On 05-Feb-18 13:36, Clem Cole wrote:
>
>
>
> ​Point taken, but DEC used the SPD as its primary defense for exactly this
> type of problem.​ It was the 'legal' definition of what was and was not
> allowed.   But as you point out, that behavior does not always make for
> happy customers or sr managers.
>
> I started in the field, and consulted with

Re: [Simh] EXT :Re: DEC Alpha Emulation

[Clem Cole]

On Mon, Feb 5, 2018 at 1:05 PM, Timothe Litt <l...@ieee.org> wrote:

> On 05-Feb-18 12:01, Clem Cole wrote:
>

> The *word *you left out was probably the issue.
>
​Fair enough ..​



> *We just didn't make adding a node to a cluster difficult and mysterious
> enough.*
>
​Right ;-)​




> So product management's conservatism is understandable, given the risk
> that the SPD won't be re-read when the function of a node changes, and the
> resulting data corruption being laid at DEC's feet.
>
​Point taken, but DEC used the SPD as its primary defense for exactly this
type of problem.​ It was the 'legal' definition of what was and was not
allowed.   But as you point out, that behavior does not always make for
happy customers or sr managers.




>
> So, the counter-argument becomes "how much engineering should be invested
> in allowing a customer to save $100 on the cost of a PCI card?"  And the
> easy answer is one of "none" and "it's not a priority".  Ship only cluster
> capable hardware, and "problem solved".  Not all engineering problems are
> best solved with engineering solutions.  But I'll grant that the
> engineering would be a lot more fun :-)
>
​I hear you and your are 100% correct -- that is exactly the way it would
have been (was) handled​.  The truth is in at least Tru64  (I think is was
Feed Knight - Mr. SCSI) had code that detect when your SCSI bus was being
shared.   It would have been easy to add add a side look up to check the
control being used and if it was not in the official table, produce a boot
message saying -- "*shared bus with unsupported SCSI controller, please
remove sharing or replace controller and reboot."*

​But I could never get marketing to accept that.​

But I agree, the fact is that somebody would have tried to do it.  My point
was that if we detected it (which was not not that hard), then we could
have at least said something.   And in practice if you still ignored it and
it was in all those system logs, it would have been pretty easy to say to
the end customer, *we told you not to do that*.

Then again to your point - I know of a case where a VPN manufacturer as
told its customer not configure their VPN's the way the customer does, but
said customer's IT dept insists on doing it differently anyway - much to
the internal development engineers (@ the customer) distress.  In
this case, its a switch, the customer are being more conservative (and
silly) than the VPN manufacturer has told it to be, but breaking a lot of
things in process that should work.  The local engineers b*tch because
things break that should not -- and they find out it is a local cause by
their own IT dept.   But it is a case where
the manufacturers recommendations are not being considered and things would
work as expected (and tested by the manufacturer) if the SW was configured
as designed.

Clem



ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT :Re: DEC Alpha Emulation

[Clem Cole]

On Sat, Feb 3, 2018 at 7:28 PM, Zane Healy  wrote:

>  I had found a nearly new PWS 433a in a used computer shop, that didn’t
> know what it was worth
> ​
>

​Likely to have been one of the NT/Alpha's in the wild.   It was a dirty
little secret in ZKO and MRO that they worked fine with Tru64 and OpenVMS.
 ​Purely a co​st issue.   It was cheaper and faster to get the NT/Alpha HW
- so they became a popular internal development systems for support for the
Adaptec chipset (who's number I now forget).   But marketing never accepted
because of the failover issue for clusters.

I never understood that.  My argument was that nobody was going to put a
$1M cluster at risk with a $100 PCI card.   We could have just stated in
the SPD that the Adaptec chip set was supported on single (small) systems
such as Workstations, DS10, DS20 etc...  But I lost that war.
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT :Re: DEC Alpha Emulation

[Clem Cole]

dyslexia sucks, sorry...   s/could properly/couldn't properly/

On Fri, Feb 2, 2018 at 8:44 PM, Clem cole <cl...@ccc.com> wrote:

> Be careful.  The comment about many of the pci boards were only NT while
> that is true really is somewhat different.  For instance both vms an tru64
> (and FreeBSD for that matter) will all boot and run fine with an Adaptec
> 1542 controller (the 500au in my office only had same in it)
>
> The SPD never spoke of it because neither TruCluster nor VMScluster
> ​couldn't
>  properly do failover on them do to issues in the Adaptec microcode which
> they would not fix because the mass market never cared.  But the default
> controller for NT/Alpha was just that controller
>
> I mention this because while the qLogic controller is the official one for
> getting simh running it is going to be a PITA and the Adaptec might be a
> better first start
>
> Send me email offline if you want more info btw.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not
> quite.

ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] PDP for beginners

[Clem Cole]

On Sat, Feb 3, 2018 at 8:12 AM, Pär Moberg  wrote:

> On 03/02/2018, Bob Eager  wrote:
> > On Sat, 3 Feb 2018 11:41:38 -
> > "Dave Wade"  wrote:
> >
> >> > -Original Message-
> >> > From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Pär
> >> > Moberg
> >> > Sent: 03 February 2018 02:26
> >> > To: simh@trailing-edge.com
> >> > Subject: [Simh] PDP for beginners
> >> >
> >> > I am looking to put up a PDP-# machine to play with. What machine
> >> > and OS should I use. I am looking for simple/beginner system, or as
> >> > beginner it got.
> >>
> >> I think I would start with a PDP-8. NO telnet terminal. Simple OS,
> >> lots of software and support. If you want blinken lights try one of
> >> these:-
> >>
> >> http://obsolescence.wixsite.com/obsolescence/pidp-8-get-one
> >>
> >> its SIMH with a nice panel
> >
> > I was going to suggest the same thing. Be warned that there's quite a
> > lot of soldering in a PiDP-8 - although not as much as an SBC-6120! (I
> > have both)
>
> Why I want terminal support is so I can use some of my old clunkers as
> terminals and access the server from different places in the house.


​Like others the PDP-8 is definitely were I would start because there is so
much around for it, from single user, batch and timesharing systems.
 Google is you friend of
course
​, a couple of interesting URLs are:
Bitsavers's PDP-8 Download
,

PDP-8 Handbooks 
,
 Running_TSS_8_on_the_DEC_PiDP-8_i_and_SIMH.html
,
and
PDP-8 Net .
[BTW:  do not pass go    down load the PDP-8 users handbook to start
BTW].

There are also a number of different simulators to work with.  But there
are some caveats that have been discussed (more in the minute). I too have
a PiDP-8 and I have it connected to serial ports on the RPi to drive
physical connections, but you can use the telnet stuff from simh described
elsewhere.

That said -- as much as I love Bob Supnik and Mark Pizzolato's
wonderful simulation system (particularly if you want to talk to 'real
hardware'), if you want to to learn a but more about the PDP-8 itself, I
might recommend you also consider Berhbard Baehr's amazing PDP-8/e
simulator for the Mac:  A PDP-8/E Simulator for the Apple Macintosh
. A know a of a couple of
excellent CS Departments that use this emulation to teach their students in
their intro to architecture class because it gives also exposes some more
modern debugging schemes and thus is easier to get a handle on what is
going on 'inside.'  From the web page:

The simulated machine is a PDP-8/E with 4K words of memory and optionally a
KM8-E Memory Extension (with up to 32K words of memory) and a KE8-E
Extended Arithmetic Element. I/O devices are implemented as plugin modules,
and plugins for an ASR 33 Console Teletype, an ASR 33 Auxiliary Teletype, a
PC8-E High Speed Paper Tape Reader and Punch, and a RK8-E Disk Cartridge
System are available.

There is also a KC8-EA Programmer's Console plugin enabling the user to
operate the simulator (nearly) like a hardware PDP-8/E, including single
step execution on memory cycle level.

​As other have pointed out OS/8​ is out there which like the later DOS/11
and RT-11 which we modeled on it, is basically single user.   But there is
also TSS/8, ETOS and I think a few other
multi-
​user ​systems for the 8.   But I would recommend starting with DOS/8.I
used's OS/8 and TSS/8 'back-in-the-day.'


That said, if you do want to mess with these with real hardware such as
PiDP-8, there is an interesting feature/bug that is annoying when working
with the DOS/8 (or TSS/8) under emulation on a real-terminal (on an XTERM
or the like this is less of an issue).  It's how the hardware works and how
^S/^Q flow control is implemented in the old systems.The problem is
that the way the OS works for terminal output is that spins on a read bit
from the UART before it writes the next character.  This is done at the
lowest level of the OS.   In the old days, even at the 'slow' 10cps of an
ASR-33, the truth is the simulated hardware will push the next chars out
faster than you the human can respond.   The ^S you will send back to the
emulated system will be seen much, much later that it would have been in
the real HW.  [The solution is we need to change simh to not set the ready
bit until a real time amount of 10 cps for 110 baud or 960 cps for 9600
baud - but this is very hard to do and in practice, not needed because we
mostly use simulated TTY today].  i.e.
​If you are one a simulated TTY such as xterm, there is enough buffering in
the xterm
​ software emulation to not 'lose' character and then it adds
the ability to 'scroll back
​.​
'​
​  B​
ut on a real display 

Re: [Simh] EXT :Re: DEC Alpha Emulation

[Clem cole]

Be careful.  The comment about many of the pci boards were only NT while that 
is true really is somewhat different.  For instance both vms an tru64 (and 
FreeBSD for that matter) will all boot and run fine with an Adaptec 1542 
controller (the 500au in my office only had same in it)

The SPD never spoke of it because neither TruCluster nor VMScluster could 
properly do failover on them do to issues in the Adaptec microcode which they 
would not fix because the mass market never cared.  But the default controller 
for NT/Alpha was just that controller

I mention this because while the qLogic controller is the official one for 
getting simh running it is going to be a PITA and the Adaptec might be a better 
first start

Send me email offline if you want more info btw. 

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Feb 2, 2018, at 4:06 PM, Hittner, David T [US] (MS) 
>  wrote:
> 
> The Alpha target is the Digital Personal Workstation (PWS) 500au [codename: 
> Miata], which qualifies as a single user workstation from a minimum licensing 
> perspective.
> 
> Bob Supnik had one in his possession, and gave it to me to do comparisons. 
> The Miata has both ARC and SRM firmware "full-flash", but the initial goal is 
> to get SRM firmware to run OpenVMS and TRU64 using the serial console. 
> Planned PCI boards are: DE500 ethernet, KZPAA(narrow) and KZP??(wide) SCSI 
> disk/tape controllers, and the Digital PCI-to-PCI bridge which are all 
> supported by every OS.  If someone writes a VGA controller in the future, it 
> should be one supported by every OS, like the fairly basic S3 TRIO32/64+.
> 
> Windows NT support on ARC firmware could come later, but would require the 
> VGA card emulation, unless you wanted to run NT "headless" over the serial 
> port, which is allowed by the NT specification. ARC firmware is much harder 
> due to having an x86 register emulator, and an INT 10 BIOS emulator, as well 
> as running everything in 32-bit mode.
> 
> Yes, I would appreciate it if you would put something on your web page to 
> have interested coders contact me. I could use the help.
> 
> Dave
> 
> -Original Message-
> From: Zane Healy [mailto:heal...@avanthar.com] 
> Sent: Friday, February 2, 2018 1:50 PM
> To: Hittner, David T [US] (MS) 
> Cc: "Vorländer, Martin" ; SIMH 
> Subject: EXT :Re: [Simh] DEC Alpha Emulation
> 
> Thanks for the information Dave!  I’m glad to hear it’s still being worked 
> on.  I can well imagine what a pain the firmware is, especially if you’re 
> trying to support both the SRM and ARC firmware.  I wish I could help.  From 
> my standpoint, getting SIMH to boot OpenVMS would be a big deal.  
> 
> Are you working to support a specific platform?  I’m curious since not every 
> system supports SRM or ARC, and many of the PCI boards were only supported by 
> Windows NT.
> 
> Would you like me to put a note on the webpage for anyone interested in 
> helping to contact you via the SIMH mailing list?
> 
> Zane
> 
> 
>> On Feb 2, 2018, at 10:01 AM, Hittner, David T [US] (MS) 
>>  wrote:
>> 
>> Well, Migration Specialties is where the developer of ES40 went, anyway. :-)
>> 
>> I'm working on the SIMH Alpha simulator. It is quite a complex beast, where 
>> the firmware required to power up the system to the chevrons (>>>) is an 
>> operating system of small Linux complexity even before you can try to boot 
>> OpenVMS, TRU64 or WinNT.  I think the simulation currently runs some 56 
>> billion instructions before encountering a missing hardware simulation, and 
>> it's nowhere near the chevrons - and hasn't even built the OS interface 
>> block or the FW-level device tables yet.
>> 
>> If anyone would like to help with the Alpha development, I wouldn't say no. 
>> It takes a long time to figure what the RISC firmware is trying to 
>> accomplish. :-)
>> 
>> Dave
>> 
>> -Original Message-
>> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Vorländer, 
>> Martin
>> Sent: Friday, February 2, 2018 3:16 AM
>> To: 'SIMH' 
>> Subject: EXT :Re: [Simh] DEC Alpha Emulation
>> 
>> Zane,
>> 
>> just had a look at your Alpha page, and noticed that you missed an emulator:
>> FreeAXP / Avanti from Migration Specialties, 
>> http://www.migrationspecialties.com/
>> This is where the ES40 emulator went, AFAIK.
>> 
>> cu,
>> Martin
>> 
>> -Ursprüngliche Nachricht-
>> Von: Simh [mailto:simh-boun...@trailing-edge.com] Im Auftrag von Zane Healy
>> Gesendet: Freitag, 2. Februar 2018 05:56
>> An: SIMH 
>> Betreff: [Simh] DEC Alpha Emulation
>> 
>> I'm in the process of slowly updating my DEC Emulation website, which has 
>> been largely stagnant since 2007.  The first page I'm spending some 
>> significant time on is the DEC Alpha page, as I'm curious to see what the 
>> current options are. 

Re: [Simh] Crowther's Adventure game

[Clem Cole]

On Fri, Feb 2, 2018 at 10:04 AM, Paul Koning  wrote
>
> From what I remember, "carriage control" still applies; "TYPE" seems to be
> simply a shorthand for "WRITE (5,"

I believe I remember that there was more to it than that explicitly when it
'knew' you were a TTY, but I've​ long since forgotten those details - which
is why I'll ask some folks from the compiler team when I see them.

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Crowther's Adventure game

[Clem Cole]

On Fri, Feb 2, 2018 at 9:12 AM, Ken Cornetet <
ken.corne...@kimballelectronics.com> wrote:

> I have vague recollections that FORMAT(/) prints a new line
>
​Sounds right - I'm O-O-O, but I​'ll try to verify with the compiler folks
when I'm on the office again.

>
> Format(20A5) takes 20 elements of an array and prints them as character
> stings padded to a width of 5 characters.
>
​Right..   -- mAw - means M elements of an input data type (typically
Integer) as type Alphabet with a width of w.​


>
> "TYPE" is not standard fortran. That must have been a DEC extension.
> Standard fortran would have used "write".
>
​Yes, TYPE was introduced by DEC with PDP-10 Fortran​ to allowed for easier
terminal I/O on timesharing (original Fortran was designed for batch i.e.
LPT, or tape style out).  I believe it was picked up on the standard with
F90 - but again I'll have to ask the Fortran compiler folks.   An example
of the difference between TYPE and traditional WRITE indeed are things like
Fortran Lineprinter control, but I've forgotten the details.



>
> -Original Message-
> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Lars
> Brinkhoff
> Sent: Friday, February 2, 2018 3:41 AM
> To: Dave L 
> Cc: simh@trailing-edge.com
> Subject: Re: [Simh] Crowther's Adventure game
>
> Dave L wrote:
> > Been a long time since I wrote fortran but IIRC the first character on
> > the output line was to perform carriage-control of the LPT, so you'd
> > have to always have a leading pad character such as a space in order
> > to get the output lines to be correct. Some characters were reserved
> > actions, 1 = FF from memory. I've not looked at the code involved but
> > that'd be my first thoughts
>
> Thanks.  Since the SPEAK subroutine is only a few lines, I'll post it
> here.  Maybe someone hows how TYPE, FORMAT(20A5), and FORMAT(/) work.
>
>
>
> SUBROUTINE SPEAK(IT)
> IMPLICIT INTEGER(A-Z)
> COMMON RTEXT,LLINE
> DIMENSION RTEXT(100),LLINE(1000,22)
>
> KKT=RTEXT(IT)
> IF(KKT.EQ.0)RETURN
> 999 TYPE 998, (LLINE(KKT,JJT),JJT=3,LLINE(KKT,2))
> 998 FORMAT(20A5)
> KKT=KKT+1
> IF(LLINE(KKT-1,1).NE.0)GOTO 999
> 997 TYPE 996
> 996 FORMAT(/)
> RETURN
> END
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>

ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Bliss versus C

[Clem Cole]

On Tue, Jan 30, 2018 at 9:45 AM, Johnny Billquist  wrote:

>  if they had been able to get a pdp-10 then Unix would not have happened.
>

​That was Ken describing the Tenex development in the introduction to his
Turning award: *"I suspect Daniel Bobrow would be here instead of me if he
could not afford a PDP-10 and had to "settle" for a PDP-11."*

 https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf


 Clem
​
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Clem-Cole's Quora Answer - Why is Fortran Still in Use?

[Clem Cole]

On Mon, Jan 29, 2018 at 3:26 PM, Larry Baker  wrote:

> Hey Clem,
>
>  Can you post a link here like you did for your Fortran post that I can
> use to read your Multics post?
>

Why-did-Unix-succeed-and-not-Multics

ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS and C

[Clem Cole]

On Mon, Jan 29, 2018 at 1:33 PM, Paul Koning  wrote:

>
> PL/I has begin/end as ALGOL does.  I don't know where { } came from, but
> it isn't from PL/I.  What perhaps did come from PL/I is ; as terminator
> rather than separator.


Fair enough, although I will say I had a PL/1 style/dialect compiler from
my IBM days that I thought I remember allowing it - which may have been
BCPL, PL/360 or maybe even PL/C -- too many beers ago.  I was never much of
a PL/1 programmer, and I could easily be mushing it all together.  Most of
my 360 hacking in those days was in assembler.

FYI:  Check out:  http://www.bobbemer.com/BRACES.HTM for an interesting
discussion of curly braces.

I do sort of remember the $( and $) digraphs as IIRC the one of the
keypunch (??19?? I think)  could not create them but the ??26?? could.
Thinking
about it... it may have been that the later was allowed for BEGIN/END in
the PL/x dialect and then later Ken switched from the BCPL digraph to curly
braces.

My point was less on PL/1 and more to the point that Ken had access to BCPL
and did not have BLISS.   But he still decided to create what would become
B.

Clem

ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS and C

[Clem Cole]

On Mon, Jan 29, 2018 at 8:20 AM, dave porter 
wrote:

> I recall reading something from Dennis Ritchie to the effect
> that if he'd been able to get hold of a BLISS compiler he
> wouldn't have bothered to invent C.  But DEC held on to
> its compilers tightly.


​Hmmm.. to be honest this sound nice but I suspect it is more like
legend/wishful thinking than something Dennis would have said.
Unfortunately we can not ask him, but I can report a little on how both
languages came into being (actually all three cause you need to include B
here also) as I know/knew the designers of both and was a witness to a
small portion of the stories.  You can then decide for yourself.

Two related things that I did not mention yesterday when I was describing
the differences between the languages are that BLISS has only one data type
(a 'word') and is 'typeless' in the sense of Pascal or other strongly typed
languages.   C was originally 'weakly typed' and only later added strong
typing (and why is important).  Also remember that at the time BLISS was
designed, Wulf specifically targeted the PDP-10(the PDP-11 did not yet exist
and the PDP-8 was explicitly a non-target).  I'm pretty sure if you read
Wulf's original paper, they were not trying to be
architecture independent.  Also it was designed to be an >>implementation<<
language for the PDP-10.  Another point is that Wulf and team had other
tools for the PDP-10 when they wrote it - including an OS.

B (C direct predecessor), like BCPL and BLISS, was untyped and worked with
words only.   In fact, Ken is on record as saying that he was originally
starting to develop a Fortran compiler for the PDP-7 to run on UNIX (both
of which had been written in PDP-7 assembler).   He ended up with a new
semi-interpreted language that was good enough to write utilities; i.e. B
was born and started a life of its own.  He was clearly influenced by BCPL
and had just been using PL/1 with Multics.   Clearly he was trying to
create an implementation language for the PDP-7.  But Ken was not using any
tools other than his own for the PDP-7 - in fact he was originally cross
assembling from a GECOS system.Once UNIX was 'up' on the PDP-7, it
was minimal compared to TOPS-10, that Wulf had used [check out:  pdp7-unix
is a project to resurrect Unix on the PDP-7
].

BTW: another salient point is that Ken, Dennis and team had previously
tried to purchase a PDP-10 for their lab, and had been rejected by their
management.   The whole reason Ken was working on the PDP-7, was that he
borrowed it from another group and he had access to it.   They were using
GCOS as their 'main systems' and the PDP-7 system was being developed as
an independent project.

So by the time of moving Unix to PDP-11, Dennis had switched from an
B interpreter to a B compiler; which then begat NB, ney C [See Clem Cole's
Quora answer What-language-was-the-first-C-compiler-written-in
].
  So the point is that Dennis was building tools to support their project
and C was just continuing the development of Ken's B.

One can argue, why did Ken not just build something more like BCPL instead
of B?  I can not say, maybe the brevity of { } from PL/1 was more
attractive than the Algol BEGIN/END style?   I don't know.   But I suspect
it was because he was originally targeting Fortran that he kept 'blocks' to
be minimal.   He ended up with something like BCPL in semantics and PL/1 in
syntax than Fortran.

Back to C:  With the PDP-11 Dennis added supports for different data types
- in particular bytes and byte addressing.   Originally, he left the C
language mostly typeless (everything defaulted to an int).  C stays that
way for a long time, through K   But as the language starts to get used
for other architectures, the ideas of being 'more strongly typed' starts to
come into play.   In fact, I think the two primary changes to ANSI C that
helped to cement C in the long run, were strong typing and function
prototypes (which used it).

As I think back on Wulf's intention to create a systems programming
language with good support for SW engineering, and I suspect the single
'word' and lack of typing actually would have hurt Bill's claimed intent
for BLISS (I've never asked him - I need too next time I see him).

All this comes back to my point.   Btw the time Dennis develops, C, B had
been in use and had been created incrementally from B.   If Ken had had
access to BLISS compiler, he would have needed it on GCOS, and CMU never
created same and then you are correct, sold the rights to their
implementations to DEC.  But the fact is, Ken and Dennis did have a BCPL
compiler on GCOS?  So why not just retarget it to the PDP-7?   Why did Ken
create B?

Clem


ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DEC GEM vs. Intel compilers

[Clem Cole]

a tad OT for simh ...l

On Sun, Jan 28, 2018 at 3:42 PM, Timothe Litt <l...@ieee.org> wrote:

>
> In the current STC, well, I saw a lot of NIH in Intel.  I suspect that
> what you report amounts to "Why tear up a "perfectly good compiler" to
> incorporate technology from a "failed company", when the result isn't
> directly marketable?"
>
​I understand.  Although if I believe what Stan Whitlock, Dave ​Eklund, and
Paul Winalski [3 of DEC more illustrious compiler folks for those that do
not recognize the names] have always claimed is that when they started
hacking on the Intel compiler, their were more open bug reports than ever
been reported bugs on Gem.  That does not say it was a perfectly good
compiler.

Although the fact that Gem had been written in BLISS vs. C I think colored
the opinion/choice/was the reason given;  but I've heard similar things
from the ex-K folks who had much of their technology in C.

To be honest, I think what drove Rich and the team nuts the most was not
the implementations as much as the lack of the support for things in IL
that DEC handled years ago.   As you pointed out, GEM's IL was designed for
N input languages and Y backends ... AND ... supported CISC and
RISC architectures and even had support for parallel ops.   Until LLVM came
on the scene, I'm not aware of any other compiler technology that was as
flexible - although like you, as an OS guy I follow compiler stuff as a
very interested user/observer -- much less lunch companion to the folks
building it all.




>
>
> Of course, both share the same defect - a shortsighted world view.  Which
> is easy to see a few decades later.
>
​Well, I think there is pride of authorship/NIH; and then practical
realities.   LLVM is the current 'savior' for the community, but to
be honest, its still unproven.   There is not yet a modern ''commercial
style'' FORTRAN or PL/1 front-ends and parallel ops are still a
work-in-progress.   That may change.  But as I have said here and in other
places, Fortran (and parallel Fortran in particular) pays my salary and I
don't think that is going to change for a long time because too
>>production<< code is written in it [See:  Clem-Cole's Quora Answer - Why
is Fortran Still in Use
<https://www.quora.com/Why-is-the-Fortran-language-still-in-use-and-most-importantly-relevant-in-HPC-Is-it-just-because-this-language-has-tremendous-numerical-calculation-capability-which-is-an-important-part-of-HPC/answer/Clem-Cole>
].




> ​... ​
> GEM was built & evolved by engineers from the ground up to support
> multiple languages at equivalent optimization levels.  Most other ILs start
> as an internal tool for one language; when extended, the rule is to make
> minimal changes to support each additional language.
>
​Exactly!!!​




> This keeps short term costs down (regressions against and changes to the
> first language - and tools), but you lose expressiveness (and
> optimizations).  And it ends up being warty and hackish.  But the
> incremental cost of the next wart/hack is always less than the cost of
> rototilling.  There's probably a formal proof to derive NIH from this
> observation :-)
>
​+1 :-)
​

>
> Old New England axiom: Never time to do it right; always time to do it
> over.
>
> Knuth's version: When writing software, do it once to understand the
> problem.  Then plan on throwing out what you built, and write it correctly
> from scratch.
>
> Neither is put to use in the technology world...at least not often.
>
​Amen -- IMO (and a many others) the best engineering manager the SW world
ever produced (Roger 'Fossil' Gourd) use to try to teach this lesson.  I
miss his wisdom,​




>
> INTC studied software development with M$, adopting its practices.  (Not
> necessarily its best ones.)
>
> Q.E.D.
>
​+1 ​




>
> ​... ​
> those who don't learn from history are doomed to repeat it?
>
> SimH does a great job of preserving the ability to use the artifacts.
> However, preserving the knowledge that created them is a different problem,
> as yet unsolved.
>
​I hope these and pages like TUHS are a small attempt to do some of it,
although I fear not enough people that are writing new code read.   Bless
you of trying to remember and get it down as a start.

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Clem Cole]

On Sun, Jan 28, 2018 at 4:43 PM, khandy21yo  wrote:

>
> Never had BLISS on anything until long after it would have been useful. So
> how does BLISS compare to C as a systems programming language? Is it worth
> learning at this late date?
>

​I'll try to answer your questions in verse order - probably not worth
learning; except for some education value and the ability to read and
really understand any BLISS code you might come upon (if the later is
something you really need/want to do).

Armando Stetner, of the TIG (Telephone Industries Group in MKO) once made a
set of 'BLISS is Ignorance' buttons which he gave to a lot of people (I
still have mine).   While I loved the language, I loathed it too.  ​I'm in
a interesting position here, because I learned BLISS before I learned C,
since I was CMU type at the time and a student of Wulf and his wife.

40 years later, I've written way more C then BLISS.  But as Tim was saying
there were some things about BLISS which I still miss - primarily the macro
system and the way conditional compilation was handled.   It was much more
sane that C's preprocessor; and the PDP-11 optimizer (discussed in the
Green Book) made the Ritchie C compiler see almost like a toy.

Remember, part of there design of the language was with software
engineering in mind.  Parnas et al was publishing and there was a lot of
thought about what made for good programs.  Hence, no goto.  Similarly, it
included a macro and conditional compilation system - which I think was
something that really made BLISS and C much more useful than say PASCAL.
 In fact, people wrote macro systems like m4 and RATFOR so that PL/1 and
FORTRAN could be conditionally compiled in a manner than was reasonable.
I've always said, for really SW engineering you need to have it (the
problem with C/C++ is that it gets abused and some resulting code is worse
because of it).

The CMU BLISS compiler had one of my favorite errors of all time BTW.   You
could use single letter like i, j, and k for loop variables, but if your
real variable were less than 6 chars, you could get an
'unimaginative variable name' warning.  So for real system programs,
expressions tended to actually have meaning and code was readable and easy
to understand.

BTW, like C, everything in BLISS is an expression and I think that worked
well.  Also for the PDP-10 at least, it is had no language runtime (by the
time of Alpha I think that was not wholly true).   There were a ton of
associated libraries, but the compiler did everything.   C never really
quite got to that because the Ritchie compiler was much smaller, so Dennis
put a lot into the runtime under the covers.  Frankly, as a user since
you are always using libraries, I never saw much of a difference.

BLISS suffered one major design error (which was self inflicted and is an
example of theory vs. practice) and a number of smaller ones that became
sort of a death of thousand cuts.

The big issue is the Wulf's choice of a 'store into' and 'contents of'
operators vs. the traditional 'assignment' and C style pointer
indirection.  His theory is 100% correct and it made the language much
cleaner and >>once you understood it<<; much more regular.  C ended up with
*, &, -> and a dot operator to handle different linguistic items.   BLISS
is much more compact and from a >>compiler's writers standpoint<<
mathematically explicit (which is what Bill was of course).  The idea was
that if the language was consistent it make for better programs. The
problem is that in practice, humans do not read code the same way as a
compiler and the BLISS conventions take a lot of getting used to.   Plus if
you are 'multi-lingual' your brain has to switch between the two schemes.
[Bill would later admit privately at least, it was great concept that in
practice, just did not pan out].

And finally, in the days of the old drum printers, if you ever look at
printouts you will see a certain amount of 'bouncing' of text in a line,
caused by the head solenoids firing a little early or late.   This means
tops and bottoms of characters were often cut off and small symbols (like
the period) might not be seen at all on the paper (although if you looked
carefully you might see a small indentation from where is was supposed to
have been -- I have examples of this effect in some old listings BTW).  We
used to say, if your program did not work, get a pepper shaker and a sponge
 then pour a few dots and remove a few others, and it would start to work
;-)

On the smaller side, there were things like the N different exits.   IIRC
Wulf used to say that was a bad idea and he should have supported labels
and then allowed and 'exit' to got to a label.   The language took the
Algol BEGIN/END and Algol68 idea of spelling word backwards to note the end
of a something (SET TES, NSET TESN ...).And of course because
the implementation of the language was done originally on the PDP-10 and
then later moved to create a PDP-11 target but 

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Clem Cole]

On Sat, Jan 27, 2018 at 1:25 PM, Tom Morris  wrote:

> On Fri, Jan 26, 2018 at 4:28 PM, Timothe Litt  wrote:
>
>>  the front end, IL optimizer, code generators and object generators
>>
>
> IL optimizer == GEM "middle end" or was that a local colloquialism?
>
​I've never heard that term.

IL optimizer was just that.   There are also machine specific optimizers
run after code generation.

In the case of the ​Intel, there are parallelism passes now done also,
first on the IL and then later on the during CG.
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Clem Cole]

On Fri, Jan 26, 2018 at 4:28 PM, Timothe Litt  wrote:

> I don't think there was any technical reason that the front end, IL
> optimizer, code generators and object generators couldn't have been
> separate sharable libraries - and separately patchable/upgradable.
>
​I was under the impression that the shared libraries were just that and
DEC was pretty tight about if the fix was in the backend, all front end
languages had to be tested (more in a minute).​

But I suspect there was marketing (and qualification) pull toward hiding
> the boundaries when packaging.
>
​Maybe in marketing (undeserved) but qual was in important.​



> After all, some 3rd party might have written a backend for a non-DEC
> architecture.
>
​Unlikely -  the sad truth is that when both the K folks and Intel
compiler groups had access to the all the code and the doc (and the people
that designed it), guess what code base was used..  not GEM.​

Grove used to say the DEC (Gem) compiler DNA was being ground up and
reinserted into the Intel compiler.   To this day the Intel IL is not as
rich as the Gem IL and it drives a lot of the old DEC team crazy.   From
what I gather, the closest IL has been what LLVM did, but I gather than is
still pretty weak for some language structures such as FORTRAN (and I
believe PL/1).

Speaking for myself and my own personal experiences in using the both the
DEC and Intel tool chains over the years, the common back-end/runtime is acute
and you see how well Gem did vs an issue Intel has had.   I've spent years
trying to get the testing and installer folks to 'get it'  when it comes to
dependancies (I was once given an Intel div level award for 'fixing' this
issue - although 5 years later I discovered much of the work we had done
had been lost and I had a deal into a new group numbskulls -- sigh - I do
think it is current correct - if you believe/know otherwise sent me email
offline).

Intel Fortran (like DEC Fortran) is dependent on the actually
source language specific runtime (because it's written in C or BLISS)
and both runtimes are dependent on a bunch of common runtime code, not just
language specific stuff.   If you make a change to the last or middle ones:
you have to ensure that you test what is dependent upon; and and when you
install don't create (and release) private versions.  i.e. install common
runtimes, then Fortran specific, then the Fortran compiler etc...   I'm
always amazed that such a simple idea is lost on some of the installation
folks (as much as a I used to b*tch at the DEC setld installer team, they
did tend to get this right).



ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Clem Cole]

below.. at bit off topic from simulators  sorry

On Fri, Jan 26, 2018 at 3:35 PM, Hunter Goatley 
wrote:

> On 1/26/2018 2:22 PM, Timothe Litt wrote:
>
>>
>> BLISS would have done better in the outside world, except for the
>> DECision to price it higher than the market would bear.
>>
>
> Indeed! I was fortunate to get access to BLISS in college thanks to DEC's
> CSLG program, but it was their second-most expensive compiler license
> (after Ada), so virtually no one outside of DEC used it. When they
> originally released Alpha, they weren't planning to make the BLISS compiler
> available, but I and others worked to try to get DEC to change that. As I'm
> sure you know, in the end, they released it with a free license for both
> VAX and Alpha (and Itanium), but it was far too late for most people to
> have any interest in adopting it. I still do some BLISS coding, but I'm one
> of the few that I know of still doing it.


​Yup it was hard to for $5K / cpu to compete with $100 plus you got the
sources and could run it on any system - - certainly for any university.
And what DEC failed to understand was both the power of the new
microprocessors and that university hacker types would want to mess with
the compiler itself.

Tim - while I agree BLISS at the time was a more complete/better language
--- the difference in the quality of the code that they generated was night
and day - assuming you have made it self hosting etc... but . I have
also wondered if "free" would have been good enough though.   Access to the
sources so you could retarget it was a huge thing that helped C spread.  In
my own case, in the summer of 1979 when we go the experimental parts at
Tektronix that would later become the 68000, I wanted/needed an HLL to mess
with it.   What did I do? I hacked on the Ritchie C compiler and made a
crude backend -- good enough for an OS guy to do his work.

A year or so after that, when we did the TCP implementation, we needed a
HLL for our Vax (running VMS).  I did manage to get Tek to buy a BLISS
license for it.   But I remember all of us be amazed that DEC was trying to
charge so much for it.

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Clem Cole]

On Fri, Jan 26, 2018 at 2:17 PM, Johnny Billquist  wrote:
>
>
> I don't think BLISS-16 ran on PDP-10, but I could be wrong. I've never
> seen or heard anything about BLISS-16 running on Alpha or beyond.

​Gem did exactly that conceptually.​



> I guess it could be possible to do, but I sortof doubt anyone did.

​It's a testing problem.   DEC was not only doing emergency fixes ​for the
PDP-11 by the time of Alpha, so I agree.   I don't think TLG did anything
with the EOL systems by then, they had their hands full with Vax, Alpha and
386; plus all the front ends.




> If anyone have the bits, I would be very interested in hearing about it,
> as I would like to recompile some bits and pieces. (Any BLISS-16 compiler
> would be a good start.)

​VMSinc had the Gem compiler as part of their license.   As I say, they
have Neil hacking on it again.   But I believe that he is only worried
about Itanium and INTEL*64 at the moment.​  I also do not know what they
are doing with the front-ends.   Clearly, they are working with the BLISS
front-end, but I have not idea what HP has them doing for the other
languages.  I would expect to see C/C++/Fortran brought forward at least
through the dialect that DEC/Compaq/HP had at EOL, so customer code will
recompile, since I know of OVMS code in those three languages.

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Clem Cole]

On Fri, Jan 26, 2018 at 2:09 PM, Johnny Billquist  wrote:

>
> Right. As far as I know, BLISS-16 only ran under VMS.

Hmm I'd be careful here.   As I understand it,​ Hobbs has implied they did
the work on the 10 to start with because at the time TLG was using PDP-10s.
  As one of the language designers, I'd believe him.  That said, what saw
the light of day as product I can not say, I was not paying attention to
that in those days.   Phil or Tim might know.

BTW -- fun side story, the BLISS "code comment" (C Pragmas if you will for
folks that don't speak a dead language) you will see in some old CMU system
code for C.mmp and Cm* is marked 'BOH'  -- which means 'Buzz-Off-Hobbs'
telling him to turn his damned optimizer and listen to us kernel guys.
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Clem Cole]

On Fri, Jan 26, 2018 at 12:48 PM, Timothe Litt  wrote:

> I wrote a fair bit of BLISS at various stages of its evolution.  My
> recollection is:
>
> BLISS-10 & BLISS-11 came from Wulf & Co at CMU.  BLISS-10 is self-hosted
>
​Right - Wulf, Steve Hobbs et al,  FWIW: I just had lunch with Steve a few
minutes ago.​

> .
>
> BLISS-11 is an evolution of BLISS-10.  There was a PDP10-hosted version of
> BLISS-11.  I don't think it was ported to VAX.
>
> BLISS-36,-16,-32,-32E,-64E, MIPS, INTEL, IA64, are DEC's common BLISS -
> evolved (and greatly extended) from BLISS-11, but not (really)
> source-compatible for non-trivial programs.  "common" means that (with
> carefully defined exceptions that can be conditionally compiled), the same
> language is accepted by all, and it's possible to write portable programs.
> Including common BLISS itself.  RMS-10/20 is another non-trivial example -
> same sources as VAX/RMS.  There are a number of targets and host
> environment combinations that are supported.
>
> BLISS-16 is hosted on both PDP-10 and VAX, producing PDP-11 object code.
> I used both.  I didn't encounter an Alpha-hosted version - but it should
> have compiled & run there, so it probably existed.  Or was VESTed.
>
> Most software written in BLISS-10 & -11 was converted to common  BLISS.
>
> There was an attempt at self-hosting BLISS-16, but it failed -
> technically, it ran, but there really wasn't enough address space to make
> it usable.  Cross-compiling wasn't popular (networks were crude), so
> BLISS-16 was not as widely adopted.
>

​This follows my recollection/understanding with the minor tweak of
addition being BLISS-INTEL64 (not to be confused with IA64), which is what
the VMS, Inc for using now for the new OVMS port to Intel*64 systems.   I
believe that is currently running on an Alpha and cross-compiling, but Neil
Faiman (one of the authors) was not at the usual 'compiler group Friday
lunch' today to ask.  Last I knew it was not 100% self hosting, although I
think Neil has also said he had the development running on his Mac.   So he
may be cross compiling from a Mac not OVMS/Alpha - which would all testing
on his laptop.   (I've sent him email to make sure and if I'm miss-informed
I'll update).

The other thing to add is there were at least two generations of the
compilers within DEC that I knew about.  Tim you may have know of a third
when I was off doing other things.   The last (current) is the 'Gem'
compilers which was a rewrite to allow N font-ends, with Y back-ends.   I
thought 'Compatible BLISS' was done to create BLISS-36/16/32 (PDP-10, 11,
Vax) from the original CMU base; but was only targeting BLISS.   AFAIK, the
original Compatible BLISS compiler was developed on the PDP-10 and
eventually replaced the CMU code.  Prism forced the rewrite of the
back-ends and with it the later generation and TLG wanted to clean up its
act with a single back-end/optimizer that was common for all the languages
[hence the Gem project - I'd have to ask Rich Grove for the details].
IIRC, Vax was used as the base for that system, although it moved to Alpha
by the mid/late 1990s.

Clem

ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Assorted ramblings was: Re: VAX Tape Emulation?

[Clem Cole]

On Thu, Jan 25, 2018 at 7:35 PM, Armistead, Jason 
wrote:

> Clem and all
>
>
>
> Your knowledge of this and many other obscure (and not-so-obscure)
> subjects from the “early days” never ceases to amaze me.  If only there was
> a way to capture all these anecdotes  into one coherent “Wikipedia of
> computing history” …  Many of these stories are absolutely fascinating, and
> often amusing too.  Whether it’s the “he did / she did **THAT** … (which
> still lives on today)” or “we had to do this because of  limitation>” or “we cobbled this together with a few parts lying around in
> the labs at ”, they are great to read.
>
>
>
> Keep sharing the stories !  Long live the glory days of computing !
>
>
>
> Thanks
>
> Jason A.
>
>
>
​Most welcome - glad to help.

In the words of Monty Python, 'I'm not dead yet.'

Clem​
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

s/couple of people/couple of families/
ᐧ

On Thu, Jan 25, 2018 at 8:47 PM, Clem Cole <cl...@ccc.com> wrote:

>
>
> On Thu, Jan 25, 2018 at 7:46 PM, Johnny Billquist <b...@softjar.se> wrote:
>
>>
>> Domain OS using 1056 bytes? On what systems? I used a lot of DN3000, 4000
>> and 5000 systems, and they used bog standard disk drives with 512 byte
>> sectors. (Interesting systems in some ways, but their windowing system was
>> pretty horrible.)
>
>
> ​All of the early ones -- until the DN1 I'm pretty sure.   They used a
> 1024 basic block, but Mike Spourer had used the Xerox Alto trick of putting
> some of the FS metadata into the controller microcode. That's what the
> extra 32 bytes were.   Masscomp and Apollo used the same SMS 'OMPTI 7000'
> controller for the ST506/ESDI drives, and you'll see it in the
> SMS marketing literature as it says something like "Supports 512/1024/1056
> block sizes".  I have controller doc somewhere in my basement - thinking
> about it, SMS might have even supported blocks as large as 4K - but I
> definitely remember them putting the 1056 stuff in for Apollo.   Remember
> we all knew each other, the firms were one town apart and couple of people
> had somebody working at each.
>
> Anyway, with the DN1, Apollo started to use the Xylogics 4xx
> controllers and Xylogics either wanted too much money for custom microcode
> or the Apollo guys decided custom microcode was too expensive.   In our
> Stellar days, we used to kid Mike about the 1056 bytes choice. BTW, Mike
> might have done the same thing at Prime, I never looked at/knew much the
> low level I/O of those systems. [@Stellar we used 4096 as the basic size
> but that was a multiple of 512 so it was never an issue].
>
> I've lost track of Mike, but Scott Baden (who is now a Prof at UCSD) was a
> CPU guy on Prime 750 and I'm still pretty close too, and he might know.
> I'll ask him if he remembers next time I see him.
>
> Clem
> ᐧ
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

On Thu, Jan 25, 2018 at 7:46 PM, Johnny Billquist  wrote:

>
> Domain OS using 1056 bytes? On what systems? I used a lot of DN3000, 4000
> and 5000 systems, and they used bog standard disk drives with 512 byte
> sectors. (Interesting systems in some ways, but their windowing system was
> pretty horrible.)


​All of the early ones -- until the DN1 I'm pretty sure.   They used a
1024 basic block, but Mike Spourer had used the Xerox Alto trick of putting
some of the FS metadata into the controller microcode. That's what the
extra 32 bytes were.   Masscomp and Apollo used the same SMS 'OMPTI 7000'
controller for the ST506/ESDI drives, and you'll see it in the
SMS marketing literature as it says something like "Supports 512/1024/1056
block sizes".  I have controller doc somewhere in my basement - thinking
about it, SMS might have even supported blocks as large as 4K - but I
definitely remember them putting the 1056 stuff in for Apollo.   Remember
we all knew each other, the firms were one town apart and couple of people
had somebody working at each.

Anyway, with the DN1, Apollo started to use the Xylogics 4xx
controllers and Xylogics either wanted too much money for custom microcode
or the Apollo guys decided custom microcode was too expensive.   In our
Stellar days, we used to kid Mike about the 1056 bytes choice. BTW, Mike
might have done the same thing at Prime, I never looked at/knew much the
low level I/O of those systems. [@Stellar we used 4096 as the basic size
but that was a multiple of 512 so it was never an issue].

I've lost track of Mike, but Scott Baden (who is now a Prof at UCSD) was a
CPU guy on Prime 750 and I'm still pretty close too, and he might know.
I'll ask him if he remembers next time I see him.

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Clem Cole]

On Thu, Jan 25, 2018 at 7:23 PM, Johnny Billquist  wrote:

>  I thought Dave Ahl didn't come from that environment.


I'm pretty sure Ahl was in Education System's group, which I thought at one
point was in MRO (Marlboro).Small-systems was in the Mill.  MRO was
36-bit land.   So he would have had access to the 10s, but I note you're
right there had been many 8s in the Education stream.

That said, few HSs could even afford them.  Folks in HS's  (like my father
who was teaching Math in a HS outside of Philadelphia during that time
period) were most likely running on remote timesharing systems via dial-up
lines - with GE(Honywell)/Mark-IV being the giant in that business (my own
entry in the computers with him in '67 was on the Mark-II and Mark-III).
DEC's customers that were trying to get into that business were mostly
supported by PDP-10s, not small systems.

RSTS Basic is a late entry, the language support for it, originally came
from the compiler group which again was originally PDP-10 based (also
remember the PDP-11 BLISS compiler needed a 10 to run it).

I can not look in my own archives from the time, my only PDP-10
documentation I have left from the early 70s, is the white monitor 'phone
book.'  I do have later (circa '78) PDP-10/20 docs but that would have be
after the book described was published.

Clem


ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Clem Cole]

On Thu, Jan 25, 2018 at 6:44 PM, Johnny Billquist  wrote:

>  if this might be from some other BASIC dialect that DEC had at some point.
>

​I think this is the Tops-10 BASIC dialect ​
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

The old netnews copytape program from the 80s did the same thing.  Somebody
has a GitHub version of it: https://github.com/halfmanhalftaco/copytape


ᐧ

On Thu, Jan 25, 2018 at 5:47 PM, Johnny Billquist  wrote:

> Zane - unless I remember wrong, there is a tool from DECUS to copy tapes
> to a file image, and then get that back to a tape again. The RSX version is
> called TPC, and I'm pretty sure it also exists for VMS.
>
> Using that, pull your physical tapes into files, copy the files over to
> the simulated machines, and write them back out to simulated tapes there.
>
>   Johnny
>
> On 2018-01-25 16:17, Zane Healy wrote:
>
>> Just to be clear, I’m looking to backup a physical machine, to a virtual
>> tape drive, such that I can restore the data to either SIMH or a Physical
>> machine.  I don’t need to extract files.  I can extract files (and I have
>> with some of the most critical) via NFS to my Mac.
>>
>> Except for legacy hardware, most tapes I dealt with in the 90’s were in
>> the 20-40GB range.  Current tapes now are multi-Terabyte, but not something
>> most of us can afford to have at home, which is why I’m looking to go this
>> route.
>>
>> Zane
>>
>>
>>
>>
>> On Jan 25, 2018, at 5:39 AM, Tim Shoppa > tsho...@gmail.com>> wrote:
>>>
>>> A couple of the tape image utilities I wrote or updated in the 1990s
>>> have that limit. Let me see if they are still in the SIMH utility tree.
>>> They never would’ve bitten me back in the 90s because the biggest reels I
>>> ever dealt with were 3600 feet at 6250 BPI, less than 250 Mbytes.
>>>
>>> Tim
>>>
>>> On Jan 25, 2018, at 8:23 AM, Johnny Billquist > b...@softjar.se>> wrote:
>>>
>>> Hmm. None of the tools I wrote ever had that limit. They just process
 records and don't give a damn about absolute disk or tape position.

 Johnny


 Tim Shoppa > skrev: (25
 januari 2018 00:53:34 CET)

 Many common tape image tools as of two decades use 32-bit
 integers to carry offsets around and will be limited to 4Gigabyte
 tape image sizes.

 I don't think this is a fundamental limit to the tape image
 formats used by SIMH, just a common limitation of the tape image
 tools you might find from 20 years ago.

 Tim.

 On Wed, Jan 24, 2018 at 5:02 PM, Zane Healy > wrote:

 What type/size of tapes does the VAX emulation support?  I
 was looking through the doc’s and it wasn’t obvious to me.
Is there a size limit?

 Thanks,
 Zane



 ___
 Simh mailing list
 Simh@trailing-edge.com 
 http://mailman.trailing-edge.com/mailman/listinfo/simh
 

>>>
>
> --
> 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
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

On Thu, Jan 25, 2018 at 4:57 PM, Mark Pizzolato  wrote:

> I think the documentation comment “cannot write variable-length blocks
> and do not allow skipping forward over records between read operations”
> was written when talking about the common cartridge tapes that were
> available on 80s and 90s Unix workstations.  I don’t recall the name.
>
That was not UNIX, that was the QIC standard.   Yes, those were blocked at
512 bytes.   Apollo's domain systems had a b*tch of time with them because
their standard disk block was 1056 bytes​



>   These things only supported fixed block size operations and not variable
> record lengths (i.e. 80 byte tape labels, then different sized data
> records, etc.).
>
​Right the 80 byte ANSI label, then different length data records.  UNIX
handles that fine, even with RMT.​  FYI: My grad school housemate, Tom
Quarles (of SPICE3 fame) wrote the ANSI tape and bunch of
other tape support that most UNIX systems used, explicitly so he could
read/write VMS tapes for the DEC guys who were doing some of the funding of
the USB CAD lab.   Leffler (who wrote rmt) used Tom's tape stuff for the
original debug of rmt.




>   Given that the remote tape drive was a drive which could do variable
> length record activities, I think MultiNet’s rmt support actually worked
> well.  I don’t remember testing it though.  Whether someone should try to
> do that now to backup simulated VMS systems is another subject I may write
> about a little later.
>

​Understood.   I was just suggest​ing trying to keep another emulated
system out of the scheme and going directly to the remote device either
through DECnet or rmt or maybe even using a NAS as virtual tape files.   It
just seemed running a Linux with a tape and then running an emulated VAX on
top of that seemed like an extra layer of indirection if there was an
easier path.


​
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

On Thu, Jan 25, 2018 at 4:14 PM, Larry Baker  wrote:

> Because UNIX tapes and tape drivers cannot write variable-length blocks
> and do not allow skipping forward over records between read operations
>

​That's not a correct statement.   UNIX does it great - I've used it (and
rmt) for years.  UNIX's tape driver is the most flexible of any OS I have
ever used (and I have done tapes on probably greater than 25 different OS's
over the last 40 years).  That's why I suggest it.  I wonder what the issue
for VMS is?

Hmm.. thinking about it, TCP sockets will remove the record orientation
(TCP creates an stream of octets without any records), so if you are doing
the funky RMS like stuff, its TCP that dropping those boundaries not the
UNIX tape driver.   If you want same then it need to be set as meta-data.
But the UNIX tape drive works as expected.   The 'block' size is the size
of the write, although I think the TM11 requires a minimum of 512 bytes.
Records passed with the MTIO ioctl' which mt/rmt all support..

That said,  I agree if he can get DECnet to work, that is likely to better
integrated into the utilities.

Clem

​
ᐧ
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

The question is do the standard tape utilities know how to exploit it --
i.e. the moral equiv of the UNIX sequence:  cmd -f - | rmt host

I thought CJ and Co had some way to make that work in mid 90's versions of
VMS but I've forgotten the details (many beers ago).


ᐧ

On Thu, Jan 25, 2018 at 3:11 PM, Tony Nicholson  wrote:

> On Fri, 26 Jan 2018 at 07:00, Larry Baker  wrote:
>
>> Clem,
>>
>> MultiNet included rmt support.  I do not know which versions included it
>> or whether MultiNet has a Hobbyist License.
>>
>
>
> Process Software’s Multinet  and PMDF for OpenVMS have had hobbyist
> licenses for a long time now. All you need to do is apply and provide an
> LMF checksum value from your hobbyist licence - see the link from the
> OpenVMS Resources page at
>
> http://www.process.com/psc/resources/openvms-resource-center/
>
> Tony
> --
> Tony Nicholson 
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

On Wed, Jan 24, 2018 at 5:25 PM, Zane Healy  wrote:

>
>   I’d like to backup to a simulated tape drive on the one emulated VAX.
> The largest drive on my Alpha is 50GB.  I’d prefer not to have to span
> tapes. :-)

​Another thought...  what are you running the emulator on?  Is it a
UNIX/Linux flavor of some type?   I ask because there might be another
solution that could work a little better in practice, although you'll need
to pull together some pieces.  The problem is the bits in my brain WRT
to VMS are 20+ years old and I've forgotten the details so you'll have to
do some homework.

At one point, I remember that some VMS folks in ZK3 (CJ Coppersmith seems
to stick in my head by I do not remember) were messing we putting a the UCB
sockets library into VMS and were somebody ported the Berkeley rcmd(3)
suite on VMS from Tru64.   I'm not sure if how much of that library or
which commands ever saw the light of day in a production version of VMS.
But the idea (then) was that a VMS system could use remote services (such
as a tape) via a socket.  The UNIX command is called rmt(8) (and of course
mt(8) and IIRC rmt(8) was originally based on the rcmd(3) calls from
rsh/rcp et al.

So assuming VMS supports same, using mt(8)/rmt(8) is trival on a UNIX side.
But more importantly for you is that on the UNIX side the remote
'device' can be a UNIX file as easily as a physical tape if the 'source'
side knows about using a socket as the output 'device.'.  I've used this
trick to back up some older systems to modern devices these days (my
Masscomp box for instance).  The "tape files" are stored on my NAS which
has redundant physical disks etc...  In fact,  I've even recompiled mt/rmt
for my Mac at one point and I have it working on *BSD with modern tapes
(just needed to grab the mtio.h file from BSD).
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Clem Cole]

Zane,

I'm not sure I follow your question.  Tape sizes are defined by the reel,
not the recording hardware.  Since the device is a vector (starting at
block 0) are conceptually unlimited (fixed by the number of bytes/blocks
available in the length of tape).   9-track mag tapes in 12" reels were
traditionally 2400 ft long.   3M managed to make a thinner tape and got the
tapes to 3600 ft.   The 6" reels were 600 ft and the 10" reels were 1200 ft
BTW.But the recording techniques (aka the tape densities) defined how
many bytes [NRZ - aka 800 bpi, PE - aka 1600 bpi, GRZ - aka 6250].   The
other issue is/was how big a 'block' you can write.   Anything more than
64k bytes could be problematic as the IEEE tape standards did not define
reliable ways to do that and on a VAX or PDP-11 that was traditionally the
DMA size limit anyway.

Anyway, with traditionally blocking, a 2400" tape @ 6250 you could get
about 120M of storage (~180M on 3600 " tapes) --  put another way, we used
assume that an RP06 could be backed up on 2.5 tapes.

Disks on the other hand are not a vector, but rather # of heads, #of
cylinders and the # of sectors in each cylinder.  Thus they have a more
fixed size.

Clem
ᐧ

On Wed, Jan 24, 2018 at 5:02 PM, Zane Healy  wrote:

> What type/size of tapes does the VAX emulation support?  I was looking
> through the doc’s and it wasn’t obvious to me.  Is there a size limit?
>
> Thanks,
> Zane
>
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] PDP11 on Simh for public access

[Clem Cole]

You tried to get it from someone else for your system often
PaperTape/Floppy/MagTape as Paul described.
By many times connecting the terminal to another system and 'printing' it.
Often a glass TTY had a second 'printer port' and if you did some work, you
could type it out.  Truth is it was probably a boot strap.   You typed in
something that was a subset, maybe just a file transfer.

Many Kermits were hacks from a different one from a different version.
 This was true until ckermit appeared, which was fairly late in Kermit's
life, but was the fanciest.   Then people started to create versions of
ckermit for specific systems.  They would use the older (like functional
one) to bring over the newer one.

Clem
ᐧ

On Tue, Jan 23, 2018 at 3:18 PM, Bryan Davies 
wrote:

> But I've always wondered - how do you get Kermit onto the target machine?
>
> On 23 January 2018 at 20:16, Jordi Guillaumes Pons <
> j...@jordi.guillaumes.name> wrote:
>
>>
>> Jordi Guillaumes i Pons
>> j...@jordi.guillaumes.name
>> HECnet: BITXOW::JGUILLAUMES
>>
>>
>>
>> On 23 Jan 2018, at 21:13, Paul Koning  wrote:
>>
>> SAV files would be binaries (RT11 format).  BAS are source files.
>>
>> There are a number of solutions.  Text files you could load via paper
>> tape, with the text file attached to the SIMH tape reader.  That's not as
>> good an answer for binaries though it could be made to work.
>>
>> Magtape or disk are better solutions.  Disk works well if you have a
>> program that can write disk images in a format the target OS knows.  That's
>> easy in this case; you can use my "flx" (RSTS File Exchange) program to do
>> this.  There's an older version written in C, a newer one written in Python
>> 3.  For the former, look in svn://akdesign.dyndns.org/flx/branches/V2.6,
>> for the latter, in svn://akdesign.dyndns.org/flx/trunk.  There's
>> documentation for both in those respective directories.  (Commments and bug
>> reports, especially for the new version, would be appreciated.)
>>
>>
>> There’s always kermit…
>>
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Attach tar to tape device and access it from v7 in simh

[Clem Cole]

The original V7 tar was not quite graceful about directories and that image
was probably not written by an original V7 system.  The directory issues
were fixed quickly.   You need a new tar, such as the one from 2BSD to read
that tape without error messages, although I suspect the original will read
it if
you do something like:

tar vtf foo.tar  > tapedirectory
grep and filter the directories tapedirectory and make a directory.list
then read that in a script that does mkdirs on the files in directory.list

Also warming, mkdir -p probably does not exist in V6 or V7 IIRC

 Finally, 1BSD (aka BSD) was based V6, 2BSD was for V7.  It was originally
a tp tape, if you have a tar image of it, it was converted by someone.

Clem

On Tue, Nov 7, 2017 at 5:02 PM, Will Senn <will.s...@gmail.com> wrote:

> On 11/7/17 2:45 PM, Clem Cole wrote:
>
>
>
> On Tue, Nov 7, 2017 at 3:37 PM, Clem Cole <cl...@ccc.com> wrote:
>
>> You need to convert the foo.tar file to a foo.tap before simh's mag tape
>> reader will understand it.
>>
>
> ​1.) ​
> gunzip 1bsd.tar.gz
> 2
> ​.)
> enblock <1bsd.tar >
> ​1bsd
> .tap
> ​
>
> ​3.) ​in simh:att mt0 1bsd.tap
> ​4.) in unix:  ​tar vxfb /dev/rmt0 ...
>
> Thanks, Clem. Now I'm getting somewhere!
>
> I converted to a tap file (lo and behold, I wrote a perl script that did
> this for the silly thing 2 years ago) and ran it. Then attached the tap to
> simh and in v7:
>
> # tar xvfb /dev/rmt0
> Invalid blocksize. (Max 20)
>
> hmm... that doesn't sound good, let's try it another way:
>
> # tar xv0
> tar: ashell/ - cannot create
> x ashell/cont.a, 114488 bytes, 224 tape blocks
> x ashell/READ_ME, 825 bytes, 2 tape blocks
> # ls -ld ashell
> drwxrwxr-x 2 root   64 Dec 31 22:18 ashell
> # ls ashell
> READ_ME
> cont.a
> # find . -name "more*" -a -print
> #
> ...
>
> It's coming back to me now, but oh so slowly, why is it complaining about
> cannot create all the while creating the folder? Also, darn! I was hoping
> more would be in there somewhere. Anybody know where the more or less pager
> source code might be for v7?
>
> Thanks,
>
> Will
>
>
>
> --
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Attach tar to tape device and access it from v7 in simh

[Clem Cole]

On Tue, Nov 7, 2017 at 3:37 PM, Clem Cole <cl...@ccc.com> wrote:

> You need to convert the foo.tar file to a foo.tap before simh's mag tape
> reader will understand it.
>

​1.) ​
gunzip 1bsd.tar.gz
2
​.)
enblock <1bsd.tar >
​1bsd
.tap
​

​3.) ​in simh:att mt0 1bsd.tap
​4.) in unix:  ​tar vxfb /dev/rmt0 ...




> If you want to skip that step, attach the foo.tar (or foo.tar.gz) file as
> a virtual disk.  The open it as a raw device
>
​I should have been more specific, attach the foo.tar file to >>simh<< as a
virtuak disk, the under the simulated OS (UNIX) you can open it as a raw
device.​


​i.e.
1.) ​
gunzip 1bsd.tar.gz
​3.) ​in simh:att
​rk3
 1bsd.ta
​r

​4.) ​in unix:  tar vxfb /dev/rrk3  






> Clem
>
> On Tue, Nov 7, 2017 at 2:58 PM, Will Senn <will.s...@gmail.com> wrote:
>
>> Hi,
>>
>> I think I may have asked this a couple of years ago, but I am unable to
>> find the email conversation, so I'll ask it again from a position of
>> experience and greater but still lacking knowledge... here's the background
>> - I am running a v7 instance in simh that I am quite pleased with. However,
>> I saw somewhere where someone was running some additional software on their
>> instance and of course, I just had to have it for my own. Unfortunately,
>> it's not clear how they got the software, where it's from, or how they got
>> it running. There are hints that the stuff came from early bsd. So... I
>> thought I would try getting the bsd source on to my v7 instance to see if I
>> could compile it and play around with it. There's a 1bsd.tar.gz in the tuhs
>> archive. It being a tar file, I figured I could:
>>
>> gunzip 1bsd.tar.gz
>>
>> in simh:
>>
>> att mt0 1bsd.tar
>>
>> in v7, which defaults to mt1 for some reason, (not a configured device on
>> my system and isn't created by make tm in /dev):
>>
>> tar vxfb /dev/rmt0 1
>> nboot.ini-13> boot rp0
>>
>> Invalid magtape record length, PC: 002400 (MOV 16,R0)
>>
>> or
>>
>> tar xv0
>>
>> nboot.ini-13> boot rp0
>>
>> Invalid magtape record length, PC: 002400 (MOV 16,R0)
>>
>> I don't know why the nboot.ini-13> boot rp0 artifact is appearing (prolly
>> some buffer flush when the sim aborts)... but of more concern is why I
>> can't access the tar. I'm sure it is a gap in my understanding, so I'd
>> appreciate some help.
>>
>> Thanks,
>>
>> Will
>>
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Attach tar to tape device and access it from v7 in simh

[Clem Cole]

You need to convert the foo.tar file to a foo.tap before simh's mag tape
reader will understand it.

If you want to skip that step, attach the foo.tar (or foo.tar.gz) file as a
virtual disk.  The open it as a raw device.

Clem

On Tue, Nov 7, 2017 at 2:58 PM, Will Senn  wrote:

> Hi,
>
> I think I may have asked this a couple of years ago, but I am unable to
> find the email conversation, so I'll ask it again from a position of
> experience and greater but still lacking knowledge... here's the background
> - I am running a v7 instance in simh that I am quite pleased with. However,
> I saw somewhere where someone was running some additional software on their
> instance and of course, I just had to have it for my own. Unfortunately,
> it's not clear how they got the software, where it's from, or how they got
> it running. There are hints that the stuff came from early bsd. So... I
> thought I would try getting the bsd source on to my v7 instance to see if I
> could compile it and play around with it. There's a 1bsd.tar.gz in the tuhs
> archive. It being a tar file, I figured I could:
>
> gunzip 1bsd.tar.gz
>
> in simh:
>
> att mt0 1bsd.tar
>
> in v7, which defaults to mt1 for some reason, (not a configured device on
> my system and isn't created by make tm in /dev):
>
> tar vxfb /dev/rmt0 1
> nboot.ini-13> boot rp0
>
> Invalid magtape record length, PC: 002400 (MOV 16,R0)
>
> or
>
> tar xv0
>
> nboot.ini-13> boot rp0
>
> Invalid magtape record length, PC: 002400 (MOV 16,R0)
>
> I don't know why the nboot.ini-13> boot rp0 artifact is appearing (prolly
> some buffer flush when the sim aborts)... but of more concern is why I
> can't access the tar. I'm sure it is a gap in my understanding, so I'd
> appreciate some help.
>
> Thanks,
>
> Will
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 8" Floppy disk image getting HALT error

[Clem Cole]

Paul - offered great info.   First are your sure these came from DEC
systems?  8" floppies were originally developed (by IBM to load microcode
on the 3330 disks) years before DEC started to use them.   IIRC DEC only
used them on PDP-8's and 11s.   The Vaxen and PDP-10 actually connected to
a PDP-11 front end that actually controlled them.

Second, as Paul said, trying to boot from them, unless you know what you
are doing is likely to cause a certain amount of madness, be a tad random.
   The trick would be to use the KryoFlux to get and image of the bits and
then start to work out from there what it is from the first we blocks.

Two more very important points 

when dealing with floppies, you have to remember two important things
format (hard or soft) and interleave.Early [8" in particular] used hard
formatting.   I don't think DEC's version of the 8" ever did [ Paul is more
likely to remember that type of factoid].  With hard formatting you at
least know the number of sectors in each 'ring' - but you don't know how
the SW interleaved them.  Different systems interleaved in different ways.

The KryoFlux has to have some way to handle all of this but its going to be
important to know as much as we can about who the SW was configured when we
try too decode the first we blocks.   So you need to tell folks as much as
you can about how the data came off the disk when you grab it.

Good luck.

On Mon, Jul 10, 2017 at 4:16 PM, Paul Koning  wrote:

> PDP-11 disks are not necessarily bootable.  If they aren't, attempting to
> do so may just give you a halt, or spurious behavior.  Some systems
> initialize non-bootable disks with a dummy bootstrap that tells you "this
> is not a bootable disk", but you can't necessarily count on that.
>
> Apart from that, you attached an RK05 drive, so if you gave it your RX01
> image that can't work right because an RK05 is a very different device
> (4800 512-byte sectors).
>
> Several operating systems support RX01 and/or RX02.  The first few sectors
> of the disk will give a clue which OS you have (or more precisely, which
> file system layout, which is tied to the OS).  If you can post the disk
> image in some place where people can see it, you're likely to get some
> help.  If that's not an option but you can post the first 5 sectors or so
> as hex dumps, the file system type and thus the OS you'd need to interpret
> the contents is likely to become clear.
>
> paul
>
> On Jul 10, 2017, at 4:10 PM, Walker Sampson  > wrote:
>
> Hi everyone,
>
> Let me preface this by saying that I’m unfamiliar with the original PDP
> machines. I work as a digital archivist and have received 8” floppy disks
> from which I need to recover data.
>
> I believe I have recovered at least partial data from these disks; I’ve
> connected a Y-E Data 8” floppy drive to a KryoFlux floppy disk controller
> and gotten positive sector results setting the format to a DEC RX02 sector
> image. When I investigate the resulting disk image in a hex editor, I am
> seeing clearly a report document, so I don’t believe I have a false
> positive.
>
> Outside of observing in a hex editor however, I don’t know how to access
> the disk or its contents. Using SIMH, I haven’t gotten the virtual machine
> to boot the floppy disk image.
>
> Commands “AT RK01 ” and then “BOOT RK01” give me a “HALT
> instruction, PC: 02 (HALT)” message for the PDP-11 program. The PDP-8
> stalls indefinitely and the PDP-10 outputs “Non-existent device” as well.
>
> I can’t go back to the donors and ask what machines these 8” floppies were
> used with, so I’m not sure how to begin troubleshooting.
>
> Any advice in that area is much appreciated!
>
> Thanks,
>
> Walker
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Mac Development of SIMH

[Clem cole]

Rob

Let's take this off list.  The quick answer is it depends on your expectations. 
 The difference will primarily be that the compiler moved forward in time and 
the UX stuff has changed.  The Unix-ness is pretty much constant.   Clem

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Jul 9, 2017, at 5:52 AM, Rob Jarratt  wrote:
> 
> Hello Everyone,
>  
> I am working on an emulator. I would like this emulator to work on a MacBook 
> because that is the machine used by one of the original designers of the 
> machine I am emulating. I don’t have any Mac hardware (other than an old Mac 
> Classic and a IIci). I know very little about Mac hardware and about Mac OS 
> X. I would like to get a really basic machine that is enough just to be able 
> to build SIMH and verify operation of the emulator, I don’t want to buy an 
> expensive machine because I would only use it for this one purpose.
>  
> I came across some eBay listings for some affordable Mac Minis running Mac OS 
> X 10.7.2 Lion. The MacBook I would like to target runs OS X El Capitan 
> 10.11.6. My question is simply, would one of these Mac Mini machines allow me 
> to validate the makefile, possibly even to create binaries?
>  
> Thanks
>  
> Rob
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] simh & pdp-8 os-8 forums / help

[Clem Cole]

xkcd aside, besides the info that Alan mentioned, a more help web site for
you might be Oscar Vermeulen's PiDP-8 site:
http://obsolescence.wixsite.com/obsolescence/pidp-8

He has a very cool PDP-8 running an RPi using Sim-* under the covers.   The
key is that he has a number of pre-configured OS's set up you can download
and examine. Check out:
http://obsolescence.wixsite.com/obsolescence/pidp-software--documentation

Good luck,

Clem Cole

On Sat, Jun 24, 2017 at 1:38 PM, Clem Cole <cl...@ccc.com> wrote:

> https://xkcd.com/927/
>
> On Sat, Jun 24, 2017 at 12:53 PM, Al Kossow <a...@bitsavers.org> wrote:
>
>>
>>
>> On 6/24/17 9:40 AM, Buddy Bell wrote:
>> > Googling does not
>> > show any DEC PDP centric forums (So I created my own Yahoo group
>> > https://groups.yahoo.com/neo/groups/VintageDEC/info)
>>
>> Great, fragment things even more.
>> Starting something new on Yahoo is a REALLY bad idea.
>>
>>
>> search for alt.sys.pdp8 (or alt.sys.pdp10, alt.sys.pdp11) for existing
>> USENET discussion groups
>>
>> also available at https://groups.google.com/forum/#!forum/alt.sys.pdp8
>>
>>
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] simh & pdp-8 os-8 forums / help

[Clem Cole]

https://xkcd.com/927/

On Sat, Jun 24, 2017 at 12:53 PM, Al Kossow  wrote:

>
>
> On 6/24/17 9:40 AM, Buddy Bell wrote:
> > Googling does not
> > show any DEC PDP centric forums (So I created my own Yahoo group
> > https://groups.yahoo.com/neo/groups/VintageDEC/info)
>
> Great, fragment things even more.
> Starting something new on Yahoo is a REALLY bad idea.
>
>
> search for alt.sys.pdp8 (or alt.sys.pdp10, alt.sys.pdp11) for existing
> USENET discussion groups
>
> also available at https://groups.google.com/forum/#!forum/alt.sys.pdp8
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Oddball platform as SIMH/pdp11 host

[Clem Cole]

In theory - I do not see why not.   IIRC its an YOCTO Linux port under the
covers >>with some hacking<< I'd have to ask some of my brethren in the
Intel OTC group exactly what was subsetted, although my worry is that some
of the folks that worked on that may have left Intel.  Also. I don't think
anyone ever tried to compile simh for it - so you are likely to run into a
something that is not quite kosher.
But simh's 'needs' are pretty simple, particularly if you start off sans
networking.

Another hint, having done this sort of thing in a past life, look carefully
at the target HW; as moving code from a PDP-11 to a PC, be careful trying
to map a real DEC DR-11 to certain PC parallel port implementations can end
up be a little trickier than you might think, as the semantics of each are
close but slightly different.  IIRC, You just need to be careful of order
of things, and leading and trailing edge latching semantics on the devices
that did not quite line up -- I just remember a project a few years back
were we had a nasty race condition with strange double counts and the
solution a TTL state machine between the emulated DR and the PC/Parallel
port.

FWIW:  I have a couple of Gallieo boards at home (Gen2 I think, but they
might be Gen1 - I have not messed with since the Edison's came out).   Drop
a line privately and I see if I can help you.

On Mon, Jun 5, 2017 at 10:20 PM, Gregg Levine 
wrote:

> Hello!
> Can the SIMH project materials, such as the PDP11 emulator be built
> and even managed on an Intel Galileo gen 2 ( or the gen 1) platform?
>
> This is an Intel QUARK SOC platform leveraged such that it's output
> and input is in the form of the Arduino families.
>
> However networking is already physically present, and there are two
> serial ports, the main one, and the classic one found as digital pins
> 0 and 1.
>
> Ideally what I'd like is to have the thing pose as an appropriate
> PDP11, and deliver its terminal via the second serial output.
>
> For digital I/O i'd eventually like to tease the thing to allow its
> eight regular pins to become the ones for an emulated DR-11 or DR-11C
> board.
>
> I do know that the latest release of the E11 product does make use of
> one company's digital I/O board to become either one of those. And I'm
> not even sure how to get that product to work in what I'm reasonably
> sure SIMH could do.
>
> But one problem at a time.
> -
> Gregg C Levine gregg.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Adding storage to vax running 4.3BSD

[Clem Cole]

On Thu, May 11, 2017 at 4:37 PM, Johnny Billquist  wrote:

> True. However, it isn't actually the geometry that cause the Unix messup
> here, but the fact that Unix divided disks into partitions. So it needed to
> know where each partition started. And before disklabels, it was hardcoded
> per disk type.

​To be fair


UNIX partition the RP06 because it overflowed a 16bit integer on the
PDP-11.The 36 bits machines DEC was making at the same time did have
that problem.Because UNIX supported mounted file systems which most
small computer systems could not, ​it was a fairly elegant solution.

Like many software tricks that were introduced to solve one issue, it was a
handy solution for others and partitions became de rigor for quotas,
organization and other sins.   The commercial UNIX vendors put labels and
support in the disk ROMS pretty early, (PC/UNIX's was ham strung by the
sins of IBM) but its a classic example of things are the way there are
because it made a lot of sense when it was done.   Time moved on

And as Paul and I were discussing off-line 'support' for MSCP really was
not a 'mess-up' -- it was a zip/zag where DEC went one direction and by
that time it came out, BSD was trying to solve a problem different than
what DEC's cared about and non-DEC UNIX vendors started having their own
solution.

So while its an example of the start of DEC HW being to quit being the
'focus' for things UNIX.  It was a cool new thing DEC had, but basically it
was minimally supported, not exploited, because people did not care at the
point.

Clem

Clem
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] How to access RT11/FIles11 floppy images on Windows?

[Clem Cole]

there is a unix program called rtpip  we wrote in the 1970s   i can dig up
a copy but not for a few weeks as i'm traveling but if you google under
that name you might find it

On Sat, Mar 18, 2017 at 5:50 AM, Timothe Litt  wrote:

> There probably is one.  But the easiest thing to do is boot VMS on SimH,
> use EXCHANGE to access the files, and push them over the network (e.g. ftp)
> to the platform of your choice.
>
>
> On 18-Mar-17 11:32, Tim Stark wrote:
>
> Folks,
>
>
>
> I googled and found PUTR utility but it is for PC-DOS systems only.   Does
> anyone know similar utility to access RT-11 and Files-11 floppy images for
> file extracts for other platforms (Windows, Linux, and OS X)?
>
>
>
> Thanks,
>
> Tim
>
>
> ___
> Simh mailing 
> listSimh@trailing-edge.comhttp://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 158, Issue 14

[Clem Cole]

On Thu, Mar 9, 2017 at 2:16 PM, William Pechter  wrote:

> Unibus DH/DM backplane s and boards were not supported by DEC on Unibus...


​I assume you mean were not supported on the VAX UBA.  And that would make
sense.​
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh