P.P.S. Errata: Destructive tabs *do* seem to work on the H19 terminal emulator I tried out, so that should be put into the "same as a Model 100" column.
On Tue, Oct 18, 2022 at 1:14 PM B 9 <[email protected]> wrote: > Interesting idea! > > Technically, the display codes are not "almost VT100", they are "almost > VT52". The TELCOM manual actually claims VT52 compatibility. In the past, > I've noted that Model T's do not make good VT52 emulators due to missing > functionality (reverse scroll, in particular). > > While that's true, I actually think the reverse is plausible. A VT52 would > *mostly* work as an Model T screen emulator. Or, more specifically, not a > VT52, per se, but Heath's H19 which was based on the VT52 and released in > 1980. It performed all the VT52 functions but had some additional features > like Esc p/q for reverse video, Esc E to clear the screen, and Esc L to > insert a new line. (If those sound familiar to you, then, yes, you know > your Model T very well!) Those are such unusual additions, I am pretty sure > the H19, or something very similar to it, was used to develop the > Kyotronic-85 before the screen system was working. (This is stretching a > bit, but it could even have been the Zenith Z-100 computer system which was > H19 compatible. It was only available as a prototype until late 1982, but > Microsoft had early access to it as they wrote the DOS for it. I admit it > is farfetched, but I like the Z-100 theory because it had a second CPU: an > 8085 just like the Model T.) > > Since my Tandy Terminfo <https://github.com/hackerb9/Tandy-Terminfo> has > (as far as I know) a complete definition of the display codes, it's easy to > see what would and wouldn't work on a H19 by using infocmp: > > All these are the same (note '\E' means Escape): > > - clear_screen= '\EE'. > - clr_eol= '\EK'. > - clr_eos= '\EJ'. > - cursor_address= '\EY%p1%' '%+%c%p2%' '%+%c'. > - cursor_down= '\EB'. > - cursor_home= '\EH'. > - cursor_left= '\ED'. > - cursor_right= '\EC'. > - cursor_up= '\EA'. > - enter_standout_mode= '\Ep'. > - exit_standout_mode= '\Eq'. > - insert_line: '\EL'. > - delete_line: '\EM'. > > These are missing on an h19: > > - cursor_normal: '\EP' > - cursor_invisible: '\EQ' > - restore_primary_line: '\ER', > - restore_secondary_line: '\Er' > - save_primary_line: '\ES', > - save_secondary_line: '\Es' > - enable_status_line: '\ET' > - disable_status_line: '\EU' > - disable_scrolling: '\EV' > - enable_scrolling: '\EW' > - destructive TAB, ^I (TAB clears any text that the cursor passes > over) > > Many programs would display correctly on an h19. Here are the possible > issues, from biggest to smallest: > > 1. Any pixel drawing (PSET, PRESET) would, of course, not work. > 2. H19 does not have the Tandy set of graphics characters. > 3. Arrow key input is different. > 4. Any program that tries to manipulate the status line using > CHR$(27)+"T" or "U" will fail. > 5. H19 lacks save current line and restore saved line > escape sequences. However, those were not well documented and may have only > worked on the Tandy 200. I would suspect that their use was rare. (How many > people here even know about CHR$(27)+"R" and friends?) > 6. H19 only understands '\EE' for clear screen. However, Model T's > documentation listed '\Ej' as an alias. > 7. The H19 did not have automatic left margins (backspace in the first > column goes to the last column in the previous row). > 8. Tandy portables have "destructive tabs"; that is, if the TAB > character would pass over text, that text is erased. I suspect few programs > relied on that feature. > 9. Do programs ever disable scrolling for anything other than speeding > up downloads in TELCOM? > 10. The inability to hide the cursor would be noticeable on an h19, > but wouldn't prevent the program from running. > > —B9 > > P.S. I made a quick table listing the escape sequence differences between > a Model T, an H19, and a VT52 > https://github.com/hackerb9/Tandy-Terminfo/blob/master/compare.md > > > On Thu, Oct 6, 2022 at 7:11 PM Stephen Adolph <[email protected]> > wrote: > >> The M100 native display has some important non standard control codes. >> >> Supposing you could read inbound characters on the serial port, the >> egress flow could be "almost VT100" for display purposes. >> >> A really useful project would be to modify a terminal program to speak >> the custom M100 display codes. This would allow a PC to really emulate a >> proper DVI video. >> >> The codes and what they do are well defined....this is what I have >> implemented in that MVT100 hardware adapter, and what both the VT100 driver >> and REX# supports. >> >> Side comment. Even with all the extended codes that a true VT100 >> supports, there seems to be no way to make a VT100 properly handle a few of >> the M100 control codes. >> >> ..steve >> >> >> On Thursday, October 6, 2022, Mike Stein <[email protected]> wrote: >> >>> Doesn't Steve's program handle the display part? Hooking the RS-232 >>> receive into the keyboard vector should also not be too difficult but as >>> you say, what's the point? >>> >>> I don't recall whether the M100 has it (ISTR that it does) but some >>> systems have a built-in function, usually CTL-P that echoes everything on >>> the display to the printer (not just one screen like PRINT), which could in >>> turn be redirected to the com port and fed to a terminal program >>> >>> m >>> >>> On Thu, Oct 6, 2022 at 3:05 PM John R. Hogerhuis <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Thu, Oct 6, 2022 at 11:47 AM Brian K. White <[email protected]> >>>> wrote: >>>> >>>>> 2. Can I run M100 stuff from my remote? >>>>> >>>>> >>>>> What? >>>>> >>>>> >>>> I guess he means display what the M100 displays on the host and route >>>> characters sent from the host to the keyboard buffer of the M100. >>>> >>>> It could be done... it would require a program on the M100 side. >>>> >>>> Not sure of its utility though. >>>> >>>> Another idea would be using a host PC as a large display for the M100. >>>> >>>> So, say you have the M100 configured for 80x24, and a 80x24 >>>> xterminal or putty window on the PC displaying its output. Bytes and >>>> display codes routed out the serial port, with character set and control >>>> code mapping. >>>> >>>> Kind of like a simple DVI or VGA adapter. >>>> >>>> At a high baud rate, I'd guess it would be more performant than the >>>> native display. >>>> >>>> -- John. >>>> >>>
