14 Mar
2007
14 Mar
'07
2:13 p.m.
On 3/14/07, Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
Jay West wrote:
If by a MAME approach you mean to build a framework for various
specific emulator components that would be implemented separately,
then I think that might be a good approach. One could even consider
using real vendor ROM code for VT100-era-and-later terminals (wouldn't
work so well for the VT52). Of course, it does lead one down the
path of where do you get the ROM images unless you already _have_ a
particular model of terminal, but you _would_ get bug-for-bug
compatibility if your framework was on target.
Ya know... this recent talk of terminals got me
thinking.....
[ thinking snipped :-) ]
What something like MAME, but for terminals, you mean? Possibly a terminal's a lot easier to implement if
you limit yourself to
something like:
keyboard
character generator
display
I/O module
bell
... but there must be lots of terminals which had various "frills" outside of
this, surely? (I can't think of any personally*, but I'm not a terminal geek :-)
Keyboard LEDs (the VT100 keyboard has 4), but that's a trivial feature
compared to other considerations.
Thinking aloud a bit, one could reduce the overt characteristics of
swaths of terminals to text size, character size, command set, and
config method (internal menu, externam dip switches, etc), and be able
to bang out a large number of ANSI-compatible terminals quickly after
the first terminal was emulated (since so many terminals were so much
like the other ones of the day), but where it all bogs down is
recreating the specifics of each model - the differences between the
menus of the VT220 vs the VT240 (let alone the graphics modes of the
VT240), or the simplistic setup of the VT100 vs the more user-friendly
CiTOH 101, or even the internal clock of the CiTOH 101 (settable from
the host with ESC[ sequences).
At first glance, something like termcap seems to be a good way to
organize the command set, but termcap-in-reverse. My memory of
termcap is that various actions that a terminal knows how to do are
described by a 2-letter designator and a set of characters needed to
invoke that feature (clear, move, end of line, etc.) In the case of a
universal classic terminal emulator, you'd need to be able to
arbitrarily add new designators for features that are in brand X and
not brand Y. As long as one could add new designators to be able to
handle new terminal vendors and models, it might be somewhat easy to
work towards a 1-to-1 correspondence with existing termcap entries,
then perhaps to refine and improve historically defective termcap
entries.
I'd say one of the trickier aspects of this concept would be for those
terminals with more than one port that supported either multiple
sessions (CiTOH 101e) or external printers. One could arbitrarily
decide that for a first cut, you get one and only one connection to
the outside world (or to a network socket), but it would be nice not
to design out the possibility of being able to properly emulate the
real performance of the real hardware.
Oh... one more frill comes to mind as being potentially difficult to
implement - some DEC terminals (VT100, VT220, VT240...) had the
ability to drive an RS-170-compatible mono monitor. That might be a
trick coming from a process on a UNIX box, unless you went "full
screen" and happen to have a video-out-compatible video card or
laptop. Not a must-have feature by any means, but it was a feature
back in the day, and there were plenty of people who took advantage of
it.
I guess it comes down to the purpose of the emulation in the first
place and how exact is "exact enough". I'd be happy with an emulator
that always rendered strings in the right place on the screen as a
start (since so many vt100 emulators only have that 99% right).
-ethan