14 Mar
2007
14 Mar
'07
2:55 p.m.
Ethan Dicks wrote:
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.
On 3/14/07, Jules Richardson <julesrichardsonuk at
yahoo.co.uk> wrote:
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
manufacturers)
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). Ya know... this recent talk of terminals got me
thinking.....
[ thinking snipped :-) ]
What something like MAME, but for terminals, you mean? ... 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. 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 :(