[Simh] Simh Digest, Vol 167, Issue 33
gilberto dos santos alves
gsavix at gmail.com
Tue Dec 12 21:51:00 EST 2017
ubuntu simh please see that we have ubuntu 16.04 lts for long term support
very stable.
Em 12/12/2017 19:13, <simh-request at trailing-edge.com> escreveu:
> 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: DECnet for Linux problems (Ubuntu 17.10) (Johnny Billquist)
> 2. Re: Simh Digest, Vol 159, Issue 26 (Johnny Billquist)
> 3. Re: Simh Digest, Vol 167, Issue 30 (Mark Pizzolato)
>
>
> ---------- Mensagem encaminhada ----------
> From: Johnny Billquist <bqt at softjar.se>
> To: simh at trailing-edge.com
> Cc:
> Bcc:
> Date: Tue, 12 Dec 2017 21:39:06 +0100
> Subject: Re: [Simh] DECnet for Linux problems (Ubuntu 17.10)
> On 2017-12-12 04:48, Tim Stark wrote:
>
>> Ok, thanks for let me know. I now learned that DECnet for Linux is
>> already orphaned a few years ago. CVS facility will go away soon on
>> Sourceforge.net. I mirrored a copy of CVS repos and successfully
>> converted to Git repo by following SF instructions for conversion. I will
>> contact them for latest Linux kernel problems.
>>
>
> Uh? Isn't Linux already using git since many years?
>
> I will now remove decent from Ubuntu 17.10 because it complaint every few
>> minutes and asked me to send report to Ubuntu maintainers.
>>
>
> Not that surprised. Linux usually have been very quick at changing
> internal APIs, making lots of code not work.
>
> Instead I will use DECnet over IP method and got TCPware and MultiNet
>> software to set up. That allows accesses to HECnet.
>>
>
> Right. It will. And probably work better. But it does require a VMS box.
> But I assume you have that.
>
> I was looking for HECnet mail archives but can’t find them. I have now
>> subscribed to HECnet list. Does anyone know where is that HECnet mail
>> archives?
>>
>
> Nope. There are none.
> I do have all posts, but not in a digestable form, and they are also not
> separated from my private mail.
>
>
>> Thanks,
>>
>> Tim
>>
>> *From:* Larry Baker [mailto:baker at usgs.gov]
>> *Sent:* Monday, December 11, 2017 5:21 PM
>> *To:* fsword007 at gmail.com
>> *Cc:* simh <simh at trailing-edge.com>
>> *Subject:* Re: [Simh] DECnet for Linux problems (Ubuntu 17.10)
>>
>> Tim,
>>
>> Linux-DECnet used to be maintained by Chrissie Caulfield. She gave that
>> up three years ago. You might ask Steve Whitehouse (steve at chygwyn.com
>> <mailto:steve at chygwyn.com>) or Eduardo Serrat (emserrat at hotmail.com
>> <mailto:emserrat at hotmail.com>)for advice. I last worked on the code
>> several years ago for a DECnet/FAL-to-NFS gateway I built on a
>> Marvell SheevaPlug (ARM) SBC using Arch Linux ARM linux-kirkwood-3.16.
>> (The latest Linux longterm 3.16 kernel at that time was 3.16.6, at
>> https://www.kernel.org. The last Arch Linux ARM Kirkwood-specific Linux
>> 3.16 kernel was for 3.16.6 on October 16, 2014, at
>> https://github.com/archlinuxarm/PKGBUILDs/commit/8be533de52d
>> 44d39b2b12999e979d4d377f5e2e5.) I had to patch the kernel driver in a
>> couple places. There have been so may changes to the routing layer and
>> networking in general in the Linux kernel, it could be a substantial amount
>> of work to advance the decnet driver any further. Also, I found that
>> submitting patches to older kernels is a bit of a problem because of the
>> attitude of the gatekeeper of the Linux networking code.
>>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>
>
> --
> 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
>
>
>
> ---------- Mensagem encaminhada ----------
> From: Johnny Billquist <bqt at softjar.se>
> To: simh at trailing-edge.com
> Cc:
> Bcc:
> Date: Tue, 12 Dec 2017 21:42:12 +0100
> Subject: Re: [Simh] Simh Digest, Vol 159, Issue 26
> On 2017-12-12 14:52, Kurt Hamm wrote:
>
>> 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.
>>
>
> The reason for this is normally that you are sharing the network interface
> between the Linux box and your simh instance. So both speak on the same
> network interface. However, you do not hear what you send out, which means
> that you cannot communicate with anything else that is using the same
> interface. Essentially, the network interface does not loop back packets
> sent out.
>
> 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.
>>
>
> Have you configured VMS to have the DZ serial ports as well?
>
> Is there a way to connect a physical serial terminal via /dev/ttyUSB0
>> using SIMh Microvax 3900 simulator?
>>
>
> Should be, I assume.
>
> Johnny
>
>
>> Thanks for any advice.
>>
>> Kurt
>>
>> On Wed, Apr 19, 2017 at 3:05 AM, <simh-request at trailing-edge.com <mailto:
>> simh-request at trailing-edge.com>> wrote:
>>
>> Send Simh mailing list submissions to
>> simh at trailing-edge.com <mailto:simh at trailing-edge.com>
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>> <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 <mailto:simh-request at trailing-edge.com
>> >
>>
>> You can reach the person managing the list at
>> simh-owner at trailing-edge.com <mailto: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 <mailto:bob at supnik.org>>
>> To: simh at trailing-edge.com <mailto: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
>> <mailto: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
>> <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
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 18 Apr 2017 22:39:08 +0200
>> From: Johnny Billquist <bqt at softjar.se <mailto:bqt at softjar.se>>
>> To: simh at trailing-edge.com <mailto:simh at trailing-edge.com>
>> Subject: Re: [Simh] DEC VT emulators on MAME
>> Message-ID: <2e3a017d-0166-df35-3b92-11ab3a6912f4 at softjar.se
>> <mailto: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 <mailto: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 <mailto:phiber at phiber.com>>
>> To: Bob Supnik <bob at supnik.org <mailto:bob at supnik.org>>
>> Cc: simh at trailing-edge.com <mailto:simh at trailing-edge.com>
>> Subject: Re: [Simh] NetBSD 5.1 on MicoVAX 3900 boot error
>> Message-ID:
>> <CAPCE1iYZrkE19nrcTB-K-ZArhYi0
>> USyAZY0FRFBvCsQwMRw30g at mail.gmail.com
>> <mailto:CAPCE1iYZrkE19nrcTB-K-ZArhYi0USyAZY0FRFBvCsQwMRw30g@
>> 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
>> <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
>> <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
>> <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 <mailto:Mark at infocomm.com>>
>> To: Mark Abene <phiber at phiber.com <mailto:phiber at phiber.com>>, Bob
>> Supnik <bob at supnik.org <mailto:bob at supnik.org>>
>> Cc: "simh at trailing-edge.com <mailto:simh at trailing-edge.com>"
>> <simh at trailing-edge.com <mailto:simh at trailing-edge.com>>
>> Subject: Re: [Simh] NetBSD 5.1 on MicoVAX 3900 boot error
>> Message-ID:
>> <03006E3FC39B5A48AB9DBCCC10109
>> 0A82E8242E585 at REDROOF2.alohasunset.com
>> <mailto: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
>> <https://github.com/nmap/npcap/releases>
>>
>> From: Simh [mailto:simh-bounces at trailing-edge.com
>> <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 <mailto:bob at supnik.org>>
>> Cc: simh at trailing-edge.com <mailto: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><mailto: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
>> <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><mailto:simh-request@
>> 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><mailto:Simh at trailing-edge.com
>> <mailto:Simh at trailing-edge.com>>
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>> <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
>> <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 <mailto:khandy21yo at gmail.com
>> >>
>> To: Johnny Billquist <bqt at softjar.se <mailto:bqt at softjar.se>>
>> Cc: "simh at trailing-edge.com <mailto:simh at trailing-edge.com>"
>> <simh at trailing-edge.com <mailto:simh at trailing-edge.com>>
>> Subject: Re: [Simh] DEC VT emulators on MAME
>> Message-ID:
>> <CANk4W2OuRsR=uLH_856YSmrG4hJu
>> rJFUkn6tq_+HGWsAegh24Q at mail.gmail.com
>> <mailto:uLH_856YSmrG4hJurJFUkn6tq_%2BHGWsAegh24Q 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
>> <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
>> <mailto: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 <mailto:bqt at softjar.se> ||
>> Reading murder books
>> > pdp is alive! || tryin' to stay hip" - B. Idol
>> > _______________________________________________
>> > Simh mailing list
>> > Simh at trailing-edge.com <mailto:Simh at trailing-edge.com>
>> > http://mailman.trailing-edge.com/mailman/listinfo/simh
>> <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
>> <http://mailman.trailing-edge.com/pipermail/simh/attachments
>> /20170419/b8562239/attachment.html>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com <mailto:Simh at trailing-edge.com>
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>> <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
>>
>>
>
> --
> 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
>
>
>
> ---------- Mensagem encaminhada ----------
> From: Mark Pizzolato <Mark at infocomm.com>
> To: Kurt Hamm <kurt at hamm.me>, "simh at trailing-edge.com" <
> simh at trailing-edge.com>
> Cc:
> Bcc:
> Date: Tue, 12 Dec 2017 13:12:20 -0800
> Subject: Re: [Simh] Simh Digest, Vol 167, Issue 30
>
> Hi Kurt,
>
>
>
> This is a duplicate of a recently reported problem with host physical
> serial port connections through the DZ device on the VAX simulator.
> Details at: https://github.com/simh/simh/issues/504
>
>
>
> I haven’t had time to setup the environment to test this so I can track
> down the underlying problem.
>
>
>
> Meanwhile, you can connect the physical terminal to the VAX simulator’s
> console port with:
>
> sim> SET CONSOLE SERIAL=ser0;9600-8n1
>
> or equivalently on your system:
>
> sim> SET CONSOLE SERIAL=/dev/ttyUSB0;9600-8n1
>
>
>
> The failure of your command:
>
> sim> attach ttix line=0,connect=/dev/ttyUSB0;1200-7n1
>
> Non-existent device
>
>
>
> Is pilot error on your part. There is no TTIX device in the VAX simulator
> and the error message correctly reports that. That command might work on
> the PDP8 simulator which does have a TTIX device…
>
>
>
> - Mark
>
>
>
>
>
> *From:* Simh [mailto:simh-bounces at trailing-edge.com] *On Behalf Of *Kurt
> Hamm
> *Sent:* Tuesday, December 12, 2017 6:01 AM
> *To:* simh at trailing-edge.com
> *Subject:* Re: [Simh] Simh Digest, Vol 167, Issue 30
>
>
>
> My sincere apologies to the group for posting a complete thread with my
> question below.
>
>
>
> I wanted to clarify. I can connect the terminal to the Raspberry Pi via
> Raspian with no problem. I would like to connect the terminal as a serial
> device within Simh.
>
>
>
> Kurt
>
>
>
> Message: 6
> Date: Tue, 12 Dec 2017 08:52:39 -0500
> From: Kurt Hamm <kurt at hamm.me>
> To: simh at trailing-edge.com
> Subject: Re: [Simh] Simh Digest, Vol 159, Issue 26
> Message-ID:
> <CAJRDvfWDKDDw5jS23BQUZqC5z89wd5U6F3i90cRNFg-ZDkkfLA at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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
>
>
> _______________________________________________
> 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/20171213/30ad1986/attachment-0001.html>
More information about the Simh
mailing list