Atari 8bit is superior to the ST

[+poobah]

So is it any wonder that during the golden age of home computing a sales figure record breaker was born in the guise of the C64? not really, it was the perfect compromise with no bullshit and a decent price (due to superior intellect of JT purchasing Moss Technologies and the C64 chipset being produced by two of the most talented engineers of the era).

 

That'd be "MOS Technology" which became CSG "Commodore Semiconductor Group"

Edited December 27, 2009 by poobah

[+poobah]

I can't really think of any game on the A8 that couldn't be reproduced exactly on the ST. The machine is just more powerful, and it's enough that the crippling lack of A8 style hardware scrolling can be overcome by software.

 

Nautilus. 2 independant scrolling regions. Sometimes a dozen or more objects independantly moving in each window.

 

The problem with using brute force CPU power to duplicate one method that another machine does almost for free in hardware is that it leaves little left for duplicating other things.

 

Oh I suspect you could take the boulderdash code from earlier in the thread, unroll it to 2 screen halves and just use a different map pointer.

[atariksi]

Good point ( I'd been assuming it was 192 lines of background + 8 lines of score )

 

Not like it makes a different to A8. Add up to 240 scanlines of LMS/HSCRL/VSCRL and it hardly adds any time to the scrolling unlike ST (and C64). Looks like A8 Boulderdash is scrolling in the 24th line vertically (although 23 are visible); however, in ST's case don't you have to split your routines for the 16*16 renderer...

 

Don't care about the C64 ( not in this topic )

...

It's in parenthesis as some people have shown up here just to mock the A8 because they are C64 fanatics rather than argue A8 and ST.

 

Of course you're right about the vscroll on A8. But what the code here proves is that it's possible to reproduce the scrolling found on the A8 with software on the ST, ...

Wrong. It proves that you can barely fit a 3-plane scroll into a frame's time which was required for the Boulderdash example. Atari still has superior scrolling as it takes less time and can still do more than 8-colors and scroll them.

 

I can't really think of any game on the A8 that couldn't be reproduced exactly on the ST. The machine is just more powerful, and it's enough that the crippling lack of A8 style hardware scrolling can be overcome by software.

 

( Like your VGA analogy - once the cpu could send 320x200x256 every frame to the graphics card all of the hardware tricks could be reproduced in software. )

Sorry, VGA can transmit a frame and have plenty of time left-over within the frame. ST is not more powerful in this example; since once you eat up all the frame's time for 5-color games, any other stuff A8 does you will struggle to get done. By the way, you didn't complete your analysis. Now give the cycles remaining in the frame for each system.

[atariksi]

I can't really think of any game on the A8 that couldn't be reproduced exactly on the ST. The machine is just more powerful, and it's enough that the crippling lack of A8 style hardware scrolling can be overcome by software.

 

Nautilus. 2 independant scrolling regions. Sometimes a dozen or more objects independantly moving in each window.

 

The problem with using brute force CPU power to duplicate one method that another machine does almost for free in hardware is that it leaves little left for duplicating other things.

 

Smaller scroll area - 64+96 makes it easier in some ways. ( I'd probably use a different technique as it's more of a fixed background )

The brute force comment is true, but in many cases even when duplicating a 'free' effect there are quite a few cycles left. ( And the A8 is a poor example, as the display is not free )

 

Now I'm going to have to play Nautilus again.. ( Uncharted 2 goes back on the shelf )

 

And by the way, I listed 5 items A8 is superior when compared with ST as an initial list and A8 can combine those 5 as well. So just because you can make up for scrolling within a frame's time for 5-color modes, doesn't allow you to dismiss the rest of the list. And don't forget that A8 can do full-screen of various graphics modes by switch graphics modes rather than replicating pixels and lines. So just like scrolling is problematic on ST, same with sprites. Once you fill up the screen with sprites especially with double/quad width, you will essentially have to update the entire frame on ST.

[STE'86]

well i dont know about the rest of u but i am convinced.

 

so all it leaves is to ask at what point atariksi is going to point us at something a bit more advanced than Hero or River Raid or Joust that shows us all a practical demonstration of the hardware thats in his Cray- sorry Atari 800 box thats sitting on his desk.

 

u do HAVE something more advanced than 1983 to prove all this rhetoric i assume?

 

u must have. coz only a complete dickhead would go to all this trouble of proving in words a machine is streets ahead of a 10 year newer computer and not have a game or demo up their sleeves which proves its superiority completely wouldnt they?

 

wouldnt they????

 

oh...

 

Steve

[atariksi]

well i dont know about the rest of u but i am convinced.

...

Convinced that ST taking the full frame to barely muster 3 planes across a few pixels is superior to the A8 doing it with a few register changes? Didn't think you were that dumb. Another case of generalizing from a some specific case. I haven't even timed/verified his code for NTSC to see if even the 3 planes fit within the frame time. Perhaps, the current Boulderdash is efficient as it is.

 

so all it leaves is to ask at what point atariksi is going to point us at something a bit more advanced than Hero or River Raid or Joust that shows us all a practical demonstration of the hardware thats in his Cray- sorry Atari 800 box thats sitting on his desk.

 

u do HAVE something more advanced than 1983 to prove all this rhetoric i assume?

...

I suggest learning some logic so you can understand the point being made. A8 scrolling is superior to ST. Whether you can reduce planes and make some games scroll within a frame's time doesn't make the ST scrolling superior-- same for the other points listed. I only keep games that I like so I don't have a hundred examples to give you.

[Crazyace]

Of course you're right about the vscroll on A8. But what the code here proves is that it's possible to reproduce the scrolling found on the A8 with software on the ST, ...

Wrong. It proves that you can barely fit a 3-plane scroll into a frame's time which was required for the Boulderdash example. Atari still has superior scrolling as it takes less time and can still do more than 8-colors and scroll them.

It's not a 3 plane scroll - please take a look at the code, or at least read my description. It's a 16 colour 320 resolution display scrolled at 160 pixel resolution - based on palletted 4 colour characters.

It does fit in a frame though, which is enough to reproduce Boulderdash a lot better than the version that came out.

 

By the way, you didn't complete your analysis. Now give the cycles remaining in the frame for each system.

I'm sorry, I thought you might look at the code. But here's some numbers.

 

Per group of 4 chars ( header ) - (28+32+48)*5*12 = 6480 cycle

Per 4 char line - 48+76=124*5*184 = 114080 ( Matching boulderdash, as Pete pointed out )

Total 120560 cycles, giving over 12k cycles for other stuff on NTSC ( >39k cycles on PAL )

 

A lot closer than the 4 colour only code, but I expect some of the better ST programmers ( especially some of the demo guys ) could reproduce the game (on any ST/STe) using less than 10% of the cycles I've used.

[atariksi]

I don't know why you guys have to call the C64 a "cheap piece of crap" to get the point across that you prefer A8. I think when you do that, it loses whatever point you may be trying to make. ...

No, if you prove it's crappy, then regardless of who says "it's cheap piece of crap", it does not take away from the point being made. It's not just for C64 for though. Anything that has inferior timing to another, you can say the inferior machine's timing is crappy. Anything that uses a cardboard RF vs. a solid metal, you can say the cardboard is a crappier RF shield. Etc. Etc.

 

...controllers, and the games look very similar. The kids today - born and growing up with 16-gig cellphones - would laugh their asses off at either and think they're both "Grandpa pieces of shit." The differences argued about so vehemently would be like the punch line of a joke, as in the historical context,...

Bullcrap. I just had people over my house with their Nintendo Cubes, XBOXes, etc. I put on the Atari and they all preferred the Atari games -- easier to play, use, and very addictive. I played the Mario Kart Double Dash-- I had no idea what was going on in the game and the controllers didn't help with their 10 buttons. I couldn't even tell which way the car was driving initially-- they had some "deformed frog" looking creature on one of them. Perhaps, a hybrid mix of a dinosaur and a frog.

[atariksi]

Of course you're right about the vscroll on A8. But what the code here proves is that it's possible to reproduce the scrolling found on the A8 with software on the ST, ...

Wrong. It proves that you can barely fit a 3-plane scroll into a frame's time which was required for the Boulderdash example. Atari still has superior scrolling as it takes less time and can still do more than 8-colors and scroll them.

It's not a 3 plane scroll - please take a look at the code, or at least read my description. It's a 16 colour 320 resolution display scrolled at 160 pixel resolution - based on palletted 4 colour characters.

It does fit in a frame though, which is enough to reproduce Boulderdash a lot better than the version that came out.

 

By the way, you didn't complete your analysis. Now give the cycles remaining in the frame for each system.

I'm sorry, I thought you might look at the code. But here's some numbers.

 

Per group of 4 chars ( header ) - (28+32+48)*5*12 = 6480 cycle

Per 4 char line - 48+76=124*5*184 = 114080 ( Matching boulderdash, as Pete pointed out )

Total 120560 cycles, giving over 12k cycles for other stuff on NTSC ( >39k cycles on PAL )

 

A lot closer than the 4 colour only code, but I expect some of the better ST programmers ( especially some of the demo guys ) could reproduce the game (on any ST/STe) using less than 10% of the cycles I've used.

 

I'll take a look at the code once I get some time. It's theoretically impossible to copy 4 planes for a full screen given the 68K bandwidth limitations.

 

You can stop speculating that it can be done in less than 10% of the cycles.

[Crazyace]

And by the way, I listed 5 items A8 is superior when compared with ST as an initial list and A8 can combine those 5 as well. So just because you can make up for scrolling within a frame's time for 5-color modes, doesn't allow you to dismiss the rest of the list. And don't forget that A8 can do full-screen of various graphics modes by switch graphics modes rather than replicating pixels and lines. So just like scrolling is problematic on ST, same with sprites. Once you fill up the screen with sprites especially with double/quad width, you will essentially have to update the entire frame on ST.

 

I'm not going to argue against your list ( Can't really be bothered, and I probably agree with them anyway..( at least if they're sane ) ) I only became intrigued because you went on about Boulderdash ( and Joust ) as examples of the inferior machine, when they're more like unoptimised implementations. After all, I wouldn't use 'Journey to the Planets' as the best the A8 could do.

[Crazyace]

I'll take a look at the code once I get some time. It's theoretically impossible to copy 4 planes for a full screen given the 68K bandwidth limitations.

 

You can stop speculating that it can be done in less than 10% of the cycles.

 

No problem, I wrote it for my info more than anything else, and then posted it so at least there would be something to back up my claim.

I'll see if I can get the Battlesquadron first level to assemble ( I couldn't fully recover one of my data discs ), as that uses vertical smooth scrolling ( 16 colours ) with roughly 20 scanlines worth of time. - Not speculation, but actual figures for a game.

 

To me, Sync scrolling is just as valid as the prior 0 hacks on the 8 bits, something that relies on an undocumented reliable mechanism in the hardware to give a boost to the machine capabilities.

[atariksi]

And by the way, I listed 5 items A8 is superior when compared with ST as an initial list and A8 can combine those 5 as well. So just because you can make up for scrolling within a frame's time for 5-color modes, doesn't allow you to dismiss the rest of the list. And don't forget that A8 can do full-screen of various graphics modes by switch graphics modes rather than replicating pixels and lines. So just like scrolling is problematic on ST, same with sprites. Once you fill up the screen with sprites especially with double/quad width, you will essentially have to update the entire frame on ST.

 

I'm not going to argue against your list ( Can't really be bothered, and I probably agree with them anyway..( at least if they're sane ) ) I only became intrigued because you went on about Boulderdash ( and Joust ) as examples of the inferior machine, when they're more like unoptimised implementations. After all, I wouldn't use 'Journey to the Planets' as the best the A8 could do.

 

You'll never see me making claims about a machine being inferior just by looking at a few games. In fact, I argued in reverse for the most part-- that it's better to look at capabilities of the hardware. I said Boulderdash and Joust are inferior on ST. But I'm not going to generalize from that that the machine is inferior. It's the reverse-- since I know ST takes a big hit for scrolling (via cycle calculations), I look for examples where that big hit takes place. It's more deductive logic than inductive.

[Crazyace]

And that's even before the someone drops a sync-scroll version of BD here showing that it can match the A8, but in 16 colours and at medium resolution

 

Maybe it's one for FormatWar ? ST Vs. A8 on BoulderDash.. It's no biggy code-wise, so it'd be interesting I reckon

 

 

Well if you've got any sync scroll code lying around

 

( I thought I'd take a look back for Atariksi's 5 points... and got as far back as then when I thought why am I bothering )

[carmel_andrews]

Another Atari vs Commodore thread possibly...or a clone thereof

[Crazyace]

You'll never see me making claims about a machine being inferior just by looking at a few games. In fact, I argued in reverse for the most part-- that it's better to look at capabilities of the hardware. I said Boulderdash and Joust are inferior on ST. But I'm not going to generalize from that that the machine is inferior. It's the reverse-- since I know ST takes a big hit for scrolling (via cycle calculations), I look for examples where that big hit takes place. It's more deductive logic than inductive.

 

Well, on a like for like case - If I scroll a 16 colour 80x192 line screen on the ST it will take less than a quarter of the cycles ( It will also only be quarter of the screen, but that's a limitation of the A8 )

I should compare 320x192 2 colour as that's the only resolution that matches between A8 and ST.

( Also GTIA on the A8 wasn't launch, maybe I should compare an ST model with blitter for timings )

 

So for me:

 

ST has 640x200 4 colour mode - better than A8

ST has 320x200 16 colour mode - better than A8

ST has 512 colours, better than 128 for launch A8

ST has faster processor - better than A8

A8 has scrolling, better than ST

A8 has 4 sound channels, better than ST

ST has parallel floppy disc, better than A8

ST has RGB video, better than A8

ST has DMA harddrive, better than A8

ST has 512k ram, better than A8

 

... and so on, can't be bothered making a longer list ....

[andym00]

And that's even before the someone drops a sync-scroll version of BD here showing that it can match the A8, but in 16 colours and at medium resolution

 

Maybe it's one for FormatWar ? ST Vs. A8 on BoulderDash.. It's no biggy code-wise, so it'd be interesting I reckon

 

 

Well if you've got any sync scroll code lying around

 

( I thought I'd take a look back for Atariksi's 5 points... and got as far back as then when I thought why am I bothering )

 

The not being a biggy code-wise thing.. I meant the logic of BD, not writing the Sync scroll I've never written one, and all of that malarkey was well after I left the world of programming on the ST.. Didn't mean that to sound like I was going to do that and just dump it here.. God! Cycle accurate stuff like that in 68k is not my cup of tea at all!!!

Plus, I've got more than my hands full with A8 stuff, and then there's the small matter of just very suddenly having fallen in love with the Coco3 which might see things go even more not to plan if I don't control the urges to play

 

I'm sure I saw some sync scrolling stuff floating around on www.atari-forum.com/ forums.. And also there's some thing I recall about being able to use the DMA chip to perform 1 bit shifts as well, or some such guff, but it was probably hot-air, just like some of the industrial level hot air claims being made in here as well

 

Really I'm just watching this thread only for it's enormously fun car crash value and entertainment Long may it run!

[PeteD]

A8 has 4 sound channels, better than ST

 

4 8 bit channels which aren't the greatest at playing notes in tune unless you combine 2 at a time to 16 bit accuracy...

 

It's not an all or nothing case of course but the fact that you may need to do it is a limiting factor.

 

 

Pete

[Crazyace]

Plus, I've got more than my hands full with A8 stuff, and then there's the small matter of just very suddenly having fallen in love with the Coco3 which might see things go even more not to plan if I don't control the urges to play

 

I'm sure I saw some sync scrolling stuff floating around on www.atari-forum.com/ forums.. And also there's some thing I recall about being able to use the DMA chip to perform 1 bit shifts as well, or some such guff, but it was probably hot-air, just like some of the industrial level hot air claims being made in here as well

 

Really I'm just watching this thread only for it's enormously fun car crash value and entertainment Long may it run!

 

I should be programming SPE stuff at the moment ( although I think it's safe to say that it's not really required this week ) - and I've got random A8 and 7800 and Jaguar stuff in my coding folder to play with.

I saw the Coco3 with the Donkey Kong and Pacman games, and the recent 256 colour pictures, but it's NTSC only which is a bit of a let down... so I'm managing to resist it.. ( and one day, maybe my Pandora console will actually arrive, and I can run the A8, C64, ST and Amiga emulators on a DS sized machine with a keyboard )

[kool kitty89]

And ALL 8-bit computers ARE NOT designed to play 80s arcade games even those designed in the 1980s.

Wait... All are not, so no 80's computer was specifically designed with arcade game playing ability as a key feature? What about the X68000 or FM Towns?

 

Regardless of scrolling and sprites, the ST was still at a disadvantage with sound, generally speaking. (other than simply having more PU resourse for sample playback and such, even then, POKEY's 4-bit linear DACs do have soe advantage compared to using the YM2149, especially via PWM -though that's not the only way)

 

I'd call it a draw - pokey was pretty cool, and had lot's of tricks but the ST sound chip had an amazing advantage - the volume control was logarithmic rather than linear. That made it possible to produce an effective 8 bit ( or even a little more ) signal from the mixture of the 3 channels.

 

Hmm, I remember you mentioning this before, but I got a different impression in another discussion here: http://sega-16.com/forum/showthread.php?t=8473

SMS, they set a square channel to a high playback rate and modulate the volume. But the volume isn't linear and since it's low of granularity steps, it's noisy. Another method is to combine this process on the three square channels so that the mixing gets more "in between values". There's the problem that you can't change all volumes fast enough, so that introduces some noise/artifacts. And there's the PWM method. You set the channel to high frequency and turn the volume on(max)/off to produce PWM waveform. Problem with this method is that it needs to be really fast and with precise timings. Pretty much all the methods require almost 100% processing time for the timed-code playback routine. The method that uses all three square channels sounds the best.

Then again, that was in specific context of the SN76489 PSG, not the AY/YM2149, so it might be different. I'd though the 76489 used logarithmic based volume control as well ("stepped" volume rather than linear), but int hat case it's 4-bit (16 volume levels), so the YM2149 might have more control there.

[Marius]

ST has parallel floppy disc, better than A8

 

And? This is also possible on Atari 8bit. when you make a list, you should not mention things that both systems can.

 

When you compare A8 and atari ST you must compare 'bare' systems. So Atari ST without floppy (520 ST).

 

And about harddrive. OK atari 8bit can hookup harddrive on Parallel Port and Cart Port, which is not DMA, but really fast. Fast enough I'd say.

[dwhyte]

[Crazyace]

Hmm, I remember you mentioning this before, but I got a different impression in another discussion here: http://sega-16.com/forum/showthread.php?t=8473

SMS, they set a square channel to a high playback rate and modulate the volume. But the volume isn't linear and since it's low of granularity steps, it's noisy. Another method is to combine this process on the three square channels so that the mixing gets more "in between values". There's the problem that you can't change all volumes fast enough, so that introduces some noise/artifacts. And there's the PWM method. You set the channel to high frequency and turn the volume on(max)/off to produce PWM waveform. Problem with this method is that it needs to be really fast and with precise timings. Pretty much all the methods require almost 100% processing time for the timed-code playback routine. The method that uses all three square channels sounds the best.

Then again, that was in specific context of the SN76489 PSG, not the AY/YM2149, so it might be different. I'd though the 76489 used logarithmic based volume control as well ("stepped" volume rather than linear), but int hat case it's 4-bit (16 volume levels), so the YM2149 might have more control there.

 

On the ST it was quick enough to do in an interrupt. The normal per voice volume level was {1,sqrt(1/2)}*{1,1/2,1/4,1/8,1/16,1/32,1/64,1/128} so the dynamic range was there, and the tables were precalculated to approximate a linear curve using 3 voices ( sometimes two )

I never looked at PWM for improving the signal capabilities as such, only to multiplex voices at one point ( and I've got no idea where the code is, it's probably on one of my old replay disks )

[Crazyace]

ST has parallel floppy disc, better than A8

 

And? This is also possible on Atari 8bit. when you make a list, you should not mention things that both systems can.

 

When you compare A8 and atari ST you must compare 'bare' systems. So Atari ST without floppy (520 ST).

 

And about harddrive. OK atari 8bit can hookup harddrive on Parallel Port and Cart Port, which is not DMA, but really fast. Fast enough I'd say.

 

I should have realised that making a list was a mistake.... but it was so tempting

 

Even the 520ST still has a parallel floppy interface - just no drive built in.

The ST HDD interface is better because it's faster, dma, and has no low cpu cost. ( Did any of the HDD interfaces actually exist back in the day - when I was using the A8 the happy chip and US doubler were the 'cool' addons, and the cartridge port was for Mac65 ) I've seen the SIO2SD stuff ( which is still slow, but cool ) and I use the SIO2USB now - but I haven't got much knowledge about internal/cart mods.

[atariksi]

You'll never see me making claims about a machine being inferior just by looking at a few games. In fact, I argued in reverse for the most part-- that it's better to look at capabilities of the hardware. I said Boulderdash and Joust are inferior on ST. But I'm not going to generalize from that that the machine is inferior. It's the reverse-- since I know ST takes a big hit for scrolling (via cycle calculations), I look for examples where that big hit takes place. It's more deductive logic than inductive.

 

Well, on a like for like case - If I scroll a 16 colour 80x192 line screen on the ST it will take less than a quarter of the cycles ( It will also only be quarter of the screen, but that's a limitation of the A8 )

I should compare 320x192 2 colour as that's the only resolution that matches between A8 and ST.

...

Sorry, but A8 graphics modes are full-screen. So whether A8 does 320*200 or 80*200 or 40*25, they are all full screen (and can be more w/overscan). And don't forget the mixing of modes like doing GTIA + Gr.8 on one scanline.

 

( Also GTIA on the A8 wasn't launch, maybe I should compare an ST model with blitter for timings )

...

STe was when people already went for Amiga/PCs. GTIA was when 8-bit was still peaking and natural upgrade (backward compatible). If ST had been compatible with A8, nobody would be debating this issue.

 

So for me:

 

ST has 640x200 4 colour mode - better than A8

ST has 320x200 16 colour mode - better than A8

...

Sorry, if you are going to list specific modes, A8 will win. A8 has a lot more graphics modes/text modes than ST. A8 can't do 640 modes but ST can't do most of the A8 modes of >16 colors. That's why you have to replicate pixels/lines to simulate those modes; otherwise I would have listed those modes as a separate advantage in my list. So Mr. Robot, Boulderdash, Joust, Pac-Man, etc. are 160*200 but the objects are well-defined at that resolution and full-screen.

 

ST has 512 colours, better than 128 for launch A8

...

Cut the "for launch" crap. ST not having RF modulator is worse than some 400/800 not having GTIA chips. 400/800 can pop in GTIA chip w/o soldering; you can't pop in a RF modulator in the ST. And I didn't put "lack of RF-modulator" in my list. Nor can you pop in a chip in the ST and give it more shades.

 

ST has faster processor - better than A8

A8 has scrolling, better than ST

A8 has 4 sound channels, better than ST

ST has parallel floppy disc, better than A8

ST has RGB video, better than A8

...

RGB video is not better than A8. A8 was targetted for TVs so it doesn't need the RGB. ST needs the RGB video (making it more expensive) in order to show it's advantage of higher resolution.

 

ST has DMA harddrive, better than A8

ST has 512k ram, better than A8

 

... and so on, can't be bothered making a longer list ....

 

Make the list longer because your list isn't long enough to show ST is superior to A8. A8 also had hard drives-- don't remember what interface they used. But both are expensive and not a normal common device. As far as other I/O goes, take the example of modern 64-bit systems. If all of your work is 32-bit and you switch to 64-bit system, you shouldn't expect loss of performance of your 32-bit stuff. 32-bit stuff has to be given importance (more-so than the new 64-bit stuff). So given A8s fast I/O using joystick I/O, that also has to be put into the comparison not just "oh, now we can use the parallel port."

[atariksi]

I'll take a look at the code once I get some time. It's theoretically impossible to copy 4 planes for a full screen given the 68K bandwidth limitations.

 

You can stop speculating that it can be done in less than 10% of the cycles.

 

No problem, I wrote it for my info more than anything else, and then posted it so at least there would be something to back up my claim.

I'll see if I can get the Battlesquadron first level to assemble ( I couldn't fully recover one of my data discs ), as that uses vertical smooth scrolling ( 16 colours ) with roughly 20 scanlines worth of time. - Not speculation, but actual figures for a game.

...

ST has video starting address at 256-byte alignment so unless you are doing some weird tricks, even vertical scrolling would be troublesome. Compare with EGA which has video starting address on BYTE alignment.

 

To me, Sync scrolling is just as valid as the prior 0 hacks on the 8 bits, something that relies on an undocumented reliable mechanism in the hardware to give a boost to the machine capabilities.

 

Sorry, but PRIOR 0 is GTIA doing its normal operations and not a big discovery-- just type something like:

 

POKE 706,122:POKE 53263,255:POKE 53250,128

 

It has nothing to do with playing with video frequencies which has proven in history to cause problems/damage (i.e., CGA).