David M. Acklam's
early impressions on the Galaxy VME graphics
card for the Mega STE and TT
Like many die-hard
Atari computer enthusiasts, I have more than
one Atari computer remaining in my collection.
Since I started using Atari computers way back
in the early 1980s with an Atari 800, several
computer systems have come and gone from my
collection and yet there are still several either
up and running, or standing by in my closet.
My 8-bit days ended in the early 1990s when
I bought my first ST system. This was a nice
used Mega ST with the Atari SLM804 laser printer.
Over the years I traded up for a new Mega STE,
added a Falcon and Portfolio and picked up a
nice used 1040ST. Then I made a major investment
in a Hades which drove all my other systems
into the closet.
While I was learning
to make the most from the Hades an opportunity
came up that allowed me to purchase a used and
slightly modified TT for almost nothing. A local
company called Datastitch had been using Mega
STs, STEs and TTs to run embroidering machines.
Atari was moving away from computers and developing
the Jaguar gaming system, so Datastitch was
switching over to a PC-driven system and was
off-loading all of its used Atari systems,
as-is, for next to nothing. I picked up a TT
with 4 MB of ST RAM, a 120 MB internal
hard drive and a mystery color card for only
$200. I spent another couple of hundred dollars
or so to get the motherboard unmodified and
even added an Ajax chip to get the high density
floppy capability. However, since the Hades
was my primary computer, my newly refurbished
TT simply went into the closet to join the rest
of my collection.
Within the first
year I had my Hades it suffered a major hardware
failure that required it to be shipped back
to Medusa, via the computer dealer I purchased
the system from. Unfortunately the dealer was
about to close down his business and to make
a long story short, my broken Hades ended up
being lost for over two years before I was able
to recover it and send it to Medusa myself to
get it repaired. None the less, with my Hades
out of the picture I pulled both the TT and
the Falcon out of the closet and made use of
both. The Falcon for the graphics and the TT
for the speed.
As time passed
I started using the TT more than the Falcon
and so began looking at upgrades to the system.
I added 4 MB of TT RAM and an external
2.1 GB hard drive. I also added an external
CD drive and an external CD-R drive to the system.
Lastly I decided to add more memory and
a new color card. I actually never used the
mystery color card that came with it since it
only supported 16 colors for the embroidery
machine. I had hoped to get a Crazy Dots or
Nova card but soon found out that both were
out of production and used ones were not to
The memory expansion
came via the Magnum card which allowed me to
simply drop in 32 MB using standard EDO
SIMMs. The answer to the color card was found
on the internet when I located Mario Becroft's
web site in New Zealand.
He was still developing the Galaxy color card
(see appendix) that would also include an Ethernet
interface. I was able to pick up one of his
beta versions of the card without the Ethernet
circuitry for around $380 delivered. Although
not perfect, what this card does provide is
a clean VME plug-in interface for a full-screen,
high-resolution color capability to the TT.
of the card are as follows:
- Pixel clock
rates up to 130 MHz.
- 16-bit color
up to 1,280x1,024 at 76 Hz on typical SVGA
- 4 MB of
video RAM (16 MB optional).
drawing performed in hardware makes screen
refreshes very fast (in this beta version
much of this has not been implemented yet).
driver for fVDI (free VDI) supplied.
running the card in my TT using a small 14
inch NEC MultiSync C400
monitor so Iím using only the 800x608 resolution
instead of its maximum of 1,280x1,024. The card
is also capable of running in monochrome mode
but Iíve not used this capability yet.
card was straightforward. I simply removed the
plate that holds the two serial ports on the
back of the TT. Since I was not using either
of these ports I elected to disconnect and remove
them completely from the motherboard. Next I
slid the card into the VME card cage until it
was fully engaged with the connector (figure
1). I installed the driver software supplied
with the card. VCONF.PRG, VSET.PRG and FVDI.PRG
were installed in the Auto folder with VSET.PRG
and VCONF.PRG running very near the top and
before FVDI.PRG. Then I installed FVDI.SYS,
VMEGRAPH.PBF and VMODE.TXT on the root directory.
Finally I connected my
MultiSync monitor to the card and tried to boot up the
system. I was a bit disappointed that there
was no display of the boot process and when
things finally completed, I failed to get the
expected desktop. It turned out that because
I'm running NVDI I had to get some additional
assistance from Mario to get the card to work.
What he had me do was to simply rename my NVDIDRV1.SYS
through NVDIDRVH.SYS files so they would not
run. This fixed my problem with getting the
card to boot up. Last, I simply had to edit
the VMOD.TXT file to set my display to
my desired 800x600 resolution. (Note that I
had problems getting the screen pager to work
in this resolution so as part of the trouble-shooting
effort with Mario, I bumped it up to 800x608.
Unfortunately this didnít solve the problem
but I elected to just leave it in this resolution).
1: Galaxy card installed in
VME card cage in back of TT.
I have found
that most of the programs I use run just fine
with my beta version of the Galaxy color card
but there are exceptions. The Recipe program
crashes the system as does the Grocery program.
Starbase and El Cal run but both have problems
with the screen display. In addition, a
list of problems, some of which I reported,
have been identified and addressed by Mario
are listed below. Also note that this list is
primarily a list of notes to Mario so that when
he can ever get around to dealing with them
he can confirm them and attempt to correct them.
Some of them, like MagiC, have not been confirmed
fVDI/Galaxy doesn't work with MagiC.
fVDI itself is known to work with MagiC although
apparently there can be some oddities. Need
to check since this is probably just an error
in the user's configuration, but might be a
Desktop pager crashes at 800x600 and 800x608.
OK, it doesn't really crash, but output is shown
on old screen, so system may appear to have
frozen. OK, BCONOUT.GTP gets this working. Simply
double-click on the program or configure the
desktop to automatically load it.
Vision 4.0 toolbox icon problem.
Vision 4.0 icons in toolbox are displayed as
white boxes. Icons are drawn by userdef, which
is successfully copying icon data of all 1s.
Problem appears to be in transformation on loading
of resource file, which is done by custom routines.
Have a copy of special test code from the authors
to debug this.
Imagecopy quits on loading.
Apparently a Line A related problem in Imagecopy.
Looking at Imagecopy 4, the jsr at $2CC
goes into the main program. Shortly thereafter
the bsr at $106C goes into the
actual main program. When the bug manifests
itself, a conditional branch before the bsr
does not happen and the program exits. Simply
changing the beq to bra seems
to get the program working. Johan says it is
checking mouse cursor shape, apparently to determine
whether running as a DA. Presumably the above
fix will make it fail as a DA.
Calamus does not support 16-bit mode.
driver must be written. Also several bugs that
prevent Calamus from loading even with driver
must be patched.
Thing color mini-icons not displayed.
Color mini-icons are not displayed in Thing.
Freedom icon display garbled.
Freedom displays garbled icons. Don't know which
version or why. Checked version 1 and it seems
OK, at least on Falcon TC mode.
N.AES quits on loading with lineafix.
No idea why. Workaround is to enable lineafix
with the fVDI DA.
Speed of Light fails in TC mode.
Might be a feature of SOL.
Flash 2 text display wrong.
Text is duplicated with two displays of the
text side by side. Could be a Flash 2 feature
in TC mode.
Papyrus 8.18 and 8.3 display color images incorrectly.
Color images wrongly rendered, probably thinks
screen byte order is swapped or similar. Might
be caused by VDI drawing/not drawing to extra
green bit. Newer papyrus versions also have
Papyrus 8.3 help problem.
A minor problem with Papyrus 8.3, using the
help menu to navigate to a section (double-clicking
on the subject) brings up a black screen. If
you scroll the screen it will finally bring
up the text. What seems to be happening is that
the help window background changes color at
various times, to various colors including white,
light gray, dark gray and... black (which is
the problem described). Not sure what makes
it change color; scrolling around the document
seems to make it come right. Johan checked in
Falcon TC mode and it doesn't happen, but may
only occur when NVDI is being used.
Papyrus and Edith show a white mouse cursor
instead of black when running under Geneva.
Problem happens only under Geneva; could be
a palette problem.
Diamond Edge icon colors all one color.
Diamond Edge icons at bottom of screen appear
in all one color, making them hard to distinguish.
Actually they are black with dark blue outlines.
All color icons in the program are affected,
but it does not seem critical since the icons
can be discerned.
LDW Power shows color blob in sheet.
LDW power shows a colored blob in upper left
of sheet, but this does not matter very much.
I was the person
that identified the problems with the desktop
pager crash, Imagecopy, Speed of Light, Flash
2, white mouse cursor, Diamond Edge and LDW
Power. Mario has verified them but to date has
not provided a complete set of fixes. Since
I donít use Flash any more it is now a ďdonít
careď. He did provide a work around for
the pager crash but I ended up using Neodesk
to call Steno whenever I access the screen pager.
The suggested fix for Imagecopy only provided
a limited capability of operation with the color
card. I would love to see a complete fix for
this as I would for Speed of Light. The remaining
problems I ran into are minor and may be related
to the current color palette set-up. Personally,
I would love to see all the bugs corrected if
possible. Even though the programs that I had
problems with seem to work on my Hades in 256-color
mode, some of the other problems identified
in the problem list could also fail on other
A few other things
I would also love to see added to this product
include an improved user interface to change
screen settings and also see what is going on
during boot-up. As I learned on my initial installation,
the normal TOS displays during boot are not
displayed on the card output. However,
they can be viewed if one connects another monitor
to the VGA output on the TT. The lack of this
boot-up display is a minor problem for me but
it would be helpful for trouble-shooting boot
I also would
like to have the ability to run the card in
256-color mode simply to see if some of the
programs that donít run in true color may work
OK with the card. Speed of Light and Imagecopy
are two of my favorites that fall into this
category. There are other programs that misbehave
with the card such as Starbase and El Cal that
may work in 256 color mode.
2: TT with Galaxy card in 800x608
Mario regarding the current status of the card
and to see if he had any updates. Unfortunately,
like many of us, Mario has been very busy with
other things in his life now and has not had
any time to update the card. He did tell me
that there are several things he is not happy
with that hopefully some day he can fix but
not at the present. Also, the card is currently
not available because of all the issues mentioned,
and others, which leads Mario to believe that
the card is not in a suitable condition for
sale. However, Mario did say that if anyone
else wanted a card, on the clear understanding
that it is unfinished, has known defects and
is unsupported (though he would try to support
it at least in terms of getting it installed)
then subject to logistical issues in testing
and shipping the card, he could sell more cards.
Mario also did indicate that he would like to
finish the project some day if he had the time
but I suspect the law of consumer demand or
lack thereof may be a key factor. In the meantime,
the beta card I purchased works nicely on my
TT with a handful of minor warts. As for the
programs that donít run on my Galaxy card set-up,
I can always run them on the Hades, Falcon or
Mega STE if needed. Figure 2 is a picture
of my TT set-up running in 800x608 resolution
under Geneva/Neodesk, illustrating the excellent
quality of the 16-bit color display.
The Galaxy card in detail
- Jumpers for
selecing the address where the card's
memory and I/O registers are mapped.
- Pads for
test during manufacture and potentially
for connecting future expansion boards.
VMEbus controller that provides an interface
for configuring the FPGA, which has
to be reconfigured each time it is powered
up (that is, the configuration is volatile).
Once the FPGA has been configured, it
takes over most VMEbus interface functions.
- The memory, which is synchronous dynamic RAM (SDRAM). The card can
be configured with either 4 or 16 MB of 32-bit RAM running at
100 MHz. In burst mode (supported by the blitter and video controller), access
can be essentially one word per cycle.
main part of the board, this is a field
programmable gate array (FPGA). It
contains the equivalent of 100,000 logic
gates, which can be configured by software
to form any circuit. This board was
so designed that a configuration is
loaded from disk (via part 3) when
the computer boots (this is done by
a program that resides in the Auto folder
on the Atari). This means that the whole
design can be upgraded by simply replacing
a file. All the other parts on the board
are just peripheral; all functions of
the board are controlled by the design
that resides in the FPGA. The design
can be changed, but at present includes:
supply (the board uses 5 V, 3.3 V and
2.5 V supplies for different functions).
Parts of the phase-locked loop (PLL) clock synthesizer. This
photograph is of an old revision, when I was still using an off-the-shelf
synthesizer. This proved to have very poor performance, so I have now removed
the crystal and the larger chip at left, implementing these functions instead
in the FPGA. The two tiny chips at right are still present and provide
the analogue part of the PLL circuitry.
for the video sync signals.
RGB 140 MHz video DAC with sync-on-green
oscillator, the system's main clock
leading to the VGA connector and some
Ethernet AUI transformer and connector.
phase-locked loop clock synthesizer
used to produce the system clock and
video clock. This can go up to about
150 MHz (the nominal system clock is
100 MHz). Also a video timing generator.
video data pipeline capable of supporting
1-bit monochrome and 16-bit direct colour
visuals with a 4-bit overlay visual
and 4-bit cursor.
- A high-speed
blitter that utilizes SDRAM burst transfers
(almost one word per cycle (memory width
is 32 bits)) can be programmed to perform
masked copies and rectangle or polygon
fills (solid or stippled).
SDRAM controller that controls the memory
and arbitrates access from several sub-systems
(such as the blitter, video pipeline,
CPU, and VMEbus).
- A high-performance
RISC processor designed to control drawing
operations. It is a general-purpose
16-bit processor that runs at 100 MHz
with a 7-stage pipeline (all instructions
are 1-cycle). It has a windowed register
file (16-register window, 256 registers
total) and has direct access to peripheral
registers such as the blitter. Instructions
can be fetched from SDRAM or a high-speed
(pipelined) internal buffer that enablse
the CPU to continuously execute one
per cycle. The CPU was designed to be
simple and fast for FPGA implementation,
so it is a bit unusual to program. The
pipeline has very little control, so
the long branch delay slots and pipeline
hazards are user-visible. However, this
is good for graphics programming, since
the routines can be highly optimized
to avoid any pipeline stalls. The CPU
incorporates some special features such
as a three-cycle hardware multiply,
special pixel pack/unpack instructions.
It also has direct single-cycle access
to the blitter buffer, so fast complex
transformations can be done, and the
CPU can even modify pixel data while
the blitter is transferring it in and
out. There is also a very useful debug
interface on the VMEbus so that the
CPU can be completely controlled by
a debugger running on the host.
the Atari, essentially the whole VDI
could be implemented in this processor
probably hundreds of times faster than
the host could do it. All the host would
need to do is queue the commands, so
not only would drawing operations themselves
be very fast, but the host CPU would
be free to continue other processing.
Although the CPU is fully implemented
and working, alas, only a few of these
possibilities have been implemented
in software as yet.
- 10 Megabit Ethernet
controller, but this is only about half
finished. I have had it working successfully
on the TT, but there is still a lot
of integration and fine tuning to be
done. It has been in this state for
a couple of years.
to Mario Becroft for the technical information.