On 2016-04-20 18:02, Paul Koning wrote:
On Apr 20, 2016, at 11:43 AM, Ken Cornetet
<ken.corne...@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
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
