Atari 8bit is superior to the ST

[FastRobPlus]

 

<snipped>

 

The problem (for me) with the ST (and presumably, the Amiga) is I am not aware of ways that are as EASY and AVAILABLE to do the same thing. The HxC floppy drive emulator http://www.torlus.com/floppy/ seems to be a step in the right direction, but does anybody know where to get one? It doesn't look nearly as elegant of a solution as SIO2PC or Sdrive for A8, or 1541 Ultimate for C64. These devices are nearly flawless and foolproof.....for the non-technically-inclined user.

 

 

There've been a few advancements on this front. Most of the more popular Amiga and Atari titles

have been updated so they will work off of mass storage devices. For the Atari ST owner, there

is the Ultrasatan. I've got 2, they rock!

 

http://joo.kie.sk/ultrasatan/

 

That's a cool device.

[Crazyace]

Changing the subject ( or maybe dragging back to the subject ) - I thought I'd knock this up as the comparision of boulderdash was being made by Atariksi.

If you run the boulder.prg on a ST it should scroll a character screen at 50/60Hz.

The character paint routine for the whole screen takes around 100k cycles ( from 133k cycles 60Hz ) - leaving 33k cycles for game code , which compares well with 29k cycles total on A8 ( before any DMA )

It's just a brute force cpu algorithm, so no sync scrolling tricks, just something to show that the stock ST could easily match an A8 game in terms of scrolling

boulder.zip

[oky2000]

Hmmm it's interesting I should be called a fanboy for saying the A8's only general superiority to the C64 in graphical terms for the sake of fast arcade games as were all the rage in 1980s was a 128 colour palette to 16....if you have to waste half your PM graphics AND half your CPU time just to get 8 or so colours on screen in 160x200 where is the killer advantage? No sorry the really thorn in the side of the ST as far as sales went was VIC-II sprites and scrolling and SID sound on the C64...all of which were not present in an ST to the same levels of sophistication....which put a lot of people off.

 

As for the Amiga and A8 being cousins...yeah only the copper/DLI and hardware sprites/PM graphics. Amiga sound was unique as was the blitter, and it is those two things coupled with a nice 68k implementation within the architecture that made the Amiga a great machine for the time. The copper was really just there to supplement colours because true 64 colour mode was slow...and hardware sprites were crap on the Amiga before AGA...waste of time bothering with them if you have a perfectly implemented blitter handy...and three people designed the Amiga...not one! And I bet Jay contributed the rubbish hardware sprites that are too few and too thin to be useful.

 

I am sticking to this comment simply because no matter how many lists Atariski produces the simple fact is the C64 does a much better job of creating standard 2D arcade games thanks to an immensely flexible 160x200x16 colours almost anywhere AND massive amounts of multiplexed sprites on top of hardware pixel scroll....Rescue on Fractalus is better on A8 (never denied that) but Eidolon is pretty much identical on both and it's not because the routines are suddenly running 35% slower on the A8

 

However even I am not stupid enough to say I'd rather play C64 Gauntlet (let alone A8 craplet in mono-vision lol) over a stunning Atari ST version of Gauntlet 1 just because the A8 has hardware scrolling (and no samples and very crap super blocky unrecognisable graphics and sound.

 

Better OS, better application/creative/business software, good games on both...but the best ST games will always be better than the best A8 games sorry, The Pawn, Lotus II, Enchanted Land, Flight Simulator II and Gauntlet 1 are examples of just about every genre there and the A8 can not do anything approaching that kind of graphical sophistication or speed.

[Crazyace]

This is the code, it's just really a scribble though

code.zip

[oky2000]

 

1. CPU Freq 1.78979Mhz

2. Rock solid timing and more accurate (No indeterminate signals to throw off cycle-exactness)

3. Easy overscanning

4. LMS -- easy to access more video memory, mirror images, repeat scanlines, etc.

5. VScroll/HScroll on per scanline basis (8-dir scrolling windows)

6. More priorities and playfields (and GPRIOR mode 0 mostly unexplored)

7. Linear and easy to use high color depth modes (GTIA)

8. Fast keyboard reading

9. Faster joystick I/O and SIO I/O (16-bit reads/writes)

10. Display lists w/various modes (use by themselves or for speeding up screen updates)

11. WSYNC for easier to start writing cycle-exact code

12. DLIs (more optimal than raster IRQs)

13. BOOT Up to cassette files or disk files (without user intervention)

14. A lot more collision detection combinations (60-bits)

15. 4 DACs w/more accurate sampling rate (lower latency)

16. Better interlace (due to more shades to reduce flicker)

17. More colors/shades (bigger palette)

18. Horizontal re-use of hardware registers (much easier like same 114 cyles on PAL/NTSC)

19. Backward compatible with all A8 computers

 

 

 

 

In isolation, most of these items are true. In combination with other traits not necessarily. For instance the A8 has a 320x200x2 mode but the fine shaded/16/9 color modes are all 80x192x16. By expending some CPU on DLIs or mixing modelines or burning up some PM graphics which are themselves a limited resource, that limitation can be overcome partially but not with complete freedom. It won't do 320x200x16 unrestricted and the ST will. While the C64 is not as unrestricted as the ST in 320x200 it is freer in this mode than the A8. Such compromises abound once something, usually a game, has to be implemented vs. other platforms. I don't see 23 colors per line in the Last Ninja thread for instance. Of course that is true regardless of platform but let's not kid ourselves that the A8 will always win.

 

And since the subject IS comparison with the ST, the A8 isn't going to win most bandwidth competitions. The CPU difference alone will crush the A8 in most contexts and the 68000 is also going to win in bus width, bandwidth, and registers. So yeah, you can contrive situations that make the A8 come on top of most any machine but the truth of the matter is a 16-bit 68000 based machine is going to stomp it in most situations. It is only going to hold it's own against C-64 and many other 8-bit micros and is only unquestionably superior in all respects if the object of comparison is something like an Aquarius. As I've said before, I think the A8 a far more innovative and far better engineered machine for it's day and since an 800XL was my first a special place in my heart as well. But most people after using both aren't going to agree with you that the A8 is superior to an almost modern machine like an ST. And yes, I'll even allow that for say hobby electronics projects the A8 may have some points but still....

 

Amen.

 

It's the way the list tells 1/2 truths and if you don't know that you'd just think WOW but when you have the knowledge to analyse it you start to see things like I listed earlier. Stuff like better interlace due to more colours, which is all fine except for the failure to mention that the A8 would usually either be in 16 colour/shade mode and then be 80xY anyway which means interlace is fairly useless compared to other machines resolutions, or would be in a 4/5 colour mode and that the C64 can do 16 colours in hires already via colour ram. Things like 114 cycles, hmm yeah minus DMA and if you're doing the much loved overscan and dare to try to scroll you'll find you've got scant few of those left on "badlines" a lot less in fact than the C64. More colours/shades yes, but only 16/lowwww res or 4/5 normal res. Accurate timing with nothing to interrupt it, hmm apart from the CPU of course, which then gets countered with WSYNC, which wastes loads of CPU. It goes on and on..

 

 

It's really no use to take these factoids in isolation and extrapolate the machines superiority against any machine from them. Many counter claims to the magical ST inferiority list of 5 have been made with PROOF and they get ignored or some lame effort to invalidate them such as when I posted 3 images in greyscale to show 8 shades 320x200 is much better than 16 shades 80x200, then the response was that "converting" from the 80x200x16 wouldn't look as good on ST because it would lose 8 shades and you'd have to do that if the higher res image wasn't available. Clutching at straws. I've written a remapper for my tools app recently and tested it with some ST images and the A8 doesn't have the palette OR the shades to handle it (and it's not my app, I've checked it against various remapping graphics apps). Of course to any normal person, you'd just say, "fair enough, I'll redraw/recolour the picture to make better use of A8 colours", but to certain people if a colour doesn't exist in a machines palette it means it's inferior...

 

 

I keep saying it and I will continue to do so, I like the A8 else I wouldn't waste my time but even with my ~6 months experience with it (and yes you CAN learn everything about a machine in that time, it's been my career to do so in a lot less time) I can safely say it's a giant bitch to do anything on when you set yourself a target of even something fairly simple in comparison to other machines. Even something like Stuntcar Racer which has been mentioned recently "should" be better on A8 due to the faster CPU. Then you start to look at it and go, hmm, how do we get all those colours on screen? and how about that engine block in the middle of the 3D stuff? and those tyres that bounce up/down with the road, etc. There are ways round things like that but they all drain resources.

 

Anyway, it's xmas, I've got family stuff to do as well as coding (for A8 projects, how stupid of me), unless baiter boy starts up again I've had my say..

 

 

Pete

 

 

Haha I just read the locked C64 vs thread.....where's Rocky mountains with his moronic laughing like a simpleton when you need him? And his sidekick...TMR. Then you guys have the complete collection again, C64 users know STs best, what a surprise.

 

LoL Rocky was funny, but to be fair he went out and found identical pictures of A8 and C64 games and posted them, everyone was free to find A8 favourable games too, some even did rather than bothering to stoke the flaming fires of the thread in protest

[kool kitty89]

While ST did have better sound and palette, you have to remember that EGA (and VGA) had hardware scroll capability and various text modes as well. ST could do a better job of games at 320*200 but applications at higher resolutions would probably win out on PC end. So getting back on topic, if a person had an A8 and wanted to upgrade the PC choice of getting the higher resolutions/faster processor speed/more memory/etc. was there. If they went for ST, it was mainly due to price.

Character mode scrolling looks pretty poor sometimes (scrolling one character block per frame, granted the ST did dtuff like this sometimes). Like in thexder, you can't even tell the BG is scrolling when the horizontal portions are uniform, it looks like you're running in place. Not sure about what VGA hardware scrolling looks like though.

 

I think they had 80286s at time of ST so not a clear win for 68000 and also it depends on speed of 80x86. 68000 is better from programming perspective (flat memory model, 32-bit registers), but from optimization for speed, 80x86 was more optimal. Probably, 32-bit register operations not involving memory would win on 68000.

Is that for faster 286s vs 8 Mhz 68k's or ones of equal clock speed? (plus there's the 68010 to considder, and then the 68020/030 vs 386, 040 vs 486, and 060 vs pentium/586)

[kool kitty89]

- no SIO port at all, and inferior joystick port (only 1 on most PCs)

Many controllers/joysticks supported dazy chaining, lacking that you could get an adaptor/splitter. (USB now shifted in favor of unfortunatly, and some of the best controllers haven't been carried over, like my favorite Xtermination -discontinued and there is a USB version, but it's uncommon)

 

Hmmm it's interesting I should be called a fanboy for saying the A8's only general superiority to the C64 in graphical terms for the sake of fast arcade games as were all the rage in 1980s was a 128 colour palette to 16....if you have to waste half your PM graphics AND half your CPU time just to get 8 or so colours on screen in 160x200 where is the killer advantage? No sorry the really thorn in the side of the ST as far as sales went was VIC-II sprites and scrolling and SID sound on the C64...all of which were not present in an ST to the same levels of sophistication....which put a lot of people off.

The color palette was probably the C64's biggest limitation (something like the TED's palette would have been awsome), really not better than the Colecovision/MST (9918 VDP), a bitt better than the VIC's and CGA though. Still pretty weak for the time, granted Atari had been ahead from 1977 with the VCS's 16-colorx8 shade palette. (probably superior to the NES's palette and definitely to EGA/SMS's 6-bit RGB)

 

The big advantage of the c64 was the large, multicolor sprites, so have argued maing it superior to NES as well (but that has a palette advantage and resolution advantage), the sound is arguable, some love the SID over POKEY (or NES for that matter), but I feel POKEY has its advantages as well (and all three are better than the PSG of the Colecovision/SMS or ST/MST/CPC/Spectrum etc). NES has the distinct advantage of PCM playback with 7-bit linear DAC channel supporting DPCM decompression. (with the SID's tweaked PCM channel vs POKEY's 4-bit linear DACs debatable as well)

8-bits have a ~75% faster CPU as well. (of course so does NES, A7800 etc)

 

I'm not sure how the background/scrolling capabilities compare though, like character block/cell differences. (other than the color palette difference)

 

And can't GTIA/CTIA clone/multiply identical sprites like the VCS can? (so have lots of the same sprite on screen without flicker, good for games like robotron, Joust, etc. (does CTIA/GTIA include the "ball" like TIA as well -which I beleive Joust on the VCS relies on for the eggs and pitfall for the vines) And with the faster CPU there's better ability to handel software sprites.

Edited December 24, 2009 by kool kitty89

[Rybags]

This is the code, it's just really a scribble though

 

Nice... but hang about... you're only moving 2 bitplanes, aren't you?

[atariksi]

This is the code, it's just really a scribble though

 

Nice... but hang about... you're only moving 2 bitplanes, aren't you?

 

Looking at his 68K code, it's 2 planes. He needs to up that to at least 3 planes. Would prefer that though over some S.Y.N.C. stuff which isn't as resolute anyway.

[atariksi]

This is the code, it's just really a scribble though

 

At least you showed one advantage of planar graphics over chunky.

 

Boulderdash as it exists on ST is jerky. At least it would be nice to get it to run at 60Hz even though still overall slower than A8 in terms of throughput. A generic A8 graphics mode would have overlayed sprite colors added in to so a 4-plane scroller would be necessary. Of course, GTIA already requires 4-planes.

[Crazyace]

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.

 

It's not GTIA though Atariksi - but it is 320x192x4 colours, which is something the A8 can't scroll at all.

 

 

( 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. )

 

The sad thing is that the ST should have had h/w scrolling from the start - Even a simple 0-15 pixel scroll ( and the ability to rewrite the screen ptrs in hblank ) would have had a stunning effect on the quality of scrolling games

[Rybags]

Well, we're talking a poor little RISC vs a CISC with nice barrel-shifter, and running a little over 4 times as fast.

 

Anyway, you don't generally need to move screen RAM around at all on the A8.

 

Also, aren't your cycle calcs out a bit for the ST? I thought that 50% of cycles were blocked for DMA - although of course the 68000 doesn't necessarily need to halt if the bus is taken.

[andym00]

Well, we're talking a poor little RISC vs a CISC with nice barrel-shifter, and running a little over 4 times as fast.

 

I'm fairly sure from memory that the 68K didn't have a barrel shifter.. I thought the ARMs were the first real consumer level CPUs to introduce that, outside of the the more esoteric CPUs of those times..

 

I do agree that's it's pretty bad form to compare an 8Mhz 68K against a 1.79Mhz 6502, but according to one poster here the 6502 is a big puncher in it's class

 

But this is exactly where this was expected to go.. Someone will do something to counter the claims of someone, then the rules change again.. And so it continues, endlessly.. So now whilst the ST has proven that it can do what was asked (which was never in doubt), and at a higher resolution, now it has to do it on more colours as well.. This is just plain silly.. 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

 

Anyway, you don't generally need to move screen RAM around at all on the A8.

 

That's true in the literal sense and I do like that about the A8 a lot, bar the 4K crossing shenanigans, but the handling of that is a major pain in the arse on the A8 when it comes to things like putting software sprites on top of it from my experience, especially in character modes!! And even then there's a fair degree of data duplication as you write new parts of the screen.. But it helps, a lot!

 

 

But if it's was absolutely true that on the A8 the scrolling was as easy as it's maintained here and in other threads then why were there never many full screen scrolling games with sprites ? I just have this sneaking suspicion that the vast majority of games on the A8 actually don't utilise the hardwares ability in ways that's proclaimed that it's so easy to do, simply because it's nightmare to get that stuff working well, rather than just sucking up the cost of doing it with the CPU.. Obviously in graphics modes it's a win versus using the CPU, but in character modes the additional complexity and additional/duplicated writes required for both scrolling and sprites in top are only a marginal win over brute forcing it when everything is taken into consdireration.. But that's just my opinion, formed from actually trying to utilise this stuff, so probably doesn't count

 

I spent too long implementing a free-scrolling setup with software sprites with multiplexed underlays and I practically no hair left after that little experiment, and not much memory either So whilst you can just scroll a screen around for very little CPU cost (not freely!) it's certainly not the complete story when it comes to doing something useful with that beyond a nice scrolly-wolly demo..

 

So where are all these games that utilise the hardware like that, since if that's the case, then I'd be expecting full multi-directional games at 50hz/60hz with gazillions of hardware sprites underlaying the screen and software sprites because scrolling costs you nothing so you can dedicate all the time to software sprites and a multiplexer, and a bit of game logic of course.. But I don't see them.. At all.. Not ever one that takes the machine anywhere near it's expected limits..

 

Where as the 'other' machines, I'll use the ST and C64 here as examples simply because I'm familiar with them, both have games/software that makes them appear to push the limits of their hardware far beyond what you'd normally expect, where as on the A8 the standard of software in terms of pushing the envelope is generally pretty poor, which is odd given the fast cpu and the powerful and fairly versatile graphics hardware.. Which begs the question why ?

 

Anyway, I'm going into personal bugbear mode now, so I'll stop..

Edited December 24, 2009 by andym00

[Crazyace]

Well, we're talking a poor little RISC vs a CISC with nice barrel-shifter, and running a little over 4 times as fast.

 

Anyway, you don't generally need to move screen RAM around at all on the A8.

 

Also, aren't your cycle calcs out a bit for the ST? I thought that 50% of cycles were blocked for DMA - although of course the 68000 doesn't necessarily need to halt if the bus is taken.

 

I'd have killed for a barrel-shifter , ( though not as much as h/w scrolling )

 

I think I'm pretty safe with the cycle counts - the 68k normally runs a 4 cycle memory access, and only 2 cycles are needed for the access, so the dma takes the other cycle. ( The amiga is the same way, so 320x200x16 doesn't slow the cpu down )

I expect that if the 68k get's out of sync ( via a 6 cycle op maybe ) it's delayed by 2 to fix things up

[+poobah]

Well, we're talking a poor little RISC vs a CISC with nice barrel-shifter, and running a little over 4 times as fast.

 

Anyway, you don't generally need to move screen RAM around at all on the A8.

 

Also, aren't your cycle calcs out a bit for the ST? I thought that 50% of cycles were blocked for DMA - although of course the 68000 doesn't necessarily need to halt if the bus is taken.

 

I'd have killed for a barrel-shifter , ( though not as much as h/w scrolling )

 

I think I'm pretty safe with the cycle counts - the 68k normally runs a 4 cycle memory access, and only 2 cycles are needed for the access, so the dma takes the other cycle. ( The amiga is the same way, so 320x200x16 doesn't slow the cpu down )

I expect that if the 68k get's out of sync ( via a 6 cycle op maybe ) it's delayed by 2 to fix things up

 

No barrel shifter on the 68000.

Need to be careful with your cycle counts though, because of prefetches.

 

Really should be using the blitter to move memory around, and STe and up had fine scrolling anyway.

[TMR]

Haha I just read the locked C64 vs thread.....where's Rocky mountains with his moronic laughing like a simpleton when you need him? And his sidekick...TMR.

 

Oh, i'm still about - just not getting involved in this thread, partly because of tacky little asides like yours but mostly because i simply don't have the time for a thread of this magnitude right now; some of us have jobs and it's feckin' Christmas even if i'm doing my best to ignore it. Of course, if you really miss me (and since you've reduced me to Rockford's sidekick presumably you don't) just assume i'm arguing with atariksi as usual and i'll be trying to ignore the stress of the "festive" period by playing a metric f**kload of shoot 'em ups.

[oky2000]

Haha I just read the locked C64 vs thread.....where's Rocky mountains with his moronic laughing like a simpleton when you need him? And his sidekick...TMR.

 

Oh, i'm still about - just not getting involved in this thread, partly because of tacky little asides like yours but mostly because i simply don't have the time for a thread of this magnitude right now; some of us have jobs and it's feckin' Christmas even if i'm doing my best to ignore it. Of course, if you really miss me (and since you've reduced me to Rockford's sidekick presumably you don't) just assume i'm arguing with atariksi as usual and i'll be trying to ignore the stress of the "festive" period by playing a metric f**kload of shoot 'em ups.

 

Well I finished all my decorating, and my work and my xmas stuff too and still manage to apparently troll

 

Just my personal opinion but the 68010 was meant to be 10% fast per mhz than the 68000 but I never really saw it myself, and it broke more than it fixed. I couldn't notice any increase in speed in Starglider or Wings sub-game 3 on the Amiga. I remember in earl 87 there was a German company selling a 16mhz 68000 board for the ST, I really wish I had bought one of those at the time after playing some ST games on STeem in virtual 16mhz 68000 mode though....makes a massive improvement to my favourite ST games.

 

Happy Xmas everyone!!

[Crazyace]

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 )

[ANTIQ]

Where as the 'other' machines, I'll use the ST and C64 here as examples simply because I'm familiar with them, both have games/software that makes them appear to push the limits of their hardware far beyond what you'd normally expect, where as on the A8 the standard of software in terms of pushing the envelope is generally pretty poor, which is odd given the fast cpu and the powerful and fairly versatile graphics hardware.. Which begs the question why ?

 

Anyway, I'm going into personal bugbear mode now, so I'll stop..

 

This was talked about in the thread from hell.

 

I'd argue that Atari collapsed just as home computer programming was getting into its stride. The A8 wasn't well-supported post-crash: The peak number of games released was in 1983. For me the first sign of the A8's twilight was in 1984 when Impossible Mission didn't show up.

 

Look at Crownland. It's probably the most advanced platformer on the A8, despite everything. There's no reason there couldn't've been lots of Super Mario-style games in the late 80s, say, except for a near-total lack of interest.

 

(That doesn't justify all the claims of the kooks, though.)

[+rdemming]

The problem (for me) with the ST (and presumably, the Amiga) is I am not aware of ways that are as EASY and AVAILABLE to do the same thing. The HxC floppy drive emulator http://www.torlus.com/floppy/ seems to be a step in the right direction, but does anybody know where to get one? It doesn't look nearly as elegant of a solution as SIO2PC or Sdrive for A8, or 1541 Ultimate for C64. These devices are nearly flawless and foolproof.....for the non-technically-inclined user.

 

It is available here:

http://www.mmj.pl/~lotharek/atari/

 

One of the reasons that its installation is more complex than SIO2PC/USB is that you need to replace the internal floppy with HxC floppy emulator. You could connect the HxC to the external floppy port (similar to SIO2PC) but then it only works as drive B and lots of floppy software assumes it is started from drive A and won't work. But if you use the 520ST without the build-in floppy, you would not have this problem. Then the external floppy is drive A by default.

 

As mentioned, the UltraSatan is a great device too. The UltraSatan appears like a harddisk so software you want to run from it must work from harddisk. Most commercial games can't be run from harddisk and must be patched to work from harddisk. D-Bug did already a lot of harddisk patches.

 

The advantage of HxC is that it appears as a normal floppy and games don't have to be patched (except for removing the floppy copy protection that is done for nearly every game already). But the UltraSatan has much faster loading times.

 

Robert

[atariksi]

Well, we're talking a poor little RISC vs a CISC with nice barrel-shifter, and running a little over 4 times as fast.

 

I'm fairly sure from memory that the 68K didn't have a barrel shifter.. I thought the ARMs were the first real consumer level CPUs to introduce that, outside of the the more esoteric CPUs of those times..

 

I do agree that's it's pretty bad form to compare an 8Mhz 68K against a 1.79Mhz 6502, but according to one poster here the 6502 is a big puncher in it's class

...

If you're referring to me, I admitted 68K is overall superior to 6502 although the memory fetches take up more cycles on 68K.

 

But this is exactly where this was expected to go.. Someone will do something to counter the claims of someone, then the rules change again.. And so it continues, endlessly.. So now whilst the ST has proven that it can do what was asked (which was never in doubt), and at a higher resolution, now it has to do it on more colours as well.. This is just plain silly.. 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

...

Rules are still the same as stated in post #622 and repeated elsewhere:

 

"Stop with the excuses. Either you compare hardware one on one (like I did) or you compare games as they are and NOT draw any conclusion about the hardware from them. I can also make excuses regarding A8 games being suboptimal as well for color useage and speed."

 

You can't say ST has better or equal scrolling hardware from some games that manage to fit their scrolls into the frame time. It still takes more time than on A8. Even without sprite overlays and other tricks or using multiple graphics modes or GTIA, the standard 160*200*5 mode would require 3 planes to be scrolled on ST.

 

Anyway, you don't generally need to move screen RAM around at all on the A8.

 

...

But if it's was absolutely true that on the A8 the scrolling was as easy as it's maintained here and in other threads then why were there never many full screen scrolling games with sprites ? I just have this sneaking suspicion that the vast majority of games on the A8 actually don't utilise the hardwares ability in ways that's proclaimed that it's so easy to do, simply because it's nightmare to get that stuff working well, rather than just sucking up the cost of doing it with the CPU..

I don't see it as a nightmare-- it's quite simple to set bit 4 on DL and use the hscroll/lms. I guess when porting stuff some may not want to recode stuff given hardly any other platform has this sort of set-up.

 

So where are all these games that utilise the hardware like that,...

Two were already mentioned-- Boulderdash and Hero and I'm not a collector.

[PeteD]

Humbug

 

 

Pete

[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.

...

For your reference:

 

ANTIC BASIC MODE BYTES/ COLUMNS ROWS ROWS SCAN LINES/ # OF SCREEN RAM

MODE MODE TYPE LINE (SPLIT) (FULL) MODE LINE COLORS REQUIRED

 

2 GR.0 TEXT 40 40 - 24 8 1* 960

3 NONE TEXT 40 40 - + 10 1* +

4 GR.12(XL) TEXT 40 40 20 24 8 5 960

5 GR.13(XL) TEXT 40 40 10 12 16 5 480

6 GR.1 TEXT 20 20 20 24 8 5 480

7 GR.2 TEXT 20 20 10 12 16 5 240

8 GR.3 GRAPH 10 40 20 24 8 4 240

9 GR.4 GRAPH 10 80 40 48 4 2 480

A GR.5 GRAPH 20 80 40 48 4 4 960

B GR.6 GRAPH 20 160 80 96 2 2 1920

C GR.14(XL) GRAPH 20 160 160 192 1 2 3840

D GR.7 GRAPH 40 160 80 96 2 4 3840

E GR.15(XL) GRAPH 40 160 160 192 1 4 7680

F GR.8 GRAPH 40 320 160 192 1 1* 7680

 

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

 

It's not GTIA though Atariksi - but it is 320x192x4 colours, which is something the A8 can't scroll at all.

 

( 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.

[peteym5]

Reading through a few of these posts, something that should be considered Atari was still under Warner when they released the 8-bit and was under Jack Tremial when releasing the ST. A few here say the Tremails took Atari in a bad direction and drove Atari into the ground. He got rid of many of the remaining programmers that were present for the 8-bit & 2600 and attempted to move Atari from just being a video game company. Jack was known as a hot head and not many people wanted to work for him or wanted to write software for the ST computer.

 

I am not sure how the ST graphics modes work. Didn't it have no text modes or tilemap modes, it was all bitmap modes? Tilemap modes were popular with the Nintendo 8-bit. The A8 has character map text modes with re-definable character sets which allowed it to run games like BoulderDash with using less CPU. If it was all done with bitmap modes, it required more processing from the CPU & GPU. Plus if you wanted to scroll in any direction, you had to redraw the whole screen. The Atari 8-bit just updates its Display List Addresses and VScroll & HScroll registers. Writing to about 30 bytes of memory instead of thousands. That is also where a Blitter circuit comes in handy so it does not take away from the CPU. The ST ran at over 4x the speed of the 8-bit with a 16bit cpu with more registers that made up the difference.

[Crazyace]

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.

 

( 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.

Edited December 24, 2009 by Crazyace