Re: [Simh] Making tape/disk images

[Ken Cornetet]

Well, the file marks would be obvious. The block size would have to be 
specified by the user. The lack of tape structure would seem to limit the 
usefulness a great deal, but I guess it could still be useful in some cases, 
and it seems pretty easy to implement.

Here's how I'd see it being useful:

1. Create tar, zip, or whatever file on host OS.
2. Copy file (with random name) into virtual tape directory.
3. Read tape in guest OS extracting files.
4. Delete host file (or perhaps have option to make simh delete after reading 
EOF)
5. Repeat as required.

Output could be handy too. Have simh create files in the specified folder using 
the epoch time and a sequential number for the "file number" in the virtual 
tape as the host file name.

The more I think about this, the better I like it. This would make it very 
simple to get files into and out of a guest where no networking exists. No more 
creating tape images, stopping the emulation, attaching tape files, starting 
the emulation.

-Original Message-
From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Al Kossow
Sent: Monday, May 03, 2010 3:35 PM
To: simh@trailing-edge.com
Subject: Re: [Simh] Making tape/disk images

On 5/3/10 12:30 PM, Tim Newsham wrote:
> the code that reads tape images in simh can also
> read from a directory instead of a tape image.
>

and create what type of on-tape directory structure?

tape image code knows of nothing above tape blocks and
file marks.



___
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] Fwd: Making tape/disk images

[Ken Cornetet]

Not sure you need to go to the effort. Most simh hosts already have a perfectly 
usable tar and it is trivial to convert a file into a simh tape image.

Now, what would be handy is a portable (c, perl, etc) of your guest OS native 
tape archiving tool, if it has no way to read or write tar tapes.

But that has little to do with the original discussion.  In the original 
discussion, we aren’t talking about having simh know anything about guest OS 
tape handling, file systems, or archive programs. Simh handles tapes the same 
regardless of OS. Virtual tapes consist of “files”. These tape files consist of 
variable length records.

What we are talking about doing is adding simh code to allow attaching a 
directory as a tape device. Remember, a virtual tape needs “files” consisting 
of records. We know how to build the file information (logical file = physical 
file). Next, we need record length. For this we have two options:  User 
specified fixed size records or text file records. You’d have to supply this 
information to simh when attaching the tape device.

Simple so far. However, the devil is in the details. How to sort files in the 
folder (date or name). How to handle backward tape reading. When to read the 
directory to get a list of files. What if a physical file gets deleted? This 
would all have to be worked out, but I think it is doable.

From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Michael Richter
Sent: Wednesday, May 05, 2010 9:46 AM
To: simh
Subject: [Simh] Fwd: Making tape/disk images

Oops.  Sent this to Tim only instead of list.
-- Forwarded message --
From: Michael Richter mailto:ttmrich...@gmail.com>>
Date: 5 May 2010 21:45
Subject: Re: [Simh] Making tape/disk images
To: "Shoppa, Tim" mailto:tsho...@wmata.com>>

On 5 May 2010 20:59, Shoppa, Tim mailto:tsho...@wmata.com>> 
wrote:
Al writes:
> On 5/3/10 12:30 PM, Tim Newsham wrote:
>> the code that reads tape images in simh can also
>> read from a directory instead of a tape image.
>

>and create what type of on-tape directory structure?

>tape image code knows of nothing above tape blocks and
>file marks.
Al hits the issue exactly on the head.

If SIMH only had to emulate one operating system, with one OS/application tape 
format, then I think the concept of a "virtual filesystem tape image" would be 
OK.

But SIMH is used with dozens of OS's, with hundreds of different tape formats. 
Seems like things spin out of control to support them all inside SIMH.

Now, tools that can manipulate files and load them into tape and disk images in 
OS-specific formats, or go the other way and extract files from tape and disk 
images, has a long tradition. Going back to at least the 1970's. My gut feeling 
is to extend this tradition, not abandon it.

Would it not be possible to make a general-purpose tape archive system that has 
mid-end plugins for the OS-specific formats and back-end plug-ins for the 
simulated physical formats?  This way a single tool with a single command line 
could be made that allows things like (example command lines only):

 *   simtar --create --file=myfile.tap --file-system=RSTS9 --tape-format=SIMH 
./*
 *   simtar --extract --file=myfile.tcp --file-system=VMS --tape-format=TPC
Unless someone can see any reason why this is intrinsically impossible, I 
wouldn't mind taking a crack at such a program written in some scripting 
language for proof of concept (and maybe even final form -- I don't see any 
particular advantage to writing something like this in C since performance 
won't be a huge issue).  Since I'm screwing around with RSTS right now my first 
version would be for RSTS, naturally.  I could then pop the code up somewhere 
for others to hack onto for other formats.  As new emulators get attached, new 
operating systems get resurrected, etc. the program could be expanded with 
plug-ins.

--
"Perhaps people don't believe this, but throughout all of the discussions of 
entering China our focus has really been what's best for the Chinese people. 
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.



--
"Perhaps people don't believe this, but throughout all of the discussions of 
entering China our focus has really been what's best for the Chinese people. 
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Fwd: Making tape/disk images

[Ken Cornetet]

I don't know what John Wilson's virtual disk driver does (I assume you are 
talking about ersatz-11).

For sure, a host program to read and write disk images would be very handy, 
BUT, you'd need a separate version for each operating system. The tape scheme 
we are discussing would be useful for all guest systems.

In my case, I use simh for running HP's RTE-6/VM. RTE's original FMGR file 
system is documented and would be easy to hack, but is of limited 
functionality. RTE's later FMP file system is not (that I know of) documented 
anywhere.

Come to think of it, I seem to recall that FMGR file systems had the built-in 
capability of being shared between two computers. I'm not sure RTE supported 
it, though. 

I think I'll try an FMGR image utility. It should be easy to whip up, and it 
would have the benefit of working with older versions of RTE as well. The 
problem is that I think there is only about three of us running RTE on simh.

-Original Message-
From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Al Kossow
Sent: Wednesday, May 05, 2010 11:17 AM
To: simh@trailing-edge.com
Subject: Re: [Simh] Fwd: Making tape/disk images

On 5/5/10 7:48 AM, Ken Cornetet wrote:

> What we are talking about doing is adding simh code to allow attaching a
> directory as a tape device.

If you're going to do that, create a virtual disk driver like John Wilson
did in his simulator, or create dynamic disk images on the host side that
know the target operating system's file format.


___
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] Hardware Requirements

[Ken Cornetet]

Keep in mind that the printer port on regular old PCs can be used for a few 
lines of general input and output. I used to do this on a regular basis back in 
the DOS days. Looks easy under linux too: 
http://www.faqs.org/docs/Linux-mini/IO-Port-Programming.html



-Original Message-
From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On 
Behalf Of Pontus
Sent: Monday, December 06, 2010 6:20 PM
To: simh@trailing-edge.com
Subject: [Simh] Hardware Requirements

Hi

I just joined the list, this is my first post :)

I was wondering, what are the hardware requirements of simh? What kind 
of CPU would be necessary to emulate a PDP-15 at or over its real world 
speed?

The reason I'm asking is that I want to build a small system to 
interface with PDP-15 panel. I'm looking at the beagleboard, but 
wouldn't mind something simpler and/or cheaper.

Kind Regards,
Pontus.
___
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] HP 2100/1000 A-series

[Ken Cornetet]

As far as peripherals, the A series used HP-IB (HP's version of IEEE 488) 
interface for interfacing with most devices including printers, plotters, tape 
drives and disks. These devices were referred to as "Amigo" and "CS-80" 
(command-set 80 - I have no idea what the 80 stood for). I *think* Amigo was an 
older spec perhaps for disk drives only, and CS-80 was a later general command 
set.

AFAIK, all of the HP-IB devices that were supported on the A series were also 
supported on the M/E/F series, so if someone does an A series emulator with 
HP-IB support, it would be beneficial port that code to the M/E/F emulator.

On the other hand, if someone does an A series emulator, the HP-IB devices are 
the least important. The more interesting devices were the SCSI interface, mux, 
and Ethernet. The only thing you'd really need HP-IB for would be a line 
printer.

As a side note, I seem to have stuck in the back of my mind that the HP 
specials division had an ARCnet board available for the M/E/F series. Does 
anyone know if this is true?

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Holger Veit
Sent: Monday, June 08, 2015 3:21 AM
To: simh@trailing-edge.com
Subject: Re: [Simh] HP 2100/1000 A-series

Am 07.06.2015 um 05:40 schrieb J. David Bryan:
> On Saturday, June 6, 2015 at 21:44, Cory Smelosky wrote:
>
>> It seems there's no current SIMH support for the HP 1000 A-series 
>> system (A900, A990, A600 et cetera) meaning RTE-A (with the ARPA/1000 
>> software!) is unfortunately out.
> That's correct.
>
>
>> Looks like enough docs for at least some of the later ones are up on 
>> Bitsavers...any plans for implementing these missing models?
> Holger Veit  had been looking into 
> doing a SIMH A-Series simulator several years ago, but I've not heard 
> what progress he made, if any.
>
> Regrettably, relatively little of the existing HP 1000 M/E/F-Series 
> simulator could be leveraged for an A-Series simulator.  The base set 
> instructions are the same, although the I/O instructions and I/O 
> structure are entirely different, and there are a number of new 
> instructions.  Also, essentially none of the M/E/F peripherals (disc, 
> tape, terminal multiplexers, line printers) were supported on the 
> A-Series, so a whole new set of peripheral simulators would have to be 
> written.  An off-the-cuff guess would be that reusing the base set 
> would cover maybe 20% of the full simulator code.  The other 80% would have 
> to be written from scratch.
>
> On the plus side, the full RTE-A sources, the A-Series microcode, and 
> several RTE-A binary releases are available in the HP 1000 Software 
> Collection on Bitsavers, so the job is by no means impossible.
JDB summarizes the problem quite precisely.

After the microcode ROM stuff, JDB and I added to the HP1000 system, I infact 
looked at the A series, to possibly extend the simulator with "the missing A 
instructions". It turned out that the A series is not only a class of quite 
different systems with entirely different properties but also with a completely 
new I/O system (based on a monolithic chip). It is a new platform. Workload 
prevented me from following this further, but I am still attracted by such a 
simulator, mainly because of the microcode which is well documented for some of 
the models, as well as for RTE-A itself which is a technological progress to 
the older RTE-IV/6VM systems.

On the documentation side, the I/O chip is well documented, however the various 
peripherals that are built around it are less described. That time I didn't 
find a complete enough set to combine a useful A hardware. The CPU part itself 
is likely the smallest problem even if I'd start this from scratch as well (as 
a plain microcode interpreter) rather than lifing the base instructions from 
the HP1000 emulator.

The things are not forgotten, as well as the PDQ3 and Sage-II/IV things
- it's just the general problem that the day is limited to 24h.

--
Holger

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

Re: [Simh] vector images

[Ken Cornetet]

msiexec /a pathtoMSIfile /qb TARGETDIR=pathtotargetfolder


From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Armistead, 
Jason BIS
Sent: Friday, July 17, 2015 9:41 AM
To: simh@trailing-edge.com
Subject: Re: [Simh] vector images

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 
mailto: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.org.

De

___
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] off-topic basic translator

[Ken Cornetet]

Perl has goto. Just sayin'

Writing a VAX basic to perl translator sounds like fun, and when you are done, 
you'd have learned a usable language.

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Dan Gahlinger
Sent: Tuesday, August 04, 2015 4:38 PM
To: Kevin Handy; Tom Morris
Cc: simh@trailing-edge.com
Subject: Re: [Simh] off-topic basic translator

Then I'll have to do it myself by hand, which from the manual doesn't look that 
bad.
I'll test the vb2py script but I won't hold my breath.
I'm not going to write my own to translate a paltry dozen or so programs (even 
if some of them are long).

I shudder at having to translate "goto" :)
But from the manual link I provided on vax basic, it doesn't look terribly bad.
I'll probably convert to freepascal which has portability to many platforms, 
and is the one I'm most familiar with.

Vax Basic was probably one of the easiest languages I've ever had to learn, in 
hindsight it was probably a bad idea to learn it
so early on, should have learned C instead...

Dan.

Date: Tue, 4 Aug 2015 14:29:49 -0600
Subject: Re: [Simh] off-topic basic translator
From: khandy2...@gmail.com
To: tfmor...@gmail.com
CC: dgahl...@hotmail.com; 
simh@trailing-edge.com
It won't help you. If you look at the section "Untranslatable Language 
Features" it specifically mentions that MAP, COMMON, and FIELD, and MAT 
statements are not habdled.

On Tue, Aug 4, 2015 at 2:19 PM, Tom Morris 
mailto:tfmor...@gmail.com>> wrote:
If you want to target Python, you might look at using something like vb2py as a 
starting point.
http://vb2py.sourceforge.net/

Tom


On Tue, Aug 4, 2015 at 3:34 PM, Dan Gahlinger 
mailto:dgahl...@hotmail.com>> wrote:
I was thinking of this one: 
http://h71000.www7.hp.com/commercial/basic/t12/t12_pro.html
so definitely there was one, it's discontinued though.

I don't know what to do with MAP or MAT statements, otherwise I could do most 
of it myself.

C or C++ is not an ideal language, I was thinking of easier translations,
like say to freepascal or python, as they are most "basic like" in looks.
Strings as you say can be tough, but that's why pascal or even python is good,
strings are just strings.
basic was great for string manipulation because you could do literally anything.

I was kind of hoping someone might have a copy of the HP/compaq product listed 
above
I certainly don't want to buy it (though its discontinued so I can't) just to 
translate a dozen programs
that I wrote myself back in the 80's.

Update: it looks like I might be able to do it myself using this reference 
document:
http://bitsavers.trailing-edge.com/pdf/dec/vax/lang/basic/AA-HY15B-TE_VAX_BASIC_User_Manual_Feb90.pdf

Dan.


Date: Tue, 4 Aug 2015 12:29:01 -0600
Subject: Re: [Simh] off-topic basic translator
From: khandy2...@gmail.com
To: dgahl...@hotmail.com
CC: simh@trailing-edge.com

I don't think DEC ever did a translator, only compilers.
There used to be a company that sold one, but is definately wasn't free. Cannot 
remember their name.
I wrote a heafty part of a VaxBasic to C++ translater, but never handled MAP's 
or their like very well. It is useful to do a preliminary conversion, but then 
needs a lot of editing for most programs. Things like programd from "101 Basic 
Computer Games" mostly work without any problems. Nut it's been a while since I 
did anything with it.
Problems with the yranslations are mostly vaused by the way Basic handles 
variables, especially strings. C++ hastwo types of string (char* and 
std::string), but Basic has several different types mixed together. MAPs want a 
fixed length fixed position string which may overlap other strings. Normal 
nasic strings are variable length and variable position. FIELD statements can 
change a string from one type to another. It gets quite complicated without 
writing the DEC string library, which is quite complex.

On Tue, Aug 4, 2015 at 9:52 AM, Dan Gahlinger 
mailto:dgahl...@hotmail.com>> wrote:
Does anyone have or know where I can get a copy of the Vax Basic translator?
Especially for VMS or windows or something?

I'd like to convert my old Vax Basic programs to something usable on modern 
systems,
but while Vax Basic is simple enough there are a few things I have trouble with,
such as MAP statements, records, etc.

I've tried looking on the HP/etc sites and it seems it's been discontinued,

does anyone have a copy I can use, or know where I can get one?

I don't want to pay for a product, as this is just hobbyist use for personal 
programs I wrote

thanks

Dan.

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


_

Re: [Simh] off-topic basic translator

[Ken Cornetet]

Well, perl is often described as a write-only language. Perfect as the output 
of a translator!

From: Dan Gahlinger [mailto:dgahl...@hotmail.com]
Sent: Tuesday, August 04, 2015 4:59 PM
To: Ken Cornetet; simh@trailing-edge.com
Subject: Re: [Simh] off-topic basic translator

Per is not a usable language. Lol



Sent from my Samsung Galaxy smartphone.


 Original message 
From: Ken Cornetet 
mailto:ken.corne...@kimballelectronics.com>>
Date: 08-04-2015 4:55 PM (GMT-05:00)
To: simh@trailing-edge.com<mailto:simh@trailing-edge.com>
Subject: Re: [Simh] off-topic basic translator

Perl has goto. Just sayin’



Writing a VAX basic to perl translator sounds like fun, and when you are done, 
you’d have learned a usable language.



From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Dan Gahlinger
Sent: Tuesday, August 04, 2015 4:38 PM
To: Kevin Handy; Tom Morris
Cc: simh@trailing-edge.com<mailto:simh@trailing-edge.com>
Subject: Re: [Simh] off-topic basic translator



Then I'll have to do it myself by hand, which from the manual doesn't look that 
bad.
I'll test the vb2py script but I won't hold my breath.
I'm not going to write my own to translate a paltry dozen or so programs (even 
if some of them are long).

I shudder at having to translate "goto" :)
But from the manual link I provided on vax basic, it doesn't look terribly bad.
I'll probably convert to freepascal which has portability to many platforms, 
and is the one I'm most familiar with.

Vax Basic was probably one of the easiest languages I've ever had to learn, in 
hindsight it was probably a bad idea to learn it
so early on, should have learned C instead...

Dan.



Date: Tue, 4 Aug 2015 14:29:49 -0600
Subject: Re: [Simh] off-topic basic translator
From: khandy2...@gmail.com<mailto:khandy2...@gmail.com>
To: tfmor...@gmail.com<mailto:tfmor...@gmail.com>
CC: dgahl...@hotmail.com<mailto:dgahl...@hotmail.com>; 
simh@trailing-edge.com<mailto:simh@trailing-edge.com>

It won't help you. If you look at the section "Untranslatable Language 
Features" it specifically mentions that MAP, COMMON, and FIELD, and MAT 
statements are not habdled.



On Tue, Aug 4, 2015 at 2:19 PM, Tom Morris 
mailto:tfmor...@gmail.com>> wrote:

If you want to target Python, you might look at using something like vb2py as a 
starting point.

http://vb2py.sourceforge.net/



Tom





On Tue, Aug 4, 2015 at 3:34 PM, Dan Gahlinger 
mailto:dgahl...@hotmail.com>> wrote:

I was thinking of this one: 
http://h71000.www7.hp.com/commercial/basic/t12/t12_pro.html
so definitely there was one, it's discontinued though.

I don't know what to do with MAP or MAT statements, otherwise I could do most 
of it myself.

C or C++ is not an ideal language, I was thinking of easier translations,
like say to freepascal or python, as they are most "basic like" in looks.
Strings as you say can be tough, but that's why pascal or even python is good,
strings are just strings.
basic was great for string manipulation because you could do literally anything.

I was kind of hoping someone might have a copy of the HP/compaq product listed 
above
I certainly don't want to buy it (though its discontinued so I can't) just to 
translate a dozen programs
that I wrote myself back in the 80's.

Update: it looks like I might be able to do it myself using this reference 
document:
http://bitsavers.trailing-edge.com/pdf/dec/vax/lang/basic/AA-HY15B-TE_VAX_BASIC_User_Manual_Feb90.pdf

Dan.





Date: Tue, 4 Aug 2015 12:29:01 -0600
Subject: Re: [Simh] off-topic basic translator
From: khandy2...@gmail.com<mailto:khandy2...@gmail.com>
To: dgahl...@hotmail.com<mailto:dgahl...@hotmail.com>
CC: simh@trailing-edge.com<mailto:simh@trailing-edge.com>



I don't think DEC ever did a translator, only compilers.

There used to be a company that sold one, but is definately wasn't free. Cannot 
remember their name.

I wrote a heafty part of a VaxBasic to C++ translater, but never handled MAP's 
or their like very well. It is useful to do a preliminary conversion, but then 
needs a lot of editing for most programs. Things like programd from "101 Basic 
Computer Games" mostly work without any problems. Nut it's been a while since I 
did anything with it.

Problems with the yranslations are mostly vaused by the way Basic handles 
variables, especially strings. C++ hastwo types of string (char* and 
std::string), but Basic has several different types mixed together. MAPs want a 
fixed length fixed position string which may overlap other strings. Normal 
nasic strings are variable length and variable position. FIELD statements can 
change a string from one type to another. It gets quite complicated without 
writing the DEC string library, which is 

Re: [Simh] off-topic basic translator

[Ken Cornetet]

I don’t know how feasible this would be for VAX code, but this might work: 
write a converter/emulator that reads the relocatable object code for VAX basic 
(assuming you can get it – I don’t know how VAX software is distributed) and 
converts it to C code. You’d have to write wrappers that emulate VAX library 
routines using posix routines.

If it worked, you’d have a portable version of VAX basic.

I’ve been thinking about trying this with the OS that I use simh for – 
hp1000/RTE



From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of khandy21yo
Sent: Wednesday, August 05, 2015 8:33 PM
To: Dan Gahlinger; simh@trailing-edge.com
Subject: Re: [Simh] off-topic basic translator

Tgat looks like vt52 sewuence. To work on more terminal screens you might want 
to upgrade to ansii vt100 at leasr. Some terminals dont understand the vt52 
codes.


 Original message 
From Dan Gahlinger mailto:dgahl...@hotmail.com>>
Date: 08/05/2015 1:56 PM (GMT-07:00)
To simh@trailing-edge.com
Subject Re: [Simh] off-topic basic translator

Another issue I'm running into which should be fun, is VT escape sequences

eg:
170 PRINT ESC+"Y"+CHR$(53)+CHR$(33);\INPUT #1;"PRESS RETURN TO CONTINUE";A$

That puts the cursor at a specific place on screen,
these were built on VT-52 and VT-100 terminals with fixed screen size.
using Linux you can get ANSI support, but the screen could be a vastly 
different size,
of course, we can just make it run like normal.

the other problem is the escape sequences themselves may not work any more.
they seem to work in Linux with ANSI enabled,
will they work on Mac CLI (maybe) or DOS/Windows ? portability is important.

But, I'm not going to do a ton of work writing cursor routines for a dozen 
basic programs from the 80's.

and btw freepascal has incredible string handling for those doubters out 
there...

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

Re: [Simh] [Announce] Emacs 21.2 for VMS/VAX

[Ken Cornetet]

For many years, MicroEmacs was my favorite editor, and I still fire up the 
windows version on occasion when I need to do some complicated substitutions on 
text.

Sadly, Dan Lawrence, the author of MicroEmacs 4 passed away several years ago. 
No one picked up support for his version. MicroEmacs 3.8 was forked by an 
outfit called jasspa. It was improved and the license changed to GPL. I don't 
see VMS listed as supported, though.

As far a MicroEmacs not being good for coding, interesting bit of trivia: 
MicroEmacs was the only editor on Linus Torvalds' systems for a long time.

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of 
li...@openmailbox.org
Sent: Monday, February 1, 2016 2:52 AM
To: simh@trailing-edge.com
Subject: [Simh] [Announce] Emacs 21.2 for VMS/VAX

Hopefully the following information will be of some interest and value to 
people running VMS/VAX on SIMH.

Because of keyboard issues I found the native VMS editors to be difficult to 
use. I have been using Emacs for a long time on other platforms so I went 
looking for a copy to run on VMS/VAX but couldn't find a binary. I don't have 
the skills or tools to build Emacs from source on VMS/VAX.

I have been using MicroEmacs 4.0 which is stable and runs very well on a low 
spec SIMH host. However the features are minimal bordering on spartan.
It's not a very good editor for coding and seems to be relatively unsupported 
although old builds are available for VMS/VAX. An appeal for help on the 
post-fork MicroEmacs mailing list yielded thundering silence.

I brought up the issue on comp.os.mvs and one of the guys spent some time 
getting gnu Emacs 21.2 working. There were a few problems initially but he 
seems to have gotten it working. The performance on a low spec SIMH host is 
unacceptable but on a reasonably modern PC it works great.

With the permission of the developer who built and got it working, I am 
reposting the info from comp.os.vms here. Many thanks to hb  
for his generosity in making this available.

Any issues, discussion, etc. please follow up to comp.os.vms on usenet.

---
I uploaded emacs21_2_vax.zip to https://www.sendspace.com/file/byw8z7.
Feel free to announce it on any other mailing list and/or copy the zip archive 
to a VMS specific archive/repository.

--- 8< ---

This is the readme file of the emacs kit for VAX: emacs21_2_vax.zip.

GNU Emacs 21.2 for VAX/VMS

Contents of emacs21_2_vax.zip:

emacs21_2_vax.txt - this file
emacs-vax-bin.txt - how to use the binary kit emacs-vax-build.txt - how to 
build emacs from the sources emacs21_2_vax_bin.zip - the binary kit 
emacs21_2_vax_src.zip - VAX specific files for building emacs

The binary kit was built on V7.3 without support for TCPIP and X11:
$ @[-.emacs212_3]configure --with-tcpip=NO --with-x=NO --WITH-X-TOOLKIT=NO -
--prefix=bld_root:[LOCAL] --startupdir=bld_root:[LOCAL.STARTUP]

Building for any other configuration may require additional source code 
changes. The supplied VAX specific sources are not intended to be compiled on 
other VMS platforms. Some of the files may be seen as hacks to get emacs 
running on VAX/VMS. The base source code for emacs is not included in this kit. 
The base source code is a VMS version based on emacs version 21.2. The source 
code can be found on the OpenVMS freeware CD version V8.0: emacs/emacs21_2.zip. 
These sources are for building emacs for Alpha. This zip archive contains 
temporary files, which are not required for the build, as well as an Alpha 
executable image.
Unfortunately these sources were not found in the emacs git repository on 
savannah.gnu.org.

Please note, officially the support for VMS was removed in Emacs 23.
---

--
Please do not copy me on mailing list replies. I read the mailing list.
RSA 4096 fingerprint 7940 3F02 16D3 AFEE F2F8  ACAA 557C 4B36 98E4 4D49 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Ken Cornetet]

I think IBM chose the 8088 over the Motorola offerings because it would be 
easier for software vendors to port their z80 CPM software to the 808x given 
the (mostly) same instruction set and the 808x segmented memory looked like a 
z80’s 64k memory space if you ignored the segment registers.

The 8088 was chosen over the 8086 because it was easier (and cheaper) to 
interface the then common 8 bit peripheral chips.

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Dave Wade
Sent: Tuesday, February 16, 2016 10:16 AM
To: 'Clem Cole'
Cc: 'SIMH'
Subject: Re: [Simh] VAX/VMS

I was deliberately ignoring the 67 (&47) as they were very much “specials”. I 
cut my teeth on the 360/67 at Newcastle Upon Type under MTS, (and OS/MVT) but 
MTS was never generally available, MVS and later won’t run on the 360/67, and 
TSS pretty much died a death. Even CP/47 and CP/67 had a major re-write to 
become VM/370… The 360/67 actually had 32 bit addressing rather than 31-bit 
that’s XA and S/390. Also as for comparison with the VAX on memory cabinet 
which I think had 64K Bytes is about the same size as a large VAX.

This is the Newcastle 360/67 with 512K of Core and the DAT gate open…

http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/slide07.jpg

and a close view of the core cabinet here:-

http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/21.html

I think it is also interesting to compare the Intel architecture which was 
designed to be economical with Silicon against the M6800, M6809 and the M68000 
which were designed to be programmer friendly, and of course note the 
similarities between the 68000 & S/360 with 16 general purpose registers and 
orthogonal instruction set) and wonder where we would be today had IBM chosen 
them for its PC rather than the 8086 which I assume was cheaper…

Dave
G4UGM

From: Clem Cole [mailto:cl...@ccc.com]
Sent: 16 February 2016 13:58
To: Dave Wade mailto:dave.g4...@gmail.com>>
Cc: SIMH mailto:simh@trailing-edge.com>>
Subject: Re: [Simh] VAX/VMS

Dave be careful --   S/360 Model 67 has VM in the late 1960's - TSS and it's 
brother MTS, both rely on it.   The 67 is a Model 65 with a  Data Address 
Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB which is in a 
cabinet that t'ed off the main CPU and is about the same size en entire Vax 780 
which would follow 10 years later.

Think about that for a minute -- an 8 word TLB.   At Intel we regularly examine 
the different sizes of the different parts of the memory system.  Core 7 (aka 
Nehalem of a few years ago) has a two-level TLB: the first level of TLB is 
shared between data and instructions. The level 1 data TLB now stores 64 
entries for small pages (4K) or 32 for large pages (2M/4M), while the level 1 
instruction TLB stores 128 entries for small pages (the same as with Core 2) 
and seven for large pages. The second level is a unified cache that can store 
up to 512 entries and operates only with small pages.

Also it is also interesting to consider that while the AT&T folks came off of 
Multics, a number of us university types that would work on earlier Unix came 
from TSS and MTS (one 360/67).   In fact, TSS is still the only system I ever 
used that lived in the debugger as your command system - which I always thought 
was a cool idea.


As for what started this thread.   I think it is interesting that the long term 
successful architectures in the market did have a excellent compatibility 
stories. IBM with system 360 certainly set a high bar, and DEC has nothing to 
be ashamed of, the different DEC lines, particularly the Vax, did a great job 
here.In truth, probably the best of pure compatibility story has to be 
Intel.  The H/L registers of the 4004 are still there ;-)   Seriously, the 
INTEL*64 is from an computer science standpoint, not an architecture you would 
create from scratch.   But Intel has completely understood the economics of SW 
compatibility.

Also, if you peeked inside a modern processor, you would discover they are 
dataflow engines and put together with all of the modern computer science; but 
there is about a 5% silicon tax paid for compatibility.  Clearly, my siblings 
at Intel believe it's worth tax and the customers seem to keep wanting it.

Clem

On Tue, Feb 16, 2016 at 8:15 AM, Dave Wade 
mailto:dave.g4...@gmail.com>> wrote:
> -Original Message-
> From: Simh 
> [mailto:simh-boun...@trailing-edge.com]
>  On Behalf Of Wilm
> Boerhout
> Sent: 16 February 2016 11:58
> To: simh@trailing-edge.com
> Subject: Re: [Simh] VAX/VMS
>
> Johnny Billquist schreef op 16-2-2016 om 12:49:
> >
> > No, it is not. Talk to IBM about S/360... :-) And there are some VAXen

S/360 compatibility is only forward, and only to a certain point. S/360 and 
S/370 are both 24-bit addressing and fairly compatible, but S/370 (Mostly) has 
Virtual Memory as standard.

Then came the "great divide" S/370XA. XA m

Re: [Simh] Zork for ITS [was: Klh10 vs Simh]

[Ken Cornetet]

I used the old “f2c” from Bell Labs to create MSDOS and unix binaries of  the 
old Mystery Mansion that ran on HP1000/RTE.

The nice thing was that since I had the source to f2c, I could modify it to 
handle the slightly irregular syntax of the source code (the only one of which 
I can remember off hand is that Mystery Mansion had nearly 100 continuation 
lines which made most compilers choke).

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Clem Cole
Sent: Monday, February 29, 2016 8:30 PM
To: Bob Supnik 
Cc: SIMH 
Subject: Re: [Simh] Zork for ITS [was: Klh10 vs Simh]


On Mon, Feb 29, 2016 at 4:49 PM, Bob Supnik 
mailto:b...@supnik.org>> wrote:
MDL sources for Dungeon are online here: 
http://simh.trailing-edge.com/games/zork-mdl.zip

/Bob

​Thanks Bob.  While its different then trying to get MDL run again, if you want 
to be a retro gamer -  I believe the Fortran version of Zork (called Dungeon), 
plus the the original Fortran Adventure sources are in the same directory:  
http://simh.trailing-edge.com/games/.   The Fortran versions are known to 
compile and run with the current Intel compiler - which to quote Rich Grove: 
"has a bunch of the DEC (Gem) compiler DNA ground up and injected into it."

I am under the impression that both Dungeon and Adventure are part of the Intel 
compiler test suite (as they were for the DEC compilers), so I suspect they 
will even run on on modern Mac's, Linux and Window's boxes if you set the FTN 
value in the makefile to point to fort (which you can get a free noncommercial 
license for if you poke around the Intel websites).

FYI: gfortran ​might work but I can not claim to have tried it, while I have 
personally run them both with ifort on my Mac to show my kids what computer 
games once looked like (I'm not sure if they were disgusted or amazed, but I 
did find when he was 16, my now 20 year, son playing adventure - i.e. it did 
suck him in - even he had been part of the Wii, Xbox and Nintendo generation.   
I think he was more impressed that I still had an adventure Map in a file 
cabinet that was created on computer printer paper.   That said, I'm not sure 
my daughter (a CS professional these days) was as entranced.

Clem

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

Re: [Simh] HP 3000 Terminals

[Ken Cornetet]

Interestingly, AICS research has abandoned QCTerm.

They have sent me the source code which is Visual Basic, I believe.

They have also sent me an email stating that I can do whatever I want including 
making it open source.

I know nothing about Visual Basic, or even doing GUI programming. Does anyone 
want to take over development, or better yet, port to a cross platform GUI 
framework?

QCTerm really needs to be archived somewhere - the hp1000 simulator is severely 
hamstrung without it.


-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of J. David Bryan
Sent: Thursday, March 10, 2016 10:54 PM
To: SIMH List 
Subject: Re: [Simh] HP 3000 Terminals

On Thursday, March 10, 2016 at 18:26, Michael Kerpan wrote:

> I'd be interested in knowing what kind of options are out there for 
> "real" HP terminal emulation.

I've used the following HP terminal emulators over the years:

 - QCTerm (Windows) by AICS
   http://www.hpmuseum.net/display_item.php?sw=585

 - AdvanceLink 2392 (DOS and Windows) by HP
   http://www.hpmuseum.net/display_item.php?sw=50
   http://www.hpmuseum.net/display_item.php?sw=178

 - Reflection (DOS and Windows) by Walker, Richer, and Quinn
   http://www.hpmuseum.net/display_item.php?sw=308

 - Crosstalk (Windows) by Attachmate

 - Session (Windows) by Tymlabs

All of the emulators, except QCTerm, were commercial products.  Reflection is 
probably the one that offered the most faithful emulation.  The others were 
close, but not perfect, reproductions of the hardware behavior.

(I used QCTerm while developing the simulator.)

  -- Dave

___
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] HP Terminal emulators, MSKermit with DosBox, CKermit 9 to the HP3000

[Ken Cornetet]

Wow, this is taking me WAY back, but IIRC, DOS would not do anything when the 
BREAK key was hit because DOS would not see it. It was trapped at the BIOS 
level and again, IIRC, it would freeze the text output to the screen until 
another key was pressed.

Keep in mind that DOS also doesn’t usually enter the picture with real serial 
port IO. The PC BIOS did have routines for handling the serial port, but since 
they weren’t UART interrupt based, they were useless for anything except 
driving a serial printer (output only), and being “shimmed” by some other code 
to provide a “virtual” serial port.

When dealing with an actual serial port, terminal emulators would talk directly 
to the UART for control and output, and they’d install their own hardware 
interrupt routine for receiving. They would not use any DOS or BIOS functions.

However many terminal emulators (and I’m pretty sure that MSKermit falls in 
this group) had an option to use the BIOS routines (int 14h) for communication 
if you had some sort of “shim” software hooked into int 14h to provide pseudo 
serial communication (like over telnet).

I don’t know how dosbox emulates serial IO, but I’m guessing it doesn’t present 
a virtualized UART to the software. Instead, it probably implements serial IO 
via the int 14h BIOS calls.

Sending a BREAK condition depended on OS and UART support. If the OS serial 
port driver didn’t support the notion of sending a BREAK, which (most?, some?, 
all?) unix didn’t, then the way to send a break was as Mr. Cole mentions – set 
the baud rate as low as possible and send the printable ASCII character that 
had the longest string of consecutive  zeros: the “@”.

Since the 8250 UART (and progeny – 16450, 16550, and super IO chips) had direct 
hardware capability for sending a BREAK condition, a terminal emulator using a 
real serial port would be able to send a BREAK condition by telling the UART to 
hold the transmit data line low for 250ms (I think that is the standard), and 
then telling the UART to return the transmit line to normal.

However, if a terminal emulator were using the int 14h BIOS routines, there’s 
no easy way to send a BREAK condition, so it probably wouldn’t. Or, it might 
try the low baud rate trick.

A terminal emulator would also need to trap the BREAK key and use it as a 
signal to send the BREAK condition.

So, in order for a terminal emulator to send a break under DOS, the following 
would have to be true:

1.   The emulator would have to trap the BREAK key at the BIOS level, or 
have some other key combination to send a BREAK.

2.   Dosbox would have to present a  virtualized UART to the emulator AND 
understand that seeing a certain combination of control bits being changed in 
the UART 250ms apart signaled a BREAK condition AND send the corresponding 
telnet command.

3.   Simh would have to catch the incoming telnet BREAK and convert it to a 
host BREAK condition.



From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Clem Cole
Sent: Wednesday, April 13, 2016 12:28 AM
To: Rodney Brown 
Cc: SIMH 
Subject: Re: [Simh] HP Terminal emulators, MSKermit with DosBox, CKermit 9 to 
the HP3000


On Tue, Apr 12, 2016 at 5:41 PM, Rodney Brown 
mailto:rdbr...@pacific.net.au>> wrote:
None of the terminal emulators could send a BREAK under DosBox. I think that a 
BREAK needs to be synthesized, so DosBox
recognizing the UART behavior and converting it into a Telnet Break command 
(RFC 854 (IAC, BRK == bytes 255, 243)) may be
challenging. Adding a DosBox keyboard command to send a Break when connected by 
Telnet should be easy.

​Hang on -- BREAK is not in the old USASCII ​7 bit map.   As explained in RFC 
854, it was a >>key<< on the old Teletype ASR33 (and the ATTEN key on the IBM 
2741).   What BREAK did was sent a very long (i.e. 1 second if I remember 
correctly) "marking" time signal.  Most UARTS were set up to recognize this as 
an "out of band" signal tell the OS to do something special.

You are correct that a number of OS, would use a >>combination<< of BREAK 
followed by some defined pattern to try to auto-detect the speed.   Sometimes 
when in auto detect, you just send t break repeatedly until what was being 
displayed on the screen matched something valid.

Anyway the problem is how to >>send<< a BREAK if its not a special key.   The 
standard way this has been handled it drop the BAUD rate to be as slow as 
possible (50 baud) and send an ASCII @  Assuming 50 baud is not being used, 
then it will look like a BREAK to the UART on the other side.   [Open up the 
code for UUCP's uucico program if you want an example of how this done -- 
Warren has the sources to V7 UNIX on his site]




One other question/thought.  I can not speak for DOSBOX, but I know VMware does 
supports sending a BREAK.   It will send a break from the host keyboard to the 
VM using the GUI.   That said, I know the issue you are caught with is you want 
the application AdvanceLink/Kermit et al, 

[Simh] Way out idea for simh

[Ken Cornetet]

A common theme on this list is how to get files copied between the host and the 
emulated machines. I have a crazy idea for a simh feature to help in that 
regard: Add an FTP server to simh that would write to a "universal" file system 
on a simh block device file (disk, tape, drum)  that the guest OS would have 
attached. You could fire up your favorite ftp client and copy files into and 
out of this file system.

Obviously, the guest OS would need to have tools written to read/write this 
universal file system, but with a simple enough file system, that wouldn't be a 
huge hurdle. I have to admit, outside of unix and RTE, I have no notion of how 
many operating systems that run on simh emulated machines allow direct disk 
access. I am assuming there is a way to do it on most all of them. If not, tape 
or drum could be an option.

For this "universal" file system, I nominate Hewlett-Packard's LIF. It is 
simple and well documented. A fixed flat directory at the beginning of the 
image, fixed size directory entries, and linear space allocation (no allocation 
tables).

I don't expect it would be trivial to add an FTP server to simh, but it could 
be handy. Just food for thought.

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

Re: [Simh] text from openvms

[Ken Cornetet]

I tried something like that using RTE Kermit under RTE-6/VM on the hp2100. I 
could never make it work reliably, and even when it did work, the performance 
was horrible.

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Dr Eberhard W 
Lisse
Sent: Wednesday, April 20, 2016 11:09 AM
To: ethan.di...@gmail.com; bill...@suddenlink.net
Cc: simh@trailing-edge.com
Subject: Re: [Simh] text from openvms

Posted this a while back to the kermit newsgroup:

[...]
So I downloaded CKV211-VAX-VMS73-NONET.EXE and put that in the ISO, fired up 
kermit on the netbook (I keep it an EVERY machine I ever
use!)  and ssh'ed to the localhost, fire up the simulator, log on, fire up 
CKV211-VAX-VMS73-NONET.EXE into servermode and Frank is your uncle :-)-O

At least for text files (for the time being) :-)-O [...]

Kermit always works!

el


On 2016-04-20 15:43, Ethan Dicks wrote:
> On Fri, Mar 25, 2016 at 9:16 PM, Bill Cunningham  
> wrote:
>> People tell me kermit in vms can be a pain.
> 
> We used Kermit on VMS everyday back in the 80s.  It was terrific.
> You do have to know how to use Kermit (the default option settings 
> aren't always the best choice) and you have to understand that files 
> on VMS are record-oriented not streams-of--bytes, so moving *binary* 
> files to/from VMS is not so trivial (EXEs aren't bad because they are 
> fixed-length 512-byte record and you can tell Kermit what you are up 
> to so you write the correct format on the VMS side, .OLB and other 
> types of random-length-record files aren't so easy - we used to wrap 
> binaries up in a text format that preserved the record-size meta-data 
> and send text files.  Kermit is superb at that).  It's not Kermit that 
> makes this "difficult", it's RMS on VMS that makes it more complicated 
> than files on UNIX or DOS or whatever else.  All heterogenous file 
> transfer techniques have the same hurdles.
> 
> So since your use-case is moving text in and out of VMS, Kermit is an 
> excellent choice that is not difficult to set up.
> 
> -ethan


-- 
Dr. Eberhard W. Lisse  \/ Obstetrician & Gynaecologist (Saar)
e...@lisse.na/ * |   Telephone: +264 81 124 6733 (cell)
PO Box 8421 \ /
Bachbrecht, Namibia ;/
___
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

[Ken Cornetet]

I think I wasn't clear on what I meant.

Simh would have an FTP server built in. In your simh control file, you'd attach 
a disk (or tape, or drum) and add an option that would make that block device 
available to the FTP server as a certain virtual directory name. A user id and 
password would also be specified.

An FTP client would connect to simh using the specified user/password and do a 
"cd" to the virtual directory name as specified in the attach options. The FTP 
client could then read, write, and erase files in the filesystem on that block 
device file.

Obviously, simh can't know how to read/write/erase files for every file system 
out there, so we'd need a very simple file system that would be simple to code 
for both simh and guest os applications. I like LIF because it is designed for 
pretty much exactly this. HP designed it as a way to transfer files across 
their various operating systems (and even  calculators).

It wouldn't have to be LIF - we could design our own from scratch if desired. 
But LIF is super simple and a user level utility could be coded up on pretty 
much any guest OS (well, any guest OS that allows block level access to 
devices).



From: Ken Cornetet
Sent: Wednesday, April 20, 2016 11:43 AM
To: simh@trailing-edge.com
Subject: Way out idea for simh

A common theme on this list is how to get files copied between the host and the 
emulated machines. I have a crazy idea for a simh feature to help in that 
regard: Add an FTP server to simh that would write to a "universal" file system 
on a simh block device file (disk, tape, drum)  that the guest OS would have 
attached. You could fire up your favorite ftp client and copy files into and 
out of this file system.

Obviously, the guest OS would need to have tools written to read/write this 
universal file system, but with a simple enough file system, that wouldn't be a 
huge hurdle. I have to admit, outside of unix and RTE, I have no notion of how 
many operating systems that run on simh emulated machines allow direct disk 
access. I am assuming there is a way to do it on most all of them. If not, tape 
or drum could be an option.

For this "universal" file system, I nominate Hewlett-Packard's LIF. It is 
simple and well documented. A fixed flat directory at the beginning of the 
image, fixed size directory entries, and linear space allocation (no allocation 
tables).

I don't expect it would be trivial to add an FTP server to simh, but it could 
be handy. Just food for thought.

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

Re: [Simh] Way out idea for simh

[Ken Cornetet]

Kermit cannot be made to work reliably on RTE-6/VM under simh. At least I was 
never able to make it work. Not to mention that trying to use an emulator other 
than QCTerm (which doesn't do Kermit) with RTE is a major PITA.

I used Kermit extensively on real RTE systems to transfer files to a variety of 
systems. 

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


> On 20 Apr 2016, at 19:58, Johnny Billquist  wrote:
> 
> I still find Kermit the most obvious, straight forward solution. Kermit 
> already exists for almost any platform we might talk about. It requires 
> minimal hardware. Runs in userland. And manages the translation of text files 
> based on the host system on each platform.

Kermit really does rock.

Considering spending 70 USD on that book that fully explains the scripting 
language etc..

Sampsa

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

Re: [Simh] Way out idea for simh

[Ken Cornetet]

You don't need the notion of mountable disk. The disk would appear attached to 
the guest OS 100% of the time.

The guest doesn't need to be able to mount foreign file systems. The guest OS 
only considers that block device as a seekable collection of blocks.  All file 
movement between the LIF block device and the OS's native file system would be 
by a userland  utility.

True, this utility would have to be developed for every guest OS running under 
simh, but if the file system was simple enough, the code would be trivial.

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of 
sky...@sky-visions.com
Sent: Wednesday, April 20, 2016 1:04 PM
To: paulkon...@comcast.net; sam...@mac.com
Cc: simh@trailing-edge.com
Subject: Re: [Simh] Way out idea for simh


Just to add some info to the discussion. This sounds like a nice idea,
however it will be very difficult to implement on some of the older
machines that SimH supports.

For example the B5500 does not have the concept of a mountable pack.
Drives could be attached, but they were a permanent attachment. For the
Ibm 7000 line, most did not support disk. The disk drive that was
supported by many of the machines was a large box that you could not
put drives into (IBM 1301/2301). Also these machines all worked in BCD
(6 bit), not Ascii. I am also not sure when TOPS10 got support for
mounting foreign file systems. I don't believe that 6.03 or 5.03
support this idea.

Tapes, paper tapes, and punch cards are probably the most universal
format. Also a Paper tape reader is pretty easy to implement, it might
be possible to put some kind of header onto the tape to indicate the
name of the file. But take a look at how much trouble Kermit does to
handle all the various systems.

Rich

--- Original Message ---
On 4/20/2016 12:14 PM Paul Koning wrote:


> On Apr 20, 2016, at 12:06 PM, Sampsa Laine wrote:

>

>

>> On 20 Apr 2016, at 19:02, Paul Koning wrote:

>>

>>>

>>

>> I don't know LIF, but the RT-11 file system is certainly simple.

>>

>> There are a couple of complications. First, you'd have to write a file 
>> access utility for each guest OS. Given a simple enough file system that 
>> isn't necessarily a huge burden. Then again, what might be simple, 
>> requiringly only modest code, on one machine might be a major burden on 
>> another simply because it has much less memory.

>>

>

> For DEC stuff, Files-11 (level 2?) would probably work across most of the 
> OSes.



No, it would work for VMS, and level 1 at least would work for RSX, but neither 
RSTS nor RT11 understand it. And it's a complex file system, more so than the 
RSTS one and vastly more than RT11. It does more, of course, but if you're 
looking for something that can easily be ported to another system, this won't 
do.



I took the proposal to mean: find a simple OS for which you can easily 
implement an application to handle it on most operating systems. So think 
something handled by an application like PDP-10 FLX (or RT-11 FLX), not a file 
system with native support.



> ...

>>

>> Paper tape is yet a third option, which is presumably unlabeled but often 
>> transparent. (Not always, the 1620 comes to mind as a notorious example of a 
>> machine that could read only coded tape with punches conforming to the code 
>> it expects.)

>

> That's a good point but doesn't make organising files trivial.



One key question is how important it is to transfer a bunch of files all at 
once. Is it sufficient to send one file at a time? With scripting, that may not 
be all that problematic.



paul





___

Simh mailing list

Simh@trailing-edge.com

http://mailman.trailing-edge.com/mailman/listinfo/simh

==
Richard Cornwell
sky...@sky-visions.com
http://sky-visions.com
==
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

[Ken Cornetet]

This is a great mechanism, but it requires that the guest OS have some native 
support (or be modified to support) some sort of device where you can pass a 
file name and then read and write data.

I actually plan to implement just such a beast on the hp2100. The plan is to 
create a  custom microcode instruction that will take operands describing the 
desired host operation perform the appropriate action. Operations would include 
file operations (wild card globbing, reads, writes) and possibly even socket 
operations. 

It would be lovely if this sort of mechanism could be worked into simh in 
general, but given the wildly different ways this would have to grafted into 
each emulated machine's archetechture, I can't really see it happening.

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

I say forget the FTP server, create a device which can access a directory on 
the host OS via a special device and then code file transfer utilities for each 
OS that needs it, like the SIMH Altair + CP/M thing..

Sampsa


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

Re: [Simh] Way out idea for simh

[Ken Cornetet]

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

Re: [Simh] Way out idea for simh

[Ken Cornetet]

Other than the OS on the old Atari 800 family of computers, I don’t know of any 
OS that supports a device to which you can supply a file name and then read or 
write data.

Most OSes view disk devices as a collection of blocks.

From: Sampsa Laine [mailto:sam...@mac.com]
Sent: Wednesday, April 20, 2016 1:37 PM
To: Ken Cornetet 
Cc: simh@trailing-edge.com
Subject: Re: [Simh] Way out idea for simh


On 20 Apr 2016, at 20:26, Ken Cornetet 
mailto:ken.corne...@kimballelectronics.com>>
 wrote:

Kermit is  not available/usable for every guest OS under simh.


Fair enough.


I do not understand what you mean by a block device that points at a directory 
on the host OS.

OK, so instead of an FTP server, you have a special device that a guest OS 
program can use to access the host OS.

Let’s call this device HOST0: and you’d have something like this is in the .ini 
file:

attach HOST0: /home/foobar/simhdir

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

Re: [Simh] Way out idea for simh

[Ken Cornetet]

I readily admit that I know nothing about the OSes that run under simh except 
RTE and unix. If a machine doesn't have support for a randomly accessible block 
device without a native file system, then this scheme wouldn't be usable.

But I'm guessing most simh OSes support either raw disks or seekable tapes, and 
either would work.


From: sky...@sky-visions.com [mailto:sky...@sky-visions.com]
Sent: Wednesday, April 20, 2016 1:49 PM
To: Ken Cornetet ; sky...@sky-visions.com; 
paulkon...@comcast.net; sam...@mac.com
Cc: simh@trailing-edge.com
Subject: RE: RE: [Simh] Way out idea for simh


I think you are missing something. For the B5500 the drives are all one file 
system. If you add a drive, it becomes part of the file system. Also there is 
no way to access the drives in a raw way. For the I7000 series there is no 
concept of a file system to speak of. Similar for CDC 6600 for anything prior 
to Scope 3.4, the drives are all one big file system.

 Rich

--- Original Message --- On 4/20/2016 1:20 PM Ken Cornetet wrote:

You don't need the notion of mountable disk. The disk would appear attached to 
the guest OS 100% of the time.



The guest doesn't need to be able to mount foreign file systems. The guest OS 
only considers that block device as a seekable collection of blocks.  All file 
movement between the LIF block device and the OS's native file system would be 
by a userland  utility.



True, this utility would have to be developed for every guest OS running under 
simh, but if the file system was simple enough, the code would be trivial.



From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of 
sky...@sky-visions.com<mailto:sky...@sky-visions.com>
Sent: Wednesday, April 20, 2016 1:04 PM
To: paulkon...@comcast.net<mailto:paulkon...@comcast.net>; 
sam...@mac.com<mailto:sam...@mac.com>
Cc: simh@trailing-edge.com<mailto:simh@trailing-edge.com>
Subject: Re: [Simh] Way out idea for simh



Just to add some info to the discussion. This sounds like a nice idea,
however it will be very difficult to implement on some of the older
machines that SimH supports.

For example the B5500 does not have the concept of a mountable pack.
Drives could be attached, but they were a permanent attachment. For the
Ibm 7000 line, most did not support disk. The disk drive that was
supported by many of the machines was a large box that you could not
put drives into (IBM 1301/2301). Also these machines all worked in BCD
(6 bit), not Ascii. I am also not sure when TOPS10 got support for
mounting foreign file systems. I don't believe that 6.03 or 5.03
support this idea.

Tapes, paper tapes, and punch cards are probably the most universal
format. Also a Paper tape reader is pretty easy to implement, it might
be possible to put some kind of header onto the tape to indicate the
name of the file. But take a look at how much trouble Kermit does to
handle all the various systems.

Rich

--- Original Message ---
On 4/20/2016 12:14 PM Paul Koning wrote:


> On Apr 20, 2016, at 12:06 PM, Sampsa Laine wrote:

>

>

>> On 20 Apr 2016, at 19:02, Paul Koning wrote:

>>

>>>

>>

>> I don't know LIF, but the RT-11 file system is certainly simple.

>>

>> There are a couple of complications. First, you'd have to write a file 
>> access utility for each guest OS. Given a simple enough file system that 
>> isn't necessarily a huge burden. Then again, what might be simple, 
>> requiringly only modest code, on one machine might be a major burden on 
>> another simply because it has much less memory.

>>

>

> For DEC stuff, Files-11 (level 2?) would probably work across most of the 
> OSes.



No, it would work for VMS, and level 1 at least would work for RSX, but neither 
RSTS nor RT11 understand it. And it's a complex file system, more so than the 
RSTS one and vastly more than RT11. It does more, of course, but if you're 
looking for something that can easily be ported to another system, this won't 
do.



I took the proposal to mean: find a simple OS for which you can easily 
implement an application to handle it on most operating systems. So think 
something handled by an application like PDP-10 FLX (or RT-11 FLX), not a file 
system with native support.



> ...

>>

>> Paper tape is yet a third option, which is presumably unlabeled but often 
>> transparent. (Not always, the 1620 comes to mind as a notorious example of a 
>> machine that could read only coded tape with punches conforming to the code 
>> it expects.)

>

> That's a good point but doesn't make organising files trivial.



One key question is how important it is to transfer a bunch of files all at 
once. Is it sufficient to send one file at a time? With scripting

Re: [Simh] Way out idea for simh

[Ken Cornetet]

That “some kind of transfer utility” is exactly what I’m trying to implement.

In order to transfer files between a guest and host you need some sort of 
shared medium.

In the realm of simh hosted OSes, there are basically 3 forms of bidirectional 
io devices: paper tape, mag tape, and disk. Paper tape isn’t seekable, so it 
isn’t really suitable.

That leaves mag tape and disk as the only shared medium that is supported by 
the guest OS.

So the next question is, how do you implement a file transfer utility using 
shared tape or disk, and that’s exactly what I’ve proposed.

There is another option which can be used: modify the guest machine virtual 
architecture to implement a new data mechanism, and to the modify guest OS to 
support it. This has the advantage that it is more flexible and more powerful, 
but has the disadvantage of requiring not so trivial modifications of the guest 
emulation and modification to the guest OS. Additionally, since emulated 
machines have vastly different architectures, this would be difficult to 
generalize and integrate into simh as a whole.

I eventually plan to do exactly this on the hp2100 emulator by writing custom 
microcode (creating new instructions essentially) and writing an RTE driver so 
that userland applications can access it . However, the mods I make for the 
2100 emulator will not be anywhere close to being usable on other architectures.

That’s the beauty of using the disk file as the shared medium – you modify simh 
once, and you get the ability to use that mechanism on every simh OS that knows 
how to handle raw disks or seekable tapes. You do have to write a small LIF 
interchange utility, but that shouldn’t be too bad.





From: Sampsa Laine [mailto:sam...@mac.com]
Sent: Wednesday, April 20, 2016 2:01 PM
To: Ken Cornetet 
Cc: simh@trailing-edge.com
Subject: Re: [Simh] Way out idea for simh


On 20 Apr 2016, at 20:45, Ken Cornetet 
mailto:ken.corne...@kimballelectronics.com>>
 wrote:

Other than the OS on the old Atari 800 family of computers, I don’t know of any 
OS that supports a device to which you can supply a file name and then read or 
write data.

Most OSes view disk devices as a collection of blocks.


You’re missing my point - the guest OS would not be mounting this as a block 
device, but would have some kind of file transfer utility to talk to the host 
OS’s file system.

Sampsa



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

Re: [Simh] Way out idea for simh

[Ken Cornetet]

Well, I did say it was a wild idea...

But on the other hand, I haven't heard any better suggestions. And the only 
problems are:
1. Not all OSes support raw disk access or seekable mag tape.
2. A small LIF transfer utility will have to be written for each OS.

If anyone has better ideas for file transfers, to quote Ross Perot: "I'm all 
ears"

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

On 2016-04-20 19:51, Armistead, Jason  . wrote:
> 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).

No, you definitely have a point. But yes, if people plan to write a separate 
application to access this device, then you worry about system caching of data 
does not apply.

But I still do not think that writing such a program for every platform (or 
even a noticeable number of them) is going to happen. Essentially I consider 
this whole thread to be a lot of hot air.

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

Right.

Now, do people want to transfer some information, or are we going to continue 
this mad idea all night?

Johnny
___
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

[Ken Cornetet]

Again, you don't need OS support for foreign file systems, you just need to be 
able to read the disk blocks in a raw mode.

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

> Date: Wed, 20 Apr 2016 17:04:18 +
> From: sky...@sky-visions.com

> For example the B5500 does not have the concept of a mountable pack.
> Drives could be attached, but they were a permanent attachment. For 
> the Ibm 7000 line, most did not support disk. The disk drive that was 
> supported by many of the machines was a large box that you could not 
> put drives into (IBM 1301/2301). Also these machines all worked in BCD
> (6 bit), not Ascii.

> I am also not sure when TOPS10 got support for mounting foreign file 
> systems. I don't believe that 6.03 or 5.03 support this idea.

As of 7.05 (the very last maintenance release, from 1990) it still hadn't.
I work with it daily.

Rich 
___
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

[Ken Cornetet]

Sigh…

No, no file system emulators needed.

The block device would be in HP LIF format. SImh would understand LIF on the 
host side, and a LIF transfer utility would handle LIF on the guest side.

From: Sampsa Laine [mailto:sam...@mac.com]
Sent: Wednesday, April 20, 2016 3:20 PM
To: Ken Cornetet ; simh@trailing-edge.com
Subject: Re: [Simh] Way out idea for simh


On 20 Apr 2016, at 22:03, Ken Cornetet 
mailto:ken.corne...@kimballelectronics.com>>
 wrote:

That is a great mechanism. But it has the HUGE disadvantage that it is very 
specific to the Altair emulator. It can’t be generalized to that it can be 
easily applied to all simh machines. And it requires (probably) guest OS 
modifications. And it still requires a user-land utility.


I’m just saying that if you extend this mechanism to those systems that do 
_NOT_ support Kermit, this mechanism could be a replacement for Kermit (with a 
userland file transfer tool for the guest OS), allowing you to easily transfer 
files back and forth between the guest and host.

For the systems that DO support Kermit, there’s really no need for the 
mechanism.

If you want to go the block device route, you’d have to write file system 
emulators for every OS to get the FTP server to work..

Sampsa


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

[Simh] Way out idea for simh

[Ken Cornetet]

Actually, here's an alternate way to allow easy file transfers. I'm starting to 
think this is a much better idea.

Create a new device for simh that is identical to a paper tape punch/reader 
except If the guest OS writes a magic string, the next character after the 
magic string is a command, and the following characters up to a newline are a 
file name.

>From that point on, guest writes to the punch would write to the given file, 
>and reads from the reader would read from the given file.

The command character would be "t" for open the file in text mode, "b" for open 
in binary mode, and "c" for close.

As an extension, if the file name contains shell wildcard characters, simh 
would return the matching file names when the guest reads the tape reader.

If the simh guest doesn't support paper tape, then the device could be mapped 
to some other sort of simple IO device (like a serial port).

Again, perhaps not all simh machines could make use of this, but many could.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

[Ken Cornetet]

I guess I need to shout this:

*** KERMIT DOES NOT WORK ON SIMH EMULATED RTE-6/VM 

Kermit does not exist (and probably couldn’t feasibly exist) on any earlier 
versions of RTE.

Also, people keep reminding me that some simh guest OSes  don’t’ have the 
ability to read raw disks. Well, I’d venture to say that even more simh guest 
OSes lack a working Kermit.

Even if Kermit does exist for a guest OS, you may not have a binary available, 
nor the compiler needed to compile it.

Yes, Kermit is wonderful. I used it extensively in the days when I worked on a 
real RTE system. Unfortunately, it is not a generally useful option for simh 
users. The fact that much of the traffic on this list is “how do I get files in 
and out of guests” is pretty well proof of that.

What I’m trying to do is come up with something that would be relatively easy 
to implement in simh, and be useful in as many of the emulated machines as 
possible.






From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Kevin Handy
Sent: Wednesday, April 20, 2016 3:58 PM
To: Paul Koning 
Cc: simh@trailing-edge.com
Subject: Re: [Simh] Way out idea for simh

I think you are trying to over-engineer this file transfer stuff.
Instead of creating new devices for the transfer to operate over, why not use 
something that already exists on most of the simulators, like a serial port.
 Instead of building all this code into simh to convert from one disk file
 format to another. inside the simulator, use a progrm attached to the serial 
port which handles the hosts file access. You will still need a program on the 
simulated system to handle it's side of the transfers. W can give the whole 
setup a common name, like "kermit".
Most of this stream just seems to me to re-inenting Kermit in one way or 
another. It might be fun/interesting but doesn't seem to gain anything beyond 
what Kermit already does.
All this stuff has been hashed over many times when the hardware was actually 
in use, and solutions were devised then to handle the
numerous problems. Creating new interfaces, new instructions, etc. and 
modifying OS's just to re-implement kermit in another way seems to be a lot of 
overkill to me., but most of these messages seem to have no advantages to just 
using existing kermit capabilities.
If you want shares access the host filesystem, look to 'nfs'. If the emulated 
system doesn't already have shared filesystem already, you are probably going 
to be fighting such things as the disk caching code. File system corruption is 
very likely to occur.
A lot of the simulated OS's have more basic problems that just making the raw 
data available to the host OS. VMS doesn't store anything, including text 
files, in a "stream of byte" form. Others have 6 or 9-bit bytes. Then there is 
ASCII (multiple variants) EBCDIC (multiple variants), BAUDOUT, etc.

I think it would be more advantageous to write disk image manipulation routines 
to insert/extract files to the simulated disk images (while simulator is not 
running).

On Wed, Apr 20, 2016 at 1:14 PM, Paul Koning 
mailto:paulkon...@comcast.net>> wrote:

> On Apr 20, 2016, at 3:08 PM, 
> sky...@sky-visions.com wrote:
>
> OS's don't support foreign file systems. What they do is provide the ability 
> to access a drive that does not have what they believe to be a valid file 
> system.

Not necessarily.  RSTS does in the latest versions, but not in early versions.  
For example, RSTS V4A has no raw disk API, and gives you no access to any disk 
except via the RSTS file system.  The same goes for some other operating 
systems; I don't know of raw disk access on CDC NOS either, for example.  
(Well, not unless you write a PPU program; if you don't mind doing that, the 
job is easy.)

paul


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

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

Re: [Simh] Way out idea for simh

[Ken Cornetet]

Because in operating systems earlier than RTE-6/VM, code had to fit in a couple 
dozen kbytes of address space.

You could create what are called "segments" which were kind of like dynamically 
loaded subroutines, but there were many coding issues using those.

Even in RTE-6/VM where you had a whopping 62k bytes of address space, the 
auther of RTE Kermit had to resort to segments, and some ugly hacks to get it 
shoehorned in.

Yes, in theory, a very simple Kermit might be able to be written, but it would 
probably have to be written in assembly, and it would have to be limited to ONE 
version of serial IO hardware, and ONE version of the firmware on that serial 
IO mux, and ONE version of the RTE driver (serial IO was an absolute nightmare 
in RTE).

HP intended serial IO for one purpose and one purpose only - to talk to an HP 
terminal. I think they intentionally made it byzantine to dissuade users from 
connecting non-HP devices to RTE systems.

Even if you got it to work, there is only one usable terminal emulator that I 
know of for RTE that I know of (QCTerm) and it does not support Kermit. RTE 
*really* wants you using an HP terminal. Trying to use any other terminal type 
is an exercise in frustration.

And on top of that, you'd have to hope that all of the possible combinations of 
serial IO settings on the RTE side are mapped to the right telnet options, and 
that there aren't any bugs or limitations in said implementation.

Just because Kermit works on one or two simh guest OSes, I wouldn't extend that 
as proof that the serial-to-telnet mapping is robust enough to handle all guest 
OSes.

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

Ken.Cornetet wrote:
> I guess I need to shout this:
> *** KERMIT DOES NOT WORK ON SIMH EMULATED RTE-6/VM 

Why not?

> Kermit does not exist (and probably couldn't feasibly exist) on any earlier 
> versions of RTE.

Again, why not?

Having just written a new shell for PDP-7 UNIX (because the original could not 
be found), I can't imagine much other than a lack of something resembling a 
serial console that would prevent _some_ version/subset of KERMIT (or something 
similar like X or ZMODEM) from being cobbled together.

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

Re: [Simh] Way out idea for simh

[Ken Cornetet]

I’d take issue with your statement that the Kermit protocol isn’t complicated. 
The base protocol isn’t, but when you throw in all of the extras, it becomes 
extremely complicated.

Can you write a Kermit with only the simple stuff? In theory, yes. In practice, 
not so much. Many Kermit implementations make bad assumptions about what’s 
available on the other end.

Now add to that the complexity of serial IO programming. I’ve heard a lot of 
people piss and moan about how bad serial port programming is under unix, but 
under RTE it was a nightmare. I suspect other minicomputer OSes were the same 
way.

Trust me, I’ve been there. I tried writing a Kermit implementation on RTE 30 
years ago. I eventually gave up because of the complexity and the 
mind-numbingly difficult task of getting RTE to do what you want with a serial 
port. Someone did eventually get one written, and I used it extensively, but I 
guarantee you he put a *lot* of time into it.

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of khandy21yo
Sent: Wednesday, April 20, 2016 4:51 PM
To: Sampsa Laine ; Phil Budne ; 
simh@trailing-edge.com
Subject: Re: [Simh] Way out idea for simh

The Kermit protocol isn't very comp,icated, is well documented, and has a lot 
of testing behind it.

What happens in your protocol with characters that devices between you and the 
simulator mangle. Modems were a major frustration, now you have all sorts of  
effort devices may do funny things with certain   haracters. Send the wrong 
characters and it could disconnect.

We've been through this before, why not make use of that experience.



Sent from my Galaxy Tab® A
 Original message 
From: Sampsa Laine mailto:sam...@mac.com>>
Date: 04/20/2016 2:35 PM (GMT-07:00)
To: Phil Budne mailto:p...@ultimate.com>>, 
"simh@trailing-edge.com" 
mailto:Simh@trailing-edge.com>>
Subject: Re: [Simh] Way out idea for simh


> On 20 Apr 2016, at 23:25, Phil Budne 
> mailto:p...@ultimate.com>> wrote:
>
> Ken.Cornetet wrote:
>> I guess I need to shout this:
>> *** KERMIT DOES NOT WORK ON SIMH EMULATED RTE-6/VM 
>
> Why not?
>
>> Kermit does not exist (and probably couldn't feasibly exist) on any earlier 
>> versions of RTE.
>
> Again, why not?
>
> Having just written a new shell for PDP-7 UNIX (because the original
> could not be found), I can't imagine much other than a lack of
> something resembling a serial console that would prevent _some_
> version/subset of KERMIT (or something similar like X or ZMODEM) from
> being cobbled together.
>

And since the connection can be assumed to be lossless, the protocol could be 
really simple, e.g. something like this:

G=Guest, H=Host

Example of a write operation..

G: WRITE-FILE
H: ACK
// Now we send the file structure / word size etc
G: FILE-META-DATA
G: 
H: ACK
G: FILE-DATA
G: 
G: ACK

Done.


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

[Ken Cornetet]

This is a long post, so I'll ask everyone to read it carefully before you start 
formulating your response to tell me I'm an idiot  (I don't need you to tell me 
this - my wife reminds me on a regular basis).

I'd like to ask everyone to back up a bit and look at the problem: how to get 
files into and out of simh guest OSes. Today's simh users are in one of four 
camps


1.   If you are running Altair, you use the host integration IO (does this 
feature have an official name?).

2.   If you are running a guest OS that supports networking, and you can 
get simh networking set up on your host (apparently not trivial) great, you use 
the network.

3.   If you have a working Kermit, you connect to a Kermit server via the 
serial port/telnet wedge, and you are off to the races.

4.   If you lack any of those, you are stuck with these options:

A.  Paper tape

B.  Mag tape

C.  Line printer

D.  Cut-and-paste

E.   Cracking the native file system with a host utility

F.   Find or write a Kermit

G. Implement Altair style host IO in your emulator

Before I go any further, I'd like to mention metadata and binary file 
transfers. Yes, metadata and the notion of binary files complicates file 
transfers tremendously. Even text transfers have EOL issues. That has always 
been a thorn, and always will. Let's set it aside for a bit.

Next, I'd like to share a little story. My grandfather used a reel type mower 
to mow his half-acre lawn the whole time he owned the house because that is 
what was available to him when he bought the house and for several years 
afterward. When my father inherited the house, it became my responsibility to 
mow this lawn. My father told me that since grandpa had successfully mowed the 
lawn with a reel mower for years, it was good enough for me. I immediately went 
and used my hard earned money to buy a power mower.

So, if you are the type to tell me that a reel mower is good enough because 
that's what grandpa used, you can probably stop reading now.

Ok, back to transfer mechanisms.

If you are in camps 1,2, or 3 above. You are covered. If you are in camp 4, 
let's look at what we have, and where we might go:

Paper tape, mag tape, line printer: These are workable, but far from 
convenient. You have to continually break the emulator and attach your source 
or destination files, then go back to the guest and issue the IO commands. Does 
it work? Yes. Is it a royal PITA? Yes.  This is the method I use when working 
with RTE, and it is a pain. In fact, I'd say this is the biggest reason I don't 
play with RTE any more than I do.

Kermit - Kermit is great, if you can get it (or write it) and compile it. And 
that is assuming your OS and machine can handle the requirements. Remember 
though,  not every simh user is a programmer, and even if they are, they may 
not know the language and architectural  quirks of the guest OS. RTE is a good 
example - even if you are an expert FORTRAN or Pascal programmer, you aren't 
going to write a Kermit for it because of the quirks of RTE in general, and 
specifically the bizarre way RTE deals with serial ports. More on Kermit later.

A host utility to crack to native file system. I know a few exist for some of 
the simh OSes.  I've written one for RTE. While better than the mag tape tango, 
it still has limitations. Even a simple real life file system is complex to 
code for. FMGR disks under RTE can be pretty simple. It is well documented. It 
still took me 1200 lines of C code and probably 100 hours just to write it. I 
still haven't tested it extensively. By the time it is done, it will have been 
a fairly extensive project, and it only benefits one guest OS.

Aside from the implementation difficulty,  you can't copy files in with the 
disk online to the guest OS, so copying files in still requires a bit of a 
shuffle. Under RTE, I have to dismount the disc LU, copy a file in, then mount 
the disc. If a guest OS doesn't support the notion of dismounting disks, you'd 
have to shut it down for every copy in. And again, not every simh user is a 
programmer, and even the ones who are may not have the skill set required to 
write code that can manipulate a file system that probably isn't documented.

So that leaves camp 4 users with a reel mower.  For the types who might argue 
that if the reel mower was good enough for grandpa, it's  good enough for us, 
I'd like to point out that file transfers are probably the number two most 
popular subject on the simh mailing list (number one would be DEC trivia). 
Clearly, there is interest in something better. The question is what can be 
done to help the simh users who are stuck with the paper or mag tape shuffle to 
transfer files?

>From an end user point of view, the best option would be to implement some 
>sort of direct host IO similar to the Altair emulator. While this provides a 
>great amount of flexibility, it has the disadvantage that it is highly 
>dependent on

Re: [Simh] So far unnamed project

[Ken Cornetet]

I can supply you a complete “kit” for running the last version of RTE-6/VM on 
the simh hp2100 emulator. Takes all the “fun” out of putting such a system 
together, but for someone who just wants to see what a real RTE-6 system was 
like, it works perfect.

I also have the HP user group contributed software library that I can include, 
but it would add quite a bit to the storage required.

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Ray Jewhurst
Sent: Tuesday, May 31, 2016 12:09 PM
To: simh 
Subject: [Simh] So far unnamed project


Greetings all

I am a total computer history buff.  I have  only used "real" PCs and Macs, but 
through simulation and emulation I have grown to be enamored with many 
different types of old computers especially DECs.  I would love to spread my 
enthusiasm to the younger generation and I feel that Simh may be one of the 
ways to accomplish this. What I would like to do is package various simulators 
with pre-built configurations and documentation to show how these old machines 
work. I would like to ask all of you for advice and suggestions to help teach 
the younger generation how elegantly things used to be done.

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

Re: [Simh] slightly off-topic where can I find the Compaq basic translator?

[Ken Cornetet]

I think I have a copy of gw-basic saved somewhere. I’ll see if I can dig it up.

But, I don’t understand how any of the MSDOS flavors of BASIC are going to help 
you with vax basic code.

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Dan Gahlinger
Sent: Wednesday, July 20, 2016 2:45 PM
To: simh@trailing-edge.com
Subject: [Simh] slightly off-topic where can I find the Compaq basic translator?

does anyone know where I can find the Compaq basic translator?
or have a copy they can let me use?

I have a ton of old vax basic code but every basic is different and trying to 
do it manually is a pain.

ultimately I'd like the code to run on Linux. in whatever language. there's a 
bunch of basics there too.

I don't care for visual basic. I loved the simple elegance of vax basic nothing 
since has come close. esp eg indexed files.

thanks

Dan



Sent from my Samsung Galaxy smartphone.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Idea for a Simh guide

[Ken Cornetet]

While you could probably get simh running using djgpp and MSDOS, you'd play 
hell trying to get networking. In theory, it would be possible to graft NDIS 
support into simh, but there probably aren't many modern NICs with real mode 
NDIS drivers.

I think you'd be better off building a simh "appliance" around a small linux 
distro. 

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Paul Koning
Sent: Wednesday, May 10, 2017 2:19 PM
To: Bob Eager 
Cc: simh@trailing-edge.com
Subject: Re: [Simh] Idea for a Simh guide


> On May 10, 2017, at 2:02 PM, Bob Eager  wrote:
> 
> I have a copy of the old Zortech C compiler, with a royalty free DOS 
> extender.

Another option would be DJGPP, which has the advantage of being GCC so SIMH 
should be comfortable with it.  I've used it in the past for Unix-origin 
programs with good success.

paul

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

[Simh] off topic, but many of you might find this interesting

[Ken Cornetet]

Seeing people on the list wax nostalgic over unixes (unixen? Unixi?)  long past 
got me to thinking about my first home unix: Microport system 5/AT. It was 
fairly impressive for the day - real, honest to God system 5 release 2 unix 
that would run on a PC/AT (80286) machine. I ran this at home from sometime in 
the late 80s until I bought a Slackware linux CD sometime in the early 90s. 
Uucp email, anyone?

I did some research on Microport System5/AT and saw where a few people had 
attempted to get it running under various emulation platforms with no complete 
success until one of the developers of VirtualBox got involved and added 
support for it into VirtualBox. I found another user who had managed to get it 
running in VirtualBox by manually specifying disk geometry into System V/AT's 
fdisk, but it wasn't entirely clear what he'd done.

Having luckily had the foresight to create image files of my install disks all 
those years ago, I managed to get it up and running. Unfortunately, one of my 
floppy images was corrupt, but fortunately it was the text processing options, 
which isn't all that interesting.

So anyway, if any of you unix archeologists are interested in Microport System 
V/AT, let me know and I'll get you the install floppy images and details of how 
to configure the disk geometry.


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

Re: [Simh] Crowther's Adventure game

[Ken Cornetet]

I have vague recollections that FORMAT(/) prints a new line

Format(20A5) takes 20 elements of an array and prints them as character stings 
padded to a width of 5 characters.

"TYPE" is not standard fortran. That must have been a DEC extension. Standard 
fortran would have used "write".

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Lars Brinkhoff
Sent: Friday, February 2, 2018 3:41 AM
To: Dave L 
Cc: simh@trailing-edge.com
Subject: Re: [Simh] Crowther's Adventure game

Dave L wrote:
> Been a long time since I wrote fortran but IIRC the first character on 
> the output line was to perform carriage-control of the LPT, so you'd 
> have to always have a leading pad character such as a space in order 
> to get the output lines to be correct. Some characters were reserved 
> actions, 1 = FF from memory. I've not looked at the code involved but 
> that'd be my first thoughts

Thanks.  Since the SPEAK subroutine is only a few lines, I'll post it here.  
Maybe someone hows how TYPE, FORMAT(20A5), and FORMAT(/) work.



SUBROUTINE SPEAK(IT)
IMPLICIT INTEGER(A-Z)
COMMON RTEXT,LLINE
DIMENSION RTEXT(100),LLINE(1000,22)

KKT=RTEXT(IT)
IF(KKT.EQ.0)RETURN
999 TYPE 998, (LLINE(KKT,JJT),JJT=3,LLINE(KKT,2))
998 FORMAT(20A5)
KKT=KKT+1
IF(LLINE(KKT-1,1).NE.0)GOTO 999
997 TYPE 996
996 FORMAT(/)
RETURN
END
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Crowther's Adventure game

[Ken Cornetet]

Given the lack of a carriage control character in “FORMAT(20A5)”, I’m guessing 
that TYPE was like write, except it was terminal oriented so it didn’t use 
carriage control.

Also, given the FORMAT(/), I’ll also hazard a guess that TYPE did not 
automatically add a new line on whatever was printed. But that is just a guess.

From: Clem Cole [mailto:cl...@ccc.com]
Sent: Friday, February 2, 2018 9:46 AM
To: Ken Cornetet 
Cc: simh@trailing-edge.com
Subject: Re: [Simh] Crowther's Adventure game



On Fri, Feb 2, 2018 at 9:12 AM, Ken Cornetet 
mailto:ken.corne...@kimballelectronics.com>>
 wrote:
I have vague recollections that FORMAT(/) prints a new line
​Sounds right - I'm O-O-O, but I​'ll try to verify with the compiler folks when 
I'm on the office again.

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


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



-Original Message-
From: Simh 
[mailto:simh-boun...@trailing-edge.com<mailto:simh-boun...@trailing-edge.com>] 
On Behalf Of Lars Brinkhoff
Sent: Friday, February 2, 2018 3:41 AM
To: Dave L mailto:davel@googlemail.com>>
Cc: simh@trailing-edge.com<mailto:simh@trailing-edge.com>
Subject: Re: [Simh] Crowther's Adventure game

Dave L wrote:
> Been a long time since I wrote fortran but IIRC the first character on
> the output line was to perform carriage-control of the LPT, so you'd
> have to always have a leading pad character such as a space in order
> to get the output lines to be correct. Some characters were reserved
> actions, 1 = FF from memory. I've not looked at the code involved but
> that'd be my first thoughts

Thanks.  Since the SPEAK subroutine is only a few lines, I'll post it here.  
Maybe someone hows how TYPE, FORMAT(20A5), and FORMAT(/) work.



SUBROUTINE SPEAK(IT)
IMPLICIT INTEGER(A-Z)
COMMON RTEXT,LLINE
DIMENSION RTEXT(100),LLINE(1000,22)

KKT=RTEXT(IT)
IF(KKT.EQ.0)RETURN
999 TYPE 998, (LLINE(KKT,JJT),JJT=3,LLINE(KKT,2))
998 FORMAT(20A5)
KKT=KKT+1
IF(LLINE(KKT-1,1).NE.0)GOTO 999
997 TYPE 996
996 FORMAT(/)
RETURN
END
___
Simh mailing list
Simh@trailing-edge.com<mailto:Simh@trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com<mailto:Simh@trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh

[https://mailfoogae.appspot.com/t?sender=aY2xlbWNAY2NjLmNvbQ%3D%3D&type=zerocontent&guid=6c7e30c9-8bbe-42d0-849b-32a107cc6c3b]ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Crowther's Adventure game

[Ken Cornetet]

You might be right. I've long ago mostly forgotten the nightmare that was 
FORTRAN carriage control, and the FORTRAN formatter in general.


-Original Message-
From: Paul Koning [mailto:paulkon...@comcast.net] 
Sent: Friday, February 2, 2018 2:39 PM
To: Lars Brinkhoff 
Cc: Ken Cornetet ; simh@trailing-edge.com
Subject: Re: [Simh] Crowther's Adventure game



> On Feb 2, 2018, at 2:26 PM, Lars Brinkhoff  wrote:
> 
> Ken Cornetet wrote:
> ...
>> Also, given the FORMAT(/), I’ll also hazard a guess that TYPE did not 
>> automatically add a new line on whatever was printed. But that is 
>> just a guess.
> 
> I think your guess is correct.

I'm not so sure.  It may be a case of ensuring the carriage is at the left 
margin -- remember that Fortran carriage control would insert a line feed at 
the start of the record (if the record carriage control character is a space) 
but not a carriage return; that happens at end of record.  So if some previous 
operation left the carriage at some other spot on the page, you'd end up with 
weird looking output.  The / supplies  to ensure all is clean.

paul


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

Re: [Simh] Crowther's Adventure game

[Ken Cornetet]

I used a hacked version of f2c to "compile" Mystery Mansion (for the HP1000) 
into c, which I was then able to compile and get a runnable game on modern 
systems.

The nice thing about using f2c is that you can tweak f2c to match the 
particular idiosyncrasies of the source code. 

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Paul Koning
Sent: Monday, February 5, 2018 4:55 PM
To: SIMH 
Subject: Re: [Simh] Crowther's Adventure game

> From: Johnny Billquist 
> >
> > A caveat is that most any Fortran compiler I've seen or heard of for 
> > Linux is not so good.

I've used the GCC Fortran compiler over the years, for substantial applications 
(like NEC2) without trouble.  And I know it's still in active development for 
the latest Fortran flavors.

paul

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

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

[Ken Cornetet]

All this talk about FORTRAN and criticisms of Pascal brought back memories of  
“Real Programmers Don’t Use Pascal”

I’d imagine all of you old timers around here have read it, but you younger 
folk may not be familiar with it. If you’ve never read this gem, go do so now. 
http://www.usm.uni-muenchen.de/~hoffmann/roff/tmp/rpdup.pdf

After you finish that, google Mel and the Royal McBee.

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Clem Cole
Sent: Thursday, February 8, 2018 12:44 PM
To: Dan Gahlinger 
Cc: Gary Lee Phillips ; simh@trailing-edge.com
Subject: Re: [Simh] anyone know how to convert/translate turbo pascal to vax 
pascal?

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

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

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

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

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

Good Luck,
Clem

** IMHO: This is a good example of where C 'beat' Pascal - the I/O was defined 
by UNIX and when it came time to create a standard, C mostly kept the UNIX 
semantics and was able to keep many/most of the OS-ism from other systems out.
[https://mailfoogae.appspot.com/t?sender=aY2xlbWNAY2NjLmNvbQ%3D%3D&type=zerocontent&guid=04606809-a8e8-441d-a498-316c887d23a1]ᐧ

On Thu, Feb 8, 2018 at 12:21 PM, Dan Gahlinger 
mailto:dgahl...@hotmail.com>> wrote:
so here you go, a simple file compare I wrote using "freepascal" 
(freepascal.org) and I've done what I can to convert it 
to vms pascal
but it doesn't compile.

code:
Program fcomp(input,output);
var
  f, g, h : text;
  s, t, u : varying [255] of char;
  c, d : char;
  i : integer;
begin
  s := 'first.txt';
  t := 'second.txt';
  u := 'output.txt';
  i := 0;
  assign(f,s);
  reset(f);
  assign(g,t);
  reset(g);
  assign(h,u);
  rewrite(h);
  while (not(eof(f))) do
begin
  read(f,c);
  read(g,d);
  i := i + 1;
  if (c <> d) then
writeln(h,i,' = 1:[',c,']/',ord(c),' 2:[',d,']/',ord(d));
end;
  close(f);
  close(g);
  close(h);
end.

errors:
 pas fcomp.pas
00016  0  1   assign(f,s);
  1
%PASCAL-E-UNDECLID, (1) Undeclared identifier ASSIGN
at line number 16 in file DUA1:[DAN]FCOMP.PAS;4
%PASCAL-E-ENDDIAGS, PASCAL completed with 1 diagnostic


From: Clem Cole mailto:cl...@ccc.com>>
Sent: February 8, 2018 10:58 AM
To: Dan Gahlinger
Cc: Gary Lee Phillips; Tim Shoppa; 
simh@trailing-edge.com
Subject: Re: [Simh] anyone know how to convert/translate turbo pascal to vax 
pascal?

Dan,

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

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

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

From a quick search on t

Re: [Simh] Printing to a pdf

[Ken Cornetet]

Years ago I needed to do something similar. What I did was to write a simple 
shell script to turn my text into HTML, then run it through html2ps, then run 
the resulting postscript through ghostscript to get PDF. I recall that other 
than being a bit clunky, it worked really well – and my text to HTML script 
could throw in some nice embellishments to the resulting document.

From: Simh  On Behalf Of Johan
Sent: Monday, May 25, 2020 5:38 AM
To: simh@trailing-edge.com
Subject: [Simh] Printing to a pdf

***ATTENTION: This message was received from an EXTERNAL source.***


Hi,

I am having fun with my virtual VAX. Thanks to SIMH, its a wonderfull 
experience to have a VAX at home.

Now, I have a question.

Is there a way to print to a pdf ? like a script running in Linux (the host) 
who intercepts the LPT output
and creates a pdf ?

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