Atari 8bit is superior to the ST

[Crazyace]

Yes, Gauntlet II shows 4 way scrolling that would be difficult to replicate on the A8 , as the static panel is on the right

[atariksi]

Yes, Gauntlet II shows 4 way scrolling that would be difficult to replicate on the A8 , as the static panel is on the right

 

Unless you use sprites for the static portion and let the lines scroll beneath it with DL scrolling.

 

And if the game involves a kernel, you could set HSCRL in the middle of the scanline.

[atariksi]

There is no slow down when you double buffer on the ST. The game still runs at 50/60 Hz.

...

You can't make up for time lost due to doing things in software.

 

That's not what double or triple buffering are there for, they're used to prevent the tearing you were talking about the ST having and the majority of games don't suffer because they're multi buffered.

...

So you double buffer and skip frames so instead of tearing you get jerkier motion or flicker or delayed effects in colliding objects.

 

And using joystick port is slow on ST regardless of whether you use it for streaming data or not. At the very least, you have to input the mouse data, keyboard data, and joystick directions for games.

 

As far as games go, joystick input should be polled once per VBL as an absolute maximum and for those jobs the speed of the port on the ST is, of course, more than adequate - and at the very least a game can get away with polling just the joystick, almost none need to read the mouse and quite a few don't even touch the keyboard.

 

What about Marble Madness-- doesn't that allow you to use all three (joystick/mouse/keyboard) with multiple players settings as well (based on Amiga version that I have played)?

[PeteD]

Yes, Gauntlet II shows 4 way scrolling that would be difficult to replicate on the A8 , as the static panel is on the right

 

Unless you use sprites for the static portion and let the lines scroll beneath it with DL scrolling.

 

And if the game involves a kernel, you could set HSCRL in the middle of the scanline.

 

Using up all your mono sprites or your cpu time.. ho hum.

 

 

You could probably do it by using pre-shifted versions of it and dump it into some reserved chars every frame, but still, cpu time, and ram, but I suppose everyone expects stuff to be 320k these days.

 

*edit* to include quote.

 

Pete

Edited December 15, 2009 by PeteD

[PeteD]

There is no slow down when you double buffer on the ST. The game still runs at 50/60 Hz.

...

You can't make up for time lost due to doing things in software.

 

That's not what double or triple buffering are there for, they're used to prevent the tearing you were talking about the ST having and the majority of games don't suffer because they're multi buffered.

...

So you double buffer and skip frames so instead of tearing you get jerkier motion or flicker or delayed effects in colliding objects.

 

Why always equate double buffering with slower? It's not always linked. Either you don't understand it or you're presuming double buffering is only done on stuff that takes 2+ frames.

 

 

Pete

[Crazyace]

Yes, Gauntlet II shows 4 way scrolling that would be difficult to replicate on the A8 , as the static panel is on the right

 

Unless you use sprites for the static portion and let the lines scroll beneath it with DL scrolling.

 

And if the game involves a kernel, you could set HSCRL in the middle of the scanline.

 

That seems very difficult - you end up using all of the players to replicate a static panel, or you waste large amounts of cpu resources on changes the scroll value.. ( I expect you've tested this mechanism - how much time does it take away? )

[andym00]

Using up all your mono sprites or your cpu time.. ho hum.

 

 

You could probably do it by using pre-shifted versions of it and dump it into some reserved chars every frame, but still, cpu time, and ram, but I suppose everyone expects stuff to be 320k these days.

 

 

Even with pre-shifted score panel chars it doesn't alter the fact that at some point it's now got to manually move the entire main playfield, since you've just destroyed the advantage the LMS stuff gives you, and you'll now have to move the screen in a conventional copying fashion.. Unless you write the score panel chars into the map data each frame, and then remove it when it needs to move, which would probably be cheaper if you could have the map uncompressed in memory.. But it's going to eat various combinations of memory, cpu and sprites resources depending upon your choice, and a large chunk of each no matter what combination you would go for..

 

The hscroll splitting isnt practical if you're in character mode, and then you encounter the badlines, which means that on those lines you have no cycles left to split it anyway.. So it would mean empty lines in the pre-shifted panel data on those lines, which would then move as the screen scrolls up and down Or you do the screen in bitmap mode, but than there's no charsets to use So the only practical way I think is to burn your sprites, and have none for the game, which isn't the brightest move in history

 

Unless you limit the scrolling to characters with no smooth scroll, which would be properly rubbish..

 

To be honest, I think every other platform that's been mentioned here probably wins on this count..

ST - doesn't cost it anything, since it's got to do it all in software anyway..

Amiga - I guessing it could split the screen at the right time easily enough, or use the hardware sprites, or use an ST like approach but blitting, or some smarty pants bit-plane arrangement..

7800 - Doesn't cost it anything anyway..

64 - Can be done using only 3 of its sprites, assuming it needs 3 sprites width in nice hires resolution.. Or 2 of you're going for chunky, and simple colouring..

 

A8 is really the only one that really has to expend a lot of very precious resources (Sprites, Memory, or CPU) to achieve that effect, resources that are in demand from the very beginning anyway..

Edited December 15, 2009 by andym00

[Marius]

When I had to throw away all my computers in my house, and I only could keep one atari. And I would not be allowed to buy any other computer back...

 

The Atari ST would stay, and the rest would leave the house.

 

Why? Because the Atari ST is much more capable doing professional things; like small DTP, nice word processing (ok, that is also good now with The Last Word 3.1 on atari 8bit), Music sequencing and notation and even some limited internet things like email.

 

And on the Atari ST are also a lot of nice games available. When I think of the very smooth scrolling (both horizontal and vertical) in the Addams Family, I simply say WOW to my Atari ST. Really: it is A M A Z I N G. You can say whatever you want: but that game is superb on atari ST. And there are more games with same quality.

 

But now I don't have to make this hard choice (lucky me) so all 'modern' tasks are done on my iMac and iBook, and all the fun is on my atari 8bit.

 

Thank to this thread (yes, there are really + sides to this thread!) I am really interested in my ST again. In a few days I have some time to spend, and I know what I'm going to do: setup my Atari ST again!

 

That will be fun!

 

But I also know where it will end: after a few days of true atari ST i will switch on my atari 8bit, and then I have the feeling: "Ooooh I really did miss my atari 8bit" ... strange eh?

 

So even after already too much pages in this thread I keep my first vote: both systems are COOL!

[+wood_jl]

A slight aside, but it was brought up earlier about the 7800 and it not having a POKEY, but that was left out of the 7800 because[1] there wasn't enough space on the board, and since you had TIA support in the anywhere they just went with that..

 

Well of course there wasn't room on the board, as they didn't place any importance on sound, didn't include it, and then created as small of a board as possible without it. I don't see how it can be given a 'pass' because of that. Obviously they should have included it or they wouldn't stuff POKEYs in cartridges. There had been 10 years of systems with better sound than 2600. At least we didn't have to play 'Super Mario Bros' with TIA sound.

[+wood_jl]

When I had to throw away all my computers in my house, and I only could keep one atari. And I would not be allowed to buy any other computer back...

 

The Atari ST would stay, and the rest would leave the house.

 

Why? Because the Atari ST is much more capable doing professional things; like small DTP, nice word processing (ok, that is also good now with The Last Word 3.1 on atari 8bit), Music sequencing and notation and even some limited internet things like email.

 

And on the Atari ST are also a lot of nice games available. When I think of the very smooth scrolling (both horizontal and vertical) in the Addams Family, I simply say WOW to my Atari ST. Really: it is A M A Z I N G. You can say whatever you want: but that game is superb on atari ST. And there are more games with same quality.

 

I'd - of course - choose my Intel PC box. Why? Do all the 'professional' things you mentioned (better, of course), and emulate the other 2 (for the most part).

 

But now I don't have to make this hard choice (lucky me) so all 'modern' tasks are done on my iMac and iBook, and all the fun is on my atari 8bit.

 

Ditto, but substitute "Intel PC Box" for iMac/iBook.

 

Thank to this thread (yes, there are really + sides to this thread!) I am really interested in my ST again. In a few days I have some time to spend, and I know what I'm going to do: setup my Atari ST again!

That's cool. I'll probably just fire up 'Steem' and play a few minutes of 'Sundog' for nostalgia.

 

But I also know where it will end: after a few days of true atari ST i will switch on my atari 8bit, and then I have the feeling: "Ooooh I really did miss my atari 8bit" ... strange eh?

Not so strange.....now you're talking!

[andym00]

A slight aside, but it was brought up earlier about the 7800 and it not having a POKEY, but that was left out of the 7800 because[1] there wasn't enough space on the board, and since you had TIA support in the anywhere they just went with that..

 

Well of course there wasn't room on the board, as they didn't place any importance on sound, didn't include it, and then created as small of a board as possible without it. I don't see how it can be given a 'pass' because of that. Obviously they should have included it or they wouldn't stuff POKEYs in cartridges. There had been 10 years of systems with better sound than 2600. At least we didn't have to play 'Super Mario Bros' with TIA sound.

 

Sorry, I was bit wrong there, not enough room because of the case that was chosen for it.. My mistake..

 

http://www.atarimuse.../atari3600.html

]

The original model # of the

Atari

7800

was the

Atari

3600. Marketing then settled on the

Atari

CX-9000 Video Computer System. Since the system was originally thought to be the ultimate gaming console, a high number was chosen. Then during marketing meetings it was realized that there would be more powerful game consoles down the road so the model # was reconsidered. It was decided that the new console would have the model #

7800

(5200 Graphics + 2600 Compatibility =

7800

) Since it would utilize the new line of PRO-LINE controllers, it would be called the PROSystem. The

Atari

7800

PRO System was born.

 

The original

Atari

3600 prototype was going to be a single sided motherboard to drastically cost reduce the unit from the start to help increase profits. However, all of the jumpers on the top of the motherboard proved to be anything but a cut in cost. It would be too costly to assemble and the single sided PCB was dropped in favor of a new PCB which was double sided. Many have asked, "why isn't there a

POKEY

chip on the motherboard?!?! All the

7800

will do is 2600 type audio!!!" Well, due to the size of the case (the

Atari

7800

case is actually a re-designed version of the

Atari

2800. The re-design was done by Barney Huang) the motheboard of the

Atari

7800

was rather small and there was not enough space to accomodate the

POKEY

chip into the design. Instead the

POKEY

chip could be added into the game cartridges themselves when higher quality sound effects were needed (Such as the Ball Blazer cartridge with its background music.)

 

I think that covers it quite nicely.. And to be fair to the TIA, it does actually make some fairly good POKEY like sound effects when pushed, perhaps more so on the 7800 than on the 2600 though.. It's not by far as shit as it's made out to be.. I personally like its character anyway..

[atariksi]

 

That's why the 18ms figure in the original calculation - it's > 16.67ms(NTSC) but less than 20ms(PAL). Scrolling really does suck on the STe.

 

For vertical scrolling I did play around with the border removal tricks in the first 8 lines to get 50Hz scrolling with sprites. I never looked at horizontal scrolling - but I guess that some of the demos did. The ST really should have had h/w scrolling

 

I guess the "STe" is a typo, since one of the most useful improvements of the STe was hardware scrolling registers.

 

As I am not a programmer, I can only say that horizontally scrolling games on the plain ST always come with compromises, it's either 2-pixel scrolling (or worse) like in "Venus the Flytrap", or reduced playfield size like in "Toki", "Warp", "Seven Gates of Jambala" or "Return to Genesis". But - contrary to the belief of atariksi, ST games do not necessarily scroll jerkily - indeed the game he chooses to substantiate his rather ridiculous claim of A8 superiority ("Boulder Dash") is an obvious example of bad ST programming. I could as well point to "Racing Destruction Set" to "prove" the jerky scrolling on the A8 or to "Up'n'Down" to "prove" the terrible sprite flickering on that hardware.

...

Well, I didn't just use the examples of games like Joust, Boulder Dash, Mr. Robot to prove A8's superiority in the (5) items listed. It's physically impossible to do the scrolling of the full screen within a frame's time, paint the sprites in the equivalent time, etc. In fact, take a look at the example of Atari 2600 grand prix which basically paints the entire screen at 60 Hz due to the large size of the cars. It's easier to do on A8 with support for many resolutions of graphics modes and sprites rather than on ST. Do all the double/triple/20-bufferring you want, the ST will perform worse than A2600 and A800.

 

As wood_jl put it so correctly: the Atari ST is a 1985 machine, the A8 is a 1979 machine. The 8 MHZ 68000 CPU runs circles around the 6502C, even if that is supported by a (for it's time!) very advanced chipset. The ST can't do overscan, and it can't scroll in hardware, but to deny the overall superiority of a 6 years younger machine would be comparable to claiming the STs superiority to a 1991 386DX40 computer ("Wing Commander" was published in 1990 and "Eye of the Beholder" in 1991, e.g.).

 

 

Thorsten

 

That does not follow logically. You can have inferior features on a machine coming out later as I gave the example of Thinkpad 770ED vs. laptops running 2X+ CPUs and giving inferior performance.

[atariksi]

Yes, Gauntlet II shows 4 way scrolling that would be difficult to replicate on the A8 , as the static panel is on the right

 

Unless you use sprites for the static portion and let the lines scroll beneath it with DL scrolling.

 

And if the game involves a kernel, you could set HSCRL in the middle of the scanline.

 

That seems very difficult - you end up using all of the players to replicate a static panel, or you waste large amounts of cpu resources on changes the scroll value.. ( I expect you've tested this mechanism - how much time does it take away? )

 

I said, "if the game involves a kernel", meaning you are already using a kernel so just have to fit in a LDA/STA for the HSCRL. And I wasn't speaking specifically for your Gauntlet II (which I am not familiar with), but in general for scrolling splits horizontally. No, you don't necessarily use up all your players. But you can't use the LMS in some cases but you can do 16 color clocks of scroll at least (still better than C64 and ST).

[atariksi]

When I had to throw away all my computers in my house, and I only could keep one atari. And I would not be allowed to buy any other computer back...

 

The Atari ST would stay, and the rest would leave the house.

 

Why? Because the Atari ST is much more capable doing professional things; like small DTP, nice word processing (ok, that is also good now with The Last Word 3.1 on atari 8bit), Music sequencing and notation and even some limited internet things like email.

...

That's a subjective statement. If I had every species of machine ever built (prior to Amiga) and only could keep one, I would keep Atari 800. All of my serious stuff was done on A800 and is impossible to port over to the other machines even theoretically.

[Crazyace]

Yes, Gauntlet II shows 4 way scrolling that would be difficult to replicate on the A8 , as the static panel is on the right

 

Unless you use sprites for the static portion and let the lines scroll beneath it with DL scrolling.

 

And if the game involves a kernel, you could set HSCRL in the middle of the scanline.

 

That seems very difficult - you end up using all of the players to replicate a static panel, or you waste large amounts of cpu resources on changes the scroll value.. ( I expect you've tested this mechanism - how much time does it take away? )

 

I said, "if the game involves a kernel", meaning you are already using a kernel so just have to fit in a LDA/STA for the HSCRL. And I wasn't speaking specifically for your Gauntlet II (which I am not familiar with), but in general for scrolling splits horizontally. No, you don't necessarily use up all your players. But you can't use the LMS in some cases but you can do 16 color clocks of scroll at least (still better than C64 and ST).

 

Ok, I assumed you were replying to my point about Gauntlet II. The point about setting HSCRL every line sounded interesting, which is why I asked how expensive it was. ( Also, if you change HSCRL mid line what gets displayed? )

[+wood_jl]

[/indent]I think that covers it quite nicely.. And to be fair to the TIA, it does actually make some fairly good POKEY like sound effects when pushed, perhaps more so on the 7800 than on the 2600 though.. It's not by far as shit as it's made out to be.. I personally like its character anyway..

 

Interesting reading I was not aware of. Thanks!

[kool kitty89]

RAM can, i believe, be added through the cartridge...?

 

It can easily be added like that.. The RoF prototype on the 7800 uses a 2K RAM expansion as an example..

My only uncertainty, is that I don't believe (correct me if I'm wrong please!) it can be used by Maria at high speed, like the 4K internal RAM can be ?? That's something I've always been a little unsure about, but never sat down and found the answer to.. I suspect not, but would love to be wrong on that for very obvious reasons

Don't Summer and Winter Games carts have 16 kB of SRAM onboard?

 

Not sure how people can complain about the ST having to do software scroll then say it isn't as flexible as the A8. By it's very nature it's the most flexible, maybe not the fastest. You can scroll any portion of the screen in any direction at any speed, move single bitplanes for effects, etc. Yes, slower than hardware scrolling, less flexible? no. 7800 can do most of it in hardware so it pretty much kicks the other 2 machines arses.

Doesn't the 7800 have to do a lot of that stuff in software as well? (I'm pretty sure of scrolling at least, not sure how sprites are handeled on it other than that it doesn't use tranditional hardware sprites -or blitter)

 

A slight aside, but it was brought up earlier about the 7800 and it not having a POKEY, but that was left out of the 7800 because[1] there wasn't enough space on the board, and since you had TIA support in the anywhere they just went with that..

 

Well of course there wasn't room on the board, as they didn't place any importance on sound, didn't include it, and then created as small of a board as possible without it. I don't see how it can be given a 'pass' because of that. Obviously they should have included it or they wouldn't stuff POKEYs in cartridges. There had been 10 years of systems with better sound than 2600. At least we didn't have to play 'Super Mario Bros' with TIA sound.

 

Sorry, I was bit wrong there, not enough room because of the case that was chosen for it.. My mistake..

 

http://www.atarimuse.../atari3600.html

]

The original model # of the

Atari

7800

was the

Atari

3600. Marketing then settled on the

Atari

CX-9000 Video Computer System. Since the system was originally thought to be the ultimate gaming console, a high number was chosen. Then during marketing meetings it was realized that there would be more powerful game consoles down the road so the model # was reconsidered. It was decided that the new console would have the model #

7800

(5200 Graphics + 2600 Compatibility =

7800

) Since it would utilize the new line of PRO-LINE controllers, it would be called the PROSystem. The

Atari

7800

PRO System was born.

 

The original

Atari

3600 prototype was going to be a single sided motherboard to drastically cost reduce the unit from the start to help increase profits. However, all of the jumpers on the top of the motherboard proved to be anything but a cut in cost. It would be too costly to assemble and the single sided PCB was dropped in favor of a new PCB which was double sided. Many have asked, "why isn't there a

POKEY

chip on the motherboard?!?! All the

7800

will do is 2600 type audio!!!" Well, due to the size of the case (the

Atari

7800

case is actually a re-designed version of the

Atari

2800. The re-design was done by Barney Huang) the motheboard of the

Atari

7800

was rather small and there was not enough space to accomodate the

POKEY

chip into the design. Instead the

POKEY

chip could be added into the game cartridges themselves when higher quality sound effects were needed (Such as the Ball Blazer cartridge with its background music.)

 

I think that covers it quite nicely..

Umm, that may expalain to some extent, but at worst, they could have put POKEY on a riser board. (and later modify the board to fit it on directly) Not th emost cost effective, but a good deal more efficient than using it on-cart. (sure there was the super-low-cost GUMBY/mini chip planned, but if they'd even considdered using POKEY in the intrim it made much more sense to include it onboard)

As soon as they dropped the plan for having sound onboard MARIA, the GCC guys should have automatically thought of POKEY (atari's standard sound chip in the arcades as well at the time) and intended on puttin it on the board from then on -all the better complimented by TIA. (putting sound on the cart would still be useful for possible future sound expansion, like the Famicom did -NES removed that ability)

 

And to be fair to the TIA, it does actually make some fairly good POKEY like sound effects when pushed, perhaps more so on the 7800 than on the 2600 though.. It's not by far as shit as it's made out to be.. I personally like its character anyway..

 

I definitely agree with that, as I mentioned earlier, TIA has advantages over the sound chips of the CV/SMS (etc) and Vectrex/IV/ST/MST/CPC/Speccy (etc) as, while it's limited to 2 channels, it's capable of producing more varied waveforms rather than just square and noise (and the noise is better for SFX too IMO), with POKEY taking that a step further. (plus allowing direct use of the 4-bit DACs for linear PCM playback) TIA does soun better ont he 7800 than the VCS, probably due to the much more limited CPU time of the 2600. (Mario Bros was mentioned above, and IMO it sounds pretty good on the 7800, compared to the 2600 in particular, bue even to the 8-bit/5200 in some respects)

[popmilo]

Atari ST has turrican so it has my vote! It is better in most cases

[+poobah]

I am not streaming tons of data into the ST's joystick port because it's too slow for that.

And because there's absolutely no sane reason to do that on the ST.

[+poobah]

So you double buffer and skip frames so instead of tearing you get jerkier motion or flicker or delayed effects in colliding objects.

It seems you don't understand the basics of game programming.

Double buffering has nothing to do with skipping frames.

You can run 60Hz all day long on a double buffered system.

You page flip during the vblank and you are done. Low overhead (literally a couple writes), improved visuals.

The purpose is to avoid writing to the screen at the same moment it is being displayed, which would result in a tearing effect (turn off vsync on any modern video card for the same effect)

 

Most A8 games use similar techniques

 

And using joystick port is slow on ST regardless of whether you use it for streaming data or not. At the very least, you have to input the mouse data, keyboard data, and joystick directions for games.

 

As far as games go, joystick input should be polled once per VBL as an absolute maximum and for those jobs the speed of the port on the ST is, of course, more than adequate - and at the very least a game can get away with polling just the joystick, almost none need to read the mouse and quite a few don't even touch the keyboard.

 

What about Marble Madness-- doesn't that allow you to use all three (joystick/mouse/keyboard) with multiple players settings as well (based on Amiga version that I have played)?

Not that the Amiga version is relative to an ST discussion, but anyways...

Tell IKBD to report sticks as keypresses. mouse in relative mode.

Each frame, peek at IKBD's status register. if no change, you are done.

If there's a packet, grab it and decode, done.

The port could be 10 times slower and still be plenty fast enough to do what it is designed for.

[griz]

So you double buffer and skip frames so instead of tearing you get jerkier motion or flicker or delayed effects in colliding objects.

It seems you don't understand the basics of game programming.

Double buffering has nothing to do with skipping frames.

You can run 60Hz all day long on a double buffered system.

You page flip during the vblank and you are done. Low overhead (literally a couple writes), improved visuals.

The purpose is to avoid writing to the screen at the same moment it is being displayed, which would result in a tearing effect (turn off vsync on any modern video card for the same effect)

 

That's IF you don't take too long in drawing the display or handling the game logic. Then frame skipping is the result.

 

That's a subjective statement. If I had every species of machine ever built (prior to Amiga) and only could keep one, I would keep Atari 800. All of my serious stuff was done on A800 and is impossible to port over to the other machines even theoretically.

 

Let me guess ... it's because the 800 supports even MORE high speed joysticks!?

[TMR]

That's not what double or triple buffering are there for, they're used to prevent the tearing you were talking about the ST having and the majority of games don't suffer because they're multi buffered.

...

So you double buffer and skip frames so instead of tearing you get jerkier motion or flicker or delayed effects in colliding objects.

 

No, because double buffering doesn't work like that either; buffer flips can happen on every VBL or every sixth depending on what the code rendering the back buffer is doing, lumping them all together like that just doesn't make sense. Multiple display buffers are incredibly common, there are a couple of machines like the 2600 (which doesn't have a screen RAM as such) or the 48K Spectrum (which can't change where it's getting bitmap or attribute data from) that don't have examples but they're the minority, i've seen buffering on the C64, Atari 8-bits, Atari ST, Amiga, C16, Amstrad CPC, even the VIC 20 but it does need a RAM expansion to do.

 

Collisions don't usually slow games down, the majority of action games use bounding boxes and those can be handled at a reasonable speed on the C64 so i doubt the ST is going to worry too much.

 

As far as games go, joystick input should be polled once per VBL as an absolute maximum and for those jobs the speed of the port on the ST is, of course, more than adequate - and at the very least a game can get away with polling just the joystick, almost none need to read the mouse and quite a few don't even touch the keyboard.

 

What about Marble Madness-- doesn't that allow you to use all three (joystick/mouse/keyboard) with multiple players settings as well (based on Amiga version that I have played)?

 

Read what i said; almost none need to read the mouse and quite a few don't even touch the keyboard. Some do more reading yes, but they're in the minority and the bulk of games simply poll a joystick or two once per VBL at most. But even in those situations where games are doing more, the way the ST handles things is still more than efficient enough to get the job done and it's nowhere near the throughput you're talking about.

[atariksi]

So you double buffer and skip frames so instead of tearing you get jerkier motion or flicker or delayed effects in colliding objects.

It seems you don't understand the basics of game programming.

...

It's clear if you go back to posts #520 onward, that I admitted that both 60Hz and 30Hz games are possible on ST involving double/triple buffering.

 

Double buffering has nothing to do with skipping frames.

You can run 60Hz all day long on a double buffered system.

You page flip during the vblank and you are done. Low overhead (literally a couple writes), improved visuals.

The purpose is to avoid writing to the screen at the same moment it is being displayed, which would result in a tearing effect (turn off vsync on any modern video card for the same effect)

 

Most A8 games use similar techniques

...

As I said, "you cannot make up for the time lost in doing things in software" vs. A8 doing it in hardware. So even if you do it double bufferred vs. A8 doing it in a VBI or with double bufferring, you still took a longer time and thus it's inferior on ST. You have less time left in the frame for other things.

 

And using joystick port is slow on ST regardless of whether you use it for streaming data or not. At the very least, you have to input the mouse data, keyboard data, and joystick directions for games.

 

As far as games go, joystick input should be polled once per VBL as an absolute maximum and for those jobs the speed of the port on the ST is, of course, more than adequate - and at the very least a game can get away with polling just the joystick, almost none need to read the mouse and quite a few don't even touch the keyboard.

 

What about Marble Madness-- doesn't that allow you to use all three (joystick/mouse/keyboard) with multiple players settings as well (based on Amiga version that I have played)?

Not that the Amiga version is relative to an ST discussion, but anyways...

...

I was giving example of game that uses multiple device inputs simultaneously and I would think the ST version does the same.

 

Tell IKBD to report sticks as keypresses. mouse in relative mode.

Each frame, peek at IKBD's status register. if no change, you are done.

If there's a packet, grab it and decode, done.

The port could be 10 times slower and still be plenty fast enough to do what it is designed for.

 

Even at 781 bytes/second, you still spend more time (cycles) reading joystick and figuring out what it does than A8 doing LDA 54016 which doesn't have any timing constraints of when to read it.

[andym00]

Don't Summer and Winter Games carts have 16 kB of SRAM onboard?

 

Actually, now you mention I think they do, but I've never even played those because I had enough of those games to last me a lifetime on the 64 first time round If I ever have to perform another Triple Lutz in a video game it will be too soon

 

 

I'm not actually that sure how many other games do use RAM expansion on the 7800.. I can't imagine it's that many, since you repeatedly hear about how Atari was being very penny pinching at the time when it came to the 7800, so I guess you had to be something very very special to get it.. Heck.. Even 16KB of RAM seems crazy for Summer Games and Winter Game..

 

Okay, just went and checked.. It looks like the RAM expanded games were:

RoF Prototype - 2K

Winter Games/Summer Games - 16K

Impossible Mission - 8K

And these, but I don't know the RAM sizes..

Crossbow

Jinks

Tower Toppler

There might be more, but those are the only Supercarts with RAM ICs on board, and I think it was only the Supercarts that could take RAM..

And to be honest, I'm not sure why half of these need that much RAM in the first place.. Especially Summer/Winter Games with 16K of RAM.. That seems positively bonkers, but then I'm sure there's some logical reason for it..

 

Doesn't the 7800 have to do a lot of that stuff in software as well? (I'm pretty sure of scrolling at least, not sure how sprites are handeled on it other than that it doesn't use tranditional hardware sprites -or blitter)

 

It's going to be a massive post to answer that in the detail you want and I don't want to do that because I've not had enough coffee or cigarettes, but briefly..

 

Suffice to say there's no hardware sprites as such.. There isn't really the concept of a screen in a conventional sense..

Basically, you provide a list of data transfers that are composed into a single 160x5bit line RAM that is double buffered.. So whilst the current line is being displayed, the data transfers you've specified are taking place into the other line buffer..

 

All screen data is generated in this fashion.. The data transfers are controlled through a series of Display Lists, and Display List Lists.. The DLLs define a region on the screen x lines high were the transfers are re-used, but with automatic address adjustment to allow for the height of the zone..

 

It's way more than that really, but anything that appears on screen is because you've specified it literally in the form 'move X bytes from address Y to pixel position Z in this line' With transparency taken care of for you if you want..

So it just blits grpahic spans into the Line Ram Buffer, exactly was you've specified them in the DLL, in the order you specified them as well..

 

Each line increment the hi-byte of the source address is modified to get to the next line of source data..

And there's helpers to work around the intrinsic problems caused by the zones and the addressing through HOLEY DMA which allows reads from alterante 2K or 4K block to be read as zero..

 

Maria runs at a much faster rate the the CPU so there's something like 456 Maria clock cycles for transferring data into the line RAM for each screen line composed.. If you construct a DLL that needs more cycles than that then everything beyond the end cycle is ignored as MARIA shuts down the DMA at the end of the line regardless of if it's finished or not, and moves to the next line.. If you create too much for it to render, only that which has completed by the shutdown time is displayed..

 

There are indirect modes as well, which allow fetching from a character like screen in memory, so east implementations of those modes are doable.. But they eat more clocks because of the indirect memory access needed to first lookup the character from memory, and to then read the actually source graphics..

 

There's trade offs in how you choose to create your screen.. Zone Size Vs. DL Memory, Vs. CPU DLL update cost Vs. Maria HOLEY fetch costs.. And it is a bloody weird way of doing things

 

Of course, all those data transfers aren't free.. When MARIA is rendering its Line RAM, the CPU is locked out, so if you create a display that uses every cycle that MARIA can use then the CPU will not get much done

 

It's an awesome system and very very flexible.. Just let down in the 7800 implementation by the rather tiny 4K of RAM..

Still, I do believe that we haven't even begun to see what the 7800 is capable of

 

 

I know I've missed out some things, but that's the jist of it If you want to know more the best bet is really to go and read the Maria Docs on it, and then write some code, because that's the only way I could clarify in my head the way the thing worked

 

 

[atariksi]

That's not what double or triple buffering are there for, they're used to prevent the tearing you were talking about the ST having and the majority of games don't suffer because they're multi buffered.

...

So you double buffer and skip frames so instead of tearing you get jerkier motion or flicker or delayed effects in colliding objects.

 

...

Collisions don't usually slow games down, the majority of action games use bounding boxes and those can be handled at a reasonable speed on the C64 so i doubt the ST is going to worry too much.

...

I wasn't talking about software collisions slowing things down-- but not being able to finish within a frame's time makes the collision detection produce a delayed effect. I have seen a lot of that on Colecovision games like Popeye giving terrible playability. Of course, collision detection does have some impact too whether it's hardware or software but I'm only talking about things that have major hits. Scrolling gives a major hit to ST and will cause skipping frames (if double bufferred) otherwise it will cause other bad effects like tearing.

 

Read what i said; almost none need to read the mouse and quite a few don't even touch the keyboard. Some do more reading yes, but they're in the minority and the bulk of games simply poll a joystick or two once per VBL at most. But even in those situations where games are doing more, the way the ST handles things is still more than efficient enough to get the job done and it's nowhere near the throughput you're talking about.

 

How can it be almost none when the entire system is built on a GUI which centers around the mouse. I would think they have plenty of mouse-based games, but non-games should also be considered. High rates was related to doing other things with joystick ports such as doing a joystick recorder which would produce inferior results on ST.