forked from arti/vt1200
checkpoint: VT1200 reverse-engineering workspace before board-model work
This commit is contained in:
SDD committed
commit
acb92d3e44
325 files changed
+951894
No files matched your search
Binary file not shown.
@@ -0,0 +1,807 @@
|
||||
X Window Terminals
|
||||
|
||||
Björn Engberg and Thomas Porcher
|
||||
|
||||
1 Abstract
|
||||
|
||||
X window terminals occupy a niche between X window workstations
|
||||
and graphics terminals. The purpose of terminals in general is
|
||||
to provide low-cost user access to host computers or smaller
|
||||
dedicated systems. X window terminals further the advance in
|
||||
graphics terminals and provide new and interesting ways to
|
||||
utilize host systems. Ethernet cable provides for graphics
|
||||
performance previously not seen in terminals. The X Window
|
||||
System developed by MIT allows multiple applications to be
|
||||
displayed and controlled from the user's workstation. Now,
|
||||
with X window terminals, the same powerful user interface is
|
||||
available on host and other non-workstation computers. [The
|
||||
XTERMINALS paper starts here.]
|
||||
|
||||
In mid 1987, the Video, Image, and Print Systems (VIPS) Group
|
||||
began the design of Digital's first X window terminal, the
|
||||
VT1000 terminal and its code upgrade, the VT1200 terminal.
|
||||
Our goal was to design and implement an X window terminal that
|
||||
would allow the use of windowing capabilities on large computer
|
||||
systems. In 1989, Digital developed the VT1300 X terminal and
|
||||
in 1991 the VXT 2000 X terminal. The designs of these X window
|
||||
terminals are all quite different. Our design approach changed
|
||||
as the underlying technology changed.
|
||||
|
||||
This paper first compares host-system computing with applica-
|
||||
tions run on workstations. It summarizes the significance of the
|
||||
X Window System developed by MIT and discusses the client-server
|
||||
model. The paper then presents the need for X window terminals
|
||||
and follows their development stages. It compares and contrasts
|
||||
Digital's different design strategies for the VT1000, VT1200,
|
||||
and VT1300 X terminals. The paper concludes with a summary of
|
||||
the recently announced VXT 2000 X terminal.
|
||||
|
||||
|
||||
Digital Technical Journal Vol. 3 No. 4 Fall 1991 1
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
2 Background
|
||||
|
||||
Before the development of the X Window System, there was very
|
||||
little overlap in functionality between workstations and other
|
||||
kinds of computers. Workstations had stunning and fast graph-
|
||||
ics, and many powerful applications were available on them.
|
||||
Those applications were not available to users of basic 80-
|
||||
by-24 character-cell text display terminals connected to a
|
||||
host system located in a clean room. Graphics terminals, of
|
||||
course, allowed the use of ReGIS or another protocol for math
|
||||
and business graphics, but their performance was far below the
|
||||
expectations of a workstation user. Few people have the patience
|
||||
to run, for example, a computer-aided design application on a
|
||||
VT240 terminal, assuming such a version of the application is
|
||||
available.
|
||||
|
||||
Although a workstation offers fast graphics capabilities, its
|
||||
applications sometimes need more CPU power or more disk space
|
||||
to do calculations in a timely fashion. Graphics applications
|
||||
written for workstations could not run on faster host computers,
|
||||
which did not provide a display. Nor was there a standard way
|
||||
to get data from the host to display on a workstation. Each
|
||||
application required a unique solution to this problem.
|
||||
|
||||
Since the introduction of the new client-server model of comput-
|
||||
ing and modern networks, many tasks can be divided into subtasks
|
||||
that can run on the most suitable processor. The X Window Sys-
|
||||
tem uses the client-server approach, as shown in Figure 1. The
|
||||
application is viewed as an X client, and a workstation or a
|
||||
terminal can run an X server that controls the display. The X
|
||||
server also controls input from the keyboard and mouse or other
|
||||
pointing devices.
|
||||
|
||||
An X client and an X server use an X wire to communicate, as
|
||||
shown in Figure 2. The X wire is simply a two-way error-free
|
||||
byte stream, which can be implemented in many different ways.
|
||||
The X Window System architecture does not stipulate how the X
|
||||
wire should be implemented, but several de facto standards have
|
||||
emerged. Manufacturers have designed X wires usually based on
|
||||
|
||||
2 Digital Technical Journal Vol. 3 No. 4 Fall 1991
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
the data transport mechanisms that were available and conve-
|
||||
nient when the X Window System was implemented. The X wires use
|
||||
transmission control protocol/internet protocol (TCP/IP), DEC-
|
||||
net, Local Area Transport (LAT), and other protocols, and even
|
||||
shared memory buffers as a transport to avoid protocol over-
|
||||
head. A single implementation often supports several transport
|
||||
mechanisms.
|
||||
|
||||
The X server typically executes on a processor with display
|
||||
hardware. The X client can execute on almost any processor. It
|
||||
may execute on the same CPU as the X server, or it may execute
|
||||
on a host, another workstation, or a compute server. The X
|
||||
server can be connected to several X clients simultaneously,
|
||||
with any combination of local (running on the same CPU) or
|
||||
remote (running on another CPU) X clients. The X server treats
|
||||
local and remote clients equally.
|
||||
|
||||
3 Workstation Environment
|
||||
|
||||
Figure 3 compares a traditional non-X windowing workstation with
|
||||
an X windowing workstation. In both workstations the application
|
||||
must use a graphics library to communicate with the display
|
||||
hardware and software.
|
||||
|
||||
In an X windowing client environment, the library of routines
|
||||
is called Xlib. An application designer can choose from a wide
|
||||
variety of toolkits, which are essentially a level of additional
|
||||
library routines between the application and Xlib. The use of
|
||||
a toolkit can significantly reduce the amount of work an ap-
|
||||
plication programmer has to do. The application software, Xlib,
|
||||
optional toolkit, and other libraries compose the X client, as
|
||||
shown in Figure 4.
|
||||
|
||||
With few exceptions, the X server comes with the display hard-
|
||||
ware and input devices (keyboard and pointer) indicated in
|
||||
Figure 5.
|
||||
|
||||
|
||||
|
||||
Digital Technical Journal Vol. 3 No. 4 Fall 1991 3
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
The X Window System with its flexibility neatly solves the prob-
|
||||
lems of CPU power and disk space versus display availability.
|
||||
Applications written for X can execute on a wide variety of com-
|
||||
puters, and the results can be displayed on any of a multitude
|
||||
of devices, even on a workstation that would not have the ca-
|
||||
pacity to run the application locally. Figure 6 shows how the X
|
||||
Window System fits into a network environment.
|
||||
|
||||
The X Window System has already generated many useful appli-
|
||||
cations, and its widespread popularity ensures that many more
|
||||
applications will be made available in the future.
|
||||
|
||||
4 Need for X Terminals
|
||||
|
||||
In a study to determine how workstations are used, the VIPS
|
||||
Group found that many users did not take advantage of the full
|
||||
potential of their workstations. In a software development or
|
||||
document editing environment, the users often set up their work-
|
||||
stations as terminals. They usually created a few terminal emu-
|
||||
lation windows and used SET HOST or RLOGIN commands to connect
|
||||
to a host system on which they stored their working environment
|
||||
and files. Only two features of a workstation were frequently
|
||||
used. Users kept several terminal emulators on their screens
|
||||
at the same time, and set the terminal emulator windows to be
|
||||
larger than 80 by 24 characters. Only rarely did the average
|
||||
workstation user take advantage of the full power of graphics
|
||||
applications.
|
||||
|
||||
The results of our study indicated a need for a cost-effective
|
||||
alternative to a workstation that would provide the features
|
||||
desired by a large number of users. We envisioned a new kind of
|
||||
terminal, one that would allow people to have multiple windows
|
||||
of arbitrary size, to connect with multiple hosts, and, since
|
||||
the X architecture allowed it, to be able to use the same kind
|
||||
of graphics as a workstation.
|
||||
|
||||
|
||||
|
||||
|
||||
4 Digital Technical Journal Vol. 3 No. 4 Fall 1991
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
From an X architecture standpoint, X terminals and X worksta-
|
||||
tions are quite similar. They can in fact use the same hardware.
|
||||
For example, Digital's VT1300 terminal runs on the same hardware
|
||||
as the VAXstation 3100 workstation. X terminal software can also
|
||||
be made to run well on hardware platforms that are not suitable
|
||||
for workstations.
|
||||
|
||||
The main architectural difference between X terminal and X
|
||||
workstation software is that X terminals are closed systems
|
||||
that do not support local user applications. Although this
|
||||
may seem to be an unnecessary restriction, it does allow X
|
||||
terminals to be made for less money. An open system that allows
|
||||
any user application to run locally must have an established
|
||||
CPU architecture, a supported operating system, such as the VMS,
|
||||
UNIX, or ULTRIX system, and, subsequently, sufficient memory and
|
||||
/or disk space to support such an environment. A closed system,
|
||||
on the other hand, can be designed with simpler hardware, a
|
||||
smaller operating system, less memory, and thus lower cost. The
|
||||
absence of the ability to run user applications locally does
|
||||
not impact usability significantly since the user can run any
|
||||
desired application on another CPU. Digital's VT1000 and VT1200
|
||||
X terminals were designed based on this approach.
|
||||
|
||||
5 X Terminal Environment
|
||||
|
||||
X terminals often have local applications, but they must be
|
||||
built into the terminal by the designers. The VT1200 terminal
|
||||
has a video terminal emulator (VTE), a window manager, and a
|
||||
terminal manager as the local applications. The VTE allows the
|
||||
VT1200 terminal to make American National Standards Institute
|
||||
(ANSI) character-cell connections to a host, via the Ethernet
|
||||
or the serial lines. This capability makes the VT1200 terminal
|
||||
useful in an environment that does not have X window support.
|
||||
|
||||
Although any X server can run windows software, it does not
|
||||
provide a user interface. To manipulate the windows, the user
|
||||
needs a window manager. The window manager creates window frames
|
||||
that allow the user to invoke functions to move windows, resize
|
||||
|
||||
Digital Technical Journal Vol. 3 No. 4 Fall 1991 5
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
windows, change stacking order, and use icons. This capability
|
||||
also makes the VT1200 terminal useful when no host is available
|
||||
to run a remote window manager. A terminal with a local window
|
||||
manager generates less network traffic, and window management is
|
||||
not slowed by host congestion or network round-trip delays. The
|
||||
VT1200 X terminal allows use of a remote window manager, if the
|
||||
user prefers a different style of window management.
|
||||
|
||||
The local terminal manager provides the user interface to initi-
|
||||
ate connections to host systems. It is also responsible for the
|
||||
terminal customization interface.
|
||||
|
||||
All clients communicate with the X server using standard X wire
|
||||
commands only. Any window manager, remote or local, can manage
|
||||
all the windows on the screen, regardless of whether the clients
|
||||
are remote or local.
|
||||
|
||||
6 Development of X Windor Terminals
|
||||
|
||||
The development process of the VT1000 and VT1200 X terminals has
|
||||
important lessons to teach us. The knowledge we gained in 1987
|
||||
has helped us develop future generations of X terminals.
|
||||
|
||||
When we designed the VT1000 X terminal and its code upgrade,
|
||||
the VT1200, we held many discussions within the group and with
|
||||
people from other groups. We planned many iterations before we
|
||||
arrived at the final architecture. It was by no means the only
|
||||
way to design an X terminal, and in 1989 we tried a different
|
||||
approach with the design of the VT1300 terminal. We knew that
|
||||
the best decision at a particular time might be very different
|
||||
from the best decision one year later, since the technical
|
||||
and marketing environment is constantly changing. New tools,
|
||||
standards, and practices enter the field while others become
|
||||
obsolete. Newer products must always have new features to meet
|
||||
changing technology requirements.
|
||||
|
||||
|
||||
|
||||
|
||||
6 Digital Technical Journal Vol. 3 No. 4 Fall 1991
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
Hardware Platform
|
||||
|
||||
Our first step was to discuss the hardware platform and select
|
||||
the kind of CPU to use, memory size, I/O considerations, type of
|
||||
display, etc. We studied many different CPUs to determine which
|
||||
one would provide the most capabilities for the lowest cost.
|
||||
A VAX chip was rejected because, at the time, it was far too
|
||||
expensive for the required price range of the VT1000 terminal.
|
||||
The Motorola 68000 series CPUs are quite powerful, but we had
|
||||
to consider other factors such as availability of software and
|
||||
hardware tools, cross compilers and linkers that could run on
|
||||
VMS, and hardware debugging facilities of sufficient power.
|
||||
We finally selected Texas Instruments' TMS34010 microprocessor
|
||||
with video support and several built-in graphics instructions
|
||||
that made it a cost-effective solution. It also came with VMS
|
||||
development tools, a C compiler, an assembler and linker, a
|
||||
single-step, hardware trace buffer with disassembler, and a
|
||||
powerful in-circuit emulator that made it possible to control
|
||||
execution in detail, inspect registers and memory, and set
|
||||
break points and hardware watch points (for example, break when
|
||||
writing value x into location y).
|
||||
|
||||
We further discussed the kind of I/O to use. A sample imple-
|
||||
mentation of the MIT X server on a VAXstation 2000 workstation
|
||||
and a primitive serial line protocol showed, as expected, that
|
||||
serial lines were clearly insufficient to carry the X wire pro-
|
||||
tocol without some compression of the wire protocol itself.
|
||||
We had to build Digital's first X terminal with an Ethernet
|
||||
interface.
|
||||
|
||||
We needed to determine if this hardware platform could give us
|
||||
sufficient performance. We made several performance estimates,
|
||||
based on what little we knew then about the X server and other
|
||||
software components. We went through each step in as much detail
|
||||
as we could (before anything was built). We calculated how
|
||||
many instructions were necessary to perform each task in the
|
||||
chain of receiving a command and displaying it on the screen.
|
||||
By knowing the speed of the CPU, we could estimate performance
|
||||
in characters or vectors per second. Our estimates showed that
|
||||
|
||||
Digital Technical Journal Vol. 3 No. 4 Fall 1991 7
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
the VT1000 X terminal would not be exceedingly fast, but the
|
||||
performance would most probably be sufficient, definitely faster
|
||||
than a VAXstation 2000 in most cases.
|
||||
|
||||
In retrospect, actual performance of the VT1000 terminal and the
|
||||
later software upgrade, the VT1200, was close to our estimates,
|
||||
but it took several passes of code optimization to achieve such
|
||||
performance.
|
||||
|
||||
We also discussed alternate hardware designs for performance
|
||||
improvements. One solution proposed two CPUs, the TMS34010
|
||||
microprocessor to handle the display and a 68000 microprocessor
|
||||
to handle I/O and other tasks. Unfortunately, we found no easy
|
||||
way to balance the workload between the two CPUs. We estimated
|
||||
that the different software components would have the following
|
||||
relative CPU demands:
|
||||
|
||||
Interrupts, 5 percent
|
||||
Communications, 10 percent
|
||||
Operating system, 5 percent
|
||||
X server (minus display routines), 60 percent
|
||||
Display routines, 20 percent
|
||||
|
||||
To equalize the load between the CPUs, we would have had to
|
||||
split the X server in two, a solution that was not feasible.
|
||||
Any other split of tasks would cause one CPU to spend most of
|
||||
its time waiting for the other, and the overall performance
|
||||
gain would be minimal. Communication between multiple CPUs is
|
||||
complex and is very difficult to debug. Therefore, we decided
|
||||
that two CPUs were not worth the trouble or the cost. The best
|
||||
way to double performance is to install a single CPU that is
|
||||
twice as fast. At that time, the TMS34020 was already being
|
||||
mentioned as a follow-up microprocessor. Since its software
|
||||
would be compatible with the TMS34010, we decided to keep it in
|
||||
mind for possible use in a future terminal.
|
||||
|
||||
|
||||
|
||||
|
||||
8 Digital Technical Journal Vol. 3 No. 4 Fall 1991
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
Code Selection
|
||||
|
||||
The use of read-only memory (ROM)-based code versus downloaded
|
||||
code has been debated for some time. ROM-based code starts up
|
||||
faster and incurs less network traffic at startup time (espe-
|
||||
cially on a site with many X terminals), but is not flexible
|
||||
when software is upgraded. On the other hand, downloaded code
|
||||
can be easily distributed. An entire site can be upgraded with
|
||||
one or a few installations by a system manager as opposed to
|
||||
changing ROMs in a large number of terminals. (With the VT1200
|
||||
X terminal, customers can change ROM boards.) From the point
|
||||
of view of terminal business, it made sense to use ROM-based
|
||||
code in 1987. We reasoned that not all sites would have Eth-
|
||||
ernet, but with ROMs the X terminal would still be useful as a
|
||||
multiwindow terminal emulator. We realized that such concerns
|
||||
would change with time, and on the whole, downloaded code would
|
||||
become the better approach. The only exceptions would be in the
|
||||
home or small office markets where a boot host or an Ethernet
|
||||
might not be available. Subsequent X terminals are being made in
|
||||
both downloaded (for example, in the VT1300 terminal) and ROM
|
||||
versions.
|
||||
|
||||
Operating System Selection
|
||||
|
||||
Next we considered which operating system to use. We looked at
|
||||
other vendors' operating systems, but found they were either too
|
||||
complex and big or inadequate. One of our coworkers had written
|
||||
a very compact operating system for a VAX system used on another
|
||||
project. We used it in our prototype and then adapted it for the
|
||||
TMS34010 processor. We implemented additional functions to run
|
||||
the rest of the software with minimum changes.
|
||||
|
||||
There are many advantages to working with "your own" operat-
|
||||
ing system. It is easy to make changes, to work around tricky
|
||||
problems, and to make special enhancements. But operating sys-
|
||||
tem code is difficult to debug. Timing is very critical, and
|
||||
throughout the project, we found strange bugs in code that had
|
||||
initially appeared to be all right to everyone involved. We
|
||||
found bugs under heavy load conditions after a rare sequence of
|
||||
|
||||
Digital Technical Journal Vol. 3 No. 4 Fall 1991 9
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
events uncovered little timing windows and race conditions that
|
||||
had not been handled properly. Even with in-circuit emulators,
|
||||
such bugs could take weeks to track down.
|
||||
|
||||
In the VT1300 we decided to use the VAXELN operating system. We
|
||||
wanted to avoid the possibility of time wasted on finding and
|
||||
patching holes in the design of a new operating system.
|
||||
|
||||
Local Terminal Manager
|
||||
|
||||
The VT1000 X terminal is self-starting at power-up, but without
|
||||
a host system, it needs a local user interface. We decided that
|
||||
this interface should resemble a workstation session manager and
|
||||
thus called it the local terminal manager. Although it covers
|
||||
a different set of functions, we wanted the local terminal
|
||||
manager to implement a similar set of objects and operations
|
||||
(the "look and feel" or style) of a workstation session manager.
|
||||
The style of the DECwindows session manager was chosen to make
|
||||
it easier for a user to switch between an X terminal and a
|
||||
DECwindows workstation. We wrote a subset toolkit for all the
|
||||
"customize" screens and ensured that the VTE could use the same
|
||||
subset toolkit for its "customize" screens. As DECwindows has
|
||||
progressed, subsequent X terminals have adapted the new user
|
||||
interface preferences, in this case Motif.
|
||||
|
||||
Local Terminal Emulator
|
||||
|
||||
We considered a local terminal emulator to be an important
|
||||
component. We knew that X-based terminal emulators could run on
|
||||
the host, but in 1987 hosts with X windowing support were rare.
|
||||
Since we were in the terminal group, a terminal that could not
|
||||
manipulate ordinary text by itself was considered unsellable.
|
||||
We wanted the ability to access both X and non-X hosts and we
|
||||
wanted to support multiple text windows. Therefore we defined
|
||||
the terminal emulator as an X client so that text windows could
|
||||
coexist with X client windows. This feature has proved to be
|
||||
exceptionally popular. A large number of users use nothing but
|
||||
video terminal emulator windows. They are not interested in
|
||||
|
||||
10 Digital Technical Journal Vol. 3 No. 4 Fall 1991
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
X windowing graphics, but do want multiple and/or larger text
|
||||
windows on a large screen.
|
||||
|
||||
Local Window Manager
|
||||
|
||||
We debated whether or not to implement a local window manager.
|
||||
The DECwindows window manager was under development and was con-
|
||||
stantly changing. The DECwindows window manager contained far
|
||||
too many VMS dependencies to be ported easily. Also the X ter-
|
||||
minal did not have enough memory to run the DECwindows toolkit
|
||||
locally. We could have ported other window managers, but they
|
||||
lacked the essential characteristics of the DECwindows window
|
||||
manager. For a while we considered letting the local clients
|
||||
have a primitive way to manage their own windows, until a full-
|
||||
featured window manager could be started on a host. Again, this
|
||||
alternative lacked the DECwindows system's qualities. We even-
|
||||
tually decided to write a window manager based only on Xlib and
|
||||
our subset toolkit calls. It has the essential characteristics
|
||||
of the DECwindows product. Also, since the DECwindows window
|
||||
manager of necessity would keep changing, we wrote the local
|
||||
window manager in such a way that it could relinquish control to
|
||||
a remote window manager. This solution gave us the most flexi-
|
||||
bility for this hardware platform. The recently announced VXT
|
||||
2000 X terminal has been designed with virtual memory to accom-
|
||||
modate a well-established unmodified window manager, the Motif
|
||||
Window Manager.
|
||||
|
||||
X Server
|
||||
|
||||
We also needed to choose an X server. We could have based our
|
||||
code on the distribution tape from MIT, but at the time the X
|
||||
Window System was not yet a mature product. Every implementor
|
||||
had to spend considerable time stabilizing the implementation
|
||||
enough to yield a product and improve performance. Since the
|
||||
VMS DECwindows Group had been writing code for the server, we
|
||||
decided to use DECwindows code. Once the porting effort started,
|
||||
we found that most of the performance had been improved by VAX
|
||||
MACRO code. Consequently, we had to re-engineer all the modules
|
||||
or adapt new ones from the MIT tape. As we kept porting and
|
||||
|
||||
Digital Technical Journal Vol. 3 No. 4 Fall 1991 11
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
enhancing performance, our code changed more and more until
|
||||
it became extremely difficult to track bug fixes made by the
|
||||
DECwindows Group. The MIT patches were also nearly impossible to
|
||||
use because of code changes and because our starting code was
|
||||
one step removed from the tape.
|
||||
|
||||
Today the MIT X server is a mature product; patches and bug
|
||||
fixes are readily available from MIT and the X community. In our
|
||||
current X terminals, the high degree of portability of the MIT
|
||||
X server allows us to keep most of the MIT X server source code
|
||||
almost unchanged so patches are easily applied.
|
||||
|
||||
Communications Protocol
|
||||
|
||||
Many communications protocols were available, but our choice
|
||||
was dictated by market pressures rather than technical reasons.
|
||||
The market demanded TCP/IP. DECnet would have been acceptable,
|
||||
but it was running out of available addresses, at least within
|
||||
Digital. DECnet address space supports only 64,000 nodes and
|
||||
requires manual address and name assignments. After waiting
|
||||
weeks to get addresses for a few workstations, we realized that
|
||||
adding thousands of X terminals into Digital's internal network
|
||||
would not be possible. DECnet Phase V software has solved this
|
||||
problem.
|
||||
|
||||
Next we looked at the LAT protocol used by Digital terminal
|
||||
servers and found that it had several advantages. First, the
|
||||
VMS operating system supports the LAT protocol. LAT uses unique
|
||||
48-bit Ethernet addresses to identify each node, which allows a
|
||||
large node address space. LAT also does not require any system
|
||||
management to add another terminal. A user can connect a termi-
|
||||
nal to a power source, and the terminal automatically becomes
|
||||
part of the network. Our performance evaluations found that the
|
||||
LAT interface on the host could be written to incur less host
|
||||
overhead than DECnet, which is important when many X terminals
|
||||
are connected to hosts.
|
||||
|
||||
|
||||
|
||||
12 Digital Technical Journal Vol. 3 No. 4 Fall 1991
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
Changes were needed in the VMS LAT driver to accommodate X wire
|
||||
and font service connections. The VMS Software Engineering Group
|
||||
worked with us to ensure that we would have those changes on
|
||||
schedule and in the appropriate VMS releases. As a result, we
|
||||
chose the LAT protocol for the VMS community and TCP/IP for
|
||||
users of ULTRIX and UNIX systems.
|
||||
|
||||
Font File System
|
||||
|
||||
Storing fonts and changing font file formats were major prob-
|
||||
lems. Since the VT1000 X terminal did not have a local file
|
||||
system, some fonts had to be stored in ROM to allow the VT1000
|
||||
terminal to function in standalone mode. A quick review of the
|
||||
available DECwindows fonts showed that not all of them fit in
|
||||
the ROM space allowed for the terminal. Furthermore, customer-
|
||||
designed fonts or new font releases could not be accommodated.
|
||||
The solution was to be able to read fonts from a host system.
|
||||
This approach provided a font service on VMS, and enabled font
|
||||
files to be read over the Internet. We designed a process called
|
||||
the font daemon to run on the VMS operating system. This process
|
||||
could deliver font data on request to one or several VT1000 ter-
|
||||
minals. The VMS font daemon uses the LAT protocol to deliver the
|
||||
fonts and protects somewhat against font file format changes. In
|
||||
many ways, the design of the font daemon makes it a precursor
|
||||
to a general font server, and it is very similar to the X Font
|
||||
Server being delivered by MIT in the latest release of the X
|
||||
Windows System.
|
||||
|
||||
To use the font service, the terminal user must specify a font
|
||||
path in the VT1200 local terminal manager. Specifying a host
|
||||
name is sufficient to access the default font path, although
|
||||
users with their own font files can optionally search other
|
||||
directories. At startup, the VT1200 terminal makes a font con-
|
||||
nection to the host's font service and delivers the font path
|
||||
specification to the font service. The font service sends font
|
||||
names and other basic font information about all the fonts in
|
||||
the selected path. When the VT1200 X server needs a font, the
|
||||
VT1200 first searches the ROM-based fonts; if it is not there, a
|
||||
request to read the font is sent to the font daemon. The daemon
|
||||
|
||||
Digital Technical Journal Vol. 3 No. 4 Fall 1991 13
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
sends the required information to the VT1200, and the X server
|
||||
can display characters from that font. Since memory is limited,
|
||||
the VT1200 has font caching, a mechanism to discard fonts no
|
||||
longer used or to discard the least used fonts. Our current X
|
||||
terminals increase the robustness of the font mechanism; for
|
||||
example, they provide recovery should the font service or its
|
||||
host become unavailable.
|
||||
|
||||
The special LAT code that we used on VMS systems for the font
|
||||
service was not available on UNIX and ULTRIX operating systems.
|
||||
Since internet protocol (IP) was available, we could use the
|
||||
trivial file transfer protocol (TFTP) to read a file from a host
|
||||
system, if the system manager set the proper protections. We
|
||||
chose TFTP for its ease of implementation and its wide avail-
|
||||
ability on UNIX and ULTRIX systems. The TFTP font path in a
|
||||
VT1200 terminal specifies a host IP address and a complete path
|
||||
to a file (usually named font.paths) that contains the complete
|
||||
path to all the font files that the VT1200 can use. The terminal
|
||||
can then access all those font files, again through TFTP, to
|
||||
obtain font names and other basic information about each font.
|
||||
When a client wishes to use a font, the proper font file can
|
||||
be read again, this time to load the complete font. Since this
|
||||
process is time-consuming, the font path pointing to the file
|
||||
has an alternate format in which the font name follows the com-
|
||||
plete path to each file. Using this alternate format, the VT1200
|
||||
terminal does not have to open and read the font file until a
|
||||
client actually intends to use it.
|
||||
|
||||
7 Comparison of X Terminals
|
||||
|
||||
The VT1200 and VT1300 X window terminals were built using dif-
|
||||
ferent approaches to solve the problems encountered during de-
|
||||
velopment. The X terminal is a new and flexible concept; there
|
||||
is no single "best" design. Table 1 compares the most impor-
|
||||
tant differences between the two terminals. We also include the
|
||||
specifics for the VXT 2000 X terminal.
|
||||
|
||||
|
||||
|
||||
14 Digital Technical Journal Vol. 3 No. 4 Fall 1991
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
|
||||
Digital Technical Journal Vol. 3 No. 4 Fall 1991 15
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
________________________________________________________________
|
||||
|
||||
Table_1:__Comparison_of_X_Window_Terminals______________________
|
||||
|
||||
VT1200 VT1300 VXT 2000
|
||||
|
||||
Monochrome only Color only Monochrome and
|
||||
color
|
||||
|
||||
1 bit plane 4 or 8 bit planes 1 or 8 bit planes
|
||||
|
||||
Code in ROM Code downloaded Code downloaded
|
||||
|
||||
No virtual memory No virtual memory Virtual memory
|
||||
|
||||
2 to 4MB RAM 8 to 32MB RAM 4 to 16MB RAM
|
||||
|
||||
TMS34010 CPU VAX CPU VAX CPU
|
||||
|
||||
Special operating VAXELN operating Special operating
|
||||
system system system
|
||||
|
||||
Local clients: No local clients Local clients:
|
||||
Terminal manager Terminal manager
|
||||
Window manager Motif window
|
||||
Video terminal manager
|
||||
emulator DECterm terminal
|
||||
emulator
|
||||
|
||||
Local customization Customized on host Local customiza-
|
||||
just as a worksta- tion
|
||||
tion Centralized cus-
|
||||
tomization
|
||||
|
||||
Choice of host Automatic X window Choice of host(LAT
|
||||
(LAT only) login to boot host and TCP/IP using
|
||||
XDMCP)
|
||||
|
||||
LAT protocol DECnet protocol LAT protocol
|
||||
|
||||
TCP/IPgprotocolhnical JTCP/IP Vol.o3oNo. 4 FallC1991 protocol
|
||||
|
||||
Special hardware Available on sev- Uses standard
|
||||
eral hardware
|
||||
workstation plat-
|
||||
_______________________forms____________________________________
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
The VT1200 is ROM-based; all its software is permanently resi-
|
||||
dent in the terminal. The VT1300 software is downloaded, so a
|
||||
host or bootserver on the same network must supply the terminal
|
||||
with a load image at power-up.
|
||||
|
||||
Since downloaded terminals are dependent on the existence of
|
||||
at least one working host system, the user interface can be
|
||||
designed differently. While the VT1200 X terminal has a built-in
|
||||
user interface, the VT1300 does not need it. The VT1300 terminal
|
||||
automatically makes an X connection to a host at power-up, and
|
||||
the user is presented with the same DECwindows login box as on a
|
||||
workstation. The VT1300 has no local clients; all clients run on
|
||||
the host system.
|
||||
|
||||
The VT1200 terminal uses the LAT protocol for its ease of use
|
||||
and minimal network management demands. The VT1300 terminal uses
|
||||
the DECnet software already implemented in the VAXELN operating
|
||||
system used internally. Both terminals support TCP/IP.
|
||||
|
||||
8 VXT 2000 X Terminal
|
||||
|
||||
One problem that has plagued all X terminals is limited memory
|
||||
space. Workstations usually have a virtual memory system, which
|
||||
provides large paging and swap areas on a disk, and applications
|
||||
and X servers can use more memory space than the hardware has.
|
||||
Until now X terminals have not had virtual memory systems. If
|
||||
too many applications made excessive demands, or if a client
|
||||
created large off-screen images (called "pixmaps" in the X Win-
|
||||
dow System) the terminals quickly used all memory space. If the
|
||||
X server implementation was correct, an error was reported and
|
||||
a client might try a less demanding approach. In other cases,
|
||||
the terminal or client might simply crash. One alternative was
|
||||
to install more memory in the X terminal, although this can be
|
||||
costly and offers no guarantees.
|
||||
|
||||
|
||||
|
||||
|
||||
Digital Technical Journal Vol. 3 No. 4 Fall 1991 17
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
In the next generation of Digital's X terminals, the VXT 2000,
|
||||
this problem has found a cost-effective solution. Based on the
|
||||
VAX architecture, the VXT 2000 terminal uses virtual memory and
|
||||
downloaded code. The Digital InfoServer, an Ethernet storage
|
||||
server, provides the load image, virtual memory paging space,
|
||||
fonts, and customization storage. The same InfoServer also
|
||||
solves another problem: now the X terminal has access to a file
|
||||
system. This allows more extensive customization, as well as
|
||||
centralized management of the customization of all X terminals
|
||||
on the network. Figure 8 shows the configuration for the VXT
|
||||
2000 X terminal.
|
||||
|
||||
|
||||
9 Conclusion
|
||||
|
||||
X terminals are not intended to replace workstations. Nor will
|
||||
workstations replace host systems or completely displace X ter-
|
||||
minals in the foreseeable future. It is likely that host comput-
|
||||
ers will always be faster and have more memory and disk space
|
||||
than reasonably priced workstations of the same era. It is also
|
||||
likely that terminals can be built cheaper than workstations of
|
||||
reasonable performance for some time to come. As long as that is
|
||||
the case, there will be a market for X terminals and host sys-
|
||||
tems. Future X terminals will be faster, and have more built-in
|
||||
functionality, more local applications, X extensions, and most
|
||||
likely, additional hardware features. X terminals will be the
|
||||
networked terminals of the 1990s.
|
||||
|
||||
10 Acknowledgements
|
||||
|
||||
We wish to thank the members of the VT1200 development team
|
||||
who worked many long hours on this project. Thanks to everyone
|
||||
inside and outside the Video, Image and Print Systems Group who
|
||||
contributed helpful suggestions, constructive criticism, and
|
||||
important hours using and testing the products. Thanks to the
|
||||
LAT and VMS Software Engineering Groups for incorporating the
|
||||
changes needed for the VT1200 X terminal to be useful. Thanks to
|
||||
|
||||
|
||||
18 Digital Technical Journal Vol. 3 No. 4 Fall 1991
|
||||
X Window Terminals
|
||||
|
||||
|
||||
|
||||
the VIPS Quality Group for ensuring that as few bugs as possible
|
||||
remained in the product when shipped.
|
||||
|
||||
Björn Engberg As a principal software engineer in the Video,
|
||||
Image and Print Systems Group, Björn Engberg was the main ar-
|
||||
chitect and software project leader for the VT1000 and VT1200
|
||||
X window terminals. He joined Digital in 1978 and worked as
|
||||
a development engineer at CSS in Sweden, where he modified
|
||||
Digital's terminals for the European market. He relocated to
|
||||
the United States in 1982 to work on the VT240, the VT320, the
|
||||
LJ250, and several advanced development projects. Björn received
|
||||
an M.S.E.E. (honors) from the Royal Institute of Technology in
|
||||
Stockholm.
|
||||
|
||||
Thomas C. Porcher Principal engineer Tom Porcher is a member of
|
||||
the Video, Image and Print Systems Group. He provided techni-
|
||||
cal leadership in the development of the VXT 2000 X terminal.
|
||||
Previously he was a technical leader for the VT240 terminal,
|
||||
VAX Session Support Utility, and the DECterm terminal emulator.
|
||||
Tom holds five patents for work on the VT240 terminal and on
|
||||
the multisession protocol used in the VT340 and VT400 series
|
||||
terminals. Tom received his B.S. in mathematics from Stevens
|
||||
Institute of Technology (1975). He is a member of the ACM.
|
||||
|
||||
DECnet, DECwindows, Digital, LAT, ULTRIX, VAX, VAXELN, VMS,
|
||||
VT1000, VT1200, VT1300, and VXT 2000 are trademarks of Digital
|
||||
Equipment Corporation.
|
||||
|
||||
UNIX is a registered trademark of UNIX System Laboratories, Inc.
|
||||
|
||||
|
||||
|
||||
|
||||
Digital Technical Journal Vol. 3 No. 4 Fall 1991 19
|
||||
=============================================================================
|
||||
Copyright 1991 Digital Equipment Corporation. Forwarding and copying of this
|
||||
article is permitted for personal and educational purposes without fee
|
||||
provided that Digital Equipment Corporation's copyright is retained with the
|
||||
article and that the content is not modified. This article is not to be
|
||||
distributed for commercial advantage. Abstracting with credit of Digital
|
||||
Equipment Corporation's authorship is permitted. All rights reserved.
|
||||
=============================================================================
|
||||
|
||||
Binary file not shown.
@@ -0,0 +1 @@
|
||||
|
||||
Binary file not shown.
@@ -0,0 +1,311 @@
|
||||
EK–V1000–RC–003
|
||||
|
||||
|
||||
VT1000/VT1200 Video Terminal
|
||||
|
||||
Installing Optional Memory
|
||||
|
||||
|
||||
This card describes how to install optional RAM (random access
|
||||
memory) into your VT1000 or VT1200 video terminal. A detailed
|
||||
installation procedure also appears in Installing and Using the
|
||||
VT1000 Video Terminal and Installing and Using the VT1200 Video
|
||||
Terminal.
|
||||
The VT1000 terminal comes with 1 megabyte of base memory.
|
||||
The VT1200 terminal comes with 2 megabytes of base memory.
|
||||
You can add 1, 2, or 3 megabytes of optional memory, for a total
|
||||
of up to 4 megabytes. Optional memory comes on 1-megabyte
|
||||
SIMM cards (single in-line memory module), which install on the
|
||||
terminal’s memory controller board.
|
||||
|
||||
CAUTION
|
||||
The memory controller board and the SIMM cards can be
|
||||
damaged by electrostatic discharge. Handle the memory
|
||||
controller board by its cover or strap. Handle the SIMM
|
||||
card by the side edges of the card. Avoid contact with any
|
||||
components or circuitry within the system box.
|
||||
Digital recommends using a grounding wrist strap and
|
||||
an antistatic mat to perform the installation, if available.
|
||||
Otherwise, Digital recommends that you frequently touch
|
||||
the metal chassis of the system box during installation, to
|
||||
neutralize any existing static charges.
|
||||
2
|
||||
|
||||
|
||||
Unpack and check the contents of the box.
|
||||
|
||||
You should receive the correct number of 1-megabyte SIMM cards
|
||||
you ordered. You will install the SIMM cards on the memory
|
||||
controller board inside the system box.
|
||||
VT1000 only: You will also receive a memory controller board,
|
||||
if necessary. The board comes with a 1-megabyte SIMM card
|
||||
already installed.
|
||||
Carefully inspect the components for shipping damage. If you have
|
||||
any missing or damaged items, contact your sales representative
|
||||
and delivery agent.
|
||||
|
||||
Remove the system box cover.
|
||||
|
||||
1. Turn the system box’s | /O power switch off (O).
|
||||
2. Turn the monitor’s | /O power switch off (O).
|
||||
3. Disconnect the two power cords from the rear of the system
|
||||
box.
|
||||
4. Disconnect the monitor video cable from the rear of the
|
||||
monitor.
|
||||
5. Remove the monitor from the top of the system box. You may
|
||||
need two people.
|
||||
6. Release the top cover of the system box by pressing in the
|
||||
two push tabs on the side of the box with the power switch,
|
||||
as shown.
|
||||
7. Slowly lift the top cover until you release the hinges on the
|
||||
other side of the box. Then lift the top cover completely off
|
||||
the system box.
|
||||
3
|
||||
|
||||
|
||||
|
||||
|
||||
23 4
|
||||
2 5
|
||||
6
|
||||
|
||||
|
||||
|
||||
|
||||
22%
|
||||
|
||||
|
||||
|
||||
GSF_0839_89.DG
|
||||
4
|
||||
|
||||
|
||||
Identify the components in the system box.
|
||||
|
||||
There are five major components in the system box.
|
||||
|
||||
1 System logic board
|
||||
2 RAM controller board
|
||||
3 SIMM card (installed on the other side of the RAM
|
||||
controller board)
|
||||
4 ROM memory board
|
||||
5 Power supply
|
||||
|
||||
|
||||
2
|
||||
3
|
||||
|
||||
4
|
||||
1
|
||||
5
|
||||
|
||||
|
||||
|
||||
|
||||
23 4
|
||||
2 5
|
||||
6
|
||||
|
||||
|
||||
|
||||
|
||||
22%
|
||||
|
||||
|
||||
GSF_1362_89.DG
|
||||
5
|
||||
|
||||
|
||||
Remove the memory controller board (if installed).
|
||||
|
||||
1. Release the standoff clips by gently pushing each clip away
|
||||
from the board and lifting up on the edges of the board.
|
||||
2. Grasp the strap of the memory controller board and pull up
|
||||
firmly to release the memory controller board connector from
|
||||
the system logic board.
|
||||
3. Place the board on top of the power supply’s metal cover,
|
||||
with the strap side down. Use the metal cover as a work
|
||||
surface to perform the SIMM card installation.
|
||||
|
||||
|
||||
|
||||
|
||||
GSF_0957_89.DG
|
||||
|
||||
|
||||
|
||||
|
||||
22% of full size
|
||||
then imod scaled at 1.5
|
||||
6
|
||||
|
||||
|
||||
Install the SIMM cards on the memory controller board.
|
||||
|
||||
1. Remove the small SIMM card(s) from the shipping bag.
|
||||
VT1000 only: Also remove the new memory controller board,
|
||||
if ordered.
|
||||
2. Place the SIMM cards and memory controller board on top
|
||||
of the power supply’s metal cover, with the strap side of the
|
||||
memory controller board facing down. Use the metal cover
|
||||
as a work surface to install the SIMM cards. This prevents
|
||||
electrostatic damage.
|
||||
3. The memory controller board has one SIMM card preinstalled
|
||||
in the connector labeled 2MB. Install the next SIMM card in
|
||||
the connector labeled 3MB and the last SIMM card in the
|
||||
connector labeled 4MB, as follows.
|
||||
|
||||
CAUTION
|
||||
SIMM cards can be damaged by electrostatic discharge.
|
||||
Handle the SIMM card by the side edges of the card.
|
||||
Avoid contact with the gold contact fingers on the card.
|
||||
7
|
||||
|
||||
|
||||
a. Insert the SIMM card into the connector at a 45-degree
|
||||
angle. Face the components on the SIMM card toward
|
||||
the components on the memory controller board. Line
|
||||
up the center key slot on the SIMM card with the
|
||||
connector key on the memory controller board.
|
||||
b. Push down on the top of the SIMM card to securely seat
|
||||
the card in the connector.
|
||||
c. Raise the SIMM card into a standup position, until both
|
||||
sides of the card lock into the connector.
|
||||
|
||||
|
||||
|
||||
|
||||
4M
|
||||
B
|
||||
3M
|
||||
B
|
||||
2M
|
||||
B
|
||||
|
||||
|
||||
|
||||
0 %
|
||||
a t 7
|
||||
DG
|
||||
T.
|
||||
DI
|
||||
_E
|
||||
RD
|
||||
OA
|
||||
_B
|
||||
M
|
||||
RA
|
||||
|
||||
|
||||
|
||||
|
||||
3M
|
||||
B
|
||||
|
||||
|
||||
|
||||
|
||||
3M
|
||||
B
|
||||
|
||||
GSF_0840_89.DG
|
||||
8
|
||||
|
||||
|
||||
Install the memory controller board into the system box.
|
||||
|
||||
1. Grasp the strap of the memory controller board.
|
||||
2. Carefully place the board on top of its connector and standoffs
|
||||
in the system box. Use the standoffs as guides to align the
|
||||
connector on the board with the logic board connector.
|
||||
3. Press down firmly on the board and its edges to seat the
|
||||
connector and lock each of the four standoff clips.
|
||||
|
||||
|
||||
|
||||
|
||||
GSF_0842_89.DG
|
||||
|
||||
|
||||
|
||||
NOTE
|
||||
If you have problems, recheck the installation procedures
|
||||
carefully. If the problem continues, contact Digital
|
||||
Customer Services.
|
||||
9
|
||||
|
||||
|
||||
Replace the system box cover.
|
||||
|
||||
1. From the rear of the system box, place the left side of the top
|
||||
cover onto the hinge tabs in the left side of the system box.
|
||||
2. Gently lower the right side of the top cover onto the system
|
||||
box. Make sure the power connector frame slides into the
|
||||
slot behind the power connectors.
|
||||
3. Push down on the right side of the top cover until it snaps
|
||||
into the two push tabs, locking it in place.
|
||||
|
||||
|
||||
|
||||
|
||||
23 4
|
||||
2 5
|
||||
6
|
||||
|
||||
|
||||
|
||||
|
||||
22%
|
||||
|
||||
|
||||
|
||||
GSF_0959_89.DG
|
||||
|
||||
|
||||
|
||||
|
||||
4. Place the monitor on top of the system box.
|
||||
5. Connect the two power cords to the rear of the system box.
|
||||
6. Connect the monitor video cable to rear of the monitor.
|
||||
7. Turn the system box’s | /O power switch on ( | ).
|
||||
8. Turn the monitor’s | /O power switch on ( | ).
|
||||
10
|
||||
|
||||
|
||||
Verify the installation.
|
||||
|
||||
The Terminal Manager window should be displayed on your
|
||||
screen. Find the Memory Remaining scale on the bottom of the
|
||||
VT1000
|
||||
Verify that the number on the right side of the Memory Remaining
|
||||
scale displays the correct number of total megabytes in your
|
||||
system.
|
||||
|
||||
Number
|
||||
Standard + Optional = Displayed
|
||||
|
||||
|
||||
VT1200
|
||||
2 megabytes 1 megabyte 3M
|
||||
2 megabytes 4M
|
||||
|
||||
VT1000
|
||||
1 megabyte 1 megabyte 2M
|
||||
2 megabytes 3M
|
||||
3 megabyte 4M
|
||||
|
||||
|
||||
NOTE
|
||||
If you have problems, recheck the installation procedures
|
||||
carefully. If the problem continues, contact Digital Customer
|
||||
Services.
|
||||
|
||||
|
||||
The installation procedure is complete.
|
||||
|
||||
|
||||
Copyright © by Digital Equipment Corporation 1990
|
||||
All Rights Reserved. Printed in Singapore.
|
||||
VT1000 and VT1200 are trademarks of Digital Equipment
|
||||
Corporation.
|
||||
|
||||
Binary file not shown.
@@ -0,0 +1,234 @@
|
||||
EK-V1000-RN-005
|
||||
|
||||
|
||||
|
||||
|
||||
VT1000 VIDEO TERMINAL V2.0
|
||||
RELEASE NOTES
|
||||
|
||||
|
||||
|
||||
|
||||
This document describes problems, corrections, and restrictions that pertain
|
||||
to V2.0 of the VT1000 Video Terminal firmware.
|
||||
|
||||
|
||||
|
||||
|
||||
Digital Equipment Corporation
|
||||
July 1990
|
||||
The information in this document is subject to change without notice and should
|
||||
not be construed as a commitment by Digital Equipment Corporation. Digital
|
||||
Equipment Corporation assumes no responsibility for any errors that may appear
|
||||
in this document.
|
||||
The software described in this document is furnished under a license and may
|
||||
be used or copied only in accordance with the terms of such license.
|
||||
No responsibility is assumed for the use or reliability of software on equipment
|
||||
that is not supplied by Digital Equipment Corporation or its affiliated companies.
|
||||
Restricted Rights: Use, duplication, or disclosure by the U. S. Government is
|
||||
subject to restrictions as set forth in subparagraph ( c ) ( 1 ) ( ii ) of the Rights
|
||||
in Technical Data and Computer Software clause at DFARS 252.227–7013.
|
||||
Copyright © by Digital Equipment Corporation 1990
|
||||
All Rights Reserved.
|
||||
|
||||
|
||||
FCC NOTICE: The equipment described in this manual generates, uses, and
|
||||
may emit radio frequency energy. The equipment has been type tested and found
|
||||
to comply with the limits for a Class A computing device pursuant to Subpart
|
||||
J of Part 15 of FCC Rules, which are designed to provide reasonable protec-
|
||||
tion against such radio frequency interference when operated in a commercial
|
||||
environment. Operation of this equipment in a residential area may cause in-
|
||||
terference, in which case the user at his own expense may be required to take
|
||||
measures to correct the interference.
|
||||
AT&T and UNIX are trademarks of American Telephone and Telegraph Com-
|
||||
pany.
|
||||
X Window System is a trademark of the Massachusetts Institute of Technology.
|
||||
The following are trademarks of Digital Equipment Corporation:
|
||||
DEC LA12, LA34, LA35 PDP ThinWire
|
||||
DECconnect LA36, LA38, LA50 P/OS ULTRIX
|
||||
DECmailer LA75 Companion Professional ULTRIX-32
|
||||
DECmate LA100, LA210 Q-bus UNIBUS
|
||||
DECnet LJ250, LJ251 Q22-bus VAX
|
||||
DECserver 200 LN01, LN03 Rainbow VAXstation
|
||||
DECservice LN03 Plus ReGIS VMS
|
||||
DECterm LQP02, LQP03 RSTS VT, VT52, VT100
|
||||
DECUS LQP45 RSX VT220, VT320,
|
||||
VT420
|
||||
DECwindows MASSBUS RT VT1000
|
||||
DECwriter MicroPDP Scholar
|
||||
DIBOL MicroVAX SERVIcenter
|
||||
|
||||
|
||||
|
||||
This document was prepared using VAX DOCUMENT, Version 1.2
|
||||
Contents
|
||||
Chapter 1 Terminal Manager and VTE Windows
|
||||
1.1 QUIT ENDS ALL CONNECTIONS . . . . . . . . . . . . . . . . . . . . . . . . 1–1
|
||||
1.2 TERMINAL MANAGER - CREATE . . . . . . . . . . . . . . . . . . . . . . . . 1–1
|
||||
1.2.1 CREATE LAT X SESSION . . . . . . . . . . . . . . . . . . . . . . . . 1–1
|
||||
1.2.2 TCP/IP X SESSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
|
||||
1.3 TERMINAL MANAGER - CUSTOMIZE . . . . . . . . . . . . . . . . . . . . 1–2
|
||||
1.3.1 CUSTOMIZE SECURITY . . . . . . . . . . . . . . . . . . . . . . . . 1–2
|
||||
1.3.2 CUSTOMIZE HOST AND PRINTER PORTS . . . . . . . . . 1–2
|
||||
1.3.3 CUSTOMIZE LAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
|
||||
1.3.4 CUSTOMIZE FONT PATH . . . . . . . . . . . . . . . . . . . . . . . 1–3
|
||||
1.4 VTE - CUSTOMIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
|
||||
1.4.1 CUSTOMIZE GENERAL . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
|
||||
1.4.2 CUSTOMIZE 7-BIT NRCS . . . . . . . . . . . . . . . . . . . . . . . . 1–4
|
||||
1.4.3 CUSTOMIZE PRINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
|
||||
1.5 SYSTEM MANAGER INFORMATION . . . . . . . . . . . . . . . . . . . . . 1–5
|
||||
1.5.1 APPENDIX D - RUNNING REMOTE X SESSION . . . . . 1–5
|
||||
|
||||
|
||||
|
||||
|
||||
iii
|
||||
Chapter 1
|
||||
Terminal Manager and VTE Windows
|
||||
|
||||
1.1 QUIT ENDS ALL CONNECTIONS
|
||||
Complete your work before using either the Terminal Manager Quit or
|
||||
Remote Session Manager Quit. Both Quits are intended to return the
|
||||
terminal to its initial state at the end of a work session.
|
||||
|
||||
1.2 TERMINAL MANAGER - CREATE
|
||||
1.2.1 CREATE LAT X SESSION
|
||||
Session Manager and VMS
|
||||
A problem can occur where a user cannot log into an X session on a host.
|
||||
The terminal can still open VTE windows and pull down menus. The
|
||||
watch cursor replaces the pointer.
|
||||
If you have this problem, enter the command:
|
||||
$ SHOW DEVICE TWA
|
||||
If the host show a device number over 999, reboot the host. This action
|
||||
will restore the VT1000’s ability to create X sessions.
|
||||
To obtain a patch that permanently corrects this problem, contact your
|
||||
Digital representative.
|
||||
|
||||
|
||||
|
||||
|
||||
Terminal Manager and VTE Windows 1–1
|
||||
1.2.2 TCP/IP X SESSION
|
||||
Remote Pause Unsupported in UWS V2.1
|
||||
A difference between UWS V2.1 and UWS V2.2 prevents the successful
|
||||
return from a Remote Session Manager Pause state in UWS V2.1.
|
||||
|
||||
1.3 TERMINAL MANAGER - CUSTOMIZE
|
||||
1.3.1 CUSTOMIZE SECURITY
|
||||
TCP/IP BIND Name Service needs Names in Security
|
||||
The Security authorization for TCP/IP requires that you only use decimal
|
||||
dot notation (123.45.67.89) for the IP address of a remote system needing
|
||||
access. However, if a BIND Name Server is available on the network and
|
||||
it knows about the remote system, then you must use the name of the
|
||||
remote system (eg, node.building.institution.area).
|
||||
|
||||
1.3.2 CUSTOMIZE HOST AND PRINTER PORTS
|
||||
Use Speed 19200 or 38400, not both
|
||||
Due to a hardware limitation in the communications circuits, the speeds
|
||||
38.4Kbaud and 19.2Kbaud are mutually exclusive. All other speeds may
|
||||
be mixed between the two serial ports, but only one or the other of the
|
||||
two top speeds is available at one time.
|
||||
|
||||
Diagnostic Port supported on Printer Port
|
||||
When this mode is enabled, a printer attached to the printer port will
|
||||
print out all messages that are displayed in the Terminal Manager
|
||||
Message Region as they are received. You can control the messages that
|
||||
are printed by selecting the appropriate message types in the Customize
|
||||
Terminal Manager dialog box.
|
||||
|
||||
1.3.3 CUSTOMIZE LAT
|
||||
Software Update required for multiple Ethernet adaptors
|
||||
If your system has multiple Ethernet adaptors to allow simultaneous
|
||||
access to separate LANs, contact your Digital representative for an up-
|
||||
dated copy of DECW$LAT_TRANSPORT.EXE. The new version provides
|
||||
support for multiple link definitions.
|
||||
|
||||
|
||||
|
||||
|
||||
1–2 Terminal Manager and VTE Windows
|
||||
1.3.4 CUSTOMIZE FONT PATH
|
||||
Must Quit to Reset Font Path
|
||||
Once a session makes use of the fonts, you can view the font path, but
|
||||
you can’t change it until you quit out of the Terminal Manager. This
|
||||
applies to all sessions including VTEs. The VTE does not require a font
|
||||
path but will use host-based fonts for character and line attributes if
|
||||
available.
|
||||
|
||||
Link lost to font server requires quit to reset font path
|
||||
If your link to the font service is disconnected, perhaps due to the font
|
||||
server node shutting down, or due to a network problem, you will get
|
||||
a message in the Terminal Manager window message area stating (for
|
||||
example):
|
||||
Session n to NODENAME terminated. Link lost with remote node.
|
||||
Font path to node NODENAME lost. Reestablish font path before
|
||||
starting X sessions.
|
||||
Even if your other sessions to other nodes are still active, you need to
|
||||
reset your font path to continue working. This is because the behaviors of
|
||||
applications running on the terminal are not predictable when a request
|
||||
for a new glyph or font fails. Therefore, you should close all sessions
|
||||
and quit the terminal manager to restart the terminal and reset the font
|
||||
path.
|
||||
|
||||
Font compiler needed for non-DECwindows environments
|
||||
If your VT1000 application requires fonts that are not in the DECwin-
|
||||
dows library, you will need to get a font compiler to convert the fonts you
|
||||
have to a format the VT1000 can use. A compiler is available through
|
||||
the Internet that will convert the standard .BDF interchange format of
|
||||
most fonts to the .DWF format of the VT1000.
|
||||
The pcf font compiler is available on gatekeeper.dec.com in the
|
||||
/pub/DEC/VT1000 directory. There are two files in that directory:
|
||||
README pcf.tar.Z
|
||||
The README file contains:
|
||||
|
||||
|
||||
|
||||
|
||||
Terminal Manager and VTE Windows 1–3
|
||||
The file pcf.tar.Z in this directory contains the contents of
|
||||
the contrib/server/pcf directory that is on tape4 of the MIT
|
||||
X11R4 distribution. This code should allow you to build a
|
||||
bdf->pcf compiler so that fonts can be generated that are
|
||||
compatible with the VT1000 series terminals.
|
||||
(Note that DEC’s .dwf format is also supported by the VT1000.)
|
||||
and the pcf.tar.Z file is a compressed tar file containing the source code.
|
||||
To retreive it via the internet, copy the files from:
|
||||
gatekeeper.dec.com:~ftp/pub/DEC/VT1000
|
||||
If you cannot copy from the internet, contact your Digital representative.
|
||||
|
||||
1.4 VTE - CUSTOMIZE
|
||||
1.4.1 CUSTOMIZE GENERAL
|
||||
Answerback only supports printable characters
|
||||
Unlike the VT320, you cannot put control characters like CR or ESC into
|
||||
the VTE answerback message.
|
||||
|
||||
1.4.2 CUSTOMIZE 7-BIT NRCS
|
||||
Choose NRCS to Match Keyboard
|
||||
When using a VTE with a non-US Keyboard and 7-bit NRCS character
|
||||
sets, you must manually use the VTE Customize 7-bit NRCS Selection to
|
||||
choose an NRCS set to match the current keyboard language. Select the
|
||||
corresponding language if you use a typewriter layout. Data Processing
|
||||
keyboards in any language require the ASCII (North American) NRCS
|
||||
set. This is a 7-bit issue only.
|
||||
|
||||
1.4.3 CUSTOMIZE PRINT
|
||||
VTE Printer Modes are user settable
|
||||
Printer Modes are user settable from the Customize dialog box as well as
|
||||
host settable by control functions. The buttons in the dialog box display
|
||||
the mode that was set from either source.
|
||||
|
||||
|
||||
|
||||
|
||||
1–4 Terminal Manager and VTE Windows
|
||||
1.5 SYSTEM MANAGER INFORMATION
|
||||
1.5.1 APPENDIX D - RUNNING REMOTE X SESSION
|
||||
Wrong node value in command
|
||||
The last command in the section should read
|
||||
SET DISPLAY/CREATE/NODE=LOCAL/SERVER=100/TRANSPORT=DECNET
|
||||
|
||||
|
||||
|
||||
|
||||
Terminal Manager and VTE Windows 1–5
|
||||
|
||||
Binary file not shown.
File diff suppressed because it is too large.
Load diff
Binary file not shown.
File diff suppressed because it is too large.
Load diff
Binary file not shown.
@@ -0,0 +1,222 @@
|
||||
EK-V1200-RN-001
|
||||
|
||||
|
||||
|
||||
|
||||
VT1200 VIDEO TERMINAL V2.0
|
||||
RELEASE NOTES
|
||||
|
||||
|
||||
|
||||
|
||||
This document describes problems, corrections, and restrictions that pertain
|
||||
to V2.0 of the VT1200 Video Terminal firmware.
|
||||
|
||||
|
||||
|
||||
|
||||
Digital Equipment Corporation
|
||||
July 1990
|
||||
The information in this document is subject to change without notice and should
|
||||
not be construed as a commitment by Digital Equipment Corporation. Digital
|
||||
Equipment Corporation assumes no responsibility for any errors that may appear
|
||||
in this document.
|
||||
The software described in this document is furnished under a license and may
|
||||
be used or copied only in accordance with the terms of such license.
|
||||
No responsibility is assumed for the use or reliability of software on equipment
|
||||
that is not supplied by Digital Equipment Corporation or its affiliated companies.
|
||||
Restricted Rights: Use, duplication, or disclosure by the U. S. Government is
|
||||
subject to restrictions as set forth in subparagraph ( c ) ( 1 ) ( ii ) of the Rights
|
||||
in Technical Data and Computer Software clause at DFARS 252.227–7013.
|
||||
Copyright © by Digital Equipment Corporation 1990
|
||||
All Rights Reserved.
|
||||
|
||||
|
||||
FCC NOTICE: The equipment described in this manual generates, uses, and
|
||||
may emit radio frequency energy. The equipment has been type tested and found
|
||||
to comply with the limits for a Class A computing device pursuant to Subpart
|
||||
J of Part 15 of FCC Rules, which are designed to provide reasonable protec-
|
||||
tion against such radio frequency interference when operated in a commercial
|
||||
environment. Operation of this equipment in a residential area may cause in-
|
||||
terference, in which case the user at his own expense may be required to take
|
||||
measures to correct the interference.
|
||||
AT&T and UNIX are trademarks of American Telephone and Telegraph Com-
|
||||
pany.
|
||||
X Window System is a trademark of the Massachusetts Institute of Technology.
|
||||
The following are trademarks of Digital Equipment Corporation:
|
||||
DEC LA12, LA34, LA35 PDP ThinWire
|
||||
DECconnect LA36, LA38, LA50 P/OS ULTRIX
|
||||
DECmailer LA75 Companion Professional ULTRIX-32
|
||||
DECmate LA100, LA210 Q-bus UNIBUS
|
||||
DECnet LJ250, LJ251 Q22-bus VAX
|
||||
DECserver 200 LN01, LN03 Rainbow VAXstation
|
||||
DECservice LN03 Plus ReGIS VMS
|
||||
DECterm LQP02, LQP03 RSTS VT, VT52, VT100
|
||||
DECUS LQP45 RSX VT220, VT320,
|
||||
VT420
|
||||
DECwindows MASSBUS RT VT1000, VT1200
|
||||
DECwriter MicroPDP Scholar
|
||||
DIBOL MicroVAX SERVIcenter
|
||||
|
||||
|
||||
|
||||
This document was prepared using VAX DOCUMENT, Version 1.2
|
||||
Contents
|
||||
Chapter 1 Terminal Manager and VTE Windows
|
||||
1.1 QUIT ENDS ALL CONNECTIONS . . . . . . . . . . . . . . . . . . . . . . . . 1–1
|
||||
1.2 TERMINAL MANAGER - CREATE . . . . . . . . . . . . . . . . . . . . . . . . 1–1
|
||||
1.2.1 CREATE LAT X SESSION . . . . . . . . . . . . . . . . . . . . . . . . 1–1
|
||||
1.2.2 TCP/IP X SESSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
|
||||
1.3 TERMINAL MANAGER - CUSTOMIZE . . . . . . . . . . . . . . . . . . . . 1–2
|
||||
1.3.1 CUSTOMIZE SECURITY . . . . . . . . . . . . . . . . . . . . . . . . 1–2
|
||||
1.3.2 CUSTOMIZE HOST AND PRINTER PORTS . . . . . . . . . 1–2
|
||||
1.3.3 CUSTOMIZE LAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
|
||||
1.3.4 CUSTOMIZE FONT PATH . . . . . . . . . . . . . . . . . . . . . . . 1–3
|
||||
1.4 VTE - CUSTOMIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
|
||||
1.4.1 CUSTOMIZE GENERAL . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
|
||||
1.4.2 CUSTOMIZE 7-BIT NRCS . . . . . . . . . . . . . . . . . . . . . . . . 1–4
|
||||
1.4.3 CUSTOMIZE PRINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
|
||||
|
||||
|
||||
|
||||
|
||||
iii
|
||||
Chapter 1
|
||||
Terminal Manager and VTE Windows
|
||||
|
||||
1.1 QUIT ENDS ALL CONNECTIONS
|
||||
Complete your work before using either the Terminal Manager Quit or
|
||||
Remote Session Manager Quit. Both Quits are intended to return the
|
||||
terminal to its initial state at the end of a work session.
|
||||
|
||||
1.2 TERMINAL MANAGER - CREATE
|
||||
1.2.1 CREATE LAT X SESSION
|
||||
Session Manager and VMS
|
||||
A problem can occur where a user cannot log into an X session on a host.
|
||||
The terminal can still open VTE windows and pull down menus. The
|
||||
watch cursor replaces the pointer.
|
||||
If you have this problem, enter the command:
|
||||
$ SHOW DEVICE TWA
|
||||
If the host show a device number over 999, reboot the host. This action
|
||||
will restore the VT1200’s ability to create X sessions.
|
||||
To obtain a patch that permanently corrects this problem, contact your
|
||||
Digital representative.
|
||||
|
||||
|
||||
|
||||
|
||||
Terminal Manager and VTE Windows 1–1
|
||||
1.2.2 TCP/IP X SESSION
|
||||
Remote Pause Unsupported in UWS V2.1
|
||||
A difference between UWS V2.1 and UWS V2.2 prevents the successful
|
||||
return from a Remote Session Manager Pause state in UWS V2.1.
|
||||
|
||||
1.3 TERMINAL MANAGER - CUSTOMIZE
|
||||
1.3.1 CUSTOMIZE SECURITY
|
||||
TCP/IP BIND Name Service needs Names in Security
|
||||
The Security authorization for TCP/IP requires that you only use decimal
|
||||
dot notation (123.45.67.89) for the IP address of a remote system needing
|
||||
access. However, if a BIND Name Server is available on the network and
|
||||
it knows about the remote system, then you must use the name of the
|
||||
remote system (eg, node.building.institution.area).
|
||||
|
||||
1.3.2 CUSTOMIZE HOST AND PRINTER PORTS
|
||||
Use Speed 19200 or 38400, not both
|
||||
Due to a hardware limitation in the communications circuits, the speeds
|
||||
38.4Kbaud and 19.2Kbaud are mutually exclusive. All other speeds may
|
||||
be mixed between the two serial ports, but only one or the other of the
|
||||
two top speeds is available at one time.
|
||||
|
||||
Diagnostic Port supported on Printer Port
|
||||
When this mode is enabled, a printer attached to the printer port will
|
||||
print out all messages that are displayed in the Terminal Manager
|
||||
Message Region as they are received. You can control the messages that
|
||||
are printed by selecting the appropriate message types in the Customize
|
||||
Terminal Manager dialog box.
|
||||
|
||||
1.3.3 CUSTOMIZE LAT
|
||||
Software Update required for multiple Ethernet adaptors
|
||||
If your system has multiple Ethernet adaptors to allow simultaneous
|
||||
access to separate LANs, contact your Digital representative for an up-
|
||||
dated copy of DECW$LAT_TRANSPORT.EXE. The new version provides
|
||||
support for multiple link definitions.
|
||||
|
||||
|
||||
|
||||
|
||||
1–2 Terminal Manager and VTE Windows
|
||||
1.3.4 CUSTOMIZE FONT PATH
|
||||
Must Quit to Reset Font Path
|
||||
Once a session makes use of the fonts, you can view the font path, but
|
||||
you can’t change it until you quit out of the Terminal Manager. This
|
||||
applies to all sessions including VTEs. The VTE does not require a font
|
||||
path but will use host-based fonts for character and line attributes if
|
||||
available.
|
||||
|
||||
Link lost to font server requires quit to reset font path
|
||||
If your link to the font service is disconnected, perhaps due to the font
|
||||
server node shutting down, or due to a network problem, you will get
|
||||
a message in the Terminal Manager window message area stating (for
|
||||
example):
|
||||
Session n to NODENAME terminated. Link lost with remote node.
|
||||
Font path to node NODENAME lost. Reestablish font path before
|
||||
starting X sessions.
|
||||
Even if your other sessions to other nodes are still active, you need to
|
||||
reset your font path to continue working. This is because the behaviors of
|
||||
applications running on the terminal are not predictable when a request
|
||||
for a new glyph or font fails. Therefore, you should close all sessions
|
||||
and quit the terminal manager to restart the terminal and reset the font
|
||||
path.
|
||||
|
||||
Font compiler needed for non-DECwindows environments
|
||||
If your VT1200 application requires fonts that are not in the DECwin-
|
||||
dows library, you will need to get a font compiler to convert the fonts you
|
||||
have to a format the VT1200 can use. A compiler is available through
|
||||
the Internet that will convert the standard .BDF interchange format of
|
||||
most fonts to the .DWF format of the VT1200.
|
||||
The pcf font compiler is available on gatekeeper.dec.com in the
|
||||
/pub/DEC/VT1000 directory. There are two files in that directory:
|
||||
README pcf.tar.Z
|
||||
The README file contains:
|
||||
|
||||
|
||||
|
||||
|
||||
Terminal Manager and VTE Windows 1–3
|
||||
The file pcf.tar.Z in this directory contains the contents of
|
||||
the contrib/server/pcf directory that is on tape4 of the MIT
|
||||
X11R4 distribution. This code should allow you to build a
|
||||
bdf->pcf compiler so that fonts can be generated that are
|
||||
compatible with the VT1000 series terminals.
|
||||
(Note that DEC’s .dwf format is also supported by the VT1000.)
|
||||
and the pcf.tar.Z file is a compressed tar file containing the source code.
|
||||
To retreive it via the internet, copy the files from:
|
||||
gatekeeper.dec.com:~ftp/pub/DEC/VT1000
|
||||
If you cannot copy from the internet, contact your Digital representative.
|
||||
|
||||
1.4 VTE - CUSTOMIZE
|
||||
1.4.1 CUSTOMIZE GENERAL
|
||||
Answerback only supports printable characters
|
||||
Unlike the VT320, you cannot put control characters like CR or ESC into
|
||||
the VTE answerback message.
|
||||
|
||||
1.4.2 CUSTOMIZE 7-BIT NRCS
|
||||
Choose NRCS to Match Keyboard
|
||||
When using a VTE with a non-US Keyboard and 7-bit NRCS character
|
||||
sets, you must manually use the VTE Customize 7-bit NRCS Selection to
|
||||
choose an NRCS set to match the current keyboard language. Select the
|
||||
corresponding language if you use a typewriter layout. Data Processing
|
||||
keyboards in any language require the ASCII (North American) NRCS
|
||||
set. This is a 7-bit issue only.
|
||||
|
||||
1.4.3 CUSTOMIZE PRINT
|
||||
VTE Printer Modes are user settable
|
||||
Printer Modes are user settable from the Customize dialog box as well as
|
||||
host settable by control functions. The buttons in the dialog box display
|
||||
the mode that was set from either source.
|
||||
|
||||
|
||||
|
||||
|
||||
1–4 Terminal Manager and VTE Windows
|
||||
|
||||
Binary file not shown.
File diff suppressed because it is too large.
Load diff
Binary file not shown.
File diff suppressed because it is too large.
Load diff
File diff suppressed because it is too large.
Load diff
File diff suppressed because it is too large.
Load diff
Binary file not shown.
|
After Width: | Height: | Size: 256 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 202 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 84 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 151 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 146 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 88 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 145 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 155 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 135 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 142 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 79 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 155 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 75 KiB |
@@ -0,0 +1,481 @@
|
||||
# VT1200 board register model — Implementation Plan
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** Replace the driver's ad-hoc board-window stubs with a modelled, unit-testable register file for the four undecoded VT1200 windows, so the firmware's status/command handshakes behave as real state machines instead of constants.
|
||||
|
||||
**Architecture:** A standalone C++ class `vt1200_board` with **no MAME dependencies** (fixed-width integer types only), so it can be unit-tested with plain `g++` outside the emulator. It models two shapes discovered in the firmware: `big` (windows `0x6200000` and `0x6400000` — STATUS at `+0x10`, COMMAND/DATA at `+0x20`, plus `+0x30`/`+0xD0`/`+0xE0`/`+0xF0`) and `dma` (the `0x5800000` data port + `0x5900000` command port pair). The MAME driver owns one instance and forwards its address-map callbacks to it.
|
||||
|
||||
**Tech Stack:** C++17, MAME 0.289 driver harness, plain `g++` for the model's unit tests, the project's existing `harness/mame/build.sh`.
|
||||
|
||||
**Spec:** `docs/superpowers/specs/2026-10-16-vt1200-board-model-design.md`
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- **No regression:** with no `VT1200_*` environment variables set, the driver must still reproduce the original wedge — `PC=3FDCE400` with ~199/200 frame samples — verified by the command in Task 1 Step 6.
|
||||
- All harness behaviour stays **opt-in** via environment variables; new behaviour must default off.
|
||||
- **Do not modify MAME's own source** (`/home/arti/code/k-space/mame0289/src/...`). Only the driver source in this repo changes.
|
||||
- Builds use `harness/mame/build.sh` (it now exits non-zero on compile failure — a bare `built:` means success).
|
||||
- The board model must use **only** `<cstdint>`, `<map>`, `<vector>` — no `emu.h` — so unit tests compile without MAME.
|
||||
- Addresses inside the model are in the **harness's units**: window base `| (offset & 0xffff)`, where the base is the disassembly operand shifted right by 4 (e.g. code `@0x64000D0` is harness `0x0640000D`).
|
||||
- Every finding discovered while implementing goes into `harness/mame/BRINGUP_LOG.md`.
|
||||
|
||||
---
|
||||
|
||||
## File Structure
|
||||
|
||||
| File | Responsibility |
|
||||
|---|---|
|
||||
| `harness/mame/vt1200_board.h` | **Create.** Declares `vt1200_board`: the four windows, both shapes, configuration, `read`/`write`/`tick`. No MAME types. |
|
||||
| `harness/mame/vt1200_board.cpp` | **Create.** Implements the register file and the status state machines. |
|
||||
| `harness/mame/test_vt1200_board.cpp` | **Create.** Standalone `g++` unit tests for the model. No MAME, no emulator. |
|
||||
| `harness/mame/vt1200.cpp` | **Modify.** Own a `vt1200_board`, forward the four window callbacks to it, keep the existing env knobs working as configuration. |
|
||||
| `harness/mame/build.sh` | **Modify.** Compile the extra translation unit and symlink it into the MAME tree. |
|
||||
| `harness/mame/BRINGUP_LOG.md` | **Modify.** Record findings. |
|
||||
|
||||
Later plans (separate documents, not this one): *video RAM + scanline renderer*, then *DUARTs / NVRAM / MAC ROM*.
|
||||
|
||||
---
|
||||
|
||||
## Task 1: Extract the existing behaviour into a standalone, unit-tested class
|
||||
|
||||
Behaviour-preserving refactor. This is the riskiest task for regressions, so it lands first and alone.
|
||||
|
||||
**Files:**
|
||||
- Create: `harness/mame/vt1200_board.h`
|
||||
- Create: `harness/mame/vt1200_board.cpp`
|
||||
- Create: `harness/mame/test_vt1200_board.cpp`
|
||||
- Modify: `harness/mame/vt1200.cpp`
|
||||
- Modify: `harness/mame/build.sh`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: nothing (first task).
|
||||
- Produces:
|
||||
- `class vt1200_board` with `uint16_t read(uint32_t addr)`, `void write(uint32_t addr, uint16_t data)`, `void tick()`
|
||||
- `void set_default(uint16_t v)`, `void set_override(uint32_t addr, uint16_t v)`
|
||||
- `void set_monitor_switch(uint8_t position)`, `void set_busy_ticks(int n)`
|
||||
- `void set_model_handshake(bool on)`
|
||||
- constants `VT1200_WIN0` = `0x05800000`, `VT1200_WIN1` = `0x05900000`, `VT1200_WIN2` = `0x06200000`, `VT1200_WIN3` = `0x06400000`
|
||||
|
||||
- [ ] **Step 1: Write the failing test**
|
||||
|
||||
Create `harness/mame/test_vt1200_board.cpp`:
|
||||
|
||||
```cpp
|
||||
// Standalone unit tests for the VT1200 board register model.
|
||||
// g++ -std=c++17 -o /tmp/t vt1200_board.cpp test_vt1200_board.cpp && /tmp/t
|
||||
#include "vt1200_board.h"
|
||||
#include <cassert>
|
||||
#include <cstdio>
|
||||
|
||||
static int failures = 0;
|
||||
#define CHECK(cond) do { if (!(cond)) { \
|
||||
std::printf("FAIL %s:%d %s\n", __FILE__, __LINE__, #cond); failures++; } } while (0)
|
||||
|
||||
static void test_default_read(void)
|
||||
{
|
||||
vt1200_board b;
|
||||
b.set_default(0x0000);
|
||||
CHECK(b.read(VT1200_WIN2 + VT1200_OFF_STATUS) == 0x0000);
|
||||
}
|
||||
|
||||
static void test_override_read(void)
|
||||
{
|
||||
vt1200_board b;
|
||||
b.set_override(VT1200_WIN2 + VT1200_OFF_STATUS, 0x00b7);
|
||||
CHECK(b.read(VT1200_WIN2 + VT1200_OFF_STATUS) == 0x00b7);
|
||||
}
|
||||
|
||||
static void test_monitor_switch_is_mixed_with_latches(void)
|
||||
{
|
||||
vt1200_board b;
|
||||
b.set_monitor_switch(7); // position 7 -> bits 4-6 = 0x70
|
||||
b.write(VT1200_WIN3 + VT1200_OFF_SWITCH, 0x0001); // output latch writes bit 0
|
||||
const uint16_t v = b.read(VT1200_WIN3 + VT1200_OFF_SWITCH);
|
||||
CHECK((v & 0x0070) == 0x0070); // switch bits read back as input
|
||||
CHECK((v & 0x0001) == 0x0001); // output bits read back as latched
|
||||
}
|
||||
|
||||
static void test_busy_bit_arms_on_write_and_clears(void)
|
||||
{
|
||||
vt1200_board b;
|
||||
b.set_model_handshake(true);
|
||||
b.set_busy_ticks(2);
|
||||
const uint32_t status = VT1200_WIN2 + VT1200_OFF_STATUS;
|
||||
const uint32_t cmd = VT1200_WIN2 + VT1200_OFF_CMD;
|
||||
|
||||
CHECK((b.read(status) & 0x0001) == 0x0000); // idle
|
||||
b.write(cmd, 0x00ca); // command arms it
|
||||
CHECK((b.read(status) & 0x0001) == 0x0001); // busy
|
||||
b.tick();
|
||||
CHECK((b.read(status) & 0x0001) == 0x0001); // still busy
|
||||
b.tick();
|
||||
CHECK((b.read(status) & 0x0001) == 0x0000); // done
|
||||
}
|
||||
|
||||
int main(void)
|
||||
{
|
||||
test_default_read();
|
||||
test_override_read();
|
||||
test_monitor_switch_is_mixed_with_latches();
|
||||
test_busy_bit_arms_on_write_and_clears();
|
||||
std::printf(failures ? "%d FAILURE(S)\n" : "all board tests passed\n", failures);
|
||||
return failures ? 1 : 0;
|
||||
}
|
||||
```
|
||||
|
||||
- [ ] **Step 2: Run test to verify it fails**
|
||||
|
||||
Run: `cd harness/mame && g++ -std=c++17 -o /tmp/t vt1200_board.cpp test_vt1200_board.cpp`
|
||||
Expected: FAIL — `vt1200_board.cpp: No such file or directory`.
|
||||
|
||||
- [ ] **Step 3: Write the header**
|
||||
|
||||
Create `harness/mame/vt1200_board.h`:
|
||||
|
||||
```cpp
|
||||
// VT1200 board register model. Deliberately free of MAME dependencies so it can
|
||||
// be unit-tested with plain g++.
|
||||
#pragma once
|
||||
#include <cstdint>
|
||||
#include <map>
|
||||
|
||||
// Window bases in the harness's address units (disassembly operand >> 4).
|
||||
static const uint32_t VT1200_WIN0 = 0x05800000; // data port of the DMA pair
|
||||
static const uint32_t VT1200_WIN1 = 0x05900000; // command port of the DMA pair
|
||||
static const uint32_t VT1200_WIN2 = 0x06200000; // big: STATUS +0x10, CMD +0x20
|
||||
static const uint32_t VT1200_WIN3 = 0x06400000; // big, plus the monitor switch
|
||||
|
||||
// Window-relative register offsets IN HARNESS UNITS.
|
||||
//
|
||||
// The harness address is the firmware's operand shifted right by 4 (MAME's
|
||||
// TMS34010 space is word-unit here), so an operand offset of +0x10 is harness
|
||||
// +0x01, and an operand offset of +0xD0 is harness +0x0d. Getting this wrong
|
||||
// makes registers silently unreachable, so always use these names.
|
||||
//
|
||||
// firmware operand harness offset role
|
||||
// +0x10 0x01 STATUS (bit 0 = ready/done)
|
||||
// +0x20 0x02 COMMAND / DATA
|
||||
// +0x30 0x03 (read/written in the same block)
|
||||
// +0xD0 0x0d mixed I/O -- monitor switch in bits 4-6
|
||||
// +0xE0 0x0e
|
||||
// +0xF0 0x0f
|
||||
static const uint32_t VT1200_OFF_STATUS = 0x0001;
|
||||
static const uint32_t VT1200_OFF_CMD = 0x0002;
|
||||
static const uint32_t VT1200_OFF_IO30 = 0x0003;
|
||||
static const uint32_t VT1200_OFF_SWITCH = 0x000d;
|
||||
static const uint32_t VT1200_OFF_E0 = 0x000e;
|
||||
static const uint32_t VT1200_OFF_F0 = 0x000f;
|
||||
|
||||
class vt1200_board
|
||||
{
|
||||
public:
|
||||
vt1200_board() = default;
|
||||
|
||||
// Configuration (replaces the test-time env knobs).
|
||||
void set_default(uint16_t v) { m_default = v; }
|
||||
void set_override(uint32_t addr, uint16_t v) { m_override[addr] = v; }
|
||||
void set_model_handshake(bool on) { m_handshake = on; }
|
||||
void set_busy_ticks(int n) { m_busy_ticks = n; }
|
||||
void set_monitor_switch(uint8_t position) { m_switch_bits = (uint16_t)((position & 7) << 4); }
|
||||
|
||||
// Bus interface.
|
||||
uint16_t read(uint32_t addr);
|
||||
void write(uint32_t addr, uint16_t data);
|
||||
void tick();
|
||||
|
||||
private:
|
||||
bool is_switch_port(uint32_t addr) const;
|
||||
|
||||
std::map<uint32_t, uint16_t> m_store; // write-back latches
|
||||
std::map<uint32_t, uint16_t> m_override; // fixed values (experiments)
|
||||
uint16_t m_default = 0;
|
||||
bool m_handshake = false;
|
||||
int m_busy_ticks = 0;
|
||||
int m_busy_left = 0;
|
||||
uint16_t m_switch_bits = 0;
|
||||
};
|
||||
```
|
||||
|
||||
- [ ] **Step 4: Write the implementation**
|
||||
|
||||
Create `harness/mame/vt1200_board.cpp`:
|
||||
|
||||
```cpp
|
||||
#include "vt1200_board.h"
|
||||
|
||||
bool vt1200_board::is_switch_port(uint32_t addr) const
|
||||
{
|
||||
// The monitor-selection switch lives in bits 4-6 of winner 3's +0xD0
|
||||
// register (harness offset 0x0d).
|
||||
return addr == (VT1200_WIN3 + VT1200_OFF_SWITCH);
|
||||
}
|
||||
|
||||
uint16_t vt1200_board::read(uint32_t addr)
|
||||
{
|
||||
auto ov = m_override.find(addr);
|
||||
if (ov != m_override.end())
|
||||
return ov->second;
|
||||
|
||||
uint16_t value = m_default;
|
||||
auto st = m_store.find(addr);
|
||||
if (st != m_store.end())
|
||||
value = st->second;
|
||||
|
||||
if (is_switch_port(addr))
|
||||
return (uint16_t)((value & 0xff8f) | (m_switch_bits & 0x0070));
|
||||
|
||||
if (m_handshake && (addr & 0xffff) == VT1200_OFF_STATUS)
|
||||
{
|
||||
if (m_busy_left > 0)
|
||||
value |= 0x0001;
|
||||
else
|
||||
value &= ~0x0001;
|
||||
}
|
||||
return value;
|
||||
}
|
||||
|
||||
void vt1200_board::write(uint32_t addr, uint16_t data)
|
||||
{
|
||||
m_store[addr] = data;
|
||||
if (m_handshake && (addr & 0xffff) == VT1200_OFF_CMD)
|
||||
m_busy_left = m_busy_ticks;
|
||||
}
|
||||
|
||||
void vt1200_board::tick()
|
||||
{
|
||||
if (m_busy_left > 0)
|
||||
m_busy_left--;
|
||||
}
|
||||
```
|
||||
|
||||
- [ ] **Step 5: Run the unit tests to verify they pass**
|
||||
|
||||
Run: `cd harness/mame && g++ -std=c++17 -o /tmp/t vt1200_board.cpp test_vt1200_board.cpp && /tmp/t`
|
||||
Expected: `all board tests passed`
|
||||
|
||||
- [ ] **Step 6: Wire the driver to the model and verify no regression**
|
||||
|
||||
In `harness/mame/vt1200.cpp`: add `#include "vt1200_board.h"`, give `vt1200_state` a `vt1200_board m_board;` member, and in `board_read`/`board_write` delegate to `m_board.read(addr)` / `m_board.write(addr, data)` instead of the current inline logic. In `machine_start`, translate the existing env vars into the model's setters (`VT1200_BOARD_DEFAULT`, `VT1200_BOARD_MAP`, `VT1200_BOARD_MODEL`, `VT1200_BOARD_BUSY_TICKS`, `VT1200_BOARD_SWITCH`). Call `m_board.tick()` once per emulated frame — the simplest correct place is the existing `scanline` callback guarded so it only fires once per frame, or `screen_update` when `cliprect.min_y == 0`.
|
||||
|
||||
In `harness/mame/build.sh`: add the new source to the symlink list and to `SOURCES=` (comma-separated), and add `g++ -c vt1200_board.cpp` to the unit-test recipe.
|
||||
|
||||
Then verify:
|
||||
|
||||
Run:
|
||||
```sh
|
||||
cd /home/arti/code/k-space/vt1200
|
||||
JOBS=8 harness/mame/build.sh 2>&1 | tail -2
|
||||
M=/home/arti/code/k-space/mame0289/vt1200
|
||||
PROG_FRAMES=200 timeout 300 $M vt1200 -rompath harness/mame/roms -video none -sound none \
|
||||
-nothrottle -debug -debugger none -autoboot_script harness/mame/progress.lua -autoboot_delay 0 2>&1 \
|
||||
| grep -oE "PC=[0-9A-F]{8} samples=[0-9]+" | head -1
|
||||
```
|
||||
Expected: `PC=3FDCE400 samples=199` (the original wedge — no regression).
|
||||
|
||||
Then re-run the handshake configuration and confirm it still advances:
|
||||
|
||||
Run:
|
||||
```sh
|
||||
VT1200_BOARD_MODEL=handshake VT1200_BOARD_BUSY_TICKS=2 VT1200_BOARD_SWITCH="0640000D:70:70" \
|
||||
COV_FRAMES=600 COV_WINDOW=300 timeout 400 $M vt1200 -rompath harness/mame/roms -video none \
|
||||
-sound none -nothrottle -debug -debugger none -autoboot_script harness/mame/coverage.lua -autoboot_delay 0 2>&1 \
|
||||
| grep -E "^frame" | tail -1
|
||||
```
|
||||
Expected: a `total_distinct` in the high 50s (not the single-instruction wedge).
|
||||
|
||||
- [ ] **Step 7: Commit**
|
||||
|
||||
```bash
|
||||
git add harness/mame/vt1200_board.h harness/mame/vt1200_board.cpp \
|
||||
harness/mame/test_vt1200_board.cpp harness/mame/vt1200.cpp harness/mame/build.sh
|
||||
git commit -m "harness: extract VT1200 board register model, unit-tested"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task 2: Per-window busy machines (`win_big` shape)
|
||||
|
||||
**Files:**
|
||||
- Modify: `harness/mame/vt1200_board.h`, `harness/mame/vt1200_board.cpp`
|
||||
- Modify: `harness/mame/test_vt1200_board.cpp`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `vt1200_board` from Task 1.
|
||||
- Produces: `void set_window_busy_ticks(uint32_t window_base, int n)` — per-window tick counts, so `0x6200000` and `0x6400000` can be tuned independently. `void tick()` now advances every window.
|
||||
|
||||
- [ ] **Step 1: Write the failing test**
|
||||
|
||||
Add to `test_vt1200_board.cpp`:
|
||||
|
||||
```cpp
|
||||
static void test_windows_are_independent(void)
|
||||
{
|
||||
vt1200_board b;
|
||||
b.set_model_handshake(true);
|
||||
b.set_window_busy_ticks(VT1200_WIN2, 1);
|
||||
b.set_window_busy_ticks(VT1200_WIN3, 3);
|
||||
|
||||
b.write(VT1200_WIN2 + VT1200_OFF_CMD, 0x0001);
|
||||
b.write(VT1200_WIN3 + VT1200_OFF_CMD, 0x0001);
|
||||
CHECK((b.read(VT1200_WIN2 + VT1200_OFF_STATUS) & 1) == 1);
|
||||
CHECK((b.read(VT1200_WIN3 + VT1200_OFF_STATUS) & 1) == 1);
|
||||
|
||||
b.tick();
|
||||
CHECK((b.read(VT1200_WIN2 + VT1200_OFF_STATUS) & 1) == 0); // WIN2 finished
|
||||
CHECK((b.read(VT1200_WIN3 + VT1200_OFF_STATUS) & 1) == 1); // WIN3 still busy
|
||||
}
|
||||
```
|
||||
|
||||
Register it in `main()` with `test_windows_are_independent();`
|
||||
|
||||
- [ ] **Step 2: Run test to verify it fails**
|
||||
|
||||
Run: `cd harness/mame && g++ -std=c++17 -o /tmp/t vt1200_board.cpp test_vt1200_board.cpp && /tmp/t`
|
||||
Expected: FAIL — `'set_window_busy_ticks' was not declared`.
|
||||
|
||||
- [ ] **Step 3: Implement per-window busy state**
|
||||
|
||||
In `vt1200_board.h`, replace the single `m_busy_left` with `std::map<uint32_t, int> m_busy_left; std::map<uint32_t, int> m_busy_ticks_by_win;`, declare `void set_window_busy_ticks(uint32_t window_base, int n);`, and keep `set_busy_ticks` as a shorthand that applies to all windows. In `.cpp`, key both maps by `addr & 0xffff0000` so all four windows behave uniformly, and have `tick()` decrement every entry.
|
||||
|
||||
- [ ] **Step 4: Run the tests to verify they pass**
|
||||
|
||||
Run: `cd harness/mame && g++ -std=c++17 -o /tmp/t vt1200_board.cpp test_vt1200_board.cpp && /tmp/t`
|
||||
Expected: `all board tests passed`
|
||||
|
||||
- [ ] **Step 5: Verify in the emulator**
|
||||
|
||||
Run the Task 1 Step 6 emulator commands unchanged.
|
||||
Expected: identical results (this task is a pure generalisation; observable behaviour must not move).
|
||||
|
||||
- [ ] **Step 6: Commit**
|
||||
|
||||
```bash
|
||||
git add harness/mame/vt1200_board.h harness/mame/vt1200_board.cpp harness/mame/test_vt1200_board.cpp
|
||||
git commit -m "harness: per-window busy state machines for the big windows"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task 3: The DMA pair (`win_pair` shape)
|
||||
|
||||
**Files:**
|
||||
- Modify: `harness/mame/vt1200_board.h`, `harness/mame/vt1200_board.cpp`
|
||||
- Modify: `harness/mame/test_vt1200_board.cpp`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `vt1200_board` from Tasks 1-2.
|
||||
- Produces: `void set_dma_ticks(int n)` and a real model of the pair — a write to the command port (`VT1200_WIN1`) followed by a write to the data port (`VT1200_WIN0`) completes in `n` ticks, after which the command port reads back `0`.
|
||||
|
||||
- [ ] **Step 1: Write the failing test**
|
||||
|
||||
Add to `test_vt1200_board.cpp`:
|
||||
|
||||
```cpp
|
||||
static void test_dma_pair_command_completes(void)
|
||||
{
|
||||
vt1200_board b;
|
||||
b.set_model_handshake(true);
|
||||
b.set_dma_ticks(2);
|
||||
|
||||
b.write(VT1200_WIN0, 0x0000); // data port first (as the firmware does)
|
||||
b.write(VT1200_WIN1, 0x0001); // then a command
|
||||
CHECK(b.read(VT1200_WIN1) == 0x0001); // accepted
|
||||
|
||||
b.tick(); b.tick();
|
||||
CHECK(b.read(VT1200_WIN1) == 0x0000); // completed
|
||||
}
|
||||
```
|
||||
|
||||
Register it in `main()`.
|
||||
|
||||
- [ ] **Step 2: Run test to verify it fails**
|
||||
|
||||
Run: `cd harness/mame && g++ -std=c++17 -o /tmp/t vt1200_board.cpp test_vt1200_board.cpp && /tmp/t`
|
||||
Expected: FAIL — `'set_dma_ticks' was not declared`.
|
||||
|
||||
- [ ] **Step 3: Implement the DMA pair**
|
||||
|
||||
Add `int m_dma_ticks = 0; int m_dma_left = 0;` and `void set_dma_ticks(int n)`. In `write()`, a write to `VT1200_WIN1` (any offset whose high 16 bits are `VT1200_WIN1`) arms `m_dma_left = m_dma_ticks`. In `read()`, while `m_dma_left > 0` return the latched command for `VT1200_WIN1`; once it reaches 0 return `0`. Decrement in `tick()`.
|
||||
|
||||
- [ ] **Step 4: Run the tests to verify they pass**
|
||||
|
||||
Run: `cd harness/mame && g++ -std=c++17 -o /tmp/t vt1200_board.cpp test_vt1200_board.cpp && /tmp/t`
|
||||
Expected: `all board tests passed`
|
||||
|
||||
- [ ] **Step 5: Commit**
|
||||
|
||||
```bash
|
||||
git add harness/mame/vt1200_board.h harness/mame/vt1200_board.cpp harness/mame/test_vt1200_board.cpp
|
||||
git commit -m "harness: model the 0x5800000/0x5900000 DMA command/data pair"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task 4: Make it configurable, and confirm on real firmware behaviour
|
||||
|
||||
**Files:**
|
||||
- Modify: `harness/mame/vt1200.cpp`
|
||||
- Modify: `harness/mame/BRINGUP_LOG.md`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: everything from Tasks 1-3.
|
||||
- Produces: env knobs `VT1200_BOARD_BUSY_W2=<n>`, `VT1200_BOARD_BUSY_W3=<n>`, `VT1200_BOARD_DMA_TICKS=<n>`.
|
||||
|
||||
- [ ] **Step 1: Add the env plumbing**
|
||||
|
||||
In `machine_start()`, read the three new variables and call `set_window_busy_ticks(VT1200_WIN2, ...)`, `set_window_busy_ticks(VT1200_WIN3, ...)`, `set_dma_ticks(...)`. Keep every existing variable working unchanged.
|
||||
|
||||
- [ ] **Step 2: Rebuild and run a parameter sweep**
|
||||
|
||||
Run each of `VT1200_BOARD_BUSY_W2` in `{1,2,4,8}` (with `W3` fixed at 2, DMA at 2, handshake on, switch `0x70`), recording the coverage result:
|
||||
|
||||
```sh
|
||||
for N in 1 2 4 8; do
|
||||
printf "W2=%s -> " "$N"
|
||||
VT1200_BOARD_MODEL=handshake VT1200_BOARD_BUSY_W2=$N VT1200_BOARD_BUSY_W3=2 \
|
||||
VT1200_BOARD_DMA_TICKS=2 VT1200_BOARD_SWITCH="0640000D:70:70" \
|
||||
COV_FRAMES=900 COV_WINDOW=300 timeout 600 $M vt1200 -rompath harness/mame/roms -video none \
|
||||
-sound none -nothrottle -debug -debugger none -autoboot_script harness/mame/coverage.lua -autoboot_delay 0 2>&1 \
|
||||
| grep -E "^frame" | tail -1
|
||||
done
|
||||
```
|
||||
|
||||
Expected: this is an experiment, not a pass/fail — but record which value moves the firmware furthest (most `total_distinct`, or a park point outside the blit loop).
|
||||
|
||||
- [ ] **Step 3: Check whether `INTENB` ever becomes non-zero**
|
||||
|
||||
Run `harness/mame/intr.lua` with the best sweep setting from Step 2.
|
||||
Expected: if `INTENB CHANGED -> <non-zero>` appears, the firmware has passed into interrupt setup — record it, because that is the level-0 boundary. If it stays `0000`, record that too; it means the model is still missing an input.
|
||||
|
||||
- [ ] **Step 4: Record findings**
|
||||
|
||||
Append a section to `harness/mame/BRINGUP_LOG.md` titled
|
||||
"Register model (2026-10-16)" with: the sweep table, the `INTENB` result, and which
|
||||
window/offset still looks unmodelled.
|
||||
|
||||
- [ ] **Step 5: Commit**
|
||||
|
||||
```bash
|
||||
git add harness/mame/vt1200.cpp harness/mame/BRINGUP_LOG.md
|
||||
git commit -m "harness: configurable board model busy timings + findings"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Self-review
|
||||
|
||||
**Spec coverage:** Task 1 establishes the two-shape structure and the unit-test harness; Task 2 covers the `big` shape (`0x6200000`/`0x6400000` with STATUS `+0x10`/CMD `+0x20`); Task 3 covers the `dma` pair (`0x5800000`/`0x5900000`); Task 4 turns env knobs into configuration, which the spec explicitly requires, and its sweep answers the "which values are right" question with data rather than a guess. The spec's *video RAM + renderer* and *DUART/NVRAM* items are deliberately **not** in this plan — they are the two follow-on plans named in the File Structure table above.
|
||||
|
||||
**Placeholder scan:** no TBD/TODO; every code step contains real code; the sweep in Task 4 Step 2 is an experiment by design and its expected-result line says so.
|
||||
|
||||
**Type consistency:** `set_window_busy_ticks(uint32_t, int)` (Task 2) is used unchanged in Task 4; `set_dma_ticks(int)` (Task 3) likewise; the constants `VT1200_WIN0..3` are defined in Task 1 and used in Tasks 2-4 with the same names.
|
||||
|
||||
---
|
||||
|
||||
## Execution note
|
||||
|
||||
The repository is **not** under git (`git status` reports no repo), so the `git add`/`git
|
||||
commit` steps will fail until it is initialised. Execute them only if the user initialises
|
||||
a repository; otherwise treat "Commit" as "stop here and report", and rely on the
|
||||
BRINGUP_LOG for the audit trail.
|
||||
@@ -0,0 +1,136 @@
|
||||
# VT1200 board model — design
|
||||
|
||||
Date: 2026-10-16
|
||||
Status: design approved in conversation; spec written for review
|
||||
|
||||
## Goal
|
||||
|
||||
Get the MAME VT1200 driver through **level 0 and level 1 power-up self-tests to the
|
||||
Terminal Manager window**, with the screen rendering — so the emulator can be compared
|
||||
against the real machine (font table, then the pie graph, then Terminal Manager).
|
||||
|
||||
Level 1 is the smallest scope that produces something *verifiable*. Level 0 alone risks
|
||||
declaring victory on a subtle fake; a fully usable terminal (LANCE + LAT + X sessions) is
|
||||
a larger project that this one is a prerequisite for anyway.
|
||||
|
||||
## Evidence this design rests on
|
||||
|
||||
* The firmware polls a **status bit** and writes a **command**, and the routine that does
|
||||
it takes the **window base as an argument** (bit `0x3FA911C0`), i.e. the windows are
|
||||
driven generically.
|
||||
* Observed layout, from `VT1200_BOARD_LOG` plus disassembly:
|
||||
|
||||
| offset | role | evidence |
|
||||
|---|---|---|
|
||||
| `+0x10` | STATUS, bit 0 = ready/done; bit 2 tested after `FILL XY` | gate 1 poll `while(!(read8(base+0x10) & 1)) delay(100)` |
|
||||
| `+0x20` | COMMAND / DATA, written in a delayed sequence | `move a9,*a11(0x20),0` then `delay(10)`, values 0xCA/0xEA/0x3A/... |
|
||||
| `+0xD0` | mixed I/O — bits 4-6 = **monitor switch** (input), rest latched output | the monitor-switch check at `0x3F2C8320` |
|
||||
|
||||
* Four windows exist: `0x5800000`, `0x5900000`, `0x6200000`, `0x6400000`. All are in the
|
||||
harness's address units (disassembly operand `>> 4`).
|
||||
* The RAM dump contains ROM strings and ROM pointers — the firmware appears to run from a
|
||||
**RAM copy** of the image.
|
||||
* Hardware, confirmed from the service guide, the wiki part number (`TMS34010FNL-50`) and
|
||||
a readable motherboard photo:
|
||||
* CPU **TMS34010FNL-50 = 50 MHz**; display **1280x1024 @ 72 Hz**, mono, 1 bpp.
|
||||
* Main RAM is **CY7C109 SRAM** (~1 MB on the system logic board; 4 MB total).
|
||||
* Video memory is a **separate bank of Toshiba TC514256 DRAMs** — the framebuffer is
|
||||
*not* in main RAM, which is why a RAM dump never located it.
|
||||
* Level 0 = 8 tests within 5 s (incl. interrupt, video control register, I/O data path,
|
||||
illegal monitor, LANCE-not-reset). Level 1 = 15 tests within 25 s (incl. video RAM,
|
||||
video, NVR, Ethernet address ROM, DUART1/2 + timers, host/printer/keyboard/mouse ports,
|
||||
keyboard, mouse). Level 1 begins with on-screen patterns, then a **pie graph**.
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
vt1200_state (driver)
|
||||
|- TMS34010 50 MHz, 16 pixels/clock (exists)
|
||||
|- screen / palette needs a real renderer (exists, incomplete)
|
||||
|- main RAM 4 MiB (exists)
|
||||
|- vt1200_board NEW: owns all four windows
|
||||
| window[0] 0x5800000 <- register file, common layout
|
||||
| window[1] 0x5900000 <- +0x10 STATUS
|
||||
| window[2] 0x6200000 <- +0x20 COMMAND/DATA
|
||||
| window[3] 0x6400000 <- +0xD0 mixed I/O
|
||||
|- video RAM NEW: separate memory, display scans from here
|
||||
\- (later) mc68681 x2, am79c90, NVRAM, MAC ROM as SIBLING devices
|
||||
```
|
||||
|
||||
Decisions:
|
||||
|
||||
1. **The board device owns no other device.** DUARTs, LANCE, NVRAM and the MAC ROM are
|
||||
siblings wired alongside, so each is independently testable and addable one at a time.
|
||||
2. **Status bits are state, not constants.** A write to `+0x20` arms a small state
|
||||
machine; `+0x10` reports its progress. Forcing constants merely relocates the wedge
|
||||
(demonstrated twice: gates 3 and 4).
|
||||
3. **Test-time env knobs become configuration.** `VT1200_BOARD_SWITCH` etc. become
|
||||
constructor/config parameters, so the model is real rather than a debugging patch.
|
||||
The env-var behaviour stays available for experiments.
|
||||
|
||||
## Risk, and the step this design takes first
|
||||
|
||||
The weakest link was the claim that **all four windows share one layout**. It was
|
||||
validated before construction (see result below), and it is **half true** — there are
|
||||
**two shapes, not one**.
|
||||
|
||||
### Validation result (2026-10-16)
|
||||
|
||||
Every absolute reference to each window, by offset:
|
||||
|
||||
```
|
||||
W2 0x6200000: +00(36) +10(8) +20(1) +30(9) +D0(15) +E0(5) +F0(8)
|
||||
W3 0x6400000: +00(18) +D0(29) +E0(9) +F0(17)
|
||||
W0 0x5800000: +00(24) +20(1) +D0(1)
|
||||
W1 0x5900000: +00(12) +10(1)
|
||||
```
|
||||
|
||||
* **W2 and W3 share a common register set** — identical offsets `+0xD0`, `+0xE0`,
|
||||
`+0xF0`, and both have a `+0x10` STATUS / `+0x20` COMMAND pair. This is the shape the
|
||||
design was built on, and it holds.
|
||||
* **W0 and W1 are a different, simpler shape** — dominated by `+0x00` (24 and 12 sites),
|
||||
with almost nothing at the higher offsets. That matches the disassembly, where
|
||||
`0x5800000`/`0x5900000` act as a **command/data pair at the window base** feeding a
|
||||
byte-addressed (DMA-style) device.
|
||||
* `+0xD0` is referenced at file offset `0x12` — inside the **reset vector region**, which
|
||||
corroborates the service guide's statement that the monitor switch is read only during
|
||||
power-up.
|
||||
|
||||
**Consequence for the design:** two register-file classes, not one.
|
||||
|
||||
```
|
||||
vt1200_win_big (W2 0x6200000, W3 0x6400000) -> STATUS +0x10, CMD +0x20,
|
||||
+0x30, +0xD0 (mixed I/O), +0xE0, +0xF0
|
||||
vt1200_win_pair (W0 0x5800000, W1 0x5900000) -> command/data pair at the base,
|
||||
bit->byte (DMA-style) addressing
|
||||
```
|
||||
|
||||
The "status bits are state machines" and "env knobs become configuration" decisions are
|
||||
unchanged. This is a much cheaper discovery than it would have been after building a
|
||||
single generic class.
|
||||
|
||||
## Scope
|
||||
|
||||
**In:** the four windows as a modelled register file; status state machines; video RAM so
|
||||
the display can render; the two DUARTs and NVRAM/MAC ROM as far as level 1 requires; the
|
||||
monitor switch as configuration; a scanline renderer producing a real image.
|
||||
|
||||
**Out (for now):** a working LANCE/TCP-IP/LAT stack; keyboard and mouse *input* beyond
|
||||
what the level-1 tests probe; sound; bit-accurate peripheral timings.
|
||||
|
||||
## Validation
|
||||
|
||||
* Per-register: write a command, assert the status machine reaches "done".
|
||||
* Per-level: the firmware prints its own progress. Success at level 0 is the firmware
|
||||
moving past the 8 tests; at level 1, reaching the patterns/pie graph/Terminal Manager.
|
||||
* **Visual oracle:** the rendered screen should match the real boot sequence — a
|
||||
character/font table, then a large circle (the pie graph) — which we have on video.
|
||||
* Regression: with the model disabled, the driver must still reproduce the original
|
||||
wedge at `PC=3FDCE400`.
|
||||
|
||||
## Success criteria
|
||||
|
||||
1. ~~The shared-layout hypothesis is confirmed or refuted, with evidence.~~
|
||||
**DONE 2026-10-16 — half confirmed: two shapes (W2/W3 common; W0/W1 a command/data pair).**
|
||||
2. `INTENB` becomes non-zero and level 0 completes.
|
||||
3. A rendered frame shows the boot patterns, comparable against the real machine.
|
||||
Reference in new issue
Block a user