All about programming the Atari Falcon
BLECH!!
Tidy coding? Ever heard of it? In times like these with multiple atari machines (and clones) that are all different, it might be worth considering. Now with more and more people upgrading with accelerator boards, it is essential.
EARX of FUN gets down to clean things up (and hopefully not introduce some extra bugs while he's at it :))
First of all the general rules:
- Save all hardware registers before you run the main program and after running restore them all. Good examples are video/audio and interrupt settings.
- All the memory you want to use you should reserve first. Either use BSS or Malloc() to do this. Using memory beyond your programs scope often doesn't cause trouble in singleTOS, but it does for sure in MiNT and Magic. One extra you should avoid as well is using low memory as spare space! Alot of old ST programs tend to do this which will hang the Falcon and TT straight away.
- Never use Line A. It might be of use in extreme situations such as 128 bytros, but can cause severe problems all around. Atari adviced not to use Line A since the introduction of the TT and still people do it.
- Avoid selfmodifying code. Not all selfmodifying code should be avoided. I agree it sometimes is a must. The kind you should avoid is changing the code you loop through in the same loop! This causes the 030 and forth to make errors. Selfmodifying code can be allowed in most cases where you first build a complete routine and then run it (i.e. C2P routines!).
1) Falcon (also called Falcy by some of freaks)
This machine had it's share of problems from the start. A buggy XBIOS, undocumented hardware and so forth made it harder for coders to know what they were doing. The result was mostly trial and error situations and an attitude like "if it runs on my own machine, it's good".
Today people finally understand the bugs in the system and now know the hardware registers Atari hid from them. There is info on all of this. But there is another problem. The accelerators falcon owners use also cause a lot of trouble. Be it software or hardware extras.. They all tend to cause some compatibility flaws.
The following are important to get demos/games running on a maximum amount of Falcon's.
VGA support:
even though RGB modes might be less stressful on the bus and hence free up CPU time, many lardasses don't like hooking their falcon up to a TV again. Also VGA 100Hz modes actually eat less bustime than VGA 50Hz/60Hz modes. VGA 100 even has the advantage of true hardware doublepixels!!!
Even more important is the failure of RGB modes with accelerators. Many extensions such as screenblaster, blowup, nemesis and centurbo all cause RGB modes to fail.
VIDEL registers (fixed by sage/escape):
Please check out the great article MrPink wrote in Maggie27. This contains perfect resolution switching for all modes. Even 2 colour ones and ST modes!
DSP handshaking:
The transferrate between CPU<->DSP (much used for demo-effects) can boosted alot when not polling if the CPU or DSP is ready (this is called handshaking). Leave the headshake out and you will gain speed. But with a different DSP clock (40MHz, 50MHz) this is very problematic. When the DSP sends the next word to the CPU, the CPU might not have fetched the first one. This means there is data loss!
The solution can be putting handshaking back in (slower on normal Falcon), or only using handshake on accelerated DSPs. There is also a good trick where you can do own handshake only once every 4 or 8 words. This seems to work fine.
TTRAM (mxalloc()):
When you are the lucky owner of TT RAM in your Falcon this becomes a must (thanx to evl/dhs for these tips). You can of course activate TTRAM bits in the executable file. The usage of these bits and the call is as follows:
Set all the TT bits ON. This can be done with lots of tools and also the THING desktop. In your program you can use the mxalloc() to specifically only allocate STRAM for both SDMA and VIDEL buffers. Mxalloc() returns an address you should store. Every other buffer can simply be held in TTRAM, which is done automatically when the TT bits are on.
2) ST progs compatibility with Falcon, TT, Hades, Milan, etc.
If you use your own video routines (i.e. you create a fast game or a demo) in your ST program, you can forget Milan and Hades compatibility. Milan and Hades are GEM clones!!! They have a 680x0 yes, and TOS compatible stuff too, but they aren't hardware compatible in any way.
If you program something for every TOS clone ever made, you should use either character based display with the traditional GEMDOS. A more suitable alternative to games is GEM programming. GEM programming is not as easy as GEMDOS and of course GEM can be very slow on a standard ST.
A more interesting subject is coding for REAL atari's. This way you can still use the features of the ST (direct video access), YM2149, STe sound, etc. If you want to do this you should understand:
- Many people still have the old 1MB 1040ST (not STE!), so no blitter, no DMA sound.
- TT's don't have a blitter!
- On TT and Falcon you can't open borders. The video chips don't have the same undocumented features as the old STs!
- TT's can't run bootable disks. Please use normal executable files.
- Falcon lacks YM2149 shadow registers. Means some sound routines don't work.
- Falcon has no microwire interface like the STe and TT.
- Every boosted ST or newer atari has a higher clock frequency which means hard syncing to clock cycles isn't possible anymore! This technique was often used for getting over 16 colours on screen (SPEC512, photochrome) and 50fps horizontal scrolling on a basic ST.
- Most importantly Falcon and TT have a different memorymap from the ST. So poking stuff in low-memory where it isn't allowed, will most definitely crash the machines.
As a consequence, you mostly have to test on which ATARI you are running. The blitter routines will work on STe and Falcon, but crash on the TT. This isn't the worst part. The sound routines are much more annoying. The Falcon misses some YM2149 features and some pins on this chip are now even used to put the IDE and speaker on/off.
Have fun coding all tidy and stuff! (most coders now think: "Yeah, right!
Sucker!" ;-PP)
EARX/FUN 1999
