14 Mar
2007
14 Mar
'07
3:21 p.m.
On 3/14/07, Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
Ethan Dicks wrote:
I don't know lots about all vendors, but in the DEC world of
terminals, they used 8-bit microprocessors for the VT100 through the
VT241. I _think_ the VT100-family uses an 8080, and the VT220 and
VT240/241 _might_ use a Z80, but they also might use an 8085. Any of
those terminals would be candidates to snarf ROM images, but one would
need to know memory maps, ROM bank select schemes, how font ROMs tie
into the video circuit, etc., first, but these are all knowable
quantities.
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 :) 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.
Dunno about light pens (except for, say, a VS11), but Tektronix
terminals, even the later raster terminals , had coordinate input
devices. Older terminals had X-Y thumb wheels, IIRC, and later ones
had some sort of 2-dimensional rocker pad - like the mouse input for
an iOpener, again, IIRC. You could select coordinates with locally
rendered crosshairs/sighting lines, then send the coordinates to the
application. I don't know about the details, only that they existed.
The most I ever did with Tektronix terminals was to render the
occasional canned image - I never wrote software from scratch to take
advantage of their features.
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)
The VT125 allowed one to overlay its raster renderings over a video-in
source, but that's not what I meant - I more meant the ability to
drive a secondary monitor or a projector or some such with the same
contents as the primary tube. Yes, I agree, it's more of a hardware
emulation feature than a software emulation feature, and is not a
show-stopper in any case.
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 :(
Too true.
-ethan