Re: [Simh] Largest VAX / PDP disk sizes

[Tim Shoppa]

Jason Stevens  wrote:
> Hmm what is weird is that when I look at the disktab from any BSD and
> compare it to the table in pdp11_rq.c they don't agree

Doesn't matter for MSCP disks. They're "just a bunch of blocks" and
accessed by block number.

Unless the device driver has to do host-side bad block replacement, which
you do not want to get into, and do not have to get into in the
emulator world!

> While looking up the RP06 I find this:
>
> pdp11_rp.c
>
> #define RP06_DTYPE  3
> #define RP06_SECT   22
> #define RP06_SURF   19
> #define RP06_CYL815
> #define RP06_DEV020022
> #define RP06_SIZE   (RP06_SECT * RP06_SURF * RP06_CYL * RP_NUMWD)
>
> and in the disktab:
>
> rp06|RP06|DEC RP06:\
>   :ty=removable:ns#22:nt#19:nc#815:\
>
> Which do agree

For SMD/Massbus drives, the physical geometry does matter to the driver.
I/O requests are issued based on physical track/cylinder/sector.

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

[Simh] RT-11 .DSK usage (was DECUS C)

[Tim Shoppa]

Rich asks:
> So, do I understand correctly that I can attach one of these .dsk files to
> a drive in a SimH PDP11 instance, run RSX-11M or RSTS/E, and FLX will do the
> right thing with it?  Or is there other magic involved?

Examples below show mounting the DECUS 11-424 disk image 110424.dsk
under the MSCP driver unit 1 (aka rq1 in SIMH).

The easiest way to access a RT-11 logical disk is with RT-11. No
FLX to run because RT-11 makes everything easy. e.g. after booting RT-11

[ctrl-E]
sim> att rq1 110424.dsk
sim> c


.dir du1:
 01-Aug-90
TST101.FOR 7  05-Feb-80  TST100.FOR 7  05-Feb-80
TIME  .SAV19  05-Feb-80  TIME  .FOR 3  05-Feb-80
VTDEMO.SAV21  05-Feb-80  VTDEMO.FOR 7  05-Feb-80
VT.OBJ 4  05-Feb-80  VT.MAC12  05-Feb-80
VT.TXT25  05-Feb-80  
 9 Files, 105 Blocks
 0 Free blocks

But under say RSX-11M+ you can also access using FLX, e.g. after booting
RSX-11M+:

[ctrl-E]
sim> att rq1 110424.dsk
sim> c   

>all du1:
>mou du1:/for
>run [3,54]flx
TT0>du1:/li/rt


DirectoryDU1:
23-AUG-10

TST101.FOR7. 05-FEB-80 
TST100.FOR7. 05-FEB-80 
TIME  .SAV   19. 05-FEB-80 
TIME  .FOR3. 05-FEB-80 
VTDEMO.SAV   21. 05-FEB-80 
VTDEMO.FOR7. 05-FEB-80 
VT.OBJ4. 05-FEB-80 
VT.MAC   12. 05-FEB-80 
VT.TXT   25. 05-FEB-80 
< Unused >0. 

 0. Free blocks

 Total of 105. blocks in 9. files

TT0>tt:=du1:time.for/rt
PROGRAM TIME
C   
C   This is a demonstration of some of the capabilities of the "VT"
C   routines. It generates a large date/time display at the top of
C   the VT100 screen. To stop the program and reset the VT100 type
c   letter S.
C   
[...]
TT0>

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

Re: [Simh] RT-11 .DSK usage (was DECUS C)

[Tim Shoppa]

sho...@trailing-edge.com (Tim Shoppa) wrote:
> Examples below show mounting the DECUS 11-424 disk image 110424.dsk
> under the MSCP driver unit 1 (aka rq1 in SIMH).
> [...]
> sim> att rq1 110424.dsk

Oh, one thing that many here do not seem to have caught on to with
regards to MSCP disk usage. Although
SIMH RQ supports specifying the disk type (e.g. SET RQn RA90) only a
few poorly-designed, and not so often used, operating systems care
what the disk type is set to. All the reasonable OS's treat it as a big
bunch of blocks.

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

Re: [Simh] Server down.

[Tim Shoppa]

Michael Richter  wrote:
> simh.trailing-edge.com seems to be down for the count.  It vanished sometime
> this morning (my time) and by 2AM next morning was still gone.

I was one of a couple hundred thousand people who lost power. I 
was lucky, my power was back (and the server was up) after 24 hours, 
others will be waiting 2 or 3 more days.

http://dcist.com/2011/01/power_outages_in_the_hundreds_of_th.php

I have about 6 hours of UPS capacity to ride out the briefest
outages, but to be realistic power outages of a week or two happen
several times a decade. So 24 hours is on the brief side :-)

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

Re: [Simh] scandocs.trailing-edge.com

[Tim Shoppa]

Al Kossow  wrote:
> On 1/29/11 10:08 AM, Al Kossow wrote:
>
> > OCRs of Tim's documents will appear in
> > http://bitsavers.org/scandocs.trailing-edge.com (which is an unlinked dir)
> > today as the OCR finishes
> >
>
> Acrobat OCR failed on the 36 bit documents because it thought the page size 
> was bigger
> than 45x45 inches, so I guess the metadata in the page scans is wrong.

Metadata is cleaned up. (well not exactly, I made everything fit into
8.5x11 rectangles more exactly.) Get new copies and I think you'll be OK.

I can also get you the original PNG's,
or turn the PNG's into TIFF's (can tumble handle color or greyscale TIFF's?
I remember working very hard about a decade ago making sure the PNG's
represented the red text and grey boxes in the original documents accurately.)

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

[Simh] Temporary SIMH mailing list outage

[Tim Shoppa]

There will be a temporary simh mailing-list outage this weekend as a I
adjust the mail system to deal with a particularly hairy spam conduit.

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

[Simh] SIMH list back up

[Tim Shoppa]

Sorry for the interruption this weekend. The SIMH mailing list is back up.

This was a particularly insidious case of Chinese SPAM forwarded to the
SIMH list administrator - me - through the mailing list software.

For a couple hours Saturday morning over 10,000 Chinese Spam E-mails were
arriving in my inbox every hour, all from IP addresses in China, all with
FROM addreses of qq.com.

This was a truly remarkable rate of SPAM. I was used to getting a couple
SPAM's each week but had never seen anything like this.

If anyone on the list has seen a rise in Chinese SPAM or SPAM from qq.com,
please let me know (preferably with E-mail headers) so I can investigate.

Tim (tsho...@gmail.com)
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 5 Questions (3 Questions Sire) About RSTS/E and Command Line.

[Tim Shoppa]

In the past, Sector7, Accelr8, and Boston Business Computing had “DCL shells” 
for Unix, DOS, and Windows. Usually they would do more and also map directory 
names etc. Some may still be available today.

Tim N3QE

> On Oct 7, 2017, at 10:32 AM, Brett Bump  wrote:
> 
> 
> Thanks Kevin,
> 
> Actually, I will have them connect to the 2 linux clusters I have running
> at home (simh RSTS-V4A - RSTS/E V10.1, some RT-11 and DOS-11).  There is
> also some RSTS zip kits they can work with, but I don't have any Vaxen
> running at home (nor any DECnet/HECnet).
> 
> I would love the idea of an open source DCL shell. ;-)  Anyone?
> 
>> On Fri, 6 Oct 2017, khandy21yo wrote:
>> 
>> If all else rails, you can always have them run simh under Linux.
>> Assuming they have their own Linux boxes, or vm ...
>> Many versions of Linux have an old version of simh for easy install (apt-get 
>> install simh) for Debian and Ubuntu, for example. You would only need to 
>> hand out a
>> pre-built image and startup file. Os/8?
>> Dosbox is also available for a msdos she'll
>> Linux has a boatload of shells to play with. Anyone written dcl for linux?
>> Sent from my Galaxy Tab® A
>>  Original message 
>> From: Brett Bump 
>> Date: 10/6/17 1:29 PM (GMT-07:00)
>> To: HECnet 
>> Cc: SIMH 
>> Subject: [Simh] 5 Questions (3 Questions Sire) About RSTS/E and Command Line.
>> This is mostly for Tim and Paul, but I figured to cross-post in case any
>> one might have seen this before (before I lob thy Holy Hand Grenade).
>> 1.  In cleaning up some of my old paperwork, I stumbled across a fanfold
>> .   paper copy of "RSTS/E System Programmer's Notebook" page 3 (no 1-2)
>> .   followed by Chapters 1-5 and Appendix A, B pages 1-5.  The bottom of
>> .   the Preface reads:
>> .
>> .   "What follows is a sermon, it is not a Gospel."
>> .
>> .   A section on the first page of Appendix A has a paragraph that says:
>> .
>> .   CAUTION
>> .   The PPEK sequences described in this (sic. I presume PEEK)
>> .   document are not a part of the supported
>> .   functionality of RSTS/E V6C as described
>> .   in the RSTS/E Software Product Description.
>> .
>> Has anyone seen/read this before, know who wrote it, have a digital copy
>> that could be distributed out, or am I destined to type it back in so all
>> can read (it is good material on old yellowed crackly fanfold paper)???
>> 2.  I lost a very good friend (coworker) this week to MI (he was 66).  We
>> .   were coteaching a class online Tuesday night and Wednesday morning he
>> .   was gone. :(  I have inherited 2 of his classes and wish to do the
>> .   best job I can for his students, honor his legacy, and live up to the
>> .   praise and respect he gave me that he disclosed to his students.
>> .
>> One of these classes is on command line and the text is linux specific.
>> While I love my linux machines, there has always been a natural flow when
>> typing commands on pretty much any DEC OS (a person kind of has to acquire
>> a little bit of tourette's tics to be competent with *nix).  Can someone
>> in the group provide me with a few accounts to connect to so his students
>> can see something other than linux???  I think I used to have an account
>> on CHIMPY, but that has been a while back.
>> 3.  Does anyone have a current HECnet map, so that said students could
>> .   see how HECnet is set up and navigate a couple of different machines?
>> That's all.  Sorry to be such a hermit.  I rarely poke my head out into
>> the world, but this time I felt it was for a just cause. :-)
>> Brett
>> ___
>> 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] Fanfold Photos.

[Tim Shoppa]

Brett, I remember from DECUS announcements that Martin Minow was author of
the RSTS/E System's Programmer Notebook. Thanks for the pictures!

Tim

On Sat, Oct 7, 2017 at 11:24 AM, Brett Bump  wrote:

>
> Paul, (and anyone else that wants to take a look).
>
> http://www.rsts.org/~bbump/unknown_author
>
> It's not like it is that long, I will probably end up typing it in.
>
> Brett
>
> On Fri, 6 Oct 2017, Paul Koning wrote:
>
>
>> On Oct 6, 2017, at 3:29 PM, Brett Bump  wrote:
>>>
>>>
>>> This is mostly for Tim and Paul, but I figured to cross-post in case any
>>> one might have seen this before (before I lob thy Holy Hand Grenade).
>>>
>>> 1.  In cleaning up some of my old paperwork, I stumbled across a fanfold
>>> .   paper copy of "RSTS/E System Programmer's Notebook" page 3 (no 1-2)
>>> .   followed by Chapters 1-5 and Appendix A, B pages 1-5.  The bottom of
>>> .   the Preface reads:
>>> .
>>> .   "What follows is a sermon, it is not a Gospel."
>>> .
>>> .   A section on the first page of Appendix A has a paragraph that says:
>>> .
>>> .   CAUTION
>>> .   The PPEK sequences described in this (sic. I presume PEEK)
>>> .   document are not a part of the supported
>>> .   functionality of RSTS/E V6C as described
>>> .   in the RSTS/E Software Product Description.
>>> .
>>> Has anyone seen/read this before, know who wrote it, have a digital copy
>>> that could be distributed out, or am I destined to type it back in so all
>>> can read (it is good material on old yellowed crackly fanfold paper)???
>>>
>>
>> That doesn't ring bells, and I don't seem to have that document in my
>> files.  I was part of RSTS/E development at that time, so if it came from
>> there I might have seen it but let it slip my memory.
>>
>> Could you scan a few pages, perhaps the first few and a couple of pages
>> of that appendix, so I can see more of the context?  Just a simple
>> photograph is probably good enough if you don't have a scanner.
>>
>> Typing it all in is hard work (I've done it for un-OCR-able listings, 300
>> pages).  If the listing is clean, a scan plus OCR will cut the effort very
>> considerably.  Or just a scan, since scans are perfectly readable for
>> humans.  OCR is only necessary if it's code that you want to be able to
>> compile/assemble or other kinds of data that need to be processed by some
>> program.  Not too long ago I sent an old listing of "BTSS" (RSTS v0) to
>> another person on this list, who scanned it very skillfully.  In other
>> words, those capabilities are around.
>>
>> 2.  I lost a very good friend (coworker) this week to MI (he was 66).
>>>  ...
>>>
>>
>> I'm sorry to hear that.  I don't have answers on your other two questions.
>>
>> 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] MicroSD Card for SimH on Raspberry Pi 3

[Tim Shoppa]

I have been running nearly a hundred PC/104 systems with 2002 era IDE flash and 
SIMH 24x7 for the past 17 years. No evidence of any Flash write cycle life 
limits in this application.

The application is not disk-intensive and modern SD cards could be worse than 
the ancient flash modules (but I would expect a SD card to have wear leveling 
at least)

PC/104 was the raspberry pi for us a few decades ago :-)

Tim

> On Dec 6, 2017, at 9:38 PM, Timothe Litt  wrote:
> 
> Consider a hard drive if you expect a non-trivial disk I/O load - SD cards do 
> wear out.
> 
>> On 06-Dec-17 21:08, khandy21yo wrote:
>> If you're just starting off with a pi, it might be easiest to buy a kit, 
>> which includes all the necessary parts to get started, including power 
>> supply, case, heat sinks, HDMI cable, and a SIM card preloaded with an os. 
>> Available on Amazon, and many others. 
>> 
>> Get a 32 or larger card if you want to set up a lot of drives. And the pi3 
>> is powerful enough for a lot of other games and stuff. Full Linux 
>> environment available, including compi,are, web browsers,, ...Fun toy.
>> 
>> If you don't have hdmi display available, get a HDMI to  vga converter. Also 
>> a usb keyboard and mouse.
>> 
>> 
>> 
>> Sent from my Galaxy Tab® A
>> 
>>  Original message 
>> From: Shaun McCloud 
>> Date: 12/6/17 5:33 PM (GMT-07:00)
>> To: simh@trailing-edge.com
>> Subject: [Simh] MicroSD Card for SimH on Raspberry Pi 3
>> 
>> Hello,
>> 
>> I have just gotten into SimH and am planning on getting a Raspberry Pi 3 for 
>> my SimH usage, just to not use up a lot of space on my laptop.  What is a 
>> good MicroSD card for the Pi 3 and SimH?  Or does it not really matter as 
>> long as it works fine in the Pi 3 on its own and has capacity for what I 
>> want to do?
>> 
>> Shaun McCloud, MCDST
>> 
>> 
>> ___
>> 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] Dec-10 Day announcement from Living Computers: Museum + Labs

[Tim Shoppa]

In the ancient past the SMD-under-Massbus-emulation third party
manufacturers (Emulex, etc.) would give binary patch locations to enlarge
the RSTS/E drivers for full size use. I'm sure these had to change for
every OS release.

I don't think Mentec had a full release of RSTS/E in their time. 10.1 was
mostly Y2K ready in 1992, and I'm sure through the 1990's that Mentec sold
it, but 10.1 release predated Mentec's acquisition. (Remind me, was the
RSTS/E 10.1 Macro assembler date listing fully Y2K compliant? I remember
that being a sticking point under one of the OS's.)

Tim N3QE



On Mon, Dec 11, 2017 at 9:38 AM, Paul Koning  wrote:

>
>
> > On Dec 10, 2017, at 5:12 AM, Johnny Billquist  wrote:
> >
> > Rich. This is a nice thing. Thanks.
> >
> > I have one question/wish, though.
> > I don't know if you were aware of a device called the RM06. This was a
> Massbus disk created by Shelby, which was varible size.
> > It would be a really nice thing to emulate. I can probably reverse
> engineer it from the RSX driver, and I don't know which systems ever
> supported it. RSX for sure. Possibly also RSTS/E, but beyond that is more
> uncertain. Most people and systems had moved on from Massbus before this
> drive came out.
>
> RSTS should be able to handle a third party Massbus disk if it identifies
> itself by the ID code of a DEC disk and has the same geometry.  (More
> precisely: if it has more cylinders than the original, that would be ok,
> those would be ignored.  But track and sector counts must be exact.)
>
> With the source kit, you could add a new disk model, it isn't all that
> hard though it is completely undocumented.  I suppose it might be possible
> to *replace* an existing entry.  Haven't looked at that.  Studying the
> sources should tell us.
>
> 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] PDP11 on Simh for public access

[Tim Shoppa]

In the “olden days”, by floppy, tape, or paper tape. In most cases you could 
order the media through Kermit project at Columbia University. In the case of 
PDP-11s, Sometimes rolled in with DECUS SIG tape trees.

Tim N3QE

> On 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 
>>  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] VAX Tape Emulation?

[Tim Shoppa]

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

Re: [Simh] VAX Tape Emulation?

[Tim Shoppa]

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  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
>> 
> 
> -- 
> Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
___
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)

[Tim Shoppa]

At one point in the  80’s/90’s several of the standard VMS command line tools 
were PL/1. I’m thinking in particular of the Error Log Formatter 
(ANALYZE/ERROR) but I recall some other ANALYZE/ sources being PL/1 as well.

I seem to recall DUMP and maybe some tape utilities were in Pascal.

The talk at DECUS was that Digital purposefully made sure every language was 
represented in VMS sources!

In the 2000s I recall a lot of the PL/1 and BLISS system sources had been 
converted to C. I’m guessing the conversion had to be done because not enough 
staff knew PL/1 or BLISS anymore.

Tim

> On Jan 29, 2018, at 4:24 AM, Jordi Guillaumes Pons 
>  wrote:
> 
> 
> Jordi Guillaumes i Pons
> j...@jordi.guillaumes.name
> HECnet: BITXOW::JGUILLAUMES
> 
> 
>> 
>> IIRC, DECC added #pragma linkage for that.  But that only matters in kernel 
>> code - any user mode JSB linkage  in the VAX calling standard has a 
>> corresponding CALL linkage.  
> 
> 
> Just as side info…
> 
> IBM added a different C compiler to zOS (MVS) to do systems stuff. They call 
> it “Metal-C” and comes with a different RTL and assorted header files to 
> invoke the MVS macros and address its control blocks.
> 
> I don’t know anyone who uses it. We toke a look into it and went back to 
> using assembler to interface with the system.
> 
> IBM itself still uses PL/X as systems implementation language., which as far 
> as I know has not been made available to the public until relatively recent 
> times. As the name hints at, it’s a PL/I derivative tailored for systems and 
> low level stuff (although the “regular” PL/I can do it without too much 
> changes).
> 
> 
> Jordi Guillaumes i Pons
> j...@jordi.guillaumes.name
> HECnet: BITXOW::JGUILLAUMES
> ___
> 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] Crowther's Adventure game

[Tim Shoppa]

I think adding the 1X to the FORMAT is the right thing to do long term.

The DEC TYPE-as-a-synonym-for-PRINT-but-with-different-FORMAT-usage
extension will not be familiar to the vast majority of Fortran programmers
even if they used it decades ago. I used it a LOT back in the 80's and just
barely remember it today.

Keep in mind that back in the old days, that in addition to the various
filesystem options saying whether a file was Format carriage control or
not, that there was also the ability for FORMAT statements to be
dynamically changed on the fly by a READ. So while the source code might
not have the 1X in front of it, that run-time the print FORMAT could have
been modified by a previous READ statement. I did Fortran for decades and
have only ever seen this used a few times in the real world. Possibly the
compilers and RTL's back then offered varying support even in their heyday.

Tim.

On Mon, Feb 5, 2018 at 7:16 AM, Lars Brinkhoff  wrote:

> Timothe Litt wrote:
> > You're going to have to change something. Either the format (to
> > discard the carriage control), or the IFILE to OPEN (to tell the RTL
> > discard it for you).  If it's only read with one format statement, I'd
> > go for that.
>
> Thanks.  I opted to add 1X to the FORMAT statements used by WRITE.
> There are only three places to edit.
> ___
> 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] anyone know how to convert/translate turbo pascal to vax pascal?

[Tim Shoppa]

Could the writeln issue, be a link time and not compile time? I remember having 
to specify the Pascal runtime libraries (more than one?) at link time.

Tim 

> On Feb 8, 2018, at 7:51 AM, Gary Lee Phillips  wrote:
> 
> VMS Pascal conforms to the language standards. So does Turbo Pascal, if the 
> code is written to standard.
> 
> The problem with porting in Pascal comes when language extensions are used. 
> These are often proprietary and/or hardware specific. On OpenVMS much of the 
> extended capability depends on calling system libraries, all of which are 
> supported. Turbo Pascal was designed specifically for the IBM PC and 
> "compatible" systems, and contains a lot of proprietary extensions that will 
> not be recognized by VMS Pascal's compiler.
> 
> If your code depends on graphic functions, the ones in Turbo Pascal are 
> almost entirely peculiar to that environment and will require a lot of 
> rewriting. These use custom libraries that come with the compiler, and 
> probably most can be duplicated by using OpenVMS system calls in some format. 
> Some analysis will be required to identify the hardware specific code and 
> select appropriate substitutions.
> 
> As for "free pascal" there are several incompatible implementations that go 
> by the name, so I'm not sure what you have used. However, all of them pretty 
> much support the original language definition and code that stays within that 
> standard definition will work without translation. Extensions that use 
> library calls or custom units are going to be the area that requires 
> (possibly a lot of) work.
> 
> The full VMS Pascal manuals are available in PDF form online and you should 
> begin there. 
> 
> By the way, VMS Pascal definitely supports writeln. It also has record 
> structures, etc. Those are all part of the standard language definition. We'd 
> need to see a sample of your code that doesn't work in order to figure out 
> where your problem comes from.
> 
> ___
> 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?

[Tim Shoppa]

Is this possibly a host compiler switch or host OS or host file system issue? 
The way Zane is hitting some limit at 2Gbytes for both emulated disks and tapes 
sounds like the limits of 32 bit operating systems or file systems using signed 
ints.

Tim

> On Feb 21, 2018, at 12:29 AM, Zane Healy  wrote:
> 
> 
>> On Feb 20, 2018, at 8:56 PM, Mark Pizzolato  wrote:
>> 
>> TQ limited to 2000GB means a limit of 2TB.  Do you have disks on the AXP 
>> system 
>> that big?
> 
> Unfortunately the 2000GB is a typo on my part.  A 2GB “tape" is too small for 
> me, and has been for a long time.  From the documentation:
> "User-specified capacity must be between 50 and 2000 MB. The TQK50 does not 
> support the BOOT
> command.”
> 
>> What happens if you merely backup a few hundred MB to the tape
>> with /VERIFY?
> 
> I’m not sure, I’d thought about giving that a try.  Right now I’m going to 
> focus on getting the data moved.
> 
>> The simh tape will have very different timing characteristics when 
>> reading as compared to a real physical tape.  I would still recommend
>> the TQ device since that I/O is asynch and isn't delaying instruction
>> execution (and cluster timing activities) during data transfers.  The
>> cluster exit may merely be due to timing on SCS messages.
> 
> I’ll see about testing that later.  While it’s not that practical to backup 
> to 2GB tapes, it would be interesting to see if the problem exists in the TQ 
> emulation.
> 
>>> End Result, I think I’m going to have to resort to the disk solution.
>> 
>> The disk solution has effectively similar limits (something just under 
>> 2TB) is the maximum RQ disk size.
> 
> In this case, that’s not a problem.  I’m creating 36GB “disks".
> 
>> Meanwhile, you needn't worry about ODS-5 vs ODS-2.  You're
>> driving the backup from the AXP side, and the VAX is merely serving 
>> access to disk blocks (not files).  The VAX can address the full capacity
>> of the disk.  Doing a BACKUP/IMAGE your target disk will be mounted
>> /FOREIGN on the AXP side.  No problem there.  When you want to 
>> access the contents of one of these target disks, once again you
>> merely let the VAX serve up access to disk blocks and on the AXP
>> side, you DON'T do a MOUNT/CLUSTER, but instead merely do a
>> MOUNT and you'll be able to see the file system naturally on the 
>> AXP side.
> 
> This I’m going to have to try.  I wouldn’t have thought of trying it, and it 
> would definitely fulfill one of my goals with this project.
> 
> 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] Install VAX/VMS 4.4 on a simulated VAX-11/780

[Tim Shoppa]

I'm sure those three standalone backup tapes are TU58 images which aren't
really "tapes" in the usual SIMH sense of the word. TU58 images are a
little more like "disks" in the emulator world.

You do not attach them to "TS". I think you attach them to "TD0" in a
simulated 11/750 or maybe just maybe a 11/730. I do not know if they would
work on a 11/780 or if 11/780 ever supported booting from TU58.

I don't think there's anything fundamentally wrong with using a different
version of standalone backup (later than VMS 4.4) to do the restore.

If you wanted to be super historically correct on a 11/780 in the mid-80's
you would could be using the RX01 standalone backup floppies.

Tim N3QE



On Fri, Mar 23, 2018 at 10:45 AM, Henk van de Kamer 
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/
> magtapes/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] Simulating a GT40

[Tim Shoppa]

Getting off topic but I have to chime in: The Tek 4010 vector storage scope 
family was very popular in the sciences and engineering through the end of the 
1980s. Way more common than the GT40 ever was. Tek4010 emulation lives on today!

Of course a storage scope is a very different beast if you were trying to play 
a video game.

The digital electronics in a Tek vector terminal was surprisingly simple and 
elegant.

Tim N3QE

> On Sep 3, 2018, at 1:37 PM, Al Kossow  wrote:
> 
> 
> 
>> On 9/3/18 10:29 AM, Timothe Litt wrote:
>> 
>> For most purposes, the GT40 was superseded by devices like the VT105 (VT100 
>> + b/w graphics), VT125, GiGi, & VT240.  But
>> those are all raster scan devices - which can't match the quality of a 
>> vector display.  And none of them had a lightpen.
> 
> In the vector world, the replacement was the (really expensive) VS-60, made 
> by Sanders.
> That competed with Vector General, E&S, and Megatek
> 
> There was also the weirdo VSV-11, a low-res raster display that talked VT-11 
> opcodes.
> 
> 
> ___
> 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] DMA access to the IO page

[Tim Shoppa]

Bob, a completely supported configuration for Q-bus RT-11 was 30K words (up
to 17) RAM on a MSV11D on a 11/23 or 11/03.

This started with, I think, V3B of RT-11 and continued through RT-11 5.7.

Similar systems could be configured with third party memory and would work
on Unibus 11/24's as well.

I never knew of any issues with DMA to the high memory addresses using DEC
DMA peripherals (16 bit or 18 bit address bus) or clones (almost all 18 bit
address bus).

The Falcon documentation shows how to enable memory even further up and a
patch in the RT-11 release notes shows how to configure a monitor to use
memory up higher than 30K.

I was told RSX-11S had support for 30K as well but I'm not as well versed
in RSX-11S configuration.

Tim

On Wed, Sep 5, 2018 at 10:14 PM Bob Supnik  wrote:

> Apparently, the GT40 does this. So... problems.
>
> 1. The original simulator I wrote didn't support DMA to IO space. Code
> for this was added in V4, but the code conformed to the internal
> simulator convention that all addresses are 22b wide. This is certainly
> not the case for Unibus DMA devices; those addresses are 18b wide. So
> the V4 code to test for the IO page needs to be bus-type sensitive.
>
> I'm assuming the GT40 either generates 18b addresses via Address
> Extension bits or does the 16b -> 18b conversion itself, including the
> IO page test. The "Unibus" does NOT do the IO page recognition/sign
> extension to 18b. In all Unibus systems, that's done in the CPU.
>
> On Qbus systems, IO page references are distinguished by the assertion
> of BBS7, and only address bits <12:0> matter. Either the CPU or a DMA
> device can assert BBS7, but I don't think the standard Qbus chips ever
> assert BBS7, so I don't think standard Qbus DMA devices can access the
> IO page. I could be wrong on this.
>
> 2. More critically, while all IO space addresses are accessible from the
> CPU, not all are accessible from DMA. In particular, internal CPU
> registers are not, at least on the systems I'm familiar with. (And I
> think Unibus map registers aren't either.) CPUs, in general, didn't need
> to monitor DMA activity, except for systems with internal caches, like
> the 11/70. I know for a fact that the F11 and J11 simply ignored DMA
> activity. The cache, if any, was external to the CPU, and it was the
> responsibility of the cache controller to deal with DMA activity.
>
> At the moment, the PDP11 simulator makes no distinction between IO page
> addresses that are CPU-internal vs bus-external. Without this, DMA
> devices can do truly evil things, like overwrite the PSW or memory
> management registers, that they couldn't do on a real system. So a data
> structure needs to be added to distinguish internal from external IO
> space addresses, code needs to be added to distinguish internal DIB
> entries from external, and call flags added to the IO page read/write
> routines to distinguish CPU access from DMA access.
>
> /Bob
>
>
> ___
> 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] F-11 chipset usage information

[Tim Shoppa]

In the 1980's, F-11 chip datasheets (enough to build a simple system)
seemed plentiful enough because DEC was making some attempt to market the
chips. I did some googling but find nothing. Maybe that's just a reflection
at how few non-DEC buyers there were for these chips!

Let me dive into the Micronotes and see if they give useful terms like part
numbers or published document numbers that will lead to datasheet
references.

F11's and J11's were used not just on Unibus and Q-bus CPU's but are also
found in DEC Pro's, HSC-50's, etc. So it's not unusual to find pulled chips.

Tim.

On Mon, Sep 17, 2018 at 2:26 PM Christopher Trumbour 
wrote:

> Hello,
>
> Several weeks ago I had obtained a set of DEC F-11 DIPs. That is,
> Control (303E) and Data (302H) together on one ceramic DIP package,
> and the memory management unit (304E) as a ceramic DIP. I've been
> looking online for information regarding the pinouts and usage of
> these ICs, but could only find very basic information (e.g. They
> Exist) or information that is nifty but does not answer my questions
> (e.g. Bob's web page on the F-11 with die shots).
>
> I've directly emailed Bob a few weeks ago about this, but never got
> any response. However, I know he's active on this list, so maybe if I
> post here, he will notice me? I'd really love to know more information
> about these chips, because it might be really cool to develop
> something around them.
>
> Thank you very much,
> Christopher Trumbour
> ___
> 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] SIMH mailing list will be migrating to groups.io in next month

[Tim Shoppa]

I have hosted the SIMH mailing list from my home server since December
2003.. That is almost 15 years now.

In the past several years, increasing spam and fishing attempts especially
through Chinese and Russian internet services have overwhelmed my ability
to run a home E-mail list server. A few years ago I summarily banned large
swaths of the internet potentially making mailing list participation
impossible to large parts of the world. At the same time, my home e-mail
server does not send authenticated E-mails so they aren't acceptable to
many E-mail addresses that are subscribed.

I am planning to re-host the mailing list at groups.io, which is a popular
E-mail *and* web based platform, in the next month.

I will still be overall list-owner and moderator. (Fortunately the list is
techie enough that I hardly ever have to do any moderation).

Archives of 2003-2018 SIMH mailing list traffic will continue to be
available through my home server but all new mailing list traffic will be
through the groups.io mail or web interfaces. I will still be list-owner
and overall moderator.

Thank you all!
Tim Shoppa
trailing-edge site owner and SIMH mailing list administrator
___
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)

[Tim Shoppa]

DECUS tapes RSTS-11-13 and RSTS-11-14 (contributed by of course David H
Ahl) contain many 1973 versions of the games that made it into the
original  BASIC Computer Games book.

http://pdp-11.trailing-edge.com/rsts11/

I've never done a one-to-one mapping of all the games but I don't think
they're an exact map to the ones that appeared in the book.

Interesting note about the history of this entry: the DECtape I read these
from, was obviously assembled from the paper tapes, as several of the games
were exactly reversed (end-to-end) because the paper tape had been sent
through the reader backwards.

Tim.


On Mon, Jan 21, 2019 at 8:39 AM Tony Nicholson 
wrote:

>
> On Mon, Jan 21, 2019 at 10:46 AM Will Senn  wrote:
>
>> Sorry to dredge up an old thread, but I’m curious as to the provenance of
>> the tape. Where’d you find it and do you know when it’s from?
>>
>
> The original (corrupted) Dectape image is at
>
>
> http://www.bitsavers.org/bits/DEC/pdp11/dectape/rsts/SeattlePacificCollege/158_ahl_basic_games.dta.gz
>
> Since RSTS (and RSTS/E) natively access files from DECtape in DOS-11
> format only - I found the home block was offset in the image file (If I
> recall it was not on a block boundary).  A snip of these superfluous bytes
> made it readable.  The location of the original file suggests it came from
> Seattle Pacific College.  Someone at bitsavers (Al Kossow) may know more
> about the DECtape's provenance.
>
> Tony
>
> On Jan 23, 2018, at 6:00 PM, Tony Nicholson 
> wrote:
>
> On Tue, Jan 23, 2018 at 11:37 PM, Bryan Davies 
>> wrote:
>>
>> [snip]
>>
>> I just need to get it all in a nice neat box, connect up he VT100, and
>>> download some games and things for the guests to use.
>>>
>>>
>> Bryan (and all).
>>
>> I first encountered RSTS/E in 1975 on a PDP-11/45 when I was a student
>> when I discovered a book "101 Basic Computer Games" with an accompanying
>> DECtape.
>>
>> Recently I tracked down a copy of the book in PDF format and an image of
>> the DECtape (that had to be fixed-up so that it was readable) on bitsavers .
>>
>> The book is at -
>>
>> http://www.bitsavers.org/pdf/dec/_Books/101_BASIC_Computer_Games_Mar75.pdf
>>
>> I now have this running on RSTS/E V10.1 and RSTS V06C-03 under SIMH -
>> after some minor edits to fix changes to the Basic-Plus source file syntax
>> (spaces between keywords etc).
>>
>> I've zipped-up the fixed DECtape image (DOS format) and an RL01 RSTS
>> level 1.2 format disk image (label=GAMES) that you can copy the games from
>> either and run them!
>>
>> The RL01 disk image is easiest (since DECtape support requires some
>> fiddling and correct pdp11 unibus 18-bit model selection).
>>
>> In your SIMH .ini file (assuming you have sysgen'ed some RL type disks)
>> you can -
>>set rl enable
>>set rl0 rl01
>>att rl0 rl01-games.dsk
>>
>> Then once RSTS/E is up as a privileged user just "MOUNT DL0: GAMES" and
>> look in DL0:[100,100]
>>
>> The zip file is
>> https://drive.google.com/file/d/1IgZkafQABxWUXeuEkeq1GjkBe3sF2Zgx/view?usp=sharing
>>
>> Tony
>>
>>
>>
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>
>
> --
> Tony Nicholson 
> ___
> 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)

[Tim Shoppa]

The spot-checks I've done show the DECTape to be identical in content and
spacing to the tapes I have containing DECUS RSTS-11-013 and RSTS-11-014.

As to which came first, the book or the tape, look at this comment in
GAMES.BAS from the tape:

100 %:%," CATALOG OF GAMES AND RECREATIONS ON RSTS":%
110 %,"FOR MAXIMUM ENJOYMENT OF THESE GAMES, YOU SHOULD HAVE A"
120 %,"COPY OF THE BOOK, '101 BASIC COMPUTER GAMES' BY DAVID AHL.":%

As to comments that seem to have shrunk, look at for example the shrinkage
of the original comment block from Mayfield's 1972 HP program library
version of STAR TREK, to the 1973 RSTS SPACWR version in the Ahl
collection. With most vintage BASIC interpreters there was a runtime
penalty to putting large comment blocks at the start of your program -
maybe the HP 3000 BASIC was a true compiler?

Tim


On Sun, Jan 20, 2019 at 9:14 PM Will Senn  wrote:

> Sorry to dredge up an old thread, but I’m curious as to the provenance of
> the tape. Where’d you find it and do you know when it’s from? The reason
> I’m asking is that I just spent a day typing in and debugging/working to
> comprehend the program SPACWR.BAS from the not so great scanned pages of
> 101 BASIC Computer Games off of bitsaver. As I was running the result on my
> SIMH PDP 11 running RSTS/E V06C-03, I made another run at finding the
> original source and came across this thread. I downloaded the RL01 and
> mounted in my RSTS 9.6 environment which was sysgen’d with RL support,
> loaded up the code and printed it out for a comparison. I was shocked how
> close my read of the scans were to the version here. Part of my surprise
> was naturally related to the restoration process, but the other came from
> the fact that the code from this tape doesn’t mention David Ahl, Mary Cole
> or Ida Potel, whereas they are credited in the source code in 101 games for
> minor work and debugging. As far as I can tell, other than whitespace, the
> only differences between my restored version from the 101 games scan and
> this version, is the additional attribution- which makes me wonder if Ahl,
> et. al., made ANY meaningful contribution worthy of attribution to the
> program.
>
> So, when was the tape created, before 101 games or after and who, exactly
> should have credit for the version therein?
>
> Later,
>
> Will
>
> Sent from my iPhone
>
> On Jan 23, 2018, at 6:00 PM, Tony Nicholson 
> wrote:
>
> On Tue, Jan 23, 2018 at 11:37 PM, Bryan Davies 
> wrote:
>
> [snip]
>
> I just need to get it all in a nice neat box, connect up he VT100, and
>> download some games and things for the guests to use.
>>
>>
> Bryan (and all).
>
> I first encountered RSTS/E in 1975 on a PDP-11/45 when I was a student
> when I discovered a book "101 Basic Computer Games" with an accompanying
> DECtape.
>
> Recently I tracked down a copy of the book in PDF format and an image of
> the DECtape (that had to be fixed-up so that it was readable) on bitsavers .
>
> The book is at -
>
> http://www.bitsavers.org/pdf/dec/_Books/101_BASIC_Computer_Games_Mar75.pdf
>
> I now have this running on RSTS/E V10.1 and RSTS V06C-03 under SIMH -
> after some minor edits to fix changes to the Basic-Plus source file syntax
> (spaces between keywords etc).
>
> I've zipped-up the fixed DECtape image (DOS format) and an RL01 RSTS level
> 1.2 format disk image (label=GAMES) that you can copy the games from either
> and run them!
>
> The RL01 disk image is easiest (since DECtape support requires some
> fiddling and correct pdp11 unibus 18-bit model selection).
>
> In your SIMH .ini file (assuming you have sysgen'ed some RL type disks)
> you can -
>set rl enable
>set rl0 rl01
>att rl0 rl01-games.dsk
>
> Then once RSTS/E is up as a privileged user just "MOUNT DL0: GAMES" and
> look in DL0:[100,100]
>
> The zip file is
> https://drive.google.com/file/d/1IgZkafQABxWUXeuEkeq1GjkBe3sF2Zgx/view?usp=sharing
>
> Tony
>
>
>
> ___
> 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] Nova DUMP not working

[Tim Shoppa]

Silly question:

Are you asking about RDOS Dump, or the SIMH dump command?

SIMH Dump command is "not implemented" for DG Nova.

And RDOS Dump is more like a backup command (often first argument will be
magtape output device).

Neither is much like, say, RT-11 Dump or VMS Dump or Unix od, if that is
what you are expecting. I know that is always what I expect!

Tim

On Mon, Mar 11, 2019 at 10:35 AM David or Jan Takle 
wrote:

> Using the DG Nova simulation.
> the >DUMP [filename] command always returns
> "Invalid Argument"
> no matter what argument I include (or none at all).
>
> Any ideas?
>
> thanks.
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_439855741286300_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] FAQ page

[Tim Shoppa]

I have cleaned up the website just a little, now the help page
http://simh.trailing-edge.com/help.html page links to the 6-May-2019 FAQ in
PDF form now at http://simh.trailing-edge.com/pdf/simh_faq.pdf

Tim

On Fri, May 10, 2019 at 11:10 AM Jonathan Welch  wrote:

> Some cleanup and adjusting needs to be done in regards to these help files.
>
> From here
> http://simh.trailing-edge.com/help.html
> There is a link to a missing file
> http://simh.trailing-edge.com/simh_faq.txt
>
> Googling simh faq
> gives this (not sure if there is a link to it, plus it is out of date)
> http://simh.trailing-edge.com/pdf/simh_faq.pdf
>
> Googling simh help
> gives this (also out of date)
> http://simh.trailing-edge.com/pdf/simh_faq.pdf
>
> Ideally I would like to see the link on the simh help point to the
> 2019 file mentioned in the previous message but converted to PDF
> format.
>
> Is anyone reading these messages able to perform some cleanup?
>
>
> On 5/10/19, Mark Pizzolato  wrote:
> > The latest FAQ is available with the latest sources on Github:
> >
> > https://github.com/simh/simh/blob/master/doc/simh_faq.doc?raw=true
> >
> > - Mark
> >
> > On Friday, May 10, 2019 at 7:27 AM, Jonathan Welch wrote:
> >> This works for me
> >>
> >> http://simh.trailing-edge.com/pdf/simh_faq.pdf
> >>
> >> On 5/10/19, Shane Bouslough  wrote:
> >> > Hi all, I'm new to SimH. I wanted to see the FAQ page
> >> >  but it generates a 404.
> >> >
> >> > Does anyone have the real link?
> >> >
> >> > -Shane
> >> >
> >> > --
> >> >  Shane Bouslough
> >> >  sh...@bouslough.com
> >> >
> >> >
> >> ___
> >> 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] FAQ page

[Tim Shoppa]

I have cleaned up the website just a little, now the help page
http://simh.trailing-edge.com/help.html page links to the 6-May-2019 FAQ in
PDF form now at http://simh.trailing-edge.com/pdf/simh_faq.pdf

It looks to me that GitHub will have canonical URL for the latest release
documents but maybe that's me being optimistic and it's really more
complicated.

If a GitHub guru knows of canonical URL's for many of these documents, I
could help Bob write the URL's on many of the simh pages, to take folks to
the newest version automatically.

Tim.



On Fri, May 10, 2019 at 11:22 AM Tim Shoppa  wrote:

> I have cleaned up the website just a little, now the help page
> http://simh.trailing-edge.com/help.html page links to the 6-May-2019 FAQ
> in PDF form now at http://simh.trailing-edge.com/pdf/simh_faq.pdf
>
> Tim
>
> On Fri, May 10, 2019 at 11:10 AM Jonathan Welch  wrote:
>
>> Some cleanup and adjusting needs to be done in regards to these help
>> files.
>>
>> From here
>> http://simh.trailing-edge.com/help.html
>> There is a link to a missing file
>> http://simh.trailing-edge.com/simh_faq.txt
>>
>> Googling simh faq
>> gives this (not sure if there is a link to it, plus it is out of date)
>> http://simh.trailing-edge.com/pdf/simh_faq.pdf
>>
>> Googling simh help
>> gives this (also out of date)
>> http://simh.trailing-edge.com/pdf/simh_faq.pdf
>>
>> Ideally I would like to see the link on the simh help point to the
>> 2019 file mentioned in the previous message but converted to PDF
>> format.
>>
>> Is anyone reading these messages able to perform some cleanup?
>>
>>
>> On 5/10/19, Mark Pizzolato  wrote:
>> > The latest FAQ is available with the latest sources on Github:
>> >
>> > https://github.com/simh/simh/blob/master/doc/simh_faq.doc?raw=true
>> >
>> > - Mark
>> >
>> > On Friday, May 10, 2019 at 7:27 AM, Jonathan Welch wrote:
>> >> This works for me
>> >>
>> >> http://simh.trailing-edge.com/pdf/simh_faq.pdf
>> >>
>> >> On 5/10/19, Shane Bouslough  wrote:
>> >> > Hi all, I'm new to SimH. I wanted to see the FAQ page
>> >> > <http://simh.trailing-edge.com/simh_faq.txt> but it generates a 404.
>> >> >
>> >> > Does anyone have the real link?
>> >> >
>> >> > -Shane
>> >> >
>> >> > --
>> >> >  Shane Bouslough
>> >> >  sh...@bouslough.com
>> >> >
>> >> >
>> >> ___
>> >> 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] Limits on MSCP controllers

[Tim Shoppa]

A related oddball question I always had about the M9058 breakout board.

It would appear that it could support four hard drives and one floppy. BUT
the RQDX3 manual says that RQDX3 itself maxes out at 4 drives.

If anyone has ever tried RQDX3 + M9058 + Four Drives + Floppy it would be
something to hear about! I could barely keep two RD series hard drives
spinning.

Tim N3QE

On Sun, Jun 23, 2019 at 1:30 PM Bob Supnik  wrote:

> The four ports is not arbitrary. SimH simulates actual hardware. DEC
> never built a backplane MSCP controller with more than four ports.
>
> If you want to extend the current RQ simulator to include third party
> boards (either SMD-based emulators or SCSI-based emulators), feel free
> to add an appropriate mode switch. I don't know what controller ID these
> third party boards returned, though, nor do I know how VMS determined
> the number of ports per controller.
>
> I think it would be better to understand why VMS is waiting to mount
> additional discs. Alternately, just create bigger discs and have fewer
> of them.
>
> /Bob
>
> On 6/23/2019 12:00 PM, simh-requ...@trailing-edge.com wrote:
> > This is, though, another slight silliness in simh. The limit to 4 disks
> > per controller is very artificial. The UDA50, KDA50, and maybe some
> > other controllers only have four actual, physical ports, which limited
> > them to only have four disks per controller. However, MSCP itself do not
> > have such a limitation, and common SCSI controllers for these machines
> > which use MSCP allows more than four disks on a controller, and most
> > software (at least RSX and VMS) also do not limit themselves to only
> > configure max four disks on a controller. I wish simh didn't put such
> > arbitrary limitations in. simh also decides on unit numbers by itself,
> > which could also have been nice to be able to choose.
>
> ___
> 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] Rolm 1602

[Tim Shoppa]

Computer History Museum ROLM 1602 page: 
https://www.computerhistory.org/atchm/if-it-moves-it-should-be-ruggednova/

(Just ROLM! Not Rohm and Haas the plastics company).

Tim

> On Jun 26, 2019, at 7:11 AM, Bob Supnik  wrote:
> 
> I'm fairly sure it existed. ADR (Applied Data Research) only wrote unusual 
> MIMIC simulators when needed. IIRC, we did some sort of process control or 
> analytical instrumentation project for Rolm & Haas itself, and they insisted 
> the 1602 be used. The listing for that is probably in the attic too...
> 
> /Bob
> 
>> On 6/25/2019 8:49 PM, Henry Bent wrote:
>> On Tue, 25 Jun 2019 at 20:41, Bob Supnik > > wrote:
>> 
>>Rolm & Haas made a militarized Nova-compatible minicomputer called
>>the
>>1602 - a follow on to their 1601 Ruggednova system. It had an
>>extended
>>instruction set. I know this because I found the listings for the
>>PDP10
>>based 1602 simulator in my attic tonight. I've never seen any other
>>documentation.
>> 
>>I'm not sure this system adds anything to Nova lore, but if people
>>are
>>interested, I can try to compile a "feature set" from the PDP10
>>simulator code.
>> 
>>/Bob
>>___
>>Simh mailing list
>>Simh@trailing-edge.com 
>>http://mailman.trailing-edge.com/mailman/listinfo/simh
>> 
>> 
>> Was it actually used in production, or did it just exist in a simulator 
>> form?  I can easily imagine a simulator for such a thing being written but 
>> not surviving past a failed bid process, so no hardware.
>> 
>> -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] PDP11 microstore

[Tim Shoppa]

I remember hearing from the the very outer periphery of the Mentec M1
design. Here's some comments on what "didn't seem insurmountable": "This
was by far the most complex section of the project and the phase that was
most under-estimated in the initial project plan. It was estimated that the
synthesis phase including iterative simulation and training would take 84
man days. In fact it took 264 man days."

Tim

On Mon, Jul 1, 2019 at 8:11 PM Bob Supnik  wrote:

> The PLA scheme (another invention from the fertile mind of Bill Roberts,
> architect of the LSI11 and UDA50 proto and founder of Emulex) was
> basically a microcode and gate conservation scheme. It provided enormous
> compression for the decode phase of the PDP11 and then got exploited to
> a fare-thee-well by clever microcoders like Burt Hashizume (F11) and
> Keith Henry (J11).
>
> Sometime during the 80s, when it became clear that the process problems
> with the J11 were intractable, and it could not be shrunk for higher
> performance, I outlined a design for a single chip PDP11. Because ROM
> densities and transistor counts were so much higher by then, I felt it
> could all be done in ROM, using the usual "indirection pointers" like Rs
> and Rd for source and destination registers and a fairly simple initial
> decoding scheme to break out the interesting cases. I didn't save
> anything about it in my online archive, so I don't know what happened to
> the design notes. The idea didn't go anywhere, of course; the PDP11 was
> clearly on its last legs by then.
>
> /Bob
>
> On 7/1/2019 2:36 PM, simh-requ...@trailing-edge.com wrote:
> > Message: 2 Date: Mon, 1 Jul 2019 10:50:51 -0600 From: Eric Smith
> >  To: simh@trailing-edge.com Subject: Re: [Simh]
> > Which PDP-11 to choose Message-ID:
> > 
> > Content-Type: text/plain; charset="utf-8" 
> > IIRC Bob has written that no one has succeeded at building an alternate
> J11
> > hardware implementation, e.g., in an FPGA., because the microcode is not
> > entirely ROM. There is a fairly large (for the time) PLA forming part of
> > the control store. The PLA could be transformed into a ROM, but IIRC it
> has
> > _many_  inputs, so the ROM would be YUGE.
> >
> > Almost 20 years ago I wrote a program to translate the PLA into VHDL
> > directly instantiating Xilinx 4LUT primitives to see how much resources
> it
> > would consume in e.g. a Spartan 3 FPGA. I don't recall the numbers, but
> it
> > didn't seem insurmountable at the time, and with today's bigger FPGAs and
> > 6LUTs, it's even less of a problem.
> >
> > Also, I think the synthesis tools are good enough that just giving the
> PLA
> > equations to synthesis would be fine, and my scheme of programmatically
> > transforming the equations to LUT instantiations is totally unnecessary.
> >
> > Eric
>
> ___
> 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] Semi-OT: Terminal Recommendations for use with SIMH

[Tim Shoppa]

It is now decades old, but MS-Kermit on DOS had the best VT100/VT220
emulation. In addition to super accurate display support, it also could map
the PC's NumLk key to the PF1/Gold key. This was super important back when
I used VMS EDT all the time.

On the Ethernet side: LAT Support in MS-Kermit is superb, and it also does
Telnet.

Yeah, I know, there have been no new versions of MS-Kermit in 24 years :-)

Tim N3QE

On Sat, Sep 28, 2019 at 1:14 AM Michael Kerpan  wrote:

> What terminal emulators are folk using with SIMH? Supposedly on Linux,
> xterm, when compiled with the right options and properly configured,
> is a very good DEC terminal emulator, but what do people on other
> platforms use? Are there any free/low-cost terminal emulators that are
> good for more than just remoting into current Linux boxes to do server
> admin stuff?
>
> 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

Re: [Simh] Initializing disks (triggered by the "Something Strange with RK05" chain

[Tim Shoppa]

The DL handler supports both RL01 and RL02 or a mix of them.

I believe "DUP-F-Size function failed" means that DL handler special
function 373 (SF.SIZ) was unable to determine the size (RL01 vs RL02) of
the volume... will delve into the driver source and see why this might not
be working with SIMH.

Tim


On Wed, Feb 12, 2020 at 12:30 PM Ken Hall  wrote:

> I’ve played with RT11 on and off over the years, but the one thing I’ve
> never been able to do is properly initialize an empty disk.  If I create a
> DL2: for example, and try to run initialize on it, I get back:
>
>
>
> .dir dl2:
>
> ?DIR-F-Error reading directory
>
>
>
> .init dl2:
>
> DL2:/Initialize; Are you sure? YES
>
> ?DUP-F-Size function failed
>
>
>
> This seems similar to the issues Henk Gooijen has been having with RK05’s,
> and it’s been so long since I’ve dealt with the real hardware I don’t
> recall exactly how this is supposed to work, but it seems to me it should
> just “work”.
>
>
>
> Has anyone found a solution to this?
>
>
>
>
> ___
> 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] Andy Hoffman's VMS 4.x packages

[Tim Shoppa]

I know that later versions of VAX-11 RSX support PDP-11 emulation
through software emulation of the PDP-11 commands. Even on VAX processors
that don't have PDP-11 hardware emulation.

This PDP-11 software emulation would presumably be missing in earlier
versions of VAX-11 RSX but I remember it being present circa 1986 on
Microvax II (KA630) hardware which would've been 1985/1986, the same era as
the 8200.

Tim.

On Sun, Mar 22, 2020 at 4:10 PM Ray Jewhurst  wrote:

> Just a couple of observations and a question about Andy's distros.  First,
> they WILL run on a simulated VAX-11 730 if RAM is set to 5 megabytes.
> Also, on the 730 all lp behaviour is normal.  Now for my question, is my
> intuition right in that the RSX package either won't run or simply be
> useless on the 8200/8250?
>
> Thanks
>
> Ray
> ___
> 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?

[Tim Shoppa]

BTW... great interview of Richie Lary:
https://www.youtube.com/watch?v=lp2NSbJ2H1k

On Mon, Mar 23, 2020 at 2:36 PM Paul Koning  wrote:

>
>
> > On Mar 23, 2020, at 1:29 PM, Timothe Litt  wrote:
> >
> > ...
> >> Since the KL10 was DEC's biggest, most expensive machine at the time,
> it wasn't nearly as cost sensitive as their other CPUs, so there probably
> wasn't even any consideration given to using PROM for the control store.
> > I don't think you could have found fast enough PROMs.  The KL is an ECL
> machine.  The RAMs are ECL, and the timing is hairy enough that the modules
> are only populated 1/2 way back - to fill the board would break timing.
> The boards also have loops of etch that serve as delay lines.
> Manufacturing would short the loops at the right place for each board -
> depending on how the board (and RAMs) turned out.  Today we take for
> granted process controls and tolerances that were, if not unattainable,
> unaffordable at that time.
>
> Was there such a thing as ECL ROM?  I don't remember.
>
> It's interesting to watch the evolution of high speed computers.  There's
> a continuous back and forth between memory and logic, depending on where
> the limitations are in the year or two when the design was frozen.  RAM and
> ROM have generally been different.
>
> One example that comes to mind is the character stroke generator for the
> CDC 6000 series mainframes.  That has a 10 MHz waveform step clock, so it
> needs a ROM with an access time comfortably below 100 ns (unless you want
> to use multiple banks).  In 1964 that was problematic, and the 6000 series
> display controller instead uses a massive logic chain to produce all the
> waveform data for all the character codes.  5-ish years later, in the Cyber
> 170 series, all that was replaced by a ROM.  Same data, but one chip
> instead of 100 or so plug-in logic modules.
>
> Another example, also from that machine: the memory access and scheduling
> machinery is quite complex, with 32 memory banks operating concurrently.
> That's because many of the instructions complete in far less than a memory
> cycle time: 300 or 400 ns for the simpler instructions, and even a multiply
> takes only 1000 ns, while memory cycles in 1000 ns.  By 1964 standards,
> 1000 ns was amazingly fast, I don't think anyone else came close, and the
> core memory wiring and circuitry is quite exotic to make it go so fast.
>
> On the VAX 730: as far as I'm aware it's the only VAX built out of
> standard LSI CPU components.  The guts of the CPU is AMD 2901 bit-slice
> chips.  All other DEC microprogrammed machines I can think of had their own
> purpose-designed logic.
>
> 2901 bitslices do appear in other DEC products, the UDA comes to mind.
> And that has, for running on-board diagnostic tools, a small PDP11-like
> instruction set implemented in a little bit of 2901 microcode.  By Richie
> Lary, wizard of compact software...
>
> 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] Is it possible to simulate the first Vaxen I ever used?

[Tim Shoppa]

Bob, the October 1978 LCG product strategy red book, shows the 2901-based
Minnow as a direct follow-on to the KS in the same technology lineage.

Many technology aspects (including R80 and RL02 peripheral system) in the
11/730 are exactly as they were in the planned Minnow. IIRC the R80
drawings referred to Minnow interface in several places?

Tim.

On Mon, Mar 23, 2020 at 3:00 PM Robert Armstrong  wrote:

> > Paul Koning  wrote:
> >2901 bitslices do appear in other DEC products, the UDA comes to mind
>
>   The KS was built with 2901s, right?  Or at least some 29xx family parts?
>
>   Actually the KS and the 730 implementations have a lot in common.  I
> always wondered if the same engineers worked on both, but that's probably
> unlikely.
>
> Bob
>
>
> ___
> 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?

[Tim Shoppa]

The Mick and Brick book is THE BEST and 100% applicable to the 2901-based  
11/730 and KS discussions here. 
http://bitsavers.org/components/amd/Am2900/Mick_Bit-Slice_Microprocessor_Design_1980.pdf

> On Mar 23, 2020, at 5:49 PM, Ray Jewhurst  wrote:
> 
> Slightly off topic, could someone explain more about what microcode is and 
> how it works? The fact that the CPU instructions are they themselves 
> programmed in seems unfathomable. 
> 
> Ray 
> 
>> On Mon, Mar 23, 2020, 5:33 PM Clem Cole  wrote:
>> 
>> 
>>> 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
> ___
> 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] Terminal emulation = MS-Kermit!

[Tim Shoppa]

I said it decades ago, and I’ll say it again, MS-Kermit is incredibly useful in 
emulating DEC Terminals.

I am particularly fond of its ability to put the Gold key in the right place on 
a PC-clone keypad.

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

Re: [Simh] Simh Digest, Vol 198, Issue 16

[Tim Shoppa]

The Teradata database-engine racks had large arrays of disks and high
densities of CPU's. Not sole 11/84's.

If you had a standalone short rack with a 11/84, I think that was used as
front-end communications, RJE-style, to the IBM mainframe it attached to. I
recall many vendors put a DEC bisync card in a Unibus 11/44 or 11/84
chassis and effectively emulated RJE. This may have been the Teradata
"IFP", but it could also have been some other third-party bolt-on not
directly sold by Teradata related to other RJE stuff in the shop.

If I had to guess based on my experience: at least half of all 11/44's and
11/84's sold were equipped with bisync cards and used in a variety RJE
front-ends.

Tim N3QE



On Fri, Jul 10, 2020 at 11:56 AM Tom Perrine  wrote:

> Way back in the mid/late 80s we had a machine from ATT/Teradata which was
> a DB appliance.  It was a standalone rack about the size of an RA81, IIRC.
> It claimed to have "single board PDP-11, a PDP-11/84" as the CPU.
>
> I had never heard of it before or since.  Was that a typo? Hype? Flat out
> wrong? Some sort of OEM thing?
>
> Thanks!
>
> ___
> 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] SIMH mailing list transitioning to Groups.io in coming week

[Tim Shoppa]

A note from your SIMH mailing list administrator:

I announced in 2018 that the SIMH mailing list would be moving from its
home since 2003 as a mailman-based list to a groups.io list.

It is finally happening. In the next week I will do a bulk-sign up using
your currently-subscribed Email addresses, and you will receive a
subscription notification from groups.io. Please be on the lookout for a
subscription E-mail.

If all goes to plan, the old mailing list will be shut down in the next
week.

Archives 2003-2020 of the mailman-based list will remain available on the
web at http://mailman.trailing-edge.com/pipermail/simh/

I will continue to be administrator of the new groups.io list and there is
a possibility that we will be able to migrate the old mailman list archives
there eventually.

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