Precompiled Windows versions of SIMH
Bob Supnik
SIMH are available on http://simh.trailing-edge.com. The VAX and
PDP11 are compiled without Ethernet support.
/.Bob Supnik
Giorgio Ungarelli
support?
I'd love to test my RSX-11M-PLUS V4.6 RD54 disk image which has DECnet
installed and operational.
I'm asking as I don't have a C compiler, or I would do it myself...
"Bob Supnik" <bsu...@nauticusnet.NOSPAM.com> wrote in message
news:ah1h3vcorbvljsktt...@4ax.com...
Magnus Olsson
Giorgio Ungarelli <giorgio@*no_spam*ungarelli.net> wrote:
>Any way to get the precompiled Windows executable of the PDP11 with Ethernet
>support?
>I'd love to test my RSX-11M-PLUS V4.6 RD54 disk image which has DECnet
>installed and operational.
Speaking about Ethernet support: on what level does simulation end and
the host machine take over? I mean, theoretically you could imagine
the simulated CPU communicating with simulated hardware which forwards
data directly to the host machine's hardware, but is it really done
that way?
--
Magnus Olsson (m...@df.lth.se)
PGP Public Key available at http://www.df.lth.se/~mol
Sergio Pedraja
some petitions of the binaries, but I think I can serve it now.
Of course, I should agree to have one "test copy" of your RSX RD54 virtual
hard disk :-)
Greetings
Sergio
"Giorgio Ungarelli" <giorgio@*no_spam*ungarelli.net> wrote in message news:<3e390370$1...@news.bluewin.ch>...
Johnny Eriksson
> Speaking about Ethernet support: on what level does simulation end and
> the host machine take over? I mean, theoretically you could imagine
> the simulated CPU communicating with simulated hardware which forwards
> data directly to the host machine's hardware, but is it really done
> that way?
How else could the simulated machine talk to the real network?
At least in my code it is done that way.
> Magnus Olsson (m...@df.lth.se)
--Johnny
John Welch
What about tapes and floppies?
Inquiring minds want to know.
>?<
Zane H. Healy
> How does one get what is on an rl02 off over onto the peecee to use in the simh?
> What about tapes and floppies?
> Inquiring minds want to know.
The easiest way is with a MicroVAX II or III. Have the appropriate
controllers and drives for said system, have an ethernet controller, and
hopefully a SCSI controller or a KDA50 as you really don't want to mess with
old MFM disks if you can help it. The system should be running OpenVMS, and
have a TCP/IP stack installed. Then you simply mount the disks as foreign,
copy them to an image file and FTP them to the PC. It's a piece of cake, IF
you have the right hardware. Oh, it also helps to have room to setup the
hardware (unfortunatly I don't so it's buried in storage).
I think RX50's can be done on some PC's if you've got the right software and
a 1.2MB floppy drive (I'm sure if you can use newer PC's for this though).
For tapes, there is software that will run on UNIX or VMS.
Zane
Giorgio Ungarelli
news:13efcc39.03013...@posting.google.com...
> >
> > "Bob Supnik" <bsu...@nauticusnet.NOSPAM.com> wrote in message
> > news:ah1h3vcorbvljsktt...@4ax.com...
> > > In response to numerous requests, precompiled Windows executables of
> > > SIMH are available on http://simh.trailing-edge.com. The VAX and
> > > PDP11 are compiled without Ethernet support.
> > >
> > > /.Bob Supnik
> How does one get what is on an rl02 off over onto the peecee to use in the
simh?
> What about tapes and floppies?
> Inquiring minds want to know.
> >?<
I used VTServer (http://users.safeaccess.com/engdahl/vtserver.htm) and help
from Fred van Kempen for the task.
It took about 24 hours to copy the RD54 over to a virtual disk file on the
PC.
Magnus Olsson
Johnny Eriksson <by...@stacken.kth.se> wrote:
>m...@df.lth.se (Magnus Olsson) writes:
>
>> Speaking about Ethernet support: on what level does simulation end and
>> the host machine take over? I mean, theoretically you could imagine
>> the simulated CPU communicating with simulated hardware which forwards
>> data directly to the host machine's hardware, but is it really done
>> that way?
>
>How else could the simulated machine talk to the real network?
SOrry if I expressed myself a bit vaguely. What I'm after is this:
Suppose we're simulating OS W running on machine Y with Ethernet
controller Z. On the real hardware, OS W presumably talks to a device
driver which controls Z. On our simulated Y hardware, we could
simulate the exact operation of Z, so that when W calls the device
driver, the original device driver code runs, never knowing that it's
not talking to a real Z but just to a simulation.
We could also trap calls to the device driver, so that when OS W calls
the device driver, the original device driver code doesn't get called,
but instead some simulator code. Or we could conceivably trap calls at
an even higher level. I don't think this would be desirable in a
simulator like the SIMH machines, but it's conceivable, isn't it?
Supposing that the simulator simulates everything down to Z's
hardware, we then have the question how the Z simulation gets out onto
the real network. When the device driver sets a value in one of Z's
registers, does the simulator set the corresponding register in the
host machine's network card? Does the simulator take complete control
over the host machine's network hardware? I assume this is not the
case, but how does it work in that case?
Holger Veit
> In article <m3ylm12...@hector-lector.stacken.kth.se>,
> Johnny Eriksson <by...@stacken.kth.se> wrote:
>>m...@df.lth.se (Magnus Olsson) writes:
>>
>>> Speaking about Ethernet support: on what level does simulation end and
>>> the host machine take over? I mean, theoretically you could imagine
>>> the simulated CPU communicating with simulated hardware which forwards
>>> data directly to the host machine's hardware, but is it really done
>>> that way?
>>
>>How else could the simulated machine talk to the real network?
>
> SOrry if I expressed myself a bit vaguely. What I'm after is this:
>
> Suppose we're simulating OS W running on machine Y with Ethernet
> controller Z. On the real hardware, OS W presumably talks to a device
> driver which controls Z. On our simulated Y hardware, we could
> simulate the exact operation of Z, so that when W calls the device
> driver, the original device driver code runs, never knowing that it's
> not talking to a real Z but just to a simulation.
What I understand is that this is exactly the case with SIMH. Some
PDP OS like RT-11 wants to talk to a RL01 device, for instance, and
calls its native driver to issue I/O commands and wait for interrupts
from the device. The simulator listens to certain I/O commands and
fakes responses like the real RL01 device, but actually the data is
read from or written to some disk file of the host OS. Same holds for
serial TTYs and DEQNA/DEUNA ethernet adapters.
> We could also trap calls to the device driver, so that when OS W calls
> the device driver, the original device driver code doesn't get called,
> but instead some simulator code. Or we could conceivably trap calls at
> an even higher level. I don't think this would be desirable in a
> simulator like the SIMH machines, but it's conceivable, isn't it?
In theory, you could do this, but this requires you have initimate
knowledge how the simulated OS W talks to the hardware or to its
device driver that controls the simulated device Z. This also
means that you cannot take an OS W out of the box, or off the tape,
but have to replace some code of OS W or to intercept some code (which
might be OS version specific in the simulator). You won't want to do this.
If OSs were well written you could rely on this path that everything
goes through the appropriate device driver. But there is also another
thread here asking how to map the I/O page into user process space.
Obviously, the original poster wants, for some reason fiddle with the
I/O registers directly. Do you want him to let his code run on the
simulator, or not? Not simulating the registers but intercept at
a high level will result in too severe constraints.
> Supposing that the simulator simulates everything down to Z's
> hardware, we then have the question how the Z simulation gets out onto
> the real network. When the device driver sets a value in one of Z's
> registers, does the simulator set the corresponding register in the
> host machine's network card? Does the simulator take complete control
It is the simulator's responsibility how it translates W commands for
a device into real hardware commands. There is unlikely to be a 1-to-1
mapping between the simulated I/O registers and the real ones. All that
is known, again for instance with disk I/O, that OS W expects to
read the content of sector XYZ exactly as it had written it before.
Whether the simulator then choose a native file for storage, or directly
writes disk sectors or even uses a tape as storage, is its own job.
For ethernet, this means that there are basically only two operations:
OS W wants the simulator to get a certain data packet sent to the
ethernet cable, and wishes to get all packets that others want to
send to this (simulated) machine.
> over the host machine's network hardware? I assume this is not the
> case, but how does it work in that case?
You need certain ethernet APIs in the host OS to perform the two
operations. This is actually the tricky part for porting a
simulator then to a new host OS platform, because they are by
no means available in the same way on each platform.
Holger
--
Please update your tables to my new e-mail address:
holger.veit$ais.fhg.de (replace the '$' with '@' -- spam-protection)
Stan Barr
>
>I think RX50's can be done on some PC's if you've got the right software and
>a 1.2MB floppy drive (I'm sure if you can use newer PC's for this though).
PUTR - http://www.dbit.com
--
Cheers,
Stan Barr sta...@dial.pipex.com
**Remove the digits from email address**
The future was never like this!
Gian Luca Sole
Magnus Olsson wrote:
> Supposing that the simulator simulates everything down to Z's
> hardware, we then have the question how the Z simulation gets out onto
> the real network. When the device driver sets a value in one of Z's
> registers, does the simulator set the corresponding register in the
> host machine's network card? Does the simulator take complete control
> over the host machine's network hardware? I assume this is not the
> case, but how does it work in that case?
No need to access directly the hardware...
I suppose that pcap library (or winpcap in the win32 environment), used by
simh to simulate network operations on a real network, allow you to do
certain low level operations on the ethernet device of the host operating
system/machine (it's however required to have administrative privileges, e.g.
process root setuid un *nix). With this libraries, setting the selected
network interface to promiscous mode, you can intercept all the frames on the
ethernet segment without filters, and not only the frames directed and
accepted to the mac address of the board (warning: switches can make it
impraticable...). And, you can send frames with arbitrary source and
destination mac address. These particular operations done by simulator
doesn't affect all the others normal network operation done by the host
system on the ethernet device (even if is better to use a dedicated nic for
the emulator).
As result, your emulated system is seen on the network as another
network-connected computer... :-)
bye G.L.
--
La logica non attiene alla verosimiglianza delle ipotesi,
ma alla coerenza delle tesi con le ipotesi.
Peter da Silva
>Supposing that the simulator simulates everything down to Z's
>hardware, we then have the question how the Z simulation gets out onto
>the real network.
Networks are actually one of the easier things to handle on the
real-world side of the simulation, because they're already built
around the idea of having multiple network devices sharing access
to the same network.
Once the simulator has created an ethernet packet, that packet can
be fed into the host's network stack. What happens then depends on
where you feed it in and how the stack is configured.
You can have the host act as a router. You can have the host act as a
bridge. You can have the host do no routing at all and mediate access
via proxies. You can do NATting and have the host proxy-arp...
Lotsa possibilities...
--
Rev. Peter da Silva, ULC. 29.6852N 95.5770W WWFD?
"Be conservative in what you generate, and liberal in what you accept"
-- Matthew 10:16 (l.trans)
Peter da Silva
Holger Veit <holge...@ais.fhg.de> wrote:
>In theory, you could do this, but this requires you have initimate
>knowledge how the simulated OS W talks to the hardware or to its
>device driver that controls the simulated device Z.
You'd probably want to do this by writing a new driver for the simulated OS
that talks to your high-level virtual device. If you're using it in production,
this would be a really good way to improve I/O performance... you only use the
hardware simulation for bootstrapping.
>You need certain ethernet APIs in the host OS to perform the two
>operations. This is actually the tricky part for porting a
>simulator then to a new host OS platform, because they are by
>no means available in the same way on each platform.
In other words, you may not be able to do bridging. You can almost always
do routing, and you can always proxy.
Holger Veit
> In article <slrnb3kjd...@borneo.gmd.de>,
> Holger Veit <holge...@ais.fhg.de> wrote:
>>In theory, you could do this, but this requires you have initimate
>>knowledge how the simulated OS W talks to the hardware or to its
>>device driver that controls the simulated device Z.
>
> You'd probably want to do this by writing a new driver for the simulated OS
> that talks to your high-level virtual device. If you're using it in production,
> this would be a really good way to improve I/O performance... you only use the
> hardware simulation for bootstrapping.
The question is whether you'd really want to use a simulated PDP or VAX in
production at all. I do accept such simulators for hobby or museum purposes;
it's really a fun to do some time-travel when running RSX or VMS again on
some modern PC. I do not doubt the simulator works stable enough - it
is maybe a lot more stable than the original hardware (unless it runs
in Windows ;-)), but in production, especially in process control, the
PC usually does not have the appropriate I/O devices besides simulated
disks, terminals or tapes. People asked me whether they could replace their
old VAX controlling some gadget with a cheap PC running the simulator, so
they wouldn't have to rewrite the tons of old FORTRAN code. Special process
I/O devices are the problem that prevents this.
>>You need certain ethernet APIs in the host OS to perform the two
>>operations. This is actually the tricky part for porting a
>>simulator then to a new host OS platform, because they are by
>>no means available in the same way on each platform.
>
> In other words, you may not be able to do bridging. You can almost always
> do routing, and you can always proxy.
You might not even be able to do routing, if the API doesn't allow to send
and receive arbitrary packets with non-standard packet headers. DECNET raw
packets with special MAC address conventions might not be generatable through
a stock TCP/IP-only socket interface.
Paul Rubin
> People asked me whether they could replace their
> old VAX controlling some gadget with a cheap PC running the simulator, so
> they wouldn't have to rewrite the tons of old FORTRAN code. Special process
> I/O devices are the problem that prevents this.
I'd think the way to deal with that is just write a new gadget
interface for the PC and replace the gadget's VMS device driver with
one that traps to the PC interface. You can then still run the rest
of the Fortran code under simulation.
Mark Zellers
"Magnus Olsson" <m...@df.lth.se> wrote in message
news:b1c4qh$112kq6$1...@ID-178465.news.dfncis.de...
> Speaking about Ethernet support: on what level does simulation end and
> the host machine take over? I mean, theoretically you could imagine
> the simulated CPU communicating with simulated hardware which forwards
> data directly to the host machine's hardware, but is it really done
> that way?
>
from inside the simulation.
For example, suppose you were to add an instruction that would take an ASCIZ
string containing simulator
commands, run them and then return to the emulator.
Then one could add a UUO to the monitor that would let a user mode program
connect host files to simuated devices
without stopping the simulation. So when some luser asks you to mount a
tape, you don't need to ^E (and stop any other
users). Just run the magic program and you are in business.
Probably far more work than I'll ever have time to hack my way through, but
it is nice to dream.
Mark Z.
Paul Rubin
> I was thinking it might be a neat hack to be able to talk to the simulator
> from inside the simulation.
>
> For example, suppose you were to add an instruction that would take
> an ASCIZ string containing simulator commands, run them and then
> return to the emulator.
>
> Then one could add a UUO to the monitor that would let a user mode
> program connect host files to simuated devices without stopping the
> simulation. So when some luser asks you to mount a tape, you don't
> need to ^E (and stop any other users). Just run the magic program
> and you are in business.
You don't need a special instruction or new UUO for that. Just have a
host program listening to the simulated console TTY that the operator
would normally get those requests on.
Mark Zellers
"Paul Rubin" <phr-n...@NOSPAMnightsong.com> wrote in message
news:7xlm115...@ruckus.brouhaha.com...
TOPS-10 monitor hacking, but never had the opportunity (until now).
:-)
Mark Z.
jmfb...@aol.com
"Mark Zellers" <mzel...@pacbell.net> wrote:
>
>"Paul Rubin" <phr-n...@NOSPAMnightsong.com> wrote in message
>news:7xlm115...@ruckus.brouhaha.com...
>> You don't need a special instruction or new UUO for that. Just have a
>> host program listening to the simulated console TTY that the operator
>> would normally get those requests on.
>>
>Ah, but where would be the fun in that...I've always wanted to do some
>TOPS-10 monitor hacking, but never had the opportunity (until now).
>
>:-)
<GRIN>
/BAH
Subtract a hundred and four for e-mail.
Baby Peanut
SIMH/VAX 2.10-2 Win32 binaries *with* Ethernet:
http://www.tubas.net/~kstailey/simh/
Requires winpcap.
http://winpcap.polito.it/install/bin/WinPcap_3_0_a4.exe
from
http://winpcap.polito.it/install/default.htm
since the packet capture drives are not bundled.
For network documentation get the SIMH source code from
http://simh.trailing-edge.com/
and look through it for readme's and *.txt.
To test if winpcap is running OK get WinDump from
and run "WinDump -D". It should print the name of any network cards
you have similar to this:
1.\Device\NPF_El90x1 (3Com 3C90x Ethernet Adapter)
If you don't see that you might need to replace the Packet.dll that is
in my ZIP file. Look for replacements at the bottom of this page:
http://winpcap.polito.it/contact.htm
Once you have that working you should use name from "WinDump -D" in a
SIMH "attach" command to tell SIMH to map your network card to the
virtual DELQA. Given the name from the previous example the attach
command would be:
ATTACH XQ \Device\NPF_El90x1
It is not well documented but the author of SIMH gave up trying to
shove a VT-100 emulator in the Windows binary and put a command to use
telnet to gain control of the console. Use
set telnet <port>
After that command, telnet into the emulator console and then type
"boot cpu" from the non-telnet session and the system will boot with
console output going to the telnet one.