14 Mar
2007
14 Mar
'07
7:54 a.m.
Ya know... this recent talk of terminals got me thinking.....
It would be a good idea IMHO to preserve the functionality of all these
classic old terminals. After all, sooner or later the real ones will
disappear or at least stop working. After all, some systems are picky about
only working with certain terminals (or some only work WELL with certain
terminals)...
Then I started thinking... most modernish "good" terminal emulation packages
don't support all the old venerable classics. Sure, many do VT100 (sort of).
But when was the last time you saw a terminal emulation package that
faithfully reproduced a beehive minibee? Or a Heath H19? I think it might be
helpful for the future if there was a "collectors" terminal emulation
program that really did strive to get emulations for all the old terminals,
and get it dead right. I know it'd be nice to have one emulator for my
systems that "did the right thing(tm)" on my HP mini's, my DECs, DGs, and my
Heathkits, GA Zebras, TI990's, etc. etc. all with one program. Instead I
have to have many different terminal emulation programs (because one that
does HP2624 emulation wont do my TI terminal emulation...)... or the real
thing (which of course I'd prefer).
So then my unix-centric brain said... Oh, well, there's always
termcap/terminfo. Surely that will document old terminals for posterity and
future emulation. So I just popped in to my local copy of terminfo and sure
enough, there's even an entry for the beehive minibee and superbee. BUT... I
then noted the comments that say "hey, this termcap entry is pretty wrong
and doesn't work right". So relying on terminfo for preservation is probably
not a great idea. But it's a start.
Just thinking out loud... would be nice to have a terminal emulation program
that was easily extensible for any terminal, already had all the ones
defined that we here are familiar with... and ran on everything from MS/DOS
to Vista to *nix. A classiccmp'ers terminal emulator :) Maybe a good start
would be those of us that have particular terminals at least going in and
correcting the terminfo entries that are incorrect.
Perhaps this is a silly idea and I just need my morning coffee!
Jay West
14 Mar
14 Mar
1:16 p.m.
On 3/14/07, Jay West <jwest at ezwind.net> wrote:
Ya know... this recent talk of terminals got me thinking.....
It would be a good idea IMHO to preserve the functionality of all these
classic old terminals. After all, sooner or later the real ones will
disappear or at least stop working. After all, some systems are picky
about
only working with certain terminals (or some only work WELL with certain
terminals)...
Then I started thinking... most modernish "good" terminal emulation
packages
don't support all the old venerable classics. Sure, many do VT100 (sort
of).
But when was the last time you saw a terminal emulation package that
faithfully reproduced a beehive minibee? Or a Heath H19? I think it might
be
helpful for the future if there was a "collectors" terminal emulation
program that really did strive to get emulations for all the old
terminals,
and get it dead right. I know it'd be nice to have one emulator for my
systems that "did the right thing(tm)" on my HP mini's, my DECs, DGs, and
my
Heathkits, GA Zebras, TI990's, etc. etc. all with one program. Instead I
have to have many different terminal emulation programs (because one that
does HP2624 emulation wont do my TI terminal emulation...)... or the real
thing (which of course I'd prefer).
So then my unix-centric brain said... Oh, well, there's always
termcap/terminfo. Surely that will document old terminals for posterity
and
future emulation. So I just popped in to my local copy of terminfo and
sure
enough, there's even an entry for the beehive minibee and superbee. BUT...
I
then noted the comments that say "hey, this termcap entry is pretty wrong
and doesn't work right". So relying on terminfo for preservation is
probably
not a great idea. But it's a start.
Just thinking out loud... would be nice to have a terminal emulation
program
that was easily extensible for any terminal, already had all the ones
defined that we here are familiar with... and ran on everything from
MS/DOS
to Vista to *nix. A classiccmp'ers terminal emulator :) Maybe a good start
would be those of us that have particular terminals at least going in and
correcting the terminfo entries that are incorrect.
Perhaps this is a silly idea and I just need my morning coffee!
Jay West
If you get something that does that... let me know.
Kermit-95 is the closest thing.
I purchased it and like the emulation for the DEC stuff. Don't know how
good the DG is... also used the SCO-Ansi... pretty good there.
Kermit 95 Terminal Types
*As of:* Kermit 95 2.0 <http://www.columbia.edu/kermit/k95.html>
*Date:* 7 June 2002
Kermit 95 2.0 supports 40 terminal emulations:
*ADM3A* The Lear-Siegler ADM-3A terminal. No F-keys.
*AIXTERM* For accessing IBM AIX systems. Compatible with the AIXTERM window
on AIX workstations, and the AIXTERM termcap / terminfo entry. Has F1-F12
keys, also Shift-F1-F12.
*ANSI-BBS (*) <http://www.columbia.edu/kermit/termtype.html#ansi>* For
accessing most BBSs. 8 bits, color, line- and box-drawing, "ANSI graphics".
As defined in the DOS 5.0 manual. Function keys F1-F4 send what VT100 sends,
F5-F12 undefined.
*AT386 (*) <http://www.columbia.edu/kermit/termtype.html#ansi>* For
accessing (SCO) Unixware and (Sunsoft) Interactive UNIX systems. Has 60
Function keys F1-F12 plus various versions with Shift, Ctrl, Ctrl-Shift,
etc.
*Avatar/0+ (*) <http://www.columbia.edu/kermit/termtype.html#ansi>* For
accessing BBSs that support certain advanced features. If a BBS supports
Avatar/0+, this is normally negotiated automatically when you log in to it.
F1-F4, like ANSI-BBS.
*BA80* The Nixdorf BA80 terminal (Germany), used for accessing Nixdorf
computers. Has PA (function) keys 1-12.
*BETERM (*) <http://www.columbia.edu/kermit/termtype.html#ansi>* BeBox
console, the preferred terminal type for accessing the BeBox and BeOS.
*DG200* Data General DASHER 200, for accessing AOS/VS, DG/UX, and other Data
General platforms. Has function keys F1-F12, which can be modified by Shift,
Ctrl, or Ctrl-Shift, plus some others (e.g. Alt-F1-F5, Alt-Shift-F1-F5,
Ctrl-Alt-F1-F5).
*DG210* Data General DASHER 210, for accessing AOS/VS, DG/UX, and other Data
General platforms. F-keys as for DG200.
*DG217* Data General DASHER 217, for accessing AOS/VS, DG/UX, and other Data
General platforms. Includes both DG and UNIX modes, as well as alternate
character sets -- Math/Symbol, Line Drawing, Word Processing. F-keys as for
DG200.
*HEATH19* The Heath-19 or Zenith-19 terminal. Has PF1-4 like VT100.
*HFT* IBM's High Function Terminal type, used for accessing AIX and other
IBM platforms that support it. Has F1-F12, Shift-F1-F12, Ctrl-F1-F12.
*HP2621A* The Hewlett Packard 2621A terminal. Has F1-F16. F9-F16 are entered
by Shift-F1-F8.
*HPTERM (*) <http://www.columbia.edu/kermit/termtype.html#hpterm>* Hewlett
Packard's generic HPTERM specification, used on HP-UX in HPTERM windows, and
compatible with various specific HP terminals such as those in the 700
series. F keys as for HP2621A.
*HZ1500* The Hazeltine 1500 terminal. Has F1-F12.
*IBM3151* The IBM 3151 terminal. This emulation is just enough to support
termcap and terminfo driven applications on Unix. A complete keyboard
mapping is provided as well as the IBM 3151 graphics character set. None of
the special forms modes are (yet) implemented. Has F1-F12, Alt-F1-F12,
Shift-Alt-F1-F12.
*LINUX* The Linux console. Has 60+ function keys, produced by F-keys (and
some others) in various combinations with Shift, Ctrl, and Alt.
*QANSI (*) <http://www.columbia.edu/kermit/termtype.html#ansi>* The QNX ANSI
terminal. F1-F10.
*QNX* The QNX console. F1-F12, Shift F1-F12.
*SCOANSI (*) <http://www.columbia.edu/kermit/termtype.html#ansi>* The SCO
version of ANSI, used by SCO UNIX, ODT, and OpenServer, and Caldera Open
UNIX. Has 60 function keys, like AT386. WARNING: The host name is ANSI, but
Kermit's name is SCOANSI, to distinguish it from ANSI-BBS, which is
different. When making Telnet connections, set Kermit's terminal type to
SCOANSI and its Telnet terminal-type to ANSI:
set terminal type scoansi
set telnet terminal-type ansi
*SNI-97801* The Siemens Nixdorf Bildschirmeinheit 97801-5xx (Germany), for
use with SINIX. Downloadable character-sets, fonts, and compose tables are
not supported. Has tons of function keys produced by various combinations of
F-keys with Shift, Ctrl, and Alt.
*TTY* Teletypewriter. This is equivalent to no terminal emulation at all.
*TVI910+* The Televideo 910+ terminal. F1-F12, Shift-F1-F12, Alt-F1-F6,
Alt-Shift-F1-F6.
*TVI925* The Televideo 925 terminal. F1-F12, Shift-F1-F12, Alt-F1-F6,
Alt-Shift-F1-F6.
*TVI950* The Televideo 950 terminal. F1-F12, Shift-F1-F12, Alt-F1-F6,
Alt-Shift-F1-F6.
*VC404* The Volker Craig 404 terminal. F1-F12.
*VIP7809* Partial emulation of the Honeywell VIP-7809 terminal. In fact,
this is VT-102 emulation with minor modifications sufficient to allow access
to Honeywell DPS-6 systems.
*VT52* The Digital Equipment Corporation VT52 terminal. Has PF keys 1-4 on
F1-F4 but no F keys.
*VT100* The industry-standard 7-bit Digital Equipment Corporation VT100
terminal, with color extensions. Has PF keys 1-4 on F1-F4, but no F keys.
*VT102* Like VT100, but with character insertion and deletion capabilities
and several other functions added, and with color extensions.
*VT220* The industry-standard 8-bit Digital Equipment Corporation VT220
terminal with color extensions. Has PF keys 1-4 on F1-F4, plus 20 F-keys,
1-20, of which only F5-F20 are usable, on F5-F12 and Shift-F1-F10.
*VT220PC* VT220 with a PC keyboard.
*VT320* The industry-standard 8-bit Digital Equipment Corporation VT320
terminal with color extensions, plus many features of the VT420, VT520, and
DECterm. F-keys as for VT220.
*VT320PC* VT320 with a PC keyboard.
*VTNT* VTNT is a proprietary Microsoft terminal definition used by the
Telnet Server distributed with Windows 2000/XP and NT Services for Unix.
*WY30* The Wyse model 30 terminal, plus most of the capaibilities of the
Wyse 30+ and 35 models. Multiple Windows, display controls, and certain
other features are not currently supported.
*WY50* The Wyse model 50 terminal. Multiple Windows, display controls, and
certain other features are not currently supported. F1-F12, Shift-F1-F12,
Alt-Shift-F1-F6, and others.
*WY60* The Wyse model 60 terminal, plus most of the features of the Wyse
120, 160, and 350 models. Multiple Windows, display controls, and certain
other features are not currently supported. F keys as for WY50.
*WY160* The Wyse model 160 terminal, plus most of the features of the Wyse
120 and 350 models. Multiple Windows, display controls, and certain other
features are not currently supported.
*WY370* The Wyse model 370 terminal, similar to VT320 but with additional
color capabilities. F-keys as for WY60, plus some more.
The names in the list are those used in the Terminal Type box on the
Terminal page of the Dialer entry notebook, and by the SET TERMINAL TYPE
command. These names are also sent to the host in Telnet terminal type
negotiations unless you have specified a TELNET terminal-type name to
override it.
------------------------------
ANSI Terminal Types Whenever a (PC)
ANSI<http://www.columbia.edu/kermit/gloss.htm#g_ansi>terminal type is
chosen, the following actions are executed automatically:
- SET TERMINAL BYTESIZE 8
- SET PARITY NONE
- SET TERMINAL CHARACTER-SET CP437
- SET TERMINAL COLOR TERMINAL LGRAY BLACK
- Your PC code page (right half) is designated to G1, G2, and G3.
The normal mode of operation for any ANSI terminal type is to converse with
a host application that uses a PC code page as its character set, and whose
code page is the same as your code page. This is because ANSI terminal
emulation is generally used for applications where there is a lot of line
and box drawing -- "graphics" simulated by colored character cells.
In some environments, however, the host sends Latin-1 or other codes for
accented or special characters. In such cases, you can set your terminal
character set to Latin-1 (or other set) AFTER selecting an ANSI terminal
type, for example:
set terminal type scoansi ; Sets CP437
set terminal remote character-set latin1 ; Set it to Latin-1
But Latin-1 (and Latin-2, Cyrillic, Hebrew, etc) do not include the many
box-drawing characters needed for ANSI emulation, and the simple form of the
SET TERMINAL CHARACTER-SET command shown above assigns Latin-1 to all of G1,
G2, and G3. Thus you must also ensure that your PC code page remains
available as an alternate character set by using the more specific form of
the command, which is:
SET TERMINAL REMOTE-CHARACTER-SET *name [ *G*n ]*
This lets you change your remote character set without having to respecify
(or even know) your local PC character set (or code page). The
optional G*n*field designates the named set to the specified terminal
graphics table, G0,
G1, G2, or G3 (you can specify more than one) according to ISO 4873 and 2022
rules.
------------------------------
HPTERM Emulation This is a functional HPTERM (Hewlett Packard Xterm)
emulation, but lacking color and multiple pages. When function keys are
programmed and/or labeled, you can view the labels on a popup help screen
using the new \Kfnkeys verb, which is assigned by default to Alt-f.
When the HPTERM emulation is selected, character sets are assigned as
follows:
Remote: GL->G0: US ASCII (94 chars)
GR->G1: Hewlett Packard Roman 8 (96 chars)
G2: HP Line Drawing Graphics (96 chars)
G3: HP Line Drawing Graphics (96 chars)
------------------------------
SNI-97801 Emulation The SNI-97801 is an advanced terminal designed
specificly with the multiple language market in mind. Kermit 95 does not
support the following features of the terminal:
- downloadable soft character sets
- downloadable compose key settings
The SNI-97801 has a keyboard with more than 42 function and editing keys
which cannot be mapped directly to a PC keyboard. K95 provides keyboard
verbs <http://www.columbia.edu/kermit/kverbs.htm> for all of the SNI-97801
keys although most are not assigned to the PC keyboard due to lack of space.
Kermit 95 does support all of the 7-bit and 8-bit CH.CODE modes which are
controlled by the following commands:
- SET TERMINAL SNI-CH.CODE {ON, OFF} or the \Ksni_ch_code keyboard
verb
- SET TERMINAL BYTESIZE { 7, 8 }
The CH.CODE mode determines whether the terminal communicates using
International character sets such U.S. ASCII and ISO Latin 1; or whether it
uses a National character set such as German. The SET TERMINAL LANGUAGE
command is used to specify the default language.
The Firmware Versions numbers can be customized using the SET TERMINAL
SNI-FIRWARE-VERSIONS command. The default keyboard version number is 920031
and the default terminal version number is 830851.
------------------------------
Automatic Actions on Switching Terminal Types Terminal types can be switched
by user command ("set terminal type"), hot key (\Ktermtype, normally
assigned to Alt-t), Telnet negotiations, or (in some cases) by host escape
sequence. Whenever the terminal type is set or switched:
- The screen is cleared.
- The corresponding terminal-specific keymap is activated.
- A macro named TT_*XXX*, where *xxx* is the same as the terminal type
name, is executed if such a macro is defined; e.g. tt_vt320, tt_scoansi,
etc. Such a macro definition might include SET TERM HEIGHT or WIDTHcommands.
------------------------------
Terminal Send Data modes Many terminals including the Wyse and Televideo
terminals support a SEND DATA feature which allows the host application to
query the terminal and request that a copy of all of the data on the screen
be sent to the host. This feature is very useful with applications that
process a complete form of data at a time; or that allow a single terminal
to be used with multiple sessions. However, this feature is also a security
hole which can be exploited to steal data. Therefore, Kermit 95 disables the
SEND DATA feature by default. If you need to use SEND DATA with your
application, you must add a SET TERMINAL SEND-DATA ON command to your
K95CUSTOM.INI file.
------------------------------
*Click Back on your Browser's Toolbar to return.*
------------------------------
--
d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now!
pechter-at-gmail.com
1:42 p.m.
Jay West wrote:
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 :-)
*other than graphics terminals; I'm not sure how much sense it makes to lump
those in with pure character-based devices.
Perhaps this is a silly idea and I just need my
morning coffee!
Interesting article I saw the other day about studies showing that coffee does
nothing to "wake you up"; all it does is provide a hit for people suffering
caffeine withdrawal symptoms. But I think that's OT :)
2:02 p.m.
On Wed, 14 Mar 2007, Jules Richardson wrote:
Jay West wrote:
Related to this, I'd like to see more terminal emulations added to
Minicom.
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Ya know... this recent talk of terminals got me
thinking.....
[ thinking snipped :-) ]
What something like MAME, but for terminals, you mean? 
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
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 :(
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
3:41 p.m.
On Mar 14, 2007, at 6:21 PM, 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.
The VT100 uses an 8085, FYI. I don't recall what the VT220/VT240
use.
I have pretty much all of the DEC microprocessor-based terminals.
Do you think it'd be a good idea for me to, over time, pull them out
and read their ROMs for archival or reconstructive purposes?
-Dave
--
Dave McGuire
Port Charlotte, FL
15 Mar
15 Mar
2:14 a.m.
Dave McGuire wrote:
I have pretty much all of the DEC
microprocessor-based terminals. Do
you think it'd be a good idea for me to, over time, pull them out and
read their ROMs for archival or reconstructive purposes?
I think that would be a good idea -- not just for emulations but to make
it possible to repair any terminals that suffer from bit rot in future.
I've been doing that for years (decades, actually!), and I have some
of the VT100 ROMs on my website at
http://www.dunnington.u-net.com/public/DECROMs/ (read the file ROMlist
to see which they are). I'd be happy to host images not already there.
See particularly the "Wanted!" list in that directory :-)
--
Pete Peter Turnbull
Network Manager
University of York
10:49 a.m.
On Mar 15, 2007, at 5:14 AM, Pete Turnbull wrote:
Oh my, well that saves me a lot of case-cracking! :) I will see
if I can add a few to your archive.
-Dave
--
Dave McGuire
Port Charlotte, FL
I have
pretty much all of the DEC microprocessor-based
terminals. Do you think it'd be a good idea for me to, over time,
pull them out and read their ROMs for archival or reconstructive
purposes?
I think that would be a good idea -- not just for emulations but to
make it possible to repair any terminals that suffer from bit rot
in future. I've been doing that for years (decades, actually!),
and I have some of the VT100 ROMs on my website at http://
www.dunnington.u-net.com/public/DECROMs/ (read the file ROMlist to
see which they are). I'd be happy to host images not already
there. See particularly the "Wanted!" list in that directory :-)
16 Mar
16 Mar
2:05 a.m.
On 15/03/2007 17:49, Dave McGuire wrote:
On Mar 15, 2007, at 5:14 AM, Pete Turnbull wrote:
Oh my, well that saves me a lot of case-cracking! :) I will see if I
can add a few to your archive.
Great! Contributions are welcome :-)
--
Pete Peter Turnbull
Network Manager
University of York
I have
pretty much all of the DEC microprocessor-based terminals.
Do you think it'd be a good idea for me to, over time, pull them out
and read their ROMs for archival or reconstructive purposes?
I'd be happy to host images not already
there. See particularly the "Wanted!" list in that directory :-) 
15 Mar
15 Mar
9:04 a.m.
Dave McGuire wrote:
The VT100 uses an 8085, FYI. I don't recall what the VT220/VT240 use.
The VT100 uses an 8080. You may be thinking of the VT101/102, but I
don't have one here to check.
The text terminals from the VT220 upwards mostly use 8051-family
microcontrollers.
--
Paul
3:17 p.m.
On Mar 15, 2007, at 12:04 PM, Paul Williams wrote:
You are absolutely correct; I have no idea what I was
thinking...sorry about that!
The VT100
uses an 8085, FYI. I don't recall what the VT220/
VT240 use.
The VT100 uses an 8080. You may be thinking of the VT101/102, but I
don't have one here to check. The text terminals from the VT220 upwards mostly use
8051-family
microcontrollers.
Now that's cool. :)
-Dave
--
Dave McGuire
Port Charlotte, FL
14 Mar
14 Mar
5:54 p.m.
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)
Along these lines -- does anyone have ROM images (preferably program &
character roms) for the firmware in, say, a VT100? This discussion has
piqued my interest in writing a hardware-level VT100 emulator (just what
I need, another software project to distract me from the dozen or so I
haven't yet finished...). I own a VT100 but I have no means to read the
firmware off of it -- if anyone out there has an image I'd love to play
around with it. Any good sources for hardware info on the VT100?
Thanks,
Josh
15 Mar
15 Mar
12:58 a.m.
On Mar 14, 2007, at 8:54 PM, Josh Dersch wrote:
Ahh, that answers that question. :) I'm about to hit the hay
right now, but I will see about reading some EPROMs tomorrow and will
let people know of their availability.
-Dave
--
Dave McGuire
Port Charlotte, FL
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)
Along these lines -- does anyone have ROM images (preferably
program & character roms) for the firmware in, say, a VT100? This
discussion has piqued my interest in writing a hardware-level VT100
emulator (just what I need, another software project to distract me
from the dozen or so I haven't yet finished...). I own a VT100 but
I have no means to read the firmware off of it -- if anyone out
there has an image I'd love to play around with it. Any good
sources for hardware info on the VT100? 
2:34 a.m.
One class of terminal that seems to have disappeared completely from
history is the viewdata terminal. 40x25 lines, colour and block
graphics and other effects implemented by control codes that took up
visible spaces..
Designed in the late '70s for display of the GPO (later British
Telecom) Prestel and other compatable dial-up services on residential
TV sets via integrated electronics (very few ever made due to cost),
it ended up as mostly dedicated terminals or set-top-boxs. The
service only really took off outside limited vertical markets in the
late '80s when "Micronet 800" started selling modems and (mostly quite
bad) terminal emulators for the various home micros. I used a few
dedicated terminals at the time, connecting either to the proper
service (run on primes I think) or our local editing system (a PDP 11
of some flavour.)
I've never seen an emulation that could cope with the rare case of
"remove the double-height -start-code" properly[1] apart from the one
I wrote, probably because nobody ever thought hard about the
implications of it..
I vote for the MAME-style hardware emulation approach!
Rob
[1] Because control codes took up display spaces, it was possible to
go back and overwrite them - this was often used for simple
animations, changing colours to hide or reveal things, etc, as at 1200
baud, it was quite slow enough to be visible.. Now.. double height
lines 'overflowed' onto the line below, hiding anything that was
printed there. when you remove the double-height start code, the
displayed double height characters are replaced by standard single
height characters, and the line below then appears. Now, if that line
had a start-double-height code on it, ignored up until now, then it
would suddenly appear and expand to cover line 3, hiding everything
that was there, etc etc... it was possible to swap an entire page of
text for another page of text, (all double height of course) by
overwriting a single control character at the top. Not bad when you
only had 1200 baud to send stuff. Unfortunately, I never met a single
emulator that could cope with this, apart from mine, although the
hardware terminals I'd encountered coped without blinking.
On 15/03/07, Dave McGuire <mcguire at neurotica.com> wrote:
On Mar 14, 2007, at 8:54 PM, Josh Dersch wrote:
Ahh, that answers that question. :) I'm about to hit the hay
right now, but I will see about reading some EPROMs tomorrow and will
let people know of their availability.
-Dave
--
Dave McGuire
Port Charlotte, FL
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)
Along these lines -- does anyone have ROM images (preferably
program & character roms) for the firmware in, say, a VT100? This
discussion has piqued my interest in writing a hardware-level VT100
emulator (just what I need, another software project to distract me
from the dozen or so I haven't yet finished...). I own a VT100 but
I have no means to read the firmware off of it -- if anyone out
there has an image I'd love to play around with it. Any good
sources for hardware info on the VT100?
3:23 a.m.
On 15/03/2007 09:34, Rob wrote:
One class of terminal that seems to have disappeared
completely from
history is the viewdata terminal.
Yup. I needed one to access home banking a decade ago, and it wasn't
easy to find one, other than on a BBC Micro or an Archimedes.
I've never seen an emulation that could cope with
the rare case of
"remove the double-height -start-code" properly[1] apart from the one
I wrote, probably because nobody ever thought hard about the
implications of it..
Define "properly" and I'll tell you if mine does :-) Actually some
servers do different things with double-height too. I swiped the code
for my terminal emulation from a program called XBtx, which was meant
for the German Bildschirmtext system. I had to remove a lot of things
and fix a few differences, including IIRC the double-height. One of the
nice things about it, though, is that it's a client/server program, so
my wife could use the client on her SGI Indigo to access the bank system
(HOBS, if you want to know) via my Indy and its modem.
--
Pete Peter Turnbull
Network Manager
University of York
3:42 a.m.
On 15/03/07, Pete Turnbull <pete at dunnington.plus.com> wrote:
On 15/03/2007 09:34, Rob wrote:
as per the footnote .. but specifically:
Send it..
HOME Esc M Hello CR LF
Esc M Goodbye CR LF
Esc M Hello CR LF
Esc M Goodbye CR LF
you should only see two double-height "Hello"s..
send it HOME and a space
you should now see two double height "Goodbye"s ..
Many emulations drop the hidden second line, rather than remember it,
so it doesn't re-appear, and you end up with just the top line
changing, if it does even that .. I've seen some that change the top
line to single height, and leave line 2 on the screen with the bottom
half of the Hello on it, or worse, because they duplicated line 1,
they think that line 2 is now a double-height Hello, overwriting line
3....
I've never seen an emulation that could cope
with the rare case of
"remove the double-height -start-code" properly[1] apart from the one
I wrote, probably because nobody ever thought hard about the
implications of it..
Define "properly" and I'll tell you if mine does :-)
4:49 p.m.
On 15/03/2007 09:34, Rob wrote:
It was, of course, the same display (and attribute code) spec as the UK
Teletext system. Many Prestel terminals used the teletext chipset, the
application bnok for the later Philips teletext chips gives a viewdata
terminal as an example application (Alas suitable code for the
microcontroller is not in said book).
Older terminals used the SAA50x0 series of ICs, of course. There was a
chip called a LUCY (I forget what it stood for), SAA5070, which was the
digital bit of the Prestel modem, a cassette interface, etc. Don't ask ne
where to get one now.
-tony
One class of terminal that seems to have
disappeared completely from
history is the viewdata terminal.
Yup. I needed one to access home banking a decade ago, and it wasn't
easy to find one, other than on a BBC Micro or an Archimedes.
9:17 a.m.
Rob wrote:
One class of terminal that seems to have disappeared
completely from
history is the viewdata terminal. 40x25 lines, colour and block
graphics and other effects implemented by control codes that took up
visible spaces..
I remember spending a while hunting out a PC terminal emulator that would
handle double-height properly; eventually I gave up. There was one (I think it
might have been Odyssey) which came fairly close, but all the others seemed to
make a total mess of it.
It's one of the things that's been nagging at me about some sort of "do
everything" terminal emulator, because I'm not sure whether supporting
double-height introduces all sorts of problems when otherwise trying to
support "classic" terminals.
9:11 a.m.
On 15/03/07, Jules Richardson <julesrichardsonuk at yahoo.co.uk> wrote:
I remember spending a while hunting out a PC terminal emulator that would
handle double-height properly; eventually I gave up. There was one (I think it
might have been Odyssey) which came fairly close, but all the others seemed to
make a total mess of it.
Mine was for the BBC; I "solved" the issue by buffering the data input
seperately, and re-drawing the main screen from it using the 50Hz
clock tick.. This allowed me to keep what was on the otherwise hidden
lines, and it automaticaly reappeared when necessary. All other
emulators I had encountered just drew to screen memory directly,
discarding the hidden line information, and then of course were
stumped when it was required..
It's one of the things that's been nagging at
me about some sort of "do
everything" terminal emulator, because I'm not sure whether supporting
double-height introduces all sorts of problems when otherwise trying to
support "classic" terminals.
I am sure that I recall codes for going to double-height (and double
width) characters in other environments, too.. Not sure if it was
terminals though, or printers..
2:15 a.m.
Josh Dersch wrote:
Along these lines -- does anyone have ROM images
(preferably program &
character roms) for the firmware in, say, a VT100?
Try http://www.dunnington.u-net.com/public/DECROMs/
I'm missing 23-031E2 because my VT had the 23-061E2 option instead, and
I don't have 23-094E2 (extra character generator ROM for VT100-WC-WK) or
any of the alternative ROMs used in the rest of the VT1xx family
--
Pete Peter Turnbull
Network Manager
University of York
14 Mar
14 Mar
10:02 p.m.
In article <45F86F35.5080107 at yahoo.co.uk>,
Jules Richardson <julesrichardsonuk at yahoo.co.uk> writes:
Actually, yes, I was thinking along the lines of
something which actually mad
e
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 :)
The weirder terminals don't use a CPU at all. They use SSI/MSI TTL
logic.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
15 Mar
15 Mar
5:27 p.m.
In article <45F8EAD6.9070607 at jetnet.ab.ca>,
woodelf <bfranchuk at jetnet.ab.ca> writes:
Richard wrote:
No, those aren't the weird ones. Those are the unobtainable ones.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
The weirder terminals don't use a CPU at all.
They use SSI/MSI TTL
logic.
I thought the weird ones used Delay lines and/or Core Memory.
9:21 a.m.
Richard wrote:
In article <45F86F35.5080107 at yahoo.co.uk>,
Jules Richardson <julesrichardsonuk at yahoo.co.uk> writes:
That's what I was wondering. Although I suppose that providing they have a
design that can be coaxed into the same architecture as a typical terminal,
then it doesn't matter as a box can be drawn around the bit that "looks"
like
a CPU.
Actually, yes, I was thinking along the lines of
something which actually mad
e
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 :)
The weirder terminals don't use a CPU at all. They use SSI/MSI TTL
logic. 
11:29 a.m.
Jules Richardson wrote:
Richard wrote:
The Microdata Prism was designed around a "cpu" which used only one
74181. This actually
was enough to emulate the Adds cursor control the copied. There was
very little else in the
way of features that required other than counters.
It had a processor tank running 24 bit wide firmware to handle the
keyboard, and screen
functions as need be. I don't think it had more than 32 firmware words
however.
The Adds 580 logic was designed around the display, and I don't know
that it had
a cpu per se in the design.
Others in the "no cpu" vein would be the hazeltine terminals, with core
display
memory, but I never had the info to know what those had as logic.
These all used nothing much more exotic than proms and the ALU at the
high end AFIK.
Jim
In article <45F86F35.5080107 at
yahoo.co.uk>,
Jules Richardson <julesrichardsonuk at yahoo.co.uk> writes:
<snip>
The weirder terminals don't use a CPU at all. They use SSI/MSI TTL
logic.
That's what I was wondering. Although I suppose that providing they
have a design that can be coaxed into the same architecture as a
typical terminal, then it doesn't matter as a box can be drawn around
the bit that "looks" like a CPU. 
10:47 a.m.
New subject: OT: Sun CPU card. Anything useful?
PCexchange is selling these for 10 clams. Are they applicable to
anything but a genuine Sun box? Is there any reason to own one?
http://pcexchange-net.stores.yahoo.net/sunmipcica40.html
Cheers,
Chuck
11:14 a.m.
New subject: OT: Sun CPU card. Anything useful?
On 3/15/07, Chuck Guzis <cclist at sydex.com> wrote:
PCexchange is selling these for 10 clams. Are they
applicable to
anything but a genuine Sun box? Is there any reason to own one?
http://pcexchange-net.stores.yahoo.net/sunmipcica40.html
I wasn't able to track down much of anything other than sale listings
on this card, but from what I remember about it, it's primary function
is an embedded PC for running Windows and whatnot. I do not recall
what the latest version of Solaris supports it, but I'd be surprised
if it's still supported under Solaris 10. For $18.95 (w/shipping),
it's _almost_ worth getting one to see if it can be run standalone as
an embedded PC... I see what looks like a space to install an IDE
connector, but the BIOS might only know how to talk to some
application running on the Sun, with a "soft" video adapter (as the
A2088 Bridgeboard did in the Amiga). I occasionally have cause to
want a smallish PC running some embedded task (smart cacheing webcam,
network-attached readout for system status, etc), so as long as I can
stick a flash card in an IDE adapter, attach a network interface, and
hang my peripherals off of parallel and/or serial ports, that's enough
- it doesn't have to have its own video interface.
Anyone have any detailed docs on this card?
Thanks,
-ethan
11:30 a.m.
New subject: OT: Sun CPU card. Anything useful?
On Mar 15, 2007, at 2:14 PM, Ethan Dicks wrote:
I don't have docs, but I've used them quite a bit. This one is
worthless...While this is a current product, this particular one is
its first incarnation, is a very limited design, and has not been
supported by (and won't actually work with) the SunPCi drivers for a
very long time. The best you'll be able to do with this card will
likely be Solaris 7 or possibly 8.
This card was quickly replaced by the SunPCi-II, which will run
with current releases of Solaris, and will run recent Microsoft OSs.
The SunPCi-IIIpro is the current incarnation of this product.
-Dave
--
Dave McGuire
Port Charlotte, FL
PCexchange is
selling these for 10 clams. Are they applicable to
anything but a genuine Sun box? Is there any reason to own one?
http://pcexchange-net.stores.yahoo.net/sunmipcica40.html
I wasn't able to track down much of anything other than sale listings
on this card, but from what I remember about it, it's primary function
is an embedded PC for running Windows and whatnot. I do not recall
what the latest version of Solaris supports it, but I'd be surprised
if it's still supported under Solaris 10. For $18.95 (w/shipping),
it's _almost_ worth getting one to see if it can be run standalone as
an embedded PC... I see what looks like a space to install an IDE
connector, but the BIOS might only know how to talk to some
application running on the Sun, with a "soft" video adapter (as the
A2088 Bridgeboard did in the Amiga). I occasionally have cause to
want a smallish PC running some embedded task (smart cacheing webcam,
network-attached readout for system status, etc), so as long as I can
stick a flash card in an IDE adapter, attach a network interface, and
hang my peripherals off of parallel and/or serial ports, that's enough
- it doesn't have to have its own video interface.
Anyone have any detailed docs on this card?
1:07 p.m.
New subject: OT: Sun CPU card. Anything useful?
On 15 Mar 2007 at 14:30, Dave McGuire wrote:
I don't have docs, but I've used them quite
a bit. This one is
worthless...While this is a current product, this particular one is
its first incarnation, is a very limited design, and has not been
supported by (and won't actually work with) the SunPCi drivers for a
very long time.
Noted. I'll pass.
I won't even discuss the $15 credit card terminal on the same site...
:)
Cheers,
Chuck
1:26 p.m.
New subject: OT: Sun CPU card. Anything useful?
--- Chuck Guzis <cclist at sydex.com> wrote:
On 15 Mar 2007 at 14:30, Dave McGuire wrote:
Weren't there a couple of these cards, like one with
a Celeron and another with a P3. I have the Celeron
version, but have yet to install it. Weirdstuff used
to have 1 or the other also.
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html
I don't have docs, but I've used them
quite a
bit. This one is
worthless...While this is a current product, this
particular one is
its first incarnation, is a very limited design,
and has not been
supported by (and won't actually work with)
the
SunPCi drivers for a
very long time.
Noted. I'll pass.
I won't even discuss the $15 credit card terminal on
the same site...
:)
Cheers,
Chuck
3:44 p.m.
New subject: OT: Sun CPU card. Anything useful?
On Mar 15, 2007, at 4:26 PM, Chris M wrote:
Weren't there a couple of these cards, like one
with
a Celeron and another with a P3. I have the Celeron
version, but have yet to install it. Weirdstuff used
to have 1 or the other also.
The one Chuck found is a SunPCi-I. There's a -II, a -IIpro (which
I have), a -III, and a -IIIpro (which is current). The -II is the
most recent one that is useful. It takes a very slight tweak to get
it running under Solaris 10.
-Dave
--
Dave McGuire
Port Charlotte, FL
11:21 p.m.
New subject: OT: Sun CPU card. Anything useful?
Chuck,
Do you need a Credit Card Terminal? If so I have one you can have for the
shipping cost. Let me know and I will dig it out and give you all the specs
and such. It is maybe 10 years old and is a Hypercom Unit I believe.
Greg Manuel
gmanuel at gmconsulting dot net
-----Original Message-----
From: Chuck Guzis [mailto:cclist at sydex.com]
Sent: Thursday, March 15, 2007 4:08 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: OT: Sun CPU card. Anything useful?
On 15 Mar 2007 at 14:30, Dave McGuire wrote:
I don't have docs, but I've used them
quite a bit. This one is
worthless...While this is a current product, this particular one is
its first incarnation, is a very limited design, and has not been
supported by (and won't actually work with) the SunPCi drivers for a
very long time.
Noted. I'll pass.
I won't even discuss the $15 credit card terminal on the same site...
:)
Cheers,
Chuck
16 Mar
16 Mar
10:05 a.m.
New subject: OT: Sun CPU card. Anything useful?
On 16 Mar 2007 at 2:21, G Manuel (GMC) wrote:
Do you need a Credit Card Terminal? If so I have one
you can have for the
shipping cost. Let me know and I will dig it out and give you all the specs
and such. It is maybe 10 years old and is a Hypercom Unit I believe.
No, we have one already, so I don't know what I'd do with one. It
might be fun as a "fool around" box, but most of these are 8051-type
boxes. A Z80/Z800/x86 model might be interesting however.
Back around 1992, our merchant card services tried to set up on-line
credit card transaction recording and asked if we wanted to
participate. We got a whole bunch of documents about how the system
internals operated. That's all probably changed now--and we signed
an NDA at any rate.
But I did write a few BASIC programs for filling in "Luhn" codes.
More than a few times, a customer would hand-write or copy his credit
card number and one or more digits would be unreadable. It was
pretty simple to write a little program to take "?" for the unknown
digits and back-compute the possibilities. It saved us a lot of
trouble on a couple of occasions.
Cheers,
Chuck
11:27 a.m.
New subject: Credit card terms (was: Sun CPU card. Anything useful?)
Do you need a
Credit Card Terminal? If so I have one you can have for the
No, we have one
already, so I don't know what I'd do with one. It
might be fun as a "fool around" box, but most of these are 8051-type
boxes. A Z80/Z800/x86 model might be interesting however. 
15 Mar
15 Mar
11:34 p.m.
New subject: OT: Sun CPU card. Anything useful?
A friend of mine had a SUN PC card (K6 based I think). From what I
researched they seemed buggy, if the software controlling the card crashed
so did the whole SUN system.
http://www.unixreview.com/documents/s=1255/urm9910a/
16 Mar
16 Mar
1:27 a.m.
New subject: OT: Sun CPU card. Anything useful?
Teo Zenios wrote:
A friend of mine had a SUN PC card (K6 based I think).
From what I
researched they seemed buggy, if the software controlling the card crashed
so did the whole SUN system.
http://www.unixreview.com/documents/s=1255/urm9910a/
I have one of the Chimera cards here, 128mb 733mhz Intel Celeron.
I believe they open up a shared window on the pci bus to mirror their
memory and some controls for the Intel cpu. It would not be surprising
if they system crashed if you crashed the sun board.
When sun announced open solaris, I was hoping that they would
release the drivers for all these arcane cards. I have not tried to
pull down a sparc open solaris, nor do I even know if they made it
possible to build the sparc platform with the open source.
However it would be interesting to be able to put up several of
these cards in an Ultra 10 all running open solaris (if it is possible
on the 256 mb you could put in) or linux.
This is way off topic, but these will be interesting "vintage" cards
to have just because Sun has now released Solaris so it should
be possible to archive what it takes to have a fun toy for the
future when it is vintage. It certainly would be an unusual
system to have maybe 4 of these running in a box, co hosted
by a sparc.
These are plentiful now but will probably dry up soon, so
picking the best ones and acquiring them would be a good
idea. Hopefully those who have posted in this thread could
post or email off list if this is too off topic to continue and
suggest a workable setup.
Jim
1:50 a.m.
New subject: OT: Sun CPU card. Anything useful?
On Mar 16, 2007, at 2:34 AM, Teo Zenios wrote:
A friend of mine had a SUN PC card (K6 based I think).
From what I
researched they seemed buggy, if the software controlling the card
crashed
so did the whole SUN system.
http://www.unixreview.com/documents/s=1255/urm9910a/
Yes, those older ones are garbage. The -II and later models are
quite good, fast, and rock-stable. I've used the -II and -IIpro
models quite a bit with much success.
-Dave
--
Dave McGuire
Port Charlotte, FL
7:32 a.m.
New subject: OT: Sun CPU card. Anything useful?
Teo Zenios wrote:
A friend of mine had a SUN PC card (K6 based I think).
From what I
researched they seemed buggy, if the software controlling the card crashed
so did the whole SUN system.
http://www.unixreview.com/documents/s=1255/urm9910a/
The K6 version sucked pretty hard, but the SunPCi II isn't bad at
all. It has its own USB and ethernet adapters, and rumor has it that
the IDE chipset is functional if you put a header on the card.
Somewhere I have an Sbus 486 board. I never found software for it,
so I couldn't tell ya how well it works.
Doc
9:55 a.m.
New subject: OT: Sun CPU card. Anything useful?
On Fri, 16 Mar 2007, Doc Shipley wrote:
Teo Zenios wrote:
I have this, too. Using 2.6 and the SunPC2 software I have not been able
to bring this one up. It always toled something about problems with
kbd and later stopped loading the DOS in a very early stage.
Machine was SS20, Dual Ross 150, 512M, V-SIMM, 2*9GB
Erik.
A friend of mine had a SUN PC card (K6 based I
think). From what I
researched they seemed buggy, if the software controlling the card crashed
so did the whole SUN system.
http://www.unixreview.com/documents/s=1255/urm9910a/
The K6 version sucked pretty hard, but the SunPCi II isn't bad at
all. It has its own USB and ethernet adapters, and rumor has it that
the IDE chipset is functional if you put a header on the card.
Somewhere I have an Sbus 486 board. I never found software for it,
so I couldn't tell ya how well it works.
14 Mar
14 Mar
2:24 p.m.
This topic reminds me to ask - are there any deeply detailed docs for
DEC terminals out there? I'm thinking of schematics for VT100s
through VT240s (since I have just about one of everything). One
"project" I just thought of was to take the board from a real VT220
and wrap it in just enough stuff to be able to plug either an LK201 or
a modern PS/2 or USB keyboard into one end, and a VGA monitor into the
other end - keyboard conversion would most likely take a
microcontroller, and converting the video to something at 31KHz (VGA
frequencies) might be a bit cumbersome to do (perhaps by grafting on
an Amiga flicker-fixer-like circuit), but to have a brick about the
size of a hardback book that one feeds +12VDC to, that _is_ a real
terminal, might be an interesting thing to have around the house. One
could drop it onto a KVM or just put it in ones toolbag as a portable
terminal, to be used with a keyboard and monitor already at the
destination site. A VT240 slab is reminiscent of this, in that it
doesn't have an integral monitor, but it's a lot larger than a wrapped
VT220 mainboard would be, and they aren't as common as VT220s.
Perhaps this is yet another thing better done with a microcontroller
and emulation software, but it's mostly a hardware project to take an
existing, known-compatible board from a classic product rather than to
roll one's own.
-ethan
3:11 p.m.
From: "Ethan Dicks"
Perhaps this is yet another thing better done with a
microcontroller
and emulation software, but it's mostly a hardware project to take an
existing, known-compatible board from a classic product rather than to
roll one's own.
I was thinking of something more like an FPGA demo board -- mine has
tons of gates, memory, PS2, VGA, the serial and parallel port are no
problem, etc.
Then you could express the hardware of the machine in VHDL or the
like, and just code in the firmware, on that hardware. A little
fairly standard magic to output to the VGA port and translate from
the PS2 keyboard, and you'd be done.
If an additional terminal type is needed, it would be some ROM dumps
and VHDL tweaks.
Hey, if it can do a PDP-8, it ought to be able to emulate a VT100 :-).
Vince
3:33 p.m.
On 3/14/07, Vincent Slyngstad <vrs at msn.com> wrote:
From: "Ethan Dicks"
Looking at an IOB6120, that's clearly no stretch (and the VHDL is
already in there for a VT52 w/PS/2 and VGA ;-)
Perhaps this is yet another thing better done
with a microcontroller
and emulation software...
I was thinking of something more like an FPGA demo board -- mine has
tons of gates, memory, PS2, VGA, the serial and parallel port are no
problem, etc. If an additional terminal type is needed, it would be
some ROM dumps
and VHDL tweaks.
As long as there's room for a bunch of ROM. I've seen raster
terminals with 68000s and a *lot* of 28-32-pin ROM chips.
Hey, if it can do a PDP-8, it ought to be able to
emulate a VT100 :-).
Entirely so. The question I have now is... what would it cost to make
one of these? If it's under $100, then will have a much larger
audience than if it costs $250. I spent quite a bit for an IOB6120
bag of parts, and I suppose that board as rigged to be a generic
classic terminal would already be cheaper than 2-3 real classic
terminals, but, as with anything non-essential, the cheaper you can
make it, the larger the potential audience.
Still... sounds like an interesting proposition to me.
-ethan
3:44 p.m.
The best thing out there for terminal emulation now is Kermit-95.
On 3/14/07, Ethan Dicks <ethan.dicks at gmail.com> wrote:
On 3/14/07, Vincent Slyngstad <vrs at msn.com> wrote:
--
--
d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now!
pechter-at-gmail.com
From: "Ethan Dicks"
Looking at an IOB6120, that's clearly no stretch (and the VHDL is
already in there for a VT52 w/PS/2 and VGA ;-)
Perhaps this is yet another thing better done
with a microcontroller
and emulation software...
I was thinking of something more like an FPGA demo board -- mine has
tons of gates, memory, PS2, VGA, the serial and parallel port are no
problem, etc. If an additional terminal type is needed, it
would be some ROM dumps
and VHDL tweaks.
As long as there's room for a bunch of ROM. I've seen raster
terminals with 68000s and a *lot* of 28-32-pin ROM chips.
Hey, if it can do a PDP-8, it ought to be able to
emulate a VT100 :-).
Entirely so. The question I have now is... what would it cost to make
one of these? If it's under $100, then will have a much larger
audience than if it costs $250. I spent quite a bit for an IOB6120
bag of parts, and I suppose that board as rigged to be a generic
classic terminal would already be cheaper than 2-3 real classic
terminals, but, as with anything non-essential, the cheaper you can
make it, the larger the potential audience.
Still... sounds like an interesting proposition to me.
-ethan
8:33 p.m.
----- Original Message -----
From: "Ethan Dicks" <ethan.dicks at gmail.com>
Cool! I should go look at that :).
Well, there's 16Mbit of flash and 256Mbit of SDRAM in mine.
(The PDP-8 is actually implemented with the 32Kx12 of block
RAM in the FPGA itself, and doesn't use any of that. Likewise,
it may be possible to represent some or all of a terminal's ROM
in the FPGA itself.)
Well, I think I paid about $200 for mine, but OTOH, it seems like it
would pretty much do the job, right out of the box. (Except for the
"small matter" of programming.)
Vince
I was thinking
of something more like an FPGA demo board -- mine has
tons of gates, memory, PS2, VGA, the serial and parallel port are no
problem, etc.
Looking at an IOB6120, that's clearly no stretch (and the VHDL is
already in there for a VT52 w/PS/2 and VGA ;-) If an
additional terminal type is needed, it would be some ROM dumps
and VHDL tweaks.
As long as there's room for a bunch of ROM. I've seen raster
terminals with 68000s and a *lot* of 28-32-pin ROM chips. Hey, if it can
do a PDP-8, it ought to be able to emulate a VT100 :-).
Entirely so. The question I have now is... what would it cost to make
one of these? If it's under $100, then will have a much larger
audience than if it costs $250. I spent quite a bit for an IOB6120
bag of parts, and I suppose that board as rigged to be a generic
classic terminal would already be cheaper than 2-3 real classic
terminals, but, as with anything non-essential, the cheaper you can
make it, the larger the potential audience.
Still... sounds like an interesting proposition to me.
8:47 p.m.
On 3/14/07, Vincent Slyngstad <vrs at msn.com> wrote:
http://www.jkearney.com/sbc6120/
Looking at an
IOB6120, that's clearly no stretch (and the VHDL is
already in there for a VT52 w/PS/2 and VGA ;-)
Cool! I should go look at that :). Well, there's 16Mbit of flash and 256Mbit of SDRAM
in mine.
Hmm... seems like enough to load several implementations at once (like
multiple Wyse or multiple VT100-family terminals) - just build in some
way to switch models...
Well, I think I paid about $200 for mine, but OTOH, it
seems like it
would pretty much do the job, right out of the box. (Except for the
"small matter" of programming.)
Programming doesn't cost the second user anything ;-)
Hmm... $200 for an assembled board with those characteristics doesn't
sound _too_ bad, but there's still the matter of buffers/drivers for
off-board I/O with TTL-ish devices, plus connector cost - I can see it
running closer to $220-$250 for something that's ready to program and
use. That might be in the acceptable range for a number of folks.
-ethan
11:32 p.m.
From: "Ethan Dicks" <ethan.dicks at gmail.com>
Sure, and there are a few tactile switches on the board (and of course
a boatload of potential input pins).
I have my XESS board plugged into a breadboard, which keeps the pins
off the table, and makes room for a MAX232, some caps and resistors,
and a DE-9 connector for the serial link. It's powered by a regulated
5V brick from JameCo. (Other boards might well come with the MAX232.)
It shouldn't take much external stuff, as the outputs are LSTTL
compatible, and the inputs nearly so (but mine are not 5V tolerant).
I also ran the LEDs in a binary clock off the outputs without problems,
with just current limit resistors in the common row paths.
But I basically agree with the $220-$250 estimate. It isn't too
hard to burn an extra $20 here or there, by the time you added a
brick, a nice box, etc.
Vince
On 3/14/07, Vincent Slyngstad <vrs at msn.com>
wrote:
http://www.jkearney.com/sbc6120/
Sure enough, there is a GPL version of the VHDL for the VT52 there.
Looking
at an IOB6120, that's clearly no stretch (and the VHDL is
already in there for a VT52 w/PS/2 and VGA ;-)
Cool! I should go look at that :). Well,
there's 16Mbit of flash and 256Mbit of SDRAM in mine.
Hmm... seems like enough to load several implementations at once (like
multiple Wyse or multiple VT100-family terminals) - just build in some
way to switch models... Well, I think
I paid about $200 for mine, but OTOH, it seems like it
would pretty much do the job, right out of the box. (Except for the
"small matter" of programming.)
Programming doesn't cost the second user anything ;-)
Hmm... $200 for an assembled board with those characteristics doesn't
sound _too_ bad, but there's still the matter of buffers/drivers for
off-board I/O with TTL-ish devices, plus connector cost - I can see it
running closer to $220-$250 for something that's ready to program and
use. That might be in the acceptable range for a number of folks. 
15 Mar
15 Mar
10 a.m.
"Vincent Slyngstad" wrote:
From: "Ethan Dicks"
I did this last summer/fall with an XESS board. Just the basics, however,
more like a tty than anything else. It wasn't hard in verilog - I'll put
the code up soon...
-brad
Perhaps this is yet another thing better done
with a microcontroller
and emulation software, but it's mostly a hardware project to take an
existing, known-compatible board from a classic product rather than to
roll one's own.
I was thinking of something more like an FPGA demo board -- mine has
tons of gates, memory, PS2, VGA, the serial and parallel port are no
problem, etc.
Then you could express the hardware of the machine in VHDL or the
like, and just code in the firmware, on that hardware. A little
fairly standard magic to output to the VGA port and translate from
the PS2 keyboard, and you'd be done.
If an additional terminal type is needed, it would be some ROM dumps
and VHDL tweaks.
Hey, if it can do a PDP-8, it ought to be able to emulate a VT100 :-).
6492
days inactive
6494
days old
48 comments
23 participants
participants (23)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
brad＠heeltoe.com -
cclist＠sydex.com -
chrism3667＠yahoo.com -
dave06a＠dunfield.com -
derschjo＠msu.edu -
dgriffi＠cs.csubak.edu -
doc＠mdrconsult.com -
erik＠baigar.de -
ethan.dicks＠gmail.com -
gmanuel＠gmconsulting.net -
julesrichardsonuk＠yahoo.co.uk -
jwest＠ezwind.net -
jwstephens＠msm.umr.edu -
legalize＠xmission.com -
mcguire＠neurotica.com -
paul＠frixxon.co.uk -
pechter＠gmail.com -
pete＠dunnington.plus.com -
robert＠irrelevant.com -
teoz＠neo.rr.com -
vrs＠msn.com