subject:"\[Simh\] Way out idea for simh"

> On 21 Apr 2016, at 01:26, Johnny Billquist  wrote:
>> 
>> Yes, exactly - the guest OS tools do this. The SIMH file server just writes 
>> the stuff to disk.
> 
> Well, the goal was to transfers files into and out of the guest system. If 
> you want to transfer files into the guest system, you cannot really expect 
> the guest system to create the information...

Again a valid point, you’d need host OS tools to create the metadata files + 
the actual data.

I assumed this was for some weird systems/OSes that simply could not run Kermit 
for some reason - but Bob is right: If you want to get stuff into your guest OS 
and Kermit isn’t an option, use whatever weird mechanism your exotic system 
used (punched cards, magnetic tape, etc).

The built-in guest-to-host-and-back file server is probably not realistic but 
it was an interesting intellectual exercise.

Sampsa

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh


On 2016-04-21 00:18, Sampsa Laine wrote:



On 21 Apr 2016, at 01:12, Johnny Billquist  wrote:


Where would you get the metadata from? And you have a lots of different types 
of binary files, multiplied with a lot of different systems. You want to try 
and figure out some system to handle all the variants?



The guest OS tool creates and interprets the metadata. The only thing that is 
consistent across all of the guest OSes is that it tells the SIMH file server 
how many octets are going to be written to disk (the guest OS tool has to 
convert the actual word size into octets so that the data file is just a stream 
of bytes)


The structure of the metadata file would depend on the host OS but SIMH doesn’t 
have to care - it just sticks the stuff in the file and it’s up to the guest 
OSes transfer tool to create/interpret it.


It's up to whoever puts the file into that container/raw device/whatever to 
make sure that the bytes also match up with the metadata, and the tool used to 
extract the file, so that the final binary output becomes what was expected.



Yes, exactly - the guest OS tools do this. The SIMH file server just writes the 
stuff to disk.


Well, the goal was to transfers files into and out of the guest system. 
If you want to transfer files into the guest system, you cannot really 
expect the guest system to create the information...


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh


On 2016-04-21 00:11, Sampsa Laine wrote:



On 21 Apr 2016, at 01:05, Johnny Billquist  wrote:

On 2016-04-20 22:35, Sampsa Laine wrote:



On 20 Apr 2016, at 23:25, Phil Budne  wrote:

Ken.Cornetet wrote:

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


Why not?


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


Again, why not?

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



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


Actually, we should not assume the connection is lossless, so I would stick 
with Kermit.

(There are examples of overflowing the serial port, resulting in lost 
characters by simple buffer overruns.)

Add checksums to the packets, and this is pretty much what Kermit is.


Agreed, add a checksum and the built-in SIMH file server sends a NAK if it 
didn’t like a packet. Each packet is let’s say X bytes + checksum.

I think the generic simple file server should be fairly simple to write and the 
guest OS tools relatively portable, you just have to change the writing/reading 
of the metadata for each guest OS.

Of course you only implement this for simulations where Kermit is not an 
option..


Well, you have pretty much described exactly how Kermit works. Why not 
use that then? You do not actually have to implement the more advanced 
stuff. Kermits can talk to each other, even ones with limited 
functionality. Also, another thing Kermit can do is escape all 
characters with the high bit set, and almost all control characters, 
which can be useful as not all OSes are that transparent on non-printing 
characters.


Kermit exists for lots of systems, but if it don't, then writing a 
simple Kermit is no worse that writing something similar with your own 
invented protocol. But using Kermit you also only have to implement one 
side. The other side already exists.


And despite other peoples comments to the contrary: Kermit is simple to 
implement. I've done it on a PDP-8.
I can't remember, but I might have been using 8K for it. Doubt I used 
more. And that had some fancy stuff that you don't really need, so a 
slimmed version could fit in less.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh


> On 21 Apr 2016, at 01:14, Mark Pizzolato  wrote:
> 
> On Wednesday, April 20, 2016 at 10:07 AM, Ken Cornetet wrote:
>> Kermit cannot be made to work reliably on RTE-6/VM under simh. At least I
>> was never able to make it work.
>> 
>> Not to mention that trying to use an
>> emulator other than QCTerm (which doesn't do Kermit) with RTE is a major
>> PITA.
>> 
>> I used Kermit extensively on real RTE systems to transfer files to a variety 
>> of
>> systems.
> 
> If you have a version of Kermit that actually worked on real hardware and
> doesn't work on the simulator, then as others have said this is a 
> deficiency/bug
> in the simulator.  If you can come up with a repeatable configuration I'll be 
> glad
> help get this fixed.
> 
> If you or someone else wants to implement the other ideas being discussed in
> this thread, you can pursue that as well, but I'm real sure that fixing the 
> existing
> Kermit issue is a much simpler problem.
> 

The problem I have with say CP/M Kermit is that it wants to write to the AUX 
device which I never bothered to figure out how to do since there’s a way to 
read/write files to/from the host OS built into the Altair emulator.

sampsa





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

> On 21 Apr 2016, at 01:12, Johnny Billquist  wrote:
> 
> 
> Where would you get the metadata from? And you have a lots of different types 
> of binary files, multiplied with a lot of different systems. You want to try 
> and figure out some system to handle all the variants?
> 

The guest OS tool creates and interprets the metadata. The only thing that is 
consistent across all of the guest OSes is that it tells the SIMH file server 
how many octets are going to be written to disk (the guest OS tool has to 
convert the actual word size into octets so that the data file is just a stream 
of bytes)

>> The structure of the metadata file would depend on the host OS but SIMH 
>> doesn’t have to care - it just sticks the stuff in the file and it’s up to 
>> the guest OSes transfer tool to create/interpret it.
> 
> It's up to whoever puts the file into that container/raw device/whatever to 
> make sure that the bytes also match up with the metadata, and the tool used 
> to extract the file, so that the final binary output becomes what was 
> expected.
> 

Yes, exactly - the guest OS tools do this. The SIMH file server just writes the 
stuff to disk.

Then if you really want to go all out, you can write some tools for the host OS 
to view the metadata in conjunction with the actual data.

>> You could also write tools for the host OS to create/view these metadata 
>> files..
>> 
>> But it’s non-trivial and probably not worth the effort.
> 
> Everything is always doable. The amount of work required, to just do 
> something that there already are tools for, seems excessive. Or if there 
> aren't any tools today, it's most likely because people did not find it worth 
> the effort. Meaning it probably still isn't worth the effort.

I’m not saying it’s trivial or even worth doing, but it’s a fun intellectual 
exercise.

Sampsa

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

2016-04-20 Thread Mark Pizzolato

On Wednesday, April 20, 2016 at 10:07 AM, Ken Cornetet wrote:
> Kermit cannot be made to work reliably on RTE-6/VM under simh. At least I
> was never able to make it work. 
>
> Not to mention that trying to use an
> emulator other than QCTerm (which doesn't do Kermit) with RTE is a major
> PITA.
> 
> I used Kermit extensively on real RTE systems to transfer files to a variety 
> of
> systems.

If you have a version of Kermit that actually worked on real hardware and 
doesn't work on the simulator, then as others have said this is a 
deficiency/bug 
in the simulator.  If you can come up with a repeatable configuration I'll be 
glad 
help get this fixed.  

If you or someone else wants to implement the other ideas being discussed in 
this thread, you can pursue that as well, but I'm real sure that fixing the 
existing
Kermit issue is a much simpler problem.

- Mark

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

Re: [Simh] Way out idea for simh


On 2016-04-21 00:00, Sampsa Laine wrote:



On 21 Apr 2016, at 00:56, Johnny Billquist  wrote:



This is not a "small" thing. This would be a huge effort if really wanted this 
to become ubiquitous. And I still fail to see the point. We've basically established that 
binary files will still not work, so we're down to text files. Why all these extra steps 
for something that can be done with already existing tools?



Binary files COULD work if we store the file metadata in another file..


Where would you get the metadata from? And you have a lots of different 
types of binary files, multiplied with a lot of different systems. You 
want to try and figure out some system to handle all the variants?



The structure of the metadata file would depend on the host OS but SIMH doesn’t 
have to care - it just sticks the stuff in the file and it’s up to the guest 
OSes transfer tool to create/interpret it.


It's up to whoever puts the file into that container/raw device/whatever 
to make sure that the bytes also match up with the metadata, and the 
tool used to extract the file, so that the final binary output becomes 
what was expected.



You could also write tools for the host OS to create/view these metadata files..

But it’s non-trivial and probably not worth the effort.


Everything is always doable. The amount of work required, to just do 
something that there already are tools for, seems excessive. Or if there 
aren't any tools today, it's most likely because people did not find it 
worth the effort. Meaning it probably still isn't worth the effort.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh


> On 21 Apr 2016, at 01:05, Johnny Billquist  wrote:
> 
> On 2016-04-20 22:35, Sampsa Laine wrote:
>> 
>>> On 20 Apr 2016, at 23:25, Phil Budne  wrote:
>>> 
>>> Ken.Cornetet wrote:
 I guess I need to shout this:
 *** KERMIT DOES NOT WORK ON SIMH EMULATED RTE-6/VM 
>>> 
>>> Why not?
>>> 
 Kermit does not exist (and probably couldn't feasibly exist) on any 
 earlier versions of RTE.
>>> 
>>> Again, why not?
>>> 
>>> Having just written a new shell for PDP-7 UNIX (because the original
>>> could not be found), I can't imagine much other than a lack of
>>> something resembling a serial console that would prevent _some_
>>> version/subset of KERMIT (or something similar like X or ZMODEM) from
>>> being cobbled together.
>>> 
>> 
>> And since the connection can be assumed to be lossless, the protocol could 
>> be really simple, e.g. something like this:
> 
> Actually, we should not assume the connection is lossless, so I would stick 
> with Kermit.
> 
> (There are examples of overflowing the serial port, resulting in lost 
> characters by simple buffer overruns.)
> 
> Add checksums to the packets, and this is pretty much what Kermit is.

Agreed, add a checksum and the built-in SIMH file server sends a NAK if it 
didn’t like a packet. Each packet is let’s say X bytes + checksum.

I think the generic simple file server should be fairly simple to write and the 
guest OS tools relatively portable, you just have to change the writing/reading 
of the metadata for each guest OS.

Of course you only implement this for simulations where Kermit is not an 
option..

Sampsa



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh


On 2016-04-20 22:35, Sampsa Laine wrote:



On 20 Apr 2016, at 23:25, Phil Budne  wrote:

Ken.Cornetet wrote:

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


Why not?


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


Again, why not?

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



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


Actually, we should not assume the connection is lossless, so I would 
stick with Kermit.


(There are examples of overflowing the serial port, resulting in lost 
characters by simple buffer overruns.)



G=Guest, H=Host

Example of a write operation..

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


Add checksums to the packets, and this is pretty much what Kermit is.

Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh


> On 21 Apr 2016, at 01:00, Sampsa Laine  wrote:
> 
> 
>> On 21 Apr 2016, at 00:56, Johnny Billquist  wrote:
> 
>> This is not a "small" thing. This would be a huge effort if really wanted 
>> this to become ubiquitous. And I still fail to see the point. We've 
>> basically established that binary files will still not work, so we're down 
>> to text files. Why all these extra steps for something that can be done with 
>> already existing tools?
>> 
> 
> Binary files COULD work if we store the file metadata in another file..
> 
> The structure of the metadata file would depend on the host OS but SIMH 
> doesn’t

I meant the guest OS determines the structure of the metadata. SIMH just knows 
that it goes into an associated file, just like the resource forks in 
“netatalk” - the UNIX box running the AFP server doesn’t give a crap, it just 
stores the extra Mac OS stuff in another file.

sampsa




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

2016-04-20 Thread Larry Stewart

You step away from the computer for a day and your inbox is full!

We want to transfer files back and forth between guest file systems and host 
file systems, preferably while the guest is running.

The mechanism should be as generic as possible, rather than be wildly different 
for each environment.  (It probably can’t be identical always, because some 
guest environments have unusual encodings, or unusual file semantics, and so 
forth.)

The mechanism should require minimum code for the guest environment, since each 
one is different, and most of us are not skilled at more than one or two 
environments.

I think unless you shutdown the guest, add files to its filesystem, and 
restart, it is going to be hard to avoid writing at least some guest code.  How 
minimal can it be?

Let’s try a thought experiment, of implementing the simh commands 

hosttoguest  
and 
guesttohost  

Taking hosttoguest first.

simh itself could obviously read from a host file, in a generic way.
Only a guest program can really deal with  and write to the 
guest file system while it is live, so I think there has to be a guest program, 
called, say
magictoguest  which reads from some magic data path and writes 
to the guest filesystem.

When you type “hosttoguest” at the simh prompt, simh opens the host file, and 
somehow (by stuffing a command into the console?) activates the magictoguest 
utility.

The magic datapath is up for discussion for the most generic possible solution, 
but it could be anything.  simh is a simulator and controls the horizontal and 
the vertical, so
the magic datapath could be previously illegal instructions that have new 
powers, or magic I/O addresses, or even just an attention grabbing  
of memory references.  For historical reasons, I would recommend Up, Up, Down, 
Down, Left, Right, Left, Right, B, A, Start.  simh would notice the sequence, 
and that would identify the memory location(s) in use for data transfer.

The magic datapath could be minimal and would be simulator specific, co-written 
with the magictoguest utility program.


guesttohost, similarly, is broken into a generic part in simh for writing host 
files, and a minimal utility on the guest for reading guest files, connected by 
pretty much any magic datapath.

This is a considerably more minimal idea than a filesystem, but when you want 
to transfer a bunch of files, you can write a script.

The SIMH and System Verilog simulators for the SiCortex ICE9 (sort of a MIPS) 
had some magic extra instructions to provide communications (putchar, getchar, 
test PASS and test FAIL) for programs running in simulation, and fancier 
functions (zeroing memory regions) intended to greatly speed up otherwise 
boring parts of simulations.

If you don’t want to initiate transfers from the simh side, then the guest 
utility can pass the host filespec up to simh with only slightly more 
complexity.


magictoguest.c
===

#include 
#include 

int mailbox;

#define EOFBIT 0x100
#define DATAAVAILABLE 0x400

int magiceof()
{
 return (mailbox & EOFBIT);
}

char magicgetchar()
{
 char c;
 while ((mailbox & DATAAVAILABLE) == 0);
 c = mailbox;
 mailbox &= ~DATAAVAILABLE;
 return(c);
}

int main(int argc, char *argv[])
{
 int fd;
 if (argc != 2) return(1);
 fd = creat(argv[1], 0666);

 mailbox = 'H';
 mailbox = 'e';
 mailbox = 'l';
 mailbox = 'l';
 mailbox = 'o';
 mailbox = ' ';
 mailbox = 'W';
 mailbox = 'o';
 mailbox = 'r';
 mailbox = 'l';
 mailbox = 'd';
 /* that sequence of writes to  wakes up simh and identifies the 
mailbox */

 while(!magiceof()) {
   char c;
   magicgetchar();
   write(fd, , 1);
 }

 close(fd);
 return(0);
}


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

Re: [Simh] Way out idea for simh

> On 21 Apr 2016, at 00:56, Johnny Billquist  wrote:

> This is not a "small" thing. This would be a huge effort if really wanted 
> this to become ubiquitous. And I still fail to see the point. We've basically 
> established that binary files will still not work, so we're down to text 
> files. Why all these extra steps for something that can be done with already 
> existing tools?
> 

Binary files COULD work if we store the file metadata in another file..

The structure of the metadata file would depend on the host OS but SIMH doesn’t 
have to care - it just sticks the stuff in the file and it’s up to the guest 
OSes transfer tool to create/interpret it.

You could also write tools for the host OS to create/view these metadata files..

But it’s non-trivial and probably not worth the effort.

Sampsa

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh


On 2016-04-20 20:48, Ken Cornetet wrote:

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


And what Rich said (again) is that you cannot mount a foreign file 
system in Tops-10. The concept don't exist.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh


> On 21 Apr 2016, at 00:28, Hittner, David T (IS)  wrote:
> 
> If Kermit does not work on SIMH emulated RTE-6/VM, but works on the real 
> hardware, then I’d say there’s a BUG in the emulator that needs fixing. Derp.
> Ø  Kermit cannot be made to work reliably on RTE-6/VM under simh.
> Ø  At least I was never able to make it work.
> Ø  Not to mention that trying to use an emulator other than QCTerm (which 
> doesn't do Kermit) with RTE is a major PITA.
> Ø  I used Kermit extensively on real RTE systems to transfer files to a 
> variety of systems.
> 
> Another option is to start a file creation in the emulation from the serial 
> port and use a terminal emulator to cut and paste (slowly) the ascii or 
> hexified file in for you (hopefully with a windows cut/paste), or type(cat) 
> the file to the terminal emulator and select/copy the text out to a host 
> file. Attachmate has worked well for me as a slow cut/paste terminal 
> emulator. Hexifying binaries is a tried-and-true serial copy method when flow 
> control is non-existent or suicidal, and there are quite a few tools to 
> hexify/unhexify data streams.
> 
> There’s also lot of tools available for file conversion (mangling), and 
> Kermit is supported on many platforms. Look at the older Kermit-16 and 
> Kermit-32 if you want a simpler Kermit.
> 
> If you want to write a universal file transfer tool for ALL of the hosts and 
> emulators SIMH supports, AND write in the OS support drivers for it on ALL of 
> the emulated OS’s, then go for it. But it’s a lot more work than you might 
> think, for very minimal gain.
> 
> If it was , and I was having problems with file transfers to a  
> emulator/OS combination, I’d look to find a solution for that specific 
> platform problem, and not try to solve all of the SIMH host file transfer 
> problems with a universal solution. You’re looking for a universal solution 
> to 50+ years of device and filesystem incompatibility. Most people agree that 
> Kermit is the most universal file transfer solution available.  :-S
> 

I still like the idea of a standardised protocol for moving files + metadata 
in/out using SOME mechanism (e.g. serial port) that is mapped to a directory on 
the host OS.

Whether people then want to actually implement the tools for the guest OS 
depends on the need for them.

But one standard, simple protocol would be nifty..

sampsa




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh


On 2016-04-20 20:47, Ken Cornetet wrote:

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


It is... Well, maybe not wild. Just way complicated and lots of work for 
something that can be done so much easier.



But on the other hand, I haven't heard any better suggestions. And the only 
problems are:


Better? I'd still say that Kermit is better in every way.


1. Not all OSes support raw disk access or seekable mag tape.


Why do you need seekable?


2. A small LIF transfer utility will have to be written for each OS.


This is not a "small" thing. This would be a huge effort if really 
wanted this to become ubiquitous. And I still fail to see the point. 
We've basically established that binary files will still not work, so 
we're down to text files. Why all these extra steps for something that 
can be done with already existing tools?



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


Kermit. The fact that you (or whoever it was) had problems does not 
invalidate the method. Maybe investigate why there was problems, and 
write up how to solve them, and then be done with it.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

2016-04-20 Thread Hittner, David T (IS)

If Kermit does not work on SIMH emulated RTE-6/VM, but works on the real 
hardware, then I’d say there’s a BUG in the emulator that needs fixing. Derp.

Ø  Kermit cannot be made to work reliably on RTE-6/VM under simh.

Ø  At least I was never able to make it work.

Ø  Not to mention that trying to use an emulator other than QCTerm (which 
doesn't do Kermit) with RTE is a major PITA.

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

Another option is to start a file creation in the emulation from the serial 
port and use a terminal emulator to cut and paste (slowly) the ascii or 
hexified file in for you (hopefully with a windows cut/paste), or type(cat) the 
file to the terminal emulator and select/copy the text out to a host file. 
Attachmate has worked well for me as a slow cut/paste terminal emulator. 
Hexifying binaries is a tried-and-true serial copy method when flow control is 
non-existent or suicidal, and there are quite a few tools to hexify/unhexify 
data streams.

There’s also lot of tools available for file conversion (mangling), and Kermit 
is supported on many platforms. Look at the older Kermit-16 and Kermit-32 if 
you want a simpler Kermit.

If you want to write a universal file transfer tool for ALL of the hosts and 
emulators SIMH supports, AND write in the OS support drivers for it on ALL of 
the emulated OS’s, then go for it. But it’s a lot more work than you might 
think, for very minimal gain.

If it was , and I was having problems with file transfers to a  
emulator/OS combination, I’d look to find a solution for that specific platform 
problem, and not try to solve all of the SIMH host file transfer problems with 
a universal solution. You’re looking for a universal solution to 50+ years of 
device and filesystem incompatibility. Most people agree that Kermit is the 
most universal file transfer solution available.  :-S

Dave

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

I guess I need to shout this:

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

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

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

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

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

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






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

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

Re: [Simh] Way out idea for simh

2016-04-20 Thread khandy21yo

The Kermit protocol isn't very comp,icated, is well documented, and has a lot 
of testing behind it.
What happens in your protocol with characters that devices between you and the 
simulator mangle. Modems were a major frustration, now you have all sorts of  
effort devices may do funny things with certain   haracters. Send the wrong 
characters and it could disconnect.
We've been through this before, why not make use of that experience.

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

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

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

G=Guest, H=Host

Example of a write operation..

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

Done.

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

Re: [Simh] Way out idea for simh

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

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

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

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

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

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

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

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

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

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

Why not?

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

Again, why not?

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

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

Re: [Simh] Way out idea for simh


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

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

G=Guest, H=Host

Example of a write operation..

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

Done.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

2016-04-20 Thread Phil Budne

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

Why not?

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

Again, why not?

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

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

Re: [Simh] Way out idea for simh

2016-04-20 Thread khandy21yo

Kermit has something ,Ike this built into it over the serial line. Look I to 
its remote commands. Doesn't need anything beyond the existing serial or 
console port.


Sent from my Galaxy Tab® A Original message From: Ken Cornetet 
<ken.corne...@kimballelectronics.com> Date: 04/20/2016  1:47 PM  (GMT-07:00) 
To: simh@trailing-edge.com Subject: [Simh] Way out idea for simh 


Actually, here’s an alternate way to allow easy file transfers. I’m starting to 
think this is a much better idea.
 
Create a new device for simh that is identical to a paper tape punch/reader 
except If the guest OS writes a magic string, the next character after the 
magic string is a command, and the following characters up to a newline are a 
file name.
 
From that point on, guest writes to the punch would write to the given file, 
and reads from the reader would read from the given file.
 
The command character would be “t” for open the file in text mode, “b” for open 
in binary mode, and “c” for close.
 
As an extension, if the file name contains shell wildcard characters, simh 
would return the matching file names when the guest reads the tape reader.
 
If the simh guest doesn’t support paper tape, then the device could be mapped 
to some other sort of simple IO device (like a serial port).
 
Again, perhaps not all simh machines could make use of this, but many could.


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

Re: [Simh] Way out idea for simh

> On Apr 20, 2016, at 3:58 PM, Kevin Handy  wrote:
> 
> I think you are trying to over-engineer this file transfer stuff.
> 
> Instead of creating new devices for the transfer to operate over, why not use 
> something that already exists on most of the simulators, like a serial port. 
>  Instead of building all this code into simh to convert from one disk file
>  format to another. inside the simulator, use a progrm attached to the serial 
> port which handles the hosts file access. You will still need a program on 
> the simulated system to handle it's side of the transfers. W can give the 
> whole setup a common name, like "kermit".
> 
> Most of this stream just seems to me to re-inenting Kermit in one way or 
> another. It might be fun/interesting but doesn't seem to gain anything beyond 
> what Kermit already does.

Sort of.  But Kermit does a whole lot more, things that are not needed here.  
Kermit assumes a lossy interconnect with errors, while here that assumption is 
not needed.  And even E-kermit is fairly large -- 1600 lines of C code.  Simply 
to say "send me file "foo" now, with the reply being simply a stream of bytes 
would be at least an order of magnitude simpler.  The obvious data format would 
be the SimH tape record format -- a block of bytes preceded by a byte count.

Attaching all this machinery to serial ports makes a lot of sense, assuming you 
have them.  Most machines do, though some (again, the IBM 1620 is a good 
example) all you have is a console, and paper tapes).  Some (like the EL-X1) 
don't even have a bidirectional console port.

paul

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

Re: [Simh] Way out idea for simh

I guess I need to shout this:

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

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

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

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

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

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

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

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

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

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

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

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

paul

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

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

Re: [Simh] Way out idea for simh

2016-04-20 Thread Kevin Handy

I think you are trying to over-engineer this file transfer stuff.

Instead of creating new devices for the transfer to operate over, why not
use something that already exists on most of the simulators, like a serial
port.
 Instead of building all this code into simh to convert from one disk file
 format to another. inside the simulator, use a progrm attached to the
serial port which handles the hosts file access. You will still need a
program on the simulated system to handle it's side of the transfers. W can
give the whole setup a common name, like "kermit".

Most of this stream just seems to me to re-inenting Kermit in one way or
another. It might be fun/interesting but doesn't seem to gain anything
beyond what Kermit already does.

All this stuff has been hashed over many times when the hardware was
actually in use, and solutions were devised then to handle the
numerous problems. Creating new interfaces, new instructions, etc. and
modifying OS's just to re-implement kermit in another way seems to be a lot
of overkill to me., but most of these messages seem to have no advantages
to just using existing kermit capabilities.

If you want shares access the host filesystem, look to 'nfs'. If the
emulated system doesn't already have shared filesystem already, you are
probably going to be fighting such things as the disk caching code. File
system corruption is very likely to occur.

A lot of the simulated OS's have more basic problems that just making the
raw data available to the host OS. VMS doesn't store anything, including
text files, in a "stream of byte" form. Others have 6 or 9-bit bytes. Then
there is ASCII (multiple variants) EBCDIC (multiple variants), BAUDOUT, etc.

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

On Wed, Apr 20, 2016 at 1:14 PM, Paul Koning  wrote:

>
> > On Apr 20, 2016, at 3:08 PM, sky...@sky-visions.com wrote:
> >
> > OS's don't support foreign file systems. What they do is provide the
> ability to access a drive that does not have what they believe to be a
> valid file system.
>
> Not necessarily.  RSTS does in the latest versions, but not in early
> versions.  For example, RSTS V4A has no raw disk API, and gives you no
> access to any disk except via the RSTS file system.  The same goes for some
> other operating systems; I don't know of raw disk access on CDC NOS either,
> for example.  (Well, not unless you write a PPU program; if you don't mind
> doing that, the job is easy.)
>
> paul
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] Way out idea for simh

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

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

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

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

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

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

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

Re: [Simh] Way out idea for simh


> On 20 Apr 2016, at 22:24, Ken Cornetet  
> wrote:
> 
> Sigh…
> 
> No, no file system emulators needed.
> 
> The block device would be in HP LIF format. SImh would understand LIF on the 
> host side, and a LIF transfer utility would handle LIF on the guest side.
> 

OK, go for it - I just personally prefer the Altair mechanism but I guess it’s 
a question of taste..

Sampsa




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

2016-04-20 Thread skyvis

That is what I meant by support. However not all OS's allow you to have a drive that is not part of the file system. Some OS's allow you to gain access to a drive, many don't. Some like IBSYS don't even have the concept of a file system. For CDC COS and Scope the disk basically was a tape image. The OS kept the directory in core. At boot in case of Scope it determined the available tracks by scanning the disk. COS did not have the concept of a disk boot. Every boot reloaded the system. B5500 MCP also operated similar to Scope.--- Original Message ---On 4/20/2016  3:14 PM Paul Koning wrote:> On Apr 20, 2016, at 3:08 PM, sky...@sky-visions.com wrote:> > OS's don't support foreign file systems. What they do is provide the ability to access a drive that does not have what they believe to be a valid file system. Not necessarily.  RSTS does in the lates
t versions, but not in early versions.  For example, RSTS V4A has no raw disk API, and gives you no access to any disk except via the RSTS file system.  The same goes for some other operating systems; I don't know of raw disk access on CDC NOS either, for example.  (Well, not unless you write a PPU program; if you don't mind doing that, the job is easy.)	paul==Richard Cornwellsky...@sky-visions.comhttp://sky-visions.com==
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

Sigh…

No, no file system emulators needed.

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

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

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

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

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

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

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

Sampsa

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

Re: [Simh] Way out idea for simh

> On 20 Apr 2016, at 22:03, Ken Cornetet  
> wrote:
> 
> That is a great mechanism. But it has the HUGE disadvantage that it is very 
> specific to the Altair emulator. It can’t be generalized to that it can be 
> easily applied to all simh machines. And it requires (probably) guest OS 
> modifications. And it still requires a user-land utility.
> 

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

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

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

Sampsa

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

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

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

paul

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

Re: [Simh] Way out idea for simh


> On 20 Apr 2016, at 21:54, Paul Koning  wrote:
> 
> Let me flesh this out a bit, I think I understand your idea and it's a pretty 
> straightforward one.  It vaguely looks like a pseudo device implementation of 
> the GDB remote stub file access setup.  Or, I suppose, vaguely like FTP 
> requests; they two are the same thing at a sufficiently superficial level.  
> :-)
> 
> Consider a new type of device exposed to the guest software.  You can send it 
> commands: read a file, write a file.  After that command, you read from the 
> device to get the file data, or write to it to send file data.  End of file 
> is an I/O status code (for read) or some special device operation (for write).
> 
> From the application point of view this isn't all that different from guest 
> OS file read/write calls, except that (a) it's sequential only I assume, (b) 
> the operations are represented as device operations rather than being handled 
> as OS calls.
> 
> What you need for this to work is a way to talk to a raw device.  That means 
> directly, if the OS allows it, or if you don't have one.  Or via a very 
> simple device driver if one is required.  For example, on RT11, or an IBM 
> 1620, you could do the I/O directly. On RSTS you'd either need a driver 
> (which is a pain) or do it through a sequence of "peek" and "poke" operations 
> (not too bad).
> 
> Yes, that seems like a notion that could be interesting.  It would be good to 
> do an existence proof, on some not too difficult machine.  Perhaps a PDP11 or 
> PDP8, with the "direct to the device" approach.

This is already implemented in the SIMH Altair emulator actually…




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

> On Apr 20, 2016, at 2:01 PM, Sampsa Laine  wrote:
> 
> 
>> On 20 Apr 2016, at 20:45, Ken Cornetet  
>> wrote:
>> 
>> Other than the OS on the old Atari 800 family of computers, I don’t know of 
>> any OS that supports a device to which you can supply a file name and then 
>> read or write data.
>>  
>> Most OSes view disk devices as a collection of blocks.
> 
> You’re missing my point - the guest OS would not be mounting this as a block 
> device, but would have some kind of file transfer utility to talk to the host 
> OS’s file system.

Let me flesh this out a bit, I think I understand your idea and it's a pretty 
straightforward one.  It vaguely looks like a pseudo device implementation of 
the GDB remote stub file access setup.  Or, I suppose, vaguely like FTP 
requests; they two are the same thing at a sufficiently superficial level.  :-)

Consider a new type of device exposed to the guest software.  You can send it 
commands: read a file, write a file.  After that command, you read from the 
device to get the file data, or write to it to send file data.  End of file is 
an I/O status code (for read) or some special device operation (for write).

From the application point of view this isn't all that different from guest OS 
file read/write calls, except that (a) it's sequential only I assume, (b) the 
operations are represented as device operations rather than being handled as OS 
calls.

What you need for this to work is a way to talk to a raw device.  That means 
directly, if the OS allows it, or if you don't have one.  Or via a very simple 
device driver if one is required.  For example, on RT11, or an IBM 1620, you 
could do the I/O directly.  On RSTS you'd either need a driver (which is a 
pain) or do it through a sequence of "peek" and "poke" operations (not too bad).

Yes, that seems like a notion that could be interesting.  It would be good to 
do an existence proof, on some not too difficult machine.  Perhaps a PDP11 or 
PDP8, with the "direct to the device" approach.

paul

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

Re: [Simh] Way out idea for simh

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

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

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

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

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

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

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

Re: [Simh] Way out idea for simh


> On 20 Apr 2016, at 21:44, Ken Cornetet  
> wrote:
> 
> That “some kind of transfer utility” is exactly what I’m trying to implement.
> 
> In order to transfer files between a guest and host you need some sort of 
> shared medium.
> 
> In the realm of simh hosted OSes, there are basically 3 forms of 
> bidirectional io devices: paper tape, mag tape, and disk. Paper tape isn’t 
> seekable, so it isn’t really suitable.
> 
> That leaves mag tape and disk as the only shared medium that is supported by 
> the guest OS.
> 
> So the next question is, how do you implement a file transfer utility using 
> shared tape or disk, and that’s exactly what I’ve proposed.
> 
> There is another option which can be used: modify the guest machine virtual 
> architecture to implement a new data mechanism, and to the modify guest OS to 
> support it. This has the advantage that it is more flexible and more 
> powerful, but has the disadvantage of requiring not so trivial modifications 
> of the guest emulation and modification to the guest OS. Additionally, since 
> emulated machines have vastly different architectures, this would be 
> difficult to generalize and integrate into simh as a whole.
> 
> I eventually plan to do exactly this on the hp2100 emulator by writing custom 
> microcode (creating new instructions essentially) and writing an RTE driver 
> so that userland applications can access it . However, the mods I make for 
> the 2100 emulator will not be anywhere close to being usable on other 
> architectures.
> 
> That’s the beauty of using the disk file as the shared medium – you modify 
> simh once, and you get the ability to use that mechanism on every simh OS 
> that knows how to handle raw disks or seekable tapes. You do have to write a 
> small LIF interchange utility, but that shouldn’t be too bad.

Fair enough - I’m just saying that maybe an FTP server isn’t the ideal 
mechanism for accessing the LIF device on the host OS side..

Sampsa





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

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

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

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

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

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

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

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

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





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


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

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

Most OSes view disk devices as a collection of blocks.


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

Sampsa



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

Re: [Simh] Way out idea for simh

2016-04-20 Thread Rich Alderson

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

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

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

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

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

Re: [Simh] Way out idea for simh


> On 20 Apr 2016, at 20:45, Ken Cornetet  
> wrote:
> 
> Other than the OS on the old Atari 800 family of computers, I don’t know of 
> any OS that supports a device to which you can supply a file name and then 
> read or write data.
> 
> Most OSes view disk devices as a collection of blocks.
> 

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

Sampsa





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh


On 2016-04-20 19:51, Armistead, Jason  . wrote:

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


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


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



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


Right.

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


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

Re: [Simh] Way out idea for simh

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

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

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

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

 Rich

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

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

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

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

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

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

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

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

Rich

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

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

>

>

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

>>

>>>

>>

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

>>

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

>>

>

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

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

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

> ...

>>

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

>

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

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

paul

___

Re: [Simh] Way out idea for simh

2016-04-20 Thread Armistead, Jason .

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

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

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

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

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

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

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

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

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

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

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

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

Re: [Simh] Way out idea for simh

2016-04-20 Thread skyvis

I think you are missing something. For the B5500 the drives are all one file system. If you add a drive, it becomes part of the file system. Also there is no way to access the drives in a raw way. For the I7000 series there is no concept of a file system to speak of. Similar for CDC 6600 for anything prior to Scope 3.4, the drives are all one big file system. Rich--- Original Message --- On 4/20/2016 1:20 PM Ken Cornetet wrote:You don’t need the notion of mountable disk. The disk would appear attached to the guest OS 100% of the time. The guest doesn’t need to be able to mount foreign file systems. The guest OS only considers that block device as a seekable collection of blocks. All file movement between the LIF block device and the OS’s native file system would be by a userland utility. True, this utility would have to be developed for every guest OS running under simh, but if the file system was simple enough, the code would be trivial. From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of sky...@sky-visions.com Sent: Wednesday, April 20, 2016 1:04 PM To: paulkon...@comcast.net; sam...@mac.com Cc: simh@trailing-edge.com Subject: Re: [Simh] Way out idea for simh Just to add some info to the discussion. This sounds like a nice idea, however it will be very difficult to implement on some of the older machines that SimH supports. For example the B5500 does not have the concept of a mountable pack. Drives could be attached, but they were a permanent attachment. For the Ibm 7000 line, most did not suppo
rt disk. The disk drive that was supported by many of the machines was a large box that you could not put drives into (IBM 1301/2301). Also these machines all worked in BCD (6 bit), not Ascii. I am also not sure when TOPS10 got support for mounting foreign file systems. I don't believe that 6.03 or 5.03 support this idea.Tapes, paper tapes, and punch cards are probably the most universal format. Also a Paper tape reader is pretty easy to implement, it might be possible to put some kind of header onto the tape to indicate the name of the file. But take a look at how much trouble Kermit does to handle all the various systems. Rich --- Original Message --- On 4/20/2016 12:14 PM Paul Koning wrote: > On Apr 20, 2016, at 12:06 PM, Sampsa Laine wrote: > > >> On 20 Apr 2016, at 19:02, Paul Koning
wrote: >> >>> >> >> I don't know LIF, but the RT-11 file system is certainly simple. >> >> There are a couple of complications. First, you'd have to write a file access utility for each guest OS. Given a simple enough file system that isn't necessarily a huge burden. Then again, what might be simple, requiringly only modest code, on one machine might be a major burden on another simply because it has much less memory. >> > > For DEC stuff, Files-11 (level 2?) would probably work across most of the OSes.No, it would work for VMS, and level 1 at least would work for RSX, but neither RSTS nor RT11 understand it. And it's a complex file system, more so than the RSTS one and vastly more than RT11. It does more, of course, but if you're looking for something that can
easily be ported to another system, this won't do.I took the proposal to mean: find a simple OS for which you can easily implement an application to handle it on most operating systems. So think something handled by an application like PDP-10 FLX (or RT-11 FLX), not a file system with native support.> ... >> >> Paper tape is yet a third option, which is presumably unlabeled but often transparent. (Not always, the 1620 comes to mind as a notorious example of a machine that could read only coded tape with punches conforming to the code it expects.) > > That’s a good point but doesn’t make organising files trivial.One key question is how important it is to transfer a bunch of files all at once. Is it sufficient to send one file at a time? With scripting, that may not be all that problematic.paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh == Richard Cornwell sky...@sky-visions.com http://sky-visions.com == == Richard Cornwell sky...@sky-visions.com http://sky-visions.com ==
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh




On 2016-04-20 19:19, Jonathan Willams wrote:

On Apr 20, 2016, at 1:04 PM, Johnny Billquist  wrote:

On 2016-04-20 18:58, Jonathan Willams wrote:

I think a more useful solution would be to engineer FUSE filesystems for
various file system formats. It removes the necessity to modify simh or
the guest OS.


Except you need to modify every host OS to add a userland bridge from the 
kernel to userspace in the file subsystem, in order to then implement the file 
system in userland.
Not to mention that not all systems easily even allows such a construct.


Yeah, I’m not suggesting that we port FUSE to RT-11 or VMS :)


Ok. So FUSE on the host side then, and implementing every file system 
you might see on the emulated side, which might have very different 
properties to what the host is able to understand.
Things like file attribute metadata in Files-11, or bytes that can be 
between 1 and 36 bits in TOPS-20...



Or are you suggesting that you would implement (in Linux or whatever) a 
userland implementation for each file system you might have on every simulated 
system? That can also become very interesting, as some file systems have 
properties that Unix do not have, so exposing this in Unix would be rather 
magic. Not to mention complex.


The original post was about "how to get files copied between the host and the 
emulated machines”. The notion of multiple records/streams/forks in guest OSes 
having not equivalent representation isn’t fixed by FTP either. Is the expected use 
case to transfer archive files the guest and host? I’m guessing most archive formats 
have a linear representation like tar?


Right. When it comes to binary data, you are mostly screwed, unless you 
know very well what you are doing, and how.
So we're down to text files. But text files are also dealt with very 
differently on different systems. However, FTP as well as Kermit, do 
provide a universal format for text, and each side then transforms it to 
the correct local storage as a part of the transfer, so you can actually 
expect this to work right.


As far as archive formats go, it very much differs from system to system 
if you have something like that, and with a linear format even close to 
what tar looks like.

So don't expect too much...

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

Re: [Simh] Way out idea for simh

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

Most OSes view disk devices as a collection of blocks.

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

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

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

Fair enough.

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

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

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

attach HOST0: /home/foobar/simhdir

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

Re: [Simh] Way out idea for simh

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

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

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

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

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

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

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

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

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

Re: [Simh] Way out idea for simh

2016-04-20 Thread Jonathan Willams

For comparison, this sort of sounds like plan9 folder sharing in qemu 

http://wiki.qemu.org/Documentation/9psetup 
<http://wiki.qemu.org/Documentation/9psetup>
> On Apr 20, 2016, at 1:36 PM, Ken Cornetet 
> <ken.corne...@kimballelectronics.com> wrote:
> 
> This is a great mechanism, but it requires that the guest OS have some native 
> support (or be modified to support) some sort of device where you can pass a 
> file name and then read and write data.
> 
> I actually plan to implement just such a beast on the hp2100. The plan is to 
> create a  custom microcode instruction that will take operands describing the 
> desired host operation perform the appropriate action. Operations would 
> include file operations (wild card globbing, reads, writes) and possibly even 
> socket operations. 
> 
> It would be lovely if this sort of mechanism could be worked into simh in 
> general, but given the wildly different ways this would have to grafted into 
> each emulated machine's archetechture, I can't really see it happening.
> 
> -Original Message-
> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Sampsa Laine
> Sent: Wednesday, April 20, 2016 12:52 PM
> To: simh@trailing-edge.com
> Subject: Re: [Simh] Way out idea for simh
> 
> I say forget the FTP server, create a device which can access a directory on 
> the host OS via a special device and then code file transfer utilities for 
> each OS that needs it, like the SIMH Altair + CP/M thing..
> 
> Sampsa
> 
> 
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

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

Re: [Simh] Way out idea for simh

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

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

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

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

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

Sampsa


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

Re: [Simh] Way out idea for simh

> On 20 Apr 2016, at 20:26, Ken Cornetet  
> wrote:
> 
> Kermit is  not available/usable for every guest OS under simh.
> 

Fair enough.

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

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

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

attach HOST0: /home/foobar/simhdir

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

2016-04-20 Thread Armistead, Jason .

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

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

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

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

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

Re: [Simh] Way out idea for simh

> On Apr 20, 2016, at 12:58 PM, Jonathan Willams  
> wrote:
> 
> I think a more useful solution would be to engineer FUSE filesystems for 
> various file system formats. It removes the necessity to modify simh or the 
> guest OS.

FUSE is doing it the hard way.  It makes an elegant user interface but it's 
harder than necessary.  A host application that can process the guest OS layout 
is sufficient.  (I've done both; for example I wrote a RSTS file system 
processor which is pretty straightforward.  I started converting it to a FUSE 
module but got somewhat discouraged when I was having trouble finding a working 
FUSE for current Mac OS.  Or a working PyFuse, I don't remember which.  (I like 
to do these jobs in Python if possible, rather than C.)

paul

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

Re: [Simh] Way out idea for simh


> On 20 Apr 2016, at 20:20, Ken Cornetet  
> wrote:
> 
> You don’t need the notion of mountable disk. The disk would appear attached 
> to the guest OS 100% of the time.
> 
> The guest doesn’t need to be able to mount foreign file systems. The guest OS 
> only considers that block device as a seekable collection of blocks.  All 
> file movement between the LIF block device and the OS’s native file system 
> would be by a userland  utility.
> 
> True, this utility would have to be developed for every guest OS running 
> under simh, but if the file system was simple enough, the code would be 
> trivial.
> 

Why an FTP server though, why not just a block device that points at a 
directory on the host OS?

Also, Kermit.

Sampsa





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

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

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

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

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

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

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

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

Rich

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

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

>

>

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

>>

>>>

>>

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

>>

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

>>

>

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

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

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

> ...

>>

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

>

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

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

paul

___

Simh mailing list

Simh@trailing-edge.com<mailto:Simh@trailing-edge.com>

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

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

Re: [Simh] Way out idea for simh

2016-04-20 Thread Jonathan Willams

> On Apr 20, 2016, at 1:04 PM, Johnny Billquist  wrote:
> 
> On 2016-04-20 18:58, Jonathan Willams wrote:
>> I think a more useful solution would be to engineer FUSE filesystems for
>> various file system formats. It removes the necessity to modify simh or
>> the guest OS.
> 
> Except you need to modify every host OS to add a userland bridge from the 
> kernel to userspace in the file subsystem, in order to then implement the 
> file system in userland.
> Not to mention that not all systems easily even allows such a construct.

Yeah, I’m not suggesting that we port FUSE to RT-11 or VMS :)

> Or are you suggesting that you would implement (in Linux or whatever) a 
> userland implementation for each file system you might have on every 
> simulated system? That can also become very interesting, as some file systems 
> have properties that Unix do not have, so exposing this in Unix would be 
> rather magic. Not to mention complex.

The original post was about "how to get files copied between the host and the 
emulated machines”. The notion of multiple records/streams/forks in guest OSes 
having not equivalent representation isn’t fixed by FTP either. Is the expected 
use case to transfer archive files the guest and host? I’m guessing most 
archive formats have a linear representation like tar?
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

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

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

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

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

Kermit really does rock.

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

Sampsa

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

Re: [Simh] Way out idea for simh


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

Kermit really does rock.

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

Sampsa



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

2016-04-20 Thread Jonathan Willams

I think a more useful solution would be to engineer FUSE filesystems for 
various file system formats. It removes the necessity to modify simh or the 
guest OS.

> On Apr 20, 2016, at 12:42 PM, Ken Cornetet 
> <ken.corne...@kimballelectronics.com> wrote:
> 
> I think I wasn’t clear on what I meant.
>  
> Simh would have an FTP server built in. In your simh control file, you’d 
> attach a disk (or tape, or drum) and add an option that would make that block 
> device available to the FTP server as a certain virtual directory name. A 
> user id and password would also be specified.
>  
> An FTP client would connect to simh using the specified user/password and do 
> a “cd” to the virtual directory name as specified in the attach options. The 
> FTP client could then read, write, and erase files in the filesystem on that 
> block device file.
>  
> Obviously, simh can’t know how to read/write/erase files for every file 
> system out there, so we’d need a very simple file system that would be simple 
> to code for both simh and guest os applications. I like LIF because it is 
> designed for pretty much exactly this. HP designed it as a way to transfer 
> files across their various operating systems (and even  calculators).
>  
> It wouldn’t have to be LIF – we could design our own from scratch if desired. 
> But LIF is super simple and a user level utility could be coded up on pretty 
> much any guest OS (well, any guest OS that allows block level access to 
> devices).
>  
>  
>  
> From: Ken Cornetet 
> Sent: Wednesday, April 20, 2016 11:43 AM
> To: simh@trailing-edge.com <mailto:simh@trailing-edge.com>
> Subject: Way out idea for simh
>  
> A common theme on this list is how to get files copied between the host and 
> the emulated machines. I have a crazy idea for a simh feature to help in that 
> regard: Add an FTP server to simh that would write to a “universal” file 
> system on a simh block device file (disk, tape, drum)  that the guest OS 
> would have attached. You could fire up your favorite ftp client and copy 
> files into and out of this file system.
>  
> Obviously, the guest OS would need to have tools written to read/write this 
> universal file system, but with a simple enough file system, that wouldn’t be 
> a huge hurdle. I have to admit, outside of unix and RTE, I have no notion of 
> how many operating systems that run on simh emulated machines allow direct 
> disk access. I am assuming there is a way to do it on most all of them. If 
> not, tape or drum could be an option.
>  
> For this “universal” file system, I nominate Hewlett-Packard’s LIF. It is 
> simple and well documented. A fixed flat directory at the beginning of the 
> image, fixed size directory entries, and linear space allocation (no 
> allocation tables).
>  
> I don’t expect it would be trivial to add an FTP server to simh, but it could 
> be handy. Just food for thought.
>  
> ___
> Simh mailing list
> Simh@trailing-edge.com <mailto:Simh@trailing-edge.com>
> http://mailman.trailing-edge.com/mailman/listinfo/simh 
> <http://mailman.trailing-edge.com/mailman/listinfo/simh>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh


On 2016-04-20 18:52, Sampsa Laine wrote:

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


Slightly simpler, and there is previous art for it (the DOS device in 
E11, which have been mentioned here before).
However, we still face the same issue that for anything except text 
files, the copying is most likely not going to work that well, and it 
requires writing either a program that reaches down to the hardware, or 
a device driver for the OS, which in many cases will not be easy to do.

So I'm not sure it's really such a useful idea.
I still find Kermit the most obvious, straight forward solution. Kermit 
already exists for almost any platform we might talk about. It requires 
minimal hardware. Runs in userland. And manages the translation of text 
files based on the host system on each platform.


Why do people want to make life more complicated?

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

Re: [Simh] Way out idea for simh

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

Sampsa




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh


On 2016-04-20 18:02, Paul Koning wrote:



On Apr 20, 2016, at 11:43 AM, Ken Cornetet 
 wrote:

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

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

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


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


True.


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


It still means writing code for a lot of OSes, just to be able to 
transport files. This seems like an overengineered solution to a 
different problem.



Another problem is that there isn't any universal disk format, so you're 
missing the foundation for a universal file format.  Consider the IBM 1620, 
with disks that have 200 digit sectors.  Or (not that SimH supports it, but 
another simulator does) CDC 6000 machines, where the sector size is 322 12-bit 
words.


Right.


Chances are that magnetic tape is more general; there aren't as many encodings 
there.  Basically it's 6 bits vs. 8 bits per frame.  Everyone understands 
variable length data, and unlabeled tapes are fairly widely supported.  Even if 
not, writing a labeled tape with a single file on it isn't too hard.  You're 
still stuck with machines that have no magnetic tape support, there aren't all 
that many but certainly some.


Agreed. Tapes would make more sense, but that still don't give a 
universal solution, as we still have different file formats and 
attributes, and god knows what else.



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


That is just a stream of bytes.
Not enough for some situations, and it also depends on the OS for how it 
actually interacts with everything else.


To summarize I think that a file system is just not a good solution, 
while being a lot of work.

Some other fake device will also have issues.
If we're talking about transferring simple text files, then Kermit is a 
good solution, as it exists for *lots* of platforms, and only requires a 
serial line, which is something more simulators do have. And if they 
don't, then you are probably will have to solve multiple issues no 
matter what solution you pick.
The next step up is if the machine have TCP/IP, or some other networking 
suite, at which point network file transfers will be possible. But these 
machines are probably a subset of the ones that also can do Kermit.


So, why not just accept and use Kermit for transfers? Text files should 
always work. Binary files will only work under some circumstances no 
matter which way you transport the files.


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

Re: [Simh] Way out idea for simh

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

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

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

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

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



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

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

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

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

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

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

Re: [Simh] Way out idea for simh

> On Apr 20, 2016, at 12:06 PM, Sampsa Laine  wrote:
> 
> 
>> On 20 Apr 2016, at 19:02, Paul Koning  wrote:
>> 
>>> 
>> 
>> I don't know LIF, but the RT-11 file system is certainly simple.
>> 
>> There are a couple of complications.  First, you'd have to write a file 
>> access utility for each guest OS.  Given a simple enough file system that 
>> isn't necessarily a huge burden.  Then again, what might be simple, 
>> requiringly only modest code, on one machine might be a major burden on 
>> another simply because it has much less memory.
>> 
> 
> For DEC stuff, Files-11 (level 2?) would probably work across most of the 
> OSes.

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

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

> ...
>> 
>> Paper tape is yet a third option, which is presumably unlabeled but often 
>> transparent. (Not always, the 1620 comes to mind as a notorious example of a 
>> machine that could read only coded tape with punches conforming to the code 
>> it expects.)
> 
> That’s a good point but doesn’t make organising files trivial.

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

paul

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

Re: [Simh] Way out idea for simh

Actually, why not just create simple file system for the FTP server, and then 
export an interface  and create a read/write tool for each OS.

That way you only need to implement one FTP server and a tool to access files 
on it.

This sort of exists for the Z80 emulation - there are read / write utilities 
for CP/M that access the host file system via some special device, no sure how 
they work exactly though.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Way out idea for simh

> On Apr 20, 2016, at 11:43 AM, Ken Cornetet 
>  wrote:
> 
> A common theme on this list is how to get files copied between the host and 
> the emulated machines. I have a crazy idea for a simh feature to help in that 
> regard: Add an FTP server to simh that would write to a “universal” file 
> system on a simh block device file (disk, tape, drum)  that the guest OS 
> would have attached. You could fire up your favorite ftp client and copy 
> files into and out of this file system.
>  
> Obviously, the guest OS would need to have tools written to read/write this 
> universal file system, but with a simple enough file system, that wouldn’t be 
> a huge hurdle. I have to admit, outside of unix and RTE, I have no notion of 
> how many operating systems that run on simh emulated machines allow direct 
> disk access. I am assuming there is a way to do it on most all of them. If 
> not, tape or drum could be an option.
>  
> For this “universal” file system, I nominate Hewlett-Packard’s LIF. It is 
> simple and well documented. A fixed flat directory at the beginning of the 
> image, fixed size directory entries, and linear space allocation (no 
> allocation tables).

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

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

Another problem is that there isn't any universal disk format, so you're 
missing the foundation for a universal file format.  Consider the IBM 1620, 
with disks that have 200 digit sectors.  Or (not that SimH supports it, but 
another simulator does) CDC 6000 machines, where the sector size is 322 12-bit 
words.

Chances are that magnetic tape is more general; there aren't as many encodings 
there.  Basically it's 6 bits vs. 8 bits per frame.  Everyone understands 
variable length data, and unlabeled tapes are fairly widely supported.  Even if 
not, writing a labeled tape with a single file on it isn't too hard.  You're 
still stuck with machines that have no magnetic tape support, there aren't all 
that many but certainly some.  

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

paul

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

Re: [Simh] Way out idea for simh


> On 20 Apr 2016, at 19:02, Paul Koning  wrote:
> 
>> 
> 
> I don't know LIF, but the RT-11 file system is certainly simple.
> 
> There are a couple of complications.  First, you'd have to write a file 
> access utility for each guest OS.  Given a simple enough file system that 
> isn't necessarily a huge burden.  Then again, what might be simple, 
> requiringly only modest code, on one machine might be a major burden on 
> another simply because it has much less memory.
> 

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

> Another problem is that there isn't any universal disk format, so you're 
> missing the foundation for a universal file format.  Consider the IBM 1620, 
> with disks that have 200 digit sectors.  Or (not that SimH supports it, but 
> another simulator does) CDC 6000 machines, where the sector size is 322 
> 12-bit words.
> 

Yup this would have to be machine (or even OS) specific.

> Chances are that magnetic tape is more general; there aren't as many 
> encodings there. Basically it's 6 bits vs. 8 bits per frame.  Everyone 
> understands variable length data, and unlabeled tapes are fairly widely 
> supported.  Even if not, writing a labeled tape with a single file on it 
> isn't too hard.  You're still stuck with machines that have no magnetic tape 
> support, there aren't all that many but certainly some.
> 
> Paper tape is yet a third option, which is presumably unlabeled but often 
> transparent. (Not always, the 1620 comes to mind as a notorious example of a 
> machine that could read only coded tape with punches conforming to the code 
> it expects.)

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

Sampsa




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] Way out idea for simh