Atari v Commodore

[potatohead]

Re: Expansions and comparisons.

 

I've absolutely no interest in these, other than to see the boundaries of what is 8 bit classic gaming pushed forward.

 

If 320K of RAM gets us some new title that feels Atari like, I'm there for that. If we can put a CPU in a cart and do the same thing, all good.

 

If that beats up on a C64? well... Go expand one of those and we can all game on, and debate how each machine lends itself to these kinds of activities.

[TMR]

I take your point about unfair comparisions utilising any type of expansion although there's a big difference in addition ram and a cpu upgrade.

 

It's still an advantage and the point is where to stop, if you allow one kind of expansion (and fitting a RAM expansion to an A8 is fairly major internal surgery from what i understand, the SuperCPU just plugs into the C64 cartridge port) what disallows another? And although we don't currently have any examples (well, i do but they're nowhere near finished yet) you'd be surprised just how much difference a RAM expansion makes to things on the C64... =-)

 

The Ram-Expansion thing I'm torn with.. I'd like to do 64 stuff using it, but you know it's not going to get run on a real 64 with REU in 99.9% of the cases so what's the point.. I might as well write it on a PC.. I think the REU could enable some blindingly good things on the 64, but what's the point if it's just going to be run on emulators..

 

Well, i don't know what the take-up is on expanded machines in the A8 camp but i know i can't play those games on my unexpanded 800XL so it's the same boat; the 1541 Ultimate can emulate an REU expansion as well, so there's at least a few more people out there who could play a game supporting it.

 

But it's nice to know that driller is finally playable on something

 

It's not officially modified, so a bit fiddly to play; the movement of the cursor isn't synchronised to the raster and goes way too fast!

Edited September 16, 2009 by TMR

[TMR]

If that beats up on a C64? well... Go expand one of those and we can all game on, and debate how each machine lends itself to these kinds of activities.

 

That was my point, we already have... but if i tried to compare Metal Dust to something on the A8, what do you think the Atarians'd say? =-)

[Tezz]

Not that it makes any difference to the fact but I would like to point out that BJ isn't actually 320k, it requires a 320k expanded machine to run as it exceeded 256k (or the cart with ram onboard which runs on any stock machine). The loading pic is also included in the executable btw.

[TMR]

Not that it makes any difference to the fact but I would like to point out that BJ isn't actually 320k, it requires a 320k expanded machine to run as it exceeded 256k (or the cart with ram onboard which runs on any stock machine). The loading pic is also included in the executable btw.

 

Yeah, but the C64 version runs from 64K so it's still a major difference... if they'd had the option of a RAM expansion or even a multiload, it would've been able to look significantly better than it does and as Andy says the same goes for Space Harrier.

[andym00]

It's the 128 characters that become an issue i reckon (i've been thinking about this for a long time now!) For one soft sprite at 8x16 pixels you've got to reserve nine characters so eight sprites is going to leave just 56 - C64-sized sprites would need the entire font for eight! You can split the fonts of course, but that's like recycling C64 sprites with fixed splits and you'd end up with "zones" they can move within.

 

I guess it depends on your zone sizes, but I think it's manageable.. My first thought when confronted with 128 was how on earth can I manage it, but a bit of a sit down, and 12 character sets worth of memory later it'll work

In my case I'm using 2 line characters splits, and allocate 64 chars for static background objects, 32 for software sprites and 32 for character positioned non-background objects..

Given I'm running a big player multiplexer I'm only interested in providing enough coverage for the players, so that means in each zone a maximum of 24 characters gone anyway in the worst case, which is manageable.. I'm going to stretch it to 4 lines when I've got time and see how bad it gets and if 32 chars will provide enough for 4 lines, or if it needs some rethinking..

At least that's how it is.. I'm loathe to let the players flicker and have the software sprites lose their overlays/underlays so I, for now, just let the software sprites flicker as well to match the player.. But it's early days and maybe all the magic numbers of character set allocations get changed

 

But even with 56 characters left, that's still a bucket load of characters to build a screen out of, if you've got zones of character set splits..

I only want as many as 64 per 2 (maybe going to 3 or 4) lines because I want to compose the screen not from blocks or tiles but from 'sprites' that are blitted into the background, if you see what I mean ?

[Tezz]

I take your point about unfair comparisions utilising any type of expansion although there's a big difference in addition ram and a cpu upgrade.

 

It's still an advantage and the point is where to stop, if you allow one kind of expansion (and fitting a RAM expansion to an A8 is fairly major internal surgery from what i understand, the SuperCPU just plugs into the C64 cartridge port) what disallows another? And although we don't currently have any examples (well, i do but they're nowhere near finished yet) you'd be surprised just how much difference a RAM expansion makes to things on the C64... =-)

Yes I agree that's true and valid that any expansion is an expansion. It's just that I see a cpu upgrade as a change to the machines architecture whereas I see ram as a simple expansion.

[Tezz]

Yeah, but the C64 version runs from 64K so it's still a major difference... if they'd had the option of a RAM expansion or even a multiload, it would've been able to look significantly better than it does and as Andy says the same goes for Space Harrier.

True yes. I wanted to use a player multiplex so not to have the masses of preshifted soft sprite data which is the reason behind that but I wasn't the only one in the team. also dropped were the sprites I drew based on the Arcade original, as the two projects joined Vega wanted to keep the c64 sprites from the port he was working on as he liked them. Edited September 17, 2009 by Tezz

[andym00]

The thing is, a VCS will always be a VCS. The challenges of programming the machine are not diminished with the addition of some hardware assist, and the overall graphics capabilities don't change either. It's arguably just more available with some assist than not. This was said about large ROM sizes too.

 

I've no problem with ROM sizes on the consoles, it's the normal thing isn't it.. I mean NeoGeo took it to extremes, but I have no problem with, say, a 512K 2600 game at all, or even with a little bit of assist like Pitfall-2, though I realise I'm digging a hole for myself by saying PF2 is fine doing this.. But something about that and David Crane doing that for that one game to provide the features he wanted that's actually faintly romantic, in a peculiar kind of way Or maybe it's just me as a programmer..

 

If it were possible to just load / store and have the extra chip basically paint out a 160x200 screen with full color, or a lot of colors, I think that would not be so good. But, I don't think we are going there really. I don't even know if that's practical.

 

We shall see I guess But since the ARM is controlling everything come over the bus, I just picture the scenario where the CPU is executing nothing but STAs being delivered by the cart thus allowing it a fairly direct access to the hardware via the 6502.. That's the bit that makes me nervous about where it'll end up..

Anyway, we shall see I guess

 

Where the project is going is just one notch better games, like what has happened fairly consistently over a lot of years. That's all good from where I stand. As the game improvements have occurred, starting with bank select schemes, supercharger and things like SARA, the flavor was not lost. So long as people can point to the finished work and say, "Hey, that's the VCS!" there won't be any significant worries.

 

I hope so

 

On a hardware / software technical accomplishment note. Batari has simply kicked some ass. Give him some credit. With Batari Basic and this Harmony deal, he's contributed a ton of both potential and real works for users of a very old and fun machine.

 

Absolutely, and I wasn't taking anything away from him with that, Harmony is great cart to have out there to enable more homebrew stuff on the real thing especially in the absence of any good carts of this kind of thing, and of course I'll be having one of them, but I guess my CuttleCart won't be seeing much more action after I get hold of one

Edited September 17, 2009 by andym00

[TMR]

Yes I agree that's true and valid that any expansion is an expansion. It's just that I see a cpu upgrade as a change to the machines architecture whereas I see ram as a simple expansion.

 

Not the way Commodore did it; you also get a DMA capable of shifting stuff into or out of the base 64K at a byte per cycle - remember that speed advantage the A8 has over the C64? For most practical uses, suddenly it doesn't...

[TMR]

I guess it depends on your zone sizes, but I think it's manageable.. My first thought when confronted with 128 was how on earth can I manage it, but a bit of a sit down, and 12 character sets worth of memory later it'll work

In my case I'm using 2 line characters splits, and allocate 64 chars for static background objects, 32 for software sprites and 32 for character positioned non-background objects..

 

Thing is, that's a significant overhead (15K for a single buffer if you add up the player RAM, screen RAM and twelve fonts) so for a fully double buffered display you've got half a 64K machine eaten! Doesn't leave a lot of room for the pre-shifts the soft sprites'll need, level data, wave data or whatever...

 

Tell you what though, since i've just thinking about this i might've just come up with a variation on the theme that'll work for what i want to do... but i'm going to keep it to myself until i can actually test the thing properly because something is nagging me and saying "not enough CPU grunt"...

 

I only want as many as 64 per 2 (maybe going to 3 or 4) lines because I want to compose the screen not from blocks or tiles but from 'sprites' that are blitted into the background, if you see what I mean ?

 

Yes i see what you mean, sort of like how Last Ninja does it really...

[emkay]

 

 

It's still an advantage and the point is where to stop, if you allow one kind of expansion (and fitting a RAM expansion to an A8 is fairly major internal surgery from what i understand, the SuperCPU just plugs into the C64 cartridge port) what disallows another? And although we don't currently have any examples (well, i do but they're nowhere near finished yet) you'd be surprised just how much difference a RAM expansion makes to things on the C64... =-)

 

 

Not much, I guess. You will get faster moving objects on the screen and cleaner digitized sounds.

And, well, on the Atari you don't need to put the soldering iron on, if you want to have more RAM and/or a faster CPU working.

 

RAM expansions are not really hardware expansions. There never was a 64K era

 

And, what to say, If the C64 league allows fast CPUs, C64 will lose again.

Imagine, what's possible, and what have been done already.

With an external bankswitched RAM controller, you get infinite transfer speeds.

With an external CPU you can write directly to GTIA registers, resulting in a real 128 colour mode with a full screen of multicolour PM ...

and so on...

[emkay]

Yeah, but the C64 version runs from 64K so it's still a major difference... if they'd had the option of a RAM expansion or even a multiload, it would've been able to look significantly better than it does and as Andy says the same goes for Space Harrier.

True yes. I wanted to use a player multiplex so not to have the masses of preshifted soft sprite data which is the reason behind that but I wasn't the only one in the team. also dropped were the sprites I drew based on the Arcade original, as the two projects joined Vega wanted to keep the c64 sprites from the port he was working on as he liked them.

 

 

Depending on the used techniques, Space Harrier on the C64 will not get faster with more RAM, but you surely can do more animations on the screen, and the level can get more complex.

Same with the Atari version: If you use simple shapes and simple levels, you can save memory, but the game does not get slower. Vice Versa. If using the charmode movement as used in most "3d" games on the C64, you don't need any pre-shifting, and movement gets faster, because the movement resolution gets down to 40x25. Space Harrier is using the movement resolution of 160x100, which needs a faster CPU by default.

[atariksi]

You can mix the sprites with GTIA modes for players and/or for GPRIOR mode 0 stuff. I guess someone else who has big library of games can give better answer as to which ones use GTIA. As far as being chunky-- it depends on image and you also have option to interleave two GR.9/10 screens to get 160 pixels across.

 

I'm interested to see GTIA stuff, especially with PRIOR0

But the GR9/10 thing.. That's the one the flickers and looks like a comb at the edge right ? Not so keen on that, but then again I hated all the flickering 'interlace' rubbish on the 64 anyway..

 

You can do PRIOR mode 0 in Graphics 10; in graphics 9/11, you get a translucent affect with missiles set as PF3 (doubling the number of colors) but the players cannot be set to OR with the graphics but they can still be used as normal players. Interlace is better on Atari with Gr.9/10 if you want to increase shading or for anti-aliasing, but for colors with big deltas they flicker like C64. There's no comb at the edge if you go overscan.

[Allas]

You can mix the sprites with GTIA modes for players and/or for GPRIOR mode 0 stuff. I guess someone else who has big library of games can give better answer as to which ones use GTIA. As far as being chunky-- it depends on image and you also have option to interleave two GR.9/10 screens to get 160 pixels across.

 

I'm interested to see GTIA stuff, especially with PRIOR0

But the GR9/10 thing.. That's the one the flickers and looks like a comb at the edge right ? Not so keen on that, but then again I hated all the flickering 'interlace' rubbish on the 64 anyway..

 

9/10 mode doesn't flicker afaik, not if "interleaving" and not "interlacing" just 10 I think is the one that weirdly draws a 1/2 colour clock off from the rest of the modes so you get offset pixels but then your vertical res goes to pot cuz of having one line of one mode and one line of another. It's also still insanely hard to do anything useful with as in writing a game. I just changed a bit of my code that does the 9/11 256 colour mode to do 9/10 but it's hard to see exactly what it's doing without graphics made for it. It does have that "comb" edge because of the pixels being offset but I suppose you could cover that up with a couple of missiles or just do overscan.

 

*edit* lol, good job I remembered to change that code back just else I'd have been scratching my head for a while tomorrow

 

Pete

 

 

sf4.zip

[atariksi]

There's a difference between DOING THE OPPOSITE OF THE ORIGINAL POSTER and doing things that are technical features of both machines. If someone tells you to get some milk and you go talk about cows and how they generate milk that's not as bad as force feeding him water.

 

If he's thirsty, giving him water is far better than discussing cows.

 

 

 

 

 

That's got to be a world first, a cow that plays (and programs) an atari

 

Perhaps if Atari under warners were as good at marketing the A8 series to software companies as well as the general market in the UK as they were in the US market the A8 would have had better support software wise

 

I think even you have to accept that Atari didn't get that right in the UK at least till tramiel took the reins, unfortunately the battle had already been lost with the 8Bit UK software market already been divvied up between commodore and sinclair because they did sometime atari didn't and courted the software houses, so Atari did the commodore/sinclair trick Hence why the ST got the software support where the 8bit didn't

 

It's amazing that despite all the problems and targetting 16K/CTIA, Atari did have great games better, faster, smoother than C64 games targetted for 64K.

CTIA also was for a fairly short period of time. GTIA was most of the life of the machine.

 

Yeah, CTIA was short-lived in machines but the softwares were targetting CTIA graphics modes not GTIA modes and low RAM useage as apparent since you can run most cartridges from 1970s and early 1980s in Atari 400 w/16K.

[atariksi]

Saying "better" is subjective anyway because it comes down to personal taste in games,...

 

WRONG again. You are speculating. Better can be used subjectively and objectively. Rest of rubbish deleted since your original point is invalid.

 

Well the problem here is your ambiguous use of the word "better" really; when talking about factors such as how games play (and most people would take the word "better" without further qualification to refer to that rather than anything else), which is better is always going to be informed by personal opinion and a subjective matter; that doesn't matter if you're a casual gamer or writing reviews. And we've pretty much proven over the last three hundred plus pages that it's not possible to objectively discuss which is the better game at a technical level too, for example there were people who preferred Zybex on the A8 despite it running at half the vertical resolution and at a pure technical level the 160x200 and the half pixel scrolling of the C64 version is better unless we start discussing subjective opinions of which colour schemes work best.

 

Now, about the other points you were trying to avoid...? =-)

 

I left out the "\quote".

 

S'okay, fixed that for you. =-)

 

I said the following: "It's amazing that despite all the problems and targetting 16K/CTIA, Atari did have great games better, faster, smoother than C64 games targetted for 64K." You have twisted it to claim it's not possible to objectively discuss which is the better game. There are games that are better on Atari despite the 16K/CTIA restrictions. I did not say ALL games. If a game does hardware-based scrolling, hardware-based collision detection, more colors, faster calculations, and/or overscanning vs. a game that's inferior in those aspects then that game can be said to be better than the other. Of course, there are games that are close calls so you can say subjectively-- "I like this better than the other" but don't generalize that no games can be objectively decided or that "better" is a subjective word.

 

Just played River-raid on Colecovision and A8 and clearly A8 is better (superior). Anyone who thinks "I like colecovision is better at river-raid" is making a subjective remark due to emotional attachment to his console.

 

I am not trying to avoid any points-- you are making absurd conclusions regarding the word "better" being subjective and that it's not possible to objectively decide any game is better.

[atariksi]

It's quite possible that interlacing the 2 IS what Atariksi meant. I've seen a lot of flickery A8 modes. I just know the 9/11 to get 256 colours doesn't so I'd think it's possible to do the same and have it offset by a pixel, although thinking about it it's not going to make a great deal of perceptual difference to resolution.

 

I keep dreaming of this 256 colour mode with PMGs overlaid in the OR mode but offset 2 pixels to get more res, or something lol, but afaik the ORing PRIOR 0 (low nibble) thing doesn't work in those modes (them not being playfields as such). At least from what I was reading on the Altirra blog it doesn't, I'm just bashing together a bit of code to test it. Even then, what would you do? offset some quad expanded PMGs by 2 pixels over the 4 pixel wide graphics beneath?

 

I'll wait for Atariksi to surface and provide more detail then

 

I like the idea of the 256 colour mode, but the res is so off-putting.. But even if PRIOR0 did work it'd look dead odd with parts of the screen being in ultra-lo-res and others being in lo-res.. I guess you could do some funky 3D stuff with it, using skewed players to bolt on the polygon edges or such like so it just smooths the edges that meet the actual raw background as opposed to edges onto other polygons..

 

I'm liking this 5th colour mode though.. It's surprising just how much difference that one extra colour makes, and also makes for more colourful software sprites with player underlays.. I thought it was going to be a right pain to work in that mode, but it actually works really well.. Though it's odd that you see so little evidence of it in A8 games out there.. I mean all the horizontal scrolly shooters thrown up in this thread seem to show absolutely no evidence of it at all, and a quick search doesn't seem to turn up much either.. But still, it's a great extension to have, even with only 128 characters..

 

I haven't played with the 256 color mode (made via PAL mixing) since I don't have any PAL machines, but you do get a resolution increase to 160 pixels (192 overscan) when you interlace the Gr.9 with Gr.10 and end up with 30 shades. You mininimze the flicker by plotting pixels as 5-bit shade values:

 

P(0..159) = 0..31 (clip to 0..29)

P(Gr10) = ((P>>2)<<1);

P(Gr9) = P-P(Gr10);

 

You can make it more complex by averaging consecutive pixels for each of the two buffers.

[andym00]

Thing is, that's a significant overhead (15K for a single buffer if you add up the player RAM, screen RAM and twelve fonts) so for a fully double buffered display you've got half a 64K machine eaten! Doesn't leave a lot of room for the pre-shifts the soft sprites'll need, level data, wave data or whatever...

 

True, but at least I don't have to have the sprites duplicated as I would on a c64 since I'd be bank switching doing the same thing, so realistically I just look at it as cost pretty much the same memory wise as if I was handling a double buffered bitmap on the 64.. It's not the end of the world by any means..

[andym00]

I haven't played with the 256 color mode (made via PAL mixing) since I don't have any PAL machines, but you do get a resolution increase to 160 pixels (192 overscan) when you interlace the Gr.9 with Gr.10 and end up with 30 shades. You mininimze the flicker by plotting pixels as 5-bit shade values:

 

P(0..159) = 0..31 (clip to 0..29)

P(Gr10) = ((P>>2)<<1);

P(Gr9) = P-P(Gr10);

 

You can make it more complex by averaging consecutive pixels for each of the two buffers.

 

Ah, so it's just PAL blending then.. Totally with you now.. Although I should have twigged that before..

 

Just for the record , here's an example of the C64 and PAL blended colours..

Note that I mean PAL blending.. Where different colours are put on alternating lines, not flicking between 2 screens and inducing a scanner like brain exploding flicker fit..

 

I don't think this has ever been posted here yet, and I think it's fair to set the record straight a bit since this is more representative of how a lot of games use the C64s palette and how useful this is on a real 64..

The "eye cancer inducing"© Emkay - Mayhem in Monsterland is a really erally good example of this, but unfortunately the screen shots are never from a real c64 on a TV, so you never get to witness the effect of this.. And the emulators mostly don't get the PAL emuation right, let alone the PAL blending, and even then least of all the whole odd/even order thing, which as you can see below makes a fair difference of the colours available..

 

That's a photo of a real tv by the way, blending 7 colours with 7 others in even/odd and odd/even order.. I just thought maybe it was good to throw that in after 335 pages and 8370 posts, mostly belittling the 64 for its palette..

 

And it also nicely demonstrates just how important the line order is when PAL blending, ie: whether odd or even order.. The top row is Blended colour 1, the bottom row is blended colour 2 and the middle 2 rows are those 2 colours blended, but in even/odd order and then odd/even order..

 

For the record those colours are

  6    2     4    12     5     3     7
  6/9  2/11  4/8  12/14  5/10  3/15  7/13
  9/6  11/2  8/4  14/12  10/5  15/3  13/7
  9    11    8    14     10    15    13

Edited September 17, 2009 by andym00

[andym00]

sf4.zip

 

Glad I hadn't had my breakfast before seeing that, otherwise I'd have been seeing it a for the second time

[andym00]

Bugger, can't attach images when you edit, but no matter..

And as an example of the poor emulator support.. WinVice 2.1 running exactly the same program as above.. Notice how the colours are the same, regardless of the odd/even order..

Edit: Oops, forgot that Vice doesn't capture the proper blended output anyway..

Edited September 17, 2009 by andym00

[andym00]

Right.. There's a proper vice capture.. With Pal emulation and capturing the final output..

Edited September 17, 2009 by andym00

[atariksi]

Right.. There's a proper vice capture..

 

I don't play with emulators but when searching for some C64 stuff, I came across a lot of "Pocket C64" stuff-- is that inferior to vice or based on the same?

[frenchman]

With the ever increasing cart 'capabilties' I expect we'll be seeing Starfox running on a 2600 this time next year...

 

 

How about 1984?

Edited September 17, 2009 by frenchman