Re: PCIe/PCI I/O access (was: Re: VT340 Emulation)

[Maciej W. Rozycki via cctalk]

On Sun, 27 Jun 2021, Kevin Bowling wrote:

> Thanks this was interesting learning.

 You are welcome!

 NB I think it is also worth noting that the presence of I/O instructions 
and corresponding bus cycles with x86 is most relevant for PCI as it is 
only *because* x86, or more importantly the PC/AT architecture, has had 
them in the first place that PCI (and consequently PCIe) has them as well. 
Likewise the interrupt acknowledge or the special cycle bus transactions 
-- they're both x86-specific, even if they may have been later repurposed 
in non-x86 PCI system designs.

 Intel was a key player in PCI design and surely their requirements were 
first-class citizens in the solution proposed.  While early PCI systems 
commonly had PCI and ISA/EISA buses arranged as peers on the CPU host bus, 
with the respective bridge chips being two of the three or more agents 
arbitrated there (the remaining ones being the CPU(s)), the ability to 
route x86-specific bus cycles over PCI eventually let the industry settle 
on PCI x86 systems of the common northbridge/southbridge architecture we 
saw so many specimens of, where I/O address space resources originating 
from the PC, PC/XT, and PC/AT architectures can be accessed behind a PCI 
bus segment just as if they were attached directly to the CPU, possibly 
via some bus buffers only, like with the original IBM design from 1981.

 Similarly an x86 CPU can send an interrupt acknowledge cycle over PCI to 
request an interrupt vector from an 8259A interrupt controller core 
present in the southbridge, or a shutdown special cycle, in response to a 
triple fault, so as to make the southbridge assert a CPU reset, just like 
the original discrete PC/AT circuitry did.  None of this is really needed 
by non-x86 systems, although again these features may have been repurposed 
now that they are present (Intel has since invented additional special CPU 
cycles too, used in power management and intepreted by the southbridge), 
and numerous host bridges used with non-x86 systems have dedicated CSRs in 
the memory address space for issuing these PCI bus cycles, which the CPU 
cannot natively produce.

 BTW it wasn't exactly obvious to me that a flood of:

LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014
IPMI: dropping non severe PEL event

messages produced by the system firmware to the console serial port was a 
symptom of a PCI device driver trying to poke at the port I/O address of 
0, correctly left by the OS in the relevant device's BAR (Base Address 
Register) along with the disabled status for I/O decoding in the device's 
PCI Command Register.  The driver, not platform-specific and unaware of 
the possibility of the inexistence of the PCI I/O address space in some 
systems, ignored the disabled status of I/O decoding with the device and 
just went ahead and poked at it, confusing the host bridge with the bus 
accesses that resulted (likely an OS bug too with port I/O address space 
accessors, though I wasn't inclined enough to chase it); of course the 
port I/O address of 0 itself has no particular meaning with non-x86 
systems and can be legitimately assigned and used with PCI devices.

 FWIW,

  Maciej

Re: VT340 Emulation

[Chuck Guzis via cctalk]

On 6/28/21 6:22 AM, David Brownlee via cctalk wrote:

> I think he's probably referring to the hugely overinflated BIOS &
> firmware updating software that most x86 hardware ships with.
> 
> I've never had the need to connect an FTDI based device to anything
> other than NetBSD, but I remember reading the horror stories a while
> back about FTDI Windows drivers trying to brick knock off clone
> hardware.

Never ran into that; I do use USB-serial dongles using the Prolific
chipset and have never had problems with Linux or Windows 7 or XP.

FWIW
Chuck

Re: VT340 Emulation

[David Brownlee via cctalk]

On Mon, 28 Jun 2021 at 14:11, Paul Koning  wrote:
> > On Jun 28, 2021, at 4:23 AM, David Brownlee via cctalk 
> >  wrote:
> >
> > ...
> > I noticed this the other day, just in case it's of interest to anyone
> > on this thread.
> >
> > | https://www.tindie.com/products/nsayer/ftdi-be-gone/
> > | FTDI-be-gone is a USB-to-serial adapter. ... Rather than use a
> > proprietary device
> > | driver to implement the serial port in the host, it relies on CDC
> > class drivers supplied by the
> > | OS.
>
> Which OS requires special FTDI drivers?  Mac OS certainly does not.

I think he's probably referring to the hugely overinflated BIOS &
firmware updating software that most x86 hardware ships with.

I've never had the need to connect an FTDI based device to anything
other than NetBSD, but I remember reading the horror stories a while
back about FTDI Windows drivers trying to brick knock off clone
hardware.

David

Re: VT340 Emulation

[Paul Koning via cctalk]

> On Jun 28, 2021, at 4:23 AM, David Brownlee via cctalk 
>  wrote:
> 
> ...
> I noticed this the other day, just in case it's of interest to anyone
> on this thread.
> 
> | https://www.tindie.com/products/nsayer/ftdi-be-gone/
> | FTDI-be-gone is a USB-to-serial adapter. ... Rather than use a
> proprietary device
> | driver to implement the serial port in the host, it relies on CDC
> class drivers supplied by the
> | OS.

Which OS requires special FTDI drivers?  Mac OS certainly does not.

paul

Re: VT340 Emulation

[David Brownlee via cctalk]

On Sat, 26 Jun 2021 at 18:15, Paul Koning via cctalk
 wrote:
> > On Jun 26, 2021, at 11:31 AM, Tapley, Mark B. via cctalk 
> >  wrote:
> >
> > At one point FTDI had a reasonably good reputation, and I own one of those 
> > devices based on that reputation. I have used it with no obvious problems 
> > connecting a TRS Color Computer 3 to an iMac G3 for a floppy-drive emulator 
> > (DriveWire on the iMac), but I think only for that application so far.
> >
> > Are there any particular pitfalls I should watch out for with the FTDI 
> > device, when/if I can get back to working with it?
>
> I once bought a USB serial port device with a DE-9 connector on it, Belkin I 
> think.  It worked somewhat.  Might have needed its own driver, which on a Mac 
> is highly unusual.  It gave me enough trouble I set it aside.
>
> Since then I've bought several different flavors of the FTDI USB serial 
> device, one RS-232, one 5 volt logic, one 3.3 volt logic (the latter two with 
> 6-pin connectors to fit onto pin headers such as are found on the BeagleBone 
> Black).  They have always worked flawlessly (on my Mac), at a number of data 
> rates: 4800, 9600, 19.2k, 115k.  I'll admit I haven't needed stranger cases 
> like 5 or 6 bit data, or exotic slow speeds.  As I mentioned, if that need 
> arises and FTDI isn't good enough I'll have the RPico to do the job.

I noticed this the other day, just in case it's of interest to anyone
on this thread.

| https://www.tindie.com/products/nsayer/ftdi-be-gone/
| FTDI-be-gone is a USB-to-serial adapter. The RS-232 variant has a
DB9M connector on one
| end and a micro-B USB connector on the other. The TTL variant has a
6 pin SIP header on the
| end opposite the USB connector. Both have two LEDs - a red one to
indicate transmitted data
| and a green one to indicate received data.
| The USB-UART chip is a Cypress Semi CY7C65213. Rather than use a
proprietary device
| driver to implement the serial port in the host, it relies on CDC
class drivers supplied by the
| OS.

Unrelated - if you know someone who works with clocks, or in other
ways has a natural affinity to even per second ticks,
https://www.tindie.com/products/nsayer/crazy-clock/ could be quite a
horrible/good present to get them depending on their sense of humour
(just bought one for a clock repairing geek friend :-p)

David

Re: PCIe/PCI I/O access (was: Re: VT340 Emulation)

[Kevin Bowling via cctalk]

Thanks this was interesting learning.

On Sun, Jun 27, 2021 at 9:41 AM Maciej W. Rozycki via cctalk <
cctalk@classiccmp.org> wrote:

> On Sun, 27 Jun 2021, Paul Koning wrote:
>
> > > However both serial and parallel ports remain reasonably available as
> > > PCIe option devices.  Though parallel ports seem to be made as legacy
> PCIe
> > > devices only, that is accessed with I/O rather than memory read/write
> bus
> > > cycles, which are not, as I have learnt the hard way recently,
> supported
> > > by all computer systems nowadays.  I guess x86 systems will continue
> to
> > > support them however as x86 CPUs have native I/O access instructions.
> >
> > I/O cycles on PCI have no direct connection to I/O instructions.  I've
> > routinely used I/O operations in PCI on a MIPS platform, which of course
> > has no such concept; all that was needed is to send the memory cycles to
> > the address block that the PCI bridge maps onto I/O cycles rather than
> > memory cycles.
>
>  That's not my point.  The host bridge has to implement them and some do
> not (e.g. the POWER9 PHB4).  For CPU architectures that do not have native
> I/O cycle support an MMIO window has to be defined by the host bridge for
> memory cycles decoded within that window to be forwarded downstream as
> PCIe I/O Read/Write TLPs (likewise with legacy PCI I/O Read/Write
> cycles).
> If you don't define such a window along with associated circuitry (like
> with the PHB4), then there's simply no way to produce I/O TLPs on PCIe.
>
>  When you have a CPU architecture such as x86 that does do I/O cycles
> natively, then they're just forwarded by the host bridge as PCIe I/O
> Read/Write TLPs.  Of course one can envisage an x86 host bridge that won't
> forward I/O cycles produced by the CPU to PCIe and will either terminate
> them with a bus error or let them time out, but I find it highly
> unlikely.
> For one I suspect the circuitry required to terminate unclaimed host bus
> I/O cycles is no less expensive than one to just forward them downstream;
> after all a PCIe I/O TLP is told apart from a memory TLP merely by a
> difference in a bit pattern sent downstream that encodes the cycle type,
> one of several (likewise with PCI cycles).
>
>  NB PCIe I/O Read/Write TLPs have been deprecated ever since the first
> revision of the PCIe specification and PCIe devices that do require I/O
> TLPs for operation have always been referred to as legacy PCIe devices.
> I guess support for such devices has been added to the specification so as
> to aid the industry with switching entirely to the MMIO operating model,
> with initial PCIe devices expected to be implemented by placing the
> original PCI/PCI-X ASIC behind a PCIe-to-PCI bridge, until new PCIe ASICs
> have been made.  For some option cards it seems the only way to date, e.g.
> PCIe ATM network adapters.
>
>  As it has turned out actual PCIe ASICs have been manufactured that do
> require I/O Read/Write TLPs for their operation such as said IEEE 1284
> parallel ports.  It's not actually clear to me why, but a plausible
> explanation is they have been considered too niche at that point for the
> effort required for the OS drivers to be updated.
>
>   Maciej
>

PCIe/PCI I/O access (was: Re: VT340 Emulation)

[Maciej W. Rozycki via cctalk]

On Sun, 27 Jun 2021, Paul Koning wrote:

> > However both serial and parallel ports remain reasonably available as 
> > PCIe option devices.  Though parallel ports seem to be made as legacy PCIe 
> > devices only, that is accessed with I/O rather than memory read/write bus 
> > cycles, which are not, as I have learnt the hard way recently, supported 
> > by all computer systems nowadays.  I guess x86 systems will continue to 
> > support them however as x86 CPUs have native I/O access instructions.
> 
> I/O cycles on PCI have no direct connection to I/O instructions.  I've 
> routinely used I/O operations in PCI on a MIPS platform, which of course 
> has no such concept; all that was needed is to send the memory cycles to 
> the address block that the PCI bridge maps onto I/O cycles rather than 
> memory cycles.

 That's not my point.  The host bridge has to implement them and some do 
not (e.g. the POWER9 PHB4).  For CPU architectures that do not have native 
I/O cycle support an MMIO window has to be defined by the host bridge for 
memory cycles decoded within that window to be forwarded downstream as 
PCIe I/O Read/Write TLPs (likewise with legacy PCI I/O Read/Write cycles).  
If you don't define such a window along with associated circuitry (like 
with the PHB4), then there's simply no way to produce I/O TLPs on PCIe.

 When you have a CPU architecture such as x86 that does do I/O cycles 
natively, then they're just forwarded by the host bridge as PCIe I/O 
Read/Write TLPs.  Of course one can envisage an x86 host bridge that won't 
forward I/O cycles produced by the CPU to PCIe and will either terminate 
them with a bus error or let them time out, but I find it highly unlikely.  
For one I suspect the circuitry required to terminate unclaimed host bus 
I/O cycles is no less expensive than one to just forward them downstream; 
after all a PCIe I/O TLP is told apart from a memory TLP merely by a 
difference in a bit pattern sent downstream that encodes the cycle type, 
one of several (likewise with PCI cycles).

 NB PCIe I/O Read/Write TLPs have been deprecated ever since the first 
revision of the PCIe specification and PCIe devices that do require I/O 
TLPs for operation have always been referred to as legacy PCIe devices.  
I guess support for such devices has been added to the specification so as 
to aid the industry with switching entirely to the MMIO operating model, 
with initial PCIe devices expected to be implemented by placing the 
original PCI/PCI-X ASIC behind a PCIe-to-PCI bridge, until new PCIe ASICs 
have been made.  For some option cards it seems the only way to date, e.g. 
PCIe ATM network adapters.

 As it has turned out actual PCIe ASICs have been manufactured that do 
require I/O Read/Write TLPs for their operation such as said IEEE 1284 
parallel ports.  It's not actually clear to me why, but a plausible 
explanation is they have been considered too niche at that point for the 
effort required for the OS drivers to be updated.

  Maciej

Re: VT340 Emulation

[Paul Koning via cctalk]

> On Jun 26, 2021, at 7:08 PM, Maciej W. Rozycki  wrote:
> 
> On Fri, 25 Jun 2021, Paul Koning via cctalk wrote:
> 
>>> Well you can find mother boards with real COM port, but they are rare.
>> 
>> One place you can find them easily is on industrial computers.  My 
>> firewall machine is one, because I wanted it to be fanless.  It has the 
>> usual pile of USB ports and HDMI, but also 2 COM ports; another model of 
>> that same line has 6 COM ports.
>> 
>> What seems to be harder to find is a parallel printer port, but there is 
>> far less reason to want one of those.
> 
> However both serial and parallel ports remain reasonably available as 
> PCIe option devices.  Though parallel ports seem to be made as legacy PCIe 
> devices only, that is accessed with I/O rather than memory read/write bus 
> cycles, which are not, as I have learnt the hard way recently, supported 
> by all computer systems nowadays.  I guess x86 systems will continue to 
> support them however as x86 CPUs have native I/O access instructions.

I/O cycles on PCI have no direct connection to I/O instructions.  I've 
routinely used I/O operations in PCI on a MIPS platform, which of course has no 
such concept; all that was needed is to send the memory cycles to the address 
block that the PCI bridge maps onto I/O cycles rather than memory cycles.

paul

Re: VT340 Emulation

[Maciej W. Rozycki via cctalk]

On Fri, 25 Jun 2021, Paul Koning via cctalk wrote:

> > Well you can find mother boards with real COM port, but they are rare.
> 
> One place you can find them easily is on industrial computers.  My 
> firewall machine is one, because I wanted it to be fanless.  It has the 
> usual pile of USB ports and HDMI, but also 2 COM ports; another model of 
> that same line has 6 COM ports.
> 
> What seems to be harder to find is a parallel printer port, but there is 
> far less reason to want one of those.

 However both serial and parallel ports remain reasonably available as 
PCIe option devices.  Though parallel ports seem to be made as legacy PCIe 
devices only, that is accessed with I/O rather than memory read/write bus 
cycles, which are not, as I have learnt the hard way recently, supported 
by all computer systems nowadays.  I guess x86 systems will continue to 
support them however as x86 CPUs have native I/O access instructions.

  Maciej

Re: USB Serial conversion / was Re: VT340 Emulation

[Brielle via cctalk]

Unfortunately, with newer M1 macs and BigSur you are limited to FTDI USB serial 
dongles since there’s no new prolific driver AFAIK.  At least the FTDI driver 
is included out of the box.

I’ve had really good luck when I’ve needed slow/odd speeds with the Comtrol RPS 
series of Ethernet connected serial boxes.

Sent from my iPad

> On Jun 26, 2021, at 3:09 PM, Brent Hilpert via cctalk  
> wrote:
> 
> (Product ID 0x2303: Prolific produces a series of PL2303x USB-Serial chips.)
> 
> It was plug-n-play on the Mac (given a terminal app program that knows to 
> accept and perform the little-used config specs).

USB Serial conversion / was Re: VT340 Emulation

[Brent Hilpert via cctalk]

On 2021-Jun-26, at 10:15 AM, Paul Koning via cctalk wrote:
>> On Jun 26, 2021, at 11:31 AM, Tapley, Mark B. via cctalk 
>>  wrote:
>> 
>> At one point FTDI had a reasonably good reputation, and I own one of those 
>> devices based on that reputation. I have used it with no obvious problems 
>> connecting a TRS Color Computer 3 to an iMac G3 for a floppy-drive emulator 
>> (DriveWire on the iMac), but I think only for that application so far.
>> 
>> Are there any particular pitfalls I should watch out for with the FTDI 
>> device, when/if I can get back to working with it?
> 
> I once bought a USB serial port device with a DE-9 connector on it, Belkin I 
> think.  It worked somewhat.  Might have needed its own driver, which on a Mac 
> is highly unusual.  It gave me enough trouble I set it aside.
> 
> Since then I've bought several different flavors of the FTDI USB serial 
> device, one RS-232, one 5 volt logic, one 3.3 volt logic (the latter two with 
> 6-pin connectors to fit onto pin headers such as are found on the BeagleBone 
> Black).  They have always worked flawlessly (on my Mac), at a number of data 
> rates: 4800, 9600, 19.2k, 115k.  I'll admit I haven't needed stranger cases 
> like 5 or 6 bit data, or exotic slow speeds.  As I mentioned, if that need 
> arises and FTDI isn't good enough I'll have the RPico to do the job.

A couple years ago, somewhat on a whim, I checked a small number of USB-Serial 
converters for driving a couple of Model 28 Teletypes.

I didn't really expect anything so modern to work below 300 BPS, or do the 
needed 5-data/2-stop, but the teletypes were 75 BPS, which is just another in 
the division-of-2 series down from 19200,9600,etc.; and I was actually figuring 
on just using 8-bit and ensuring the later bits were 0 so they would be seen as 
stop bits, and take a bit of a penalty on the 28 print speed (might be a little 
rough/abusive on the teletype commutator start/stop though).

Sometimes, ya luck out: one of them actually worked down to 75 BPS, *and* did 
5-data/2-stop.

There's no ID on the physical unit but it shows up on the system (OSX) as: 
Product ID: 0x2303
 Vendor ID: 0x067b  (Prolific Technology, Inc.)

(Product ID 0x2303: Prolific produces a series of PL2303x USB-Serial chips.)

It was plug-n-play on the Mac (given a terminal app program that knows to 
accept and perform the little-used config specs).

There are some other teletypes to get going that need slower speeds, for which 
I intend a solution as (Paul) suggests, bit-banging out of an RPi. The code was 
written some time ago, but haven't gotten around to the physical connections.

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/26/21 6:43 AM, Peter Corlett via cctalk wrote:
A bit of both. The USB communications device class (CDC) is designed 
for modems, and it can be hit-and-miss trying to speak to something 
else.



Are you commenting about USB-to-Serial (a.k.a. FTDI) devices or USB 
devices in general?


I commonly referred to USB as Useless  Bus between the late 
'90s and mid '00s.  Supporting it, especially on non-bleeding edge 
computers / OSs, was ... not pleasant.


Of course, that doesn't prevent one from ignoring that standard and 
just creating a bespoke USB device which happens to produce RS232, 
and FTDI do just that. FTDI's devices are better than standard CDC, 
but that's not a terribly high bar.


Interesting.

Well, these things will contain a UART of some form, because how 
else could they work?


Snark warning:  Have you seen a WinModem?

Seriously, I could see something blindly sampling the electrical signal 
and then doing everything in software.  As in Digital Signal Processing. 
 No actual knowledge / design as if it's serial until you get the data 
stream out the other end.  Obviously needing comparable to be able to 
transmit.


For all I know they may even incorporate an actual 16550 IP core in 
the design and talk to that from its firmware, although a UART uses 
bugger all gates by modern standards and you can just get an intern 
to design one in a lunchbreak rather than pay for an IP core.


I suspect you'd get what you paid for.  IMHO there are too many 
permutations on what constitutes serial.  If anything, this discussion 
supports that.  Even if we limit our scope to be RS-232, RS-422, and 
RS-485 without going further afield.  How much of the serial ecosystem 
do we eliminate if equipment assumes 8-bit?  }:-)


It doesn't seem impossible to build a decent USB-serial dongle which 
caters to all of the weird and wonderful edge cases, but the market 
for such things is small enough that they would be quite expensive 
to produce, reducing the market further.


I don't know.  Maybe.  I've seen some really fancy things designed by 
people as part of the Retro Computing / Retro Networking hobby.  Perhaps 
someone will take up the torch and a Good (TM) USB to Serial converter, 
open source the design* and someone else will sell PCBs and / or kits 
for it.  Maybe even someone will assemble some and sell them for those 
that don't own a soldering iron or aren't good at using one.


Something I'm putting off is installing a USB micro-B plug on my 
old iPod whose 30 pin socket has finally given up the ghost. I could 
just buy a new one, except they don't make them any more: the current 
device called an "iPod" is a glorified advertising hoarding which has 
a usability disaster of a media player bolted on as an afterthought.


Interesting.  I've not heard of anyone doing this.  But I'm not 
surprised that it's possible.




--
Grant. . . .
unix || die

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/26/21 9:31 AM, Tapley, Mark B. via cctalk wrote:
Are there any particular pitfalls I should watch out for with the 
FTDI device, when/if I can get back to working with it?


I've used -- what I'll generically call -- FTDI devices one or more 
times a year for the last decade or more.  Admittedly I'm not asking 
much of it; 115200, 8, n, 1, or 9600, 8, n, 1, to connect to serial 
console ports on network equipment.


Aside:  I believe that Cisco started including such FTDI devices in some 
of their equipment and only exposing the USB cable / port.  So all you 
need is a passive USB cable -- easy enough to obtain -- and a new enough 
OS that it includes drivers for FTDI ports -- also easy enough to obtain.


I do recall having problems with /some/ devices that fall into the FTDI 
device category.  I don't know that they were FTDI /brand/ per se.  I 
don't know if those problems were driver and / or hardware related.  But 
I do know that the ones that had FTDI in their driver / device name (as 
reported by Windows' Device Manager) tended to be more reliable and work 
longer.  As in didn't die 6 months later.


I have one USB-to-Serial that I picked up out of a junk pile that has 16 
(?) DE-9 male ports on it and one USB-B port on it.  It presents itself 
to the computer as 16 discrete serial ports on one USB device.  It was 
definitely worth the price of digging through the bone pile in 95 degree 
heat.




--
Grant. . . .
unix || die

Re: VT340 Emulation

[Paul Koning via cctalk]

> On Jun 26, 2021, at 11:31 AM, Tapley, Mark B. via cctalk 
>  wrote:
> 
> At one point FTDI had a reasonably good reputation, and I own one of those 
> devices based on that reputation. I have used it with no obvious problems 
> connecting a TRS Color Computer 3 to an iMac G3 for a floppy-drive emulator 
> (DriveWire on the iMac), but I think only for that application so far.
> 
> Are there any particular pitfalls I should watch out for with the FTDI 
> device, when/if I can get back to working with it?

I once bought a USB serial port device with a DE-9 connector on it, Belkin I 
think.  It worked somewhat.  Might have needed its own driver, which on a Mac 
is highly unusual.  It gave me enough trouble I set it aside.

Since then I've bought several different flavors of the FTDI USB serial device, 
one RS-232, one 5 volt logic, one 3.3 volt logic (the latter two with 6-pin 
connectors to fit onto pin headers such as are found on the BeagleBone Black).  
They have always worked flawlessly (on my Mac), at a number of data rates: 
4800, 9600, 19.2k, 115k.  I'll admit I haven't needed stranger cases like 5 or 
6 bit data, or exotic slow speeds.  As I mentioned, if that need arises and 
FTDI isn't good enough I'll have the RPico to do the job.

paul

Re: VT340 Emulation

[Tapley, Mark B. via cctalk]

On Jun 26, 2021, at 7:43 AM, Peter Corlett via cctalk 
mailto:cctalk@classiccmp.org>> wrote:
...
A bit of both. The USB communications device class (CDC) is designed for
modems, and it can be hit-and-miss trying to speak to something else. Of
course, that doesn't prevent one from ignoring that standard and just
creating a bespoke USB device which happens to produce RS232, and FTDI do
just that. FTDI's devices are better than standard CDC, but that's not a
terribly high bar.
...

At one point FTDI had a reasonably good reputation, and I own one of those 
devices based on that reputation. I have used it with no obvious problems 
connecting a TRS Color Computer 3 to an iMac G3 for a floppy-drive emulator 
(DriveWire on the iMac), but I think only for that application so far.

Are there any particular pitfalls I should watch out for with the FTDI device, 
when/if I can get back to working with it?

- Mark

Re: VT340 Emulation

[Peter Corlett via cctalk]

On Fri, Jun 25, 2021 at 04:53:08PM -0600, Grant Taylor via cctalk wrote:
> On 6/25/21 2:48 AM, Peter Corlett via cctalk wrote:
[...]
>> The other is in the software layer: the standards are a mess and the
>> full gamut of serial protocols are not available and/or not implemented
>> properly.
> I can't tell if that's a USB specification problem or a problem with what
> people have executed / built (thus far).

A bit of both. The USB communications device class (CDC) is designed for
modems, and it can be hit-and-miss trying to speak to something else. Of
course, that doesn't prevent one from ignoring that standard and just
creating a bespoke USB device which happens to produce RS232, and FTDI do
just that. FTDI's devices are better than standard CDC, but that's not a
terribly high bar.

> From my naive point of view, I wonder if it would be possible to build
> some sort of USB device that has a traditional UART that has supporting
> circuitry to connect to the host over USB. -- I say this because it sounds
> like many ~> most ~> all (?) USB to RS-232 converters are doing something
> inferior.

Well, these things will contain a UART of some form, because how else could
they work? For all I know they may even incorporate an actual 16550 IP core
in the design and talk to that from its firmware, although a UART uses
bugger all gates by modern standards and you can just get an intern to
design one in a lunchbreak rather than pay for an IP core.

It doesn't seem impossible to build a decent USB-serial dongle which caters
to all of the weird and wonderful edge cases, but the market for such things
is small enough that they would be quite expensive to produce, reducing the
market further.

>> The physical connector and pinout is an irrelevance in comparison. I own
>> a soldering iron.
> LOL (literally) I love your sentiment there. I quite agree with it.

Something I'm putting off is installing a USB micro-B plug on my old iPod
whose 30 pin socket has finally given up the ghost. I could just buy a new
one, except they don't make them any more: the current device called an
"iPod" is a glorified advertising hoarding which has a usability disaster of
a media player bolted on as an afterthought.

Re: VT340 Emulation

[Glen Slick via cctalk]

On Fri, Jun 25, 2021 at 3:53 PM Grant Taylor via cctalk
 wrote:
>
>  From my naive point of view, I wonder if it would be possible to build
> some sort of USB device that has a traditional UART that has supporting
> circuitry to connect to the host over USB.  --  I say this because it
> sounds like many ~> most ~> all (?) USB to RS-232 converters are doing
> something inferior.
>

Of course that has been done in commercial products. For example I
have some Inside Out Networks Edgeport / 4 devices (apparently later
sold by Digi) that are implemented using a traditional ST16C654 quad
UART and MAX3243E RS-232 transceivers, with an Intel 80930
microcontroller as the interface between the UART and the USB host.
The Intel 80930 has an 80251 core integrated with a USB interface, and
was one of the first microcontrollers available on the market. This
device dates from 1997, so reasonably early in the USB game.

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/25/21 2:48 AM, Peter Corlett via cctalk wrote:
USB-serial dongles tend to be a wretched experience for a couple 
of reasons.  The first is at the electrical layer: USB only has 5V 
available and generating RICH CHUNKY VOLTS in such a small dongle 
is difficult and expensive, so doesn't happen, and the voltage 
swing might not be wide enough for older devices.


That sounds like a legitimate problem.  But it sounds more like an 
/execution/ problem than a /possibility/ or /capability/ problem.  E.g. 
USB interface between a host the device (both in the USB parlance) where 
the device is externally powered.


The other is in the software layer: the standards are a mess and 
the full gamut of serial protocols are not available and/or not 
implemented properly.


I can't tell if that's a USB specification problem or a problem with 
what people have executed / built (thus far).


From my naive point of view, I wonder if it would be possible to build 
some sort of USB device that has a traditional UART that has supporting 
circuitry to connect to the host over USB.  --  I say this because it 
sounds like many ~> most ~> all (?) USB to RS-232 converters are doing 
something inferior.


The physical connector and pinout is an irrelevance in comparison. I 
own a soldering iron.


LOL  (literally)  I love your sentiment there.  I quite agree with it.



--
Grant. . . .
unix || die

Re: VT340 Emulation

[Zane Healy via cctalk]

On Jun 25, 2021, at 6:07 AM, Paul Koning via cctalk  
wrote:
> A possible issue is that a lot of applications, including many Apple ones, 
> don't offer an adequate selection of scaling options.  This is one of the 
> very few places where Windows is better, in that it offers ways to scale the 
> text to comfortably large sizes for old eyes.
> 
>   paul

I had an Intern run afoul of the text scaling on Windows a couple months ago.  
When he started we thought they’d given him a laptop with some ridiculously low 
resolution, and he couldn’t run the main application we needed him working with 
in a usable fashion.  Finally I realized Windows was “zooming” it.  When an 
application needs to be able to display a certain number of “lines” of data to 
be usable, this sort of behavior isn’t exactly useful in such a case. 

Zane

Re: VT340 Emulation

[Paul Koning via cctalk]

> On Jun 25, 2021, at 10:24 AM, ben via cctalk  wrote:
> ...
> Well you can find mother boards with real COM port, but they are rare.

One place you can find them easily is on industrial computers.  My firewall 
machine is one, because I wanted it to be fanless.  It has the usual pile of 
USB ports and HDMI, but also 2 COM ports; another model of that same line has 6 
COM ports.

What seems to be harder to find is a parallel printer port, but there is far 
less reason to want one of those.

paul

Re: VT340 Emulation

[ben via cctalk]

On 2021-06-25 2:48 a.m., Peter Corlett via cctalk wrote:


USB-serial dongles tend to be a wretched experience for a couple of reasons.
The first is at the electrical layer: USB only has 5V available and
generating RICH CHUNKY VOLTS in such a small dongle is difficult and
expensive, so doesn't happen, and the voltage swing might not be wide enough
for older devices. The other is in the software layer: the standards are a
mess and the full gamut of serial protocols are not available and/or not
implemented properly.


Or if you change USB ports the serial COM# changes.


The physical connector and pinout is an irrelevance in comparison. I own a
soldering iron.


Well you can find mother boards with real COM port, but they are rare.
I just got a new system built, and mine has one hidden on it. No 
connector for it however.

Ben.

Re: VT340 Emulation

[Paul Koning via cctalk]

> On Jun 25, 2021, at 4:48 AM, Peter Corlett via cctalk  
> wrote:
> 
> On Thu, Jun 24, 2021 at 06:46:41PM -0600, Grant Taylor via cctalk wrote:
> [...]
>> The 4k monitors that I've worked with have been ultra high DPI. This means
>> that things that don't have DPI settings end up being tiny on the screen.
> 
> It works fine on MacOS, except for various garbage ports from Windows
> (Audacity is the one which comes to mind first) using "cross-platform"
> toolkits which ignore or misuse the native APIs. 

There may be applications like that but Audacity does not fit the description.  
It uses WxWidgets, which is specifically known for using the native APIs on 
each of the platforms it runs on.

Mac OS "retina" screen handling works by pretending, by default, that dots on 
the screen are 2x the real size.  But you can address the actual pixels by 
requesting a scale factor of 0.5 in the API.  I have several WxWidgets 
application that do this.

A possible issue is that a lot of applications, including many Apple ones, 
don't offer an adequate selection of scaling options.  This is one of the very 
few places where Windows is better, in that it offers ways to scale the text to 
comfortably large sizes for old eyes.

paul

Re: VT340 Emulation

[Peter Corlett via cctalk]

On Thu, Jun 24, 2021 at 06:46:41PM -0600, Grant Taylor via cctalk wrote:
[...]
> The 4k monitors that I've worked with have been ultra high DPI. This means
> that things that don't have DPI settings end up being tiny on the screen.

It works fine on MacOS, except for various garbage ports from Windows
(Audacity is the one which comes to mind first) using "cross-platform"
toolkits which ignore or misuse the native APIs. It's somewhat more
hit-and-miss on Linux because it relies a lot more on those toolkits a lot
more for GUI application software as there aren't so many native
alternatives. But hey, it's still less broken than Windows.

Windows is a curiously-heavyweight bootloader for Steam. It serves no other
useful purpose.

> It's especially a problem if you try to mix non-4k and 4k monitors.

Disregarding the aforementioned software deliberately trying to subvert it,
this again just works on the Mac: drag a window from one monitor to the
other and the window contents will change its DPI to match.

>> OK, sorry. "Real" is for me here, physically the same connectors like
>> DB25/DB9/MMJ/etc ...
> So how does that differ than a USB-to-RS-232 with the proper passive
> adapter to go from DB-9 to DB-25 / MMJ.

USB-serial dongles tend to be a wretched experience for a couple of reasons.
The first is at the electrical layer: USB only has 5V available and
generating RICH CHUNKY VOLTS in such a small dongle is difficult and
expensive, so doesn't happen, and the voltage swing might not be wide enough
for older devices. The other is in the software layer: the standards are a
mess and the full gamut of serial protocols are not available and/or not
implemented properly.

The physical connector and pinout is an irrelevance in comparison. I own a
soldering iron.

Re: VT340 Emulation

[Paul Koning via cctalk]

> On Jun 24, 2021, at 8:51 PM, Grant Taylor via cctalk  
> wrote:
> 
> On 6/22/21 9:12 AM, Ethan Dicks via cctalk wrote:
>> The OP said he meant with "real" connectors, but in my case, I've 
>> encountered strange buffering issues with USB serial dongles (since they are 
>> really block-mode devices, not character-at-a-time) and I've definitely had 
>> problems supporting lines with odd parameters (especially speeds slower than 
>> 300 baud or with 5-bits-per-char, like one would use for a Model 19 or Model 
>> 28 teletype).  The hardware UARTs on AVR processors implement those juse 
>> fine (though for "50 baud", you often have to put a slower crystal on the 
>> processor because the 16-bit divisor overflows at 16-20MHz).  The "soft 
>> serial" libraries often just hard-code 8-bit implementations.  Fine for 
>> modern stuff but I have uses for connecting to electromechanical serial 
>> devices.
> 
> These seem like real problems, which can't be overcome by a passive physical 
> adapter.
> 
> These also seem like implementation problems to me.  At least more than they 
> seem like a USB spec problem.  I naively assume that if someone wanted to 
> produce a USB-to-Serial adapter that supported the things you're describing 
> that they could do so.  But sadly, I believe that RoI will be on the wrong 
> side of the demand curve.

An Arduino or something of that size can easily do a USB to serial adapter in 
software.  That would let you do any data rate and character length the device 
can so (if you use its UART) or whatever you can generate in bit-banging 
software.  For example, a Raspberry Pico can clearly do any rate you want, 
including strange slow ones or oddballs like 134.5 baud 6 bits (or is that 7 -- 
for the serial line 2741).  45.45 baud 5 level and some strange fractional stop 
bit, not quite 1.5 -- no problem.  10 bit characters (for the classic PLATO 
terminal to host direction) -- no problem.  

paul

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/22/21 9:12 AM, Ethan Dicks via cctalk wrote:
The OP said he meant with "real" connectors, but in my case, 
I've encountered strange buffering issues with USB serial dongles 
(since they are really block-mode devices, not character-at-a-time) 
and I've definitely had problems supporting lines with odd parameters 
(especially speeds slower than 300 baud or with 5-bits-per-char, like 
one would use for a Model 19 or Model 28 teletype).  The hardware UARTs 
on AVR processors implement those juse fine (though for "50 baud", 
you often have to put a slower crystal on the processor because the 
16-bit divisor overflows at 16-20MHz).  The "soft serial" libraries 
often just hard-code 8-bit implementations.  Fine for modern stuff 
but I have uses for connecting to electromechanical serial devices.


These seem like real problems, which can't be overcome by a passive 
physical adapter.


These also seem like implementation problems to me.  At least more than 
they seem like a USB spec problem.  I naively assume that if someone 
wanted to produce a USB-to-Serial adapter that supported the things 
you're describing that they could do so.  But sadly, I believe that RoI 
will be on the wrong side of the demand curve.


In terms of a CRT terminal, though, most modern serial implementations 
are fine.


*nod*



--
Grant. . . .
unix || die

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/22/21 5:26 AM, emanuel stiebler via cctalk wrote:

Why? I love the new ones, as I travel a lot ;-)


The 4k monitors that I've worked with have been ultra high DPI.  This 
means that things that don't have DPI settings end up being tiny on the 
screen.


It's especially a problem if you try to mix non-4k and 4k monitors.


OK, sorry. "Real" is for me here, physically the same connectors like
DB25/DB9/MMJ/etc ...


So how does that differ than a USB-to-RS-232 with the proper passive 
adapter to go from DB-9 to DB-25 / MMJ.


Season to taste regarding DB vs DE.



--
Grant. . . .
unix || die

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/23/21 4:08 PM, Mark Matlock via cctalk wrote:
One VT340 emulator that works quite well is the VT Lan 40. This was 
one of the last terminals made by DEC. It ran Windows 3.1 from ROM 
and used the LK411-AA keyboard (with the round PC keyboard connector) 
displaying on a Super VGA LCD display (1024 x 768 x 16 colors)


It could connect to several (unto 8) systems simultaneously using a 
DB25 serial, a MMJ serial, then over its ethernet connector: multiple 
LAT, CTERM (DECnet) and Telnet (TCP/IP) sessions. The session windows 
allow cut and paste between Windows.


The VT340 emulation seems to be perfect displaying Regis and pixels 
correctly and handling mouse movements correctly in the VT340 mode. 
Output from Saturn Graph for VMS works great!


It also displays APL overstrike characters correctly with VAX APL 
using the ^D prefix described in the APL documentation. It also 
handles some escape sequence quirks that RSX KED does that mess up 
other VT100 emulators.


I think the VT LAN 40 looks super interesting.  Though the mentioned 
price is out of my /want/ range.  Maybe if I /needed/ it.  But I don't 
/need/ it.


I wonder what terminal emulator it's running on top of Windows 3.x.  I'd 
be interested in playing with it on a comparable system.




--
Grant. . . .
unix || die

Re: VT340 Emulation

[Al Kossow via cctalk]

On 6/24/21 12:34 PM, Zane Healy wrote:
paul


Thanks.   That's a crazy high price for what "untested, for parts" with a thick 
coat of dirt.   I find a conventional PC layout good enough for what I need.

paul


Geeze, at that price, do I need to start clearing out my keyboard collection? 


ccmp'ers blissfully ignorant at what keyboard ghouls have done to prices

$70 is cheap for a Cherry kb now

Re: VT340 Emulation

[Zane Healy via cctalk]

On Jun 24, 2021, at 10:11 AM, Paul Koning via cctalk  
wrote:
> 
>> On Jun 24, 2021, at 1:07 PM, Al Kossow via cctalk  
>> wrote:
>> 
>> On 6/24/21 9:06 AM, Paul Koning via cctalk wrote:
>> 
>>> LK201s use 4800 baud UART interfacing.  PC keyboards with DIN connectors 
>>> (PS-2) have a very different type of interface, nothing like a UART.  If 
>>> the terminal you are talking about wants a PS-2 keyboard, as my VT501 does, 
>>> you need a protocol translator.  It would essentially be the reverse of the 
>>> LK201 emulator for PS-2 keyboards I released a while back, and possibly the 
>>> same board could be used with a rather different program running on it.
>>> paul
>> ebay seller wooch22 has been selling cherry wyse ansi layout keyboards that 
>> are restorable, if you want something to convert
>> with the right layout
>> 
>> https://www.ebay.com/itm/313552477333 
> 
> Thanks.   That's a crazy high price for what "untested, for parts" with a 
> thick coat of dirt.   I find a conventional PC layout good enough for what I 
> need.
> 
>   paul

Geeze, at that price, do I need to start clearing out my keyboard collection?  
Nope, not going to do it...

I’m actually in pretty good shape, plenty of LK201’s & LK401’s (from my 
VT320’s, VT420’s, and workstations), plus a couple LK450-AA’s and a PCXAL or 
two.

I’m just not clear on if there is any difference between a LK412-AA and a 
LK450-AA, both have the WPS keycaps, both have the PS/2 style DIN connector.

I do wish I had a couple LK402-AA's (basically a 401 with WPS keycaps).

I also wish I knew why I have two LK450-AA’s. :-)  Though I’m glad I do.

Besides a terminal with ReGIS Graphics, the only other terminal that would 
tempt me is a Honeywell, but then I can connect to Multics from a VT420 just 
fine.

Zane

Re: VT340 Emulation

[Mark Matlock via cctalk]

> On Jun 24, 2021, at 11:06 AM, Paul Koning  wrote:
> 
> LK201s use 4800 baud UART interfacing.  PC keyboards with DIN connectors 
> (PS-2) have a very different type of interface, nothing like a UART.  If the 
> terminal you are talking about wants a PS-2 keyboard, as my VT501 does, you 
> need a protocol translator.  It would essentially be the reverse of the LK201 
> emulator for PS-2 keyboards I released a while back, and possibly the same 
> board could be used with a rather different program running on it.
> 
>   paul

Paul,
   The VT LAN 40 does use the PS-2 keyboard protocol like the VT501. The main 
board
of the unit is a PC mother board running Windows 3.1 from ROM. It has some 
amount of
non-volatile memory to store session settings.

   It does sound like a protocol translator like you design but in reverse 
would allow the
older more common VT keyboard to be used.

Mark

Re: VT340 Emulation

[Mark Matlock via cctalk]

> On Jun 24, 2021, at 9:36 AM, Zane Healy  wrote:
> 
> Hi Mark,
> Thanks!  That’s not bad at all considering what VT525’s are going for, and 
> I’d really like to get a terminal with ReGIS Graphics (though I finally have 
> a VAXstation 4000/90 running as a VAXstation).  Mind you, I’m not sure why I 
> need one. 
> 
> I wonder if an LK450-AA keyboard will work, I have a couple with WPS 
> key-caps.  I know those will work on an AlphaStation.  The VTLAN40 page 
> indicates it needs a LK412-AQ for the WPS version of the keyboard, so i’d 
> probably better figure that in the cost.  This makes me wonder, has anyone 
> ever documented what all the different keyboards go to, and how they’re 
> different?
> 
> I’m more awake this morning, and took another look through the webpage, this 
> time on my computer, rather than an iPod.  This looks like the perfect 
> replacement for the VT420 & DECserver 90TL in my Office.  The ReGIS graphics 
> helps to sell it.  Most of the time I simply use SecureCRT on my Mac Pro, but 
> occasionally I need a real DEC keyboard.
> 
> Zane

Zane,
Does the LK450-AA keyboard have a round 6 conductor PS/2 style connector? 
If so I think it would work.
I looked up a pin out for that PS/2 connector and Pin 1 is data, Pin 2 is 
ground, Pin 4 is +5V, and Pin 5 is Clock
with Pins 2 and 6 not used. I suspect that a common cheap PS/2 keyboard would 
also work fine except that
keyboard mapping especially the keypad needed for EDT, KED, etc. might not work 
quite right.

I do think this would make a great replacement for a VT420 and DECserver as 
few terminal emulators do LAT
although Reflection did in the past. My favorite Mac VT terminal editor at the 
moment is ZOC which continues to
get better with each update (although no VT340).

   I’ll send you a .pdf of the user manual for the VT LAN 40 separately that 
will give you a better picture of the unit.

Best,
Mark

  

Re: VT340 Emulation

[Paul Koning via cctalk]

> On Jun 24, 2021, at 1:07 PM, Al Kossow via cctalk  
> wrote:
> 
> On 6/24/21 9:06 AM, Paul Koning via cctalk wrote:
> 
>> LK201s use 4800 baud UART interfacing.  PC keyboards with DIN connectors 
>> (PS-2) have a very different type of interface, nothing like a UART.  If the 
>> terminal you are talking about wants a PS-2 keyboard, as my VT501 does, you 
>> need a protocol translator.  It would essentially be the reverse of the 
>> LK201 emulator for PS-2 keyboards I released a while back, and possibly the 
>> same board could be used with a rather different program running on it.
>>  paul
> ebay seller wooch22 has been selling cherry wyse ansi layout keyboards that 
> are restorable, if you want something to convert
> with the right layout
> 
> https://www.ebay.com/itm/313552477333 

Thanks.   That's a crazy high price for what "untested, for parts" with a thick 
coat of dirt.   I find a conventional PC layout good enough for what I need.

paul

Re: VT340 Emulation

[Al Kossow via cctalk]

On 6/24/21 9:06 AM, Paul Koning via cctalk wrote:


LK201s use 4800 baud UART interfacing.  PC keyboards with DIN connectors (PS-2) 
have a very different type of interface, nothing like a UART.  If the terminal 
you are talking about wants a PS-2 keyboard, as my VT501 does, you need a 
protocol translator.  It would essentially be the reverse of the LK201 emulator 
for PS-2 keyboards I released a while back, and possibly the same board could 
be used with a rather different program running on it.

paul



ebay seller wooch22 has been selling cherry wyse ansi layout keyboards that are 
restorable, if you want something to convert
with the right layout

https://www.ebay.com/itm/313552477333

Re: VT340 Emulation

[emanuel stiebler via cctalk]

On 2021-06-24 10:36, Zane Healy via cctalk wrote:

> Thanks!  That’s not bad at all considering what VT525’s are going for, and 
> I’d really like to get a terminal with ReGIS Graphics (though I finally have 
> a VAXstation 4000/90 running as a VAXstation).  Mind you, I’m not sure why I 
> need one. 

If you just need Regis, get a GIGI, keyboard built in ;-)

Re: VT340 Emulation

[Paul Koning via cctalk]

> On Jun 24, 2021, at 9:30 AM, Mark Matlock via cctalk  
> wrote:
> 
> 
>> On Jun 24, 2021, at 1:25 AM, Zane Healy  wrote:
>> 
>> And all this time I thought that I wanted a VT525!  How much are the 
>> VTLAN40’s going for?
>> 
>> Zane 
> 
> Zane,
>If you explain to Mitch Miller at Keyways that you are a hobbyist, he will 
> sell them for $400,
> at least he has in the past. He also has new and used LK411-AA keyboards. The 
> last one I
> bought was $190 for new. That seems expensive but it has the round connector 
> like a PC
> used to used for keyboard before USB. It might be possible to make an adapter 
> to convert
> an old VT420 keyboard to the round connector if one knew how the pin outs for 
> each mapped?

LK201s use 4800 baud UART interfacing.  PC keyboards with DIN connectors (PS-2) 
have a very different type of interface, nothing like a UART.  If the terminal 
you are talking about wants a PS-2 keyboard, as my VT501 does, you need a 
protocol translator.  It would essentially be the reverse of the LK201 emulator 
for PS-2 keyboards I released a while back, and possibly the same board could 
be used with a rather different program running on it.

paul

Re: VT340 Emulation

[Mark Matlock via cctalk]

> On Jun 24, 2021, at 1:25 AM, Zane Healy  wrote:
> 
> And all this time I thought that I wanted a VT525!  How much are the 
> VTLAN40’s going for?
> 
> Zane 

Zane,
If you explain to Mitch Miller at Keyways that you are a hobbyist, he will 
sell them for $400,
at least he has in the past. He also has new and used LK411-AA keyboards. The 
last one I
bought was $190 for new. That seems expensive but it has the round connector 
like a PC
used to used for keyboard before USB. It might be possible to make an adapter 
to convert
an old VT420 keyboard to the round connector if one knew how the pin outs for 
each mapped?

  On the SVGA displays, I’ve been using the NEC Accusync LCD 71VM and it works 
well.
As the unit comes it will operate at 800 x 600 256 color, but if you go to the 
Windows 3.1 
settings it can be changed to 1024 x 768 x 16 colors which works better to have 
multiple 
sessions windows open at once.

Mark

Re: VT340 Emulation

[Zane Healy via cctalk]

On Jun 24, 2021, at 6:30 AM, Mark Matlock  wrote:
> On Jun 24, 2021, at 1:25 AM, Zane Healy  wrote:
>> 
>> And all this time I thought that I wanted a VT525!  How much are the 
>> VTLAN40’s going for?
>> 
>> Zane 
> 
> Zane,
>If you explain to Mitch Miller at Keyways that you are a hobbyist, he will 
> sell them for $400,
> at least he has in the past. He also has new and used LK411-AA keyboards. The 
> last one I
> bought was $190 for new. That seems expensive but it has the round connector 
> like a PC
> used to used for keyboard before USB. It might be possible to make an adapter 
> to convert
> an old VT420 keyboard to the round connector if one knew how the pin outs for 
> each mapped?
> 
>  On the SVGA displays, I’ve been using the NEC Accusync LCD 71VM and it works 
> well.
> As the unit comes it will operate at 800 x 600 256 color, but if you go to 
> the Windows 3.1 
> settings it can be changed to 1024 x 768 x 16 colors which works better to 
> have multiple 
> sessions windows open at once.
> 
> Mark

Hi Mark,
Thanks!  That’s not bad at all considering what VT525’s are going for, and I’d 
really like to get a terminal with ReGIS Graphics (though I finally have a 
VAXstation 4000/90 running as a VAXstation).  Mind you, I’m not sure why I need 
one. 

I wonder if an LK450-AA keyboard will work, I have a couple with WPS key-caps.  
I know those will work on an AlphaStation.  The VTLAN40 page indicates it needs 
a LK412-AQ for the WPS version of the keyboard, so i’d probably better figure 
that in the cost.  This makes me wonder, has anyone ever documented what all 
the different keyboards go to, and how they’re different?

I’m more awake this morning, and took another look through the webpage, this 
time on my computer, rather than an iPod.  This looks like the perfect 
replacement for the VT420 & DECserver 90TL in my Office.  The ReGIS graphics 
helps to sell it.  Most of the time I simply use SecureCRT on my Mac Pro, but 
occasionally I need a real DEC keyboard.

Zane

Re: VT340 Emulation

[Zane Healy via cctalk]

And all this time I thought that I wanted a VT525!  How much are the VTLAN40’s 
going for?

Zane 



Sent from my iPod

> On Jun 23, 2021, at 3:08 PM, Mark Matlock via cctalk  
> wrote:
> 
>   One VT340 emulator that works quite well is the VT Lan 40. This was one
> of the last terminals made by DEC. It ran Windows 3.1 from ROM and
> used the LK411-AA keyboard (with the round PC keyboard connector) 
> displaying on a Super VGA LCD display (1024 x 768 x 16 colors)
> 
>  It could connect to several (unto 8) systems simultaneously using a 
> DB25 serial, a MMJ serial, then over its ethernet connector: multiple LAT, 
> CTERM (DECnet) and Telnet (TCP/IP) sessions. The session windows allow 
> cut and paste between Windows.
> 
>   The VT340 emulation seems to be perfect displaying Regis and pixels 
> correctly and handling mouse movements correctly in the VT340 mode. 
> Output from Saturn Graph for VMS works great!
> 
>  It also displays APL overstrike characters correctly with VAX APL using 
> the ^D prefix described in the APL documentation. It also handles some 
> escape sequence quirks that RSX KED does that mess up other VT100
> emulators.
> 
>   Being able to use a Super VGA display allows a small footprint compared to 
> a 
> real VT340 (for VCF events) and the fact that it uses a real LK411 keyboard 
> is great.
> 
>   The only minor issue is that they are not cheap, but you can buy 
> new-in-thebox
> old inventory at:
> 
> http://keyways.com/vtlan40.html
> 
>   You’ll also need a VT411-AA keyboard sold separately and find a Super VGA 
> LCD display. Fortunately the last item can be cheap. I got a good NEC one at 
> a 
> second hand store for $20.
> 
>   One final comment, the two VT Lan 40s I got eventually had a connector 
> between the front power switch and the actual switch break due to a bad 
> choice of plastic by DEC. However, this can easily be repaired with a 1” 
> piece 
> of 1/8” I.D. PVC tubing from the hardware store.
> 
> Mark Matlock

Re: VT340 Emulation

[Mark Matlock via cctalk]

   One VT340 emulator that works quite well is the VT Lan 40. This was one
of the last terminals made by DEC. It ran Windows 3.1 from ROM and
used the LK411-AA keyboard (with the round PC keyboard connector) 
displaying on a Super VGA LCD display (1024 x 768 x 16 colors)

  It could connect to several (unto 8) systems simultaneously using a 
DB25 serial, a MMJ serial, then over its ethernet connector: multiple LAT, 
CTERM (DECnet) and Telnet (TCP/IP) sessions. The session windows allow 
cut and paste between Windows.

   The VT340 emulation seems to be perfect displaying Regis and pixels 
correctly and handling mouse movements correctly in the VT340 mode. 
Output from Saturn Graph for VMS works great!

  It also displays APL overstrike characters correctly with VAX APL using 
the ^D prefix described in the APL documentation. It also handles some 
escape sequence quirks that RSX KED does that mess up other VT100
emulators.

   Being able to use a Super VGA display allows a small footprint compared to a 
real VT340 (for VCF events) and the fact that it uses a real LK411 keyboard is 
great.

   The only minor issue is that they are not cheap, but you can buy 
new-in-thebox
old inventory at:

http://keyways.com/vtlan40.html

   You’ll also need a VT411-AA keyboard sold separately and find a Super VGA 
LCD display. Fortunately the last item can be cheap. I got a good NEC one at a 
second hand store for $20.

   One final comment, the two VT Lan 40s I got eventually had a connector 
between the front power switch and the actual switch break due to a bad 
choice of plastic by DEC. However, this can easily be repaired with a 1” piece 
of 1/8” I.D. PVC tubing from the hardware store.

 Mark Matlock

Re: VT340 Emulation

[Christian Corti via cctalk]

On Mon, 21 Jun 2021, Ethan Dicks wrote:

I would love some sample ReGIS files, color or B  Anything, really.


You can use GNUplot with the terminal type set to ReGIS.

Christian

Re: ARDS was Re: VT340 Emulation

[Lars Brinkhoff via cctalk]

Steve Malikoff wrote:
> Douglas said
>> Someone already did this with a TEK4010 emulation:  See
>> https://github.com/rricharz/Tek4010
>> Hmmm... You could use a Raspberry Pi to emulate a number of terminals.
>
> Interesting that that emulator covers the ARDS.

I collected some notes about ARDS as relating to the ITS operating system:
https://github.com/PDP-10/its/issues/821

ARDS was Re: VT340 Emulation

[Steve Malikoff via cctalk]

Douglas said
> Someone already did this with a TEK4010 emulation:  See
>
> https://github.com/rricharz/Tek4010
>
> Hmmm... You could use a Raspberry Pi to emulate a number of terminals.

Interesting that that emulator covers the ARDS.

Surely there can't have been too many graphics terminals for general sale in 
the 1960s that
had a mouse, but the ARDS was one of them.
Here's an ad for it on page 17, Datamation December 1969:
https://archive.org/details/bitsavers_datamation_42955706/page/n17/mode/2up

Steve.

Re: VT340 Emulation

[Douglas Taylor via cctalk]

Someone already did this with a TEK4010 emulation:  See

https://github.com/rricharz/Tek4010

Hmmm... You could use a Raspberry Pi to emulate a number of terminals.

Doug

On 6/22/2021 3:49 AM, emanuel stiebler via cctalk wrote:

On 2021-06-22 01:03, Grant Taylor via cctalk wrote:


I'm now wondering about building something like a Raspberry Pi with an
LCD display (native resolution?)

Be careful. The "native" resolution of the vt340 is 800x480 in 4:3
format ...

So I would use an 15" 4K display at the RBpi, and scale up...

Imagine a Tekronox Emulation on a 4K display ;-)


in a custom case that's stylaized after
the VT340 (?) case, all be it abbreviated so that it's much shallower.
I'd probably simply run a full screen XTerm without any window manager.
(I might have a different way to start with a window manager and
traditional GUI.)
I could support serial, but if I'm using an SBC, why not use Ethernet
(or even WiFI)???

I would love to see REAL RS232 on a RBPi, probably even the original MMJ
from DEC for keyboard & mouse

Re: VT340 Emulation

[Paul Koning via cctalk]

> On Jun 22, 2021, at 12:57 PM, Zane Healy  wrote:
> 
> 
> 
>> On Jun 22, 2021, at 6:19 AM, Paul Koning via cctalk  
>> wrote:
>> 
 Imagine a Tekronox Emulation on a 4K display ;-)
>> 
>> Like a Tek 4019?  I remember seeing those in Typeset-11, amazing.
> 
> That brings up an interesting question, how good is a 4K display for 
> emulating vector graphics?

Assuming you can feed such a display a video signal that actually represents 4k 
worth of pixels, without compression, it should be quite decent for vector 
graphics up to 11 bit x/y resolution or so.  I have a CDC console (DD60) 
emulation, that's a 512x512 display with vector characters, which looks good on 
the 1k resolution laptop screen.  Not so good before I started using the 
"Retina" mode and was only getting 512 pixel resolution; with that the pixel 
artefacts were quite visible and somewhat annoying.

Depending on the API of the vector system, the hard part may be to create an 
adequate emulation of display persistence and fade. If the vector machine has a 
well defined refresh cycle that's probably straightforward (just display what 
the current display list says).  If the graphics primitives simply amount to 
"send a stream of vectors to the tube" as is the case for the DD60, then you 
have to track elapsed time and fade the older pixels -- possibly with the help 
of an inferred display refresh cycle that isn't expressed in the data stream.  

paul

Re: VT340 Emulation

[Zane Healy via cctalk]

> On Jun 22, 2021, at 6:19 AM, Paul Koning via cctalk  
> wrote:
> 
>>> Imagine a Tekronox Emulation on a 4K display ;-)
> 
> Like a Tek 4019?  I remember seeing those in Typeset-11, amazing.

That brings up an interesting question, how good is a 4K display for emulating 
vector graphics?

Zane

Re: VT340 Emulation

[Ethan Dicks via cctalk]

On Tue, Jun 22, 2021 at 6:32 AM Grant Taylor via cctalk
 wrote:
> > I would love to see REAL RS232 on a RBPi, probably even the original
> > MMJ from DEC for keyboard & mouse
>
> What is a /real/ RS-232?  How does it differ from USB-to-RS-232 and / or
> bit banging GPIO lines?

The OP said he meant with "real" connectors, but in my case, I've
encountered strange buffering issues with USB serial dongles (since
they are really block-mode devices, not character-at-a-time) and I've
definitely had problems supporting lines with odd parameters
(especially speeds slower than 300 baud or with 5-bits-per-char, like
one would use for a Model 19 or Model 28 teletype).  The hardware
UARTs on AVR processors implement those juse fine (though for "50
baud", you often have to put a slower crystal on the processor because
the 16-bit divisor overflows at 16-20MHz).  The "soft serial"
libraries often just hard-code 8-bit implementations.  Fine for modern
stuff but I have uses for connecting to electromechanical serial
devices.

In terms of a CRT terminal, though, most modern serial implementations are fine.

-ethan

Re: VT340 Emulation

[Paul Koning via cctalk]

> On Jun 22, 2021, at 6:32 AM, Grant Taylor via cctalk  
> wrote:
> 
> On 6/22/21 1:49 AM, emanuel stiebler via cctalk wrote:
>> Be careful. The "native" resolution of the vt340 is 800x480 in 4:3 format ...
> 
> 800x480 isn't 4:3 aspect, like VGA 640x480 / SVGA 800x600 / XGA (?) 1024x768. 
>  But I suppose the aspect ratio can be the area that the pixels cover, not 
> the actual pixel matrix.

Some DEC displays use non-square pixels.  An example (annoying because I've 
been wanting to connect to a modern display) is the Pro, which has a max 
resolution of 1024 by 480, on a 4:3 tube.

> ...
>> Imagine a Tekronox Emulation on a 4K display ;-)

Like a Tek 4019?  I remember seeing those in Typeset-11, amazing.

paul

Re: VT340 Emulation

[emanuel stiebler via cctalk]

On 2021-06-22 06:32, Grant Taylor via cctalk wrote:
> On 6/22/21 1:49 AM, emanuel stiebler via cctalk wrote:

>> So I would use an 15" 4K display at the RBpi, and scale up...
> 
> I personally dislike all the 4k monitors that I've seen.  I'd be more
> likely to go old school.

Why? I love the new ones, as I travel a lot ;-)

>> Imagine a Tekronix Emulation on a 4K display ;-)
> 
> ~chuckle~

;-)

>> I would love to see REAL RS232 on a RBPi, probably even the original
>> MMJ from DEC for keyboard & mouse
> 
> What is a /real/ RS-232?  How does it differ from USB-to-RS-232 and / or
> bit banging GPIO lines?

OK, sorry. "Real" is for me here, physically the same connectors like
DB25/DB9/MMJ/etc ...

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/22/21 1:49 AM, emanuel stiebler via cctalk wrote:
Be careful. The "native" resolution of the vt340 is 800x480 in 4:3 
format ...


800x480 isn't 4:3 aspect, like VGA 640x480 / SVGA 800x600 / XGA (?) 
1024x768.  But I suppose the aspect ratio can be the area that the 
pixels cover, not the actual pixel matrix.


Your point is noted.  Though I don't know if an improper resolution 
would make that much difference to me in my use case.  But I'm not 
chasing an authentic experience.  Rather I am after something neat / 
nifty / quaint, much like the PiCade is not a real arcade cabinet.



So I would use an 15" 4K display at the RBpi, and scale up...


I personally dislike all the 4k monitors that I've seen.  I'd be more 
likely to go old school.



Imagine a Tekronox Emulation on a 4K display ;-)


~chuckle~

I would love to see REAL RS232 on a RBPi, probably even the original 
MMJ from DEC for keyboard & mouse


What is a /real/ RS-232?  How does it differ from USB-to-RS-232 and / or 
bit banging GPIO lines?




--
Grant. . . .
unix || die

Re: VT340 Emulation

[emanuel stiebler via cctalk]

On 2021-06-22 01:03, Grant Taylor via cctalk wrote:

> I'm now wondering about building something like a Raspberry Pi with an
> LCD display (native resolution?) 

Be careful. The "native" resolution of the vt340 is 800x480 in 4:3
format ...

So I would use an 15" 4K display at the RBpi, and scale up...

Imagine a Tekronox Emulation on a 4K display ;-)

> in a custom case that's stylaized after
> the VT340 (?) case, all be it abbreviated so that it's much shallower.
> I'd probably simply run a full screen XTerm without any window manager.
> (I might have a different way to start with a window manager and
> traditional GUI.)

> I could support serial, but if I'm using an SBC, why not use Ethernet
> (or even WiFI)???

I would love to see REAL RS232 on a RBPi, probably even the original MMJ
from DEC for keyboard & mouse

Re: VT340 Emulation

[emanuel stiebler via cctalk]

On 2021-06-22 01:03, Grant Taylor via cctalk wrote:

> After seeing the prices of VT3xx / VT4xx / VT5xx when I looked a few
> years ago, I quickly decided that I didn't want to spend that sort of
> money.

And, if you get a cheap VT340, it probably is just an "A", not a "G+"
version :(

Re: VT340 Emulation

[Ethan Dicks via cctalk]

On Mon, Jun 21, 2021 at 11:14 PM Douglas Taylor via cctalk
 wrote:
> Wow, that is very helpful.  I had downloaded xterm from
> invisible-island.net and executed a ./configure.  I complained that I
> lacked the Athena X widgets, so I paused on it.

I got that.  On a RHEL7 box, I did:

$ sudo yum install libXaw-devel.x86_64

It built cleanly.  I'm about to test it.

-ethan

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/21/21 10:35 PM, Douglas Taylor via cctalk wrote:
DECterm does allow graphics.  I've used it, but can't remember the 
details.


:-)


For me the options were:

1. get a real VT340, already have a VT240


I've occasionally wondered about getting a VT340 (or VT4xx / VT5xx). 
But then I look at prices and realize that I'd be chasing this for the 
wrong reasons.  --  Especially when I think I could get what I want 
other ways.



2. emulation software on a PC


After seeing the prices of VT3xx / VT4xx / VT5xx when I looked a few 
years ago, I quickly decided that I didn't want to spend that sort of money.


I'm now wondering about building something like a Raspberry Pi with an 
LCD display (native resolution?) in a custom case that's stylaized after 
the VT340 (?) case, all be it abbreviated so that it's much shallower. 
I'd probably simply run a full screen XTerm without any window manager. 
(I might have a different way to start with a window manager and 
traditional GUI.)


I could support serial, but if I'm using an SBC, why not use Ethernet 
(or even WiFI)???


3. DECterm, not a great option, works but if you want to use it remote 
the hardware multiplys


Pleas elaborate and enlighten this DEC n00b?

Aside:  Does PATHWORKS include a DEC terminal emulator?  If so, does it 
support graphics?  Could it be made to run on contemporary systems?



4. xterm, this was new to me, easy under linux


:-)

I'd hop it to be relatively easy under any Unix (like) operating system.



--
Grant. . . .
unix || die

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/21/21 9:33 PM, Zane Healy via cctalk wrote:
I have to admit, I’m watching this with interest.  Hopefully I can 
see about getting this up and running one of these days.


I too keep an eye out for things XTerm / Sixel (raster?) / ReGIS 
(vector) related.  I learned about Sixel first, became quite interested, 
and then about ReGIS.


I've since learned about GDM (?term?) graphics on 3279 (?model?) on 
mainframes.  I've not yet managed to reproduce this myself, but I've 
seen pictures.


I hope this goes without needing to be said, but for people reading this 
archive in the future, we're talking about the terminal actually 
supporting and displaying graphics, not some pseudo overlay / alpha 
background that some more mainstream terminal emulators use.


I find myself wondering what it would take to build this on a Mac, 
the current Mac xterm *SUCKS*!!!  On the Mac, I can’t seem to use 
the custom DEC keybindings.


XTerm on macOS?  Please tell me more.  I'm currently using iTerm2 as 
it's considerably better than Terminal from Apple.  Though, it does seem 
as if iTerm2 supports Sixel.  I think I heard some noise about ReGIS 
support in future versions.  (I think it was ReGIS.  Maybe it was that 
Sixel was coming when I last read about it.)


Actually does DECterm support either Sixel and ReGIS?  I’m dead on 
my feet, so won’t power up my VAXstation 4000/90 and look.


I'm not up on DEC software.  I think that there is a full DEC terminal 
emulator that some versions of may support graphics, though I don't know 
what type.  I think there was also an XTerm profile / nickname that 
included DEC.  (Or am conflating AIXterm?)




--
Grant. . . .
unix || die

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/21/21 6:10 PM, Ethan Dicks via cctalk wrote:

I would love some sample ReGIS files, color or B  Anything, really.


Here's the (relatively) simple ReGIS (.rgs) file that I made, modeled 
after something I saw on Twitter.


I'm copying and pasting the ReGIS file because it's mostly printable 
text.  The only exception is that "^[" on the first and last line are 
really the ASCII representation of the escape character.


--8<--
^[P1p;
W(I3);
F(
^IP[130,362]
^IV[312,44]
^IV[450,287]
^IV[372,287]
^IV[312,187]
^IV[170,430]
^IV[130,362]
);
W(I1);
F(
^IP[312,44]
^IV[390,44]
^IV[572,362]
^IV[292,362]
^IV[329,287]
^IV[450,287]
^IV[312,44]
);
W(I2);
F(
^IP[572,362]
^IV[532,430]
^IV[170,430]
^IV[312,187]
^IV[352,255]
^IV[292,362]
^IV[572,362]
);
^[\
-->8--

If it looks relatively simple, that's because it's three (identical, but 
rotated) shapes consisting of six points returning to the 1st to close 
the shape.  From memory, it enters ReGIS mode, sets a color, defines the 
shape to be filled, and repeats.



Thanks!


You're welcome.

I'll happily email anybody copies of the ReGIS file(s) and / or Sixel 
file(s) that I have.  Simply let me know that you'd like a copy. 
(Please email me directly instead of sending me too(s) to the list.)


Teas:  My one of my two favorite Sixels is a TRON tank.

P.S.  I've configured answer backs on my main systems and plumbed the 
skeleton into my rc files to allow the systems to know if the client 
(based on answer back of known systems) supports Sixel / ReGIS.  I have 
grand ideas of making Zsh conditionally display a stop sign if / when $? 
is not zero.  Maybe a yellow attention triangle with an exclamation 
point.  }:-)




--
Grant. . . .
unix || die

Re: VT340 Emulation

[Douglas Taylor via cctalk]

DECterm does allow graphics.  I've used it, but can't remember the details.

For me the options were:

1. get a real VT340, already have a VT240
2. emulation software on a PC
3. DECterm, not a great option, works but if you want to use it remote 
the hardware multiplys

4. xterm, this was new to me, easy under linux

Doug

On 6/21/2021 11:33 PM, Zane Healy via cctalk wrote:

I have to admit, I’m watching this with interest.  Hopefully I can see about 
getting this up and running one of these days.

I find myself wondering what it would take to build this on a Mac, the current 
Mac xterm *SUCKS*!!!  On the Mac, I can’t seem to use the custom DEC 
keybindings.

Actually does DECterm support either Sixel and ReGIS?  I’m dead on my feet, so 
won’t power up my VAXstation 4000/90 and look.

Zane




On Jun 21, 2021, at 8:13 PM, Douglas Taylor via cctalk  
wrote:

Grant;

Wow, that is very helpful.  I had downloaded xterm from invisible-island.net 
and executed a ./configure.  I complained that I lacked the Athena X widgets, 
so I paused on it.

I'm going to give this another try.

I'd like to thank all the kind folks who posted a response to my initial 
question.

Doug

On 6/20/2021 6:06 PM, Grant Taylor via cctalk wrote:

On 6/19/21 11:47 AM, Douglas Taylor via cctalk wrote:

Really?  I'm interested.  How do you build your own xterm?

Download and extract the source code.

Here's the configure command that I most recently used before teaching Gentoo's 
ebuild about Sixel and ReGIS.  (The command is derived from the ebuild I was 
patterning off of.)

./configure --build=x86_64-pc-linux-gnu --datadir=/usr/share 
--disable-full-tgetent --disable-imake --disable-setgid --disable-setuid 
--disable-toolbar --enable-256-color --enable-broken-osc --enable-broken-st 
--enable-dabbrev --enable-exec-xterm --enable-i18n --enable-load-vt-fonts 
--enable-logging --enable-luit --enable-mini-luit --enable-openpty 
--enable-regis-graphics --enable-screen-dumps --enable-sixel-graphics 
--enable-warnings --enable-wide-chars --host=x86_64-pc-linux-gnu 
--infodir=/usr/share/info --libdir=/etc --localstatedir=/var/lib 
--mandir=/usr/share/man --prefix=/usr --sysconfdir=/etc 
--with-app-defaults=/usr/share/X11/app-defaults --without-Xaw3d 
--without-xinerama --with-utempter --with-x

The key part is "--enable-sixel-graphics" and / or "--enable-regis-graphics".  I'm also partial to 
the "--enable-256-color" and "--enable-screen-dumps".

The screen dumps mean that XTerm will save XHTML and / or XML dumps. Meaning 
they are text that you can search / copy paste. }:-)

P.S.  My messages to cctech don't seem to be going through.  So I'm re-replying 
to the message to cctalk.

Re: VT340 Emulation

[Zane Healy via cctalk]

I have to admit, I’m watching this with interest.  Hopefully I can see about 
getting this up and running one of these days.

I find myself wondering what it would take to build this on a Mac, the current 
Mac xterm *SUCKS*!!!  On the Mac, I can’t seem to use the custom DEC 
keybindings.

Actually does DECterm support either Sixel and ReGIS?  I’m dead on my feet, so 
won’t power up my VAXstation 4000/90 and look.

Zane



> On Jun 21, 2021, at 8:13 PM, Douglas Taylor via cctalk 
>  wrote:
> 
> Grant;
> 
> Wow, that is very helpful.  I had downloaded xterm from invisible-island.net 
> and executed a ./configure.  I complained that I lacked the Athena X widgets, 
> so I paused on it.
> 
> I'm going to give this another try.
> 
> I'd like to thank all the kind folks who posted a response to my initial 
> question.
> 
> Doug
> 
> On 6/20/2021 6:06 PM, Grant Taylor via cctalk wrote:
>> On 6/19/21 11:47 AM, Douglas Taylor via cctalk wrote:
>>> Really?  I'm interested.  How do you build your own xterm?
>> 
>> Download and extract the source code.
>> 
>> Here's the configure command that I most recently used before teaching 
>> Gentoo's ebuild about Sixel and ReGIS.  (The command is derived from the 
>> ebuild I was patterning off of.)
>> 
>> ./configure --build=x86_64-pc-linux-gnu --datadir=/usr/share 
>> --disable-full-tgetent --disable-imake --disable-setgid --disable-setuid 
>> --disable-toolbar --enable-256-color --enable-broken-osc --enable-broken-st 
>> --enable-dabbrev --enable-exec-xterm --enable-i18n --enable-load-vt-fonts 
>> --enable-logging --enable-luit --enable-mini-luit --enable-openpty 
>> --enable-regis-graphics --enable-screen-dumps --enable-sixel-graphics 
>> --enable-warnings --enable-wide-chars --host=x86_64-pc-linux-gnu 
>> --infodir=/usr/share/info --libdir=/etc --localstatedir=/var/lib 
>> --mandir=/usr/share/man --prefix=/usr --sysconfdir=/etc 
>> --with-app-defaults=/usr/share/X11/app-defaults --without-Xaw3d 
>> --without-xinerama --with-utempter --with-x
>> 
>> The key part is "--enable-sixel-graphics" and / or 
>> "--enable-regis-graphics".  I'm also partial to the "--enable-256-color" and 
>> "--enable-screen-dumps".
>> 
>> The screen dumps mean that XTerm will save XHTML and / or XML dumps. Meaning 
>> they are text that you can search / copy paste. }:-)
>> 
>> P.S.  My messages to cctech don't seem to be going through.  So I'm 
>> re-replying to the message to cctalk.
>> 
>> 
>> 
> 

Re: VT340 Emulation

[Douglas Taylor via cctalk]

Grant;

Wow, that is very helpful.  I had downloaded xterm from 
invisible-island.net and executed a ./configure.  I complained that I 
lacked the Athena X widgets, so I paused on it.


I'm going to give this another try.

I'd like to thank all the kind folks who posted a response to my initial 
question.


Doug

On 6/20/2021 6:06 PM, Grant Taylor via cctalk wrote:

On 6/19/21 11:47 AM, Douglas Taylor via cctalk wrote:

Really?  I'm interested.  How do you build your own xterm?


Download and extract the source code.

Here's the configure command that I most recently used before teaching 
Gentoo's ebuild about Sixel and ReGIS.  (The command is derived from 
the ebuild I was patterning off of.)


./configure --build=x86_64-pc-linux-gnu --datadir=/usr/share 
--disable-full-tgetent --disable-imake --disable-setgid 
--disable-setuid --disable-toolbar --enable-256-color 
--enable-broken-osc --enable-broken-st --enable-dabbrev 
--enable-exec-xterm --enable-i18n --enable-load-vt-fonts 
--enable-logging --enable-luit --enable-mini-luit --enable-openpty 
--enable-regis-graphics --enable-screen-dumps --enable-sixel-graphics 
--enable-warnings --enable-wide-chars --host=x86_64-pc-linux-gnu 
--infodir=/usr/share/info --libdir=/etc --localstatedir=/var/lib 
--mandir=/usr/share/man --prefix=/usr --sysconfdir=/etc 
--with-app-defaults=/usr/share/X11/app-defaults --without-Xaw3d 
--without-xinerama --with-utempter --with-x


The key part is "--enable-sixel-graphics" and / or 
"--enable-regis-graphics".  I'm also partial to the 
"--enable-256-color" and "--enable-screen-dumps".


The screen dumps mean that XTerm will save XHTML and / or XML dumps. 
Meaning they are text that you can search / copy paste. }:-)


P.S.  My messages to cctech don't seem to be going through.  So I'm 
re-replying to the message to cctalk.

Re: VT340 Emulation

[Ethan Dicks via cctalk]

On Mon, Jun 21, 2021 at 4:12 PM Grant Taylor via cctalk
 wrote:
> On 6/21/21 1:07 AM, Ethan Dicks via cctalk wrote:
> > I'm not the OP, but I'm interested in fiddling with ReGIS a little.
> > I just pulled out my VS240 and fired it up.  Right now, I have a
> > VR201 on it, but I also have a VR241 for it as well.
>
> Let me know if you would like some sample ReGIS files.  I have a few of
> them at hand.  I even managed to create one by hand with little effort.

I would love some sample ReGIS files, color or B  Anything, really.

Thanks!

-ethan

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/21/21 1:07 AM, Ethan Dicks via cctalk wrote:
I'm not the OP, but I'm interested in fiddling with ReGIS a little. 
I just pulled out my VS240 and fired it up.  Right now, I have a 
VR201 on it, but I also have a VR241 for it as well.


Nice.

Let me know if you would like some sample ReGIS files.  I have a few of 
them at hand.  I even managed to create one by hand with little effort.




--
Grant. . . .
unix || die

Re: VT340 Emulation

[Ethan Dicks via cctalk]

On Mon, Jun 21, 2021 at 2:47 AM Grant Taylor via cctalk
 wrote:
> On 6/18/21 5:50 PM, Wayne S via cctech wrote:
> > We didn't really need Regis graphics so we never tested that out.
>
> I'm not sure what the OP's use case is, but if they / you are wanting
> ReGIS (or Sixel) graphics, XTerm supports (both of) them.

I'm not the OP, but I'm interested in fiddling with ReGIS a little.  I
just pulled out my VS240 and fired it up.  Right now, I have a VR201
on it, but I also have a VR241 for it as well.

-ethan

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/18/21 5:50 PM, Wayne S via cctech wrote:

We didn't really need Regis graphics so we never tested that out.


I'm not sure what the OP's use case is, but if they / you are wanting 
ReGIS (or Sixel) graphics, XTerm supports (both of) them.


Incidentally, I have my XTerm configured to set it's decTerminalID to vt340.



--
Grant. . . .
unix || die

Re: VT340 Emulation

[Grant Taylor via cctalk]

On 6/19/21 11:47 AM, Douglas Taylor via cctalk wrote:

Really?  I'm interested.  How do you build your own xterm?


Download and extract the source code.

Here's the configure command that I most recently used before teaching 
Gentoo's ebuild about Sixel and ReGIS.  (The command is derived from the 
ebuild I was patterning off of.)


./configure --build=x86_64-pc-linux-gnu --datadir=/usr/share 
--disable-full-tgetent --disable-imake --disable-setgid --disable-setuid 
--disable-toolbar --enable-256-color --enable-broken-osc 
--enable-broken-st --enable-dabbrev --enable-exec-xterm --enable-i18n 
--enable-load-vt-fonts --enable-logging --enable-luit --enable-mini-luit 
--enable-openpty --enable-regis-graphics --enable-screen-dumps 
--enable-sixel-graphics --enable-warnings --enable-wide-chars 
--host=x86_64-pc-linux-gnu --infodir=/usr/share/info --libdir=/etc 
--localstatedir=/var/lib --mandir=/usr/share/man --prefix=/usr 
--sysconfdir=/etc --with-app-defaults=/usr/share/X11/app-defaults 
--without-Xaw3d --without-xinerama --with-utempter --with-x


The key part is "--enable-sixel-graphics" and / or 
"--enable-regis-graphics".  I'm also partial to the "--enable-256-color" 
and "--enable-screen-dumps".


The screen dumps mean that XTerm will save XHTML and / or XML dumps. 
Meaning they are text that you can search / copy paste.  }:-)


P.S.  My messages to cctech don't seem to be going through.  So I'm 
re-replying to the message to cctalk.




--
Grant. . . .
unix || die

Re: VT340 Emulation

[Michael Kerpan via cctalk]

Grab the sources from https://invisible-island.net/xterm/ and build
it. Documentation is lacking,but you should be able to find out what
options are needed to enable ReGIS and Sixel graphics by running
"./configure --help"

Mike

On Sat, Jun 19, 2021 at 1:47 PM Douglas Taylor  wrote:
>
> On 6/18/2021 8:49 PM, Michael Kerpan wrote:
>
> IIRC, Xterm has ReGIS and Sixel support in it's code these days, but most 
> Linux distro disable those features in their prepackaged builds for some 
> reason.
>
>
> Really?  I'm interested.  How do you build your own xterm?
>
> Doug
>
>
> Mike
>
> On Fri, Jun 18, 2021, 3:50 PM Douglas Taylor via cctech 
>  wrote:
>>
>> Right, according to the few notes I've seen on the packages currently
>> for sale on ebay.
>>
>> I hesitate to buy because I picked up a similar piece of software,
>> Smarterm 240, which seemed to do the desired emulation.  It was old
>> software for DOS, but I have an old DOS machine I use for PUTR I thought
>> I could install it on and be up and running.  It didn't turn out that
>> way because Smarterm wanted a particular video card and driver (which I
>> didn't have, of course).  I didn't find that out until I got the package
>> open and tried installing it.
>>
>> I don't know if the Reflection software has any restrictions like that.
>> The versions I see for sale are for Win3.1 and such, not exactly the
>> heyday of plug and play.  I was hoping to get some guidance from someone
>> who has used the Reflection software on what the actual
>> hardware/software requirements are.
>>
>> On a side note, emulating a Tektronix 4010 is apparently free and high
>> quality (see github).  It is the DEC graphics terminals that no one has
>> produced an open source emulation software for, so that's why I am
>> asking this question.
>> Doug
>>
>> On 6/18/2021 1:16 PM, Bill Degnan wrote:
>> > Reflection 4 should do that, right?
>> > Bill
>> >
>> > On Fri, Jun 18, 2021 at 1:15 PM Douglas Taylor via cctech
>> > mailto:cct...@classiccmp.org>> wrote:
>> >
>> > Does anyone have experience with the Reflection software that will
>> > emulate a DEC VT340 color graphics terminal?
>> >
>>
>

Re: VT340 Emulation

[Douglas Taylor via cctalk]

On 6/18/2021 8:49 PM, Michael Kerpan wrote:
IIRC, Xterm has ReGIS and Sixel support in it's code these days, but 
most Linux distro disable those features in their prepackaged builds 
for some reason.



Really?  I'm interested.  How do you build your own xterm?

Doug



Mike

On Fri, Jun 18, 2021, 3:50 PM Douglas Taylor via cctech 
mailto:cct...@classiccmp.org>> wrote:


Right, according to the few notes I've seen on the packages currently
for sale on ebay.

I hesitate to buy because I picked up a similar piece of software,
Smarterm 240, which seemed to do the desired emulation. It was old
software for DOS, but I have an old DOS machine I use for PUTR I
thought
I could install it on and be up and running.  It didn't turn out that
way because Smarterm wanted a particular video card and driver
(which I
didn't have, of course).  I didn't find that out until I got the
package
open and tried installing it.

I don't know if the Reflection software has any restrictions like
that.
The versions I see for sale are for Win3.1 and such, not exactly the
heyday of plug and play.  I was hoping to get some guidance from
someone
who has used the Reflection software on what the actual
hardware/software requirements are.

On a side note, emulating a Tektronix 4010 is apparently free and
high
quality (see github).  It is the DEC graphics terminals that no
one has
produced an open source emulation software for, so that's why I am
asking this question.
Doug

On 6/18/2021 1:16 PM, Bill Degnan wrote:
> Reflection 4 should do that, right?
> Bill
>
> On Fri, Jun 18, 2021 at 1:15 PM Douglas Taylor via cctech
> mailto:cct...@classiccmp.org>
>> wrote:
>
>     Does anyone have experience with the Reflection software
that will
>     emulate a DEC VT340 color graphics terminal?
>

RE: VT340 Emulation

[Dave Wade G4UGM via cctalk]

Doug,
It looks like PERSOFT Smartterm Office for 95/NT will also do REGIS Graphics. I 
have V8.0 but have yet to try REGIS.
Dave

> -Original Message-
> From: cctech  On Behalf Of Douglas Taylor
> via cctech
> Sent: 18 June 2021 18:15
> To: General Discussion: On-Topic Posts 
> Subject: VT340 Emulation
> 
> Does anyone have experience with the Reflection software that will emulate
> a DEC VT340 color graphics terminal?

Re: VT340 Emulation

[Liam Proven via cctalk]

On Fri, 18 Jun 2021 at 19:15, Douglas Taylor via cctech
 wrote:
>
> Does anyone have experience with the Reflection software that will
> emulate a DEC VT340 color graphics terminal?

I did try Reflection waaa back in the day, possibly around 1990 or
so. It worked, but I had no need of graphics support. I never imagined
that about 30y later I'd be working for the company that produced it.
(But now my bit has been spun off and floated.)

Most of my customers back then were running Wyse terminals -- later
(i.e. cheaper) models but usually under Wyse-50 or Wyse-60 emulation,
if I recall. For one or 2 demanding customers, we ended up going with
the J River Company's ICE/TEN tools instead.

https://www.icetcp.com/products/price-list.html

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

RE: VT340 Emulation

[Dave Wade G4UGM via cctalk]

Its been a while but Attachate software generally only needed special
hardware for stuff like 5250 twinax, 3270 co-ax, and various SDLC
connections.
This page might help check which versions support regis but they perhaps
don't go back to the really old versions...

https://support.microfocus.com/kb/doc.php?id=7021488

Dave
G4UGM

> -Original Message-
> From: cctech  On Behalf Of Wayne S via
> cctech
> Sent: 19 June 2021 00:50
> To: Douglas Taylor ; General Discussion: On-Topic
> Posts 
> Subject: Re: VT340 Emulation
> 
> We tried to use Reflection 240 on IBM PS/2 machines circa 1990. IIRC, it
> installed easily w/o needing special drivers.
> For the most part it worked as advertised. We didn't really need Regis
> graphics so we never tested that out. It's problem was that it was really
slow
> on PCs, much slower than a real VT240 terminal. We were trying to use
Dec's
> "all in one" office automation to do word processing and spreadsheets.
It's
> slowness caused us to abandon it and just use word perfect and lotus 123
> instead. FYI, There are reflection manuals on the wayback machine for
> reference.
> 
> 
> Wayne
> 
> 
> > On Jun 18, 2021, at 12:51 PM, Douglas Taylor via cctech
>  wrote:
> >
> > Right, according to the few notes I've seen on the packages currently
for
> sale on ebay.
> >
> > I hesitate to buy because I picked up a similar piece of software,
Smarterm
> 240, which seemed to do the desired emulation.  It was old software for
DOS,
> but I have an old DOS machine I use for PUTR I thought I could install it
on and
> be up and running.  It didn't turn out that way because Smarterm wanted a
> particular video card and driver (which I didn't have, of course).  I
didn't find
> that out until I got the package open and tried installing it.
> >
> > I don't know if the Reflection software has any restrictions like that.
The
> versions I see for sale are for Win3.1 and such, not exactly the heyday of
plug
> and play.  I was hoping to get some guidance from someone who has used
> the Reflection software on what the actual hardware/software requirements
> are.
> >
> > On a side note, emulating a Tektronix 4010 is apparently free and high
> quality (see github).  It is the DEC graphics terminals that no one has
> produced an open source emulation software for, so that's why I am asking
> this question.
> > Doug
> >
> >> On 6/18/2021 1:16 PM, Bill Degnan wrote:
> >> Reflection 4 should do that, right?
> >> Bill
> >>
> >> On Fri, Jun 18, 2021 at 1:15 PM Douglas Taylor via cctech
> mailto:cct...@classiccmp.org>> wrote:
> >>
> >>Does anyone have experience with the Reflection software that will
> >>emulate a DEC VT340 color graphics terminal?
> >

Re: VT340 Emulation

[emanuel stiebler via cctalk]

On 2021-06-18 15:09, Christian Groessler via cctalk wrote:
> I've got a real VT340, if somebody wants to verify an emulation.

340 A or 340 G+?

Big difference ...

Re: VT340 Emulation

[Michael Kerpan via cctalk]

IIRC, Xterm has ReGIS and Sixel support in it's code these days, but most
Linux distro disable those features in their prepackaged builds for
some reason.

Mike

On Fri, Jun 18, 2021, 3:50 PM Douglas Taylor via cctech <
cct...@classiccmp.org> wrote:

> Right, according to the few notes I've seen on the packages currently
> for sale on ebay.
>
> I hesitate to buy because I picked up a similar piece of software,
> Smarterm 240, which seemed to do the desired emulation.  It was old
> software for DOS, but I have an old DOS machine I use for PUTR I thought
> I could install it on and be up and running.  It didn't turn out that
> way because Smarterm wanted a particular video card and driver (which I
> didn't have, of course).  I didn't find that out until I got the package
> open and tried installing it.
>
> I don't know if the Reflection software has any restrictions like that.
> The versions I see for sale are for Win3.1 and such, not exactly the
> heyday of plug and play.  I was hoping to get some guidance from someone
> who has used the Reflection software on what the actual
> hardware/software requirements are.
>
> On a side note, emulating a Tektronix 4010 is apparently free and high
> quality (see github).  It is the DEC graphics terminals that no one has
> produced an open source emulation software for, so that's why I am
> asking this question.
> Doug
>
> On 6/18/2021 1:16 PM, Bill Degnan wrote:
> > Reflection 4 should do that, right?
> > Bill
> >
> > On Fri, Jun 18, 2021 at 1:15 PM Douglas Taylor via cctech
> > mailto:cct...@classiccmp.org>> wrote:
> >
> > Does anyone have experience with the Reflection software that will
> > emulate a DEC VT340 color graphics terminal?
> >
>
>

Re: VT340 Emulation

[Douglas Taylor via cctalk]

Right, according to the few notes I've seen on the packages currently 
for sale on ebay.


I hesitate to buy because I picked up a similar piece of software, 
Smarterm 240, which seemed to do the desired emulation.  It was old 
software for DOS, but I have an old DOS machine I use for PUTR I thought 
I could install it on and be up and running.  It didn't turn out that 
way because Smarterm wanted a particular video card and driver (which I 
didn't have, of course).  I didn't find that out until I got the package 
open and tried installing it.


I don't know if the Reflection software has any restrictions like that.  
The versions I see for sale are for Win3.1 and such, not exactly the 
heyday of plug and play.  I was hoping to get some guidance from someone 
who has used the Reflection software on what the actual 
hardware/software requirements are.


On a side note, emulating a Tektronix 4010 is apparently free and high 
quality (see github).  It is the DEC graphics terminals that no one has 
produced an open source emulation software for, so that's why I am 
asking this question.

Doug

On 6/18/2021 1:16 PM, Bill Degnan wrote:

Reflection 4 should do that, right?
Bill

On Fri, Jun 18, 2021 at 1:15 PM Douglas Taylor via cctech 
mailto:cct...@classiccmp.org>> wrote:


Does anyone have experience with the Reflection software that will
emulate a DEC VT340 color graphics terminal?

Re: VT340 Emulation

[Christian Groessler via cctalk]

I've got a real VT340, if somebody wants to verify an emulation.

regards,
chris


On 6/18/21 7:14 PM, Douglas Taylor via cctech wrote:
Does anyone have experience with the Reflection software that will 
emulate a DEC VT340 color graphics terminal?

Re: VT340 Emulation

[Bill Degnan via cctalk]

Reflection 4 should do that, right?
Bill

On Fri, Jun 18, 2021 at 1:15 PM Douglas Taylor via cctech <
cct...@classiccmp.org> wrote:

> Does anyone have experience with the Reflection software that will
> emulate a DEC VT340 color graphics terminal?
>
>