Atari 8bit is superior to the ST

[atariksi]

 

You are miscalculating something-- many A8 games can get away with just hardware sprites multiplexed so A8 wins. There's no need for A8 to do ST type software sprites and purposely slow things down. The point is ST cannot do those games where A8 uses the hardware sprites without expending more time (making it inferior). And the 312 sprites is per frame so it means you can't do anything else requiring CPU.

 

When you multiplex h/w sprites there's an added cost on the 8 bit for the interrupt routines, and the code to change the player positions. That helps to offset the extra cost of the ST software sprites. Plus there's a software cost for the sprite multiplexor needed when more than 2 4 colour sprites are expected on a single line which isn't a problem with straightforward software sprites.

 

The problem with the ST isn't sprites - it's the background scrolling ( and maybe the lack of character modes )

 

But your choosing an example of 16*16 sprites which A8 doesn't employ in most of sprite-based games. Interrupt overhead to reposition isn't that much. May need some recalculations here. Char-mode software sprites was another issue.

[atariksi]

It's not one of the points I in the list even if it's wrong. And in reality, I don't know yet-- perhaps it is doing hardware collision detection. I know better not to take your word.

 

So the new rules are that we're not to tackle you on inaccuracies and half truths in your posts, but only in your evolving lists you enjoy posting so much.. Fine..

 

List hasn't evolved. It's still 5 items. I have mentioned other things but not added them to the list. Did you play the "dragon" level in Joust w/o collision detection?

 

 

This list ? No, not yet.. But since I can only judge you based on your previous list performance I'm not holding my breath that it'll stay that way..

 

Anyway, as for our old friend Mr.Collisions... Nope, no "dragon" level for me.. Just fired the game up, started a game, switched off collision registers, continued to play, and everything functioned quite as normal, which was surprising to say the least since that was the last thing I expected to see..

 

 

Let me guess.. They use the hardware collisions on the "dragon" level ?

 

I did base the list on what I know about both platforms so I guess it can grow once I find out more limitations of ST. I just saw that Joust uses Overscan a bigger ST killer than collision detection (and this one is on my list).

 

I don't have emulator so any internal specific game information is based on what I read and what it looks like given the exactness.

[GroovyBee]

But your choosing an example of 16*16 sprites which A8 doesn't employ in most of sprite-based games. Interrupt overhead to reposition isn't that much. May need some recalculations here. Char-mode software sprites was another issue.

If its 8 bit wide the 7800 is really gonna whup the ST and A8's ass .

[Crazyace]

ah, but the 7800 only supports 128 colours, so fails on the 16 shade test

[Crazyace]

 

You are miscalculating something-- many A8 games can get away with just hardware sprites multiplexed so A8 wins. There's no need for A8 to do ST type software sprites and purposely slow things down. The point is ST cannot do those games where A8 uses the hardware sprites without expending more time (making it inferior). And the 312 sprites is per frame so it means you can't do anything else requiring CPU.

 

When you multiplex h/w sprites there's an added cost on the 8 bit for the interrupt routines, and the code to change the player positions. That helps to offset the extra cost of the ST software sprites. Plus there's a software cost for the sprite multiplexor needed when more than 2 4 colour sprites are expected on a single line which isn't a problem with straightforward software sprites.

 

The problem with the ST isn't sprites - it's the background scrolling ( and maybe the lack of character modes )

 

But your choosing an example of 16*16 sprites which A8 doesn't employ in most of sprite-based games. Interrupt overhead to reposition isn't that much. May need some recalculations here. Char-mode software sprites was another issue.

 

Maybe the best comparision is to look at Goldrunner, which was a cool near launch title from Steve Bak .... 50fps vertical scroller with sprites. That compares pretty well with any A8 game.

( Another example: I cant actually remember making any money from the ST version of screaming wings ... It wasn't that good a game, but it did look way better than the A8 version )

[GroovyBee]

ah, but the 7800 only supports 128 colours, so fails on the 16 shade test

 

Nope! Its palette is 256 colours and it has 16 shades of grey.

 

EDIT: You can find the NTSC palette (taken from the ProSystem emulator) here :-

 

http://www.atariage.com/forums/topic/143720-7800-ntsc-colour-bitmap/

Edited December 14, 2009 by GroovyBee

[andym00]

I did base the list on what I know about both platforms so I guess it can grow once I find out more limitations of ST. I just saw that Joust uses Overscan a bigger ST killer than collision detection (and this one is on my list).

 

Oh, the overscan trick again eh ? I'll play, just this once okay...

 

Right.. Ummmm... Okay....

 

It's just a shame that the A8 version doesn't bother to clip it's sprites at the screen edges, on the (very!) few sprites it has.. Oh, sorry that'd take extra cycles to do wouldn't it (an extra and zp or so), since you're burnt all the missiles on the jousts themselves.. Silly me..

 

So slightly bigger screen, versus disappearing sprites because you've burnt all the sprite resources just getting 4 tiny bird on screen, oh, split several times down the screen, musn't forget that, but lets call it a multiplexer because that sounds better..

 

There.. Done..

 

Your go...

 

I don't have emulator so any internal specific game information is based on what I read and what it looks like given the exactness.

 

Assumption earns you nothing more than a custard flan in the face in this world I'm afraid..

Edited December 14, 2009 by andym00

[Crazyace]

ah, but the 7800 only supports 128 colours, so fails on the 16 shade test

 

Nope! Its palette is 256 colours and it has 16 shades of grey.

 

EDIT: You can find the NTSC palette (taken from the ProSystem emulator) here :-

 

http://www.atariage.com/forums/topic/143720-7800-ntsc-colour-bitmap/

 

Of course you're correct ... show's how long it's been since I last looked at the 7800 docs..

My apologies

 

( You should now start a 7800 vs ST thread )

[GroovyBee]

( You should now start a 7800 vs ST thread )

 

Nah! I'm just here to champion the 7800.

[atariksi]

ah, but the 7800 only supports 128 colours, so fails on the 16 shade test

 

Nope! Its palette is 256 colours and it has 16 shades of grey.

 

EDIT: You can find the NTSC palette (taken from the ProSystem emulator) here :-

 

http://www.atariage.com/forums/topic/143720-7800-ntsc-colour-bitmap/

 

Of course you're correct ... show's how long it's been since I last looked at the 7800 docs..

My apologies

 

( You should now start a 7800 vs ST thread )

 

I think it fails on the keyboard test, disk drive test, etc. It's not a computer. It would also fail the translucency test even with the 16 shades since there's no GTIA doing the ORing. Anyway, I haven't done in smooth scrolling or overscanning to know how it does it.

[atariksi]

I did base the list on what I know about both platforms so I guess it can grow once I find out more limitations of ST. I just saw that Joust uses Overscan a bigger ST killer than collision detection (and this one is on my list).

 

Oh, the overscan trick again eh ? I'll play, just this once okay...

 

Right.. Ummmm... Okay....

 

It's just a shame that the A8 version doesn't bother to clip it's sprites at the screen edges, on the (very!) few sprites it has.. Oh, sorry that'd take extra cycles to do wouldn't it (an extra and zp or so), since you're burnt all the missiles on the jousts themselves.. Silly me..

 

So slightly bigger screen, versus disappearing sprites because you've burnt all the sprite resources just getting 4 tiny bird on screen, oh, split several times down the screen, musn't forget that, but lets call it a multiplexer because that sounds better..

 

There.. Done..

 

Your go...

...

Come on, I have played Joust on ST and A8, A8 version is superior. It does give appearance of 8 birds + "dragon" + the moving lava hand and only once in a 16-shaded blue moon, the sprites are aligned like the planets and cause inauspicious flicker which is more prevalent on ST games; didn't see disappearing sprites though on either machine.

 

I don't have emulator so any internal specific game information is based on what I read and what it looks like given the exactness.

 

Assumption earns you nothing more than a custard flan in the face in this world I'm afraid..

If it was in the list of (5), I would be worried. Mr. Robot does hardware collision detection and hardware sprite multiplexing; this also based on what I have read.

[GroovyBee]

I think it fails on the keyboard test, disk drive test, etc. It's not a computer.

 

It was planned back in the day :-

 

http://www.atarimuseum.com/videogames/consoles/7800/7800keyboard.html

 

Curt Vendel is working on something like this for the 7800. I don't know when its going to be released tho.

 

It would also fail the translucency test even with the 16 shades since there's no GTIA doing the ORing. Anyway, I haven't done in smooth scrolling or overscanning to know how it does it.

 

It can do one pixel scrolling in all directions and it clips sprites in hardware in X too.

[+wood_jl]

Agree with what? He hasn't even addressed the 5 points I made and he's pretending that he did. Which argument are you contending?

 

I'm waiting for you (or anyone) to post a list of 8bit versions of

games or apps, found on the ST, that show the technical superiority

of the 8bit over the ST.

 

Still. Waiting....

 

 

Shirley, you can't be serious.

[You are serious, and don't call you "Shirley."

 

Is that the arguement? That in absolute terms, the 8-bit must be technically superior to the ST? How can it be? It's an 8-bit! It is, howevever, capable of being "more technically superior for its time" or something like that. Heck, one can prefer the 8-bit for whatever reason. However, why do we need proof that a 1985 68000-class machine is superior to a 1979 6502-class machine? Did I miss something here?

[+wood_jl]

Agree with what? He hasn't even addressed the 5 points I made and he's pretending that he did. Which argument are you contending?

 

I'm waiting for you (or anyone) to post a list of 8bit versions of

games or apps, found on the ST, that show the technical superiority

of the 8bit over the ST.

 

Still. Waiting....

 

Fujiboink on the XE is absolutely better than on the ST. I remember being shocked that an 8-bit could do anything better than a 16-bit computer.

I agree! And the sound effects on the ST version are not as good (the crashing/rumbling sound).

[+remowilliams]

Did I miss something here?

No you didn't. A grossly unqualified comparison such as 'superior' is meaningless and pointless here.

[atariksi]

I think it fails on the keyboard test, disk drive test, etc. It's not a computer.

 

It was planned back in the day :-

 

http://www.atarimuseum.com/videogames/consoles/7800/7800keyboard.html

 

Curt Vendel is working on something like this for the 7800. I don't know when its going to be released tho.

 

It would also fail the translucency test even with the 16 shades since there's no GTIA doing the ORing. Anyway, I haven't done in smooth scrolling or overscanning to know how it does it.

 

The keyboard looks cool and it uses the joystick port. I guess they modify the OS ROM to check joystick port. However, the SIO on the keyboard may cause slow downs.

 

It can do one pixel scrolling in all directions and it clips sprites in hardware in X too.

 

With overscan, you don't need to clip sprites or are you talking about some other form of clipping?

[+wood_jl]

( You should now start a 7800 vs ST thread )

 

Nah! I'm just here to champion the 7800.

 

I hope you don't champion the sound, then. I didn't play a 7800 until years later after they were out; I simply didn't know anybody who had one. To me, the graphics looked "pretty much" like the A8, but UGGGH what terrible sound. I was shocked. Pretty big turn-off. After being an A8 user for years and taking shit from Commodore users about how "bad" A8 sound was compared to the C64, I wondered how something like the 7800 could even be released. I'd gladly trade the sprites back for a POKEY sound.

[GroovyBee]

With overscan, you don't need to clip sprites or are you talking about some other form of clipping?

The sprite X position (including base address, palette index and width) is controlled with a Display List entry (not the same as the A8s). If the X coordinate is >=160 the sprite is not drawn. If the X coordinate is less than 0 only the sprite data that is visible on screen is drawn.

 

The 7800 doesn't have overscan but you can change to one of the 320 pixel wide modes on the fly.

 

EDIT: For technical accuracy.

Edited December 14, 2009 by GroovyBee

[GroovyBee]

I hope you don't champion the sound, then. I didn't play a 7800 until years later after they were out; I simply didn't know anybody who had one. To me, the graphics looked "pretty much" like the A8, but UGGGH what terrible sound. I was shocked. Pretty big turn-off. After being an A8 user for years and taking shit from Commodore users about how "bad" A8 sound was compared to the C64, I wondered how something like the 7800 could even be released. I'd gladly trade the sprites back for a POKEY sound.

 

The stock 7800 sound comes from TIA (the video chip in the 2600). I agree a POKEY would have been much better. Both Commando and Ballblazer had POKEY in the cart.

 

I guess 2600 backwards compatibility came at a price .

[+remowilliams]

I guess 2600 backwards compatibility came at a price .

I was wowed at the 7800's graphics and then immediately horrified by the sound the first time I saw one.

[+DarkLord]

 

<snipped>

 

overscan abilities (although I think the ST's max horizontal resolution is still higher anyway, not positive)

 

-ST (standard, not MEGA/STe)

total colors available

colors of display mode most often used -especially for games (16 vs 4)

character/software sprites

horizontal resolution (and vertical res for monochrome)

more raw CPU power

additional I/O ports -debatable (parallel ports+joystick+serial+midi vs joystick+PBI/ECI+SIO)

 

<snipped>

 

 

I'm a bit confused by some of these comparisons, I have to admit.

 

There are any number of ST games and demos that have far more than 16 colors and overscan

too, whether its hardware, sofware or just pure CPU "grunt" it exists. Static screens like

Photochrome and Spectrum 512 broke (by far) what standard ST's were listed as being able

to do...

 

I've never, ever, ever seen an 8bit picture that could come close to a good Spectrum 512

picture or even more so, a Photochrome picture...

[atariksi]

I hope you don't champion the sound, then. I didn't play a 7800 until years later after they were out; I simply didn't know anybody who had one. To me, the graphics looked "pretty much" like the A8, but UGGGH what terrible sound. I was shocked. Pretty big turn-off. After being an A8 user for years and taking shit from Commodore users about how "bad" A8 sound was compared to the C64, I wondered how something like the 7800 could even be released. I'd gladly trade the sprites back for a POKEY sound.

 

The stock 7800 sound comes from TIA (the video chip in the 2600). I agree a POKEY would have been much better. Both Commando and Ballblazer had POKEY in the cart.

 

I guess 2600 backwards compatibility came at a price .

 

I guess they made the cartridges more expensive by putting POKEYs in the cartridges rather than the motherboard. It would have been better if ST had made their system A8 compatible.

[+DarkLord]

I have another question... Why aren't we comparing in this order:

 

Atari 400 -> Atari 520ST

 

Atari 800 -> Atari 1040ST

 

XL and XE series - STE and Mega STe

 

I mean, if we're going to do this right, its unfair to compare

the later 8bit models to the earliest ST models - if we're trying

to gauge technical superiority and impact, at the times they

were introduced...

 

Thanks.

[atariksi]

I have another question... Why aren't we comparing in this order:

 

Atari 400 -> Atari 520ST

 

Atari 800 -> Atari 1040ST

 

XL and XE series - STE and Mega STe

 

I mean, if we're going to do this right, its unfair to compare

the later 8bit models to the earliest ST models - if we're trying

to gauge technical superiority and impact, at the times they

were introduced...

 

Thanks.

 

I have been comparing A800 with atari ST. They didn't enhance the 8-bit chip set really in later models and neither was STe models that common and came way after other platforms took over technically and marketwise.

[+DarkLord]

I have been comparing A800 with atari ST. They didn't enhance the 8-bit chip set really in later models and neither was STe models that common and came way after other platforms took over technically and marketwise.

 

Okay, so why not the first 8bit model (400) vs the first ST model (520ST)?