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

[Armistead, Jason]

Maybe a brief discussion of this topic could be added to the SIMH FAQ.  It 
seems like a key piece of information to help others kick-start their attempts 
to run VMS/OpenVMS under SIMH.

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Brian
Sent: Monday, 17 December 2018 11:52 PM
To: SIMH@trailing-edge.com
Subject: [External] Re: [Simh] Transferring the licence file to the VAX 
emulator - THE FIX

On 12/17/18 8:28 AM, Brian wrote:

OK, thanks to all who helped. As I found from a website to which I was
directed, and as Mark also said, the solution was to copy the file off
the CD-ROM and then

SET FILE/ATTRIBUTE=(RFM=STM) VMSLICENCES.COM

Then run the commands again, and it all worked perfectly.

I guess I've forgotten a lot more about VMS than I thought in 30-odd
years. :( This could be an interesting (re-)learning curve...

Brian.

> Hi all,
> 
> Please bear with me for what I'm sure is a beginner question, but it
> has me beat. :(
> 
> I've set up SIMH, built it all, got my kits for OpenVMS and have
> installed the system. So far, so good.
> 
> The problem I'm having is in getting the licence file I received under
> the Hobbyist scheme onto the VAX. I had thought that 'burning' it into
> an ISO on my Linux box and then mounting that image would work. It
> does, but not completely.
> 
> According to the e-mail, the licence file is in the form of a VMS
> command file. On my Linux box, this looks just fine. However,
> irrespective of whether I use Linux or Windows line endings, when I
> transfer the file onto the VAX as above, all the lines run together
> and the file format is trashed. If I edit the file on the VAX, I can
> see the LF or CR/LF characters in the editor, just as they should be.
> 
> Maybe I've forgotten more about the VAX than I think. WHAT does it
> expect to see as a line terminator? If I know, then I can fix the file
> on my Linux box and transfer it over again, but if neither Linux nor
> Windows line endings work, I've no idea what I need to try. Or am I
> missing something, and there's some fundamental flaw with the whole
> idea of transferring text files via an ISO image?
> 
> I really don't want to have to enter all the licence data
> interactively, or fix a couple of thousand line endings in the editor!
> There must be SOME way of getting the file onto a new setup?
> 
> Thanks for any assistance,
> 
> Brian.
> 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] SIMH mailing list will be migrating to groups.io in next month

[Armistead, Jason]

Many thanks Tim for your selfless years of dedication to SIMH.  We appreciate 
your efforts and are equally frustrated by the impact “bad actors” have had on 
the Internet and all who use it.

PS: Maybe once the migration to groups.io is done, there is an opportunity to 
donate a copy of the mailing list archives to BitSavers or some other computer 
history project just so that there’s a permanent backup “for posterity”.  It 
would be a shame to lose the collective wisdom of this list over such a long 
period. I am constantly impressed by everything that people have contributed to 
the SIMH community, especially the detailed discussions of all sort of 
technical nuances and stories of the people, life and times at DEC and other 
companies/organizations during those early foundational years of computing 
history.


From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Tim Shoppa
Sent: Wednesday, 3 October 2018 3:49 PM
To: SIMH
Subject: [External] [Simh] SIMH mailing list will be migrating to groups.io in 
next month

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] swtp6800-swk.zip

[Armistead, Jason]

Bill

Have you ever given any thought to emulating the Intel iPDS system running 
ISIS-II ?

They were the white and black portable little brother of the MDS family.  We 
had one once, which we called Big Blue because of its sheer physical size.  
Those MDS 8" floppies were really something.  Going to 5 1/4 inch on the iPDS 
was so much nicer, but man, could those iPDS disk drives make some noise when 
the disk had an error and it did a track 0 recalibration of the heads.  You 
*KNEW* that you had a bad disk !!!  Fun times ...

Jason

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Bill Beech 
(NJ7P)
Sent: Tuesday, 6 March 2018 3:37 PM
To: mikestra...@gmail.com; simh@trailing-edge.com
Subject: Re: [Simh] swtp6800-swk.zip

All,

I corrected the SWTP-6800 simulator so it will now boot correctly.  The problem 
with the 'E' command will take more time. I am currently in the middle of 
rewriting the Intel Microprocessor Development Systems (MDS-i and II) 
simulators.

Bill


On 2/22/2018 3:06 AM, Mike Stramba wrote:
> Bill,
>
> I downloaded your www.nj7p.org/Computers/work/run-work_v00d.7z
>
> Going by the name of your file :
> run_MinGW_SWTP-6800mp-a.bat
>
> ..does that mean you are running MingGW ?
>
> I have two machines, one with Win7, the other Ubuntu 14.04 LTS.
>
> On both OS's, after starting the sim, then attempting "D" (boot), I get :
>
> fdccmd: File error
> fdccmd: File error
>
> PC=6000 SP=A042 IX=2400 A=05 B=40 CCR=D2 Invalid Opcode, PC: 6000
>
> This is with both
> SWTP 6800, V2, MP-A2 CPU Board simulator V4.0-0 Betagit commit
> id: 202e49cf
> SWTP 6800, V2, MP-A2 CPU Board simulator V4.0-0 Betagit commit
> id: c4e55d0f
>
> Mike
>
> On 2/21/18, Bill Beech (NJ7P)  wrote:
>> Mike,
>>
>> This is an old build of the simulator and an even older version of 
>> the run-time package.  The current support package is on my web site at:
>>
>> www.nj7p.org/Computers/work/run-work_v00d.7z
>>
>> The current version of SIMH is on the GitHub site.
>>
>> This version logs on as follows:
>>
>> D:\Development\0GitHub\run\swtp6800>call
>> ..\..\simh-nj7p\BIN\swtp6800mp-a swtp6800mp-a.ini
>>
>> SWTP 6800, V2, MP-A CPU Board simulator V4.0-0 Beta git commit id: 
>> 202e49cf
>>
>> $
>>
>> The error with the SIMH "E" command still occurs with this version.  
>> I will look into it when I review the simulators in the next week or so.
>>
>> Thanks!
>>
>> Bill
>> On 2/19/2018 4:56 AM, Mike Stramba wrote:
>>> I'm trying to run 
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__simh.trailing-2D
>>> edge.com_kits_swtp6800-2Dswk.zip=DwIGaQ=ilBQI1lupc9Y65XwNblLtw
>>> =CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4=i482CoHQsLAGJrFB3hPvl
>>> mzqewjQFE5faffbdhhHmmE=5eTOTsaA1SSyKbwDOI6PLAMMqrOE9o55BPyV6G4R_8E
>>> =
>>>
 swtp6800mp-a2.exe swtp6800mp-a2.ini
>>> SWTP 6800, V2, MP-A2 CPU Board simulator V3.9-0
>>>
>>> PC=E1AB SP= IX= A=07 B=00 CCR=D0 Invalid Opcode, PC: E1AB
>>>
>>> And .. (never have seen this in any other SIMH emulator)  :
>>> sim> e e1ab
>>> Unit not attached
>>> sim> e -m e1ab
>>> Unit not attached
>>> sim>
>>>
>>>
>>> --- -swtp6800mp-a2.ini  ---
>>>
>>> set bootrom 2708
>>> attach bootrom swtbug.bin
>>> set mp-a2 mon, lo_prom
>>> set cpu hex
>>> set cpu itrap
>>> set cpu mtrap
>>> reset
>>> set mp-b2 bd0, bd1, bd2, bd3, bd4, bd5 att dc-40 6800boot.img att 
>>> dc-41 6800work1.img set dc-41 rw att dc-42 6800work2.img set dc-42 
>>> rw att dc-43 6800work3.img set dc-43 rw g 
>>> ___
>>> Simh mailing list
>>> Simh@trailing-edge.com
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.trailing
>>> -2Dedge.com_mailman_listinfo_simh=DwIGaQ=ilBQI1lupc9Y65XwNblLtw&
>>> r=CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4=i482CoHQsLAGJrFB3hPv
>>> lmzqewjQFE5faffbdhhHmmE=1s1Q5qh99202HVhSLwD9jL4QGaTZc7ZOdx3U6MOFCI
>>> M=
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.trailing-
>> 2Dedge.com_mailman_listinfo_simh=DwIGaQ=ilBQI1lupc9Y65XwNblLtw=
>> CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4=i482CoHQsLAGJrFB3hPvlmz
>> qewjQFE5faffbdhhHmmE=1s1Q5qh99202HVhSLwD9jL4QGaTZc7ZOdx3U6MOFCIM=

___
Simh mailing list
Simh@trailing-edge.com
https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.trailing-2Dedge.com_mailman_listinfo_simh=DwIGaQ=ilBQI1lupc9Y65XwNblLtw=CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4=i482CoHQsLAGJrFB3hPvlmzqewjQFE5faffbdhhHmmE=1s1Q5qh99202HVhSLwD9jL4QGaTZc7ZOdx3U6MOFCIM=
___
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?

[Armistead, Jason]

Dan

What exact version of Pascal compiler are you using ?  (presumably you are 
using OpenVMS 7.3 on a VAX  as the operating system)

What is the exact message the complier gives concerning the writeln() function?

Can you generate a simple “proof of concept” and share what you are doing ?

Looking at the HP Pascal for OpenVMS Language Reference Manual (for V5.8/V5.9) 
it is supported

http://h30266.www3.hpe.com/odl/i64lp/progtool/pasi6461/pasi64rm.pdf

It’s hard to “suspect” that types and records are also non-existent, along with 
writeln().  They’re part of what makes Pascal, well …, Pascal !


Jason


From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Dan Gahlinger
Sent: Wednesday, 7 February 2018 6:22 PM
To: simh@trailing-edge.com
Subject: [External] [Simh] anyone know how to convert/translate turbo pascal to 
vax pascal?

since I did all that work recreating "castle" from the vax to the pc
using turbo pascal (then free pascal)
I'd like to "port" it back to the vax,
but the vms 7.3 pascal compiler doesn't recognize "writeln"
and I suspect things like types and records and case statements wont work 
either.

anyone have any ideas?

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

Re: [Simh] Terminal Emulator

[Armistead, Jason]

Another good terminal emulator was WRQ's Reflection 2.  Of course, it was not 
freeware/shareware, but it ran well, and had its own file transfer protocol 
built in.  For VAX/VMS hosts, once you uploaded a minimalist bootstrap program 
(a simple copy-paste operation of a DCL script that embedded some VAX MACRO 
code that it assembled IIRC), it then copied an actual VAX EXE that could do 
the heavy lifting of file upload/download long-term. Worked very well and we 
were loyal Reflection users all the way through from DOS 3.x in the late 1980s 
through to the days of Windows 2000 (circa Reflection V7.x for Windows IIRC).  
Nowadays the Reflection suite is owned by MicroFocus.

Fun times ...

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Richard
Sent: Friday, 26 January 2018 1:15 AM
To: SIMH
Subject: Re: [Simh] Terminal Emulator

I used PROCOMM on an 8088; I never used telix.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Armistead, Jason]

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 ” 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.

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Clem Cole
Sent: Thursday, 25 January 2018 6:44 PM
To: Mark Pizzolato
Cc: SIMH; Larry Baker
Subject: [External] Re: [Simh] VAX Tape Emulation?



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?

[Armistead, Jason]

Zane

The program that Johnny is thinking of is VMSPTC

http://www.digiater.nl/openvms/decus/vax86a/bnelson/vmstpc/vmstpc.c

Note sure if this is the latest, but it came up in the first set of Google 
search results for "VMSTPC"

Good luck
Jason


-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny Billquist
Sent: Thursday, 25 January 2018 5:48 PM
To: Zane Healy; Tim Shoppa
Cc: simh@trailing-edge.com
Subject: Re: [Simh] VAX Tape Emulation?

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 > > 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 > > 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 
>>> 
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.trailing-2Dedge.com_mailman_listinfo_simh=DwIGaQ=ilBQI1lupc9Y65XwNblLtw=CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4=Tuv134HGgnWc1vxno4wpeUgonHLScwAzyLK3tGM--Wo=KG58MZsCGTQPkaifTTlluf-_bo-FOhuQ7JJUEBB3Hvk=
>>>  
>>> 
>>> >> g-2Dedge.com_mailman_listinfo_simh=DwIGaQ=ilBQI1lupc9Y65XwNblLtw
>>> =CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4=Tuv134HGgnWc1vxno4w
>>> peUgonHLScwAzyLK3tGM--Wo=KG58MZsCGTQPkaifTTlluf-_bo-FOhuQ7JJUEBB3H
>>> vk= >


-- 
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
https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.trailing-2Dedge.com_mailman_listinfo_simh=DwIGaQ=ilBQI1lupc9Y65XwNblLtw=CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4=Tuv134HGgnWc1vxno4wpeUgonHLScwAzyLK3tGM--Wo=KG58MZsCGTQPkaifTTlluf-_bo-FOhuQ7JJUEBB3Hvk=
 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simulator development: Advice on system timing

[Armistead, Jason]

If you need accurate device timing, then perhaps something like the core of 
MAME/MESS is a better choice than SIMH.  All those retro arcade machine games 
in MAME depend on counting cycles in order to give realistic game behavior for 
the human who is playing them.  If they ran twice as fast, they'd be unplayable 
(or at least, very challenging), so everything is carefully handled to ensure 
it runs smoothly at a realistic rate.

Maybe not the answer you're looking for, but it is one alternative.

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Paul Koning
Sent: Thursday, 26 October 2017 2:16 PM
To: Seth Morabito
Cc: simh@trailing-edge.com
Subject: Re: [Simh] Simulator development: Advice on system timing


> On Oct 26, 2017, at 1:55 PM, Seth Morabito  wrote:
> 
> Hello all, and especially those who have written or are writing 
> simulators,
> 
> I'm battling system timing in the 3B2/400 emulator I'm working on. As 
> with any system, particular activities such as disk seeks, reads, and 
> writes must be completed within certain margins -- if they happen too 
> early or too late, an interrupt will be missed. But the "fudge 
> factor", so to speak, seems pretty tight on the 3B2, possibly because 
> it runs at a system clock frequency of 10MHz.

In most systems, odd things can happen if interrupts happen too soon.  If an 
I/O completes essentially instantaneously, then software that relies on being 
able to start I/O, then do some more stuff, and count on that completing before 
the interrupt -- even though interrupts are enabled -- will break.

The correct description for such software is "defective" though there certainly 
is quite a lot of it in the wild.

For this reason, simulators need to delay interrupts by some number of 
instruction times, and SIMH makes that easy.  But it doesn't normally matter 
that the timing is not exact, all that's needed in most cases that the 
interrupt is held off long enough to work around the sort of poorly written 
code I mentioned.  So if you base your delays on average instruction times and 
average I/O latency, you'll normally be fine.  In the 3B2 case, with 10 MHz 
clock and an average of 8 cycles per instruction, that's 1.25 MIPS.  A disk I/O 
might take 20 ms (1/2 rotation at 3600 RPM), so that would be 25,000 
instruction times.  Quite likely you could crank that number way down and have 
the code still run.

If you want to have realistic timing, that's a different matter.  You'd find 
yourself tracking the cylinder position and charging for seek timing.  The 
DECtape emulation does that, and it matters because some operating systems 
(TOPS-10, VMS) do tape position prediction based on elapsed time.  But that's 
an unusual case.

paul


___
Simh mailing list
Simh@trailing-edge.com
https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.trailing-2Dedge.com_mailman_listinfo_simh=DwIGaQ=ilBQI1lupc9Y65XwNblLtw=CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4=28teaDEfpeRsG91nozxabV4mdFUU29mk-Z8uKnyQzU8=eipMJsFHOejQwt_QvM2i4SQzThEadhwDwVzO6zm-M7s=
 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Problem with MT_ASTLVL on the VAX-11/780

[Armistead, Jason]

Johnny Billquist wrote:

>However, this might be different on different CPU models, so I suspect this 
>should be applied with care.
>He was testing VAX/VMS V4.5, which is pretty ancient. The models supported by 
>that version would probably only be the VAX-11 models. (And yes, I include the 
>86x0 in the VAX-11 series.)

MicroVMS 4.5B was available for MicroVAX 2000 circa 1987.  I remember loading 
it from a large stack of between 50 and 70 RX33 (?) floppies ...  what fun !

I believe that the first "Micro" versions of VMS started with MicroVMS 4.4 when 
the MicroVAX family was added.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DEC VT emulators on MAME

[Armistead, Jason]

Malcolm

After looking at the photos you took of the ROM cartridge internals I think you 
might be better leaving them in-place and making up an adapter from the edge 
connector to a 28 pin socket that you could plug into an EPROM programmer.  By 
the looks of it, there's no chip selection/data buffering logic on the PCB, and 
it's just the EPROMs and some decoupling capacitors.  If you activate the 
appropriate chip select and output enable lines of the EPROMS one at a time, 
you can make sure just a single chip is talking to the EPROM programmer and the 
rest would be dormant.  The pinouts of the 27C256 chips should be readily 
available.

Good luck !

Jason

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of 
malc...@avitech.com.au
Sent: Tuesday, 18 April 2017 9:25 AM
To: simh@trailing-edge.com
Subject: Re: [Simh] DEC VT emulators on MAME

Just a quick update: I've broken open the VT340 ROM cartridge.  Inside are 5 x 
surface-mount N27C256 ROMs.

Some pictures of the ROM cartridge are now included on this page -> 
http://avitech.com.au/?p=1818

Is there anyone who has the tools, time and interest to remove these ROMs and 
dump the contents?  If so, please let me know and I will pay the cost of 
shipping to get this cartridge to you.

Malcolm.

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

Re: [Simh] DEC VT emulators on MAME

[Armistead, Jason]

Tim

Malcolm had previously indicated that E80 was a Xicor X2804AP-45 chip.  That 
would make it a 512 byte (4096 bit arranged as 512 * 8)  EEPROM, rather than an 
NVRAM, with an access time of 450ns.

Link to datasheet 
http://pdf1.alldatasheet.com/datasheet-pdf/view/103364/XICOR/X2804A.html

This chip should be easily readable by almost any PROM/EPROM/EEPROM programmer, 
but if it's only got settings as you suspect, then hopefully the firmware would 
be able to identify a blank device and just set up defaults.

Jason

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Tim Stark
Sent: Sunday, 16 April 2017 1:24 AM
To: malc...@avitech.com.au; 'Cory Smelosky'
Cc: simh@trailing-edge.com
Subject: Re: [Simh] DEC VT emulators on MAME

Malcolm,

Ok, thanks for let us know.  I now found video docs for VT340 (dragon system - 
vipers and adders).  Each chip hold one bitmap plane individually. VCB02 
graphics card uses the same chips. 

I misread schematics.I believe that E80 is NVRAM chip for just settings - 
512 x 8,  not 512K x 8.  Firmware is in ROM cartridge.  

E49 dump should be labelled as 236E6.bin for CG rom. 

Does anyone have a copy of CRT 9007 video controller docs for VT220 terminal?

Thanks,
Tim

-Original Message-
From: malc...@avitech.com.au [mailto:malc...@avitech.com.au] 
Sent: Saturday, April 15, 2017 9:43 PM
To: 'Tim Stark' ; 'Cory Smelosky' 
Cc: simh@trailing-edge.com
Subject: RE: [Simh] DEC VT emulators on MAME

I've now pulled apart a spare non-working VT340, for the ROM dumps. This 
terminal has a faulty power supply and very significant screen burn, so I 
wasn't planning on repairing it anyway.

On my board, E80 is a XICOR X2804AP-45 which is soldered in place. So I haven't 
removed it or dumped its contents.

E49 is a 27256 EPROM.  I have dumped the content of that ROM and it is now 
available here -> 
https://urldefense.proofpoint.com/v2/url?u=http-3A__avitech.com.au_-3Fp-3D1818=DwIGaQ=ilBQI1lupc9Y65XwNblLtw=CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4=YpwywTuCsVKkSvuZSul6C6BTase_SV-J2yCTQkZVeBQ=WAvNJXtV69LsjK_LBZBMcmtmo-gwnd1OPsJy0_seTI0=
  

That page also has pictures of the VT340 internals.

Tim - I will write to you separately to arrange sending the VT340 logic board 
to you.

Malcolm.

___
Simh mailing list
Simh@trailing-edge.com
https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.trailing-2Dedge.com_mailman_listinfo_simh=DwIGaQ=ilBQI1lupc9Y65XwNblLtw=CeQuuq99aEH_1RE1yGnGXY4AbMg6_1cjkYeJjaT-sd4=YpwywTuCsVKkSvuZSul6C6BTase_SV-J2yCTQkZVeBQ=bvqLN4m2owRHsY-V572p8fso74T-IQHWY8L1K59aCWk=
 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VT240, VT340 and DS200/300 HW specs info

[Armistead, Jason]

A DS200 fits in a standard 19 inch rack.

Refer to page E-2 of the DS200 hardware installation guide for precise 
dimensions and weight:

http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/ethernet/decserver_200/EK-D200C-IN-001_DECserver_200_Hardware_Installation_Oct86.pdf


From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of khandy21yo
Sent: Tuesday, 11 April 2017 11:02 AM
To: Gregg Levine; Brian Wheeler
Cc: Simh
Subject: Re: [Simh] VT240, VT340 and DS200/300 HW specs info

DS200 is about the size of an IBM PC-XT. Not as heavy though.
Lousy fans on most of them. They always gave me problems.



Sent from my Galaxy Tab® A

 Original message 
From: Gregg Levine >
Date: 4/11/17 8:02 AM (GMT-07:00)
To: Brian Wheeler >
Cc: Simh >
Subject: Re: [Simh] VT240, VT340 and DS200/300 HW specs info

Hello!
It's okay. How big is it?
-
Gregg C Levine gregg.drw...@gmail.com
"This signature fought the Time Wars, time and again."


On Tue, Apr 11, 2017 at 9:51 AM, Brian Wheeler 
> wrote:
> All of this talk reminds me -- I've got a DS200 in my basement that I don't
> need any more.  Does anybody want it?  Free for shipping from 47408.
>
>
> Apologies for the off-topic-ness since this is real hardware :)
>
> Brian
>
>
> On 04/11/2017 09:18 AM, Patrick Finnegan wrote:
>
> On Mon, Apr 10, 2017 at 6:25 PM, Richard 
> > wrote:
>
> In article 
> <01d2b0ef$c2cd4330$4867c990$@verizon.net>,
> "Tim Stark" > writes:
>
> DS200 uses 68000 processor with AM7990 (LANCE) and 4 2681 DUARTs.
>
> DS300 uses 68020 processor with TC23SC241AP and 8 2681 DUARTs.
>
> DS500 uses KDJ11-SD processor (11/53) with CXA16/CXB16 devices.
>
> What are these?
>
> DECserver, aka a terminal/console server. Older ones are LAT only,
> newer ones do Telnet as well.
>
> Pat
> ___
> 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

[Simh] Now trending on Google News: stories about the humble floppy disk !

[Armistead, Jason .]

Interesting to see stories like these appearing on Google News today:

"US nuclear force still uses floppy disks"

http://www.bbc.com/news/world-us-canada-36385839

"The long legacy of the floppy disk"

http://www.bbc.com/news/technology-36389711

Long live the floppy disk, retrocomputing, and SimH, but I think the US nuclear 
arsenal is probably due for an upgrade !

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

[Simh] Thoughts on combining individual scanned pages

[Armistead, Jason .]

One tool that I have found useful in the past is tiffcp, which is part of the 
tools in the libTIFF distribution.

http://www.remotesensing.org/libtiff/tools.html

tiffcp makes it easy to combine multiple TIFF images into a single TIFF file.

tiff2pdf makes it easy to convert that multi-page TIFF fine into PDF.

Hope this helps when archiving documentation from these old systems


Jason



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

Re: [Simh] Way out idea for simh

[Armistead, Jason .]

OK, so maybe my example was a bit more high-level than what folks are 
discussing, but even for a "bunch of bits/bytes" device, synchronization still 
has to be considered here (just as it would for access to common data when 
writing a multi-threaded program).

As long as the guest OS has exclusive access to the device (preventing the host 
OS doing reads or writes) , or the host OS has exclusive access to the 
underlying host file representation (preventing the guest OS from doing reads 
or writes), then things are OK.  The minute that both try to access it, with 
one reading and the other writing, it all falls apart because there are lots of 
ways to corrupt the data stream mid-way through either operation.

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Ken Cornetet
Sent: Wednesday, 20 April 2016 1:43 PM
To: simh@trailing-edge.com
Subject: [External] Re: [Simh] Way out idea for simh

The guest OS wouldn't care, because the guest OS wouldn't see it - there isn't 
a guest OS file system on the disk. The *only* thing reading or writing the 
bits in the guest world is the custom utility program.

For all I know, there may be some guest OSes that insist on having a native 
file system on a disk device. RTE and unix (the only two simh OSes I am 
familiar with) are perfectly happy to have a disk with no file system and let 
you access it as a collection of blocks. 

If an OS insists on a native file system on the disk, then this scheme wouldn't 
work.

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Armistead, 
Jason .
Sent: Wednesday, April 20, 2016 1:31 PM
To: simh@trailing-edge.com
Subject: Re: [Simh] Way out idea for simh

One thing that I don't think has been mentioned is that the guest OS being run 
under SIMH might not take kindly to data changing on these new devices that are 
being proposed.

I would expect the guest OS doesn't expect things to "magically happen", 
because it (quite rightly) believes it is the only thing that is capable of 
doing that.  So any sort of data from the device that is cached by the guest OS 
(maybe directory entries, block allocation data, or parts of a file that was 
recently read) would suddenly risk becoming invalid.  That's a sure-fire recipe 
for chaos.

On something like a SCSI-clustered VMS system, while there were multiple hosts 
attached to a common SCSI bus, there was also cluster communication taking 
place another communication channel like Ethernet to ensure that all nodes had 
a consistent view of what was going on with each SCSI disk.

Dual porting is a tricky thing, but doing it without properly notification 
mechanisms or processes to ensure on-device and in-memory consistency is asking 
for trouble !  Having the guest OS shut down, then making changes to the 
contents of the new device, and then restarting the guest OS via a reboot with 
no further changes from an external source would be one way of doing this in a 
purely process-driven fashion.  This is essentially what SIMH does when 
attaching devices prior to starting the guest OS.

___
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] Way out idea for simh

[Armistead, Jason .]

One thing that I don't think has been mentioned is that the guest OS being run 
under SIMH might not take kindly to data changing on these new devices that are 
being proposed.

I would expect the guest OS doesn't expect things to "magically happen", 
because it (quite rightly) believes it is the only thing that is capable of 
doing that.  So any sort of data from the device that is cached by the guest OS 
(maybe directory entries, block allocation data, or parts of a file that was 
recently read) would suddenly risk becoming invalid.  That's a sure-fire recipe 
for chaos.

On something like a SCSI-clustered VMS system, while there were multiple hosts 
attached to a common SCSI bus, there was also cluster communication taking 
place another communication channel like Ethernet to ensure that all nodes had 
a consistent view of what was going on with each SCSI disk.

Dual porting is a tricky thing, but doing it without properly notification 
mechanisms or processes to ensure on-device and in-memory consistency is asking 
for trouble !  Having the guest OS shut down, then making changes to the 
contents of the new device, and then restarting the guest OS via a reboot with 
no further changes from an external source would be one way of doing this in a 
purely process-driven fashion.  This is essentially what SIMH does when 
attaching devices prior to starting the guest OS.

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

[Simh] Pop culture references to DEC and VAX

[Armistead, Jason .]

And now for a bit of a diversion after an otherwise fairly quiet week on the 
SIMH mailing list ...

Last week I was watching a DVR-ed recording of Arrow on the CW network 
(http://www.cwtv.com/shows/arrow ). The particular episode was "Beacon of 
Hope".  Just a few minutes in, as the last of the opening credits are 
finishing, one the main characters, Felicity Smoak, is working on a hard 
problem when her tech-geek offsider Curtis makes a reference to Digital 
Equipment Corporation and them spending $700K on the first VAX.  I had to hit 
rewind to make sure I heard that correctly.

Obviously someone who writes for the show is fond of old computer systems from 
the good-old days when DEC rule the minicomputer space, or they did a little 
bit of Googling and perhaps just plucked the $700K figure out of thin air !



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

Re: [Simh] Cross Compilers (and memories thereof)

[Armistead, Jason BIS]

Let's move this to a new thread subject of its own !

On Tuesday, 23 February 2016 12:04 PM, Davis Johnson  wrote 
(under old subject Re: [Simh] Interdata OS/32: hello-world in CAL32) :

> One that I remember was TI had a 9900 cross assembler written in FORTRAN (all 
> caps in those days). It was free to educational institutions.
> I talked a prof. into requesting it, but the available FORTRAN compiler 
> didn't like it.

Another now-defunct company, Microtec Research Incorporated (purchased by 
Mentor Graphics in late 1995), definitely had a TI9900 cross assembler written 
in FORTRAN from 1983.  We had the source code under license and compiled it 
under VAX/VMS (complete with CLI switches), and with a few custom tweaks, it 
was largely compatible with SDSMAC that ran on TI's 990 computer systems (now 
simulated via Dave Pitts' SIM990).  There was also a linker/loader that 
produced Tektronix HEX output (similar to TI's SDSLNK) as the final executable. 
 I was able to modify the code enough to get it to compile under OpenWatcom's 
Fortran 77 on Windows XP.





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

Re: [Simh] Interdata OS/32: hello-world in CAL32

[Armistead, Jason BIS]

On Feb 23, 2016, an anonymous user (li...@openmailbox.org) wrote:

> Thanks very much for the additional info. Your post was very timely since I 
> read in the notes that come with the PL/M cross compiler
> that is being discussed that it was a cross-compiler hosted on MTS and VM/CMS.

> I don't think I ever came across a cross compiler in the old days. It is 
> interesting to see that people used these odd combinations.

> I wonder if we should start trying to archive and document cross compilers 
> specifically.

> On Tue, 23 Feb 2016 01:01:28 -0500
> johns...@gregjohnson.org wrote:

> [very nice story snipped]

Cross compilers were great when your target system didn't have enough memory, 
storage, and possibly no actual operating system to support a locally-hosted 
compiler.  For a language like PL/M-86 which had no language specific I/O 
constructs beyond reading to and writing from I/O ports on the target CPU, it 
was perfect for writing applications for an OS-less embedded systems, but it 
needed a host.  Hosting on a VAX under VMS might be viewed as a little extreme 
when the target had less than 64K of EPROM and a few K of RAM, but it worked.  
The only complaint I had is that Intel limited the symbol table sizes somewhere 
in the linker (IIRC !), and you could exceed the maximum number of external 
symbols, thus requiring some splitting of modules and multi-step linking to 
resolve this dilemma.  I suspect the origins of this limitation was the MS-DOS 
environment with 640K of memory (Intel's tools didn't use a DOS extender), and 
that whoever ported the toolset to VAX/VMS never increased this limitation, 
even though VAX/VMS could support a lot more than virtual memory than DOS.

Assemblers were a little bit easier to host on a target - smaller code size in 
your editor, no optimization required, etc., though plenty of cross assemblers 
certainly existed for a wide range of targets, especially those that were 
embedded like Intel 8048 & 8051, Motorola 680x, etc.

A lot of the "classic" embedded cross compiler/cross assembler companies are no 
longer in existence, either gobbled up by larger companies, or simply going the 
way of the Dodo bird.  Names like Franklin, 2500AD, Avocet System, Adtek (from 
Japan) and Hi-Tech (from Queensland Australia), were pretty common players, but 
these days their products are no longer available, or if you're lucky they are 
end-of-life and provided as-is with no support, even if you buy them.  Intel 
created their own systems, like the Intel's iPDS-100 running ISIS-II, or 
Motorola/Freescale (now NXP) got 3rd party vendors like P Micro to do some of 
their tools and development boards.  It was a wild time !!!

PS: I'd love to see an iPDS-100 emulation in SIMH one day !!!


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

Re: [Simh] Intel's PL/M-86, ASM86 and iAPX-86 Utilities source code

[Armistead, Jason BIS]

The PL/M compiler for CP/M was for 8080/8085/Z80 target, i.e. PL/M-80.

Intel did a lot of work to adapt PL/M for iAPX-86 processors 
(8086/8088/80186/80188 variants) and added support for the segmented memory 
architecture amongst other changes.  The last DOS version I had was V3.4 from 
1987.  There was a UDI shim that mapped Intel's own style of I/O calls to the 
underlying DOS equivalents.

On the VAX/VMS side, we also had Intel's PL/M-86 V3.4 from circa 1989 - that's 
when we got the MicroVAX 2000 that it was hosted on.  I learned to love loading 
MicroVMS 4.5B from a set of 50-ish floppy disks onto the RD54 system disk, and 
then installing the Intel tools from TK50 tapes.

When we switched from VAX to Alphas running OpenVMS 6.2-1H3 in the late 1990s, 
we simply DECmigrated the Intel tools and the translated EXEs ran perfectly 
fine.  Thanks to DEC for solving that problem for us !


On Mon, Feb 22, 2016, Kevin Handy khandy2...@gmail.com wrote:

> A deeper look at the site "http://www.cpm.z80.de/; shows other PL/M sources, 
> such as a "VAX PL/M", ans a PL/M to C translator.

> The "Unofficial CP/M web site" has a PL/M compiler. I don't know if it's 
> close to anything you're looking for.  it'S  listed with the following 
> description
> Here is the source to the Intel PLM compiler. It is written in Fortran (66), 
> and is supposed to be pretty clean.
> It compiles correctly with gcc's g77 on Linux. However, it is not the version 
> required to compile CP/M 2.2 or 3.0. It works well, but lacks support for 
> external definitions and some PLM constructs, as required by the DR source. 

On Mon, Feb 22, 2016 at 9:04 AM, Clem Cole <cl...@ccc.com> wrote:
below

On Mon, Feb 22, 2016 at 10:31 AM, Armistead, Jason BIS 
<jason.armist...@otis.com> wrote:
Sorry for this off-topic posting, but with all the recent talk about Intel’s 
history of x86 development, I was wondering whether there are any “Intel 
connected” people around here who might know what happened to the source code 
for Intel’s PL/M-86, ASM86 and iAPX-86 Utilities (LINK86, LOC86, LIB86, CREF86 
and OH86).  The manuals for many of these are on Bitsavers.
​I've wondered the same.​


 
 
 
PL/M-86 was never (to my knowledge)
​I thought Seattle Computer ​products used it to write some of DOS-86, which 
they later sold to Gates (which became DOS).  


 

 
We also used PL/M-80 under ISIS-II on Intel’s iPDS and MDS-80 development 
workstations, PL/M-80 under iSIM85 ISIS-II emulator on DOS/Windows 16/32-bit, 
as well as PL/M-51 under DOS/Windows 16/32-bit.  There were also PL/M-286 and 
PL/M-386 varieties, and possibly PL/M-48 (?) though I never personally used 
them.
I believe that all of the Intel tools were in FTN in those days - the 
assembler, tools and PL/x.
I once had some of them I looked a while ago, but I have long lost track of the 
sources.​


___
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] Intel's PL/M-86, ASM86 and iAPX-86 Utilities source code

[Armistead, Jason BIS]

Sorry for this off-topic posting, but with all the recent talk about Intel's 
history of x86 development, I was wondering whether there are any "Intel 
connected" people around here who might know what happened to the source code 
for Intel's PL/M-86, ASM86 and iAPX-86 Utilities (LINK86, LOC86, LIB86, CREF86 
and OH86).  The manuals for many of these are on Bitsavers.

I have used both the DOS-hosted and VAX/VMS hosted versions of these tools, but 
when Y2K was approaching I reached out to Intel to see if we could obtain the 
source code under some sort of license (given that these products weren't being 
sold anymore) that would allow us to modify it for Y2K just to tidy up the 
generated compiler listing files, linker map files, etc., which were the only 
real place dates and times were used.  The reply I got from Intel was basically 
stating that this was "lost" and no-one knew what became of it.  And now, with 
the switch to x64, Windows 7.x and later Windows incarnations no longer support 
running the old 16-bit DOS executables in a 64-bit environment, other than 
resorting to virtually hosted DOS using DOSbox, VirtualBox or similar.

PL/M-86 was never (to my knowledge) used to build a widely-used operating 
system in the way its predecessor PL/M-80 was used to build the early CP/M 1.x 
and 2.0, so it never quite got as much attention as  "piece of computing 
history".

We also used PL/M-80 under ISIS-II on Intel's iPDS and MDS-80 development 
workstations, PL/M-80 under iSIM85 ISIS-II emulator on DOS/Windows 16/32-bit, 
as well as PL/M-51 under DOS/Windows 16/32-bit.  There were also PL/M-286 and 
PL/M-386 varieties, and possibly PL/M-48 (?) though I never personally used 
them.

Interestingly, I just discovered that there was a PL/M-VAX version (see 
http://www.cpm.z80.de/source.html ) that was written in Fortran and emits VAX 
instructions.  From looking at that source it looks like that was something 
done by National Energy Software Center at the Argonne National Laboratory 
using Intel code from 1981 as a starting point.

I probably should have thought of asking on the SIMH e-mail list years ago !  
Perhaps someone on this list has connections at Intel (or used to work there) 
and maybe this source code really does exist in either the corporate archives 
or in some private or museum collection.

Cheers
Jason A.

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

Re: [Simh] Sounds

[Armistead, Jason BIS]

On Thursday, 11 February 2016 12:23 PM Kevin Handy wrote:

> Nowodays, many people haven't even heard a dot-matrix printer grinding away, 
> let alone the huge mass of fans that seemed to make up most of an 11/70.
> Daisy weel printers are also extremely rare now. Line printers (drum, chain, 
> printronix) seem to be nonexistant any more, but were how most of us thought 
> about computers.

I always thought those band printers were the noisiest contraptions.  Always 
housed in their own sound-proofed box, they let out an awful noise when the lid 
was opened !
 

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

Re: [Simh] SIMH and physical hardware

[Armistead, Jason BIS]

On 2/9/16 11:41 PM, Zachary Kline wrote:
> This is around 50% humorous, but it’s still a thing I’ve been thinking about 
> lately. From a newbie’s perspective, all SIMH machines are very similar. The 
> worst thing about emulation is that the “feel,” of the original hardware 
> doesn’t seem to be there. Simh can emulate tons of hardware from different 
> manufacturers, but none of that will tell me what it was like to actually use 
> the devices in a physical sense.
> As a blind user, I’m doubly interested in this kind of physicality because I 
> experience the world through touch and sound. I have little conception of the 
> shape or size of many of these notional machines, and they are all reduced to 
> various abstractions at a console prompt. It’s hard to imagine a thing I was 
> far too young to experience.
> I was reminded of an Apple II emulator I saw once, sadly not accessible, 
> which made the appropriate disk drive noises in use. Its kind of useless from 
> a  practical standpoint, but a lot of my interest in these machines isn’t 
> practical to begin with. I want to explore an earlier kind of computing, but 
> don’t expect to get a job with it or have anything beyond some entertainment.
> I really don’t know what, if anything, can be done to bridge this weird 
> disconnect. Actual hardware is probably gradually fading out, and in any case 
> probably wouldn’t be accessible from my perspective anyway.
>
> Any thoughts? Apologies for the disjointed post, it’s rather late. ;) 

Others have mentioned the familiar sound of disk drives and other devices.  In 
the world of SIMH, if the emulated system is running at a higher speed than the 
original hardware, the access times of such devices is also reduced (possibly 
quite significantly).  So what might have once been the slow clack-clack sound 
of floppy drive heads being stepped into position or recalibrated back to track 
zero, now becomes a much faster, higher-pitched sound.  Unless the simulated 
I/O device response timing matches that of the original hardware it emulates, 
attempting to play back recordings from physical hardware based on when and how 
SIMH access that device would be impossible to achieve, or be completely 
unsynchronized, or would need to be sped up, resulting in a "Vintage Computing 
meets the Chipmunks" sound !

PS: I always remember the sounds of an RD54 disk buzzing to life during the 
boot sequence of our trusty MicroVAX 2000, and the TK50 tape leader being 
picked up by the drive mechanism when first loaded.

Just my $0.02 worth
Jason
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Pascal 1.3 manual for RSX 11 4.6

[Armistead, Jason BIS]

Al Kossow wrote:

> here is the SPD
>
> http://h18000.www1.hp.com/info/SP1418/SP1418PF.PDF

And the second page of the SPD even mentions "On-line Debugging Technique 
(ODT)" - the topic of one of our other recent SIMH mailing list threads !!!


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

[Simh] The minutiae of hardware/software interactions affecting SIMH

[Armistead, Jason BIS]

On the topic of Configuring DMC11 Devices, while discussing wait delays Mark 
Pizzolato recently wrote:

> Sounds reasonable.  I've got to see if I can find the reason the delay was 
> initially added and make sure a change like this is compatible.

What is the "SIMH strategy" for documenting such requirements ? i.e. where does 
this behavior get called out in the source code (or elsewhere) in a way that 
will allow future generations of SIMH users and maintainers to understand "why 
things are the way they are" or "why things need to be the way they are" ?

There is one reference to the DDCMP protocol manual in the source of 
pdp11_dmc.c, but that's about it.  Should references to other documents be 
added ?

Reconstructing and understanding history is easy when people familiar with the 
subject matter (especially those who lived it, in this case, at DEC) are still 
around to ask, but gets progressively harder as years go by without leaving a 
good trail of "breadcrumbs" for others to follow.

PS: I am constantly amazed at the sheer volume of knowledge and resourcefulness 
that contributors to this list have, which is one of the reasons I'd love to 
see as much of it preserved directly in the SIMH code base !!!


Jason

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

Re: [Simh] terminal multiplexers

[Armistead, Jason BIS]

Patrick Finnegan  wrote:

>DEC's DECserver, Xyplex Maxserver, Annex terminal servers, and Xylogics (for 
>the ones I have touched and remember) all converted telnet into
> real RS/EIA-232 lines. (telnet client -> host serial, or serial terminal -> 
> host telnet server)

The early DECservers like the DECserver 100 & 200 models only spoke LAT 
protocol to host systems, and required a MOP boot file download to get up and 
running.  The early models had a Motorola 68000 CPU inside them, and just 
enough firmware in EPROM to do some basic startup diagnostics and complete the 
MOP boot.  The later DECserver 90M (introduced circa mid 1990s) was one of the 
first to support Telnet in addition to LAT, and had all their firmware on board.

See https://en.wikipedia.org/wiki/DECserver for a bit of an overview of the 
various models and capabilities.

I originally used DECserver 200s running LAT on our VAX/VMS systems, but I 
believe it was also available on PDPs (running RSX ?) and Ultrix / OSF/1 / 
Digital Unix, and nowadays there is even an open source LAT and MOP daemon 
implementation for Linux.

The DECservers 200s were rock solid performers in our engineering offices and 
on the factory floor.



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

Re: [Simh] VMS/VDE: Almost there

[Armistead, Jason BIS]

Rich Alderson wrote:

>DECNET is available under RSX-11M and RSTS/E on PDP-11s, Tops-10 and TOPS-20 
>on PDP-10s, and under VMS (and possibly Ultrix, I don't remember for certain)
>on VAXen, and on VMS follow-on systems.  It is as far as possible agnostic 
>about what kind of system it was running on or connecting to.

Don't forget that DECnet was also available on DOS and Windows PCs via the DEC 
Pathworks, and later, Pathworks 32 product lines.

It was also available on Ultrix for RISC (e.g. DECstations with MIPS CPU) and 
OSF/1 aka Digital Unix for Alpha

DEC at one stage produced a DECimage scanning platform that coupled an 80286 PC 
running DOS + DEC Ethernet card, together with a Fujitsu scanner and Xionics 
interface card (to handle the CCITT G42D compression).  The resultant output 
was either TIFF files or DDIF (Digital Document Interchange Format) files.  
Everything was triggered from the VMS system talking DECnet to the PC.



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

Re: [Simh] Mark's mailbox full

[Armistead, Jason BIS]

I actually find it interesting how much it reveals about the target e-mail and 
account configuration

We know he's running VMS
We know he has a disk called $DISK3:
We know his user space is under $DISK3:[MARK]
And we know we've successfully filled his disk, thus denying some level of 
service and system functionality

In this era of hackers that feed off this sort of exposed data, I doubt any 
modern mail server would be game to post back so much configuration-specific 
information that could be used to aid in a targeted hacking attack.

Cheers
Jason A

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Alan Frisbie
Sent: Friday, 7 August 2015 7:33 PM
To: SIMH@trailing-edge.com
Subject: [Simh] Mark's mailbox full

If anyone know how to get in touch with Mark Pizzolato outside of email, please 
let him know that he has a disk allocation failure:

 This is a report on the delivery status of your message.
 
   Message-ID:  15080716022951_...@slug.flying-disk.com
   Subject: Re: [Simh] Problem with default builds
 
   --Failed delivery to:
   Address: MARK+SIMH
   Status:  error writing !AS
 
 Reporting-MTA: dns;infocomm.com
 Arrival-Date: Fri, 7 Aug 2015 15:25:38 -0700
 
 Final-Recipient: x-local;MARK+SIMH
 Action: failed
 Status: 5.2.0 (Other or undefined mailbox status)
 Diagnostic-Code: x-local;error writing !AS  %MAIL-W-WRITEERR, error 
 writing $DISK3:[MARK.MAIL]MAIL.MAI  -RMS-F-FUL, device full 
 (insufficient space for allocation)
 Last-Attempt-Date: Fri, 7 Aug 2015 15:25:40 -0700

Thanks,
Alan Frisbie
___
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] vector images

[Armistead, Jason BIS]

Surely it is possible to extract files from SETUP.MSI without running the 
installer.  Someone must have the tools to do this (either commercial or 
freeware perhaps ?).

Another alternative is to run a virtual Windows OS image inside something like 
VirtualBox, thus avoiding any problems “destroying” your day-to-day Windows 
host system (if you even have one).  I you didn’t specify what Windows version 
the rimh altairz80 emulator requires, so this may or may not be possible.  
Other alternatives to VirtualBox might be something like the Bochs IA-32 
emulator.

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Kevin Handy
Sent: Thursday, 16 July 2015 8:50 PM
To: Dennis Boone
Cc: simh@trailing-edge.com
Subject: Re: [Simh] vector images

Yes, they are there, in a file called setup.msi, and nowhere else.
So, as long as you ahve a windows machine that you don;t care if it installs 
older file on top of newer ones,  I had to re-install too many windows systems 
because of this, and finding all of the right install pckges, and figuring out 
the proprt order to reinstall them to get a working system was always a pain. 
msi is the old install format that comonly had this problem.
However, I think I have come up with a painful, roundabout way to extract the 
files, maybe. If not, I was just curious about its memory mapped video, ans if 
the flexwriter emulation was useful enough to bother with. If this doesn't 
work, I'll just have to give up on it.

On Thu, Jul 16, 2015 at 8:44 PM, Dennis Boone 
d...@msu.edumailto:d...@msu.edu wrote:
  Many companies builf computers that  used this operating system, like
  the altair, imsai, osborne, kaypro, and vector graPhics to name a
  few.  Many years later, the rimh altairz80 emulator was written with
  the abiliry ro emulate the vector graphic machines, but the only copy
  of the necessary config and disk images was wrapped up in a miceosoft
  install file called setup.msi.

1. Vector Graphic, no s.

2. Most of the stuff in the altairz80 kits is probably available from
vector-archive.orghttp://vector-archive.org.

De

___
Simh mailing list
Simh@trailing-edge.commailto: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 floppy disk interleave questions

[Armistead, Jason BIS]

Dying RFxx disks might be due to failure of FLASH memory in the controllers 
(either onboard the CPU or external chips).  The charge in the memory cells in 
FLASH memory chips doesn't last forever, and slowly bleeds away.  Early devices 
could fail after 10 years.  Newer FLASH parts are better, but the lifetime is 
not infinite like it was with PROMs/EPROMs.

The folks at CMU and LSI Corp wrote a good article about this:

http://users.ece.cmu.edu/~omutlu/pub/flash-memory-data-retention_hpca15.pdf

And to Alan's floppy archiving plans - Just remember to regularly refresh 
your CD collection.  Those CD-R disks don't last forever either!  If it was me, 
I'd be creating at least two copies.

Cheers
Jason

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Hans-Ulrich 
Hölscher
Sent: Thursday, 16 July 2015 9:16 AM
To: simh@trailing-edge.com
Subject: [Simh] DEC floppy disk interleave questions


   if you want to image your disks and floppies for use with simh,   
 there's an easy way to do it.  All you need is a (Micro-)VAX   having 
 the appropriate drive(s) running VMS.
   MOUNT/FOREIGN
   COPY/LOG  yourimagename.img
   DISMOUNT
   Don't worry about the error message at the end of the COPY process  
  - that's normal, just that copy discovers the end of media.
   You get an image containing all the blocks of your device in   
 logical order - VMS will take care of the device details.

 That sounds like the really easy way to do it.   Does it copy
 track 0 of RX01/02 floppies?

Every bit that is readable normally from VMS, hiding only strange sector orders 
and bad block information.
Images from bootable devices are bootable within simh (as long as there's a 
suitable bootable simh device)


 I finally got a MicroVAX 3300 up and running again.   Most of
 my RF3x drives seem to have died while in storage.  Now I have to see 
 if any of the RX02 drives will still work.

So are my RF3xs :-((
My DSSI-VAXen run on HSD coupled RZ disks in BA350 boxes now.


   Will you make your images available?

 Absolutely!   I'm still working on the 9-track tapes, after a
 several-week pause due to my Alpha XP1000 dying and me taking time out 
 for a couple of all-weekend endurance races (24 Hours of LeMons -- the 
 fruit, not the town in France).

 I plan to put all my DEC media images on CDs so I can easily
 make copies.   Each tape/floppy image will be accompanied by a
 text file with the label and other information, and a .JPG photo
 of the media and label.   I've done about 300 tapes so far, of
 which 82 are DEC.   I have another 300 or so to do.   I should
 be done in a couple of months.


I'm very keen on your software pool, many thanks for preserving it!

As you probably know I'm mainly after old VMS software (everything pre VMS V5)
 

Regards

Ulli




---
Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! 
http://email.freenet.de/basic/Informationen


___
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] Booting the vax750 simulator.

[Armistead, Jason BIS]

Out of curiosity, I did a bit of Googling, and found a link to the following 
Digital Technical Journal article from 1992 that explains GEM in detail.  It 
also gives the biographies of a number of the key players involved with GEM – I 
wonder how many Clem still has sitting in his office these days.

http://www.linux-mips.org/pub/linux/mips/people/macro/DEC/DTJ/DTJ808/DTJ808PF.PDF

Jason

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Clem Cole
Sent: Tuesday, 7 July 2015 4:17 PM
To: Henry Bent
Cc: simh@trailing-edge.com; Mark Pizzolato - Info Comm
Subject: Re: [Simh] Booting the vax750 simulator.


On Tue, Jul 7, 2015 at 3:49 PM, Henry Bent 
hb...@oberlin.edumailto:hb...@oberlin.edu wrote:
It appears that it comes with VAX C, which is part of the base Ultrix packages.

​That makes sense.   As I said, I'm would suspect it was driven by VAX Fortran 
project, but once that was done any of the DEC languages would have used it 
since GEM tried to be common for all.

GEM was an amazing project.   N front ends, Y backends.  A compiler suite 
designed to last for 20 years.   Needed to span a 16 to 64 bits, parallel, 
vectorization etc.N included Fortran, Bliss, C, C++, Pascal, ​Cobol, Ada, 
Basic and I believe others now forgotten.   Y was PDP-11, Vax, MIPS, Alpha, 
Itanium, x86, 68K, Prism and again probably others which I have forgotten.

Clem

BTW:  Intel owns all of the IP and the few members of the GEM team that have 
not yet retired (we will lose Mr. Fortran on July 15).   IMO:  Sadly, guess 
which compiler technology Intel uses, something developed locally to benchmark 
the x86 or GEM?   As Rich Grove (father of GEM) once said to me, the DEC DNA 
lives, and has slowly been injected into the Intel technology.

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

Re: [Simh] Problem with reading tape with PDP-11 SIMH

[Armistead, Jason BIS]

So now that Alan has TPC working, where and how do we document all this, i.e. 
the symptoms, the underlying SIMH design  behavior vs the expected RSX 
behavior that cause it to manifest itself as a problem, and the DEP TS TIME 
solution, in an easy-to-find way so the next person doesn't have to go through 
this pain ?

There is an awful lot of collective wisdom from the contributors to this e-mail 
list, but unless someone diligently searches the mailing list archives and gets 
lucky, it's not easy for a user to solve their own problem, even if it's been 
seen several times previously.

The SIMH FAQ on the trailing edge web site (in PDF) has not been updated in 3 
years, and the DOC version on GitHub was last updated a little over 2 years 
ago, and I wonder whether a better living form of documentation like a Wiki 
would be a more useful solution. i.e. when a system-specific usage-related 
problem is discovered (and hopefully fixed), the cause, effect and solution is 
distilled into an appropriate new or existing Wiki page.

As I read the e-mails on this list, I am in constant awe at the depth of 
knowledge that many contributors have - in this particular case Mark and 
Timothe did the heavy lifting to help Alan, but there are many others whose 
first-hand experience back in the day drives SIMH user problems to a 
solution.  How do we preserve everyone's legacy of product knowledge for future 
generations who will use SIMH long after they are gone ?  To me it's as 
important as preserving the knowledge of the hardware SIMH simulates.

Jason

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Alan Frisbie
Sent: Thursday, 21 May 2015 8:16 PM
To: m...@infocomm.com
Cc: SIMH@trailing-edge.com
Subject:  Re: [Simh] Problem with reading tape with PDP-11 SIMH

Mark,

 Please follow Timothe Litt's suggestion and get back to me with the 
 minimal value of DEP TS TIME which produces reasonable results for the 
 original TPC problem you saw.

Here are the results:

5000 - TPC works fine
2500 - TPC works fine
1800 - TPC works fine
1500 - TPC works fine, RSX reported tape drive errors
1350 - TPC works fine, RSX reported tape drive errors
1200 - TPC hangs
0- TPC hangs

To be safe, I think I'll use 2000 from now on when using TPC.

Thanks a lot for all the help.   It saved me a lot of
debugging and head scratching.

Alan Frisbie
___
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] In the DEC world, what was ZK3 ?

[Armistead, Jason BIS]

One of the recent discussions on this list mentioned ZK3

I remember it also appeared in numerous DEC publications, with e-mail addresses 
@zk3.digital.com, and, I think, in some DEC documentation (though I may be 
wrong on that point)

What exactly was ZK3 ?  I'm gathering it was possibly a building on the DEC 
campus in Nashua NH.

What did the initials ZK stand for ?  And what was done there ?

Just curious !


Jason

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

Re: [Simh] how to get eth connexion

[Armistead, Jason]

Gérard

SIMH has a console terminal connection.  This is activated after SIMH starts up 
by creating a Telnet connection to port 1 on your host (or else it times 
out).  That implies that the IP protocol be activated on at least one network 
interface on your host.

Jason

-Original Message-
From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Gérard Calliet
Sent: Wednesday, 6 November 2013 3:49 AM
To: simh@trailing-edge.com
Subject: [External] Re: [Simh] how to get eth connexion

Le 05/11/2013 13:55, Mark Pizzolato - Info Comm a écrit :
 2) I saw we need at least one ip host connexion alive to have a 
 connexion for
 simh - I am on Windows with wincap -. Again, why ?
 I'm not sure exactly what you mean by 'need at least one ip host connexion 
 alive'.  Are you saying that you need to be connected to a network?
Thanks to your help, I was able to communicate using a classic wire connexion. 
It works also with the only wire interface, used by Windows for ip traffic, and 
by simh for its (ip also) traffic.
If I disable the ip protocol for the interface, simh also cannot work.
My question is theoretical : why do we need an ip host protocol on the host 
interface for simh being able of work with this interface ? It's perhaps a 
window / wincap issue.
Don't worry about it : it is only to increese my knowledge. I do go on with 
wired and ip-ed solutions.

Gérard Calliet
___
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] PIP10 on PDP-8 SIM

[Armistead, Jason]

I had trouble with Timothe’s link to the USPTO, but found this same patent in 
PDF form at

http://www.brouhaha.com/~eric/retrocomputing/dec/dectape/3387293.pdf

As a relative newbie who started my serious journey into computing with an 
Apple ][  I’ve never fully understood DEC’s fascination with word lengths that 
weren’t multiples of 2 (even though I dabbled with the PDP-11s at the local 
council my father worked at as a civil engineer – mainly to play Mugwump and 
Wumpus after giving up on trying to learn FORTRAN).  Maybe someone can give a 
brief history behind the 12-bit, 18-bit and 36-bit sizing of words.  All I’ve 
ever had to deal with are 8-bit, 16-bit, 32-bit and 64-bit processors and their 
O/S. (But yes, I do remember the 4004 !!!)

From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Timothe Litt
Sent: Tuesday, 19 March 2013 9:03 AM
To: simh@trailing-edge.com
Subject: Re: [Simh] PIP10 on PDP-8 SIM

The DECtape format as such, with all the headers and so on, is the same on all 
tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, 
while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I 
remember right).
Pretty much right.  129 may be slightly misleading.  The format is 129, but the 
-8 used  only 128 of the 129 12-bit words/block for data.

The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8) formatted 
DECtape would have 578 blocks of 128 36-bit words.  (256 18-bit words at the 
hardware level.)

Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and didn't contain 
user data.

Block 100 is the directory block.  Thus 574 blocks for user data.  The 
directory holds up to 22 files, plus a map of which file owns each block.

The user data blocks have a one word header (LH = next block of file; RH = 
first block  words used in this block) + 127 words of payload.  This differed 
from disk files, where all 128 words were payload, so inattentive programmers 
could make a number of mistakes.  (E.g. random access block isn't word/128; you 
had to pay attention to the buffer's word count, etc.)

Data blocks of a file are (usually) not contiguous; this allowed the drive to 
stop and restart while reading or writing without having to reverse direction.  
The spacing depended on what blocks were free when files were written, and the 
data mode.  (Files written in 'core dump' modes were assumed to be read by the 
monitor without stopping, so the gap was smaller, allowing larger programs to 
be read without reversing direction.)

The gory details of the format are in the Monitor Calls manual (TOPS-10).

The PDP-11 used 18-bit format, but ignored the high 2 bits of each word (except 
when reading PDP-10 tapes; the hardware for that was tricky as the high bits 
had to be read with programmed IO; the low 16 were DMAed on the TC-11.)

The low-level formatting that established the mark track, end zones and block 
delimiters was done via a stand-alone diagnostic.  This differs between the two 
formats.  The directory block could be initialized under timesharing.

Directory structure given is for the PDP-10; other OSs used different formats.

From an emulation point of view, the PDP-10's controller was the most 
interesting; the driver does dead reckoning; that is, it will start a drive 
spinning for a seek, disconnect, service other drives, and reconnect just 
before the desired block is expected to be over the read head.  So real-world 
timing matters.  The other controllers (and thus OSs) didn't support this.

Oh, all numbers above are radix 10.

The link for OS8 that I posted yesterday was via filewatcher; the direct link 
is ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/ Sorry 
if this was confusing.

Of potential interest to low-level folks is 
http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1Sect2=HITOFFp=1u=/netahtml/PTO/search-bool.htmlr=1f=Gl=50d=PALLRefSrch=yesQuery=PN/3387293

Hope this is useful.



This communication may not represent my employer's views,

if any, on the matters discussed.
On 18-Mar-13 16:26, Johnny Billquist wrote:
On 2013-03-18 17:44, Bob Supnik wrote:

I was trying to get a debug setup for PIP10, per Ian King's mail, when I
discovered that none of my OS/8 images have PIP10 on them. This
certainly explains why the feature has never been tested before. I
suspect that ReadAll and WriteAll either are not working at all, or are
not working when the DECtape format is 18b. Another possibility is that
PDP-10 DECtape format is not the same as 18b format, at the nitty-gritty
level (format of headers and trailers).

The DECtape format as such, with all the headers and so on, is the same on all 
tapes. A normal PDP-8 formatted tape will have 129 (12-bit) words, however, 
while a PDP-10 (or any other 18-bitter) would have 128 18-bit words (if I 
remember right).
The PDP-8, when doing 12-bit formatted tapes, just packs data in a way that is 
rather different from an 

Re: [Simh] Extended SimH on BeagleBone controls real blinkenlight panels

[Armistead, Jason]

Why not go all the way and record video of each type of old hardware in action 
?  Obviously this makes no sense for blinkenlights, but it might be fun to 
watch tape drives spinning back and forth (a series of short sequences of video 
for each operation), or maybe someone opening up a disk pack and installing 
platters.  Of course, this would require yet another interface from SIMH to the 
video playback system.

It would remind me of those old movies where the computer rooms always had rows 
and rows of lights, and tapes running, together with the sounds of teletype 
printers spewing data out ...

Now, if we could just skin our favorite terminal emulator with a VT-220 case 
around the window area, we'd be all set in our virtual retro-computing world !

Wait, did I mention using 3-D glasses ??? LOL !!!


-Original Message-
From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of dott.Piergiorgio d' Errico
Sent: Thursday, 19 April 2012 12:24 PM
To: simh@trailing-edge.com
Subject: Re: [Simh] Extended SimH on BeagleBone controls real blinkenlight 
panels

Il 19/04/2012 15:21, Bucher, Andreas (Andreas)** CTR ** ha scritto:
 Hi,

 I just finished another Blinkenlight project: An extended SimH runs 
 on a BeagleBone (credit card sized Linux platform) and controls real 
 console panels of historical computers, or simulations of those 
 panels. So the project is named BlinkenBone.

 First implementation is re-animation of a PDP-11/40 console (KY11-D), 
 others will follow. See documentation here:
 www.retrocmp.com/projects/blinkenbone

 I think there are a few? a lot? other SimH-blinkenlight projects 
 out there. Perhaps it is time to define the definitive SimH - 
 Blinkenlight interface, so there's a standard for future work. My 
 proposal is 
 http://www.retrocmp.com/projects/blinkenbone/169-blinkenbone-a
 rchitecture-overview

 If you like to build this too, we will support you ... but it won't 
 be cheap. And code deployment isn't organized yet, contact me on 
 demand.



 Hi,

 that's waaay cool ! Not really useful for practical computing, but 
 absolutely mandatory for the genuine look-and-feel of some ancient 
 big iron :-)

 I like your modular approach - it allows people NOT owning true 
 hardware blinkenlights to replace them with some software simulated 
 frontend instead ! Would be cool to have SIMH equipped with all kind 
 of genuine virtual (or real, for the purists) designs of the systems 
 it emulates ! Have a look for PINMAME, the pinball emulator software, 
 and you know what I mean :-) (wll, yes, a pinball machine's main 
 item IS the hardware you see, and the CPU is only some aid in behind, 
 while our emulated data processing systems are vice-versa - but anyway 
 ...)

 And - finally ... that's what I already suggested years ago (and only 
 got startled looks): Equip SIMH with some standard interface to 
 optionally drive real hardware components of the systems it 
 emulates, like console panels and stuff. I even went as far as to 
 suggest incorporating all other kind of events from inside the system 
 beeing signalled out - this could be used to generate sound events as 
 well !

Perhaps the startled looks came from people whose main interest is keeping 
running legacy software, an important thing in se, but driving real 
(reconstructed) hardware is equally important, if not for the recovering  
preservation of software  source codes on DECtapes, tapes, removable platters 
c

On the blinkenlighten project, I have indeed suggested (ands ends
rejected...) that ex and de command accept (and outputs) binary digits and 
space, (e.g. de 000 100 111 ) whose IMVHO is not only a convenient means when 
dealing with old big iron software, but also a convenient protocol (being 
*both* human and machine readable/writable) for a blinkenlighten protocol.

Seems that there's a consensus in starting working on graphics emulation after 
3.9.0 release and the sort of retirement (If I have understand
well...) of bob from the active development of SIMH.

I reckon that my perspective (of Historian of technology and random hacking 
when the mood is in) differ from the other member of this fair ML, but it's my 
perspective (for the record my lack of frequent contribuition is because of the 
extreme dispersiveness in dealing with project (I suspect that my WIP list is 
in high 10s or low 100s, but I have never done a census of it...)

 Think about your DECbox emitting true 11/750 noises, perhaps with some 
 TE16 tape in the background, hehe :-)

 So, you better go ahead and digitize not only the Front Panels, but 
 also the sound of the remaining hardware that is alive, or sythesize 
 the sound of dead hardware and have it proof-listened by the few 
 people knowing the hardware that still are alive as well ...

I'm deaf and not much interested in that ambient sound emulation idea, but 
ISTR to have pointed to bob in a PM the group whose mantain and keep running 

Re: [Simh] Running and compiling SIMH under 64-bit Windows 7

[Armistead, Jason]

Thanks for all your help Jason.  It's these sorts of offers for help that I've 
always loved about the DEC user community.  8-)

I'm using VS 2008 Express, so let's stick with that, and I'm running Windows 7 
64-bit on an Intel Core Duo CPU PC.

Of all the SIMH emulated hardware, I only need the MicroVAX 3900 with Ethernet 
support.  I've always had a special place for the MicroVAX range since I first 
started working with a MicroVAX 2000 back in 1988 (even if I wasn't keen 
loading MicroVMS 4.5B onto it from a stack of nearly 80 5.25 floppies !!!).

Jason

-Original Message-
From: Jason Stevens [mailto:neoz...@gmail.com] 
Sent: Monday, 2 May 2011 9:59 AM
To: Armistead, Jason
Cc: simh@trailing-edge.com
Subject: Re: [Simh] Running and compiling SIMH under 64-bit Windows 7

I'm using VS 2010 professional... As far as I remember the express
stuff is 32bit only.  The platform SDK's come with all kinds of stuff,
including cross compilers, I think they are free...?

Like this one for 2003...
http://www.microsoft.com/downloads/en/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5displaylang=en

While this one is for 2008 / .net 4.0
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6B6C21D2-2006-4AFA-9702-529FA782D63B

I don't have any MS Makefiles (nmake is.. weird.) but looking at the
makefile you can usually figure out what you want along the lines of
...

cl -DVM_VAX -DVAX_780  -I VAX -I PDP11 -I. -Ox  -c scp.c
cl -DVM_VAX -DVAX_780  -I VAX -I PDP11 -I. -Ox  -c sim_console.c
cl -DVM_VAX -DVAX_780  -I VAX -I PDP11 -I. -Ox  -c sim_ether.c


etc...

Microsoft started on the 64bit train some time back in 2001 on the Dec
Alpha of all things... Then when Compaq bought Dec, it saw the Alpha
as a threat to it's high end Pentium stuff and killed the Alpha NT
port.. But it was developed internal, lots of SDK's have the
Alpha64/DEC64 tags in them so clearly it is where is started.. And of
course the long road to the Itanium, then finally the x86_64.  I've
recently acquired an Itanium, and it's not as bad as I'd thought, but
the compilers are far less forgiving then the x86_64 stuff.

What platform do you need?  I'm sure I can cook up a nmake package file for you.

On Mon, May 2, 2011 at 9:32 AM, Armistead, Jason
jason.armist...@otis.com wrote:
 Jason

 I'm running VC 2008 Express, but could probably grab the VC 2010 Express 
 edition if that's what you're using.

 I'm not entirely sure when Microsoft started being able to generate 64-bit 
 EXEs in their toolchains, but since I started writing my reply I also did 
 some Googling and it seems that I may need to get a fully-blown version of 
 Visual Studio Professional

 http://blogs.msdn.com/b/deeptanshuv/archive/2006/04/11/573795.aspx

 but then I read posts like

 http://social.msdn.microsoft.com/Forums/en/Vsexpressvc/thread/4ce313a3-cb5f-43fc-bbb9-50233f8ed11b

 which seem to indicate I may be OK.

 Sigh !  Too many toolset options compared with what I was used to under 
 OpenVMS VAX / Alpha !

 Cheers
 Jason

 -Original Message-
 From: Jason Stevens [mailto:neoz...@gmail.com]
 Sent: Monday, 2 May 2011 9:14 AM
 To: Armistead, Jason
 Cc: simh@trailing-edge.com
 Subject: Re: [Simh] Running and compiling SIMH under 64-bit Windows 7

 I'm pretty sure I've done it at some point

 I've done a VC 2005 project on older source here..

 http://sourceforge.net/projects/simh/files/simh%20source%20code/simh%203.7-3/simh-3.73-vc2005.zip/download

 I guess I could update it, is Visual Studio 2010 ok?  I need to do a
 'proper' Itanium version at any rate

 On Mon, May 2, 2011 at 9:02 AM, Armistead, Jason
 jason.armist...@otis.com wrote:
 Has anyone built an EXE of SIMH with networking support which will run
 properly under Windows 7 64-bit ?  Or, perhaps somehow has the current SIMH
 EXEs running under Windows 7 64-bit as-is

  ?

 We’re beginning the inevitable corporate move from XP 32-bit to Windows 7,
 and 64-bit seems like the preferred option rather than 32-bit.

 Has SIMH been compiled specifically for 64-bit Windows platforms, and is
 there a Visual Studio project environment (or perhaps another alternative
 environment) that I can get from somewhere to give this a go for myself ?

 Thanks

 Jason

 ___
 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] EXTERNAL: Problem booting an emulated VAX-11/780 from a Massbus disk drive

[Armistead, Jason]

So now the real question from this discussion becomes …

 

“How do “we” (initially Bob Supnik and perhaps the SIMH users/contributor base) 
track the “core” and “per platform” SIMH requirements ?”

 

which then leads on to the whole issue of test cases for requirements 
validation, functional allocation, etc. and also to a discussion about how much 
of this ought to be documented right inside the SIMH source code (given that 
many SIMH users may never have access to the hardware manuals or operating 
system source listings (in this case, for various flavors of VMS), and what 
degree of “assumed knowledge” (and prerequisite DEC reading materials) is 
required to actually understand the source fully.

 

One day, (hopefully not for a VERY, VERY long time), Bob won’t be around to ask 
these questions about SIMH’s implementation or about the original DEC 
hardware/software he based the VAX implementations on.  If we’re truly going to 
keep SIMH going long past that point, we need to come up with a plan to make 
sure that the SIMH software has well-documented requirements.

 

Jason

 

From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Hittner, David T (IS)
Sent: Tuesday, 25 January 2011 3:55 PM
To: Peter Allan; simh@trailing-edge.com
Subject: Re: [Simh] EXTERNAL: Problem booting an emulated VAX-11/780 from a 
Massbus disk drive

 

Congratulations, you have found a “Devil in the details”!

 

Over the years, VMS driver internal implementations have changed substantially. 
What you are experiencing is that VMS V4 appears to interact with the RP 
controller (not just the RP06 drive) differently than later versions of VMS. It 
 appears that there was a substantial driver standardization/rewrite effort 
that occurred around the VMS V4/V5 era from the later driver comments that I 
have seen.

 

The way to find the exact problem is to either walk your way through the VMS 
driver with the VMS source code, and see where the controller simulation is 
behaving differently than expected, OR put some breakpoints in the simulated 
read/write routines, and try to intuit the correct controller behavior from 
what you see happening from the driver. The second way is harder, but sometimes 
it’s the only way if you don’t have source code.

 

In many hangs, the problem turns out to be a timing issue – the controller 
simulation is responding too fast or too slow, based on the behavior that the 
driver expects to see. VMS may be hung waiting for an interrupt that has 
already fired or a register value that has already been overwritten - that is, 
the simulation is “too fast” and needs to delay things with a timer.

 

I’ve just finished debugging a similar problem in the VMS DEUNA driver, where 
later versions of VMS work fine, but the earlier VMS V3/V4 drivers left the 
controller not functional.  Using the second method (because I don’t have any 
VMS sources earlier than 7.2), I watched the DELUA registers and intuited that 
the problem was incorrect behavior in the DEUNA SELFTEST command, since that’s 
the point where the VMS driver quit trying to work with the card. My DEUNA 
patch will appear in the next full release of SIMH.

 

If you can’t debug the problem yourself, you can always ask someone in the SIMH 
community to step up and take a crack at it.

Or ignore the problem and use your RA81 workaround.

Good luck.

 

Dave Hittner

 

From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Peter Allan
Sent: Tuesday, January 25, 2011 3:00 PM
To: simh@trailing-edge.com
Subject: EXTERNAL:[Simh] Problem booting an emulated VAX-11/780 from a Massbus 
disk drive

 

I started this thread over on comp.os.vms in case anyone knew of VMS cause of 
my problem, but it seems to be a problem with simh.

have been trying to set up the VAX780 emulator in simh to boot VMS 4.6 from an 
RP06 disk drive and I have failed.

My tests have been the following.

I installed VMS 4.6 (and 4.0 and 4.2) on an RP06 drive. When I try to boot from 
the RP06, then VMS starts up, displays a line like 

VAX/VMS Version  KG  15-Jun-1987 10:00

and sits there forever. The KG is because I have not yet been able to apply 
the mandatory update. Clearly the 780 is booting from the disk since it 
displays the one line message.

If I boot with the command

b rp0/r5:1

then I get into SYSBOOT, but everything appears to be fine. Typing CONTINUE 
returns to the hung state.


Next I tried installing VMS 4.6 on to an RA81 disk drive. This works fine, so I 
copied the contents of the RA81 to an RP06 drive using stand alone backup and 
tried booting from the RP06, but still the system hung during the boot process. 
So the problem appears to be with the RP06 drive, not with VMS or with the 
installation procedure.

I tried changing the RP06 disk type to all other possible Massbus disk types 
(RP04/05/07, RM02/03/05/80) and installing VMS 4.6. These all act in the same 
way as the 

[Simh] SIMH test suite / target CPU speed control

[Armistead, Jason]

While discussing SIMH futures, Vince Mulhollon wrote:

 I use a bash script that automates:

 wget's some relevant papertape or whatever of diagnostic routine

 runs a short expect script on simh pdp8 or whatever that executes the
 diagnostic routine and saves the disk images etc.

 md5sum the resulting output, and compare to the golden correct
 answer.

One potential problem would be accounting for any variation in the execution 
behavior, e.g. if the time-of-day clock was read from the host or if network 
interactions occur (assuming networking is enabled).  That would prevent you 
from getting repeatable modification dates on the SIMH target's disk file 
systems, and also the content of log files e..g  the OpenVMS OPERATOR.LOG.  So, 
the resultant disk images would differ in non-trivial ways.  Even if you could 
seed the time-of-day clock before running your SIMH test suite, any other 
process running on your host OS (and these days, there are many), would cause 
jitter in the elapsed execution time, again affecting timestamps. Even under 
DOS, I once observed a Toshiba Tecra laptop (Pentium 233) which had about a 10% 
variation in the number of simple increment operations it could do between the 
55msec BIOS timer ticks - my conclusion was that the effects of all the 
background hardware ISRs implemented on a modern PC in the BIOS ar
 e non-trivial, e.g. battery management, network, USB, and who knows what else, 
even under good old DOS.

 For over a decade I've dreamed of a simh with 
 real time execution, so it runs and I/O operates at real time speeds,
 or perhaps a configurable multiple thereof.  I've always believed the
 current idle loop detection system is an architectural and scalability 
 dead end, the solution to a PDP-8 running at 100 times real speed and 
 hogging the host CPU 100% is to force the PDP-8 to run at configurable 
 real speed and ignore that its hogging a whopping 1% of the host CPU 
 in the idle loop.

The last time I looked, the arcade machine emulator MAME achieves this using 
the x86 Performance Counter functionality, and by knowing the clock cycle cost 
of each machine language instruction.  It then lets the emulated CPU run for 
some number of expected cycles, then idles itself until it's ready to do 
another chunk of instructions.  For example, if you can do 100msec worth of 
emulated instructions in 1msec on your shiny new multi-GHz CPU-equipped PC, you 
simply idle for 99msec.  To the observing user, if the time quanta is set 
right, it's not observable that it's not truly realtime.  For MAME, I think 
this is normally synchronized to the video refresh rate since that's what 
someone playing an arcade game is observing.

One of the challenges is retrofitting machine cycle counting into SIMH.  Some 
of those complex VAX instructions like the CRC instruction could take a 
variable amount of time to complete.  If you truly want to be cycle-accurate, 
you need to know all the gory implementation details.  If you wanted a near 
enough is good enough approximation and had an instruction which took between, 
say, 6 and 10 cycles to execute, you might split the difference and say that 8 
cycles is an OK average.

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

Re: [Simh] SIMH future releases / Sourceforge project

[Armistead, Jason]

Previously, Nigel Hornen...@bandsman.co.uk wrote:

 and SIMH, originally, was not open source in the sense that any 
 responsible programmer could contribute.
 The quality of the software and the ultimate decision on released 
 functionality was always in the hands of Bob S.
 And a mighty fine job he did!

And then later, Wilm Boerhout wrote:

 This discussion is not (was not originally) where it's stored (although 
 others above have pointed to viable alternatives) but who is 
 responsible: Bob Supnik or the open source community. I vote for Bob.

Just to be perfectly clear, I am a HUGE fan of Bob Supnik's work on SIMH.  
Booting OpenVMS on SIMH still brings a grin to my face when I think back about 
wrestling with a shiny new MicroVAX 2000 and loading MicroVMS 4.5B from about 
80 floppy disks back in 1989.  Bob's (largely single-handed) vision and 
dedication is what brought SIMH and the retro-computing it allows us all to 
enjoy, to the point where it is today.

Having said that, I also don't want to see SIMH become stagnant if Bob's 
available time to devote to SIMH may become (or perhaps already is) limited.  
And I don't want to see multiple forked versions of the code start to spring up 
because people are impatient waiting for patches to be incorporated in the 
mainline, or for their favorite new whiz-bang OS to be supported as a host.  I 
am not voting against Bob, but rather, my vote is for SIMH *and* for 
maintaining it to the same high standard as Bob intended.  If that means having 
a core team that ensures Bob's blueprint is followed, fantastic.  If Bob wants 
to tell us all to take a hike, I've got to respect that too.

Bob, if you're out there reading this thread, your devoted SIMH fans would love 
to hear your thoughts !!!

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

Re: [Simh] Largest VAX / PDP disk sizes

[Armistead, Jason]

Tim

 

Doing a bit more digging, it looks like if I just use the SIMH “RAUSER” disk 
type, and give it a size large enough for my needs, I’ll be OK.  The 
precompiled SIMH binaries for Windows include 64 bit file support so I can go 
bigger than 2Gb without any problems.

 

I also came across a archived post from Bob Supnik lamenting the lack of 
information for the RA70, RA73 and the other disk I mentioned.  Kind of bizarre 
that no-one knows the details.  I half expected a former Digital employee or a 
NOPSIG member might have known the answers or been able to put their hands on a 
product technical / service manual, or that someone with a still-running system 
might have been able to provide the answers.  Thank goodness for MSCP !

 

Thanks

Jason

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