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 <twospru...@gmail.com> 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 <mhs.st...@gmail.com> 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 <jho...@pobox.com> >> wrote: >> >>> >>> >>> On Thu, Oct 6, 2022 at 11:47 AM Brian K. White <bw.al...@gmail.com> >>> 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. >>> >>
