Atari 8bit is superior to the ST

[atariksi]

Yes, it's only 2 planes - that works for me as Boulderdash is only 4 colours. The other twelve colours are available for software sprites.

...

 

Boulderdash uses ANTIC mode 4 and has 5 colors. I can see the five different colors for the playfield.

I captured the screen for the playfield, and there were only 4 colours - I know that there are 5 colours supported in that mode though - it just wasn't relevant to reproduce the game at 60fps on the ST.

...

It is relevant.

 

 

( Correct me if I'm wrong, but for on the A8 there are probably 192*48+24*48 cycles for the scroll, plus 192*3 for dlist, plus 262*4 for refresh. So thats other 11000 cycles taken for the display - leaving around 18000 cycles for the 6502 ... even assuming that the 6502 is more efficient than the 68000, the ST has nearly 15000 cycles extra to play with per frame. )

...

 

Okay, I'll correct you since you're wrong. ANTIC mode 4 is 24 lines not 192. Also, adding scrolling to a display shouldn't include the time for display dma or refresh. That would be a separate comparison.

 

and I'll correct you back as you are wrong - Antic mode 4 in this case is 192 lines, 24 of which fetch map data as well as char data - hence 192x48 + 24*48.

Refresh takes cycles away from the A8, and not from the ST, so that's why I included it.

The dlist fetch may be less than 192*3 - I never checked if the entries are fetched redundantly every line, so feel free to add 500 cycles to the a8 count.

No, the display as it exists has refresh cycles and DMA cycles. When you add scrolling, you add 2 DMA cycles for the LMS vs. normal display mode instruction. You got all your calculations screwed for scrolling. Yeah, it's only one LMS per mode line so it would be 24 for 24 mode 4 lines.

[Crazyace]

It's not relevant to me, as my example was not 'scrolling mode 4 on ST' but 'Boulderdash on ST'

 

...

 

Give me the exact timing calculations then - I'm not in A8 mode at the moment ( I remembered that when scrolling is enabled PF width goes up from 40 to 48 bytes )

[PeteD]

DMA Timings

 

 

Careful you don't go using that much vaunted overscan

 

 

Pete

[atariksi]

It's not relevant to me, as my example was not 'scrolling mode 4 on ST' but 'Boulderdash on ST'

 

...

 

I'm not hanging you for it as atleast you give me rational arguments. But the 5th color is used -- for example, when the diamond is cycling colors-- it's using a different color than the other 4 in the playfield.

 

Give me the exact timing calculations then - I'm not in A8 mode at the moment ( I remembered that when scrolling is enabled PF width goes up from 40 to 48 bytes )

 

Only in overscan, you fetch 48 bytes. This one doesn't use overscan, so the fetches are 0-2 bytes extra per scanline (automatically done by ANTIC) depending on HSCRL value. DList would add 2 DMA cycles for LMS vs. normal mode so it would be 24*2 = 48 extra cycles. I suppose you can add worst case of 2 extra memory fetches per scanline for the scroll for 192*2 = 384 cycles so total of 432 maximum DMA cycles added to add scrolling.

[PeteD]

Are the diamonds a different colour? or animated chars using the already available 4 colours?? If they were another colour to allow colour changes per scanline that would mean an awful lot of cpu wasted (versus copying in new char defs, what, 32 bytes?) plus there are things like the colour cycling squares which would be impossible to do that way so why use 2 methods?

 

 

 

Pete

[Crazyace]

Are you sure? - I've just been frame stepping boulderdash on the emulator, and the diamond seems to only be 4 colours in the animation.

As far as cycle counting though - you need to calculate all of the dma cycles taken for the display to compare against the ST ( as ST video/refresh dma doesn't slow down the 68k )

[PeteD]

Are you sure? - I've just been frame stepping boulderdash on the emulator, and the diamond seems to only be 4 colours in the animation.

As far as cycle counting though - you need to calculate all of the dma cycles taken for the display to compare against the ST ( as ST video/refresh dma doesn't slow down the 68k )

 

I think my post above is how it's done. You can't have the 5 colours in the same area so you'd have to either do scanline changes of a PF colour which has been reserved for such and we all know that doesn't exist in char mode, so wsyncs to keep the colours stable OR it's just 4 colour mode copying char definitions, then you can do the animating squares and other stuff too with the same method.

 

 

Pete

[Crazyace]

I suppose I could check in the Atari800win debugger - but I always assumed the animations were simply 4 ( or however many ) different character sets - as only 1 write would be needed to change all of the animations.

[peteym5]

BoulderDash does use Antic 4 mode with 5 colors. You see the 5th color with the Amoeba (green slime) or the permeable walls (blue slime) that have the high bit set on to show those characters. BTW, Antic 4 is 24 characters high, but since each character is 8pixel tall, it results in having 192 pixels. It only has to do the DMA fetch for 24 lines, not all 192 lines. Takes less cycles than Antic Mode E.

[PeteD]

I suppose I could check in the Atari800win debugger - but I always assumed the animations were simply 4 ( or however many ) different character sets - as only 1 write would be needed to change all of the animations.

 

Could well be depending on the state of CPU vs RAM. If CPU wasn't a problem though (can't see it being) I'd go for copying new definitions into the existing charset.

 

 

Pete

[atariksi]

BoulderDash does use Antic 4 mode with 5 colors. You see the 5th color with the Amoeba (green slime) or the permeable walls (blue slime) that have the high bit set on to show those characters. BTW, Antic 4 is 24 characters high, but since each character is 8pixel tall, it results in having 192 pixels. It only has to do the DMA fetch for 24 lines, not all 192 lines. Takes less cycles than Antic Mode E.

 

Yeah, the LMS fetch is for 24 lines and antic E doesn't have the 5th color option. Okay, diamonds appears to use a difference color but I guess you are right-- it's used for special chars. I can't pause the color rotation on a real machine. If I press space-bar, the color keep rotating although the game pauses.

[atariksi]

Are you sure? - I've just been frame stepping boulderdash on the emulator, and the diamond seems to only be 4 colours in the animation.

As far as cycle counting though - you need to calculate all of the dma cycles taken for the display to compare against the ST ( as ST video/refresh dma doesn't slow down the 68k )

 

Petemy5 seems to be right regarding the 5th color useage. So they don't need the DLIs to rotate the colors through the diamonds (although that would make for more beautiful diamonds).

 

You can do a compare of static graphics/text modes by themselves with ST in static display mode. But when you add scrolling, you have to look at the ADDITIONAL cycles involved to enable scrolling. I mean if I use overscan, you can't add display/refresh timing again to enable overscan. You would only look at the ADDITIONAL cycles used to enable overscan.

[Crazyace]

The valid comparison is to compare like for like, not the delta - ie. static screen vs static screen is 0 cycles on ST vs xxx cycles on A8 , and scrolling screen is nnn cycles on ST vs yyy cycles on A8. Also comparing the 'free' cycles is valid, as it shows what the 'rest' of the system is capable of after the scrolling.

 

Never the less hardware scrolling is a huge win for the A8 , and as I said before it should have been part of the ST. However it doesn't automatically make the A8 superior to the ST , as pure software gruntwork can make up for the lack of elegant hardware.

 

I'll go back and play a little with the code to make it 8 colours - as you are write^H^H^H^H^H right about 5 being used on the A8 though.

 

( and have a merry xmas )

Edited December 24, 2009 by Crazyace

[Lazarus]

Petemy5 seems to be right regarding the 5th color useage. So they don't need the DLIs to rotate the colors through the diamonds (although that would make for more beautiful diamonds).

That however still ignores that the ST is scrolling twice the resolution and as somebody else has shown here already: Higher resolution can easily compensate less colors, especially in this case where it's only 1 color less which isn't even used in most levels.

Edited December 25, 2009 by Lazarus

[Rybags]

Antic 4, and even 5, has more DMA than Mode E (character codes + bitmap vs bitmap only + ~165 or so more DList)

 

And if you're nitpicking about exact cycle counts on each machine, you can't just go an say "ST static screen = 0 cycles" because it isn't that way.

 

Additionally (and somewhat sadly), the number of proper smooth h-scrolling games on the ST is pitifully small - so such comparisons don't amount to much.

 

It's kinda like someone remembering a drag race they had 10 years ago that they lost but could have won because they forgot the car had a nitrous button.

Edited December 25, 2009 by Rybags

[Crazyace]

To be honest I wasn't that fussed about exact cycle counts ( apart from when I scribble possible loops ), but the 0 cycle cost on ST is effectively true due to the interleaved 68000/DMA cycles ( baring the odd 2 cycle offset opcodes, which is why I mentioned rounding to 4 earlier ) compared to the A8 where Antic and 6502 fight for the 1.79MHz memory.

I'm interested in what timings I might have missed though.

 

I guess the problem with ST games in general, was that they were pretty much always ST/Amiga games - so the graphics were shared, and the ST version sucked compared to the Amiga version. It wasn't really being compared to the A8 at the time though.

( I had loads of bits of scrolling routines lying around, but basically a decision to run at 25Hz was made, and everything was designed to look good around that )

 

Doing code today isn't like 'remembering about a nitrous button' - it's more like thinking 'I could drive better, given the experience I have now'

 

( Given that the required 30 minutes 'shredding of the christmas present wrapping' has occured, I've got some time in front of the PC - so I can waste it playing around with code just because it's fun )

[TwiliteZoner]

The ST is the ultimate example of it's poor musician who blames his instrument. The programmers that knew how to exploit the hardware produced some pretty damn good games.

[atarian63]

Humbug

 

 

Pete

Figures..

[atarian63]

To be honest I wasn't that fussed about exact cycle counts ( apart from when I scribble possible loops ), but the 0 cycle cost on ST is effectively true due to the interleaved 68000/DMA cycles ( baring the odd 2 cycle offset opcodes, which is why I mentioned rounding to 4 earlier ) compared to the A8 where Antic and 6502 fight for the 1.79MHz memory.

I'm interested in what timings I might have missed though.

 

I guess the problem with ST games in general, was that they were pretty much always ST/Amiga games - so the graphics were shared, and the ST version sucked compared to the Amiga version. It wasn't really being compared to the A8 at the time though.

( I had loads of bits of scrolling routines lying around, but basically a decision to run at 25Hz was made, and everything was designed to look good around that )

 

Doing code today isn't like 'remembering about a nitrous button' - it's more like thinking 'I could drive better, given the experience I have now'

 

( Given that the required 30 minutes 'shredding of the christmas present wrapping' has occured, I've got some time in front of the PC - so I can waste it playing around with code just because it's fun )

Actaully the 1st 2-3 years most games were ST and ported to Amiga so other than sound the ST versions were better

[Crazyace]

Different comparison topic though ( I don't want to be dragged into that.. )

[+poobah]

The 68010 sped up small instruction loops, but didn't help if the loops were bigger, or unrolled already for speed.

 

Regarding the blitter/STe - they weren't part of the original machine spec. ( A blitter, or scrolling at the ST launch would have been much superb though )

 

Well then you'd need to compare to the original A8 spec

 

(That's CTIA, 8 or 16K of RAM)

 

/stirs pot

[atariksi]

Petemy5 seems to be right regarding the 5th color useage. So they don't need the DLIs to rotate the colors through the diamonds (although that would make for more beautiful diamonds).

That however still ignores that the ST is scrolling twice the resolution and as somebody else has shown here already: Higher resolution can easily compensate less colors, especially in this case where it's only 1 color less which isn't even used in most levels.

 

Bullcrap. You have NO IDEA what you are talking about. You can easily distinguish between 4 and 5 colors. And in general, a 640*480*16 VGA image looks worse than 320*480*256 (image not text).

[PeteD]

Petemy5 seems to be right regarding the 5th color useage. So they don't need the DLIs to rotate the colors through the diamonds (although that would make for more beautiful diamonds).

That however still ignores that the ST is scrolling twice the resolution and as somebody else has shown here already: Higher resolution can easily compensate less colors, especially in this case where it's only 1 color less which isn't even used in most levels.

 

Bullcrap. You have NO IDEA what you are talking about. You can easily distinguish between 4 and 5 colors. And in general, a 640*480*16 VGA image looks worse than 320*480*256 (image not text).

 

I'd imagine he's referring to the A8 double shades Vs ST double horizontal res. Instead of keeping things in the realms of reasonable discussion though you have to exaggerate it into a more ridiculous comparison. I wonder why...

 

 

Pete

[atariksi]

The ST is the ultimate example of it's poor musician who blames his instrument. The programmers that knew how to exploit the hardware produced some pretty damn good games.

 

Substitute "ST" with "Apple II".

I.e., there's very little hardware to use. Unless by "exploit" you mean S.Y.N.C.

[atariksi]

The valid comparison is to compare like for like, not the delta - ie. static screen vs static screen is 0 cycles on ST vs xxx cycles on A8 , and scrolling screen is nnn cycles on ST vs yyy cycles on A8. Also comparing the 'free' cycles is valid, as it shows what the 'rest' of the system is capable of after the scrolling.

 

Never the less hardware scrolling is a huge win for the A8 , and as I said before it should have been part of the ST. However it doesn't automatically make the A8 superior to the ST , as pure software gruntwork can make up for the lack of elegant hardware.

...

 

I never said just the scrolling would prove the A8 superior. Software making up for lack of hardware is only true for minimal overhead things like collision detection given the marginally superior processor. Now, if you had a local bus graphics or 1Ghz processor, that would make things interesting.

 

Whatever cycles are remaining with the graphics mode/text mode you choose is what is normal on Atari. What you add to that afterwards is the cycle overhead for that additional feature.