Issue 25: Nov 2002
Features
- | Foreword
- | Pocket an Atari!
- | Collecting Atari Games
- | Tip of the day
- | Unfinished Business
- | I had a dream: The Grid Sequencer!
- | Atari in the USA: Mr Atari's IDE
- | Atari 7800: The system that could (but didn't)
- | Tablet PCs in Today's World
- | Atari Goes Metal
Reviews
- | Unreal Tournament 2003
- | V-Rally 3
- | Do you have 19 inches of rack mounted Atari?
- | Multi Worms
- | Pixel Power
News
| Pixel Power 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 be found. 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. The specifications of the card are as follows: Pixel clock rates up to 130 MHz. 16-bit color (65,536 colors). Resolutions up to 1,280x1,024 at 76 Hz on typical SVGA monitors. 4 MB of video RAM (16 MB optional). High-speed drawing performed in hardware makes screen refreshes very fast (in this beta version much of this has not been implemented yet). Accelerated driver for fVDI (free VDI) supplied. I'm currently 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. Installing the 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).
Figure 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 yet. Problem: fVDI/Galaxy doesn't work with MagiC. Comment: 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 bug. Problem: Desktop pager crashes at 800x600 and 800x608. Comment: 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. Problem: Vision 4.0 toolbox icon problem. Comment: 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. Problem: Imagecopy quits on loading. Comment: 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. Problem: Calamus does not support 16-bit mode. Comment: Special driver must be written. Also several bugs that prevent Calamus from loading even with driver must be patched. Problem: Thing color mini-icons not displayed. Comment: Color mini-icons are not displayed in Thing. Problem: Freedom icon display garbled. Comment: Freedom displays garbled icons. Don't know which version or why. Checked version 1 and it seems OK, at least on Falcon TC mode. Problem: N.AES quits on loading with lineafix. Comment: No idea why. Workaround is to enable lineafix with the fVDI DA. Problem: Speed of Light fails in TC mode. Comment: Might be a feature of SOL. Problem: Flash 2 text display wrong. Comment: Text is duplicated with two displays of the text side by side. Could be a Flash 2 feature in TC mode. Problem: Papyrus 8.18 and 8.3 display color images incorrectly. Comment: 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 the problem. Problem: Papyrus 8.3 help problem. Comment: 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. Problem: Papyrus and Edith show a white mouse cursor instead of black when running under Geneva. Comment: Problem happens only under Geneva; could be a palette problem. Problem: Diamond Edge icon colors all one color. Comment: 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. Problem: LDW Power shows color blob in sheet. Comment: 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 graphics cards. 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 problems. 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.
Figure 2: TT with Galaxy card in 800x608 resolution.
I contacted 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. Appendix: 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. Bootstrap 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. The 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: A 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. A 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). An 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 instruction 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, and 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. On 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. Power 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 PLL clock 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. Buffer for the video sync signals. 10-bit RGB 140 MHz video DAC with sync-on-green support. Crystal oscillator, the system's main clock source. Tracks leading to the VGA connector and some filtering. The Ethernet AUI transformer and connector. VGA connector. Thanks to Mario Becroft for the technical information.
Useful link
Mario Becroft http://gem.win.co.nz/mb/
[ Top of page ] | MyAtari magazine - Review #5, November 2002
Copyright 2002 MyAtari magazine