11.4.2 How not to fit an Afterburner

How not to fit an Afterburner040

Let me start this piece by stating

The AB is not, to use one of those horrible new Microsoft/PC phrases, Plug'n'Play. I repeat it is not Plug'n'Play.
The AB will require your Falcon to be recased.
The AB could have serious implications for your software collection.
Fitting the AB could seriously damage you mental health.
I am not great at writing, typing or spelling.

A Quick History Lesson

For those of you that have read my article in the FFF about fitting my Falcon into a System Solutions Lighthouse Tower, you will know that I have been waiting to get my hands on the Afterburner (AB) since July 1995. At the time Gasteiner were the UK distributer, because the AB was sold by GE-Soft. Since then it swapped to Overscan, so in the UK Compo took over. Compo went under so Titan Designs grabbed the distribution earlier this year. I wanted to get an 68RC040 powered board because it has a built in FPU. The LC040 does not have the FPU. Sadly the RC version was becoming impossible to get hold of but the overall performance increase and extra RAM would be a more than a touch useful and only my 3D model rendering with Xenomorf would suffer, assuming that the 040 would be slower than the 030+FPU combination, so I settled for an LC040 board.

Todays Second Lesson: Computer Architecture

I am no expert in this so I apologise in advance for any errors. This is the my understanding of how it works.
The Falcon's normal buses run at 16MHz and are shared by the 030, the RAM, the DSP, the FPU, and the sound and video hardware. This compromises the overall performance of the Falcon.
Let us look at the updating of the screen at say 60 times a second on a 640x480, 16 colour VGA display. This means that about 150K is sent through the buses 60 times a second, that totals around 9MB a second. So even with the machine doing nothing it is shifting 9MB of data round every second. The buses are capable of a transfer rate of 64MB per second. Therefore 14% of the machines time is spent just updating the screen. This is why the machine speed alters with resolution. A 256 colour display takes twice the memory of an equivalent 16 colour display, and there requires twice the bus time. This is why something like the TurboBlanker display speeds up the machine. The screen updates are stopped, freeing up the buses.
The AB has it's own buses that are independent of the Falcon's, it is effectively a separate computer. This is assuming that there is FastRAM installed, without it the AB has to to constantly access the ST-RAM nullifying most of the performance gains. Making it like installing the PowerUp2 32MHz upgrade. Software run solely on the AB will not be affected by the constant screen update. Though of course the software still has to send data of any changes made to screen to the ST-RAM.
Most new software will automatically use the FastRAM. Older ones can often be forced to using the utility supplied with the AB or one of the many others available. Be warned not all software will let you force it and much will not work if you do. Again it is the games and things that access the hardware directly that tend not to work.

The Sorry Tale

The AB arrived in a very big box. I began to wonder if my tower case was going to have enough space to house the board. Buried in the foam chips was an anti-static bag containing the AB, a smaller one with two 16MB SIMMs, a ribbon cable, a disk, and the instructions.
The instructions were in German. Entirely.
My German is limited to say the least, though when it comes to technical things many words are the same in any language. I could make out the basics and with help of a translation program on the Falcon and a large English-German dictionary I managed to work out most of what was said. Just enough to be worried.

Dimensions

The board is 6.5" (16.5cm) long and 5" (13cm) wide. From the top of the fan to the bottom of the expansion slot socket it is about 1.5" (4cm) deep. When plugged into the Falcon's expansion slot it pretty much fills the gap from the power supply to the front of the motherboard and from the lefthand edge of the PSU to the lefthand edge of the IDE drive. Through ports are provided so that anything that is normaly in the expansion slot, Expose for example, can be fitted on top of the AB. Though the closeness and height of the 040 and it's fan may mean that spacers need to used to lift extras above it.

Fitting

The most obvious thing that needed attaching was a ribbon cable with a plug on one end that plugs onto the AB board with 8 free wires on the other end that needed to be soldered to various chips on the motherboard. The chips are the four at the front of the motherboard, they are called the GALs, I think.
If only that was it it would be a very simple upgrade to perform. Just solder these 8 wires to 8 pins on various chips. Plug the AB board into the expansion slot and plug the ribbon cable into the AB. Wire the fan into a suitable voltage line. Doddle.
Even the separating of a couple of pins on the 030 from the motherboard is easy enough... Did I not mention that bit? Oops. This is simple to do but it is one of the most worrying things I have ever done. Having 'broken' the pins there is no going back. The machine isn't useless, not quite, more of which later.
Sadly it is not that simple. At least for most of us.

Clock Patch

The big stumbling block was the requirement of a 'clock patch' to be fitted. This is needed due those helpful people at Atari cutting corners and giving us owners problems. From what I have been told parts of the Falcon board are almost useless. Junctions and resistors in places that really don't need them and but for the addition of a simple component a set of signals that are rather weak. Basically a 16MHz signal is generated for the system to run by. This signal is split into three for various parts of the board to use. Resistors are used to prevent bouncing signals merging together and giving an unreliable signal. This all combines to give a signal that most of the time is OK but if you are doing direct-to-disk recording and/or using fast SCSI devices or fitting an acceleraator board the weakness of the signal can cause corruption. The clock patch boosts this signal. All C-Lab Falcons have this fitted and many of you will have one installed already. You lucky b*****ds.
There are several variations of the clock patch all achieving the same goal. There are diagrams of two different ones in the manual, the German desriptions for which were almost impenetrable. Did it matter which one I used? Did it depend on the revision version of my Falcon? Hhheeelllppp!
David Encill at Titan Designs put me in touch with someone who knew what they were doing and he pointed me in the right direction. I got my Falcon going without the patch and he E-mailled me a couple of diagrams and some instructions, all in English. An additional chip needs to be bought, a 74F04, it is a hex-inverter. Pins on this need to be connected with various points on the board, most of which are on one particular chip. It took me several goes to get it running but eventually it did.
With the various wires and the chip I soldered I was a little concerned that a bare wire may come into contact with the bottom of the AB. If you piggy-back the 74F04 onto the the relevant chip the AB will almost be resting on it if plugged in firmly. To prevent any short circuits I sellotaped a piece of thin cardboard to the bottom of the AB.
Without the clock-patch I found the Falcon was very unstable, which is to be expected. Crashes could happen at any time and even booting it became a problem. Using a 2 colour resolution enabled me to get reasonable level of stability and while trying to buy some 74F04s it spent nearly a week without the clock patch. It was used very little during this time but with no problems. My main worry was file corruption and consequent possible hard drive data damage.
The actual soldering was not too much of a problem. I am a real novice when it comes to doing such things and perhaps, in hindsight, it was a little foolish to attempt it. Taking a soldering iron to your thousand pound computer that you have used nearly every day for two years really makes you think.
You would think that soldering and desoldering various wires several times would damage the motherboard irreparably but these things are amazingly resilient.

I fitted the Falcon into the tower case successfully, not that it compares in complexity to fitting an AB, and was determined to do this. With the design of the tower I could hinge open the machine up and do all the work with the need even to take the motherboard out of the case. Though many would prefer to.

Software Patches

The next big problem was the software patches. To make the 040 and FastRAM work software patches need to be run. One does something to the MMU and makes the machine run from the 040. If the Falcon is boot t without the patches, i.e. holding down control, then it thinks it has an 8MHz 68020 chip, according to the cookie jar, and acts accordlingly. Without the AB plugged in it won't boot at all. The others are a FastRAM patch and an FPU 'emulator'. The FastRAM and FPU patches caused me alot of problems. The FastRAM patch has a disike of being autobooted and the FPU patch would just bomb.
The patches should be auto booted and be the first to be loaded. Executing them from the desktop is possible but the system may get confused so it is best avoided.
The manual suggested that FPU patch was a software 68882 emulator which would allow my FPU using software to run even if it wouldn't be as quick as an RC040. Any FPU that you already have fitted in the Falcon will be ignored when AB is installed. What I have been told is that the FPU patch is actually for patching the RC040's FPU to be more 68882 compatible, not a software emulator. Apparently a software FPU emulator exsists but has yet to be tracked down.
According to people in the know there are two different verions of the patches and two different versions of the board. Each board type has a corresponding patch. So you might not even get the right set of patches. Wonderful!!
In the middle of all this I got a patch written by Doug Little, of Apex fame, which replaces the MMU and FastRAM patches. It is much better.

Now we come to the FastRAM saga

Initial use of the supplied patches gave the expected 32MB of FastRAM but software really didn't like running in it. Doug's patch reduced the available RAM to only 11MB. Swapping the two SIMMs over gave zero RAM. From this I assumed that one of the SIMMs didn't work at all and that the other was a little faulty, it seemed a reasonable assumption. I know you have to be very careful about static electricity especially with SIMMs. I was as careful as possible. With only the partly working SIMM plugged in the original patches still caused the machine to think it had 32MB installed. Work that one out. Even with the reduced 11MB of Mr. Little's patch some software didn't work at all or would crash after some usuage.
An updated version of Doug's patch reduced the RAM to only 8MB but I didn't have any of the software problems of earlier. I wanted to get the SIMMs tested on another computer but this didn't come about as soon as hoped so I tried the SIMMs again in a last ditch attempt. If they didn't work this time they were being sent back. This time I also decided to have a fiddle with some 'jumpers' that were on the AB board next to the SIMM slots. No-one seemed to know what the jumpers were for so I thought I would try and find out.
There are two jumpers each made up of of three pins and a cap too short either pins 1&2 or 2&3 together. The non-working SIMM on the first go showed the 8MB that the partial working SIMM gave. Changing the jumpers round enabled me to get the proper 16MB. Putting the 2nd SIMM in and further jumper fiddling gave me the full 32MB.
With various combinations of SIMMs and jumpers I could get 0, 4, 8, 12, 16 or 32MB of FastRAM.
I just couldn't believe it. A SIMM that just a couple of weeks previously gave no RAM at all suddenly gave the right amount. I had even had doubts about the functionality of the SIMMs sockets themselves and I didn't fancy sending the whole lot back.
<p>I still can't figure out if I missed something last time. Oh well it all looked like it was working.
The next test was the software that previous took a distinct dislike to FastRAM. Would it run?
Would filling the RAM show up damage in the SIMMs?
I spent a fun few minutes running MultiTOS, not a thing I often use, gradually and gratuitously filling the memory.

MultiTOS

Three copies of Xenomorf 2, each with several hundred K of objects loaded.
GEM-View with 20-30 pictures loaded.
Two-In-One
ESS-Code
Oasis
CAB + a couple of others


All on in 256 colour 640x480 screen mode. None of them were really doing much, the system would have been crawling along.
I got to within about 2MB of filling the FastRAM before stopping. The standard built in 4MB of ST-RAM was hardly touched.
The software that didn't previously like the FastRAM's mere presence now worked. And no problems with any corruption.
6 weeks after getting the AB I had the Falcon I should have. After a brief return to instability caused by one of my soldered wired coming lose the Falcon has been very stable. It usually spends at least couple hours a day switched on, it has even done a few all night rendering sessions, without problems.

Software Compatibility

Half the 'fun' of any upgrade like this is finding out how much of your software collection no longer runs. The answer is not too much of it. The real problems will be with Falcon specific stuff such as games. A few will work but not many.
The vast majority of normal software works. Thanks to the advent of MultiTOS and the reduction in Atari users most new software is written to work on all Atari machines. This should all work with the AB.

By preventing the AB being initialised and reverting to the 8MHz 68020 mode some software that takes a dislike to the 040 or FastRAM will work.
Here is a short list of software and comments:

Apex Media & lt v2.15

doesn't work but updated versions do.
The latest, v2.2, is free to every Apex user that buys an AB from Titan Designs.

 

Rainbow 2

The art package, doesn't work.
This is a shame because I only got it a few weeks before getting the AB.

 

JpegDSP v2.2

Dave Oldcorn's Jpeg, Gif and Targa viewer, runs but not in FastRAM.

 

Xenomorf v1 & v2

Works fine.
WinX works, ROMSpeed bombs but with D.Little's AB patch the ROM is automatically copied into FastRAM.

 

NameNet

(v4.002 is the one I have), the database used by the FFF will only work in a 2 colour mode.

 

CAB/STiK

Work, no problems.

 

Oasis1.35/NOS

No problems

 

Oasis2/ICE

Are giving a few problems if run in FastRAM and is more unstable if run in ST-RAM.

 

Selectric

The replacement fileselector, fine.

 

Two-In-One

The archive shell, fine.

 

Stoop

The boot controller, even works in '020 mode' so the AB software patches can be chosen to boot by it.

 

Backward

Doesn't work so forget about the old ST games collection.

 

SubStation

The demo I have from an STF coverdisk runs but the graphics are a bit of a mess.

 

LlamaZap

The demo I have runs.

 

SteelTalons

The demo I have does not run.

 

Stardust

Runs but because it boots before the AB patches so the Falcon will be in 8MHz 020
but it makes no difference to it.

 

Outside

The virtual memory program doesn't work, but with 32MB of FastRAM who needs it.

 

BadMood

The Falcon Doom WAD file viewer, runs considerably smoother at around
8 fps most of the time. With more RAM all the textures are cached
removing the occasional loading pauses.

 

Starball

Dave Oldcorn's Pinball type game, works but not in FastRAM.

 

Performance Figures

Okay, okay.Your thinking.
This is all very well but how fast is it?
The most obvious thing is that the desktop is just plain quicker, using something like WinX to give realtime scrolling and dragging, it is noticably smoother. Using higher resolution has less of a performance hit than previously, for the reasons stated above.
Using CAB/STiK online the actual downloading isn't any quicker but the formating of text and tables and converting the graphics is much quicker so more can be achieved in the same amount time.
I haven't ever used it much but MultiTOS will be more usable with more RAM and processing power.

Yes, yes, but we want actual figures!

Okay. For things that make much use of the DSP, such as JPEG viewers the speed increase isn't really noticable. For real CPU intensive tasks it is around 6 times faster.
For example I have several MPEG viewers. One that uses the DSP gains an increase of less than 1 frame a second with AB+FastRAM, on top of the usual 13fps. Another player that only uses the CPU and consequently normally with the 030 rarely more than 1 frame a second, showing the power of the DSP, with the 040 and FastRAM this jumped to around 7fps. Without the FastRAM it got to around 2fps.

I would like to show some amazing figures for rendering but because my AB doesn't have an FPU and the Falcon's is ignored, rendering is actually slower. But because of the extra RAM I can render much more complex models that would only have been possible with virtual memory before. So in that respect rendering complex models will quicker because the VM will slow the system to a crawl. Trust me I know about exceptionally long rendering times using VM. As mentioned earlier Outside does not work on the AB. It must be looking for the 030 cookie jar entry not finding it.

More figures! Give us more figures!

Okay, okay. Some tables for you.
'TT' in the tables below refers to TT-RAM, the Atari name for FastRAM.

Wow! Zipping up almost as fast as Unzipping!

This shows the extra speed of having the FastRAM installed and the merits of the DSP. The DSP can decode the JPEG faster than the 040 but the 040/FastRAM combination can easily out do the 030 when it comes to the dithering to 256 colours.

The FPU figure is not included in the AB test because it crashest the test is attempted.
The AB CPU figure would be higher still if the FPU could be included.

In summary

With better instructions, and this wonderful write up, fitting should not be too difficult, if a little nerve racking. Hopefully by the time you read this an English manual will be done. If not, ask Titan Designs for all the instructions and patches that were given to me. They will make life much easier.
As tricky and agonising as fitting became at times getting it working certainly gave me a huge sense of achievement. The reason that my Falcon is so much quicker and has more memory is because I fitted it. Every time I switch it on the reason it even boots up is because I fixed it. And if it starts to go wrong, as it has done once, I have more chance of fixing it myself, or at least understanding what is wrong.
Ultimately the Afterburner has not yielded quite the level of performance gain I had hoped for, primarily due to the lack of FPU to compare rendering speeds. The general speeding up of everything is nice though and the extra memory is fantastic. No more out of memory messages. For normal use 32MB is more than enough, perhaps even a little excessive, 8 or 16 would be just as effective, but with the recent drops in the cost of memory why not?

To summarise the summary

If I can do it then so can you and it was definitely worth it.
If you have any comments or questions you can E-mail me:
rich@rjelwell.demon.co.uk
Copyright (c) 1996 by Richard Ewell