From rubhone at aol.com  Sat Aug  1 13:32:01 2015
From: rubhone at aol.com (rubhone at aol.com)
Date: Sat, 1 Aug 2015 13:32:01 -0400
Subject: [Simh] Porting simh for IBM VM/CMS
In-Reply-To: <080901d0cb89$bbcce5b0$3366b110$@gmail.com>
Message-ID: <14eea520761-2f57-28494@webprd-m89.mail.aol.com>

Dave,


You need not be amazed; your idea is sound and as you mentioned, getting the brackets
right was the worst of it.  Congrats on the code transformation from simply "nasty" to
"really horrid" and finally "truely noxious".  I'll insert some line breaks and comments to
make it potentially readable.  (Here I thought APL was the only write-only language.)


Perhaps this original code struck you as nasty because it is really a hidden OS dependency,
is it not?  Or are character set arrangements not included in that realm?


Thinking about related matters, do I need to be concerned that the IBM systems are
big endian?  It appears that simh takes this into account with the sim_finit routine in sim_fio.c,
but there could be other places with data coding assumptions not fitting the /370 architecture.

For the moment, I hacked the "attach" <dev>" code to avoid a rb+ file open attempt since
the CMS implementation of the stdio package does not support simultaneous r/w file access.
This will surely prove to be another big problem, but for now the attach is successful for an
existing file.


Fritz


-----Original Message-----
From: Dave G4UGM <dave.g4ugm at gmail.com>
To: rubhone <rubhone at aol.com>
Cc: 'simh' <simh at trailing-edge.com>
Sent: Fri, Jul 31, 2015 7:09 am
Subject: RE: [Simh] Porting simh for IBM VM/CMS


 
  
I am amazed, and very glad, it works, been ages since I wrote any “C” ….
  
.. and as for threads, well they are hidden in the headers, and should just pick up again. 
  
 
  
Dave Wade
  
G4UGM
  
 




          
         
        
       
      
     
    
   
  
 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150801/ace0aeea/attachment.html>

From dave.g4ugm at gmail.com  Sat Aug  1 14:29:11 2015
From: dave.g4ugm at gmail.com (Dave G4UGM)
Date: Sat, 1 Aug 2015 19:29:11 +0100
Subject: [Simh] Porting simh for IBM VM/CMS
In-Reply-To: <14eea520761-2f57-28494@webprd-m89.mail.aol.com>
References: <080901d0cb89$bbcce5b0$3366b110$@gmail.com>
 <14eea520761-2f57-28494@webprd-m89.mail.aol.com>
Message-ID: <008301d0cc87$f6ffb9b0$e4ff2d10$@gmail.com>

>Dave, 

 

>You need not be amazed; your idea is sound and as you mentioned, getting the brackets

>right was the worst of it.  Congrats on the code transformation from simply "nasty" to

>"really horrid" and finally "truely noxious".  I'll insert some line breaks and comments to

>make it potentially readable.  (Here I thought APL was the only write-only language.)

 

>Perhaps this original code struck you as nasty because it is really a hidden OS dependency,

>is it not?  Or are character set arrangements not included in that realm?

 

Well it’s a character set dependency and a really neat piece of optimization. However its hiding something in a bit field, a trick which in High Level languages has always caused me problems in the past.

I think it would be more portable to have the Alphabet as a string “ABCDEFGHIJKLMNOPQRSTUVWXYZ” and then search through it for the wanted character, but of course much slower…

 

As Michael Jackson once said :-

 

"Beer may cause you to digress--and lead a happier life"

 

(that was another late and much lamented Michael Jackson aka “the beer hunter” - https://en.wikipedia.org/wiki/Michael_Jackson_(writer)”

 

Michael Jackson author of – Principles of Program Design - https://en.wikipedia.org/wiki/Michael_A._Jackson

 

Had a more apposite saying, that is  “we will look at optimaztion – but later on” , perhaps its not time…

 

>Thinking about related matters, do I need to be concerned that the IBM systems are

>big endian?  It appears that simh takes this into account with the sim_finit routine in sim_fio.c,

>but there could be other places with data coding assumptions not fitting the /370 architecture.

 

It possible, but its probably easier to try and test, rather than to find.

 

>For the moment, I hacked the "attach" <dev>" code to avoid a rb+ file open attempt since

>the CMS implementation of the stdio package does not support simultaneous r/w file access.

>This will surely prove to be another big problem, but for now the attach is successful for an

>existing file.

 

You didn’t say which IBM platform you were running this on, and which “C” compiler….

 

Fritz

 

Dave

 

From: rubhone at aol.com [mailto:rubhone at aol.com] 
Sent: 01 August 2015 18:32
To: dave.g4ugm at gmail.com
Cc: simh at trailing-edge.com
Subject: Re: [Simh] Porting simh for IBM VM/CMS

 

-----Original Message-----
From: Dave G4UGM <dave.g4ugm at gmail.com <mailto:dave.g4ugm at gmail.com> >
To: rubhone <rubhone at aol.com <mailto:rubhone at aol.com> >
Cc: 'simh' <simh at trailing-edge.com <mailto:simh at trailing-edge.com> >
Sent: Fri, Jul 31, 2015 7:09 am
Subject: RE: [Simh] Porting simh for IBM VM/CMS

I am amazed, and very glad, it works, been ages since I wrote any “C” ….

.. and as for threads, well they are hidden in the headers, and should just pick up again. 

 

Dave Wade

G4UGM

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150801/17d91c46/attachment-0001.html>

From Mark at infocomm.com  Mon Aug  3 15:36:27 2015
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Mon, 3 Aug 2015 12:36:27 -0700
Subject: [Simh] Porting simh for IBM VM/CMS
In-Reply-To: <008301d0cc87$f6ffb9b0$e4ff2d10$@gmail.com>
References: <080901d0cb89$bbcce5b0$3366b110$@gmail.com>
 <14eea520761-2f57-28494@webprd-m89.mail.aol.com>
 <008301d0cc87$f6ffb9b0$e4ff2d10$@gmail.com>
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A823733C0948@REDROOF2.alohasunset.com>

On Saturday, August 1, 2015 at 11:29AM Dave G4UGM wrote:
> On Saturday, August 1, 2015 at 10:32AM Fritz wrote:
> >Perhaps this original code struck you as nasty because it is really a hidden OS dependency,
> >is it not?  Or are character set arrangements not included in that realm?

> Well it’s a character set dependency and a really neat piece of optimization. 
> However its hiding something in a bit field, a trick which in High Level languages has 
> always caused me problems in the past.
> I think it would be more portable to have the Alphabet as a string 
> “ABCDEFGHIJKLMNOPQRSTUVWXYZ” and then search through it for the wanted 
> character, but of course much slower…

That is a good suggestion, AND since code paths which use the SWMASK macro are not performance sensitive speed really isn't a concern.

The simh code at https://github.com/simh/simh has been changed to implement the SWMASK macro with code which does this as Dave suggested.

The simh source code now doesn't have a ASCII character set dependency, however, many/most of the systems that have simh simulators expect ASCII characters as input and output.  Mapping from host platform character set into the ASCII simulated character set will also be required as you move forward...

> >Thinking about related matters, do I need to be concerned that the IBM systems are
> >big endian?  It appears that simh takes this into account with the sim_finit routine in sim_fio.c,
> >but there could be other places with data coding assumptions not fitting the /370 architecture.
>
> It possible, but its probably easier to try and test, rather than to find.

The simh codebase works fine on big endian systems.

> >For the moment, I hacked the "attach" <dev>" code to avoid a rb+ file open attempt since
> >the CMS implementation of the stdio package does not support simultaneous r/w file access.
> >This will surely prove to be another big problem, but for now the attach is successful for an
> >existing file.
>
> You didn’t say which IBM platform you were running this on, and which “C” compiler….

A C runtime environment which supports open mode "rb+" is definitely a requirement.  

I have no familiarity with VM/CMS, but the name (and the issues Fritz previously mentioned) suggest to me that this is a legacy environment.  Porting simh to run on legacy environments is generally out of scope with respect to the project goals.  The general simh goals are to provide ways of simulating legacy environments or systems on modern systems.

- Mark

From dave.g4ugm at gmail.com  Mon Aug  3 16:38:52 2015
From: dave.g4ugm at gmail.com (Dave G4UGM)
Date: Mon, 3 Aug 2015 21:38:52 +0100
Subject: [Simh] Porting simh for IBM VM/CMS
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A823733C0948@REDROOF2.alohasunset.com>
References: <080901d0cb89$bbcce5b0$3366b110$@gmail.com>
 <14eea520761-2f57-28494@webprd-m89.mail.aol.com>
 <008301d0cc87$f6ffb9b0$e4ff2d10$@gmail.com>
 <03006E3FC39B5A48AB9DBCCC101090A823733C0948@REDROOF2.alohasunset.com>
Message-ID: <1f0b01d0ce2c$69b58110$3d208330$@gmail.com>



> -----Original Message-----
> From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com]
> Sent: 03 August 2015 20:36
> To: Dave G4UGM <dave.g4ugm at gmail.com>; rubhone at aol.com
> Cc: simh at trailing-edge.com
> Subject: RE: [Simh] Porting simh for IBM VM/CMS
> 
> On Saturday, August 1, 2015 at 11:29AM Dave G4UGM wrote:
> > On Saturday, August 1, 2015 at 10:32AM Fritz wrote:
> > >Perhaps this original code struck you as nasty because it is really a
> > >hidden OS dependency, is it not?  Or are character set arrangements not
> included in that realm?
> 
> > Well it’s a character set dependency and a really neat piece of optimization.
> > However its hiding something in a bit field, a trick which in High
> > Level languages has always caused me problems in the past.
> > I think it would be more portable to have the Alphabet as a string
> > “ABCDEFGHIJKLMNOPQRSTUVWXYZ” and then search through it for the
> wanted
> > character, but of course much slower…
> 
> That is a good suggestion, AND since code paths which use the SWMASK
> macro are not performance sensitive speed really isn't a concern.
> 
> The simh code at https://github.com/simh/simh has been changed to
> implement the SWMASK macro with code which does this as Dave
> suggested.
> 
> The simh source code now doesn't have a ASCII character set dependency,
> however, many/most of the systems that have simh simulators expect ASCII
> characters as input and output.  Mapping from host platform character set
> into the ASCII simulated character set will also be required as you move
> forward...
> 
> > >Thinking about related matters, do I need to be concerned that the
> > >IBM systems are big endian?  It appears that simh takes this into
> > >account with the sim_finit routine in sim_fio.c, but there could be other
> places with data coding assumptions not fitting the /370 architecture.
> >
> > It possible, but its probably easier to try and test, rather than to find.
> 
> The simh codebase works fine on big endian systems.
> 
> > >For the moment, I hacked the "attach" <dev>" code to avoid a rb+ file
> > >open attempt since the CMS implementation of the stdio package does
> not support simultaneous r/w file access.
> > >This will surely prove to be another big problem, but for now the
> > >attach is successful for an existing file.
> >
> > You didn’t say which IBM platform you were running this on, and which “C”
> compiler….
> 
> A C runtime environment which supports open mode "rb+" is definitely a
> requirement.
> 
> I have no familiarity with VM/CMS, but the name (and the issues Fritz
> previously mentioned) suggest to me that this is a legacy environment.

VM/CMS suggests to me the freely available VM/370R6 environment, which is definitely a legacy environment, and the only way I know how to run it is under the Hercules IBM Mainframe emulators.
There are two "C" compilers that will generate "C" code on this environment. One is a port of GCC 3.4 (I think, its been a while) but the code is really only enough to support the C90 environment. There is no C++ and it uses the VM native linker and loaded which also have restrictions. The other is called JCC and I haven't used it in ages, but from what I remember it only works as a cross compiler...

However there is a modern zVM environment which is broadly upwardly compatible with VM/370 R6. It has an IBM provided "C" compiler which  is compliant with modern standards, but it is still EBCDIC so the macro is broken. I am not sure how it supports "rb+" but the file system is record orientation so how you translate the "C" stream oriented paradigms can be "interesting"...


> Porting simh to run on legacy environments is generally out of scope with
> respect to the project goals.  The general simh goals are to provide ways of
> simulating legacy environments or systems on modern systems.
> 

That’s kind of why I was trying to figure out if he was using a modern VM or a legacy environemt....

> - Mark

Dave


From rubhone at aol.com  Tue Aug  4 06:46:36 2015
From: rubhone at aol.com (rubhone at aol.com)
Date: Tue, 4 Aug 2015 06:46:36 -0400
Subject: [Simh] Porting simh for IBM VM/CMS
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A823733C0948@REDROOF2.alohasunset.com>
Message-ID: <14ef851ef4c-6e03-32513@webprd-m87.mail.aol.com>

I'm pleased that my efforts have inspired others to produce code to improve
portability of simh.


My base hardware for this project runs Ubuntu on a AMD Athlon system,
maybe 3-4 years old.  The surmised legacy environment is
provided by Hercules emulator on Ubuntu; this runs the VM/370 "Six-Pack"
v1.2 by Robert O'Hara.


Out of time for tonight, but will be back with more details and some answers
to "Why???".


Thanks for the help so far.
Fritz



-----Original Message-----
From: Mark Pizzolato - Info Comm <Mark at infocomm.com>
To: Dave G4UGM <dave.g4ugm at gmail.com>; rubhone <rubhone at aol.com>
Cc: simh <simh at trailing-edge.com>
Sent: Mon, Aug 3, 2015 2:36 pm
Subject: RE: [Simh] Porting simh for IBM VM/CMS


On Saturday, August 1, 2015 at 11:29AM Dave G4UGM wrote:
> On Saturday, August
1, 2015 at 10:32AM Fritz wrote:
> >Perhaps this original code struck you as
nasty because it is really a hidden OS dependency,
> >is it not?  Or are
character set arrangements not included in that realm?

> Well it’s a
character set dependency and a really neat piece of optimization. 
> However
its hiding something in a bit field, a trick which in High Level languages has

> always caused me problems in the past.
> I think it would be more portable
to have the Alphabet as a string 
> “ABCDEFGHIJKLMNOPQRSTUVWXYZ” and then
search through it for the wanted 
> character, but of course much
slower…

That is a good suggestion, AND since code paths which use the SWMASK
macro are not performance sensitive speed really isn't a concern.

The simh
code at https://github.com/simh/simh has been changed to implement the SWMASK
macro with code which does this as Dave suggested.

The simh source code now
doesn't have a ASCII character set dependency, however, many/most of the systems
that have simh simulators expect ASCII characters as input and output.  Mapping
from host platform character set into the ASCII simulated character set will
also be required as you move forward...

> >Thinking about related matters, do
I need to be concerned that the IBM systems are
> >big endian?  It appears that
simh takes this into account with the sim_finit routine in sim_fio.c,
> >but
there could be other places with data coding assumptions not fitting the /370
architecture.
>
> It possible, but its probably easier to try and test, rather
than to find.

The simh codebase works fine on big endian systems.

> >For
the moment, I hacked the "attach" <dev>" code to avoid a rb+ file open attempt
since
> >the CMS implementation of the stdio package does not support
simultaneous r/w file access.
> >This will surely prove to be another big
problem, but for now the attach is successful for an
> >existing file.
>
>
You didn’t say which IBM platform you were running this on, and which “C”
compiler….

A C runtime environment which supports open mode "rb+" is
definitely a requirement.  

I have no familiarity with VM/CMS, but the name
(and the issues Fritz previously mentioned) suggest to me that this is a legacy
environment.  Porting simh to run on legacy environments is generally out of
scope with respect to the project goals.  The general simh goals are to provide
ways of simulating legacy environments or systems on modern systems.

- Mark

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150804/eeb3a347/attachment.html>

From dgahling at hotmail.com  Tue Aug  4 11:52:20 2015
From: dgahling at hotmail.com (Dan Gahlinger)
Date: Tue, 4 Aug 2015 11:52:20 -0400
Subject: [Simh] off-topic basic translator
In-Reply-To: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>
Message-ID: <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>

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.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150804/11af9a20/attachment.html>

From khandy21yo at gmail.com  Tue Aug  4 14:29:01 2015
From: khandy21yo at gmail.com (Kevin Handy)
Date: Tue, 4 Aug 2015 12:29:01 -0600
Subject: [Simh] off-topic basic translator
In-Reply-To: <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>
Message-ID: <CANk4W2P=rwdZ9nBDG9X_Fwb36+OBCR-uEvk+KaqV=tpugfg_Vw@mail.gmail.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 <dgahling at 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 at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150804/85d4c823/attachment.html>

From dave.g4ugm at gmail.com  Tue Aug  4 15:03:26 2015
From: dave.g4ugm at gmail.com (Dave G4UGM)
Date: Tue, 4 Aug 2015 20:03:26 +0100
Subject: [Simh] Porting simh for IBM VM/CMS
In-Reply-To: <14ef851ef4c-6e03-32513@webprd-m87.mail.aol.com>
References: <03006E3FC39B5A48AB9DBCCC101090A823733C0948@REDROOF2.alohasunset.com>
 <14ef851ef4c-6e03-32513@webprd-m87.mail.aol.com>
Message-ID: <04b501d0cee8$3f2af9e0$bd80eda0$@gmail.com>

So that has the Paul Edwards GCC port and hacked BREXX. I am busy this week, but if you nag next week I will look at how SIMH does i/o and see if it is possible to provide some kind of read/write support in the I/O in GCC.
 
Dave
 
From: rubhone at aol.com [mailto:rubhone at aol.com] 
Sent: 04 August 2015 11:47
To: Mark at infocomm.com; dave.g4ugm at gmail.com
Cc: simh at trailing-edge.com
Subject: Re: [Simh] Porting simh for IBM VM/CMS
 
I'm pleased that my efforts have inspired others to produce code to improve 
portability of simh. 
 
My base hardware for this project runs Ubuntu on a AMD Athlon system,
maybe 3-4 years old.  The surmised legacy environment is
provided by Hercules emulator on Ubuntu; this runs the VM/370 "Six-Pack"
v1.2 by Robert O'Hara.
 
Out of time for tonight, but will be back with more details and some answers
to "Why???".
 
Thanks for the help so far.
Fritz
 
-----Original Message-----
From: Mark Pizzolato - Info Comm <Mark at infocomm.com <mailto:Mark at infocomm.com> >
To: Dave G4UGM <dave.g4ugm at gmail.com <mailto:dave.g4ugm at gmail.com> >; rubhone <rubhone at aol.com <mailto:rubhone at aol.com> >
Cc: simh <simh at trailing-edge.com <mailto:simh at trailing-edge.com> >
Sent: Mon, Aug 3, 2015 2:36 pm
Subject: RE: [Simh] Porting simh for IBM VM/CMS
On Saturday, August 1, 2015 at 11:29AM Dave G4UGM wrote:
> On Saturday, August
1, 2015 at 10:32AM Fritz wrote:
> >Perhaps this original code struck you as
nasty because it is really a hidden OS dependency,
> >is it not?  Or are
character set arrangements not included in that realm?
 
> Well it’s a
character set dependency and a really neat piece of optimization. 
> However
its hiding something in a bit field, a trick which in High Level languages has
 
> always caused me problems in the past.
> I think it would be more portable
to have the Alphabet as a string 
> “ABCDEFGHIJKLMNOPQRSTUVWXYZ” and then
search through it for the wanted 
> character, but of course much
slower…
 
That is a good suggestion, AND since code paths which use the SWMASK
macro are not performance sensitive speed really isn't a concern.
 
The simh
code at https://github.com/simh/simh has been changed to implement the SWMASK
macro with code which does this as Dave suggested.
 
The simh source code now
doesn't have a ASCII character set dependency, however, many/most of the systems
that have simh simulators expect ASCII characters as input and output.  Mapping
from host platform character set into the ASCII simulated character set will
also be required as you move forward...
 
> >Thinking about related matters, do
I need to be concerned that the IBM systems are
> >big endian?  It appears that
simh takes this into account with the sim_finit routine in sim_fio.c,
> >but
there could be other places with data coding assumptions not fitting the /370
architecture.
> 
> It possible, but its probably easier to try and test, rather
than to find.
 
The simh codebase works fine on big endian systems.
 
> >For
the moment, I hacked the "attach" <dev>" code to avoid a rb+ file open attempt
since
> >the CMS implementation of the stdio package does not support
simultaneous r/w file access.
> >This will surely prove to be another big
problem, but for now the attach is successful for an
> >existing file.
> 
> 
You didn’t say which IBM platform you were running this on, and which “C”
compiler….
 
A C runtime environment which supports open mode "rb+" is
definitely a requirement.  
 
I have no familiarity with VM/CMS, but the name
(and the issues Fritz previously mentioned) suggest to me that this is a legacy
environment.  Porting simh to run on legacy environments is generally out of
scope with respect to the project goals.  The general simh goals are to provide
ways of simulating legacy environments or systems on modern systems.
 
- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150804/e910633e/attachment-0001.html>

From dgahling at hotmail.com  Tue Aug  4 15:34:39 2015
From: dgahling at hotmail.com (Dan Gahlinger)
Date: Tue, 4 Aug 2015 15:34:39 -0400
Subject: [Simh] off-topic basic translator
In-Reply-To: <CANk4W2P=rwdZ9nBDG9X_Fwb36+OBCR-uEvk+KaqV=tpugfg_Vw@mail.gmail.com>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>,
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>,
 <CANk4W2P=rwdZ9nBDG9X_Fwb36+OBCR-uEvk+KaqV=tpugfg_Vw@mail.gmail.com>
Message-ID: <COL131-W656487F35C3DAB1428D62AC9760@phx.gbl>

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: khandy21yo at gmail.com
To: dgahling at hotmail.com
CC: simh at 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 <dgahling at 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 at trailing-edge.com

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

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150804/fb924585/attachment.html>

From tfmorris at gmail.com  Tue Aug  4 16:19:14 2015
From: tfmorris at gmail.com (Tom Morris)
Date: Tue, 4 Aug 2015 16:19:14 -0400
Subject: [Simh] off-topic basic translator
In-Reply-To: <COL131-W656487F35C3DAB1428D62AC9760@phx.gbl>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>
 <CANk4W2P=rwdZ9nBDG9X_Fwb36+OBCR-uEvk+KaqV=tpugfg_Vw@mail.gmail.com>
 <COL131-W656487F35C3DAB1428D62AC9760@phx.gbl>
Message-ID: <CAE9vqEGtWrT+FiUXayUJiTo3C_fyfir5-eSHA1f4bULAQKAzDA@mail.gmail.com>

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 <dgahling at 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: khandy21yo at gmail.com
> To: dgahling at hotmail.com
> CC: simh at 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 <dgahling at 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 at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150804/eb9ca76c/attachment.html>

From khandy21yo at gmail.com  Tue Aug  4 16:29:49 2015
From: khandy21yo at gmail.com (Kevin Handy)
Date: Tue, 4 Aug 2015 14:29:49 -0600
Subject: [Simh] off-topic basic translator
In-Reply-To: <CAE9vqEGtWrT+FiUXayUJiTo3C_fyfir5-eSHA1f4bULAQKAzDA@mail.gmail.com>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>
 <CANk4W2P=rwdZ9nBDG9X_Fwb36+OBCR-uEvk+KaqV=tpugfg_Vw@mail.gmail.com>
 <COL131-W656487F35C3DAB1428D62AC9760@phx.gbl>
 <CAE9vqEGtWrT+FiUXayUJiTo3C_fyfir5-eSHA1f4bULAQKAzDA@mail.gmail.com>
Message-ID: <CANk4W2Ps2=sfoQcULq_kQ3v1fh9atA+Jd226eNotVWpZYWY6Gw@mail.gmail.com>

It won't help you. If you look at the section "U*ntranslatable 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 <tfmorris at 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 <dgahling at 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: khandy21yo at gmail.com
>> To: dgahling at hotmail.com
>> CC: simh at 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 <dgahling at 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 at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150804/6ee8501f/attachment-0001.html>

From dgahling at hotmail.com  Tue Aug  4 16:37:39 2015
From: dgahling at hotmail.com (Dan Gahlinger)
Date: Tue, 4 Aug 2015 16:37:39 -0400
Subject: [Simh] off-topic basic translator
In-Reply-To: <CANk4W2Ps2=sfoQcULq_kQ3v1fh9atA+Jd226eNotVWpZYWY6Gw@mail.gmail.com>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>,
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>,
 <CANk4W2P=rwdZ9nBDG9X_Fwb36+OBCR-uEvk+KaqV=tpugfg_Vw@mail.gmail.com>,
 <COL131-W656487F35C3DAB1428D62AC9760@phx.gbl>,
 <CAE9vqEGtWrT+FiUXayUJiTo3C_fyfir5-eSHA1f4bULAQKAzDA@mail.gmail.com>,
 <CANk4W2Ps2=sfoQcULq_kQ3v1fh9atA+Jd226eNotVWpZYWY6Gw@mail.gmail.com>
Message-ID: <COL131-W94B7A8C5FE387E9C07399C9760@phx.gbl>

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: khandy21yo at gmail.com
To: tfmorris at gmail.com
CC: dgahling at hotmail.com; simh at 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 <tfmorris at 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 <dgahling at 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: khandy21yo at gmail.com
To: dgahling at hotmail.com
CC: simh at 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 <dgahling at 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 at trailing-edge.com

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

 		 	   		  

_______________________________________________

Simh mailing list

Simh at trailing-edge.com

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



_______________________________________________

Simh mailing list

Simh at trailing-edge.com

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

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150804/d7730dfc/attachment.html>

From Ken.Cornetet at kimballelectronics.com  Tue Aug  4 16:55:06 2015
From: Ken.Cornetet at kimballelectronics.com (Ken Cornetet)
Date: Tue, 4 Aug 2015 20:55:06 +0000
Subject: [Simh] off-topic basic translator
In-Reply-To: <COL131-W94B7A8C5FE387E9C07399C9760@phx.gbl>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>,
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>,
 <CANk4W2P=rwdZ9nBDG9X_Fwb36+OBCR-uEvk+KaqV=tpugfg_Vw@mail.gmail.com>,
 <COL131-W656487F35C3DAB1428D62AC9760@phx.gbl>,
 <CAE9vqEGtWrT+FiUXayUJiTo3C_fyfir5-eSHA1f4bULAQKAzDA@mail.gmail.com>,
 <CANk4W2Ps2=sfoQcULq_kQ3v1fh9atA+Jd226eNotVWpZYWY6Gw@mail.gmail.com>
 <COL131-W94B7A8C5FE387E9C07399C9760@phx.gbl>
Message-ID: <1f2563bf61b94618882c9cdaf080aa77@NTS1115.kei.keint.com>

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-bounces at trailing-edge.com] On Behalf Of Dan Gahlinger
Sent: Tuesday, August 04, 2015 4:38 PM
To: Kevin Handy; Tom Morris
Cc: simh at 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: khandy21yo at gmail.com<mailto:khandy21yo at gmail.com>
To: tfmorris at gmail.com<mailto:tfmorris at gmail.com>
CC: dgahling at hotmail.com<mailto:dgahling at hotmail.com>; simh at trailing-edge.com<mailto:simh at 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 <tfmorris at gmail.com<mailto:tfmorris at 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 <dgahling at hotmail.com<mailto:dgahling at 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: khandy21yo at gmail.com<mailto:khandy21yo at gmail.com>
To: dgahling at hotmail.com<mailto:dgahling at hotmail.com>
CC: simh at trailing-edge.com<mailto:simh at 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 <dgahling at hotmail.com<mailto:dgahling at 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 at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh


_______________________________________________
Simh mailing list
Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh


_______________________________________________
Simh mailing list
Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150804/d6d28827/attachment-0001.html>

From dgahling at hotmail.com  Tue Aug  4 16:58:59 2015
From: dgahling at hotmail.com (Dan Gahlinger)
Date: Tue, 4 Aug 2015 16:58:59 -0400
Subject: [Simh] off-topic basic translator
Message-ID: <COL402-EAS6754DB0B9D31FECDF7B4CBC9760@phx.gbl>

Per is not a usable language. Lol


Sent from my Samsung Galaxy smartphone.

-------- Original message --------
From: Ken Cornetet <Ken.Cornetet at kimballelectronics.com>
Date: 08-04-2015  4:55 PM  (GMT-05:00)
To: simh at 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-bounces at trailing-edge.com] On Behalf Of Dan Gahlinger
Sent: Tuesday, August 04, 2015 4:38 PM
To: Kevin Handy; Tom Morris
Cc: simh at 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: khandy21yo at gmail.com<mailto:khandy21yo at gmail.com>
To: tfmorris at gmail.com<mailto:tfmorris at gmail.com>
CC: dgahling at hotmail.com<mailto:dgahling at hotmail.com>; simh at trailing-edge.com<mailto:simh at 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 <tfmorris at gmail.com<mailto:tfmorris at 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 <dgahling at hotmail.com<mailto:dgahling at 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: khandy21yo at gmail.com<mailto:khandy21yo at gmail.com>
To: dgahling at hotmail.com<mailto:dgahling at hotmail.com>
CC: simh at trailing-edge.com<mailto:simh at 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 <dgahling at hotmail.com<mailto:dgahling at 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 at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh


_______________________________________________
Simh mailing list
Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh


_______________________________________________
Simh mailing list
Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150804/2cc05f2e/attachment.html>
-------------- next part --------------
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

From Ken.Cornetet at kimballelectronics.com  Tue Aug  4 17:04:45 2015
From: Ken.Cornetet at kimballelectronics.com (Ken Cornetet)
Date: Tue, 4 Aug 2015 21:04:45 +0000
Subject: [Simh] off-topic basic translator
In-Reply-To: <COL402-EAS6754DB0B9D31FECDF7B4CBC9760@phx.gbl>
References: <COL402-EAS6754DB0B9D31FECDF7B4CBC9760@phx.gbl>
Message-ID: <c84363f576534f16865f8b72e7789cb4@NTS1115.kei.keint.com>

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

From: Dan Gahlinger [mailto:dgahling at hotmail.com]
Sent: Tuesday, August 04, 2015 4:59 PM
To: Ken Cornetet; simh at 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 <Ken.Cornetet at kimballelectronics.com<mailto:Ken.Cornetet at kimballelectronics.com>>
Date: 08-04-2015 4:55 PM (GMT-05:00)
To: simh at trailing-edge.com<mailto:simh at 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-bounces at trailing-edge.com] On Behalf Of Dan Gahlinger
Sent: Tuesday, August 04, 2015 4:38 PM
To: Kevin Handy; Tom Morris
Cc: simh at trailing-edge.com<mailto:simh at 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: khandy21yo at gmail.com<mailto:khandy21yo at gmail.com>
To: tfmorris at gmail.com<mailto:tfmorris at gmail.com>
CC: dgahling at hotmail.com<mailto:dgahling at hotmail.com>; simh at trailing-edge.com<mailto:simh at 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 <tfmorris at gmail.com<mailto:tfmorris at 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 <dgahling at hotmail.com<mailto:dgahling at 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: khandy21yo at gmail.com<mailto:khandy21yo at gmail.com>
To: dgahling at hotmail.com<mailto:dgahling at hotmail.com>
CC: simh at trailing-edge.com<mailto:simh at 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 <dgahling at hotmail.com<mailto:dgahling at 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 at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh



_______________________________________________
Simh mailing list
Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh



_______________________________________________
Simh mailing list
Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150804/06483140/attachment-0001.html>

From khandy21yo at gmail.com  Tue Aug  4 17:21:58 2015
From: khandy21yo at gmail.com (Kevin Handy)
Date: Tue, 4 Aug 2015 15:21:58 -0600
Subject: [Simh] off-topic basic translator
In-Reply-To: <c84363f576534f16865f8b72e7789cb4@NTS1115.kei.keint.com>
References: <COL402-EAS6754DB0B9D31FECDF7B4CBC9760@phx.gbl>
 <c84363f576534f16865f8b72e7789cb4@NTS1115.kei.keint.com>
Message-ID: <CANk4W2M+1vsaw4eZ0VB4jF=rbicv6Kt9pTooBGguTKeXxqTEcg@mail.gmail.com>

C++ hs std::string which handles most of the basic strings, except for
those in maps and other such structures.
It also has GOTO, and you can implement GOSUB without too much trouble You
just hve to be careful about jumping over definitions..


On Tue, Aug 4, 2015 at 3:04 PM, Ken Cornetet <
Ken.Cornetet at kimballelectronics.com> wrote:

> Well, perl is often described as a write-only language. Perfect as the
> output of a translator!
>
>
>
> *From:* Dan Gahlinger [mailto:dgahling at hotmail.com]
> *Sent:* Tuesday, August 04, 2015 4:59 PM
> *To:* Ken Cornetet; simh at 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 <Ken.Cornetet at kimballelectronics.com>
> Date: 08-04-2015 4:55 PM (GMT-05:00)
> To: simh at 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-bounces at trailing-edge.com
> <simh-bounces at trailing-edge.com>] *On Behalf Of *Dan Gahlinger
> *Sent:* Tuesday, August 04, 2015 4:38 PM
> *To:* Kevin Handy; Tom Morris
> *Cc:* simh at 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: khandy21yo at gmail.com
> To: tfmorris at gmail.com
> CC: dgahling at hotmail.com; simh at trailing-edge.com
>
> It won't help you. If you look at the section "U*ntranslatable 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 <tfmorris at 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 <dgahling at 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: khandy21yo at gmail.com
> To: dgahling at hotmail.com
> CC: simh at 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 <dgahling at 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 at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150804/31d27707/attachment.html>

From stephen_van_berg at earlicker.com  Tue Aug  4 16:42:50 2015
From: stephen_van_berg at earlicker.com (Stephen Van Berg)
Date: Tue, 04 Aug 2015 15:42:50 -0500
Subject: [Simh] off-topic basic translator
In-Reply-To: <mailman.2166.1438722293.1222.simh@trailing-edge.com>
References: <mailman.2166.1438722293.1222.simh@trailing-edge.com>
Message-ID: <55C123CA.5090400@earlicker.com>

I would second  using Perl, it would probably be the easiest translator 
target as a lot of the typing and string manipulation may require less 
work than something like C/C++ or Pascal.

>
> -------- Original message --------
> From: Ken Cornetet <Ken.Cornetet at kimballelectronics.com<mailto:Ken.Cornetet at kimballelectronics.com>>
> Date: 08-04-2015 4:55 PM (GMT-05:00)
> To: simh at trailing-edge.com<mailto:simh at 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 at alderson.users.panix.com  Tue Aug  4 21:44:04 2015
From: simh at alderson.users.panix.com (Rich Alderson)
Date: Tue,  4 Aug 2015 21:44:04 -0400 (EDT)
Subject: [Simh] off-topic basic translator
In-Reply-To: <1f2563bf61b94618882c9cdaf080aa77@NTS1115.kei.keint.com> (message
 from Ken Cornetet on Tue, 4 Aug 2015 20:55:06 +0000)
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>,
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>,
 <CANk4W2P=rwdZ9nBDG9X_Fwb36+OBCR-uEvk+KaqV=tpugfg_Vw@mail.gmail.com>,
 <COL131-W656487F35C3DAB1428D62AC9760@phx.gbl>,
 <CAE9vqEGtWrT+FiUXayUJiTo3C_fyfir5-eSHA1f4bULAQKAzDA@mail.gmail.com>,
 <CANk4W2Ps2=sfoQcULq_kQ3v1fh9atA+Jd226eNotVWpZYWY6Gw@mail.gmail.com>
 <COL131-W94B7A8C5FE387E9C07399C9760@phx.gbl>
 <1f2563bf61b94618882c9cdaf080aa77@NTS1115.kei.keint.com>
Message-ID: <20150805014404.758B924242@panix5.panix.com>

> From: Ken Cornetet <Ken.Cornetet at kimballelectronics.com>
> Date: Tue, 4 Aug 2015 20:55:06 +0000

> Perl has goto. Just sayin'

*Pascal* has goto.

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

Yes, and one in which white space is not syntactically significant. :-)

                                                                Rich

From ahling at eadc.se  Wed Aug  5 02:33:16 2015
From: ahling at eadc.se (=?UTF-8?B?R8O2cmFuIMOFaGxpbmc=?=)
Date: Wed, 5 Aug 2015 08:33:16 +0200
Subject: [Simh] off-topic basic translator
In-Reply-To: <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>
Message-ID: <55C1AE2C.4040408@eadc.se>



Den 2015-08-04 kl. 17:52, skrev Dan Gahlinger:
> 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.
>
If "modern systems" is included in the set of {Win; Mac OSX; Linux; 
Android}, why not stay BASIC?
http://www.qb64.net/
I have used it to make old GW-basic-programs usable in a PC of today 
(ie. >= Win 7).

The snag was to run an old GW-basic, load the program into it, and then 
save the program using Ascii-mode, to get a file that QB64 can load. 
(Actually a file that looks like a LIST print-out, as opposed to the 
GW-basic native format)

It is described in Microsoft Knowledge base: Article ID: 80745

I was astonished how much of structural-programming possibilities and 
support that has been put into this modern BASIC, the step from "old 
days" style that was more close to Fortran-4 is immense! It can 
definitively be used to write "Pascal-looking" programs.

In my case, one of the programs I converted didn't work properly, so I 
ended up correcting it - taking all line-numbers away was a great start, 
as the problem was hidden in GOTO:s by the original author...

Besides from using the QB-64 once, I have no hooks to it or to its 
development...

/Göran

> 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 at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150805/1b003339/attachment-0001.html>

From bqt at softjar.se  Wed Aug  5 04:58:50 2015
From: bqt at softjar.se (Johnny Billquist)
Date: Wed, 5 Aug 2015 10:58:50 +0200
Subject: [Simh] off-topic basic translator
In-Reply-To: <55C1AE2C.4040408@eadc.se>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl> <55C1AE2C.4040408@eadc.se>
Message-ID: <55C1D04A.6090101@softjar.se>

Not adressing Göra specifically.

VAX Basic is not like GW-BASIC. I suspect the differences are large 
enough that we could almost call it two different programming languages...

Anyway, I'm confused by this whole thread.

First of all, VAX Basic is still around. But you still need VMS. I think 
it's called HP Basic nowadays. The naming went: BAX Basic -> DEC Basic 
-> COMPAQ Basic (I suspect) -> HP Basic. But the OP asked for something 
for VMS. So he should be good, and there is no need to do anything. The 
hobbyist program covers hobby use, so you can get a license, install it, 
and be happy. No money involved.

You should be able to find some info you you just manage to locate the 
VMS information at HP. HP is confused, so I'm surprised if you have 
problems finding any kind of information there.

Second - translating stuff from VAX Basic to C++ - I fail to see the 
problem. Normal strings in VAX Basic are dynamic. std::string should fit 
the bill perfectly. Strings in MAPs are static in size and location. No 
different than a char [] in C or C++.
MAP statements as such are actually pretty much a 1:1 mapping to a 
static defined struct in C or C++. If you want to do I/O related to a 
MAP, you'll just do the I/O to the static struct instead, and you're there.
COMMONs are the same thing as MAPs, so the same static structs in C work 
for those too.

For strings, you will need some special assignment and compare operators 
to make it work identical. In VAX Basic, an assignment to a static 
string (such as in a MAP) will pad the string with spaces at the end. 
And there are two string comparators. The normal equal operation will 
consider two strings to be equal even if there are different trailing 
spaces on either or both strings. There is a second string compare 
operator if you want to check for exact equality, including string 
length and trailing spaces.

The FIELD statement is just some more data shuffling related to I/O. 
Nothing difficult about it.

MAT statements is something I would skip, as that is more complex, but 
seldom used.

I think that error handling would be a rather difficult part in any 
translation, though. I don't even care to go into that story here.

But the things other have mentioned, I've touched on above, and they are 
not hard to translate for the most part. But Perl would *not* be a 
language I would translate to.

	Johnny

On 2015-08-05 08:33, Göran Åhling wrote:
>
>
> Den 2015-08-04 kl. 17:52, skrev Dan Gahlinger:
>> 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.
>>
> If "modern systems" is included in the set of {Win; Mac OSX; Linux;
> Android}, why not stay BASIC?
> http://www.qb64.net/
> I have used it to make old GW-basic-programs usable in a PC of today
> (ie. >= Win 7).
>
> The snag was to run an old GW-basic, load the program into it, and then
> save the program using Ascii-mode, to get a file that QB64 can load.
> (Actually a file that looks like a LIST print-out, as opposed to the
> GW-basic native format)
>
> It is described in Microsoft Knowledge base: Article ID: 80745
>
> I was astonished how much of structural-programming possibilities and
> support that has been put into this modern BASIC, the step from "old
> days" style that was more close to Fortran-4 is immense! It can
> definitively be used to write "Pascal-looking" programs.
>
> In my case, one of the programs I converted didn't work properly, so I
> ended up correcting it - taking all line-numbers away was a great start,
> as the problem was hidden in GOTO:s by the original author...
>
> Besides from using the QB-64 once, I have no hooks to it or to its
> development...
>
> /Göran
>
>> 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 at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>


-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

From bqt at softjar.se  Wed Aug  5 05:03:55 2015
From: bqt at softjar.se (Johnny Billquist)
Date: Wed, 5 Aug 2015 11:03:55 +0200
Subject: [Simh] off-topic basic translator
In-Reply-To: <55C1D04A.6090101@softjar.se>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl> <55C1AE2C.4040408@eadc.se>
 <55C1D04A.6090101@softjar.se>
Message-ID: <55C1D17B.4040602@softjar.se>

Sigh! Spelling is worse than normal this morning...

On 2015-08-05 10:58, Johnny Billquist wrote:
> Not adressing Göra specifically.

"Göran".

> VAX Basic is not like GW-BASIC. I suspect the differences are large
> enough that we could almost call it two different programming languages...
>
> Anyway, I'm confused by this whole thread.
>
> First of all, VAX Basic is still around. But you still need VMS. I think
> it's called HP Basic nowadays. The naming went: BAX Basic -> DEC Basic
> -> COMPAQ Basic (I suspect) -> HP Basic. But the OP asked for something
> for VMS. So he should be good, and there is no need to do anything. The
> hobbyist program covers hobby use, so you can get a license, install it,
> and be happy. No money involved.

s/BAX/VAX/

> You should be able to find some info you you just manage to locate the
> VMS information at HP. HP is confused, so I'm surprised if you have
> problems finding any kind of information there.

So I'm *not* surprised if you have problems finding any kind if 
information around there...

> Second - translating stuff from VAX Basic to C++ - I fail to see the
> problem. Normal strings in VAX Basic are dynamic. std::string should fit
> the bill perfectly. Strings in MAPs are static in size and location. No
> different than a char [] in C or C++.
> MAP statements as such are actually pretty much a 1:1 mapping to a
> static defined struct in C or C++. If you want to do I/O related to a
> MAP, you'll just do the I/O to the static struct instead, and you're there.
> COMMONs are the same thing as MAPs, so the same static structs in C work
> for those too.
>
> For strings, you will need some special assignment and compare operators
> to make it work identical. In VAX Basic, an assignment to a static
> string (such as in a MAP) will pad the string with spaces at the end.
> And there are two string comparators. The normal equal operation will
> consider two strings to be equal even if there are different trailing
> spaces on either or both strings. There is a second string compare
> operator if you want to check for exact equality, including string
> length and trailing spaces.
>
> The FIELD statement is just some more data shuffling related to I/O.
> Nothing difficult about it.
>
> MAT statements is something I would skip, as that is more complex, but
> seldom used.
>
> I think that error handling would be a rather difficult part in any
> translation, though. I don't even care to go into that story here.
>
> But the things other have mentioned, I've touched on above, and they are
> not hard to translate for the most part. But Perl would *not* be a
> language I would translate to.
>
>      Johnny

Yay!

	Johnny

>
> On 2015-08-05 08:33, Göran Åhling wrote:
>>
>>
>> Den 2015-08-04 kl. 17:52, skrev Dan Gahlinger:
>>> 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.
>>>
>> If "modern systems" is included in the set of {Win; Mac OSX; Linux;
>> Android}, why not stay BASIC?
>> http://www.qb64.net/
>> I have used it to make old GW-basic-programs usable in a PC of today
>> (ie. >= Win 7).
>>
>> The snag was to run an old GW-basic, load the program into it, and then
>> save the program using Ascii-mode, to get a file that QB64 can load.
>> (Actually a file that looks like a LIST print-out, as opposed to the
>> GW-basic native format)
>>
>> It is described in Microsoft Knowledge base: Article ID: 80745
>>
>> I was astonished how much of structural-programming possibilities and
>> support that has been put into this modern BASIC, the step from "old
>> days" style that was more close to Fortran-4 is immense! It can
>> definitively be used to write "Pascal-looking" programs.
>>
>> In my case, one of the programs I converted didn't work properly, so I
>> ended up correcting it - taking all line-numbers away was a great start,
>> as the problem was hidden in GOTO:s by the original author...
>>
>> Besides from using the QB-64 once, I have no hooks to it or to its
>> development...
>>
>> /Göran
>>
>>> 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 at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>
>


-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

From dgahling at hotmail.com  Wed Aug  5 10:19:01 2015
From: dgahling at hotmail.com (Dan Gahlinger)
Date: Wed, 5 Aug 2015 10:19:01 -0400
Subject: [Simh] off-topic basic translator
In-Reply-To: <55C1D17B.4040602@softjar.se>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>,
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>
 <55C1AE2C.4040408@eadc.se>, <55C1D04A.6090101@softjar.se>,
 <55C1D17B.4040602@softjar.se>
Message-ID: <COL131-W10DF16C0297613702CF6E2C9750@phx.gbl>

I would never translate them to C/C++/Perl...
and the code I want to translate has MAT statements,

I want to move the code off of VMS to something useful.
I've pretty much settled on freepascal

HP Basic translator is discontinued and no longer available, so that's out.
And according to documentation it doesn't support MAT statements anyhow.

Using the Basic reference manual I found, it seems simple enough
to do the translations by hand to whatever language.
but I definitely won't be using C, C++, C# or Perl.

I''ll probably go with freepascal as I have tons of libraries I've written already.

Dan.


> To: simh at trailing-edge.com
> From: bqt at softjar.se
> Date: Wed, 5 Aug 2015 11:03:55 +0200
> Subject: Re: [Simh] off-topic basic translator
> 
> Sigh! Spelling is worse than normal this morning...
> 
> On 2015-08-05 10:58, Johnny Billquist wrote:
> > Not adressing Göra specifically.
> 
> "Göran".
> 
> > VAX Basic is not like GW-BASIC. I suspect the differences are large
> > enough that we could almost call it two different programming languages...
> >
> > Anyway, I'm confused by this whole thread.
> >
> > First of all, VAX Basic is still around. But you still need VMS. I think
> > it's called HP Basic nowadays. The naming went: BAX Basic -> DEC Basic
> > -> COMPAQ Basic (I suspect) -> HP Basic. But the OP asked for something
> > for VMS. So he should be good, and there is no need to do anything. The
> > hobbyist program covers hobby use, so you can get a license, install it,
> > and be happy. No money involved.
> 
> s/BAX/VAX/
> 
> > You should be able to find some info you you just manage to locate the
> > VMS information at HP. HP is confused, so I'm surprised if you have
> > problems finding any kind of information there.
> 
> So I'm *not* surprised if you have problems finding any kind if 
> information around there...
> 
> > Second - translating stuff from VAX Basic to C++ - I fail to see the
> > problem. Normal strings in VAX Basic are dynamic. std::string should fit
> > the bill perfectly. Strings in MAPs are static in size and location. No
> > different than a char [] in C or C++.
> > MAP statements as such are actually pretty much a 1:1 mapping to a
> > static defined struct in C or C++. If you want to do I/O related to a
> > MAP, you'll just do the I/O to the static struct instead, and you're there.
> > COMMONs are the same thing as MAPs, so the same static structs in C work
> > for those too.
> >
> > For strings, you will need some special assignment and compare operators
> > to make it work identical. In VAX Basic, an assignment to a static
> > string (such as in a MAP) will pad the string with spaces at the end.
> > And there are two string comparators. The normal equal operation will
> > consider two strings to be equal even if there are different trailing
> > spaces on either or both strings. There is a second string compare
> > operator if you want to check for exact equality, including string
> > length and trailing spaces.
> >
> > The FIELD statement is just some more data shuffling related to I/O.
> > Nothing difficult about it.
> >
> > MAT statements is something I would skip, as that is more complex, but
> > seldom used.
> >
> > I think that error handling would be a rather difficult part in any
> > translation, though. I don't even care to go into that story here.
> >
> > But the things other have mentioned, I've touched on above, and they are
> > not hard to translate for the most part. But Perl would *not* be a
> > language I would translate to.
> >
> >      Johnny
> 
> Yay!
> 
> 	Johnny
> 
> >
> > On 2015-08-05 08:33, Göran Åhling wrote:
> >>
> >>
> >> Den 2015-08-04 kl. 17:52, skrev Dan Gahlinger:
> >>> 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.
> >>>
> >> If "modern systems" is included in the set of {Win; Mac OSX; Linux;
> >> Android}, why not stay BASIC?
> >> http://www.qb64.net/
> >> I have used it to make old GW-basic-programs usable in a PC of today
> >> (ie. >= Win 7).
> >>
> >> The snag was to run an old GW-basic, load the program into it, and then
> >> save the program using Ascii-mode, to get a file that QB64 can load.
> >> (Actually a file that looks like a LIST print-out, as opposed to the
> >> GW-basic native format)
> >>
> >> It is described in Microsoft Knowledge base: Article ID: 80745
> >>
> >> I was astonished how much of structural-programming possibilities and
> >> support that has been put into this modern BASIC, the step from "old
> >> days" style that was more close to Fortran-4 is immense! It can
> >> definitively be used to write "Pascal-looking" programs.
> >>
> >> In my case, one of the programs I converted didn't work properly, so I
> >> ended up correcting it - taking all line-numbers away was a great start,
> >> as the problem was hidden in GOTO:s by the original author...
> >>
> >> Besides from using the QB-64 once, I have no hooks to it or to its
> >> development...
> >>
> >> /Göran
> >>
> >>> 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 at trailing-edge.com
> >>> http://mailman.trailing-edge.com/mailman/listinfo/simh
> >>
> >>
> >>
> >> _______________________________________________
> >> Simh mailing list
> >> Simh at trailing-edge.com
> >> http://mailman.trailing-edge.com/mailman/listinfo/simh
> >>
> >
> >
> 
> 
> -- 
> Johnny Billquist                  || "I'm on a bus
>                                    ||  on a psychedelic trip
> email: bqt at softjar.se             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150805/3dc78f78/attachment-0001.html>

From bqt at softjar.se  Wed Aug  5 11:59:26 2015
From: bqt at softjar.se (Johnny Billquist)
Date: Wed, 5 Aug 2015 17:59:26 +0200
Subject: [Simh] off-topic basic translator
In-Reply-To: <COL131-W10DF16C0297613702CF6E2C9750@phx.gbl>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl> <55C1AE2C.4040408@eadc.se>
 <55C1D04A.6090101@softjar.se> <55C1D17B.4040602@softjar.se>
 <COL131-W10DF16C0297613702CF6E2C9750@phx.gbl>
Message-ID: <55C232DE.80100@softjar.se>

Hi.

On 2015-08-05 16:19, Dan Gahlinger wrote:
> I would never translate them to C/C++/Perl...

Thanks. :-)

> and the code I want to translate has MAT statements,

Oh well. For I/O, that is more or less just a hidden for-loop. If you 
are doing arithmetic, it's also loops, but a little more involved. 
Nothing magic, though.

> I want to move the code off of VMS to something useful.

You mentioned "Windows", which I would consider less useful. :-)

> I've pretty much settled on freepascal

Well, among things I would consider, Pascal is also pretty far down the 
list. In some ways, Pascal will cause you bigger problems. String 
handling is often rather restricted and weird in Pascal.

> HP Basic translator is discontinued and no longer available, so that's out.
> And according to documentation it doesn't support MAT statements anyhow.

What do you mean "discontinued"? I have not heard of anything like that, 
and I'm pretty sure I've heard that this Basic will also be ported to 
x85, as VMS is moving there. It is definitely still available today, 
that much I know. I don't know what you are looking at, but it's not the 
VMS BASIC compiler.

However, as far as I know, HP have now handed all VMS stuff over to VSI, 
so while you will still be able to buy from HP, they will no longer do 
the development.

> Using the Basic reference manual I found, it seems simple enough
> to do the translations by hand to whatever language.

The tricky parts to move are the string abilities of BASIC, some I/O 
stuff, if you are using that (think indexed filed for example), and 
error handling, which is very different in every language.

> but I definitely won't be using C, C++, C# or Perl.

Well, of those choices (including Pascal), I's say that C++ would 
probably be the easiest to target.

> I''ll probably go with freepascal as I have tons of libraries I've
> written already.

Good luck. :-)

	Johnny

>
> Dan.
>
>
>  > To: simh at trailing-edge.com
>  > From: bqt at softjar.se
>  > Date: Wed, 5 Aug 2015 11:03:55 +0200
>  > Subject: Re: [Simh] off-topic basic translator
>  >
>  > Sigh! Spelling is worse than normal this morning...
>  >
>  > On 2015-08-05 10:58, Johnny Billquist wrote:
>  > > Not adressing Göra specifically.
>  >
>  > "Göran".
>  >
>  > > VAX Basic is not like GW-BASIC. I suspect the differences are large
>  > > enough that we could almost call it two different programming
> languages...
>  > >
>  > > Anyway, I'm confused by this whole thread.
>  > >
>  > > First of all, VAX Basic is still around. But you still need VMS. I
> think
>  > > it's called HP Basic nowadays. The naming went: BAX Basic -> DEC Basic
>  > > -> COMPAQ Basic (I suspect) -> HP Basic. But the OP asked for something
>  > > for VMS. So he should be good, and there is no need to do anything. The
>  > > hobbyist program covers hobby use, so you can get a license,
> install it,
>  > > and be happy. No money involved.
>  >
>  > s/BAX/VAX/
>  >
>  > > You should be able to find some info you you just manage to locate the
>  > > VMS information at HP. HP is confused, so I'm surprised if you have
>  > > problems finding any kind of information there.
>  >
>  > So I'm *not* surprised if you have problems finding any kind if
>  > information around there...
>  >
>  > > Second - translating stuff from VAX Basic to C++ - I fail to see the
>  > > problem. Normal strings in VAX Basic are dynamic. std::string
> should fit
>  > > the bill perfectly. Strings in MAPs are static in size and location. No
>  > > different than a char [] in C or C++.
>  > > MAP statements as such are actually pretty much a 1:1 mapping to a
>  > > static defined struct in C or C++. If you want to do I/O related to a
>  > > MAP, you'll just do the I/O to the static struct instead, and
> you're there.
>  > > COMMONs are the same thing as MAPs, so the same static structs in C
> work
>  > > for those too.
>  > >
>  > > For strings, you will need some special assignment and compare
> operators
>  > > to make it work identical. In VAX Basic, an assignment to a static
>  > > string (such as in a MAP) will pad the string with spaces at the end.
>  > > And there are two string comparators. The normal equal operation will
>  > > consider two strings to be equal even if there are different trailing
>  > > spaces on either or both strings. There is a second string compare
>  > > operator if you want to check for exact equality, including string
>  > > length and trailing spaces.
>  > >
>  > > The FIELD statement is just some more data shuffling related to I/O.
>  > > Nothing difficult about it.
>  > >
>  > > MAT statements is something I would skip, as that is more complex, but
>  > > seldom used.
>  > >
>  > > I think that error handling would be a rather difficult part in any
>  > > translation, though. I don't even care to go into that story here.
>  > >
>  > > But the things other have mentioned, I've touched on above, and
> they are
>  > > not hard to translate for the most part. But Perl would *not* be a
>  > > language I would translate to.
>  > >
>  > > Johnny
>  >
>  > Yay!
>  >
>  > Johnny
>  >
>  > >
>  > > On 2015-08-05 08:33, Göran Åhling wrote:
>  > >>
>  > >>
>  > >> Den 2015-08-04 kl. 17:52, skrev Dan Gahlinger:
>  > >>> 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.
>  > >>>
>  > >> If "modern systems" is included in the set of {Win; Mac OSX; Linux;
>  > >> Android}, why not stay BASIC?
>  > >> http://www.qb64.net/
>  > >> I have used it to make old GW-basic-programs usable in a PC of today
>  > >> (ie. >= Win 7).
>  > >>
>  > >> The snag was to run an old GW-basic, load the program into it, and
> then
>  > >> save the program using Ascii-mode, to get a file that QB64 can load.
>  > >> (Actually a file that looks like a LIST print-out, as opposed to the
>  > >> GW-basic native format)
>  > >>
>  > >> It is described in Microsoft Knowledge base: Article ID: 80745
>  > >>
>  > >> I was astonished how much of structural-programming possibilities and
>  > >> support that has been put into this modern BASIC, the step from "old
>  > >> days" style that was more close to Fortran-4 is immense! It can
>  > >> definitively be used to write "Pascal-looking" programs.
>  > >>
>  > >> In my case, one of the programs I converted didn't work properly, so I
>  > >> ended up correcting it - taking all line-numbers away was a great
> start,
>  > >> as the problem was hidden in GOTO:s by the original author...
>  > >>
>  > >> Besides from using the QB-64 once, I have no hooks to it or to its
>  > >> development...
>  > >>
>  > >> /Göran
>  > >>
>  > >>> 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 at trailing-edge.com
>  > >>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>  > >>
>  > >>
>  > >>
>  > >> _______________________________________________
>  > >> Simh mailing list
>  > >> Simh at trailing-edge.com
>  > >> http://mailman.trailing-edge.com/mailman/listinfo/simh
>  > >>
>  > >
>  > >
>  >
>  >
>  > --
>  > Johnny Billquist || "I'm on a bus
>  > || on a psychedelic trip
>  > email: bqt at softjar.se || Reading murder books
>  > pdp is alive! || tryin' to stay hip" - B. Idol
>  > _______________________________________________
>  > Simh mailing list
>  > Simh at trailing-edge.com
>  > http://mailman.trailing-edge.com/mailman/listinfo/simh


-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

From clemc at ccc.com  Wed Aug  5 15:24:00 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 5 Aug 2015 15:24:00 -0400
Subject: [Simh] off-topic basic translator
In-Reply-To: <55C232DE.80100@softjar.se>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl> <55C1AE2C.4040408@eadc.se>
 <55C1D04A.6090101@softjar.se> <55C1D17B.4040602@softjar.se>
 <COL131-W10DF16C0297613702CF6E2C9750@phx.gbl> <55C232DE.80100@softjar.se>
Message-ID: <CAC20D2OkbcvEqoWH40bAL0YuhASUtEb-Cr6J0psevdmV-zoOMQ@mail.gmail.com>

On Wed, Aug 5, 2015 at 11:59 AM, Johnny Billquist <bqt at softjar.se> wrote:
>
> Pascal is also pretty far down the list. In some ways, Pascal will cause
> you bigger problems.

​Traditional (pure) Pascal - a very very true (and sad) observation.
Although,
I still have a soft spot for it and think its the best >>teaching<<
language ever (beat's Python, Java and C/C++ which seem to be what most of
the young folks learn first].


> String handling is often rather restricted and weird in Pascal.

I agree with you.  What Wirth has in the report is pretty simplistic (and I
hated it).  In fact, later Pascal's added pretty sophisticated support for
strings -- but...  in lots of different ways -- I remember at Tektronix on
the early 1980s we counted about 10 different Tek Pascal's (at the same
Hatfield/McOy party we also counted over 30 different HP Basics).  The
different Pascal extensions of course was a huge downfall of Pascal IMO ->
there were too many differences and not enough commonality.   But alas
Pascal/Modula/Sail/Ada (and BLISS) et al lost to C for economic reasons not
really technical ones [says a long time programmer that has written way for
C code than anything else in my life].

That said, the good news is that Free Pascal [ http://www.freepascal.org ]
which Dan wants to use supports most of the modern Pascal extensions, and
in particular the "Delphi" & TP flavor​s

*"The language syntax has excellent compatibility with TP 7.0 as well as
with most versions of Delphi (classes, rtti, exceptions, ansistrings,
widestrings, interfaces). A Mac Pascal mode, largely compatible with Think
Pascal and MetroWerks Pascal, is also available. Furthermore Free Pascal
supports function overloading, operator overloading, global properties and
several other extra features."*




>
> Well, of those choices (including Pascal), I's say that C++ would probably
> be the easiest to target.

​I have to laugh when I read this.  I actually disagree on that observation
and I admit I'm a little surprised to hear it from a European - many (most)
of my European trained colleagues in the technical languages team here hate
C++ and wonder out loud why the Algol family did not win ("You damned
Americans didn't know <insert your favorite comment here>").

It's funny we were just arguing about this at lunch last Friday.  One of
them was calling the designers and implementors of a large programming
system "incompetent" for picking C++ when they could have used Modula-II or
ever Ada in those days.  [Check out a great treatise: "The big problem we
face isn't coordinated cyber-terrorism, it's that software sucks" -
https://medium.com/@felixsalmon/this-is-a-very-lightly-edited-version-of-my-gist-spiel-3fb7eee4c4e5
 ]

Anyway, for someone comfortable with Pascal or Modula for similar family, I
think using Free Pascal should not be much different than using C++ -- you
pretty have all of the same tools at your disposal.  It's about how much
you know how to bring to bear on the problem.



>
>
> I''ll probably go with freepascal as I have tons of libraries I've
>> written already.
>>
>
​That seems like as good a reason as any I have heard.

Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150805/03f639f9/attachment.html>

From dgahling at hotmail.com  Wed Aug  5 15:56:34 2015
From: dgahling at hotmail.com (Dan Gahlinger)
Date: Wed, 5 Aug 2015 15:56:34 -0400
Subject: [Simh] off-topic basic translator
In-Reply-To: <CAC20D2OkbcvEqoWH40bAL0YuhASUtEb-Cr6J0psevdmV-zoOMQ@mail.gmail.com>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>,
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>
 <55C1AE2C.4040408@eadc.se>,<55C1D04A.6090101@softjar.se>
 <55C1D17B.4040602@softjar.se>,<COL131-W10DF16C0297613702CF6E2C9750@phx.gbl>
 <55C232DE.80100@softjar.se>,
 <CAC20D2OkbcvEqoWH40bAL0YuhASUtEb-Cr6J0psevdmV-zoOMQ@mail.gmail.com>
Message-ID: <COL131-W2556C27406D10709EAFC3FC9750@phx.gbl>

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.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150805/6e07d412/attachment.html>

From dave.g4ugm at gmail.com  Wed Aug  5 16:21:36 2015
From: dave.g4ugm at gmail.com (Dave G4UGM)
Date: Wed, 5 Aug 2015 21:21:36 +0100
Subject: [Simh] off-topic basic translator
In-Reply-To: <COL131-W2556C27406D10709EAFC3FC9750@phx.gbl>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>,
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>
 <55C1AE2C.4040408@eadc.se>,
 <55C1D04A.6090101@softjar.se> <55C1D17B.4040602@softjar.se>,
 <COL131-W10DF16C0297613702CF6E2C9750@phx.gbl> <55C232DE.80100@softjar.se>,
 <CAC20D2OkbcvEqoWH40bAL0YuhASUtEb-Cr6J0psevdmV-zoOMQ@mail.gmail.com>
 <COL131-W2556C27406D10709EAFC3FC9750@phx.gbl>
Message-ID: <073701d0cfbc$5575d010$00617030$@gmail.com>

As I am sure most of you know ANSI escapes don't work in "modern" windows
command shell.
 
http://stackoverflow.com/questions/16755142/how-to-make-win32-console-recogn
ize-ansi-vt100-escape-sequences
 
Dave Wade
G4UGM
 
From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of Dan
Gahlinger
Sent: 05 August 2015 20:57
To: simh at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150805/3d719a92/attachment-0001.html>

From dgahling at hotmail.com  Wed Aug  5 16:26:43 2015
From: dgahling at hotmail.com (Dan Gahlinger)
Date: Wed, 5 Aug 2015 16:26:43 -0400
Subject: [Simh] off-topic basic translator
In-Reply-To: <073701d0cfbc$5575d010$00617030$@gmail.com>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>, ,
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl>, <55C1AE2C.4040408@eadc.se>, ,
 <55C1D04A.6090101@softjar.se>
 <55C1D17B.4040602@softjar.se>,,<COL131-W10DF16C0297613702CF6E2C9750@phx.gbl>
 <55C232DE.80100@softjar.se>, ,
 <CAC20D2OkbcvEqoWH40bAL0YuhASUtEb-Cr6J0psevdmV-zoOMQ@mail.gmail.com>,
 <COL131-W2556C27406D10709EAFC3FC9750@phx.gbl>,
 <073701d0cfbc$5575d010$00617030$@gmail.com>
Message-ID: <COL131-W57D0ED354B983A9979173BC9750@phx.gbl>

Ansicon looks interesting
freepascal also has functions built-in but that would need conversion of the code.
maybe I should forget dos/windows, it's almost dead anyhow :)

Dan.

From: dave.g4ugm at gmail.com
To: simh at trailing-edge.com
Date: Wed, 5 Aug 2015 21:21:36 +0100
Subject: Re: [Simh] off-topic basic translator

As I am sure most of you know ANSI escapes don’t work in “modern” windows command shell. http://stackoverflow.com/questions/16755142/how-to-make-win32-console-recognize-ansi-vt100-escape-sequences Dave WadeG4UGM From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of Dan Gahlinger
Sent: 05 August 2015 20:57
To: simh at 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 at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150805/9dd03590/attachment.html>

From ahling at eadc.se  Wed Aug  5 18:21:01 2015
From: ahling at eadc.se (=?UTF-8?B?R8O2cmFuIMOFaGxpbmc=?=)
Date: Thu, 6 Aug 2015 00:21:01 +0200
Subject: [Simh] off-topic basic translator
In-Reply-To: <55C1D04A.6090101@softjar.se>
References: <7e9655ca650eb2aa91b9cc69c45f7d37@email.freenet.de>
 <COL131-W68A53A18BA482AB0F54D20C9760@phx.gbl> <55C1AE2C.4040408@eadc.se>
 <55C1D04A.6090101@softjar.se>
Message-ID: <55C28C4D.6040703@eadc.se>

No offence taken!

I'm fully aware that DEC-Basic not equals GW-basic, but I'd guess the 
similarities between DEC-Basic and QB-64 really are larger than those 
between DEC-basic and Pascal / C / C++ / Perl / ... (Please note that 
QB-64 seems to be a quite modern BASIC, but still compatible with older 
MS-basic. Please also note that I prefer Pascal rather than BASIC ;-)

More similar should mean less complicated to translate in my humble opinion!

If I'm not mistaken, the QB-64 seems to be a translator from Basic to 
C++ (from reading the "Linux-requirements" for it), and if writing a 
Basic--> ? - translator, is on the table, it might be less work to start 
with one working translator and improve it from taking GW-basic source 
into taking DEC-Basic... (or having a flag/option for it?)

This written just to bring some ideas to discuss into the air.

Göran

On 2015-08-05 10:58, Johnny Billquist wrote:
> Not adressing Göra specifically.
>
> VAX Basic is not like GW-BASIC. I suspect the differences are large 
> enough that we could almost call it two different programming 
> languages...
>
> Anyway, I'm confused by this whole thread.
>
> First of all, VAX Basic is still around. But you still need VMS. I 
> think it's called HP Basic nowadays. The naming went: BAX Basic -> DEC 
> Basic -> COMPAQ Basic (I suspect) -> HP Basic. But the OP asked for 
> something for VMS. So he should be good, and there is no need to do 
> anything. The hobbyist program covers hobby use, so you can get a 
> license, install it, and be happy. No money involved.
>
> You should be able to find some info you you just manage to locate the 
> VMS information at HP. HP is confused, so I'm surprised if you have 
> problems finding any kind of information there.
>
> Second - translating stuff from VAX Basic to C++ - I fail to see the 
> problem. Normal strings in VAX Basic are dynamic. std::string should 
> fit the bill perfectly. Strings in MAPs are static in size and 
> location. No different than a char [] in C or C++.
> MAP statements as such are actually pretty much a 1:1 mapping to a 
> static defined struct in C or C++. If you want to do I/O related to a 
> MAP, you'll just do the I/O to the static struct instead, and you're 
> there.
> COMMONs are the same thing as MAPs, so the same static structs in C 
> work for those too.
>
> For strings, you will need some special assignment and compare 
> operators to make it work identical. In VAX Basic, an assignment to a 
> static string (such as in a MAP) will pad the string with spaces at 
> the end. And there are two string comparators. The normal equal 
> operation will consider two strings to be equal even if there are 
> different trailing spaces on either or both strings. There is a second 
> string compare operator if you want to check for exact equality, 
> including string length and trailing spaces.
>
> The FIELD statement is just some more data shuffling related to I/O. 
> Nothing difficult about it.
>
> MAT statements is something I would skip, as that is more complex, but 
> seldom used.
>
> I think that error handling would be a rather difficult part in any 
> translation, though. I don't even care to go into that story here.
>
> But the things other have mentioned, I've touched on above, and they 
> are not hard to translate for the most part. But Perl would *not* be a 
> language I would translate to.
>
>     Johnny
>
> On 2015-08-05 08:33, Göran Åhling wrote:
>>
>>
>> Den 2015-08-04 kl. 17:52, skrev Dan Gahlinger:
>>> 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.
>>>
>> If "modern systems" is included in the set of {Win; Mac OSX; Linux;
>> Android}, why not stay BASIC?
>> http://www.qb64.net/
>> I have used it to make old GW-basic-programs usable in a PC of today
>> (ie. >= Win 7).
>>
>> The snag was to run an old GW-basic, load the program into it, and then
>> save the program using Ascii-mode, to get a file that QB64 can load.
>> (Actually a file that looks like a LIST print-out, as opposed to the
>> GW-basic native format)
>>
>> It is described in Microsoft Knowledge base: Article ID: 80745
>>
>> I was astonished how much of structural-programming possibilities and
>> support that has been put into this modern BASIC, the step from "old
>> days" style that was more close to Fortran-4 is immense! It can
>> definitively be used to write "Pascal-looking" programs.
>>
>> In my case, one of the programs I converted didn't work properly, so I
>> ended up correcting it - taking all line-numbers away was a great start,
>> as the problem was hidden in GOTO:s by the original author...
>>
>> Besides from using the QB-64 once, I have no hooks to it or to its
>> development...
>>
>> /Göran
>>
>>> 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 at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>
>


From khandy21yo at gmail.com  Wed Aug  5 20:33:27 2015
From: khandy21yo at gmail.com (khandy21yo)
Date: Wed, 05 Aug 2015 18:33:27 -0600
Subject: [Simh] off-topic basic translator
Message-ID: <yjua05qd8v83wuhw470wve8w.1438821011309@email.android.com>

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 <dgahling at hotmail.com> 
Date: 08/05/2015  1:56 PM  (GMT-07:00) 
To simh at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150805/4dfaaa82/attachment.html>

From Ken.Cornetet at kimballelectronics.com  Thu Aug  6 09:35:21 2015
From: Ken.Cornetet at kimballelectronics.com (Ken Cornetet)
Date: Thu, 6 Aug 2015 13:35:21 +0000
Subject: [Simh] off-topic basic translator
In-Reply-To: <yjua05qd8v83wuhw470wve8w.1438821011309@email.android.com>
References: <yjua05qd8v83wuhw470wve8w.1438821011309@email.android.com>
Message-ID: <544be9579c244e8cabaeee53a84fb841@NTS1115.kei.keint.com>

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-bounces at trailing-edge.com] On Behalf Of khandy21yo
Sent: Wednesday, August 05, 2015 8:33 PM
To: Dan Gahlinger; simh at 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 <dgahling at hotmail.com<mailto:dgahling at hotmail.com>>
Date: 08/05/2015 1:56 PM (GMT-07:00)
To simh at trailing-edge.com<mailto:simh at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150806/265423e3/attachment-0001.html>

From rft at asthomas.com  Thu Aug  6 10:45:49 2015
From: rft at asthomas.com (Robert Thomas)
Date: Thu, 6 Aug 2015 10:45:49 -0400
Subject: [Simh] off-topic basic translator
Message-ID: <012001d0d056$98a68880$c9f39980$@asthomas.com>

I'm sure that I'm missing something, but VAX/VMS runs very well under SIMH.
If you have access to the hobbyist program it is straightforward to install
VMS and Basic.  We have a number of very old Basic programs that haven't yet
been converted to Itanium VMS 8.4 that when they are needed (approximately
once per year), we start SIMH on a PC and boot the "MicroVAX".  It never
ceases to amaze us how small and efficient SIMH, the VAX emulators, VMS with
all of the layered products are when compared to the "modern" operating
systems.  The performance of the emulated MicroVAX on a relatively recent PC
is very good.

 

When properly configured, the emulated MicroVAX system can become part of a
cluster (although there is no official support for mixed VAX 7.3 and
Itanium-64 8.4 clusters).  We are able to use DECWindows/MOTIF to connect
from PC's and VMS systems to the emulated system. 

 

Sincerely,

Robert F. Thomas

A. S. Thomas, Inc.

 44 Industrial Way 
Norwood, MA USA 02062
*  Office Phone - (781) 329-9200
* mail to: rft at asthomas.com

 

[Disclaimer] WARNING- This document may contain technical data whose export
is restricted by the Arms Export Control Act (Title 22, U.S.C., SEQ 2751 ET
SEQ) or the Export Administration Act (Title 50, U.S.C., APP 2401-2420).
Violations of these export laws are subject to severe criminal penalties.
This e-mail is strictly confidential and intended solely for the addressee.
It may contain information which is covered by legal, professional, or other
privilege. If you are not the intended addressee you must not use, disclose,
or copy this transmission. This E-mail is not intended to impose nor shall
it be construed as imposing any legally binding obligation upon A. S.
Thomas, Inc. ("AST"), and/or any subsidiaries thereof or associated
companies therof. Neither AST nor any subsidiaries thereof or associated
companies thereof gives any representation or warranty as to the accuracy or
completeness of the contents of this E-mail. AST shall not be held liable to
any person resulting from the use of any information contained in this
E-mail and shall not be liable to any person who acts or omits to do
anything in reliance upon it.  Unendorsed export or re-export is prohibited.


 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150806/76ca2877/attachment.html>

From el at lisse.NA  Thu Aug  6 11:21:45 2015
From: el at lisse.NA (Dr Eberhard Lisse)
Date: Thu, 6 Aug 2015 16:21:45 +0100
Subject: [Simh] off-topic basic translator
In-Reply-To: <012001d0d056$98a68880$c9f39980$@asthomas.com>
References: <012001d0d056$98a68880$c9f39980$@asthomas.com>
Message-ID: <55C37B89.4000904@lisse.NA>

Robert,

do you have a cookbook on how to install (and in particular the
networking)?

I am struggling with this on Mac.

It's only a blast from the past (Medical School 30 years ago) but I
would like to run it eventually on a MacPro and perhaps even on
Ubuntu 14.04 (outward facing :-)-O).

greetings, el


On 2015-08-06 15:45, Robert Thomas wrote:
> I’m sure that I’m missing something, but VAX/VMS runs very
> well under SIMH. If you have access to the hobbyist program it is
> straightforward to install VMS and Basic.  We have a number of
> very old Basic programs that haven’t yet been converted to
> Itanium VMS 8.4 that when they are needed (approximately once per
> year), we start SIMH on a PC and boot the “MicroVAX”.  It
> never ceases to amaze us how small and efficient SIMH, the VAX
> emulators, VMS with all of the layered products are when compared
> to the “modern” operating systems.  The performance of the
> emulated MicroVAX on a relatively recent PC is very good.
> 
>  
> 
> When properly configured, the emulated MicroVAX system can become
> part of a cluster (although there is no official support for mixed
> VAX 7.3 and Itanium-64 8.4 clusters).  We are able to use
> DECWindows/MOTIF to connect from PC’s and VMS systems to the
> emulated system.
> 
>  
> 
> Sincerely,
> 
> Robert F. Thomas
[...]

-- 
Dr. Eberhard W. Lisse  \        / Obstetrician & Gynaecologist (Saar)
el at lisse.NA            / *     |   Telephone: +264 81 124 6733 (cell)
PO Box 8421             \     /
Bachbrecht, Namibia     ;____/

From rft at asthomas.com  Thu Aug  6 11:53:37 2015
From: rft at asthomas.com (Robert Thomas)
Date: Thu, 6 Aug 2015 11:53:37 -0400
Subject: [Simh] off-topic basic translator
In-Reply-To: <55C37B89.4000904@lisse.NA>
References: <012001d0d056$98a68880$c9f39980$@asthomas.com>
 <55C37B89.4000904@lisse.NA>
Message-ID: <016f01d0d060$10f23150$32d693f0$@asthomas.com>

I'm sorry.  I've only installed it on Windows.  I'm sure others have experience with OS-X.  The networking and other installation issues are addressed in http://simh.trailing-edge.com/pdf/simh_faq.pdf see specifically:

2.3 How do I install SIMH on Unix/Linux/OS-X?
Ethernet support is available only on Linux, OS-X, NetBSD, OpenBSD, FreeBSD and Solaris.
- Unzip the archive of sources to a new directory. You must specify the -a switch to unzip for
proper conversion of Windows cr-lf sequences to UNIX newline sequences.
- The makefile included in the simh source distribution is a GNU make makefile. Some systems
have GNU make as the default make (i.e. Linux). If your system’s make is not GNU make, then 
be sure to install the GNU make package first and then use the ‘gmake’ command instead of
‘make’:
% make all
- If you want Ethernet support in the PDP-11, VAX or VAX780, you should install your OS
distribution’s libpcap-devel package prior to building the simulator:
- More details about Ethernet installation and configuration can be found in the
0readme_ethernet.txt file in the simh sources. 


Sincerely,
Robert F. Thomas

 44 Industrial Way 
Norwood, MA USA 02062
N  Office Phone - (781) 329-9200
O mail to: rft at asthomas.com
 

-----Original Message-----
From: Dr Eberhard Lisse [mailto:el at lisse.NA] 
Sent: Thursday, August 6, 2015 11:22 AM
To: rft at asthomas.com
Cc: simh at trailing-edge.com; nigel at roberts.co.uk; sdeerhake at gmail.com
Subject: Re: [Simh] off-topic basic translator

Robert,

do you have a cookbook on how to install (and in particular the networking)?

I am struggling with this on Mac.

It's only a blast from the past (Medical School 30 years ago) but I would like to run it eventually on a MacPro and perhaps even on Ubuntu 14.04 (outward facing :-)-O).

greetings, el


-- 
Dr. Eberhard W. Lisse  \        / Obstetrician & Gynaecologist (Saar)
el at lisse.NA            / *     |   Telephone: +264 81 124 6733 (cell)
PO Box 8421             \     /
Bachbrecht, Namibia     ;____/


From tvoverbeek at esa.nascom.nasa.gov  Thu Aug  6 12:15:35 2015
From: tvoverbeek at esa.nascom.nasa.gov (Ton van Overbeek)
Date: Thu, 06 Aug 2015 18:15:35 +0200
Subject: [Simh] off-topic basic translator
In-Reply-To: <55C37B89.4000904@lisse.NA>
References: <012001d0d056$98a68880$c9f39980$@asthomas.com>
 <55C37B89.4000904@lisse.NA>
Message-ID: <D1E95476.13863%tvoverbeek@esa.nascom.nasa.gov>

For a cookbook look at
http://www.wherry.com/gadgets/retrocomputing/vax-simh.html
It includes setting up TCP/IP.
It is for Linux, but most of it is applicable to OS X too.
At the end is how to install Basic.
Just tried to install Basic on my OS X simh running VAX VMS 7.3. Installs
fine.

Ton van Overbeek



>



From frisbie at flying-disk.com  Thu Aug  6 22:53:58 2015
From: frisbie at flying-disk.com (Alan Frisbie)
Date: Thu, 6 Aug 2015 19:53:58 -0700 (PDT)
Subject: [Simh] Problem with default builds
Message-ID: <15080619535827_449@slug.flying-disk.com>

Another build error.   Unfortunately, I do not have the knowledge
to fix it myself.

Today, 6-Aug-2015, I downloaded the current simh-master.zip from
github.

My host is an Alpha XP1000 running VMS v8.4

Using MMK from the VMS Freeware 8 CD, I tried to do a default
build of all SIMH simulators.   All went well until the build of
ID16-AXP.OLB Library.   At that point I got the error:

    { "DP", SWMASK ('F'), 9, 0x32, o_DP0, o_DPF },
............^
%CC-E-NEEDCONSTEXPR, In the initializer for dboot_tab[1].sw,
"sim_swmask(...)" is not constant, but occurs in a context that requires a constant
expression.
at line number 318 in file DKA200:[FRISBIE.SIMH.SIMH-MASTER.INTERDATA]ID16_DBOOT.C;4
%MMK-F-ERRUPD, error status %X10B91262 occurred when updating
target SYS$DISK:[.BIN.VMS.LIB]ID16-AXP.OLB


The log of the build (with lots of successful stuff snipped)
follows below.

Thanks,
Alan Frisbie

--------------------------------------------------

$ unzip simh-master.zip
Archive:  DKA200:[FRISBIE.SIMH]SIMH-MASTER.ZIP;5
7c7b44e409f05751c960a614dbb1e2abde22da60
replace [.simh-master].gitattributes? [y]es, [n]o, [A]ll, [N]one, [r]ename: A

  inflating: [.simh-master].gitattributes
  inflating: [.simh-master].gitignore
  inflating: [.simh-master]0readmeAsynchIO.txt
  inflating: [.simh-master]0readme_39.txt
...
  inflating: [.simh-master.swtp6800.swtp6800]swtp6800mp-a2.ini
  inflating: [.simh-master.swtp6800.swtp6800]swtp_defs.h
  inflating: [.simh-master.swtp6800.swtp6800]swtp_swtbug_bin.h
$
$ set default [.simh-master]
$ $ set file/attri=rfm:stm makefile,*.mms,[...]*.c,[...]*.h,[...]*.txt
$
$ mmk
$!
$! Building The SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB
Library.
$!
$ CC/DECC/PREF=ALL/DEBUG/OPT=(LEV=5)/ARCH=HOST 
/NEST=PRIMARY/NAME=(AS_IS,SHORT)/DEF=("_LA
RGEFILE","SIM_ASYNCH_IO=1")  /OBJ=SYS$DISK:[.BIN.VMS.LIB.BLD-AXP]
SYS$DISK:[]SIM_CONSOLE.C
,SYS$DISK:[]SIM_SOCK.C,SYS$DISK:[]SIM_TMXR.C,SYS$DISK:[]SIM_ETHER.C,SYS$DISK:[]SIM_TAPE.C,
SYS$DISK:[]SIM_FIO.C,SYS$DISK:[]SIM_TIMER.C,SYS$DISK:[]SIM_DISK.C,SYS$DISK:[]SIM_SERIAL.C,
SYS$DISK:[]SIM_VIDEO.C
$ IF (F$SEARCH("SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB").EQS."")
THEN  LIBRARY/CREATE SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB
$ LIBRARY/REPLACE SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB
SYS$DISK:[.BIN.VMS.LIB.BLD-AXP]*.OBJ
$ DELETE/NOLOG/NOCONFIRM SYS$DISK:[.BIN.VMS.LIB.BLD-AXP]*.OBJ;*
$!
$! Building The SYS$DISK:[.BIN.VMS.LIB]ALTAIR-AXP.OLB Library.
...
...
$! IBM1130 done
$!
$! Building The SYS$DISK:[.BIN.VMS.LIB]ID16-AXP.OLB Library.
$!
$ CC/DECC/PREF=ALL/DEBUG/OPT=(LEV=5)/ARCH=HOST 
/NEST=PRIMARY/NAME=(AS_IS,SHORT)/INCL=(SYS
$DISK:[],SYS$DISK:[.INTERDATA])/DEF=("_LARGEFILE","SIM_ASYNCH_IO=1") 
/OBJ=SYS$DISK:[.BIN.
VMS.LIB.BLD-AXP]
SYS$DISK:[.INTERDATA]ID16_CPU.C,SYS$DISK:[.INTERDATA]ID16_SYS.C,SYS$DISK:
[.INTERDATA]ID_DP.C,SYS$DISK:[.INTERDATA]ID_FD.C,SYS$DISK:[.INTERDATA]ID_FP.C,SYS$DISK:[.I
NTERDATA]ID_IDC.C,SYS$DISK:[.INTERDATA]ID_IO.C,SYS$DISK:[.INTERDATA]ID_LP.C,SYS$DISK:[.INT
ERDATA]ID_MT.C,SYS$DISK:[.INTERDATA]ID_PAS.C,SYS$DISK:[.INTERDATA]ID_PT.C,SYS$DISK:[.INTER
DATA]ID_TT.C,SYS$DISK:[.INTERDATA]ID_UVC.C,SYS$DISK:[.INTERDATA]ID16_DBOOT.C,SYS$DISK:[.IN
TERDATA]ID_TTP.C

    { "DP", SWMASK ('F'), 9, 0x32, o_DP0, o_DPF },
............^
%CC-E-NEEDCONSTEXPR, In the initializer for dboot_tab[1].sw,
"sim_swmask(...)" is not constant, but occurs in a context that requires a constant
expression.
at line number 318 in file DKA200:[FRISBIE.SIMH.SIMH-MASTER.INTERDATA]ID16_DBOOT.C;4
%MMK-F-ERRUPD, error status %X10B91262 occurred when updating target SYS$DISK:[.BIN.VMS.LI
B]ID16-AXP.OLB
$

--------------------------------------------------

From khandy21yo at gmail.com  Thu Aug  6 23:23:52 2015
From: khandy21yo at gmail.com (khandy21yo)
Date: Thu, 06 Aug 2015 21:23:52 -0600
Subject: [Simh] Problem with default builds
Message-ID: <o0f9l08dsawdyhxct6guldnj.1438917653489@email.android.com>

Wasnr rgere a recent change to tge SWMASK macro,
Gcc peobably optimizes this reference, but dev c must not.

-------- Original message --------
From Alan Frisbie <frisbie at flying-disk.com> 
Date: 08/06/2015  8:53 PM  (GMT-07:00) 
To SIMH at trailing-edge.com 
Subject [Simh] Problem with default builds 
 
Another build error.   Unfortunately, I do not have the knowledge
to fix it myself.

Today, 6-Aug-2015, I downloaded the current simh-master.zip from
github.

My host is an Alpha XP1000 running VMS v8.4

Using MMK from the VMS Freeware 8 CD, I tried to do a default
build of all SIMH simulators.   All went well until the build of
ID16-AXP.OLB Library.   At that point I got the error:

    { "DP", SWMASK ('F'), 9, 0x32, o_DP0, o_DPF },
............^
%CC-E-NEEDCONSTEXPR, In the initializer for dboot_tab[1].sw,
"sim_swmask(...)" is not constant, but occurs in a context that requires a constant
expression.
at line number 318 in file DKA200:[FRISBIE.SIMH.SIMH-MASTER.INTERDATA]ID16_DBOOT.C;4
%MMK-F-ERRUPD, error status %X10B91262 occurred when updating
target SYS$DISK:[.BIN.VMS.LIB]ID16-AXP.OLB


The log of the build (with lots of successful stuff snipped)
follows below.

Thanks,
Alan Frisbie

--------------------------------------------------

$ unzip simh-master.zip
Archive:  DKA200:[FRISBIE.SIMH]SIMH-MASTER.ZIP;5
7c7b44e409f05751c960a614dbb1e2abde22da60
replace [.simh-master].gitattributes? [y]es, [n]o, [A]ll, [N]one, [r]ename: A

  inflating: [.simh-master].gitattributes
  inflating: [.simh-master].gitignore
  inflating: [.simh-master]0readmeAsynchIO.txt
  inflating: [.simh-master]0readme_39.txt
...
  inflating: [.simh-master.swtp6800.swtp6800]swtp6800mp-a2.ini
  inflating: [.simh-master.swtp6800.swtp6800]swtp_defs.h
  inflating: [.simh-master.swtp6800.swtp6800]swtp_swtbug_bin.h
$
$ set default [.simh-master]
$ $ set file/attri=rfm:stm makefile,*.mms,[...]*.c,[...]*.h,[...]*.txt
$
$ mmk
$!
$! Building The SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB
Library.
$!
$ CC/DECC/PREF=ALL/DEBUG/OPT=(LEV=5)/ARCH=HOST 
/NEST=PRIMARY/NAME=(AS_IS,SHORT)/DEF=("_LA
RGEFILE","SIM_ASYNCH_IO=1")  /OBJ=SYS$DISK:[.BIN.VMS.LIB.BLD-AXP]
SYS$DISK:[]SIM_CONSOLE.C
,SYS$DISK:[]SIM_SOCK.C,SYS$DISK:[]SIM_TMXR.C,SYS$DISK:[]SIM_ETHER.C,SYS$DISK:[]SIM_TAPE.C,
SYS$DISK:[]SIM_FIO.C,SYS$DISK:[]SIM_TIMER.C,SYS$DISK:[]SIM_DISK.C,SYS$DISK:[]SIM_SERIAL.C,
SYS$DISK:[]SIM_VIDEO.C
$ IF (F$SEARCH("SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB").EQS."")
THEN  LIBRARY/CREATE SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB
$ LIBRARY/REPLACE SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB
SYS$DISK:[.BIN.VMS.LIB.BLD-AXP]*.OBJ
$ DELETE/NOLOG/NOCONFIRM SYS$DISK:[.BIN.VMS.LIB.BLD-AXP]*.OBJ;*
$!
$! Building The SYS$DISK:[.BIN.VMS.LIB]ALTAIR-AXP.OLB Library.
...
...
$! IBM1130 done
$!
$! Building The SYS$DISK:[.BIN.VMS.LIB]ID16-AXP.OLB Library.
$!
$ CC/DECC/PREF=ALL/DEBUG/OPT=(LEV=5)/ARCH=HOST 
/NEST=PRIMARY/NAME=(AS_IS,SHORT)/INCL=(SYS
$DISK:[],SYS$DISK:[.INTERDATA])/DEF=("_LARGEFILE","SIM_ASYNCH_IO=1") 
/OBJ=SYS$DISK:[.BIN.
VMS.LIB.BLD-AXP]
SYS$DISK:[.INTERDATA]ID16_CPU.C,SYS$DISK:[.INTERDATA]ID16_SYS.C,SYS$DISK:
[.INTERDATA]ID_DP.C,SYS$DISK:[.INTERDATA]ID_FD.C,SYS$DISK:[.INTERDATA]ID_FP.C,SYS$DISK:[.I
NTERDATA]ID_IDC.C,SYS$DISK:[.INTERDATA]ID_IO.C,SYS$DISK:[.INTERDATA]ID_LP.C,SYS$DISK:[.INT
ERDATA]ID_MT.C,SYS$DISK:[.INTERDATA]ID_PAS.C,SYS$DISK:[.INTERDATA]ID_PT.C,SYS$DISK:[.INTER
DATA]ID_TT.C,SYS$DISK:[.INTERDATA]ID_UVC.C,SYS$DISK:[.INTERDATA]ID16_DBOOT.C,SYS$DISK:[.IN
TERDATA]ID_TTP.C

    { "DP", SWMASK ('F'), 9, 0x32, o_DP0, o_DPF },
............^
%CC-E-NEEDCONSTEXPR, In the initializer for dboot_tab[1].sw,
"sim_swmask(...)" is not constant, but occurs in a context that requires a constant
expression.
at line number 318 in file DKA200:[FRISBIE.SIMH.SIMH-MASTER.INTERDATA]ID16_DBOOT.C;4
%MMK-F-ERRUPD, error status %X10B91262 occurred when updating target SYS$DISK:[.BIN.VMS.LI
B]ID16-AXP.OLB
$

--------------------------------------------------
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150806/0b5d42ff/attachment.html>

From Mark at infocomm.com  Fri Aug  7 12:47:14 2015
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Fri, 7 Aug 2015 09:47:14 -0700
Subject: [Simh] Problem with default builds
In-Reply-To: <o0f9l08dsawdyhxct6guldnj.1438917653489@email.android.com>
References: <o0f9l08dsawdyhxct6guldnj.1438917653489@email.android.com>
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A823733C096A@REDROOF2.alohasunset.com>

Sorry folks.  The problem occurs anywhere the SWMASK is used in a static initializer.  I’ve reverted the recent change.

The change was initially thought to be benign and attempted to allows for the simh source to be useful on systems with other than ASCII character sets (i.e. EBCDIC).  There are other issues with simulators running on hosts with EBCDIC character sets which are unrelated to the source code.  If/when those are also addressed, we’ll revisit how to solve the non ASCII source code issue as well.


-        Mark

From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of khandy21yo
Sent: Thursday, August 6, 2015 8:24 PM
To: Alan Frisbie <frisbie at flying-disk.com>; SIMH at trailing-edge.com
Subject: Re: [Simh] Problem with default builds

Wasnr rgere a recent change to tge SWMASK macro,
Gcc peobably optimizes this reference, but dev c must not.



-------- Original message --------
From Alan Frisbie <frisbie at flying-disk.com<mailto:frisbie at flying-disk.com>>
Date: 08/06/2015 8:53 PM (GMT-07:00)
To SIMH at trailing-edge.com<mailto:SIMH at trailing-edge.com>
Subject [Simh] Problem with default builds


Another build error.   Unfortunately, I do not have the knowledge
to fix it myself.

Today, 6-Aug-2015, I downloaded the current simh-master.zip from
github.

My host is an Alpha XP1000 running VMS v8.4

Using MMK from the VMS Freeware 8 CD, I tried to do a default
build of all SIMH simulators.   All went well until the build of
ID16-AXP.OLB Library.   At that point I got the error:

    { "DP", SWMASK ('F'), 9, 0x32, o_DP0, o_DPF },
............^
%CC-E-NEEDCONSTEXPR, In the initializer for dboot_tab[1].sw,
"sim_swmask(...)" is not constant, but occurs in a context that requires a constant
expression.
at line number 318 in file DKA200:[FRISBIE.SIMH.SIMH-MASTER.INTERDATA]ID16_DBOOT.C;4
%MMK-F-ERRUPD, error status %X10B91262 occurred when updating
target SYS$DISK:[.BIN.VMS.LIB]ID16-AXP.OLB


The log of the build (with lots of successful stuff snipped)
follows below.

Thanks,
Alan Frisbie

--------------------------------------------------

$ unzip simh-master.zip
Archive:  DKA200:[FRISBIE.SIMH]SIMH-MASTER.ZIP;5
7c7b44e409f05751c960a614dbb1e2abde22da60
replace [.simh-master].gitattributes? [y]es, [n]o, [A]ll, [N]one, [r]ename: A

  inflating: [.simh-master].gitattributes
  inflating: [.simh-master].gitignore
  inflating: [.simh-master]0readmeAsynchIO.txt
  inflating: [.simh-master]0readme_39.txt
...
  inflating: [.simh-master.swtp6800.swtp6800]swtp6800mp-a2.ini
  inflating: [.simh-master.swtp6800.swtp6800]swtp_defs.h
  inflating: [.simh-master.swtp6800.swtp6800]swtp_swtbug_bin.h
$
$ set default [.simh-master]
$ $ set file/attri=rfm:stm makefile,*.mms,[...]*.c,[...]*.h,[...]*.txt
$
$ mmk
$!
$! Building The SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB
Library.
$!
$ CC/DECC/PREF=ALL/DEBUG/OPT=(LEV=5)/ARCH=HOST
/NEST=PRIMARY/NAME=(AS_IS,SHORT)/DEF=("_LA
RGEFILE","SIM_ASYNCH_IO=1")  /OBJ=SYS$DISK:[.BIN.VMS.LIB.BLD-AXP]
SYS$DISK:[]SIM_CONSOLE.C
,SYS$DISK:[]SIM_SOCK.C,SYS$DISK:[]SIM_TMXR.C,SYS$DISK:[]SIM_ETHER.C,SYS$DISK:[]SIM_TAPE.C,
SYS$DISK:[]SIM_FIO.C,SYS$DISK:[]SIM_TIMER.C,SYS$DISK:[]SIM_DISK.C,SYS$DISK:[]SIM_SERIAL.C,
SYS$DISK:[]SIM_VIDEO.C
$ IF (F$SEARCH("SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB").EQS."")
THEN  LIBRARY/CREATE SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB
$ LIBRARY/REPLACE SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB
SYS$DISK:[.BIN.VMS.LIB.BLD-AXP]*.OBJ
$ DELETE/NOLOG/NOCONFIRM SYS$DISK:[.BIN.VMS.LIB.BLD-AXP]*.OBJ;*
$!
$! Building The SYS$DISK:[.BIN.VMS.LIB]ALTAIR-AXP.OLB Library.
...
...
$! IBM1130 done
$!
$! Building The SYS$DISK:[.BIN.VMS.LIB]ID16-AXP.OLB Library.
$!
$ CC/DECC/PREF=ALL/DEBUG/OPT=(LEV=5)/ARCH=HOST
/NEST=PRIMARY/NAME=(AS_IS,SHORT)/INCL=(SYS
$DISK:[],SYS$DISK:[.INTERDATA])/DEF=("_LARGEFILE","SIM_ASYNCH_IO=1")
/OBJ=SYS$DISK:[.BIN.
VMS.LIB.BLD-AXP]
SYS$DISK:[.INTERDATA]ID16_CPU.C,SYS$DISK:[.INTERDATA]ID16_SYS.C,SYS$DISK:
[.INTERDATA]ID_DP.C,SYS$DISK:[.INTERDATA]ID_FD.C,SYS$DISK:[.INTERDATA]ID_FP.C,SYS$DISK:[.I
NTERDATA]ID_IDC.C,SYS$DISK:[.INTERDATA]ID_IO.C,SYS$DISK:[.INTERDATA]ID_LP.C,SYS$DISK:[.INT
ERDATA]ID_MT.C,SYS$DISK:[.INTERDATA]ID_PAS.C,SYS$DISK:[.INTERDATA]ID_PT.C,SYS$DISK:[.INTER
DATA]ID_TT.C,SYS$DISK:[.INTERDATA]ID_UVC.C,SYS$DISK:[.INTERDATA]ID16_DBOOT.C,SYS$DISK:[.IN
TERDATA]ID_TTP.C

    { "DP", SWMASK ('F'), 9, 0x32, o_DP0, o_DPF },
............^
%CC-E-NEEDCONSTEXPR, In the initializer for dboot_tab[1].sw,
"sim_swmask(...)" is not constant, but occurs in a context that requires a constant
expression.
at line number 318 in file DKA200:[FRISBIE.SIMH.SIMH-MASTER.INTERDATA]ID16_DBOOT.C;4
%MMK-F-ERRUPD, error status %X10B91262 occurred when updating target SYS$DISK:[.BIN.VMS.LI
B]ID16-AXP.OLB
$

--------------------------------------------------
_______________________________________________
Simh mailing list
Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150807/31cbf7cd/attachment.html>

From khandy21yo at gmail.com  Fri Aug  7 13:33:17 2015
From: khandy21yo at gmail.com (Kevin Handy)
Date: Fri, 7 Aug 2015 11:33:17 -0600
Subject: [Simh] Problem with default builds
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A823733C096A@REDROOF2.alohasunset.com>
References: <o0f9l08dsawdyhxct6guldnj.1438917653489@email.android.com>
 <03006E3FC39B5A48AB9DBCCC101090A823733C096A@REDROOF2.alohasunset.com>
Message-ID: <CANk4W2NK_21hKcuddqrsqDASyNhxsMo=a-4AcN-5ut8==S8NkQ@mail.gmail.com>

The current macro has some masth in it rihgt now, but would the 1st
proposed fix for this (with the ?: macros) work any better than the 'index;
(or whatever was used) work any better on all C compilers? It seems that
the compiler must be able to resuce simple expressions into a constant, but
how fat can you sucessfully push it and still work with most C compilers?


On Fri, Aug 7, 2015 at 10:47 AM, Mark Pizzolato - Info Comm <
Mark at infocomm.com> wrote:

> Sorry folks.  The problem occurs anywhere the SWMASK is used in a static
> initializer.  I’ve reverted the recent change.
>
>
>
> The change was initially thought to be benign and attempted to allows for
> the simh source to be useful on systems with other than ASCII character
> sets (i.e. EBCDIC).  There are other issues with simulators running on
> hosts with EBCDIC character sets which are unrelated to the source code.
> If/when those are also addressed, we’ll revisit how to solve the non ASCII
> source code issue as well.
>
>
>
> -        Mark
>
>
>
> *From:* Simh [mailto:simh-bounces at trailing-edge.com] *On Behalf Of *
> khandy21yo
> *Sent:* Thursday, August 6, 2015 8:24 PM
> *To:* Alan Frisbie <frisbie at flying-disk.com>; SIMH at trailing-edge.com
> *Subject:* Re: [Simh] Problem with default builds
>
>
>
> Wasnr rgere a recent change to tge SWMASK macro,
>
> Gcc peobably optimizes this reference, but dev c must not.
>
>
>
>
> -------- Original message --------
> From Alan Frisbie <frisbie at flying-disk.com>
> Date: 08/06/2015 8:53 PM (GMT-07:00)
> To SIMH at trailing-edge.com
> Subject [Simh] Problem with default builds
>
>
> Another build error.   Unfortunately, I do not have the knowledge
> to fix it myself.
>
> Today, 6-Aug-2015, I downloaded the current simh-master.zip from
> github.
>
> My host is an Alpha XP1000 running VMS v8.4
>
> Using MMK from the VMS Freeware 8 CD, I tried to do a default
> build of all SIMH simulators.   All went well until the build of
> ID16-AXP.OLB Library.   At that point I got the error:
>
>     { "DP", SWMASK ('F'), 9, 0x32, o_DP0, o_DPF },
> ............^
> %CC-E-NEEDCONSTEXPR, In the initializer for dboot_tab[1].sw,
> "sim_swmask(...)" is not constant, but occurs in a context that requires a
> constant
> expression.
> at line number 318 in file
> DKA200:[FRISBIE.SIMH.SIMH-MASTER.INTERDATA]ID16_DBOOT.C;4
> %MMK-F-ERRUPD, error status %X10B91262 occurred when updating
> target SYS$DISK:[.BIN.VMS.LIB]ID16-AXP.OLB
>
>
> The log of the build (with lots of successful stuff snipped)
> follows below.
>
> Thanks,
> Alan Frisbie
>
> --------------------------------------------------
>
> $ unzip simh-master.zip
> Archive:  DKA200:[FRISBIE.SIMH]SIMH-MASTER.ZIP;5
> 7c7b44e409f05751c960a614dbb1e2abde22da60
> replace [.simh-master].gitattributes? [y]es, [n]o, [A]ll, [N]one,
> [r]ename: A
>
>   inflating: [.simh-master].gitattributes
>   inflating: [.simh-master].gitignore
>   inflating: [.simh-master]0readmeAsynchIO.txt
>   inflating: [.simh-master]0readme_39.txt
> ...
>   inflating: [.simh-master.swtp6800.swtp6800]swtp6800mp-a2.ini
>   inflating: [.simh-master.swtp6800.swtp6800]swtp_defs.h
>   inflating: [.simh-master.swtp6800.swtp6800]swtp_swtbug_bin.h
> $
> $ set default [.simh-master]
> $ $ set file/attri=rfm:stm makefile,*.mms,[...]*.c,[...]*.h,[...]*.txt
> $
> $ mmk
> $!
> $! Building The SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB
> Library.
> $!
> $ CC/DECC/PREF=ALL/DEBUG/OPT=(LEV=5)/ARCH=HOST
> /NEST=PRIMARY/NAME=(AS_IS,SHORT)/DEF=("_LA
> RGEFILE","SIM_ASYNCH_IO=1")  /OBJ=SYS$DISK:[.BIN.VMS.LIB.BLD-AXP]
> SYS$DISK:[]SIM_CONSOLE.C
>
> ,SYS$DISK:[]SIM_SOCK.C,SYS$DISK:[]SIM_TMXR.C,SYS$DISK:[]SIM_ETHER.C,SYS$DISK:[]SIM_TAPE.C,
>
> SYS$DISK:[]SIM_FIO.C,SYS$DISK:[]SIM_TIMER.C,SYS$DISK:[]SIM_DISK.C,SYS$DISK:[]SIM_SERIAL.C,
> SYS$DISK:[]SIM_VIDEO.C
> $ IF (F$SEARCH("SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB").EQS."")
> THEN  LIBRARY/CREATE SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB
> $ LIBRARY/REPLACE SYS$DISK:[.BIN.VMS.LIB]SIMH-NONET-AXP.OLB
> SYS$DISK:[.BIN.VMS.LIB.BLD-AXP]*.OBJ
> $ DELETE/NOLOG/NOCONFIRM SYS$DISK:[.BIN.VMS.LIB.BLD-AXP]*.OBJ;*
> $!
> $! Building The SYS$DISK:[.BIN.VMS.LIB]ALTAIR-AXP.OLB Library.
> ...
> ...
> $! IBM1130 done
> $!
> $! Building The SYS$DISK:[.BIN.VMS.LIB]ID16-AXP.OLB Library.
> $!
> $ CC/DECC/PREF=ALL/DEBUG/OPT=(LEV=5)/ARCH=HOST
> /NEST=PRIMARY/NAME=(AS_IS,SHORT)/INCL=(SYS
> $DISK:[],SYS$DISK:[.INTERDATA])/DEF=("_LARGEFILE","SIM_ASYNCH_IO=1")
> /OBJ=SYS$DISK:[.BIN.
> VMS.LIB.BLD-AXP]
> SYS$DISK:[.INTERDATA]ID16_CPU.C,SYS$DISK:[.INTERDATA]ID16_SYS.C,SYS$DISK:
>
> [.INTERDATA]ID_DP.C,SYS$DISK:[.INTERDATA]ID_FD.C,SYS$DISK:[.INTERDATA]ID_FP.C,SYS$DISK:[.I
>
> NTERDATA]ID_IDC.C,SYS$DISK:[.INTERDATA]ID_IO.C,SYS$DISK:[.INTERDATA]ID_LP.C,SYS$DISK:[.INT
>
> ERDATA]ID_MT.C,SYS$DISK:[.INTERDATA]ID_PAS.C,SYS$DISK:[.INTERDATA]ID_PT.C,SYS$DISK:[.INTER
>
> DATA]ID_TT.C,SYS$DISK:[.INTERDATA]ID_UVC.C,SYS$DISK:[.INTERDATA]ID16_DBOOT.C,SYS$DISK:[.IN
> TERDATA]ID_TTP.C
>
>     { "DP", SWMASK ('F'), 9, 0x32, o_DP0, o_DPF },
> ............^
> %CC-E-NEEDCONSTEXPR, In the initializer for dboot_tab[1].sw,
> "sim_swmask(...)" is not constant, but occurs in a context that requires a
> constant
> expression.
> at line number 318 in file
> DKA200:[FRISBIE.SIMH.SIMH-MASTER.INTERDATA]ID16_DBOOT.C;4
> %MMK-F-ERRUPD, error status %X10B91262 occurred when updating target
> SYS$DISK:[.BIN.VMS.LI
> B]ID16-AXP.OLB
> $
>
> --------------------------------------------------
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150807/49cfab76/attachment-0001.html>

From rly1 at embarqmail.com  Fri Aug  7 13:50:40 2015
From: rly1 at embarqmail.com (Ron Young)
Date: Fri, 07 Aug 2015 10:50:40 -0700
Subject: [Simh] Problem with default builds
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A823733C096A@REDROOF2.alohasunset.com>
References: <o0f9l08dsawdyhxct6guldnj.1438917653489@email.android.com>
 <03006E3FC39B5A48AB9DBCCC101090A823733C096A@REDROOF2.alohasunset.com>
Message-ID: <20150807175040.B904B200073@ron-amd64.localdomain>

Your message dated: Fri, 07 Aug 2015 09:47:14 -0700
--------

> The change was initially thought to be benign and attempted to allows for
> the simh source to be useful on systems with other than ASCII character
> sets (i.e. EBCDIC). There are other issues with simulators running on hosts
> with EBCDIC character sets which are unrelated to the source code. If/when
> those are also addressed, we’ll revisit how to solve the non ASCII source
> code issue as well.

One of things that I frequently did when moving character specific packages
to different machines is to run all input and output through two translation
vectors/arrays/etc. For example the old language grammer package "Lang-pak"
(written in fortran) has the following two arrays and support routines to
translate terminal I/O. When I moved the code to a Cyber, all I had to do
to change character sets is redo the arrays. Of course this doesn't address
the architectual differences, but converting data item to "standard" format
using things like htons, htonl ntohs, ntohl can help alot.

-ron

      BLOCKDATA
      COMMON /TRANS/ IE2A(256), IA2E(256)
      DATA IE2A
     + /   0,   1,   2,   3, 156,   9, 134, 127,
     +   151, 141, 142,  11,  12,  13,  14,  15,
     +    16,  17,  18,  19, 157, 133,   8, 135,
     +    24,  25, 146, 143,  28,  29,  30,  31,
     +   128, 129, 130, 131, 132,  10,  23,  27,
     +   136, 137, 138, 139, 140,   5,   6,   7,
     +   144, 145,  22, 147, 148, 149, 150,   4,
     +   152, 153, 154, 155,  20,  21, 158,  26,
     +    32, 160, 161, 162, 163, 164, 165, 166,
     +   167, 168,  91,  46,  60,  40,  43,  93,
     +    38, 169, 170, 171, 172, 173, 174, 175,
     +   176, 177,  33,  36,  42,  41,  59,  94,
     +    45,  47, 178, 179, 180, 181, 182, 183,
     +   184, 185, 124,  44,  37,  95,  62,  63,
     +   186, 187, 188, 189, 190, 191, 192, 193,
     +   194,  96,  58,  35,  64,  39,  61,  34,
     +   195,  97,  98,  99, 100, 101, 102, 103,
     +   104, 105, 196, 197, 198, 199, 200, 201,
     +   202, 106, 107, 108, 109, 110, 111, 112,
     +   113, 114, 203, 204, 205, 206, 207, 208,
     +   209, 126, 115, 116, 117, 118, 119, 120,
     +   121, 122, 210, 211, 212, 213, 214, 215,
     +   216, 217, 218, 219, 220, 221, 222, 223,
     +   224, 225, 226, 227, 228, 229, 230, 231,
     +   123,  65,  66,  67,  68,  69,  70,  71,
     +    72,  73, 232, 233, 234, 235, 236, 237,
     +   125,  74,  75,  76,  77,  78,  79,  80,
     +    81,  82, 238, 239, 240, 241, 242, 243,
     +    92, 159,  83,  84,  85,  86,  87,  88,
     +    89,  90, 244, 245, 246, 247, 248, 249,
     +    48,  49,  50,  51,  52,  53,  54,  55,
     +    56,  57, 250, 251, 252, 253, 254, 255/
      DATA IA2E
     + /   0,   1,   2,   3,  55,  45,  46,  47,
     +    22,   5,  37,  11,  12,  13,  14,  15,
     +    16,  17,  18,  19,  60,  61,  50,  38,
     +    24,  25,  63,  39,  28,  29,  30,  31,
     +    64,  90, 127, 123,  91, 108,  80, 125,
     +    77,  93,  92,  78, 107,  96,  75,  97,
     +   240, 241, 242, 243, 244, 245, 246, 247,
     +   248, 249, 122,  94,  76, 126, 110, 111,
     +   124, 193, 194, 195, 196, 197, 198, 199,
     +   200, 201, 209, 210, 211, 212, 213, 214,
     +   215, 216, 217, 226, 227, 228, 229, 230,
     +   231, 232, 233,  74, 224,  79,  95, 109,
     +   121, 129, 130, 131, 132, 133, 134, 135,
     +   136, 137, 145, 146, 147, 148, 149, 150,
     +   151, 152, 153, 162, 163, 164, 165, 166,
     +   167, 168, 169, 192, 106, 208, 161,   7,
     +    32,  33,  34,  35,  36,  37,   6,  23,
     +    40,  41,  42,  43,  44,   9,  10,  27,
     +    48,  49,  50,  51,  52,  53,  54,   8,
     +    56,  57,  58,  59,   4,  20,  62, 225,
     +    65,  66,  67,  68,  69,  70,  71,  72,
     +    73,  81,  82,  83,  84,  85,  86,  87,
     +    88,  89,  98,  99, 100, 101, 102, 103,
     +   104, 105, 112, 113, 114, 115, 116, 117,
     +   118, 119, 120, 128, 138, 139, 140, 141,
     +   142, 143, 144, 154, 155, 156, 157, 158,
     +   159, 160, 170, 171, 172, 173, 174, 175,
     +   176, 177, 178, 179, 180, 181, 182, 183,
     +   184, 185, 186, 187, 188, 189, 190, 191,
     +   202, 203, 204, 205, 206, 207, 218, 219,
     +   220, 221, 222, 223, 234, 235, 236, 237,
     +   238, 239, 250, 251, 252, 253, 254, 255/
      END

      subroutine tread(in,kf,ilen)
      character*1000 inputline
      character*480 request
      dimension in(1)
      common /trans/ ie2a(256), ia2e(256)
      common /iocom/ iout

      request=''
      irlen=0

 10   read (*,'(a)') inputline
      ilen = len(inputline)
 1    if (inputline(ilen:ilen).eq.' '.and.ilen.gt.0) then
         ilen = ilen - 1
         goto 1
      endif

      request(irlen+1:irlen+ilen) = inputline(1:ilen)
      irlen = irlen + ilen

      if (inputline(ilen:ilen).eq.'$') then
         irlen = irlen - 1
         goto 10
      endif

      ilen = irlen
      do 2 i = 1, ilen
         in(kf+i-1) = ia2e(ichar(request(I:I))+1)
 2    continue
      return
      end

      subroutine twrite(in,kf,ilen)
      character*1000 outputline
      character*1000 encodestring
      dimension in(1)
      common /iocom/ iout

      outputline = encodestring(in,kf,ilen)
      write(iout,'(a)') outputline(1:ilen)
      return
      end

      character*(*) function encodestring(LN,kf,LEN)
      dimension ln(1)
      COMMON /TRANS/ IE2A(256), IA2E(256)

      encodestring = ''
      do 1 i = 1, len
         encodestring(i:i) = char(ie2a(ln(i+kf-1)+1))
 1    continue
      return
      end
				  
===============================================================================
Ron Young				rly1 at embarqmail.com

From frisbie at flying-disk.com  Fri Aug  7 19:33:02 2015
From: frisbie at flying-disk.com (Alan Frisbie)
Date: Fri, 7 Aug 2015 16:33:02 -0700 (PDT)
Subject: [Simh] Mark's mailbox full
Message-ID: <15080716330249_44C@slug.flying-disk.com>

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

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

Thanks,
Alan Frisbie

From robert at schaffrath.net  Fri Aug  7 20:57:13 2015
From: robert at schaffrath.net (Robert G. Schaffrath)
Date: Fri, 07 Aug 2015 20:57:13 -0400
Subject: [Simh] Mark's mailbox full
In-Reply-To: <15080716330249_44C@slug.flying-disk.com>
References: <15080716330249_44C@slug.flying-disk.com>
Message-ID: <55C553E9.7000407@schaffrath.net>

Ah those munged up error messages bring back memories: !AS

On 8/7/2015 7:33 PM, Alan Frisbie wrote:
> Status:  error writing !AS


From Jason.Armistead at otis.com  Mon Aug 10 11:06:06 2015
From: Jason.Armistead at otis.com (Armistead, Jason          BIS)
Date: Mon, 10 Aug 2015 15:06:06 +0000
Subject: [Simh] Mark's mailbox full
Message-ID: <78CD6B448AA1E54FBAB5EF46F90F9B3831F61429@UUSNWE1S.na.utcmail.com>

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

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

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

Cheers
Jason A

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

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

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

Thanks,
Alan Frisbie
_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

From lists at openmailbox.org  Mon Aug 10 13:06:47 2015
From: lists at openmailbox.org (lists at openmailbox.org)
Date: Mon, 10 Aug 2015 17:06:47 +0000
Subject: [Simh] Mark's mailbox full
In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B3831F61429@UUSNWE1S.na.utcmail.com>
References: <78CD6B448AA1E54FBAB5EF46F90F9B3831F61429@UUSNWE1S.na.utcmail.com>
Message-ID: <mailman.0.1439226423.1219.simh@trailing-edge.com>

It might be helpul to post this to comp.os.vms too, since new development
on VMS is in the works and security is high on their list of things to work
on.


On Mon, 10 Aug 2015 15:06:06 +0000
"Armistead, Jason          BIS" <Jason.Armistead at otis.com> wrote:

> I actually find it interesting how much it reveals about the target
> e-mail and account configuration
> 
> We know he's running VMS
> We know he has a disk called $DISK3:
> We know his user space is under $DISK3:[MARK]
> And we know we've successfully filled his disk, thus denying some level
> of service and system functionality
> 
> In this era of hackers that feed off this sort of exposed data, I doubt
> any modern mail server would be game to post back so much
> configuration-specific information that could be used to aid in a
> targeted hacking attack.
> 
> Cheers
> Jason A
> 
> -----Original Message-----
> From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of Alan
> Frisbie Sent: Friday, 7 August 2015 7:33 PM
> To: SIMH at trailing-edge.com
> Subject: [Simh] Mark's mailbox full
> 
> If anyone know how to get in touch with Mark Pizzolato outside of email,
> please let him know that he has a disk allocation failure:
> 
> > This is a report on the delivery status of your message.
> > 
> >   Message-ID:  <15080716022951_44C at slug.flying-disk.com>
> >   Subject:     Re: [Simh] Problem with default builds
> > 
> >   --Failed delivery to:
> >   Address: MARK+SIMH
> >   Status:  error writing !AS
> > 
> > Reporting-MTA: dns;infocomm.com
> > Arrival-Date: Fri, 7 Aug 2015 15:25:38 -0700
> > 
> > Final-Recipient: x-local;MARK+SIMH
> > Action: failed
> > Status: 5.2.0 (Other or undefined mailbox status)
> > Diagnostic-Code: x-local;error writing !AS  %MAIL-W-WRITEERR, error 
> > writing $DISK3:[MARK.MAIL]MAIL.MAI  -RMS-F-FUL, device full 
> > (insufficient space for allocation)
> > Last-Attempt-Date: Fri, 7 Aug 2015 15:25:40 -0700
> 
> Thanks,
> Alan Frisbie
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

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

From bob at supnik.org  Mon Aug 10 14:13:52 2015
From: bob at supnik.org (Bob Supnik)
Date: Mon, 10 Aug 2015 14:13:52 -0400
Subject: [Simh] Needed: RH750 specification
Message-ID: <55C8E9E0.7040009@supnik.org>

Mark Pizzolato sent me a note about a code sequence in the original 
VAX750 bootstrap that fails on the 750 simulator. The code is doing a

BBC #7,address,10$

where the address is in the RH750 Massbus adapter. The sequence fails 
because the simulated RH750 throws an error - the operand access is not 
an aligned longword.

BBC and the other bit branches use a byte access operand. The SRM says 
that VAX implementations must access the precise byte specified by the 
base address and the byte part of the bit offset. There's no leeway in 
the wording, and the VAX chips (and the 780) do precisely that.

If the 750 microcode is correctly implemented, then the best explanation 
is that the RH750, unlike the RH780, does not in fact check the length 
(and possibly not the alignment) of register accesses. This is true of 
the respective Unibus adapters: the 780's does lots of checking, the 
750's does none.

The 750 simulator is not mine, but I'd like to track this problem down. 
The RH750 schematics don't help, because the critical logic is inside 
gate arrays. What's needed is an RH750 specification. Does anyone have it?

Thanks,

/Bob Supnik


From litt at ieee.org  Mon Aug 10 15:02:48 2015
From: litt at ieee.org (Timothe Litt)
Date: Mon, 10 Aug 2015 15:02:48 -0400
Subject: [Simh] Needed: RH750 specification
In-Reply-To: <55C8E9E0.7040009@supnik.org>
References: <55C8E9E0.7040009@supnik.org>
Message-ID: <55C8F558.1060508@ieee.org>

On 10-Aug-15 14:13, Bob Supnik wrote:
> Mark Pizzolato sent me a note about a code sequence in the original
> VAX750 bootstrap that fails on the 750 simulator. The code is doing a
>
> BBC #7,address,10$
>
> where the address is in the RH750 Massbus adapter. The sequence fails
> because the simulated RH750 throws an error - the operand access is
> not an aligned longword.
>
> BBC and the other bit branches use a byte access operand. The SRM says
> that VAX implementations must access the precise byte specified by the
> base address and the byte part of the bit offset. There's no leeway in
> the wording, and the VAX chips (and the 780) do precisely that.
>

This is not exactly correct.  BB uses a FIELD access, not a pure byte
access.  SRM 3.5 (p. 3-56 "BB") "opcode pos.rl, base.vb, displ.bb,
{field.mv}" Note the "v".

Fields are 1-5 bytes, and "access the minimum number of aligned
longwords necessary to to contain the field".  (SRM 1.2.10)  (Rev. J
added a reference to INSV in 3.4, but this postdates the 750 and isn't
relevant here.)

The SRM also says that BBC is not legal in I/O space.  See 7.5.5 (3) --
BBC is a control instruction with a field operand.  Operand types of
field are not legal in I/O space.

As a practical matter, BB is problematic in I/O space.  For example,
Aquarius fetches a quadword around the base address, which can have side
effects reading the unwanted register... (And yes, the implementation
conforms to 1.2.10 from the programmer's perspective when the field is
in memory.)  I remember finding and removing a number of OS/driver bugs
where I/O space was used...

That said, programmers do things that are unspecified & when they "seem
to work" on the hardware they're using, move on.

Apparently the 750 hardware deals with whatever access the CPU generates
for BBC - which architecturally can be anything from a byte read to a
longword.

I don't have the RH750 specification - but this is unspecified
behavior.  I would be mildly surprised if the spec bothered to mention it.

The spirit of SimH, of course, is to make the software work despite
implementation bugs.  I'd say this is an unspecified behavior in the
RH750 simulator that SimH needs to fix there... Removing the check is
probably the right hack - with a suitable comment.

> If the 750 microcode is correctly implemented, then the best
> explanation is that the RH750, unlike the RH780, does not in fact
> check the length (and possibly not the alignment) of register
> accesses. This is true of the respective Unibus adapters: the 780's
> does lots of checking, the 750's does none.
>
Either the 780 driver doesn't do this, or this particular case isn't
checked for in the 780 hardware.  The hardware is not obliged to check
for UNSPECIFIED behavior (FIELD in I/O space).  If the 780 ucode happens
to make a longword reference to fetch the byte for BB (which is valid
for memory, so long as it's aligned & won't pagefault), things would
"appear to work".  Without looking at the hardware, that would be my guess.

> The 750 simulator is not mine, but I'd like to track this problem
> down. The RH750 schematics don't help, because the critical logic is
> inside gate arrays. What's needed is an RH750 specification. Does
> anyone have it?
>
> Thanks,
>
> /Bob Supnik
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150810/be175b51/attachment.bin>

From stafford.winters at gmail.com  Mon Aug 10 19:26:02 2015
From: stafford.winters at gmail.com (Stafford Winters)
Date: Mon, 10 Aug 2015 16:26:02 -0700
Subject: [Simh] Mark's mailbox full
In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B3831F61429@UUSNWE1S.na.utcmail.com>
References: <78CD6B448AA1E54FBAB5EF46F90F9B3831F61429@UUSNWE1S.na.utcmail.com>
Message-ID: <55C9330A.7070307@gmail.com>

Consider that it possible that disk quotas have been applied and/or 
$DISK3 could be a logical disk with a small size to avoid impacting 
services.  In fact, Mark may only use that username for email.

On 8/10/2015 8:06 AM, Armistead, Jason BIS wrote:
> I actually find it interesting how much it reveals about the target e-mail and account configuration
>
> We know he's running VMS
> We know he has a disk called $DISK3:
> We know his user space is under $DISK3:[MARK]
> And we know we've successfully filled his disk, thus denying some level of service and system functionality
>
> In this era of hackers that feed off this sort of exposed data, I doubt any modern mail server would be game to post back so much configuration-specific information that could be used to aid in a targeted hacking attack.
>
> Cheers
> Jason A
>
> -----Original Message-----
> From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of Alan Frisbie
> Sent: Friday, 7 August 2015 7:33 PM
> To: SIMH at trailing-edge.com
> Subject: [Simh] Mark's mailbox full
>
> If anyone know how to get in touch with Mark Pizzolato outside of email, please let him know that he has a disk allocation failure:
>
>> This is a report on the delivery status of your message.
>>
>>    Message-ID:  <15080716022951_44C at slug.flying-disk.com>
>>    Subject:     Re: [Simh] Problem with default builds
>>
>>    --Failed delivery to:
>>    Address: MARK+SIMH
>>    Status:  error writing !AS
>>
>> Reporting-MTA: dns;infocomm.com
>> Arrival-Date: Fri, 7 Aug 2015 15:25:38 -0700
>>
>> Final-Recipient: x-local;MARK+SIMH
>> Action: failed
>> Status: 5.2.0 (Other or undefined mailbox status)
>> Diagnostic-Code: x-local;error writing !AS  %MAIL-W-WRITEERR, error
>> writing $DISK3:[MARK.MAIL]MAIL.MAI  -RMS-F-FUL, device full
>> (insufficient space for allocation)
>> Last-Attempt-Date: Fri, 7 Aug 2015 15:25:40 -0700
> Thanks,
> Alan Frisbie
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


From bob at supnik.org  Tue Aug 11 16:11:08 2015
From: bob at supnik.org (Bob Supnik)
Date: Tue, 11 Aug 2015 16:11:08 -0400
Subject: [Simh]  Needed: RH750 specification
In-Reply-To: <mailman.1.1439308802.25128.simh@trailing-edge.com>
References: <mailman.1.1439308802.25128.simh@trailing-edge.com>
Message-ID: <55CA56DC.5040402@supnik.org>

Actually, the SRM spells out exactly how BBS/BBC behave in 7.3, 
subparagraph 6d (now you know why microcoders were called SRM lawyers):

"BB{S,C}, BB{S,C}{S,C}. Only the single byte specified by the base and 
position operands is read."

In short, a byte access, mandated by the SRM.

Now, most VAXen could only read a whole longword or quadword from 
memory, but the system bus contained a byte mask or other encoding to 
say which bytes really mattered. This could be ignored on memory reads, 
of course. In generating byte masks, the VAX chips made no distinction 
between memory space and IO space and would generate proper byte masks 
for all reads. The 780 microcode used byte accesses for BBxy, so I 
assume it did the same.

Only two hypotheses are possible: either the 750 microcode makes a real 
longword reference (all byte mask bits set), in contravention of the 
SRM; or the RH750 doesn't check operand lengths. I incline to the latter 
hypothesis, but we need either the  RH750 spec to be sure.

/Bob

On 8/11/2015 12:00 PM, simh-request at trailing-edge.com wrote:
> Message: 3 Date: Mon, 10 Aug 2015 15:02:48 -0400 From: Timothe Litt 
> <litt at ieee.org> To: simh at trailing-edge.com Subject: Re: [Simh] Needed: 
> RH750 specification Message-ID: <55C8F558.1060508 at ieee.org> 
> Content-Type: text/plain; charset="utf-8" On 10-Aug-15 14:13, Bob 
> Supnik wrote:
>> >Mark Pizzolato sent me a note about a code sequence in the original
>> >VAX750 bootstrap that fails on the 750 simulator. The code is doing a
>> >
>> >BBC #7,address,10$
>> >
>> >where the address is in the RH750 Massbus adapter. The sequence fails
>> >because the simulated RH750 throws an error - the operand access is
>> >not an aligned longword.
>> >
>> >BBC and the other bit branches use a byte access operand. The SRM says
>> >that VAX implementations must access the precise byte specified by the
>> >base address and the byte part of the bit offset. There's no leeway in
>> >the wording, and the VAX chips (and the 780) do precisely that.
>> >
> This is not exactly correct.  BB uses a FIELD access, not a pure byte
> access.  SRM 3.5 (p. 3-56 "BB") "opcode pos.rl, base.vb, displ.bb,
> {field.mv}" Note the "v".
>
> Fields are 1-5 bytes, and "access the minimum number of aligned
> longwords necessary to to contain the field".  (SRM 1.2.10)  (Rev. J
> added a reference to INSV in 3.4, but this postdates the 750 and isn't
> relevant here.)
>
> The SRM also says that BBC is not legal in I/O space.  See 7.5.5 (3) --
> BBC is a control instruction with a field operand.  Operand types of
> field are not legal in I/O space.
>
> As a practical matter, BB is problematic in I/O space.  For example,
> Aquarius fetches a quadword around the base address, which can have side
> effects reading the unwanted register... (And yes, the implementation
> conforms to 1.2.10 from the programmer's perspective when the field is
> in memory.)  I remember finding and removing a number of OS/driver bugs
> where I/O space was used...
>
> That said, programmers do things that are unspecified & when they "seem
> to work" on the hardware they're using, move on.
>
> Apparently the 750 hardware deals with whatever access the CPU generates
> for BBC - which architecturally can be anything from a byte read to a
> longword.
>
> I don't have the RH750 specification - but this is unspecified
> behavior.  I would be mildly surprised if the spec bothered to mention it.
>
> The spirit of SimH, of course, is to make the software work despite
> implementation bugs.  I'd say this is an unspecified behavior in the
> RH750 simulator that SimH needs to fix there... Removing the check is
> probably the right hack - with a suitable comment.
>
>> >If the 750 microcode is correctly implemented, then the best
>> >explanation is that the RH750, unlike the RH780, does not in fact
>> >check the length (and possibly not the alignment) of register
>> >accesses. This is true of the respective Unibus adapters: the 780's
>> >does lots of checking, the 750's does none.
>> >
> Either the 780 driver doesn't do this, or this particular case isn't
> checked for in the 780 hardware.  The hardware is not obliged to check
> for UNSPECIFIED behavior (FIELD in I/O space).  If the 780 ucode happens
> to make a longword reference to fetch the byte for BB (which is valid
> for memory, so long as it's aligned & won't pagefault), things would
> "appear to work".  Without looking at the hardware, that would be my guess.
>
>> >The 750 simulator is not mine, but I'd like to track this problem
>> >down. The RH750 schematics don't help, because the critical logic is
>> >inside gate arrays. What's needed is an RH750 specification. Does
>> >anyone have it?
>> >
>> >Thanks,
>> >
>> >/Bob Supnik
>> >


From litt at ieee.org  Wed Aug 12 07:47:59 2015
From: litt at ieee.org (Timothe Litt)
Date: Wed, 12 Aug 2015 07:47:59 -0400
Subject: [Simh] Needed: RH750 specification
In-Reply-To: <55CA56DC.5040402@supnik.org>
References: <mailman.1.1439308802.25128.simh@trailing-edge.com>
 <55CA56DC.5040402@supnik.org>
Message-ID: <55CB326F.8080801@ieee.org>

On 11-Aug-15 16:11, Bob Supnik wrote:
> Actually, the SRM spells out exactly how BBS/BBC behave in 7.3,
> subparagraph 6d (now you know why microcoders were called SRM lawyers):
>
Having been responsible for several microdes and having worked with CPU
instruction set architects, I am familiar with their behaviors...and the
complications in the SRM text that lead to them.  And the long meetings
and discussions in the architecture notes files...

It's rare that we disagree on a VAX issue, but in this case I think
you're focusing on the wrong text.  (I've played SRM lawyer too.)

This is a case of the *software* not conforming to the SRM, and relying
on an UNDEFINED implementation choice.  BB* is not allowed to have an
operand in I/O space, and the result of such an instruction is
UNDEFINED.  UNDEFINED operations are not constrained by most other parts
of the SRM.  But in this case, I don't think there's a conflict.

> "BB{S,C}, BB{S,C}{S,C}. Only the single byte specified by the base and
> position operands is read."
>
> In short, a byte access, mandated by the SRM.
>
This was the subject of some discussion. 

It doesn't contradict the SRM section that I  cited - 7.5.5 (3), which
states that a field operand can not be in I/O space.  Nor 7.5.3, which
explicitly disallows BB* references to I/O space.

My world (HPS/Aquarius) concluded that in context this means that only
the byte referenced by the base and position contributes to the observed
effects of the instruction.  Given that field instructions are illegal
in I/O space, only memory references matter.  We took advantage of this
in a couple of ways -- reading more than required often saves time.  The
IBox prefetches the quadword at the base address before the position
(and for other field instructions, size) is evaluated.  Instruction
traces showed that the vast majority of field references hit that
quadword, which allowed the EBox to avoid an explicit operand read
(which is much further down the pipeline and would stall).  Of course if
the EBox determines that the bit is somewhere else, the prefetched data
is discarded along with any exception it might have incurred.  For
non-field references, the "byte mask" is used by the MBox to rotate
(align) data put into the operand queue.  The gory details of field
references escape me at the moment.  There are also some conditions
where operands can be read more than once - which is perfectly OK for
memory.  Tryggve (Fossum, the Aquarius system architect) was very
aggressive about finding (and getting the box leaders to find)
opportunities for performance optimization.  We could and did spend
gates and complexity for performance.  I had the fun of arguing
software's case where there was ambiguity.  And debugging the beast. 
The VAX chip world world (at that time) was optimizing for space - just
getting things to fit was their big challenge.  So treating I/O and
memory references the same naturally falls out.

The SRM also defines what bytes a FIELD can reference in 3.4 & 1.2.10. 
These conflict; the former amounts to "the minimum number of *bytes*
needed to contain the field, except for INSV", while the latter says
"minimum number of *aligned longwords*."

Given the restriction on I/O space, why (6d)  talks about the memory
read is somewhat mysterious at first reading.  Memory read can have no
visible side effects, except when crossing a page boundary.  And one
would expect BB to read either the bye, or an enclosing aligned entity
that would not cross a page boundary.  The full context of your
reference is:

     "BB{S,C}, BB{S,C}{S,C}. Only the single byte <containing the test
bit> specified by the base and position operands is read.  <If the test
bit does not need to change state, it is UNPREDICTABLE whether the byte
is written back.>"

This rather awkward construction does constrain the write of
BB{S,C}{S,C} to the single selected byte.  And that does matter for the
atomicity/visibility rules.  (Though BB{S,C} should never write...})  I
think that's the point that's being made here, as the previous sections
cover the constraints on read.

Being more specific, (6d) would control interpretation to the extent
that there are conflicts.  But it does not allow an I/O space operand. 
So if an I/O space operand is referenced, from an SRM point of view what
happens is UNDEFINED.  (SRM 7.5.2 (5) "...and field references in the
I/O space result in UNDEFINED behavior.") It *might* be a byte access,
it might be no access, or anything other than hanging the processor or
console. (SRM B.1.6)

> Now, most VAXen could only read a whole longword or quadword from
> memory, but the system bus contained a byte mask or other encoding to
> say which bytes really mattered. This could be ignored on memory
> reads, of course. In generating byte masks, 
And BB* can only reference memory.
> the VAX chips made no distinction between memory space and IO space
> and would generate proper byte masks for all reads. The 
This is an implementation choice that SRM conformant software was
forbidden to rely upon.  It effectively extended the architecture,
allowing field references (including BB*) to operate on I/O space.  It
happened to be convenient for the "chip" VAXes, but it would not have
been convenient for other technologies.  As I've noted, Aquarius (at
least) made use of the restriction to avoid extra logic (and time) that
would have been required to disable legal optimizations when referencing
I/O space.  There was nothing "improper" about this - the programmer
writing SRM-conformant code can not detect the implementation
differences.  And because any peripheral hardware must be in I/O space
where field references can't be made, neither can hardware.

SRM section 7.5.3 (p. 7-25) lists the only instructions and operand
addressing modes that can be used to reference I/O space.  The list
excludes BB*.  The implementation note on p 7-26 of the SRM is explicit
about this exclusion -- "For reference instructions were discarded as
follows"... (7) "operand types: ... BB{S,C}, BB{S,C}{S,C}..."

All that said, the VAX chips are SRM compliant - they are not required
to enforce the rule that field references may not be to I/O space. 
Their behavior in this UNDEFINED case happens to be predictable - and
some coder got away with relying on it.  It's the CODE, not the machine
that is violating the SRM.  Unfortunately.  This is why we encouraged
implementations to check for violations whenever possible.

NVAX borrowed some of its microarchitecture from Aquarius (and in fact,
our RQT machines ran the NVAX simulations).  I'm not sure what it did
with this case - it simplified things to fit in the VLSI of the time. 
But had development continued, I expect that eventually the chip VAXes
would have made more aggressive use of the SRM's opportunities for
optimization.  And this code fragment would have caused an issue on them
as well.

> 780 microcode used byte accesses for BBxy, so I assume it did the same.
>
> Only two hypotheses are possible: either the 750 microcode makes a
> real longword reference (all byte mask bits set), in contravention of
> the SRM; or the RH750 doesn't check operand lengths. I incline to the
> latter hypothesis, but we need either the  RH750 spec to be sure.
>
Since it's a *memory* read (and as you note), the byte masks need not be
passed to the cache.  What matters to the SRM is whether the programmer
can detect a reference beyond the selected byte.  Assuming the ucode
doesn't do something stupid (like reference beyond the end of a page and
report an undeserved exception), reading a byte, a word, a longword or
an octaword doesn't contravene the SRM.  Internally, the memory
subsystem is almost certain to read more than a byte due to ECC.  As
long as the instruction selects the correct bit to branch on, the
reference type doesn't matter.  (If the BB were a BBx{S,C}, then the
write would have to obey the atomicity rules.  But that doesn't apply to
the reported case.)  So I don't agree with your "in contravention of the
SRM." 

If a programmer can't distinguish an implementation from the SRM
description, it's legal.  Just like SRM 2.6 which says that the
architecture assumes a sequential model where "no instruction is
processed, (even partially) until the one before it completes."  If
implementations adhered literally to that, there could be no instruction
or data prefetch, branch prediction, or speculation.  And every VAX
would be non-conformant.  The SRM is interpreted to mean that an
implementation must work from a programmers point of view "as if" it
literally follows the text.  But what's under the covers is fodder for
creativity.

Now if it's a reference to I/O space, this does become important.  But
that's what is in contravention of the SRM.  This instruction is not
allowed to have an operand in I/O space.  To correctly support I/O
space, including registers that have read side-effects, byte masks need
to be supplied and obeyed.  I guess the good news is that if this is
only being done with MBA registers, offhand I can't think of a Massbus
device that has registers with read side-effects.

I don't know whether the 750 spec says that the machine will support all
types of references to I/O space, even those disallowed by the SRM.   If
it does, no software engineer should have relied on the statement. 
Except, perhaps a platform-specific diagnostic coder in some corner
case.  Specs weren't required to list what happens in all the UNDEFINED
cases.

You're probably right that the the RH750 doesn't check lengths.  I hope
that the RH or CPU spec clarifies this for you, but as it's an
UNDEFINED, I wouldn't bet on whether there's enough information in the
specs to tell.

What *is* clear is that this particular bit of code worked on the real
750 hardware & that SRM issues aside, SimH will have to make it work
too.  Exactly how painful that must be depends on how pervasive this
non-compliant coding is...and the SimH 750 code, which I haven't
examined.  From your description, the RH shouldn't be throwing an error...

> /Bob
>
> On 8/11/2015 12:00 PM, simh-request at trailing-edge.com wrote:
>> Message: 3 Date: Mon, 10 Aug 2015 15:02:48 -0400 From: Timothe Litt
>> <litt at ieee.org> To: simh at trailing-edge.com Subject: Re: [Simh]
>> Needed: RH750 specification Message-ID: <55C8F558.1060508 at ieee.org>
>> Content-Type: text/plain; charset="utf-8" On 10-Aug-15 14:13, Bob
>> Supnik wrote:
>>> >Mark Pizzolato sent me a note about a code sequence in the original
>>> >VAX750 bootstrap that fails on the 750 simulator. The code is doing a
>>> >
>>> >BBC #7,address,10$
>>> >
>>> >where the address is in the RH750 Massbus adapter. The sequence fails
>>> >because the simulated RH750 throws an error - the operand access is
>>> >not an aligned longword.
>>> >
>>> >BBC and the other bit branches use a byte access operand. The SRM says
>>> >that VAX implementations must access the precise byte specified by the
>>> >base address and the byte part of the bit offset. There's no leeway in
>>> >the wording, and the VAX chips (and the 780) do precisely that.
>>> >
>> This is not exactly correct.  BB uses a FIELD access, not a pure byte
>> access.  SRM 3.5 (p. 3-56 "BB") "opcode pos.rl, base.vb, displ.bb,
>> {field.mv}" Note the "v".
>>
>> Fields are 1-5 bytes, and "access the minimum number of aligned
>> longwords necessary to to contain the field".  (SRM 1.2.10)  (Rev. J
>> added a reference to INSV in 3.4, but this postdates the 750 and isn't
>> relevant here.)
>>
>> The SRM also says that BBC is not legal in I/O space.  See 7.5.5 (3) --
>> BBC is a control instruction with a field operand.  Operand types of
>> field are not legal in I/O space.
>>
>> As a practical matter, BB is problematic in I/O space.  For example,
>> Aquarius fetches a quadword around the base address, which can have side
>> effects reading the unwanted register... (And yes, the implementation
>> conforms to 1.2.10 from the programmer's perspective when the field is
>> in memory.)  I remember finding and removing a number of OS/driver bugs
>> where I/O space was used...
>>
>> That said, programmers do things that are unspecified & when they "seem
>> to work" on the hardware they're using, move on.
>>
>> Apparently the 750 hardware deals with whatever access the CPU generates
>> for BBC - which architecturally can be anything from a byte read to a
>> longword.
>>
>> I don't have the RH750 specification - but this is unspecified
>> behavior.  I would be mildly surprised if the spec bothered to
>> mention it.
>>
>> The spirit of SimH, of course, is to make the software work despite
>> implementation bugs.  I'd say this is an unspecified behavior in the
>> RH750 simulator that SimH needs to fix there... Removing the check is
>> probably the right hack - with a suitable comment.
>>
>>> >If the 750 microcode is correctly implemented, then the best
>>> >explanation is that the RH750, unlike the RH780, does not in fact
>>> >check the length (and possibly not the alignment) of register
>>> >accesses. This is true of the respective Unibus adapters: the 780's
>>> >does lots of checking, the 750's does none.
>>> >
>> Either the 780 driver doesn't do this, or this particular case isn't
>> checked for in the 780 hardware.  The hardware is not obliged to check
>> for UNSPECIFIED behavior (FIELD in I/O space).  If the 780 ucode happens
>> to make a longword reference to fetch the byte for BB (which is valid
>> for memory, so long as it's aligned & won't pagefault), things would
>> "appear to work".  Without looking at the hardware, that would be my
>> guess.
>>
>>> >The 750 simulator is not mine, but I'd like to track this problem
>>> >down. The RH750 schematics don't help, because the critical logic is
>>> >inside gate arrays. What's needed is an RH750 specification. Does
>>> >anyone have it?
>>> >
>>> >Thanks,
>>> >
>>> >/Bob Supnik
>>> >
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150812/197a3729/attachment.bin>

From mattislind at gmail.com  Wed Aug 12 08:13:44 2015
From: mattislind at gmail.com (Mattis Lind)
Date: Wed, 12 Aug 2015 14:13:44 +0200
Subject: [Simh] Needed: RH750 specification
In-Reply-To: <55CB326F.8080801@ieee.org>
References: <mailman.1.1439308802.25128.simh@trailing-edge.com>
 <55CA56DC.5040402@supnik.org> <55CB326F.8080801@ieee.org>
Message-ID: <CABr82SLoi5vxjCzFDR=5K80JLsq3H9oOSvedxRzYuWi4RRS4iA@mail.gmail.com>

If it helps I have access to a working VAX-11/750 which has a RH750 adapter
(but no devices attached to the massbus).

Now if there would be no RH750 specification surfacing then I could try to
attach a logic analyzer to the CMI bus to investigate this if that would
help solving this issue.

/Mattis

2015-08-12 13:47 GMT+02:00 Timothe Litt <litt at ieee.org>:

> On 11-Aug-15 16:11, Bob Supnik wrote:
> > Actually, the SRM spells out exactly how BBS/BBC behave in 7.3,
> > subparagraph 6d (now you know why microcoders were called SRM lawyers):
> >
> Having been responsible for several microdes and having worked with CPU
> instruction set architects, I am familiar with their behaviors...and the
> complications in the SRM text that lead to them.  And the long meetings
> and discussions in the architecture notes files...
>
> It's rare that we disagree on a VAX issue, but in this case I think
> you're focusing on the wrong text.  (I've played SRM lawyer too.)
>
> This is a case of the *software* not conforming to the SRM, and relying
> on an UNDEFINED implementation choice.  BB* is not allowed to have an
> operand in I/O space, and the result of such an instruction is
> UNDEFINED.  UNDEFINED operations are not constrained by most other parts
> of the SRM.  But in this case, I don't think there's a conflict.
>
> > "BB{S,C}, BB{S,C}{S,C}. Only the single byte specified by the base and
> > position operands is read."
> >
> > In short, a byte access, mandated by the SRM.
> >
> This was the subject of some discussion.
>
> It doesn't contradict the SRM section that I  cited - 7.5.5 (3), which
> states that a field operand can not be in I/O space.  Nor 7.5.3, which
> explicitly disallows BB* references to I/O space.
>
> My world (HPS/Aquarius) concluded that in context this means that only
> the byte referenced by the base and position contributes to the observed
> effects of the instruction.  Given that field instructions are illegal
> in I/O space, only memory references matter.  We took advantage of this
> in a couple of ways -- reading more than required often saves time.  The
> IBox prefetches the quadword at the base address before the position
> (and for other field instructions, size) is evaluated.  Instruction
> traces showed that the vast majority of field references hit that
> quadword, which allowed the EBox to avoid an explicit operand read
> (which is much further down the pipeline and would stall).  Of course if
> the EBox determines that the bit is somewhere else, the prefetched data
> is discarded along with any exception it might have incurred.  For
> non-field references, the "byte mask" is used by the MBox to rotate
> (align) data put into the operand queue.  The gory details of field
> references escape me at the moment.  There are also some conditions
> where operands can be read more than once - which is perfectly OK for
> memory.  Tryggve (Fossum, the Aquarius system architect) was very
> aggressive about finding (and getting the box leaders to find)
> opportunities for performance optimization.  We could and did spend
> gates and complexity for performance.  I had the fun of arguing
> software's case where there was ambiguity.  And debugging the beast.
> The VAX chip world world (at that time) was optimizing for space - just
> getting things to fit was their big challenge.  So treating I/O and
> memory references the same naturally falls out.
>
> The SRM also defines what bytes a FIELD can reference in 3.4 & 1.2.10.
> These conflict; the former amounts to "the minimum number of *bytes*
> needed to contain the field, except for INSV", while the latter says
> "minimum number of *aligned longwords*."
>
> Given the restriction on I/O space, why (6d)  talks about the memory
> read is somewhat mysterious at first reading.  Memory read can have no
> visible side effects, except when crossing a page boundary.  And one
> would expect BB to read either the bye, or an enclosing aligned entity
> that would not cross a page boundary.  The full context of your
> reference is:
>
>      "BB{S,C}, BB{S,C}{S,C}. Only the single byte <containing the test
> bit> specified by the base and position operands is read.  <If the test
> bit does not need to change state, it is UNPREDICTABLE whether the byte
> is written back.>"
>
> This rather awkward construction does constrain the write of
> BB{S,C}{S,C} to the single selected byte.  And that does matter for the
> atomicity/visibility rules.  (Though BB{S,C} should never write...})  I
> think that's the point that's being made here, as the previous sections
> cover the constraints on read.
>
> Being more specific, (6d) would control interpretation to the extent
> that there are conflicts.  But it does not allow an I/O space operand.
> So if an I/O space operand is referenced, from an SRM point of view what
> happens is UNDEFINED.  (SRM 7.5.2 (5) "...and field references in the
> I/O space result in UNDEFINED behavior.") It *might* be a byte access,
> it might be no access, or anything other than hanging the processor or
> console. (SRM B.1.6)
>
> > Now, most VAXen could only read a whole longword or quadword from
> > memory, but the system bus contained a byte mask or other encoding to
> > say which bytes really mattered. This could be ignored on memory
> > reads, of course. In generating byte masks,
> And BB* can only reference memory.
> > the VAX chips made no distinction between memory space and IO space
> > and would generate proper byte masks for all reads. The
> This is an implementation choice that SRM conformant software was
> forbidden to rely upon.  It effectively extended the architecture,
> allowing field references (including BB*) to operate on I/O space.  It
> happened to be convenient for the "chip" VAXes, but it would not have
> been convenient for other technologies.  As I've noted, Aquarius (at
> least) made use of the restriction to avoid extra logic (and time) that
> would have been required to disable legal optimizations when referencing
> I/O space.  There was nothing "improper" about this - the programmer
> writing SRM-conformant code can not detect the implementation
> differences.  And because any peripheral hardware must be in I/O space
> where field references can't be made, neither can hardware.
>
> SRM section 7.5.3 (p. 7-25) lists the only instructions and operand
> addressing modes that can be used to reference I/O space.  The list
> excludes BB*.  The implementation note on p 7-26 of the SRM is explicit
> about this exclusion -- "For reference instructions were discarded as
> follows"... (7) "operand types: ... BB{S,C}, BB{S,C}{S,C}..."
>
> All that said, the VAX chips are SRM compliant - they are not required
> to enforce the rule that field references may not be to I/O space.
> Their behavior in this UNDEFINED case happens to be predictable - and
> some coder got away with relying on it.  It's the CODE, not the machine
> that is violating the SRM.  Unfortunately.  This is why we encouraged
> implementations to check for violations whenever possible.
>
> NVAX borrowed some of its microarchitecture from Aquarius (and in fact,
> our RQT machines ran the NVAX simulations).  I'm not sure what it did
> with this case - it simplified things to fit in the VLSI of the time.
> But had development continued, I expect that eventually the chip VAXes
> would have made more aggressive use of the SRM's opportunities for
> optimization.  And this code fragment would have caused an issue on them
> as well.
>
> > 780 microcode used byte accesses for BBxy, so I assume it did the same.
> >
> > Only two hypotheses are possible: either the 750 microcode makes a
> > real longword reference (all byte mask bits set), in contravention of
> > the SRM; or the RH750 doesn't check operand lengths. I incline to the
> > latter hypothesis, but we need either the  RH750 spec to be sure.
> >
> Since it's a *memory* read (and as you note), the byte masks need not be
> passed to the cache.  What matters to the SRM is whether the programmer
> can detect a reference beyond the selected byte.  Assuming the ucode
> doesn't do something stupid (like reference beyond the end of a page and
> report an undeserved exception), reading a byte, a word, a longword or
> an octaword doesn't contravene the SRM.  Internally, the memory
> subsystem is almost certain to read more than a byte due to ECC.  As
> long as the instruction selects the correct bit to branch on, the
> reference type doesn't matter.  (If the BB were a BBx{S,C}, then the
> write would have to obey the atomicity rules.  But that doesn't apply to
> the reported case.)  So I don't agree with your "in contravention of the
> SRM."
>
> If a programmer can't distinguish an implementation from the SRM
> description, it's legal.  Just like SRM 2.6 which says that the
> architecture assumes a sequential model where "no instruction is
> processed, (even partially) until the one before it completes."  If
> implementations adhered literally to that, there could be no instruction
> or data prefetch, branch prediction, or speculation.  And every VAX
> would be non-conformant.  The SRM is interpreted to mean that an
> implementation must work from a programmers point of view "as if" it
> literally follows the text.  But what's under the covers is fodder for
> creativity.
>
> Now if it's a reference to I/O space, this does become important.  But
> that's what is in contravention of the SRM.  This instruction is not
> allowed to have an operand in I/O space.  To correctly support I/O
> space, including registers that have read side-effects, byte masks need
> to be supplied and obeyed.  I guess the good news is that if this is
> only being done with MBA registers, offhand I can't think of a Massbus
> device that has registers with read side-effects.
>
> I don't know whether the 750 spec says that the machine will support all
> types of references to I/O space, even those disallowed by the SRM.   If
> it does, no software engineer should have relied on the statement.
> Except, perhaps a platform-specific diagnostic coder in some corner
> case.  Specs weren't required to list what happens in all the UNDEFINED
> cases.
>
> You're probably right that the the RH750 doesn't check lengths.  I hope
> that the RH or CPU spec clarifies this for you, but as it's an
> UNDEFINED, I wouldn't bet on whether there's enough information in the
> specs to tell.
>
> What *is* clear is that this particular bit of code worked on the real
> 750 hardware & that SRM issues aside, SimH will have to make it work
> too.  Exactly how painful that must be depends on how pervasive this
> non-compliant coding is...and the SimH 750 code, which I haven't
> examined.  From your description, the RH shouldn't be throwing an error...
>
> > /Bob
> >
> > On 8/11/2015 12:00 PM, simh-request at trailing-edge.com wrote:
> >> Message: 3 Date: Mon, 10 Aug 2015 15:02:48 -0400 From: Timothe Litt
> >> <litt at ieee.org> To: simh at trailing-edge.com Subject: Re: [Simh]
> >> Needed: RH750 specification Message-ID: <55C8F558.1060508 at ieee.org>
> >> Content-Type: text/plain; charset="utf-8" On 10-Aug-15 14:13, Bob
> >> Supnik wrote:
> >>> >Mark Pizzolato sent me a note about a code sequence in the original
> >>> >VAX750 bootstrap that fails on the 750 simulator. The code is doing a
> >>> >
> >>> >BBC #7,address,10$
> >>> >
> >>> >where the address is in the RH750 Massbus adapter. The sequence fails
> >>> >because the simulated RH750 throws an error - the operand access is
> >>> >not an aligned longword.
> >>> >
> >>> >BBC and the other bit branches use a byte access operand. The SRM says
> >>> >that VAX implementations must access the precise byte specified by the
> >>> >base address and the byte part of the bit offset. There's no leeway in
> >>> >the wording, and the VAX chips (and the 780) do precisely that.
> >>> >
> >> This is not exactly correct.  BB uses a FIELD access, not a pure byte
> >> access.  SRM 3.5 (p. 3-56 "BB") "opcode pos.rl, base.vb, displ.bb,
> >> {field.mv}" Note the "v".
> >>
> >> Fields are 1-5 bytes, and "access the minimum number of aligned
> >> longwords necessary to to contain the field".  (SRM 1.2.10)  (Rev. J
> >> added a reference to INSV in 3.4, but this postdates the 750 and isn't
> >> relevant here.)
> >>
> >> The SRM also says that BBC is not legal in I/O space.  See 7.5.5 (3) --
> >> BBC is a control instruction with a field operand.  Operand types of
> >> field are not legal in I/O space.
> >>
> >> As a practical matter, BB is problematic in I/O space.  For example,
> >> Aquarius fetches a quadword around the base address, which can have side
> >> effects reading the unwanted register... (And yes, the implementation
> >> conforms to 1.2.10 from the programmer's perspective when the field is
> >> in memory.)  I remember finding and removing a number of OS/driver bugs
> >> where I/O space was used...
> >>
> >> That said, programmers do things that are unspecified & when they "seem
> >> to work" on the hardware they're using, move on.
> >>
> >> Apparently the 750 hardware deals with whatever access the CPU generates
> >> for BBC - which architecturally can be anything from a byte read to a
> >> longword.
> >>
> >> I don't have the RH750 specification - but this is unspecified
> >> behavior.  I would be mildly surprised if the spec bothered to
> >> mention it.
> >>
> >> The spirit of SimH, of course, is to make the software work despite
> >> implementation bugs.  I'd say this is an unspecified behavior in the
> >> RH750 simulator that SimH needs to fix there... Removing the check is
> >> probably the right hack - with a suitable comment.
> >>
> >>> >If the 750 microcode is correctly implemented, then the best
> >>> >explanation is that the RH750, unlike the RH780, does not in fact
> >>> >check the length (and possibly not the alignment) of register
> >>> >accesses. This is true of the respective Unibus adapters: the 780's
> >>> >does lots of checking, the 750's does none.
> >>> >
> >> Either the 780 driver doesn't do this, or this particular case isn't
> >> checked for in the 780 hardware.  The hardware is not obliged to check
> >> for UNSPECIFIED behavior (FIELD in I/O space).  If the 780 ucode happens
> >> to make a longword reference to fetch the byte for BB (which is valid
> >> for memory, so long as it's aligned & won't pagefault), things would
> >> "appear to work".  Without looking at the hardware, that would be my
> >> guess.
> >>
> >>> >The 750 simulator is not mine, but I'd like to track this problem
> >>> >down. The RH750 schematics don't help, because the critical logic is
> >>> >inside gate arrays. What's needed is an RH750 specification. Does
> >>> >anyone have it?
> >>> >
> >>> >Thanks,
> >>> >
> >>> >/Bob Supnik
> >>> >
> >
> > _______________________________________________
> > Simh mailing list
> > Simh at trailing-edge.com
> > http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150812/27039d7d/attachment-0001.html>

From litt at ieee.org  Wed Aug 12 09:03:41 2015
From: litt at ieee.org (Timothe Litt)
Date: Wed, 12 Aug 2015 09:03:41 -0400
Subject: [Simh] Needed: RH750 specification
In-Reply-To: <55CA56DC.5040402@supnik.org>
References: <mailman.1.1439308802.25128.simh@trailing-edge.com>
 <55CA56DC.5040402@supnik.org>
Message-ID: <55CB442D.5010200@ieee.org>

For the non-"SRM lawyers":  the short(er) form of my long reply:

1) Yes, SimH needs to match the 750's behavior.

2) No, the SRM doesn't tell you how to do it. 

3) The *code* in question violates the SRM because this instruction is
not allowed to reference I/O space.  The result is UNDEFINED, which
means that the 750 implementation can do anything except hang the
processor or console.  This includes executing the instruction as if the
operand was in memory, but that's not the only possibility.  Singing
"God save the Queen" on the paper tape punch and clearing memory is
equally valid.  Really. :-)

So any argument that defines useful behavior based on the SRM is not
dispositive.

4) Exactly how the instruction is implemented when the operand IS in
memory can differ from the literal SRM text, as long as the programmer
sees results AS IF the SRM text was followed literally.  Which is hard
because the text is somewhat confused.  But memory behavior is fairly
flexible.  Attempting to apply this to I/O space gets complicated,
because I/O space has special characteristics and rules. (This is why
there are restrictions on which instructions can be used.)

What SimH does now is SRM-compliant.  It's just not useful in that the
hardware does something different.

The 750 specs may or may not describe what happens in this UNDEFINED
case.  They're not required to.

An intelligent guess would suffice for this case.  Reading the byte or
reading the aligned longword and extracting the byte would both work. 
SimH can choose based on its internals.

Supporting all the field instructions for I/O space, especially those
that modify the field, is more involved.  Multi-bit fields can span
bytes and longwords (EXTV, FF, etc).  The 750 probably has restrictions
(perhaps documented, certainly practical) on how this interacts with I/O
space.  E.g. INSV to a field that crosses two longword I/O registers
probably doesn't work as expected. 

To keep the scope of this effort reasonable, one probably wants to do
the "simple obvious" thing, and deal with the messy cases if code
surfaces that invokes them.  And hope that none does...

On 11-Aug-15 16:11, Bob Supnik wrote:
> Actually, the SRM spells out exactly how BBS/BBC behave in 7.3,
> subparagraph 6d (now you know why microcoders were called SRM lawyers):
>
> "BB{S,C}, BB{S,C}{S,C}. Only the single byte specified by the base and
> position operands is read."
>
> In short, a byte access, mandated by the SRM.
>
> Now, most VAXen could only read a whole longword or quadword from
> memory, but the system bus contained a byte mask or other encoding to
> say which bytes really mattered. This could be ignored on memory
> reads, of course. In generating byte masks, the VAX chips made no
> distinction between memory space and IO space and would generate
> proper byte masks for all reads. The 780 microcode used byte accesses
> for BBxy, so I assume it did the same.
>
> Only two hypotheses are possible: either the 750 microcode makes a
> real longword reference (all byte mask bits set), in contravention of
> the SRM; or the RH750 doesn't check operand lengths. I incline to the
> latter hypothesis, but we need either the  RH750 spec to be sure.
>
> /Bob
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150812/e505aac6/attachment.bin>

From clemc at ccc.com  Wed Aug 12 10:09:54 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 12 Aug 2015 10:09:54 -0400
Subject: [Simh] Needed: RH750 specification
In-Reply-To: <55CB442D.5010200@ieee.org>
References: <mailman.1.1439308802.25128.simh@trailing-edge.com>
 <55CA56DC.5040402@supnik.org> <55CB442D.5010200@ieee.org>
Message-ID: <CAC20D2P0Wbwc6X_KbSWAtMo5V=KTPt_h__ndUhrtVpHkx9dh2w@mail.gmail.com>

​below​

On Wed, Aug 12, 2015 at 9:03 AM, Timothe Litt <litt at ieee.org> wrote:

> What SimH does now is SRM-compliant.  It's just not useful in that the
> hardware does something different.
>
+1




> The 750 specs may or may not describe what happens in this UNDEFINED
> case.  They're not required to.
>
​Right - but as you point out, that probably does not matter either since
we have a real implementation of 750 and code written for that
implementation.   The documentation for the implementation is nice, the
primary target is not the documentation. ;-)

>
> ​...
>
>
> To keep the scope of this effort reasonable, one probably wants to do
> the "simple obvious" thing, and deal with the messy cases if code
> surfaces that invokes them.  And hope that none does...
>
​I think this is reasonable - certainly for the case of UNIX.  IMO: The
good news here is that the danger should be limited to boot level code.
The BSD kernel code itself, tried to be CPU independent so that the
"generic" UNIX could load and run.   If people wanted to customize, their
own kernel they could, but they did not have too.   Thus by the time you
got to the kernel itself loaded into memory, the drivers would have had to
been agnostic - certainly the ones I wrote were.  The only time I ever got
funky/CPU specific was dealing with boot loader which was needed to be
specific to each CPU implementation.     I had 780's only in my lab in Cory
Hall, the mass of 750's were over in Evans in the main CSRG machine room at
the time.  IIRC: ​ Leffler and Joy wrote the 750 boot loader for BSD
(although Rob Pike had a 750 in BTL a few months before we got one at UCB -
so it's possible Sam could have gotten the boot loader from him).

My point is that if there was something really bad in the kernel drivers
itself, I think we would have seen it before now because the other Vax
implementations would have tripped over that code path.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150812/bde26e2c/attachment.html>

From frisbie at flying-disk.com  Wed Aug 12 10:17:53 2015
From: frisbie at flying-disk.com (Alan Frisbie)
Date: Wed, 12 Aug 2015 07:17:53 -0700 (PDT)
Subject: [Simh] Needed: RH750 specification
Message-ID: <15081207175345_44C@slug.flying-disk.com>

I am really loving (seriously!) this discussion of documentation
versus reality.   It takes me back to the days when I was writing
drivers and diagnostics for custom devices, and debugging others
failures.

Please continue these discussions in public, as I find them quite
enjoyable -- and educational.

Alan "Undefined Behavior" Frisbie

From litt at ieee.org  Wed Aug 12 14:23:57 2015
From: litt at ieee.org (Timothe Litt)
Date: Wed, 12 Aug 2015 14:23:57 -0400
Subject: [Simh] Needed: RH750 specification
In-Reply-To: <CAC20D2P0Wbwc6X_KbSWAtMo5V=KTPt_h__ndUhrtVpHkx9dh2w@mail.gmail.com>
References: <mailman.1.1439308802.25128.simh@trailing-edge.com>
 <55CA56DC.5040402@supnik.org> <55CB442D.5010200@ieee.org>
 <CAC20D2P0Wbwc6X_KbSWAtMo5V=KTPt_h__ndUhrtVpHkx9dh2w@mail.gmail.com>
Message-ID: <55CB8F3D.3040708@ieee.org>

On 12-Aug-15 10:09, Clem Cole wrote:
>
>     The 750 specs may or may not describe what happens in this UNDEFINED
>     case.  They're not required to.
>
> ​Right - but as you point out, that probably does not matter either
> since we have a real implementation of 750 and code written for that
> implementation.   The documentation for the implementation is nice,
> the primary target is not the documentation. ;-)
>
>
>     ​ .
>
Agreed. My point was that searching for the RH750 spec - which is what
started this - may not resolve the question that Bob raised.
>
>     ..
>
>
>     To keep the scope of this effort reasonable, one probably wants to do
>     the "simple obvious" thing, and deal with the messy cases if code
>     surfaces that invokes them.  And hope that none does...
>
> ​I think this is reasonable - certainly for the case of UNIX.  IMO:
> The good news here is that the danger should be limited to boot level
> code.  The BSD kernel code itself, tried to be CPU independent so that
> the "generic" UNIX could load and run.   If people wanted to
> customize, their own kernel they could, but they did not have too.  
> Thus by the time you got to the kernel itself loaded into memory, the
> drivers would have had to been agnostic - certainly the ones I wrote
> were.  The only time I ever got funky/CPU specific was dealing with
> boot loader which was needed to be specific to each CPU
> implementation.     I had 780's only in my lab in Cory Hall, the mass
> of 750's were over in Evans in the main CSRG machine room at the
> time.  IIRC: ​ Leffler and Joy wrote the 750 boot loader for BSD
> (although Rob Pike had a 750 in BTL a few months before we got one at
> UCB - so it's possible Sam could have gotten the boot loader from him). 
>
> My point is that if there was something really bad in the kernel
> drivers itself, I think we would have seen it before now because the
> other Vax implementations would have tripped over that code path.
>
Even boot code should have been platform independent in the sense of
SRM-compliant.  "A VAX is a  VAX is a VAX.  period."  The only code that
legally relied on implementation quirks was the code that implemented
the VLSI VAX "console".  (Well, and maybe some diagnostic, though that
was discouraged.)  The VLSI console is the reason for the note in the
SRM that allows platform-specific code to fetch i-stream from I/O space
(e.g. a [flash] rom) and/or to have the stack or PCB in I/O space. (SRM
7.5.3 before the final implementation note "Notwithstanding the above
rules...").  However, this exception carefully does NOT allow fields to
live in I/O space.  This is always illegal.  And as I've noted, in the
general case (size > 1) there is no obvious definition of how a field in
I/O space should/could work.

I was responsible for all the OS software on Aquarius - VMS (including
VMB, which packaged the boot drivers), System V, Ultrix, & VAX/ELN. 
This involved a lot of SRM lawyering with my friends in the OS groups,
in the hardware architecture groups (peripherals tried to take shortcuts
too) and in the console and diagnostic groups.  I know that I removed
(or caused to be removed) a fair bit of non-SRM-compliant code like that
discussed in this thread.  So this is a very familiar discussion. 

One problem is that VMB was stuck in ROM or in console code that was
only updated by FCO (field service).  So fixes to VMB rarely got pushed
back to prior implementations, especially for the VLSI VAXen.  And new
OS releases were pretty much stuck with old VMB bugs.  (Though having
ROM load VMB load a newer VMB, which then loaded the OS was not unheard
of.)  For the separate console VAXes, VMS could push a new VMB onto the
console media. 

VMS was pretty clean when it came to SRM compliance.  Both because the
engineers were regularly educated, and because low-level code is
assembler.  But the other OSs, often because they used compilers for
low-level code and were further from the hardware groups, had more
broken code.  "But INSV to this register works on <insert platform
here>; C (or PASCAL) has always generated it here."  Sorry, it's not
legal.  And even on <foo>, it may not work with the next set of peephole
optimizations...

VMB is the VAX bootstrap (initially VMS bootstrap, but ALL the OSs use
it).  It contains the primitive drivers for the boot device, a pointer
to the selected one is passed to the first part of the OS, which
typically saves that driver for writing crash dumps and for loading the
rest of the OS.  [In the case of VMS, this would be SYSLOAxxx - the
platform dependent module, and for VMS 5+, the loadable execlets.]  The
OS has no control over these drivers.  The BSD boot loader is probably
the code loaded by VMB.  I haven't looked at it, so don't know whether
it used the primitive boot drivers, or ignored them and supplied its
own.  It could do either, depending on the NIH quotient of those who
wrote it.

The platform dependencies were not SRM exceptions.  They were things
like machine check error handling, bus and bus adapter enumeration and
error handling (SBI is rather different from XMI), subset instruction
emulation.  There is a certain amount of cleverness in the way busses
layer; a UDA-50 on a unibus on a BI on an XMI can look the same to its
driver as one on a unibus on an SBI.  If it's properly configured and
enumerated, the addresses are mapped and remapped so the driver can be
platform-agnostic.  But that's a different kind of platform
compatibility from the main discussion here.  Here we have a problem
caused by code which does something that is explicitly forbidden by the
SRM.  SimH does need to emulate the hardware's behavior.  But appeals to
what the SRM says do not resolve what the 750 does (or should do). 
UNDEFINED is a black hole.   Other implementations may do what this code
expects.  Or may not.  Did BSD ever run on Aquarius (VAX 9000)?  It
wasn't on my list.  I guarantee that if it did, this particular
instruction would fail spectacularly...

Once the OS was loaded (and usually after memory management and
interrupts were turned on), the OS-supplied drivers would be used.

In theory, the OS could use its own drivers for loading itself.  But
this was rarely convenient as they tend to rely on process structure,
memory management and interrupts.  All of which usually aren't present
until at least 2 pieces of the OS are loaded...

So the smart move was to use the VMB-supplied primitive boot driver to
continue the load & switch to the OS drivers once the OS core functions
were alive.  Not only are they there, but someone else wrote and
debugged them... Though people with sufficiently large NIH quotients
could always find reasons to redefined 'smart'.

And that's probably more than most people on this list ever wanted to
know...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150812/1e465bcc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150812/1e465bcc/attachment.bin>

From bob at supnik.org  Wed Aug 12 17:25:58 2015
From: bob at supnik.org (Bob Supnik)
Date: Wed, 12 Aug 2015 17:25:58 -0400
Subject: [Simh] BBS/C behavior [was Re:  Needed: RH750 specification]
In-Reply-To: <mailman.1.1439395201.25847.simh@trailing-edge.com>
References: <mailman.1.1439395201.25847.simh@trailing-edge.com>
Message-ID: <55CBB9E6.7030807@supnik.org>

On 8/12/2015 12:00 PM, simh-request at trailing-edge.com wrote:
> Message: 1
> Date: Wed, 12 Aug 2015 09:03:41 -0400
> From: Timothe Litt<litt at ieee.org>
> To:simh at trailing-edge.com
> Subject: Re: [Simh] Needed: RH750 specification
> Message-ID:<55CB442D.5010200 at ieee.org>
> Content-Type: text/plain; charset="utf-8"
>
> For the non-"SRM lawyers":  the short(er) form of my long reply:
>
> 1) Yes, SimH needs to match the 750's behavior.
Agreed. That's why I want to know what the 750 did for real, not guess 
at it.
>
> 2) No, the SRM doesn't tell you how to do it.
I'll disagree here, but I don't have sufficient evidence that every 
system (except the 9000) did it the way I describe. I have checked all 
the VAX chip microcode listings, including NVAX; they all issue a read 
of byte length. The 780 is the same. However, I don't have microcode 
listings for MicroVAX I, 730, 750, 8600, or 8800.

The point is moot for memory. For BBx, which is read only, memory can't 
detect the kind of reference used, it doesn't matter. The write back in 
BBxy{I} does have to be precisely one byte, because the VAX supported 
byte granularity of sharing.
> 3) The*code*  in question violates the SRM because this instruction is
> not allowed to reference I/O space.
Yes, but as you point out, it works, as did the BLBC to Qbus space in 
Ultrix. That too is outlawed by the SRM (only byte and word references 
allowed), but it worked on real hardware, and I ended up rewriting all 
of the unaligned memory access routines to get it to work per the hardware.
>
> 4) Exactly how the instruction is implemented when the operand IS in
> memory can differ from the literal SRM text, as long as the programmer
> sees results AS IF the SRM text was followed literally.  Which is hard
> because the text is somewhat confused.  But memory behavior is fairly
> flexible.  Attempting to apply this to I/O space gets complicated,
> because I/O space has special characteristics and rules. (This is why
> there are restrictions on which instructions can be used.)
>
> What SimH does now is SRM-compliant.  It's just not useful in that the
> hardware does something different.
>
I would prefer to say that SimH 750 is inaccurate. It's rather broad to 
label SimH, or even SimH VAX, as not useful.

The question of where the 750 simulator is inaccurate is easily tested 
on real hardware. Try

BITB #1,aligned_massbusadapterregister

If there's a trap, exception, or interrupt, then the implementation of 
BBx is wrong for the 750. If there's none, then the Massbus adapter 
doesn't validate operand lengths, just like its Unibus counterpart.

/Bob

From Mark at infocomm.com  Wed Aug 12 17:42:53 2015
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Wed, 12 Aug 2015 14:42:53 -0700
Subject: [Simh] Needed: RH750 specification
In-Reply-To: <55CB442D.5010200@ieee.org>
References: <mailman.1.1439308802.25128.simh@trailing-edge.com>
 <55CA56DC.5040402@supnik.org> <55CB442D.5010200@ieee.org>
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A823754E0736@REDROOF2.alohasunset.com>

I'm the one who raised this particular question.

It came up due to Mattis Lind's recent comments/questions to me about why the VAX750 simulator didn't boot exactly like the real hardware did.  Specifically, the initial implementation of the VAX750 simulator borrowed the paradigm used by the VAX780 simulator.  That paradigm reflects what happened in the VAX 11/780 console subsystem to boot the system.  Specifically, the simh boot mechanisms performed the same steps that the normal console XXXBOO.CMD file did on the console LSI11.  Those steps initialized the CPU, copied VMB.EXE to RAM and loaded some registers with parameters useful for VMB and started execution of VMB.

This paradigm works fine on any VAX, but the real VAX 11/750 hardware was different.  It had a 4 position boot device selector switch which was used to 'point' at a ROM routine which loaded sector 0 from the target disk (specified by the switch position) and started execution of the data that was loaded.  This is called a boot block boot which is distinctly different from the VMB boot.  The VMB boot has code which can parse ODS1 and ODS2 file structures so it locates the secondary boot files by walking the file system.  If R5 bit 3 is set, VMB will do a boot block boot as well.  When VMB was moved into ROM for the MicroVAX systems the boot behavior was changed to first try a file structure boot and if that failed fall back to a boot block boot.  This allowed Ultrix and BSD systems (which didn't have OSD2 file systems) to boot without any special commands being entered.  The current VMB.EXE provided with the simh simulators has been patched to also perform this file structure boot with a fallback to a boot block boot.  

In any case, inspired by Mattis Lind's question I've looked into providing the ROM based boot for the VAX750 simulator.  Mattis has a working VAX 11/750 system and he was able to extract the console ROM contents (using >>> E ROMaddr commands).  He happened to have more than one ROM set.  An older one which could boot from TU58, RK06, DL and UDA devices and a newer one which could boot from TU58, RP/RM and UDA devices.  The code which started this thread is the boot block boot of the RP/RM device.  I'm working my way through each of these new pieces of boot code to make sure that they actually behave like the original hardware did.

Apart from the interesting question about BBC for the RP/RM boot, booting the Unibus devices showed that UBA's initial power on/reset state clearly had the map registers initialized to 1) be valid and 2) map the first 256Kb of RAM directly.  The minimal boot code in the ROM doesn't mess with the Unibus Map at all, so this initial state must have existed.

I've been distracted by other real world problems for the past few days and I'll get back to finish this debugging soon.

- Mark


From phil at ultimate.com  Wed Aug 12 18:06:57 2015
From: phil at ultimate.com (Phil Budne)
Date: Wed, 12 Aug 2015 18:06:57 -0400
Subject: [Simh] Needed: RH750 specification
In-Reply-To: <55CB326F.8080801@ieee.org>
References: <mailman.1.1439308802.25128.simh@trailing-edge.com>
 <55CA56DC.5040402@supnik.org> <55CB326F.8080801@ieee.org>
Message-ID: <201508122206.t7CM6v9K025231@ultimate.com>

Tim wrote:
> This is a case of the *software* not conforming to the SRM, and relying
> on an UNDEFINED implementation choice.  BB* is not allowed to have an
> operand in I/O space, and the result of such an instruction is
> UNDEFINED.

I hope there is a special corner in Hell(*) reserved for people who
think C "bitfields" are a good way to do I/O register access!  Yeah,
it's a pain to read, modify and write a specific width of data, but
there's NO telling what the compiler will generate, and whether it
will work.

(*) I guess it's a sub-corner of the corner for people who say
"it's working fine for me right now"

From jeremy at vsm.com.au  Wed Aug 12 19:05:46 2015
From: jeremy at vsm.com.au (Jeremy Begg)
Date: Thu, 13 Aug 2015 08:35:46 +0930
Subject: [Simh] Needed: RH750 specification
In-Reply-To: <55CB8F3D.3040708@ieee.org>
References: <mailman.1.1439308802.25128.simh@trailing-edge.com>
 <55CA56DC.5040402@supnik.org> <55CB442D.5010200@ieee.org>
 <CAC20D2P0Wbwc6X_KbSWAtMo5V=KTPt_h__ndUhrtVpHkx9dh2w@mail.gmail.com>
 <55CB8F3D.3040708@ieee.org>
Message-ID: <39AD8122-A419-457E-89A9-6EA354B90E94@vsm.com.au>

Hi Timothe,

> On 13 Aug 2015, at 3:53 am, Timothe Litt <litt at ieee.org> wrote:
> 
> And that's probably more than most people on this list ever wanted to know...

Quite the contrary, like Alan I have thoroughly enjoyed this discussion.

Thanks,

Jeremy Begg

From pontus at Update.UU.SE  Thu Aug 13 02:15:36 2015
From: pontus at Update.UU.SE (Pontus Pihlgren)
Date: Thu, 13 Aug 2015 08:15:36 +0200
Subject: [Simh] Needed: RH750 specification
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A823754E0736@REDROOF2.alohasunset.com>
References: <mailman.1.1439308802.25128.simh@trailing-edge.com>
 <55CA56DC.5040402@supnik.org> <55CB442D.5010200@ieee.org>
 <03006E3FC39B5A48AB9DBCCC101090A823754E0736@REDROOF2.alohasunset.com>
Message-ID: <20150813061536.GA5921@Update.UU.SE>

On Wed, Aug 12, 2015 at 02:42:53PM -0700, Mark Pizzolato - Info Comm wrote:
> 
> I'm working my way through each of these new pieces of boot code to 
> make sure that they actually behave like the original hardware did.
> 

I'm amazed by the effort you put in and level of accuracy that you are 
going for! It's commendable!

And I'm happy that my old VAX comes to good use.

Regards,
Pontus.

From bob at supnik.org  Thu Aug 13 21:19:19 2015
From: bob at supnik.org (Bob Supnik)
Date: Thu, 13 Aug 2015 21:19:19 -0400
Subject: [Simh] SC/750
Message-ID: <55CD4217.5040803@supnik.org>

While no RH750 spec has been found, the spec for Emulex's SC/750 is 
online. It provides a detailed summary of the RH750 internal registers. 
As I suspected, the RH750 is a subset of the RH780, with lots of status 
bits and a register or two omitted. It also adds a mode not present in 
the RH780 - ignore byte count mode.

Unfortunately, it doesn't answer the question of how BBS/C works. The 
spec says that accesses "should" be done with longword instructions but 
doesn't say what happens in other cases - unlike the RH780 spec, which 
says explicitly that a machine check occurs.

/Bob


From cvanbrederode at gmail.com  Fri Aug 21 12:45:43 2015
From: cvanbrederode at gmail.com (Chris Van Brederode)
Date: Fri, 21 Aug 2015 12:45:43 -0400
Subject: [Simh] Odd Question on CP/M and sector sizes
Message-ID: <CAMAo5ptaoeNftAiLiOYUZcWVS+Ru0i_v5Smm64SqcNZ_8icraw@mail.gmail.com>

Hello,

I'm working on coding my own 8080 emulator (as an exercise/hobby) and I've
gotten to the point where I need to build BIOS for CP/M.  I'm looking at
using a SIMH based Altair emulator to build the CP/M for my system.

I have a weird question though.  All the documentation I can find on CP/M
and floppies from that era point to a 128 byte sector size.  But the source
code in simh/Altair/altair_dsk.c (and also in the AltairZ80 source), the
sector size is given as 137 bytes.

Looking at this makes me cock my head like a dog.  What is up with the
extra 9 bytes?  Where do they go when the fdc reads a 128 sector to memory
for CP/M 3?

Sorry if I sound ignorant, but I've actually tried to research this, but
the only place I can find that mentions 137 byte sectors is the source
file, and one post on this list that mentions that it is 137 bytes but
doesn't say anything beyond that.

Thanks for any help,

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150821/32565a55/attachment.html>

From tvoverbeek at esa.nascom.nasa.gov  Fri Aug 21 13:35:27 2015
From: tvoverbeek at esa.nascom.nasa.gov (Ton van Overbeek)
Date: Fri, 21 Aug 2015 19:35:27 +0200
Subject: [Simh] Odd Question on CP/M and sector sizes
In-Reply-To: <CAMAo5ptaoeNftAiLiOYUZcWVS+Ru0i_v5Smm64SqcNZ_8icraw@mail.gmail.com>
References: <CAMAo5ptaoeNftAiLiOYUZcWVS+Ru0i_v5Smm64SqcNZ_8icraw@mail.gmail.com>
Message-ID: <D1FD2D95.13AB4%tvoverbeek@esa.nascom.nasa.gov>

Chris,

A bit of Googling showed that the 137 byte physical sector size came from
The Altair 88 disk controller.
Search for 'Altair 88 dcdd disk controller 137¹

HTH
Ton

From:  Simh <simh-bounces at trailing-edge.com> on behalf of Chris Van
Brederode <cvanbrederode at gmail.com>
Date:  Friday 21 August 2015 18:45
To:  <simh at trailing-edge.com>
Subject:  [Simh] Odd Question on CP/M and sector sizes

Hello,

I'm working on coding my own 8080 emulator (as an exercise/hobby) and I've
gotten to the point where I need to build BIOS for CP/M.  I'm looking at
using a SIMH based Altair emulator to build the CP/M for my system.

I have a weird question though.  All the documentation I can find on CP/M
and floppies from that era point to a 128 byte sector size.  But the source
code in simh/Altair/altair_dsk.c (and also in the AltairZ80 source), the
sector size is given as 137 bytes.

Looking at this makes me cock my head like a dog.  What is up with the extra
9 bytes?  Where do they go when the fdc reads a 128 sector to memory for
CP/M 3?

Sorry if I sound ignorant, but I've actually tried to research this, but the
only place I can find that mentions 137 byte sectors is the source file, and
one post on this list that mentions that it is 137 bytes but doesn't say
anything beyond that.

Thanks for any help,

Chris
_______________________________________________ Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150821/9a67e36b/attachment.html>

From elson at pico-systems.com  Sat Aug 22 14:50:21 2015
From: elson at pico-systems.com (Jon Elson)
Date: Sat, 22 Aug 2015 13:50:21 -0500
Subject: [Simh] Simh Digest, Vol 139, Issue 23
In-Reply-To: <mailman.1.1440259201.5621.simh@trailing-edge.com>
References: <mailman.1.1440259201.5621.simh@trailing-edge.com>
Message-ID: <55D8C46D.3060904@pico-systems.com>


>
>
> Message: 1
> Date: Fri, 21 Aug 2015 12:45:43 -0400
> From: Chris Van Brederode <cvanbrederode at gmail.com>
> To: simh at trailing-edge.com
> Subject: [Simh] Odd Question on CP/M and sector sizes
>
> Hello,
>
> I'm working on coding my own 8080 emulator (as an exercise/hobby) and I've
> gotten to the point where I need to build BIOS for CP/M.  I'm looking at
> using a SIMH based Altair emulator to build the CP/M for my system.
>
> I have a weird question though.  All the documentation I can find on CP/M
> and floppies from that era point to a 128 byte sector size.  But the source
> code in simh/Altair/altair_dsk.c (and also in the AltairZ80 source), the
> sector size is given as 137 bytes.
>
>
Wow, I've never run into that.  CP/M used a logical sector 
of 1024 bytes, IIRC.  They mapped this onto however many 
physical sectors the available media/controller provided.  
The only thing I can think of is the sector header is in the 
data portion (where usually it would be in a separate spot 
on the track.)  This would save space on the media, as you 
would not have to have an erase gap before and after the 
sector header, but it would require overwriting the sector 
header+data sector any time you wrote a sector.

I've never come across that.  I looked at the backup files 
from my CPM system, and at least for the hard drive I added, 
the logical sectors were definitely 1024, while the physical 
sectors were 256. I couldn't quite dope out what the floppy 
controller did.

Jon

From bqt at softjar.se  Wed Aug 26 09:44:45 2015
From: bqt at softjar.se (Johnny Billquist)
Date: Wed, 26 Aug 2015 15:44:45 +0200
Subject: [Simh] Announcing TCP/IP for RSX-11M-PLUS
In-Reply-To: <55928194.5040506@softjar.se>
References: <54B5ACD2.7080804@softjar.se> <54B889EE.4050807@softjar.se>
 <5575CAE9.4070207@softjar.se> <55928194.5040506@softjar.se>
Message-ID: <55DDC2CD.30902@softjar.se>

Close to two months since my last official release, so I figure it's 
time I do another one.

So - there is a new release of BQTCP/IP. I strongly encourage anyone who 
uses this software to upgrade.

A short list of changed:
. TCP have been rewritten to not use any system pool at all.
   Even the small amount previously used added up when a lot of
   traffic was going on.
   At the same time, IPPOOL usage for connections have also decreased,
   as memory is only allocated when needed for transmissions. This
   also lead to the ability to have larger transmit buffers.
. A new HELP file have been included for some help in general.
   If installed, you can see information through HELP/IP
. FTP rate calculation was slightly wrong. Fixed now.
. Various included tasks have now been built without the need for
   language specific resident libraries so that they can be used
   on any system.
. TCP could disconnect sessions erroneously under some circumstances.
   Fixed.
. Telnet daemon can give more comprehensive welcome messages now.
. WWW server CGI scripts could cause the web connection to close
   even though the script was not finished. Fixed.
. The SPOOF detection/prevention now will not block the DNS server.
. Improved response times for TCP connection establishment.
. If a daemon created a task, and the task never picked up the
   connection that came in, the socket was left in a broken state.
   Fixed.

As usual, the distribution is available from:
ftp://madame.update.uu.se/bqtcp.dsk
ftp://madame.update.uu.se/bqtcp.tap
ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk

The documentation is also available through ftp on Madame, or also at 
http://madame.update.uu.se/tcpipdoc

Right now, I don't know what the next project will be. Some testing and 
improvements. But I probably need to take a step back and look at the 
bigger picture. Do anyone have any special wishes (and don't say SSH or 
IPv6 :-) ).

Oh, and as a icing on the cake, http://magica.update.uu.se (or 
telnet://magica.update.uu.se) will lead you to a real, physical 
PDP-11/70 running this software. Magica have been on the internet in the 
past, but she has been down for quite some time. But I'm happy to 
announce that the machine is starting to live again.

	Johnny

On 2015-06-30 13:46, Johnny Billquist wrote:
> I'm happy to announce a new release of TCP/IP for RSX-11M-PLUS.
>
> Since I'm broadening the scope of the announcement slightly, a more
> complete list of features is included, and not just what changed since
> last. For anyone who is currently running TCP/IP for RSX, I strongly
> encourage you to update to this latest version. Several improvements
> have gone in in the last couple of weeks. Most important change is that
> there now is telnet support, both client and server side.
>
> The TCP/IP for RSX that I've written is sometimes referred to as
> BQTCP/IP, just to make clear that it is a different product than Process
> Software's TCPWARE, or JSA's TCP/IP.
>
> BQTCP/IP is a rather feature rich TCP/IP implementation, which also
> comes with libraries for various high level languages. The API is not
> compatible, even at the source level, with Unix, but on the other hand,
> if people write some code, they will see that it is a very easy API to
> work with. The reasons for the incompatibilities are several, including
> both resource concerns and differences between how RSX works and Unix
> like operating systems.
>
> BQTCP/IP has tried to comply with all relevant RFCs, but I'm sure there
> are corners where it does not do things right. It also does not demand
> much resources. It do require RSX-11M-PLUS with split I/D space, and it
> has only been tested properly on RSX-11M-PLUS V4.6. It should work on
> any version 4 release of RSX-11M-PLUS, but there might be a couple of
> tweaks or fixes needed.
>
> BQTCP/IP is distributed in binary form, so very little compilation is
> required to get it up and running. However, pretty much all utilities do
> come with sources. The actual TCP/IP stack sources are not included. I
> do not have a good setup for distributing them in a sane way, and it has
> had a low priority on my list of things to do. But I do not mind
> distributing the sources as a general principle.
>
> All that said, BQTCP/IP current supports the following protocols:
>
> o Ethernet and loopback interfaces.
> o ARP. BQTCP/IP can use Ethernet in co-existance with DECnet, or
>    standalone using the provided Unibus ethernet device driver.
> o IP. The largest IP packets supported are approximately
>    8KB.
> o ICMP.
> o UDP. The largest UDP packets supported are approximately
>    8KB.
> o TCP. The window is approximately 8KB in size, and TCP do
>    manage out of order packets in an efficient way.
>
> BQTCP/IP supports the following applications:
> o DHCP. DHCP can be used to configure interface addresses, network
>    masks, default gateways, DNS servers and NTP servers dynamically.
> o NTP. NTP can be used to set the local time.
> o TELNET. The TELNET server hooks in to the standard TT: terminal
>    driver, and the number of terminals to create is configurable.
>    The TELNET client can be used to connect to other systems.
> o FTP. The FTP server can serve all kind of files to other RSX
>    systems, and can serve text and binary files to any system.
>    The FTP client can retrieve RSX format files from RSX servers,
>    and text, binary and block format files from any system.
> o TFTP. The TFTP server and client can be used for simpler file
>    transfer operations.
> o RWHOD. RWHOD is a program that reports current users and uptime
>    from RSX, for other systems to collect.
> o IRC. IRC is a program to communicate with other users around
>    the world.
> o IRCBOT. IRCBOT is a small example robot program connecting to IRC
>    and performing a service for IRC users.
> o PCL. PCL is a protocol for printing, used by HP (and other) printers
>    over a network. The PCL implementation in BQTCP/IP appears as a
>    print symbiont, which you can create a printer queue for.
> o WWW. WWW (or World Wide Web) is a service that can present hypertext
>    information to clients. The WWW server in BQTCP/IP also supports CGI,
>    which makes it possible to create dynamic content.
> o DNS. BQTCP/IP have DNS implemented as an ACP, that anyone can query
>    to get translations between IP addresses and domain names. It also
>    supports different users using different name servers, or private
>    translations.
> o SINK. A standard TCP service.
> o ECHO. A standard TCP service.
> o DAYTIME. A standard TCP service.
> o QUOTD. A standard TCP service.
> o IDENTD. A standard TCP service.
>
> BQTCP/IP also have automatic IP spoof detection and prevention.
>
> Additional tools are IFCONFIG, PING, TRACEROUTE, NETSTAT as well as two
> new pages for RMD.
>
> High level language libraries exists for BASIC+2, PDP-11 C and FORTRAN-77.
>
> I'm sure I have forgotten a thing or three, but that's a fairly
> comprehensive list.
>
> The documentation is a weak point, but there is hopefully enough
> documentation to get people running, and I am happy to answer any
> questions, or give support if needed. BQTCP/IP is already running on the
> internet, and have been for a while. People who are curious to check it
> out can ether look at http://madame.update.uu.se/, or telnet to
> telnet://madame.update.uu.se and login as user GUEST with password
> GUEST, or use ftp against ftp://madame.update.uu.se. Anonymous ftp
> account exist.
>
> As usual, the distribution is available from:
> ftp://madame.update.uu.se/bqtcp.dsk
> ftp://madame.update.uu.se/bqtcp.tap
> ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk
>
> The .tap file is an RSX virtual tape. It is only possible to download
> and use if you are using FTP from anther RSX system and fetch the file.
> The .dsk files are virtual RL02 images that are useful both from within
> RSX as well as through emulators.
>
> The documentation is also available through ftp on Madame, or also at
> http://madame.update.uu.se/tcpipdoc
>
>      Johnny


From bqt at update.uu.se  Fri Aug 28 10:15:37 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Fri, 28 Aug 2015 16:15:37 +0200
Subject: [Simh] Announcing TCP/IP for RSX-11M-PLUS
In-Reply-To: <55DDC2CD.30902@softjar.se>
References: <54B5ACD2.7080804@softjar.se> <54B889EE.4050807@softjar.se>
 <5575CAE9.4070207@softjar.se> <55928194.5040506@softjar.se>
 <55DDC2CD.30902@softjar.se>
Message-ID: <55E06D09.5000901@update.uu.se>

I have received some bug reports, and it turns out there was some very 
serious bug in the release, which corrupted low memory, including 
interrupt vectors.

A new release have been cut. Please update immediately if you have 
updated since the announcement I made two days ago...

	Johnny

On 2015-08-26 15:44, Johnny Billquist wrote:
> Close to two months since my last official release, so I figure it's
> time I do another one.
>
> So - there is a new release of BQTCP/IP. I strongly encourage anyone who
> uses this software to upgrade.
>
> A short list of changed:
> . TCP have been rewritten to not use any system pool at all.
>     Even the small amount previously used added up when a lot of
>     traffic was going on.
>     At the same time, IPPOOL usage for connections have also decreased,
>     as memory is only allocated when needed for transmissions. This
>     also lead to the ability to have larger transmit buffers.
> . A new HELP file have been included for some help in general.
>     If installed, you can see information through HELP/IP
> . FTP rate calculation was slightly wrong. Fixed now.
> . Various included tasks have now been built without the need for
>     language specific resident libraries so that they can be used
>     on any system.
> . TCP could disconnect sessions erroneously under some circumstances.
>     Fixed.
> . Telnet daemon can give more comprehensive welcome messages now.
> . WWW server CGI scripts could cause the web connection to close
>     even though the script was not finished. Fixed.
> . The SPOOF detection/prevention now will not block the DNS server.
> . Improved response times for TCP connection establishment.
> . If a daemon created a task, and the task never picked up the
>     connection that came in, the socket was left in a broken state.
>     Fixed.
>
> As usual, the distribution is available from:
> ftp://madame.update.uu.se/bqtcp.dsk
> ftp://madame.update.uu.se/bqtcp.tap
> ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk
>
> The documentation is also available through ftp on Madame, or also at
> http://madame.update.uu.se/tcpipdoc
>
> Right now, I don't know what the next project will be. Some testing and
> improvements. But I probably need to take a step back and look at the
> bigger picture. Do anyone have any special wishes (and don't say SSH or
> IPv6 :-) ).
>
> Oh, and as a icing on the cake, http://magica.update.uu.se (or
> telnet://magica.update.uu.se) will lead you to a real, physical
> PDP-11/70 running this software. Magica have been on the internet in the
> past, but she has been down for quite some time. But I'm happy to
> announce that the machine is starting to live again.
>
> 	Johnny
>
> On 2015-06-30 13:46, Johnny Billquist wrote:
>> I'm happy to announce a new release of TCP/IP for RSX-11M-PLUS.
>>
>> Since I'm broadening the scope of the announcement slightly, a more
>> complete list of features is included, and not just what changed since
>> last. For anyone who is currently running TCP/IP for RSX, I strongly
>> encourage you to update to this latest version. Several improvements
>> have gone in in the last couple of weeks. Most important change is that
>> there now is telnet support, both client and server side.
>>
>> The TCP/IP for RSX that I've written is sometimes referred to as
>> BQTCP/IP, just to make clear that it is a different product than Process
>> Software's TCPWARE, or JSA's TCP/IP.
>>
>> BQTCP/IP is a rather feature rich TCP/IP implementation, which also
>> comes with libraries for various high level languages. The API is not
>> compatible, even at the source level, with Unix, but on the other hand,
>> if people write some code, they will see that it is a very easy API to
>> work with. The reasons for the incompatibilities are several, including
>> both resource concerns and differences between how RSX works and Unix
>> like operating systems.
>>
>> BQTCP/IP has tried to comply with all relevant RFCs, but I'm sure there
>> are corners where it does not do things right. It also does not demand
>> much resources. It do require RSX-11M-PLUS with split I/D space, and it
>> has only been tested properly on RSX-11M-PLUS V4.6. It should work on
>> any version 4 release of RSX-11M-PLUS, but there might be a couple of
>> tweaks or fixes needed.
>>
>> BQTCP/IP is distributed in binary form, so very little compilation is
>> required to get it up and running. However, pretty much all utilities do
>> come with sources. The actual TCP/IP stack sources are not included. I
>> do not have a good setup for distributing them in a sane way, and it has
>> had a low priority on my list of things to do. But I do not mind
>> distributing the sources as a general principle.
>>
>> All that said, BQTCP/IP current supports the following protocols:
>>
>> o Ethernet and loopback interfaces.
>> o ARP. BQTCP/IP can use Ethernet in co-existance with DECnet, or
>>     standalone using the provided Unibus ethernet device driver.
>> o IP. The largest IP packets supported are approximately
>>     8KB.
>> o ICMP.
>> o UDP. The largest UDP packets supported are approximately
>>     8KB.
>> o TCP. The window is approximately 8KB in size, and TCP do
>>     manage out of order packets in an efficient way.
>>
>> BQTCP/IP supports the following applications:
>> o DHCP. DHCP can be used to configure interface addresses, network
>>     masks, default gateways, DNS servers and NTP servers dynamically.
>> o NTP. NTP can be used to set the local time.
>> o TELNET. The TELNET server hooks in to the standard TT: terminal
>>     driver, and the number of terminals to create is configurable.
>>     The TELNET client can be used to connect to other systems.
>> o FTP. The FTP server can serve all kind of files to other RSX
>>     systems, and can serve text and binary files to any system.
>>     The FTP client can retrieve RSX format files from RSX servers,
>>     and text, binary and block format files from any system.
>> o TFTP. The TFTP server and client can be used for simpler file
>>     transfer operations.
>> o RWHOD. RWHOD is a program that reports current users and uptime
>>     from RSX, for other systems to collect.
>> o IRC. IRC is a program to communicate with other users around
>>     the world.
>> o IRCBOT. IRCBOT is a small example robot program connecting to IRC
>>     and performing a service for IRC users.
>> o PCL. PCL is a protocol for printing, used by HP (and other) printers
>>     over a network. The PCL implementation in BQTCP/IP appears as a
>>     print symbiont, which you can create a printer queue for.
>> o WWW. WWW (or World Wide Web) is a service that can present hypertext
>>     information to clients. The WWW server in BQTCP/IP also supports CGI,
>>     which makes it possible to create dynamic content.
>> o DNS. BQTCP/IP have DNS implemented as an ACP, that anyone can query
>>     to get translations between IP addresses and domain names. It also
>>     supports different users using different name servers, or private
>>     translations.
>> o SINK. A standard TCP service.
>> o ECHO. A standard TCP service.
>> o DAYTIME. A standard TCP service.
>> o QUOTD. A standard TCP service.
>> o IDENTD. A standard TCP service.
>>
>> BQTCP/IP also have automatic IP spoof detection and prevention.
>>
>> Additional tools are IFCONFIG, PING, TRACEROUTE, NETSTAT as well as two
>> new pages for RMD.
>>
>> High level language libraries exists for BASIC+2, PDP-11 C and FORTRAN-77.
>>
>> I'm sure I have forgotten a thing or three, but that's a fairly
>> comprehensive list.
>>
>> The documentation is a weak point, but there is hopefully enough
>> documentation to get people running, and I am happy to answer any
>> questions, or give support if needed. BQTCP/IP is already running on the
>> internet, and have been for a while. People who are curious to check it
>> out can ether look at http://madame.update.uu.se/, or telnet to
>> telnet://madame.update.uu.se and login as user GUEST with password
>> GUEST, or use ftp against ftp://madame.update.uu.se. Anonymous ftp
>> account exist.
>>
>> As usual, the distribution is available from:
>> ftp://madame.update.uu.se/bqtcp.dsk
>> ftp://madame.update.uu.se/bqtcp.tap
>> ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk
>>
>> The .tap file is an RSX virtual tape. It is only possible to download
>> and use if you are using FTP from anther RSX system and fetch the file.
>> The .dsk files are virtual RL02 images that are useful both from within
>> RSX as well as through emulators.
>>
>> The documentation is also available through ftp on Madame, or also at
>> http://madame.update.uu.se/tcpipdoc
>>
>>       Johnny
>
>


From md.benson at gmail.com  Fri Aug 28 17:36:11 2015
From: md.benson at gmail.com (Mark Benson)
Date: Fri, 28 Aug 2015 22:36:11 +0100
Subject: [Simh] Latest Sources?
Message-ID: <55E0D44B.2040709@gmail.com>

Hi,

Long time no comms. I've recently moved out to my own place and I'm 
rebuilding my DEC network from the ground up.

I've been out of the loop with SimH for a good while. Where is the best 
place to get the latest development sources from? Still github simh/master?

Thanks,
-- 

Mark @ DECtec.info
twitter.com/DECtecInfo

From Mark at infocomm.com  Fri Aug 28 17:41:08 2015
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Fri, 28 Aug 2015 14:41:08 -0700
Subject: [Simh] Latest Sources?
In-Reply-To: <55E0D44B.2040709@gmail.com>
References: <55E0D44B.2040709@gmail.com>
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A82379F90AEE@REDROOF2.alohasunset.com>

On Friday, August 28, 2015 at 2:36 PM, Mark Benson wrote:
> Long time no comms. I've recently moved out to my own place and I'm
> rebuilding my DEC network from the ground up.
> 
> I've been out of the loop with SimH for a good while. Where is the best
> place to get the latest development sources from? Still github simh/master?

Well, umm, yes!   

Most recent changes were just a few days ago.

A zip file of the latest code is at: https://github.com/simh/simh/archive/master.zip

Git access to the repo is https://github.com/simh/simh.git or git at github.com:simh/simh.git


- Mark



From dugo at xs4all.nl  Sat Aug 29 19:00:51 2015
From: dugo at xs4all.nl (Jacob Goense)
Date: Sun, 30 Aug 2015 01:00:51 +0200
Subject: [Simh] Latest Sources?
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A82379F90AEE@REDROOF2.alohasunset.com>
References: <55E0D44B.2040709@gmail.com>
 <03006E3FC39B5A48AB9DBCCC101090A82379F90AEE@REDROOF2.alohasunset.com>
Message-ID: <8ad5bbb3e974c9cd9b96b2f4a60a6097@xs4all.nl>

On 2015-08-28 23:41, Mark Pizzolato - Info Comm wrote:
> A zip file of the latest code is at:
> https://github.com/simh/simh/archive/master.zip

https://github.com/simh/simh/archive/master.tar.gz
works as well for the .ZIP impaired.



From Mark at infocomm.com  Sat Aug 29 19:22:30 2015
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Sat, 29 Aug 2015 16:22:30 -0700
Subject: [Simh] Latest Sources?
Message-ID: <7e688b40-464d-4811-a10f-160b27a1f8fb@email.android.com>


On Aug 29, 2015 4:01 PM, Jacob Goense <dugo at xs4all.nl> wrote:
>
> On 2015-08-28 23:41, Mark Pizzolato - Info Comm wrote:
> > A zip file of the latest code is at:
> > https://github.com/simh/simh/archive/master.zip
>
> https://github.com/simh/simh/archive/master.tar.gz
> works as well for the .ZIP impaired.

True, but given:

1) the simh source has always been distributed in a zip file, and any existing instructions refer to the zip format

AND

2) on some platforms the zip instructions must be followed to get a successful build.

This is why I only mention the zip download.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150829/dd78b16f/attachment.html>