julesrichardsonuk at yahoo.co.uk
Wed Mar 14 16:55:01 CDT 2007
Ethan Dicks wrote:
> On 3/14/07, Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
>> Jay West wrote:
>> > Ya know... this recent talk of terminals got me thinking.....
>> [ thinking snipped :-) ]
>> What something like MAME, but for terminals, you mean?
> 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).
Actually, yes, I was thinking along the lines of something which actually made
use of the original firmware. That quite possible isn't practical though as
presumably at least some vendors did something really oddball rather than
using an off the shelf CPU :)
But yes, "warts and all" through use of the original ROMs would seem ideal to
me (from an accurate as possible emulation point of view). There's almost
certainly far less of an issue with publishing these ROMs for terminals I
would have thought - lots of the companies in question have either gone under
or are hardly likely to care (unlike the situation with MAME and games
>> ... 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.
Sure. I was speculating on whether some terminals had something other than a
single-tone bell, or also had mice for input etc. as those would have to be
taken into account for any framework. Hmmm, I bet a few had light-pen support.
> 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.
I suppose in a way though that's just another "I/O module" in terms of
software - and I would have thought that support for more than one module was
necessary already just because lots of terminals had more than one type of I/O
to the outside world (even if only one could often be used at once)
> 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.
Isn't that blurring the line between software and hardware a little, though?
We're only talking about a software emulation, so driving a monitor is just a
window on the screen of the real machine, just like the terminal's main
display. Or do you mean that some terminals could drive an external monitor
*independently* from the main display? (which implies our framework needs to
support multiple display devices)
In the Unix world at least there's often a choice of display output for apps
(X11 shm, X11 opengl, raw framebuffer), so I suppose if someone wanted to
write a driver to take RS-170 monitor output and spit it out to raw hardware
somewhere (rather than a window) they could :)
> 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).
That would sure be nice - but experience seems to be that terminal emulator
writers can focus on only three or four models and *still* not get it right :(
More information about the cctech