Atari v Commodore

[Fröhn]

Problem is that atleast theoretically you have to provide those 5 refresh cycles per line. I believe 9 was chosen because A8 badlines have only 1, so 1+9 = 10 = 2*5.

 

Recognizing the lines with only 1 would be neccessary to detect the lines where 9 is needed which in turn is required to detect the lines where only 5 would be needed, not 9.

[atariksi]

INC/DEC also use the bus every cycle. You can easily prove it by INC $D01A

 

Instruction, addr l, addr h, read memory, write back, write back new value. Since reading $D01A should return $0F an INC $D01A instruction will give a brief colour change to Col=0 Lum=14 followed by Col=1 Lum=0

 

Not sure about the implied set - I was of the impression that the 6502 just re-read the instruction byte on cycle 2. There's a document out there somewhere that properly describes what happens.

 

Inc/Dec zp has a cycle not using the bus. I guess Inc/Dec Abs may run into compatibility problems if you removed that extra write and forced tri-stating of the bus. But keeping the simple approach and avoiding complexity with LDA/STA, one can just decode instructions that have a free bus cycle available and use it for refresh. There's a huge implied set of instructions.

[atariksi]

No, in that situation it should simply figure the cycles are used. Likewise on cycles 3 and 4 of a branch instruction. Trying to exploit those particular cycles would require way too much effort to be worthwhile.

Oh great, it would know that it maybe could have used that cycle long after the cycle has been used. That's not really an improvement of not being able to use that cycle because you still are not able to use that cycle

 

You misunderstood. Supercat is right-- logic is simple if you only make cycles free for those instructions you are guaranteed to have bus on rather than complicate the circuit by conditional free cycles. As Supercat stated, you can know through simple logic when opcode is fetched. Depending on opcode, you can make a logic for a guaranteed free cycle for refresh without involving a complex circuit like another 6502. You don't have to get all the possible free cycles. A simple circuit that gets a few from Inc/Dec or implied instructions would fit the bill.

[Allas]

35 - MR. DO !

 

Atari screenshots

 

There is no doubt where you want to mix colors, graphics, sound and motion on one game, Atari is the best system to work, not easy, but the results worth the wait. Atari version was programmed using hardware sprites and software sprites, good set of colors on screen, nice arcade music, intermediate screen. In brief the best version, only comparable to the NES counterpart.

 

C64 screenshots

[potatohead]

Anybody know what happens when that cycle is denied to Antic?

 

Is there snow on the screen, blank line, object pixel extended? Nothing?

[ijor]

You misunderstood. Supercat is right-- logic is simple if you only make cycles free for those instructions you are guaranteed to have bus on rather than complicate the circuit by conditional free cycles. As Supercat stated, you can know through simple logic when opcode is fetched. Depending on opcode, you can make a logic for a guaranteed free cycle for refresh without involving a complex circuit like another 6502. You don't have to get all the possible free cycles. A simple circuit that gets a few from Inc/Dec or implied instructions would fit the bill.

 

IMHO, this doesn't make any sense.

 

The logic required to implement this (even just for the simple cases that unconditionally have a dummy cycle) is not simple at all, and the task is not a minor one.

 

If you were going to implement something like this, it would be much better and simpler to use static ram instead of DRAM. Then avoiding the need of refresh cycles alltogether. And while you change to SRAM, you could easily make it work at twice the system clock. Then you could interleave Antic and CPU bus mastering, recovering not just refresh cycles, but all the DMA cycles as well.

 

In either case you need much more than just minor simple logic. More than Bob's brilliant XL7 design (which is simpler and more powerful at the same time).

[Goochman]

35 - MR. DO !

 

Atari screenshots

 

There is no doubt where you want to mix colors, graphics, sound and motion on one game, Atari is the best system to work, not easy, but the results worth the wait. Atari version was programmed using hardware sprites and software sprites, good set of colors on screen, nice arcade music, intermediate screen. In brief the best version, only comparable to the NES counterpart.

 

 

C64 screenshots

 

Mr. Do is awesome on the Atari - I only wish other authors put as much time and effort into the little things like this one........................Dig Dug should've been almost arcade perfect

[Tezz]

Yea Mr Do was really well done. I thought it was a really excellent conversion back in the eighties. very close to the original. Was it really a 1984 release as listed in AtariMania? hmm I thought it was earlier than that.

[peteym5]

POKEY with 4 voices, different frequency bases, distortion controls, and volume only mode exceeds what that SID chip can do.

You sure?

 

 

Half those C64 games I tried out reminds me of my Basic programming days when I am first starting out. In my opinion, the Atari 8bit can run games better than any of the Commodore 8bit line.

Congratulations, you just discovered the "95% of <insert_anything_here> is crap" phenomenon. Same applies for A8 games btw

 

You know a good example to compare the sound capabilities of both machine is Boulder Dash. Both look almost identical on either machine, but the Atari version just sounds much better because of all the different things going on with POKEY. Plus I think most of the Atari games play better because of the higher clock speed. I admit they had some fun game ports on the C64, and had a few that were never ported over to the Atari. But I can see where it has issues with the limited clock speed and hear only having 3 sound voices.

[Fröhn]

You know a good example to compare the sound capabilities of both machine is Boulder Dash.

No it is not. It's an example of "almost no sound at all".

 

Both look almost identical on either machine, but the Atari version just sounds much better because of all the different things going on with POKEY.

Proves nothing. It is just a 1:1 port from A8 to C64, it doesn't use the C64 sprite hardware at all (and that's the primary feature of the C64), it hardly uses the C64 sound hardware etc etc. It's a very bad example for showing C64 hardware capabilities. If you want to see C64 capabilities, better go for games like IO, Armalyte, Turrican 2, Mayhem in Monsterland, Flimbos Quest etc etc.

 

Plus I think most of the Atari games play better because of the higher clock speed. I admit they had some fun game ports on the C64, and had a few that were never ported over to the Atari.

You should stop to look at ports. Ports are usually played best on their original platform. If you want to see what a platform can do, check out the games which have developed for that platform. Famous names on one platform often mean nothing on another.

 

But I can see where it has issues with the limited clock speed and hear only having 3 sound voices.

The CPU speed is not that different. On a normal 160x200 resolution it is a difference of 20%. And then the faster CPU often has to compensate the lack of good sprites. Just look at games like Draconus or Zybex: On C64 they run smoothly in full 160x200 resolution. On Atari the resolution is half of that (160x100), the sprites are smaller, there are less of them and they need to share the 4 colors of the background graphics. Ofcourse there are examples like the Lucasfilm games where the low resolution modes and the faster CPU pays out for the A8, but most of the 2D sprite-based games are much easier to do on C64.

[ijor]

Anybody know what happens when that cycle is denied to Antic?

Is there snow on the screen, blank line, object pixel extended? Nothing?

 

From Antic's point of view, you can't "deny" him a cycle. Antic will always perform a DMA cycle when it thinks it should. All you can do is to "put yourself" between Antic and the rest of the system, in such a way that the stolen cycle would not reach the system. But Antic would still "think" that the DMA cycle was performed, and it would grab whatever is present in its data pins (being real data, dummy data, or just noise).

[emkay]

The CPU speed is not that different. On a normal 160x200 resolution it is a difference of 20%. And then the faster CPU often has to compensate the lack of good sprites. Just look at games like Draconus or Zybex: On C64 they run smoothly in full 160x200 resolution. On Atari the resolution is half of that (160x100), the sprites are smaller, there are less of them and they need to share the 4 colors of the background graphics. Ofcourse there are examples like the Lucasfilm games where the low resolution modes and the faster CPU pays out for the A8, but most of the 2D sprite-based games are much easier to do on C64.

 

Particular Zybex is a worse example.... for both platforms. While on the Atari the game with this limited amount of moving objects easily could have been done at 160x200, the C64 version uses ugly charmovement for the shots, to save CPU cycles aswell.

 

Really, except the nice music of the game, it is a bad game at all.

[Fröhn]

Particular Zybex is a worse example.... for both platforms. While on the Atari the game with this limited amount of moving objects easily could have been done at 160x200, the C64 version uses ugly charmovement for the shots, to save CPU cycles aswell.

Charmovement for shots is common for many games. Dropzone does it too.

[potatohead]

Thanks. That makes perfect sense, and I suppose that's what I was really saying. Antic is gonna do what it does, period. Probably noise would result then.

 

Re: Sound. At this moment in time, SID does better tunes. IMHO, general game sounds are a wash, and having more channels (up to 5) is an advantage for just relating audio to game events. And if the Apple ][ can get some sound done while blitting to the screen, the Atari can as well. Just have to be careful about the sounds. (And that makes the 5th channel, reserved for the little key click useful)

 

Boulderdash, and Rally Speedway use the nice scrolling. Rally is one of the really fun games. I think John Anderson wrote that one. Played the hell out of that one back in the day. IMHO, that's a great A8 strength. If you go with the 160x96, you can have really big maps, with the sprite objects being used all over the place. That combination is just begging for a UFO type game, with a background map, maybe an active one! It would be totally fast, furious, loud and colorful!! Classic A8.

 

Re: CPU 20 percent, if true and I just don't want to hash that, is a lot! 2d sprite games are easier, until you push it, then I think it's a wash as well. One system does this, another does that, and the game environment generally falls around that. I like Atari centric game environments more than I do C64 ones in general.

 

Agreed roughly with peteym5 on these points.

 

My fave about the machines remains the systems engineering. The BIOS is cool, with lots of firsts. OSS did a great job with the resources they had. For what it's worth, I like the Apple ][ for the same reasons. Nice, sensible ROM BIOS code that does the stuff it needs to do, and does it well. I really like the basic too. It had a decent set of features for it's time. Easy to write in, and not Microsoftish... That counts for a lot. Yeah, I know it's shallow, but it just is what it is with me.

 

That has always been a C64 weak spot for me. Of course, everything can be done. Don't get me wrong there. It just seems a bit more of a hack at times, and things like the device independent I/O, just are not there, out of the box.

 

Total benchmarks for me are 3D rendering and emulation. Atari seems to just cross the threshold on these a bit farther than C64 does, and that makes it more powerful. Better? Well, we all like the stuff we like, don't we?

Edited December 24, 2008 by potatohead

[Fröhn]

If you go with the 160x96, you can have really big maps, with the sprite objects being used all over the place. That combination is just begging for a UFO type game, with a background map, maybe an active one! It would be totally fast, furious, loud and colorful!! Classic A8.

You don't need to reduce the resolution for bigger maps. Game maps are usually made from tiles.

 

That has always been a C64 weak spot for me. Of course, everything can be done. Don't get me wrong there. It just seems a bit more of a hack at times, and things like the device independent I/O, just are not there, out of the box.

Ofcourse the IO was device independent. Every device carried it own driver.

[potatohead]

If you have a given amount of RAM memory, and want to make really good use of the Atari graphics hardware and CPU, 160x96 is very tough to beat.

 

Double scan lines delivers lots of time for sprite tricks, the larger character cell can mean fast, low CPU demand scrolling, and 5 colors right there. Do it in wide DMA, and completely use the NTSC frame, for the no borders at all look. The wide DMA will eat up a bit more, but double scan-lines leaves plenty of doors open.

 

Somebody probably could work out a scanline based sprite multiplexer, to cut the effects of full on flicker on an object basis too. Done that way, a portion of each object would be visible at all times. On newer sets, this might even be processed out!

 

Tiles need to be written to bitmap memory somewhere. Characters don't need this, and that leaves a lot of CPU left for other tricks.

 

Anyway, getting back to the given amount of RAM, running at one of the lower native resolutions frees up system memory that could go to bigger maps. If the game is effect tight, this option will deliver a bigger map than doubling things up would.

 

All depends on the kind of map, and the intent behind the game doesn't it? Tiles -vs- Chars generally means CPU speed bonuses to be leveraged elsewhere. That's why the option is there on the Atari in the first place.

 

Go load up Rally Speedway sometime. It's an awesome scroller, running about like I described. Really shows off the A8 stuff nicely, IMHO.

 

Resolution just isn't everything.

[potatohead]

If you go with the 160x96, you can have really big maps, with the sprite objects being used all over the place. That combination is just begging for a UFO type game, with a background map, maybe an active one! It would be totally fast, furious, loud and colorful!! Classic A8.

You don't need to reduce the resolution for bigger maps. Game maps are usually made from tiles.

 

That has always been a C64 weak spot for me. Of course, everything can be done. Don't get me wrong there. It just seems a bit more of a hack at times, and things like the device independent I/O, just are not there, out of the box.

Ofcourse the IO was device independent. Every device carried it own driver.

 

Sure. But you could easily write code to leverage the I/O routines already in the machine. Just list your device, and it can behave like other devices. Or new devices could be created that would operate with older code. It's a cool setup for 8K. You get output redirection and a common interface for devices, in the box, ready to use.

[Fröhn]

If you have a given amount of RAM memory, and want to make really good use of the Atari graphics hardware and CPU, 160x96 is very tough to beat.

I still don't see why lowering resolution would reduce any memory usage. Character set stays same size, and screen memory is very little anyway.

 

Double scan lines delivers lots of time for sprite tricks, the larger character cell can mean fast, low CPU demand scrolling, and 5 colors right there.

Scrolling is hardly a problem on A8.

 

Tiles need to be written to bitmap memory somewhere. Characters don't need this, and that leaves a lot of CPU left for other tricks.

Tiles and characters don't exclude each other. Turrican on C64 uses tiles made from 4x4 characters for example. Most tile based games I know use character mode.

 

Anyway, getting back to the given amount of RAM, running at one of the lower native resolutions frees up system memory that could go to bigger maps. If the game is effect tight, this option will deliver a bigger map than doubling things up would.

Saving 500 bytes is not worth the low resolution.

 

Go load up Rally Speedway sometime. It's an awesome scroller, running about like I described. Really shows off the A8 stuff nicely, IMHO.

Rally Speedway is pretty much the same on C64 and A8. Also, it uses character mode and huge tiles too. I think the tiles are 16x16 characters big.

 

EDIT: Looked at it again, Rally Speedway uses 160x100 resolution on A8 and 160x200 on C64. So it's not the same.

 

Resolution just isn't everything.

If there's no real reason to lower it, why do it?

Edited December 25, 2008 by Fröhn

[potatohead]

So then we are talking about char mode then.

 

When I hear somebody say "tiles", that's a different thing where retro computing is concerned.

 

There is a feel to each resolution that has it's qualities. So, in terms of the look of the thing, having that choice available is part of the game art.

 

And, since a whole lot of this discussion has been about this trick or that, why not open the door for ALL the tricks?

[Fröhn]

So then we are talking about char mode then.

 

When I hear somebody say "tiles", that's a different thing where retro computing is concerned.

No I am talking about tiles made from several chars.

[+Stephen]

POKEY with 4 voices, different frequency bases, distortion controls, and volume only mode exceeds what that SID chip can do.

You sure?

 

 

Those 2 examples are amazing! I love my Atari, but no way in hell could PoKey do either of those. I really don't care about the sprite differences, but I really do miss a hi-res color mode for no other reason than wanting a color 80-column ANSI terminal. Ice-T XE is great, but it's mono.

 

Stephen Anderson

[potatohead]

So then we are talking about char mode then.

 

When I hear somebody say "tiles", that's a different thing where retro computing is concerned.

No I am talking about tiles made from several chars.

 

I understood that, after your other post. That's why I posted, "so we are talking char mode then."

 

Given that's it's a character mode then, having several sizes of characters is an advantage in terms of the kinds of screen layouts, screen memory required, and overall map size / CRT screen coverage achieved.

 

On the A8, if you want full-over scan scrollers, you can do that at a variety of resolutions, and depending on which one you choose, you then open the door for other tricks running at the same time, or detail, or in some cases both!

 

YOOMP! Runs at the lower resolution. I like it! It's immersive, looks totally retro, runs fast, etc... That's a bitmap game, of course, but it clearly shows the game art aspect different resolutions bring to the table.

 

I happen to like the double scan line resolutions. Objects are big, bold, can move fast, etc...

 

One example would be NOT having to combine a bunch of chars, or fewer of them to produce an image. Simple screen size, per memory bit spent, is just a more modest equation with the lower resolution. Sprites could run higher too, to mix it up a bit.

 

Another thing I generally like with scrollers is full over scan. It's kind of nice to just have the WHOLE screen doing something. While not always possible, for a lot of reasons, it's great when it is.

Edited December 25, 2008 by potatohead

[potatohead]

Great SID Tune links, BTW!

[Fröhn]

Given that's it's a character mode then, having several sizes of characters is an advantage in terms of the kinds of screen layouts, screen memory required, and overall map size / CRT screen coverage achieved.

Larger map sizes can easily be achieved by larger tile sizes. No need to reduce resolution because of that. The screen memory also isn't an issue because it's quite small even in the highest resolution.

 

YOOMP! Runs at the lower resolution. I like it! It's immersive, looks totally retro, runs fast, etc... That's a bitmap game, of course, but it clearly shows the game art aspect different resolutions bring to the table.

For Yoomp the lower resolution makes sense because it gains framerate and saves bitmap memory. But those reasons do not apply on scrolling games.

[peteym5]

I understood that, after your other post. That's why I posted, "so we are talking char mode then."

 

Given that's it's a character mode then, having several sizes of characters is an advantage in terms of the kinds of screen layouts, screen memory required, and overall map size / CRT screen coverage achieved.

 

On the A8, if you want full-over scan scrollers, you can do that at a variety of resolutions, and depending on which one you choose, you then open the door for other tricks running at the same time, or detail, or in some cases both!

 

YOOMP! Runs at the lower resolution. I like it! It's immersive, looks totally retro, runs fast, etc... That's a bitmap game, of course, but it clearly shows the game art aspect different resolutions bring to the table.

 

I happen to like the double scan line resolutions. Objects are big, bold, can move fast, etc...

 

One example would be NOT having to combine a bunch of chars, or fewer of them to produce an image. Simple screen size, per memory bit spent, is just a more modest equation with the lower resolution. Sprites could run higher too, to mix it up a bit.

 

Another thing I generally like with scrollers is full over scan. It's kind of nice to just have the WHOLE screen doing something. While not always possible, for a lot of reasons, it's great when it is.

 

I think both computers are about equal on char mapped screens and combining characters for tile mapped screens, Like Boulder Dash. The Atari can handle Antic 4 mode with overscan and fullscreen height during its VBI, and still has tons of CPU cycles left to do animations. I agree it does not take full advantage of the C64 sprites, but it doesn't use the Player/Missile graphics as well. Nor does it use the C64's color maps, nor does the Ataris' use DLIs. Either could apply more screen colors to either version. I agree Yoomp is not at all using character mapped screen.

 

If we are talking screen size. You can take an Atari with extended memory and do 256x256 characters just on a 128k machine. Limited size is only what is available through expanded memory. I am working on a side scroller type game and making use of DLIs for many colors and sprites. In early pre-alpha stage got it over 30 onscreen colors.