maybe an H19 emulator could be converted to work with M100 control codes 100%?
On Tue, Oct 18, 2022 at 4:20 PM B 9 <[email protected]> wrote: > 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. >>>>> >>>>
