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 <hostfilespec> <guestfilespec>
and
guesttohost <guestfilespec> <hostfilespec>
Taking hosttoguest first.
simh itself could obviously read from a host file, in a generic way.
Only a guest program can really deal with <guestfilespec> and write to the
guest file system while it is live, so I think there has to be a guest program,
called, say
magictoguest <guestfilespec> 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 <sequence>
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 <fcntl.h>
#include <unistd.h>
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 <anywhere> wakes up simh and identifies the
mailbox */
while(!magiceof()) {
char c;
magicgetchar();
write(fd, &c, 1);
}
close(fd);
return(0);
}
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
