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 < cctech at classiccmp.org> wrote:

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 <dj.taylor4 at comcast.net> 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:

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:

On 2021-06-22 01:03, Grant Taylor via cctalk wrote: And, if you get a cheap VT340, it probably is just an "A", not a "G+" version :(

On 6/22/21 1:49 AM, emanuel stiebler via cctalk wrote: 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. I personally dislike all the 4k monitors that I've seen. I'd be more likely to go old school. ~chuckle~ What is a /real/ RS-232? How does it differ from USB-to-RS-232 and / or bit banging GPIO lines? -- Grant. . . . unix || die

On 6/22/21 5:26 AM, emanuel stiebler 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's especially a problem if you try to mix non-4k and 4k monitors. 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

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

On 2021-06-25 2:48 a.m., Peter Corlett via cctalk wrote: Or if you change USB ports the serial COM# changes. 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.

On Fri, 25 Jun 2021, Paul Koning via cctalk 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. Maciej

On Sun, 27 Jun 2021, Paul Koning wrote: 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

On Sun, 27 Jun 2021, Kevin Bowling wrote: 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 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

On Fri, Jun 25, 2021 at 3:53 PM Grant Taylor via cctalk <cctalk at classiccmp.org> wrote: 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.

On Jun 26, 2021, at 7:43 AM, Peter Corlett via cctalk <cctalk at classiccmp.org<mailto:cctalk at 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

On 2021-Jun-26, at 10:15 AM, Paul Koning via cctalk wrote: 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.

On Sat, 26 Jun 2021 at 18:15, Paul Koning via cctalk <cctalk at classiccmp.org> 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. 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

On Mon, 28 Jun 2021 at 14:11, Paul Koning <paulkoning at comcast.net> 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. David

On 6/26/21 9:31 AM, Tapley, Mark B. via cctalk wrote: 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

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. Like a Tek 4019? I remember seeing those in Typeset-11, amazing. paul

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

On 6/22/21 9:12 AM, Ethan Dicks via cctalk wrote: 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. *nod* -- Grant. . . . unix || die

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:

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

On Mon, Jun 21, 2021 at 11:14 PM Douglas Taylor via cctalk <cctalk at classiccmp.org> wrote: 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

On 2021-06-18 15:09, Christian Groessler via cctalk wrote: 340 A or 340 G+? Big difference ...