[Simh] Simh Digest, Vol 159, Issue 26

Jordi Guillaumes i Pons jg at jordi.guillaumes.name
Thu Dec 14 02:59:18 EST 2017


Hello,

Please excuse my top-posting. I’m writing this on a phone :)

If what you want to achieve is to login into your VAX from the host system, you don’t need to fiddle with a real terminal (although that can be fun in itself ;)). You should check the alternative network attachments that SIMH provides:

- tun/tap: you’d get a private, virtual interface dedicated to your VAX, which you should have to bridge to the physical Ethernet in your host

- vde: you’d get a complete virtual Ethernet switch for your VAX to attach to; that virtual switch can be ‘plugged’ into your real network in several ways

- SLiRP/NAT: you’d get a dedicated subnet to which attach your VAX, with SIMH providing a virtual router and address/port translation.

The easiest to setup is SLiRP/NAT, but that restricts your network to TCP/IP, so you could not play with DECNET.

I recommend using VDE, which provides other interesting functionality. I blogged about it some time ago, but the information is mostly valid:

http://ancientbits.blogspot.com.es/2012/06/simh-39-using-vde-for-fun-and.html?m=1

Jordi Guillaumes Pons


El 12 des 2017, a les 14:52, Kurt Hamm <kurt at hamm.me> va escriure:

> I am having a devil of a time hooking a physical VT220 into my Raspberry PI Simh VAX.  Everything is setup and working beautifully.  I can telnet from another computer with no trouble and get a vax login.  
> 
> I have a ttyusb0 connection.  I can echo text to the terminal with no problem.
> 
> I can configure Raspian to divert the console to the terminal with no problem.  But, I can't telnet to the vax from the Raspberry PI operating system.  I can telnet from another PC, but not from within the Raspberry Pi.  So, that doesn't give me the Vax login on the terminal.
> 
> So, I tried to create a serial connection to the ttyUSB0 using various means.
> Method 1) attach ttix line=0,connect=/dev/ttyUSB0;1200-7n1 - This results in an error that says non-existent device.
> Method 2) attach dz line=0,connect=/dev/ttyUSB0;9600-8n1 - This seemed to run successfully, but showed nothing on the terminal after a reboot.
> 
> Is there a way to connect a physical serial terminal via /dev/ttyUSB0 using SIMh Microvax 3900 simulator?
> 
> Thanks for any advice.
> 
> Kurt
> 
>> On Wed, Apr 19, 2017 at 3:05 AM, <simh-request at trailing-edge.com> wrote:
>> Send Simh mailing list submissions to
>>         simh at trailing-edge.com
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         http://mailman.trailing-edge.com/mailman/listinfo/simh
>> or, via email, send a message with subject or body 'help' to
>>         simh-request at trailing-edge.com
>> 
>> You can reach the person managing the list at
>>         simh-owner at trailing-edge.com
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Simh digest..."
>> 
>> 
>> Today's Topics:
>> 
>>    1. Re:  NetBSD 5.1 on MicoVAX 3900 boot error (Bob Supnik)
>>    2. Re:  DEC VT emulators on MAME (Johnny Billquist)
>>    3. Re:  NetBSD 5.1 on MicoVAX 3900 boot error (Mark Abene)
>>    4. Re:  NetBSD 5.1 on MicoVAX 3900 boot error (Mark Pizzolato)
>>    5. Re:  DEC VT emulators on MAME (Kevin Handy)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Tue, 18 Apr 2017 16:08:34 -0400
>> From: Bob Supnik <bob at supnik.org>
>> To: simh at trailing-edge.com
>> Subject: Re: [Simh] NetBSD 5.1 on MicoVAX 3900 boot error
>> Message-ID: <4ee0f9dc-071c-9ea9-fe74-48134c5e979b at supnik.org>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>> 
>> You can get a pre-built Windows 32b 3.9 executable without Ethernet (and
>> therefore, without needing WinPCap) here:
>> http://simh.trailing-edge.com/sources/simhv39-0-exe.zip. It should run
>> fine under W10. See if it will boot NetBSD 5.1.
>> 
>> /Bob Supnik
>> 
>> On 4/18/2017 3:53 PM, simh-request at trailing-edge.com wrote:
>> > You shouldn't need WinPCAP merely to test if the CD image is bootable.
>> > The point of the boot test exercise is to help determine if the problem is
>> > in NetBSD or due to recent changes to simh.  If changes to simh are at
>> > fault, I'll track it down and fix the problem.
>> >
>> >> I specifically want to run a 5.x version of NetBSD. I'm pretty sure it did
>> >> run on SIMH 3.8-1 on Windows 7 before the upgrade. I need to downgrade a
>> >> laptop I have to Win7 in the future and may try that. Until then I'll play
>> >> with OpenBSD which doesn't seem to have any problems with SIMH 4.0 beta.
>> > The boot test I'm suggesting will be far less work than setting up another
>> > system.
>> >
>> > Let me know.
>> >
>> > - Mark
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 2
>> Date: Tue, 18 Apr 2017 22:39:08 +0200
>> From: Johnny Billquist <bqt at softjar.se>
>> To: simh at trailing-edge.com
>> Subject: Re: [Simh] DEC VT emulators on MAME
>> Message-ID: <2e3a017d-0166-df35-3b92-11ab3a6912f4 at softjar.se>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>> 
>> Ok, looked at the schematics now.
>> 
>> On 2017-04-18 21:53, Timothe Litt wrote:
>> >
>> >
>> >> Since they're windowless, they are not EPROM (remember what the E
>> >> stands for), but plain ROMs.
>> > Nope.  I meant exactly what I wrote.
>> 
>> [...]
>> 
>> Good point about it being the same chip. I hadn't considered that
>> possibility. I know that for some 27-series proms, there were certainly
>> both mask programmable as well as EPROM versions, where the mask
>> programmable was more persistent safe. EPROMs have a risk of loosing
>> their content eventually, even if not exposed to UV light.
>> 
>> > As for which signal you use for what - it doesn't matter.  OE puts the
>> > chip into a low power state just as effectively as CS - assuming that
>> > the part isn't in programming or ID mode.  Since the part is never
>> > written (in the terminal), this effectively gives you 2 CS pins
>> > (effectively ANDed), and thus decoding requires at most an inverter.
>> 
>> Not entirely true.
>> OE should timing wise be done after CS and addresses have been stable
>> for a certain time. And power consumption of the chip is related to the
>> control of CS, and is not related to OE.
>> 
>> While power consumption might not be a problem, and the timing can be
>> solve, it does mean that driving CS and OE cannot be done identically.
>> If you use OE as a CS, you should make make sure the address is stable
>> some time before you activate OE, and if you use CS, you need to still
>> drive OE at a point later in time, and not just tie them together or
>> something.
>> 
>> > The 27C256 is a 32K x 8 part; it has no A15 (but the cartridge socket does.)
>> 
>> Yes, that was obvious.
>> 
>> > Keven pointed out that the odd chip is probably the character generator
>> > ROM - thus the separate address and data bus - and it doesn't need a CS
>> > or OE.  It's always reading something.
>> >
>> > As I've written before, rather than guessing, a few minutes with an
>> > ohmmeter can sort all this out.
>> >
>> > I'm leaving that - and further exploration - as an exercise to the reader.
>> 
>> I seriously doubt it's a character generator ROM in the normal sense of
>> the word. The VT340 do not generate character output in hardware.
>> It's a graphic terminal, which stores the text in the the bitmap, as far
>> as I remember (I seem to remember being able to go into graphics mode
>> and affect text already written). Also, you have soft definable
>> characters, so the CPU need to have access to the same memory the
>> character generator would use anyway, and it has to contain some RAM,
>> minimum. So it needs to be in the normal memory space of the CPU.
>> 
>> But there is indeed two address and databuses, so I think it's fair to
>> say the two select lines are only used for a subset of the PROMs.
>> 
>> There might be data in one ROM that is copied into RAM at startup.
>> Character definition tables, for example, I could imagine.
>> 
>> Anyway, most things can be worked out my doing the measurements you
>> suggest, yes.
>> 
>>         Johnny
>> 
>> --
>> Johnny Billquist                  || "I'm on a bus
>>                                    ||  on a psychedelic trip
>> email: bqt at softjar.se             ||  Reading murder books
>> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>> 
>> 
>> ------------------------------
>> 
>> Message: 3
>> Date: Tue, 18 Apr 2017 15:07:06 -0700
>> From: Mark Abene <phiber at phiber.com>
>> To: Bob Supnik <bob at supnik.org>
>> Cc: simh at trailing-edge.com
>> Subject: Re: [Simh] NetBSD 5.1 on MicoVAX 3900 boot error
>> Message-ID:
>>         <CAPCE1iYZrkE19nrcTB-K-ZArhYi0USyAZY0FRFBvCsQwMRw30g at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> Should one want winpcap in Windows 10, all one needs is:
>> http://www.win10pcap.org/
>> 
>> -Mark
>> 
>> 
>> On Tue, Apr 18, 2017 at 1:08 PM, Bob Supnik <bob at supnik.org> wrote:
>> 
>> > You can get a pre-built Windows 32b 3.9 executable without Ethernet (and
>> > therefore, without needing WinPCap) here: http://simh.trailing-edge.com/
>> > sources/simhv39-0-exe.zip. It should run fine under W10. See if it will
>> > boot NetBSD 5.1.
>> >
>> > /Bob Supnik
>> >
>> >
>> > On 4/18/2017 3:53 PM, simh-request at trailing-edge.com wrote:
>> >
>> >> You shouldn't need WinPCAP merely to test if the CD image is bootable.
>> >> The point of the boot test exercise is to help determine if the problem is
>> >> in NetBSD or due to recent changes to simh.  If changes to simh are at
>> >> fault, I'll track it down and fix the problem.
>> >>
>> >> I specifically want to run a 5.x version of NetBSD. I'm pretty sure it did
>> >>> run on SIMH 3.8-1 on Windows 7 before the upgrade. I need to downgrade a
>> >>> laptop I have to Win7 in the future and may try that. Until then I'll
>> >>> play
>> >>> with OpenBSD which doesn't seem to have any problems with SIMH 4.0 beta.
>> >>>
>> >> The boot test I'm suggesting will be far less work than setting up another
>> >> system.
>> >>
>> >> Let me know.
>> >>
>> >> - Mark
>> >>
>> >
>> > _______________________________________________
>> > Simh mailing list
>> > Simh at trailing-edge.com
>> > http://mailman.trailing-edge.com/mailman/listinfo/simh
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20170418/7481cbde/attachment-0001.html>
>> 
>> ------------------------------
>> 
>> Message: 4
>> Date: Tue, 18 Apr 2017 22:39:48 -0700
>> From: Mark Pizzolato <Mark at infocomm.com>
>> To: Mark Abene <phiber at phiber.com>, Bob Supnik <bob at supnik.org>
>> Cc: "simh at trailing-edge.com" <simh at trailing-edge.com>
>> Subject: Re: [Simh] NetBSD 5.1 on MicoVAX 3900 boot error
>> Message-ID:
>>         <03006E3FC39B5A48AB9DBCCC101090A82E8242E585 at REDROOF2.alohasunset.com>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> Actually, the latest simh ‘supported’ WinPcap is npcap.
>> 
>> Npcap is part of the nmap project and directly shares the latest libpcap code.
>> 
>> Npcap has a BSD license like the original WinPcap did.  Win10pcap is a GPL package and is untested and unsupported for use with simh Ethernet devices.
>> 
>> Npcap is available from: https://github.com/nmap/npcap/releases
>> 
>> From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of Mark Abene
>> Sent: Tuesday, April 18, 2017 3:07 PM
>> To: Bob Supnik <bob at supnik.org>
>> Cc: simh at trailing-edge.com
>> Subject: Re: [Simh] NetBSD 5.1 on MicoVAX 3900 boot error
>> 
>> Should one want winpcap in Windows 10, all one needs is:
>> http://www.win10pcap.org/
>> 
>> -Mark
>> 
>> 
>> On Tue, Apr 18, 2017 at 1:08 PM, Bob Supnik <bob at supnik.org<mailto:bob at supnik.org>> wrote:
>> You can get a pre-built Windows 32b 3.9 executable without Ethernet (and therefore, without needing WinPCap) here: http://simh.trailing-edge.com/sources/simhv39-0-exe.zip. It should run fine under W10. See if it will boot NetBSD 5.1.
>> 
>> /Bob Supnik
>> 
>> 
>> On 4/18/2017 3:53 PM, simh-request at trailing-edge.com<mailto:simh-request at trailing-edge.com> wrote:
>> You shouldn't need WinPCAP merely to test if the CD image is bootable.
>> The point of the boot test exercise is to help determine if the problem is
>> in NetBSD or due to recent changes to simh.  If changes to simh are at
>> fault, I'll track it down and fix the problem.
>> I specifically want to run a 5.x version of NetBSD. I'm pretty sure it did
>> run on SIMH 3.8-1 on Windows 7 before the upgrade. I need to downgrade a
>> laptop I have to Win7 in the future and may try that. Until then I'll play
>> with OpenBSD which doesn't seem to have any problems with SIMH 4.0 beta.
>> The boot test I'm suggesting will be far less work than setting up another
>> system.
>> 
>> Let me know.
>> 
>> - Mark
>> 
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com<mailto:Simh at trailing-edge.com>
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>> 
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20170418/0aaa0ccb/attachment-0001.html>
>> 
>> ------------------------------
>> 
>> Message: 5
>> Date: Wed, 19 Apr 2017 01:05:20 -0600
>> From: Kevin Handy <khandy21yo at gmail.com>
>> To: Johnny Billquist <bqt at softjar.se>
>> Cc: "simh at trailing-edge.com" <simh at trailing-edge.com>
>> Subject: Re: [Simh] DEC VT emulators on MAME
>> Message-ID:
>>         <CANk4W2OuRsR=uLH_856YSmrG4hJurJFUkn6tq_+HGWsAegh24Q at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> Looking at the schematic of the terminal from
>> http://bitsavers.trailing-edge.com/pdf/dec/terminal/vt340/K-TC-VT340_Schematic_Feb87.pdf,
>> it appears that there are two 8031 processors. One (E57) uses the 'P1 AA'
>> bus and has the 51x8 nvrom, the other (E24) uses the 'P2 BA' bus.
>> 
>> 64Kx8 ram seems to be shared between them.
>> 
>> 1st guess, E57 does most of the heavy work (serial, uart, keyboard, etc),
>> and the other E24  handles the display.
>> 
>> Also, for chip select,there is a 'P1 AA15 H' and a'P1 AA15 L' on the
>> connector which should help with the chip selection logic. (ie. the
>> inverter is inside the terminal, not on the card).
>> 
>> 
>> 
>> 
>> On Tue, Apr 18, 2017 at 2:39 PM, Johnny Billquist <bqt at softjar.se> wrote:
>> 
>> > Ok, looked at the schematics now.
>> >
>> > On 2017-04-18 21:53, Timothe Litt wrote:
>> >
>> >>
>> >>
>> >> Since they're windowless, they are not EPROM (remember what the E
>> >>> stands for), but plain ROMs.
>> >>>
>> >> Nope.  I meant exactly what I wrote.
>> >>
>> >
>> > [...]
>> >
>> > Good point about it being the same chip. I hadn't considered that
>> > possibility. I know that for some 27-series proms, there were certainly
>> > both mask programmable as well as EPROM versions, where the mask
>> > programmable was more persistent safe. EPROMs have a risk of loosing their
>> > content eventually, even if not exposed to UV light.
>> >
>> > As for which signal you use for what - it doesn't matter.  OE puts the
>> >> chip into a low power state just as effectively as CS - assuming that
>> >> the part isn't in programming or ID mode.  Since the part is never
>> >> written (in the terminal), this effectively gives you 2 CS pins
>> >> (effectively ANDed), and thus decoding requires at most an inverter.
>> >>
>> >
>> > Not entirely true.
>> > OE should timing wise be done after CS and addresses have been stable for
>> > a certain time. And power consumption of the chip is related to the control
>> > of CS, and is not related to OE.
>> >
>> > While power consumption might not be a problem, and the timing can be
>> > solve, it does mean that driving CS and OE cannot be done identically. If
>> > you use OE as a CS, you should make make sure the address is stable some
>> > time before you activate OE, and if you use CS, you need to still drive OE
>> > at a point later in time, and not just tie them together or something.
>> >
>> > The 27C256 is a 32K x 8 part; it has no A15 (but the cartridge socket
>> >> does.)
>> >>
>> >
>> > Yes, that was obvious.
>> >
>> > Keven pointed out that the odd chip is probably the character generator
>> >> ROM - thus the separate address and data bus - and it doesn't need a CS
>> >> or OE.  It's always reading something.
>> >>
>> >> As I've written before, rather than guessing, a few minutes with an
>> >> ohmmeter can sort all this out.
>> >>
>> >> I'm leaving that - and further exploration - as an exercise to the reader.
>> >>
>> >
>> > I seriously doubt it's a character generator ROM in the normal sense of
>> > the word. The VT340 do not generate character output in hardware.
>> > It's a graphic terminal, which stores the text in the the bitmap, as far
>> > as I remember (I seem to remember being able to go into graphics mode and
>> > affect text already written). Also, you have soft definable characters, so
>> > the CPU need to have access to the same memory the character generator
>> > would use anyway, and it has to contain some RAM, minimum. So it needs to
>> > be in the normal memory space of the CPU.
>> >
>> > But there is indeed two address and databuses, so I think it's fair to say
>> > the two select lines are only used for a subset of the PROMs.
>> >
>> > There might be data in one ROM that is copied into RAM at startup.
>> > Character definition tables, for example, I could imagine.
>> >
>> > Anyway, most things can be worked out my doing the measurements you
>> > suggest, yes.
>> >
>> >
>> >         Johnny
>> >
>> > --
>> > Johnny Billquist                  || "I'm on a bus
>> >                                   ||  on a psychedelic trip
>> > email: bqt at softjar.se             ||  Reading murder books
>> > pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>> > _______________________________________________
>> > Simh mailing list
>> > Simh at trailing-edge.com
>> > http://mailman.trailing-edge.com/mailman/listinfo/simh
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20170419/b8562239/attachment.html>
>> 
>> ------------------------------
>> 
>> Subject: Digest Footer
>> 
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>> 
>> ------------------------------
>> 
>> End of Simh Digest, Vol 159, Issue 26
>> *************************************
> 
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20171214/e2340292/attachment-0001.html>


More information about the Simh mailing list