[Simh] Way out idea for simh

[Johnny Billquist]

On 2016-04-20 18:02, Paul Koning wrote:
>
>> On Apr 20, 2016, at 11:43 AM, Ken Cornetet <Ken.Cornetet at kimballelectronics.com> 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