Atari Vs C64 --- 80s Computer scene etc chat...

[frogstar_robot]

hires+16 colors comes with a price: no 128 color palette.c)

128 colors comes with a price: with no tricks you can only display 16 colors of the same shade, or 16 shades of the same color, in very lowres. (iirc)

 

its just a different compromise of the technique present at the day. you choose which do u prefer.

 

Slightly lower resolution seems a small price to pay for 8 times the color depth. Color is no less a figure of merit in detail than raw resolution.

 

what do you call a DMA ? C64's gfx chip uses quite a few hardwired different "direct memory acces" types for sprites, char data, etc, for which it stops the cpu, when its time to read the mem.

 

The video hardware can directly access any portion of the memory map just by flicking a pointer around and that can be done quickly enough to make some interesting things possible. What I call "DMA" is exactly that: direct access to any part of the memory map by the video hardware.

 

Less common and probably a lot harder to do are effects like the Rubik's Cube that solves itself in Numen

 

c64 is almost twice as slow as atari in that gfxmode. run numen at 50% speed in the emu and check that fx again, and you'll know why c64 demos dont do that often . its simply slow. however there are a few demos which do complicated 3d stuff going as far as phong shading with texturing at the same time. let me know if you want me to list them tho prolly you will need emu (most of them are not on youtube).

 

Sure. I have a recent version of VICE.

 

 

 

and what does that mean? I think the situation is quite similar: Both on Atari & c64 you usually start with coding your screenmode, when it comes to demos

 

It means that this machine was Jay Miner architecture like the first Amiga chipset. What you have is a scanline video generator whose operation can be changed at every scanline or some useful multiple of scanlines. This means there is hardware assist for switching palletes and hardware video mode at any arbitrary vertical point onscreen. Some of the best Atari effects don't mean just setting a screenmode and drawing on it. Things like HIP and TIP make software graphics modes possible. The entire color pallete can be put onscreen at once. It is possible to exploit bugs in the ANTIC/GTIA chipset and do limited mixing of modes in vertically as well. Basically, the Atari video hardware wasn't a dumb pixel buffer. It was a combination of a dumb scanline generator controlled by a simple video coprocessor.

 

dont think so, c64 was designed in less than a year including the chips. you can do whatever tho with the usage of the 'cartridge' port, as all important lines are routed out. guess its the same on a8.

 

Unfortunately that isn't true. Only with the addition of the PBI port were most important lines brought out. Still, many mods require getting inside the unit proper and there are very few items that utilize the PBI port.

[atarian63]

I guess their 80-column mode gave the C64/128s some edge over Atari;

The C64 had no 80 column mode.

 

IMO it were the "free" games which made the C64 that successful. Many people I knew back than already had a C64 and the supply of new games newer stopped. That's why I decided for the C64.

I have a retail business and we were selling both back in the day. You are right, it was the old "my brother got one" mentality. Piracy was sooo huge. Not to mention the C64 defect rate. Abysmal. It doesn't have to be the best, just good enough or as in this case an easy way to get stuff for free. We sold both, we preferred the Atari.However we had alot of nice folks that bought C64 then later 128 128D etc. We had many of each setup and the demos and counter demos on each platform supplied by customers raged each day. Heck even the staff participated. We did not sell apple at all. Never really had many customers ask for it back then.

Were you here here in the states when you bought your C64?

[atarian63]

I guess their 80-column mode gave the C64/128s some edge over Atari;

The C64 had no 80 column mode.

 

IMO it were the "free" games which made the C64 that successful. Many people I knew back than already had a C64 and the supply of new games newer stopped. That's why I decided for the C64.

I have a retail business and we were selling both back in the day. You are right, it was the old "my brother got one" mentality. Piracy was sooo huge. Not to mention the C64 defect rate. Abysmal. It doesn't have to be the best, just good enough or as in this case an easy way to get stuff for free. We sold both, we preferred the Atari.However we had alot of nice folks that bought C64 then later 128 128D etc. We had many of each setup(Atari and Commodore) and the demos and counter demos on each platform supplied by customers raged each day. Heck even the staff participated. We did not sell apple at all. Never really had many customers ask for it back then.

Were you here here in the states when you bought your C64?

Edited April 21, 2008 by atarian63

[atariksi]

I am not familiar with Ghostbusters but from the hardware perspective, I can see clearly Atari can simulate more sprites equivalent to it's built-in hardware sprites.

By using interrupts, you could reuse sprites in the C64 too.

 

...and play digitized samples >10Khz.

And how is the C64 limited here?

 

Yes, C64/128 has better text mode (whether 40 or 80 column) since it has a separate color memory area, but limited colors and sub-par pixel quality does not render it justice.

Actually, the text mode was most frequently used C64 for games. Combined with the hardware soft scrolling registers, the CPU could pretty easily soft scroll a whole screen.

 

What do you mean with "sub-par pixel quality"?

 

The point about >10Khz and more sprites was to make a point that Atari can also generate more sprites if needed and good digitized audio if needed (4-bit or 5-bit/sample) not that it would limit the C64. Sub-par pixel quality is my experience of hooking up and viewing both the C64 and Atari 400/800/XL/XE systems to the same composite monitor using the same color scheme (it's an Amiga monitor). The video looks better on Atari due to better saturation of colors or other issues.

 

As far as re-useability of sprites, again the same point can be made that because of Atari's faster CPU, more accurate timer, DLI, etc. you can re-use them even on the same scan-line. I need to know what divisor you used for the CIA timer of 1.022730Mhz to get your interrupts to re-use the sprite?

[atariksi]

I wasn't exaggerating-- just taking it as it is. It may be easier to program sprites on the C64/128 but given the DLIs, more accurate timers, etc. you can generate more sprites on the Atari (like in Joust).

 

Erm... unless i'm missing something Joust isn't exactly busy - got a screenshot of it really going for it with the sprites?

 

It was a simple point-- I see more than 8 sprites with joust. They may just be using a VBI although there are better methods.

 

As far as colors discussed by others, if you start talking temporal dithering you can make a better argument for more colors for Atari since 256 colors interlaced/dithered give more combinations than 16 colors interlaced/dithered and you are dropping quality of the pixel. So it can be properly stated the C64 has 16 REAL colors and Atari has 256 REAL colors.

[Rybags]

You don't need CIA interrupts for sprite reuse. The C64 raster IRQ generated by VIC is the best way of going about it.

It's not as precise as on the Atari due to lack of a WSYNC function, but wait loops and other tricks make it nearly so.

 

The Atari has a slight advantage and disadvantage re digitized sound. Extra processor speed and a simpler process of setting the amplitude level, vs lower speed and (I guess the most common method) using the pulse wave and varying the Sustain level on the C-64.

 

But the C-64 gains on the front that less DMA means that digi-sound routines don't have their timing so adversely affected.

 

Although, we know these days that on the A8 the best methods of digital sound involve timer IRQs or storing samples based on a VCOUNT wait loop.

[Heaven/TQA]

Re Joust

 

Joust uses 3 (haven't here the screenshot) players for the enemies which get multiplexed by DLIs. It is one of the few games which use ring buffer method (--> flicker when more than 4 hardware sprites per one scanline). so in total i haven't seen more than 8 per screen? even on higher levels?

the lance are the missles multiplexed.

 

the eggs are software sprites as the game uses Antic E (160x192x3).

 

so not much trickery here but i love the multiplexor... as i went into the Joust one years ago when playing around with multiplexor.

 

and as coder believe me... atari players are slowing down game engine just because you have to erase and draw the sprite data every time you move vertical and with multiplexing it gets even more cpu consuming... while the c64 you simple do lda x,sta x,lda y sta y... and that's it... and you have 8 of 12x21x3 sprites, each of them with different colour set (similar like the 7800), and even not multiplexed them...

[TMR]

I wasn't exaggerating-- just taking it as it is. It may be easier to program sprites on the C64/128 but given the DLIs, more accurate timers, etc. you can generate more sprites on the Atari (like in Joust).

 

Erm... unless i'm missing something Joust isn't exactly busy - got a screenshot of it really going for it with the sprites?

 

It was a simple point-- I see more than 8 sprites with joust. They may just be using a VBI although there are better methods.

 

More than eight sprites doesn't really prove much; eight on a scanline is the C64's upper limit and even some of the earlier games use over twice that number in total; if we remember there's a learning curve for any machine and that Joust was released in 1983, some four years after the Atari itself was first put out, shuffling forward that same four years after the C64 was released finds games like Delta using over fifty sprites on the C64 (if it's not a star or bullet in Delta it's a hardware sprite) and Chris Butler's conversion of Commando was already out by that point and that's at least a 16 sprite sorting multiplex akin to what Heaven says is in Joust. It's easier to not only program sprites on the C64 but to recycle them, as Heaven points out the changing of a sprite definition is one LDA and one STA rather than a complete clear/redraw cycle.

[Oswald]

Slightly lower resolution seems a small price to pay for 8 times the color depth. Color is no less a figure of merit in detail than raw resolution.

 

thats not exactly 8 times the color depth, but 8 times the palette. in stock modes you have the same 16 colordepth (out of 128) , but in 4 times smaller resolution.

 

 

The video hardware can directly access any portion of the memory map just by flicking a pointer around and that can be done quickly enough to make some interesting things possible. What I call "DMA" is exactly that: direct access to any part of the memory map by the video hardware.

 

this is DMA: http://en.wikipedia.org/wiki/Direct_memory_access. c64 and atari both uses it.

 

 

This means there is hardware assist for switching palletes and hardware video mode at any arbitrary vertical point onscreen.

 

nice stuff indeed, but I think c64 used the better compromise: doing sprites is much harder with the cpu, so the video HW supports sprites extensively, and lets the easyer per line regchange job done by the cpu. unless it comes to demos you only want to change screenmode / palettes just a few times on a screen.

 

here is the demolist, all of them do their thing in realtime:

 

phong/gouraud:

http://noname.c64.org/csdb/release/?id=3394

 

phonged texture:

http://noname.c64.org/csdb/release/?id=36663

 

gouraud in pixel res, wolfenstein clone:

http://noname.c64.org/csdb/release/?id=11692

 

shading&texturing porn:

http://noname.c64.org/csdb/release/?id=4605

 

2x2x16 textured cube at the end:

http://noname.c64.org/csdb/release/?id=3585

 

aged coderporn:

http://noname.c64.org/csdb/release/?id=4762

 

phong torus&texturing:

http://noname.c64.org/csdb/release/?id=4761

 

gourad, texturing etc in pixel res:

http://noname.c64.org/csdb/release/?id=4019

 

best filledvectorshow up to date:

http://noname.c64.org/csdb/release/?id=11610

 

one of the very rare programs doing a whole 3d world:

http://www.ffd2.com/fridge/lib3d/coolworld.zip

[Bryan]

The video hardware can directly access any portion of the memory map just by flicking a pointer around and that can be done quickly enough to make some interesting things possible. What I call "DMA" is exactly that: direct access to any part of the memory map by the video hardware.

 

this is DMA: http://en.wikipedia.org/wiki/Direct_memory_access. c64 and atari both uses it.

 

 

I was going to address that too. DMA simply means chips other than the CPU can read from memory. For example, the 2600 doesn't have DMA so your code must 'draw' the screen 50 or 60 times a second consuming most of your CPU time. Most computers have video chips that can read memory all by their lonesomes (once the screen is set up properly). You can then put the CPU in an infinite loop (or lock it up with an invalid opcode) and you still see the picture. It has nothing to do with additional features like relocation of the screen. Those are just nice add-ons to DMA.

[Heaven/TQA]

coming from demo scene for more than 20 years now i have to admit that i loved my A800 simply because of most of it's flexibility in gfx point of view...

 

but being now for 2 years in "game mode" I personally more and more realise that speed is not everything... for gaming following features are cool to have:

 

- Antic and display list incl. 4k scanlines

- softscrolling in conjunction with display list

- DLIs + Wsync

- Players (sometimes f.e. for time bars... --> M.U.L.E.)

- CPU speed (but the speed advantage is not x-factor of c64 even if you try to mimik the sprites)

but sorry for stressing that again... but for gaming i have to admit that the c64 is far more suitable... (here only the out of the box features)

 

- 256 chars vs 128 chars

- 16 colours in multicolour incl. colour ram vs 4 colour plus pm overlays (tooo complicated and advanced to integrate in games)

- 8 multicolour sprites (24x21/12x21) vs 4 players (8x256, 2x256)

- soft scrolling still there with restrictions...

- nearly 64kram usage possible (? Oswald?)

- raster interrupts still there (ok...without WSYNC but you can have stable rasters)

- mixing highres + multicolourmode in one scanline and per charcell.

- SID (oh no...again... )

 

so... I was suprised that even games like Rainbow Walker look good and play good compared to the 800 counterpart...

 

I only can tell people who claiming A8 is far (!) better for gaming than the c64... please grab assembler and try both... Beyond (the) Evil game I could be quicker in terms of gfx if I would go for the c64 as dev system and not the A8...

[emkay]

so... I was suprised that even games like Rainbow Walker look good and play good compared to the 800 counterpart...

 

Why not?

 

The game itself doesn't move "that much" stuff around.

With all the Sprite benefits , the C64 version is slower.

Not to mention about a rainbow without rainbow colours

 

The fastest is the A8 PAL version, while the 60Hz version seems to be almost at same speed as the C64 version.

Actually, like with some other games, the ATARI PAL version is faster to handle, because some movement is directly done by the available speed. Same happens with Salmon Run, where the Grizzly runs faster, making the PAL version nearly unplayable.

[Oswald]

heaven, yeah it could be said that atari is better for demos, and c64 is better for games. on the c64 64k is usable except stack & hardware vectors at the very and of the memory (same on atari guess, as same cpu and 2 bytes 0000 and 0001 which are used for tape IO, and changing which roms are on/off. but guess you can turn off roms and have 64k in ataris aswell ?

[Heaven/TQA]

Oswald... how much RAM can you use in C64 excluding the hardware vectors?

 

on Atari you have to exclude $d000-$d7ff which is 2k in total.

[Fröhn]

16 color is enough

 

That's why the picture has a 256 colour index?

The 256 color index is there because of PAL emulation which is required to produce authentic colors and not "emulator coloring". As you might know, the PAL decoder mixes the color carrier of a two rasterlines so even if the C64 only has 16 colors as palette, the decoding process makes it far more colors. If you have two colors with the same luminance but different chrominance alternating every rasterline, you get a PERFECTLY mixed color (no flickering etc, it's REALLY mixed).

 

Btw you Atari people use that 50:50 color carrier mixing too for your 256 color pictures. You use the fact that a rasterlines color tone is mixed 50% with the previous rasterlines color tone, that's why the 16 chromas mode mixes with the 16 lumas mode if you use them on alternating lines (but with only half the saturation).

 

The point about >10Khz and more sprites was to make a point that Atari can also generate more sprites if needed and good digitized audio if needed (4-bit or 5-bit/sample) not that it would limit the C64.

As others pointed out already, you can easily multiplex sprites on C64 too. Heck, the sprite engine of the VIC2 was even developed for sprite multiplexing (inspired by TI99).

 

Sub-par pixel quality is my experience of hooking up and viewing both the C64 and Atari 400/800/XL/XE systems to the same composite monitor using the same color scheme (it's an Amiga monitor). The video looks better on Atari due to better saturation of colors or other issues.

That's only true for composite video because the C64 has a higher pixel clock frequency and gets closer to the color carrier frequency due to that. But C64 allows for S-Video without hacking, that one doesn't show those color interference stuff.

 

As far as re-useability of sprites, again the same point can be made that because of Atari's faster CPU, more accurate timer, DLI, etc. you can re-use them even on the same scan-line.

Yes, A8 allows reuse of sprites on a scanline, but only in a very limited way. It's unusable for true moving "sprites", basically you can only use it for static graphic elements. On C64 reusing a sprite on a scanline is not possible but let's compare: IF you managed to reuse all A8 players and missiles on a scanline, you get 80 (2*40) single color pixels. Now on C64 you can't reuse sprites, but even without reusing you have 8 sprites which are 24 pixels wide, that gives you 8*24 = 192 pixels from sprites per scanline WITHOUT reusing anything. To have 192 pixels from A8 PM's you would need to reuse all PM's 4.8 times which is completely impossible.

 

I need to know what divisor you used for the CIA timer of 1.022730Mhz to get your interrupts to re-use the sprite?

Raster IRQs are used for that. Just tell the VIC2 on which rasterline you want an IRQ and then you can multiplex sprites in that IRQ with only a few LDA/STAs.

 

Oswald... how much RAM can you use in C64 excluding the hardware vectors?

 

on Atari you have to exclude $d000-$d7ff which is 2k in total.

On C64 you can use $0002-$FFFF. $D000-$DFFF is a bit difficult to use because the IO stuff is mapped there, but you can easily put a bitmap there so the CPU doesn't need to switch off and on the IO all the time.

[Rybags]

Yes, the C-64 has the advantage that it can use all 64K, although swapping in the $D000-DFFF area means you can't access the memory-mapped I/O there.

Although as pointed out, the main use for that area would be for graphics or stuff that you don't need constant access to.

 

You can also access RAM locations 0/1 through trickery although it's hardly worth the effort - although I believe some protection schemes used the method for keeping secret flags.

 

The colour mixing on scanlines isn't the only means to get 256 colours onscreen - you can still do so in Gr. 9 although you then have limitations imposed per scanline.

 

 

One thing I'm a little curious about - has anyone ever bothered to try to interface a 1541 disk drive to the Atari? Although these days it's a kinda pointless exercise due to things like APE, IDE interfaces and SIO2SD.

[Fröhn]

The colour mixing on scanlines isn't the only means to get 256 colours onscreen - you can still do so in Gr. 9 although you then have limitations imposed per scanline.

Ofcourse but this wasn't my point. My point was: The screenshot shows more than 16 colors because on a real monitor there are more than 16 colors too due to the PAL decoding process. Btw, this is something which Atari800Win still lacks.

 

One thing I'm a little curious about - has anyone ever bothered to try to interface a 1541 disk drive to the Atari?

No but I thought about something else: Reading/writing Atari disks with a 1541. I believe this is possible, if my information is right the bitrates used in the 1050 can also be selected on a 1541.

[emkay]

Ofcourse but this wasn't my point. My point was: The screenshot shows more than 16 colors because on a real monitor there are more than 16 colors too due to the PAL decoding process. Btw, this is something which Atari800Win still lacks.

 

Well, I guess we're not talking about the same fact.

Your "PAL decoding process colours" is some "random" stuff, resulting on the PAL timing. the 256 Atari colours are still there on a 50Hz machine when using an SVideo Display... You are right when saying, it is a result of the colour mixing of the display. But the difference to the C64 resulting colours is that the A8 has the resulting 256 colours for real in its palette.

Not to mention that "new" colours could be mixed aswell.

Edited April 21, 2008 by emkay

[Bryan]

Btw you Atari people use that 50:50 color carrier mixing too for your 256 color pictures. You use the fact that a rasterlines color tone is mixed 50% with the previous rasterlines color tone, that's why the 16 chromas mode mixes with the 16 lumas mode if you use them on alternating lines (but with only half the saturation).

 

Only on PAL. On NTSC those gfx just look like alternating lines (NTSC sets have no color memory). I never understood why people made pictures that way until I saw it on a PAL machine.

 

-Bry

[Fröhn]

Ofcourse but this wasn't my point. My point was: The screenshot shows more than 16 colors because on a real monitor there are more than 16 colors too due to the PAL decoding process. Btw, this is something which Atari800Win still lacks.

Well, I guess we're not talking about the same fact.

Your "PAL decoding process colours" is some "random" stuff, resulting on the PAL timing. the 256 Atari colours are still there on a 50Hz machine when using an SVideo Display... You are right when saying, it is a result of the colour mixing of the display.

S-Video or composite does not matter, in both cases the color carrier still has to be decoded into U and V components, and to do this the chroma of two rasterlines is 50:50 mixed. That's because the inventors of PAL thought that the chroma changes only very little from one rasterline to another and based their decoding onto this fact. It's not "random stuff" and has nothing to do with "PAL timing", it has to do with the way the color information is encoded in a PAL signal.

 

But the difference to the C64 resulting colours is that the A8 has the resulting 256 colours for real in its palette.

But the 256 color mode is not a result of using a 256 color palette, but the result of using a 16 lumas palette mixed with a 16 chromas palette.

 

Not to mention that "new" colours could be mixed aswell.

Ofcourse, but since the human eye is very bad in distinguishing different chromas, it stops being useful at some point.

[Oswald]

now I know why the c64 was more popular: because emkay scared off all the people from the atari

[frogstar_robot]

One thing I'm a little curious about - has anyone ever bothered to try to interface a 1541 disk drive to the Atari? Although these days it's a kinda pointless exercise due to things like APE, IDE interfaces and SIO2SD.

 

I suppose it could be done in principle but it would take a bit of software writing and you'd have to get the timings for the protocol from somewhere. I once used something called (I believe) x64 to connect a 1571 drive to a PC's parallel port. There was DOS software that you could use to write c64 disk images to the PC suitable for use in emulators. You could also write downloaded disk images to floppies. Since this project used some pins on the parallel port rather than the RS-232 port, it doesn't appear that interfacing a 1541 to j-random-serial-port is all that easy. You can use pins of a PC parallel port as a custom serial port if you want to interface a serial device that doesn't use RS-232 timings and you have the chops to code for a custom serial protocol.

 

I rescued a buddy's childhood C-64 disk collection this way. I also used Linux to pull the contents of his Amiga hard drive but that is another story .

[Osbo]

Atari liked to keep their stuff secret. John Harris messed around with the A800 and wrote a excellent game IMO "Frogger". It goes to show what the 800 was capable of, but, according to him, he couldn't get anything out of Atari, he had to hack the machine to discover the secrets. I think the Commodore was more open, therefore, there are more C64 games... I like them both

[frogstar_robot]

Atari liked to keep their stuff secret. John Harris messed around with the A800 and wrote a excellent game IMO "Frogger". It goes to show what the 800 was capable of, but, according to him, he couldn't get anything out of Atari, he had to hack the machine to discover the secrets. I think the Commodore was more open, therefore, there are more C64 games... I like them both

 

The Atari wasn't all that secret after '81 or so when De Re Atari came out. Still Atari did sit on the true capabilities of the machine for three years. I believe much of the reason for this is in the original intentions for the ANTIC/GTIA/POKEY chipset. The A8 custom chips were initially intended for a 5200-like console and the machine was intended to pretty much be a "super 2600". The burgeoning market of Apple IIs, Pets, and TRS-80s and other micros changed the minds of the Atari brass so the 400/800 were designed around the chips instead.

 

How does this explain anything? Atari didn't divulge 2600 programming information at all initially. The idea of a third-party console developer was still new and didn't happen in a big way until Activision came along. Even though Atari wanted a computer to compete in the computer market, they were still thinking like a 70s game company accustomed to full control over hardware and software.

 

Once the C-64 hit the market, there was very little if any secrets about the A8. Although I'll grant that the C-64 came with MUCH better documentation, I don't think that explains the popularity of the C-64. Tramiel simply had better ideas for promoting the product and had the advantage of controlling MOS technologies. Pity he couldn't switch gears and quit thinking like a cutthroat mass marketer when HE got Atari.

[atariksi]

Re Joust

 

Joust uses 3 (haven't here the screenshot) players for the enemies which get multiplexed by DLIs. It is one of the few games which use ring buffer method (--> flicker when more than 4 hardware sprites per one scanline). so in total i haven't seen more than 8 per screen? even on higher levels?

the lance are the missles multiplexed.

 

the eggs are software sprites as the game uses Antic E (160x192x3).

 

so not much trickery here but i love the multiplexor... as i went into the Joust one years ago when playing around with multiplexor.

 

and as coder believe me... atari players are slowing down game engine just because you have to erase and draw the sprite data every time you move vertical and with multiplexing it gets even more cpu consuming... while the c64 you simple do lda x,sta x,lda y sta y... and that's it... and you have 8 of 12x21x3 sprites, each of them with different colour set (similar like the 7800), and even not multiplexed them...

 

I just want to make it clear first that I don't have a bias toward any machine and my replies are just to establish the truth-- I support C64, Atari 800, Atari ST, and Amiga in MPDOS (www.mpdos.com).

Regarding Joust, I treated all the birds, the flying monster, and lances as sprites. It seems Atari rushed to produce their computers so the 4 players got lumped into 4 missiles instead of 4 more players. However, just imagine a scenario of creating Joust II where the lances could be launched then would you not treat the lances as sprites and would you not have to use up another sprite channel on the C64? Yes, the Atari sprites are thinner but they are also taller. And if you have same shapes to move in Y-axes and target 48K+ machine (as you can do in this case), you can simulate the Y-axes without having to move the 20 or so bytes. In double line resolution, you would simple use VDELAY to move by one pixel and for other visible positions, you can have the shapes already in proper position and change PMBASE given the game is only using 16KB. In single line resolution, you use the probability and statistics and find that Joust uses most of the motion in lower half of the screen and use memory moves in the upper half.

 

As long as the sprite capability, accurate interrupts, CPU speed, etc. are present in some form or another, the game creation is more dependent on the creativity of the coder. C64 that were originally designed for that machine will be sub-par on Atari when ported and vice-versa. More colors are always a plus for games-- it increases the beauty.