Atari v Commodore

[Shawn Jefferson]

Well, i'll play with just about anything that has a 6502 variant... one day i'll have another go at learning Z80 to play with more stuff too! =-)

 

Had a look at the Lynx? We could use your skills there...

[Allas]

10 - BANDITS

 

Atari screenshots

 

C64 version have a little more colors on his screen, but finally the fast action on Atari side give a great playability. Sirius doesn't use hardware sprites on his programming, they preferred his own set of routines. A great classic!

 

C64 screenshots

[potatohead]

This is one reason to entertain these threads.

 

I've not seen this game! Looks like a fun one.

 

Thanks.

[Heaven/TQA]

aLLAS,

 

yes, reminds me the time when Atari ST was around in the first years where the ST versions of the game looked better or were technically better than their Amiga counter parts but changed when the dev system started to become Amiga and the guys were familiar with the Amiga.

 

Your games are all around 1983/84 released...

 

as more as I get into this in detail as more it is a wonder how good oue 1979 built machine can compete with the c64...

[Oswald]

C64 version have a little more colors on his screen, but finally the fast action on Atari side give a great playability. Sirius doesn't use hardware sprites on his programming, they preferred his own set of routines. A great classic!

 

so its faster on the atari ? I dont see the game doing anything that the c64 couldnt do just as fast. I couldnt start it in a8 emulator to check.

[emkay]

10 - BANDITS

 

 

Don't know why. If someone ask me about my top 10 of Atari games, this game wouldn't come to my mind.

But it was such a fun game and nicely done. I also made some good highscore here

[emkay]

C64 version have a little more colors on his screen, but finally the fast action on Atari side give a great playability. Sirius doesn't use hardware sprites on his programming, they preferred his own set of routines. A great classic!

 

so its faster on the atari ? I dont see the game doing anything that the c64 couldnt do just as fast. I couldnt start it in a8 emulator to check.

 

As you might see in the title of this game, it was done in 1982. Pre C64 and Pre ATARI XL. You need an 800 "wrapper" on the XL/XE or just switch the emulator to 800 and use the 800 OS.

[Oswald]

C64 version have a little more colors on his screen, but finally the fast action on Atari side give a great playability. Sirius doesn't use hardware sprites on his programming, they preferred his own set of routines. A great classic!

 

so its faster on the atari ? I dont see the game doing anything that the c64 couldnt do just as fast. I couldnt start it in a8 emulator to check.

 

As you might see in the title of this game, it was done in 1982. Pre C64 and Pre ATARI XL. You need an 800 "wrapper" on the XL/XE or just switch the emulator to 800 and use the 800 OS.

 

"OSB" doesnt works either.

[Crazyace]

Bandit's was an Apple II game, converted to A8 and C64. It throws around a lot of software sprites - and would need some serious multiplexing to run using h/w sprites.

( look at the later levels when the bandits, centipede, and balls are all on the screen at the same time )

The C64 look is probally closer to the Apple II original - but the Atari runs faster.

[Tezz]

Oswald, you'll need to use "The translator" before running Bandits if you're emulating the XL/XE as it's written for the 400/800.

Many of these older titles have been patched recently.

 

Or as suggested above you can use the 800 OS in the emulator settings if you have the rom downloaded instead.

Edited December 1, 2008 by Tezz

[www.atarimania.com]

Oswald, as well as making sure you are in OS-B mode, try disabling the "SIO patch for fast disk access".

 

--

Atari Frog

http://www.atarimania.com

[Bryan]

BTW. RE: the OR'ing overlap, it's worth pointing out that this can also be set to "black out" instead.

That came in handy for Castle Crisis when I needed the descending dragon and a fireball on the screen at the same time. I was able to make the dragon out of 3 players with the yellow one being double-width, but you can't tell the yellow is lower rez than the red because any residual blockiness was removed with the conflict-black trick.

 

When moving horizontally in the middle area (where I don't lose any colors to castles), the dragon is mostly characters.

 

-Bry

Edited December 1, 2008 by Bryan

[Tezz]

BTW. RE: the OR'ing overlap, it's worth pointing out that this can also be set to "black out" instead.

That came in handy for Castle Crisis when I needed the descending dragon and a fireball on the screen at the same time. I was able to make the dragon out of 3 players with the yellow one being double-width, but you can't tell the yellow is lower rez than the red because any residual blockiness was removed with the conflict-black trick.

 

When moving horizontally in the middle area (where I don't lose any colors to castles), the dragon is mostly characters.

 

-Bry

Excellent that's a good example of using the attributes to your advantage.

 

I would think that feature also could have been put to use regarding the discussion earlier in the thread with the Bruce Lee sprite on the A8 version if they had wanted to.

[TMR]

I would think that feature also could have been put to use regarding the discussion earlier in the thread with the Bruce Lee sprite on the A8 version if they had wanted to.

 

i was thinking that as well, giving it a bit of a ponder it's actually rather useful for quite a few situations. i'll say it again, this is why i like these threads! =-)

[TMR]

Well, i'll play with just about anything that has a 6502 variant... one day i'll have another go at learning Z80 to play with more stuff too! =-)

 

Had a look at the Lynx? We could use your skills there...

 

It's been on my "to do" list for a while now but (as i'm sure you or any of the coders about here know) it's a matter of finding time... right now i've sort of started looking at the BBC Micro, am working on C64 code and was up to 3am seeing if i could improve the Atari sprite handler i wrote a few weeks ago!

[Bryan]

One thing I like about programming the A8 is that it isn't terribly clear what kind of results are possible when you start a project. If you use the hardware in the straightforward textbook way, you'll get something that looks like 1978. If you start thinking outside the box, all sorts of things become possible. I tend to start a project with a pie-in-the-sky spec and only eliminate features when I've exhausted all possible approaches.

 

That's great for someone who does this sort of thing for fun, but it sucks for the software publisher who just wants to quickly port something to all platforms. I'm not much of a 64 programmer, but on that system I feel like the textbook approach generally yields good enough results for most things.

[Heaven/TQA]

Well, i'll play with just about anything that has a 6502 variant... one day i'll have another go at learning Z80 to play with more stuff too! =-)

 

Had a look at the Lynx? We could use your skills there...

 

It's been on my "to do" list for a while now but (as i'm sure you or any of the coders about here know) it's a matter of finding time... right now i've sort of started looking at the BBC Micro, am working on C64 code and was up to 3am seeing if i could improve the Atari sprite handler i wrote a few weeks ago!

 

oha...sprite handler... sounds interesting...

[Tezz]

I just noticed on Kaz's site today that Mark (Wrathchild) is working again on the Paradroid conversion from the C64 with the assistance of one of the guys on Lemon64 who's been making a new version.

Edited December 1, 2008 by Tezz

[Wrathchild]

Hi!

 

Yes indeed... almost 750 posts on and I haven't actually contributed to this thread yet

 

In the attempts I've made at porting some of the C64 titles, each one tends to reveal those tantilising things that our A8 could have done with (an example of this would be the hi-rez sprite, e.g. Mission Impossible, Nebulus/Tower Toppler). That is not to say that these things couldn't be done on the A8 - but most of the time they'd need to be done a slightly different way (e.g. for World Class Leaderboard I could take the sprites from the original A8 Leaderboard and use those instead). For me, I think back to when these multi-platform releases were being done around the mid-late '80s, the extra effort involved in coding these differences against the lesser sales the 8-bits were making (the Atari in particular) just meant many of these nice titles never made it to our platform. Also, I suspect, here in the UK the number of A8 programmers capable of pushing the machine were 'not many'. In doing these ports I'm trying to match as closely the originals taking into consideration the limitations of our machine. Where these are met and some re-writing is required, an alternative may not turn out to be as-good or sometimes it may turn out slightly better - some people will like that - others not - c'est la vie (alpha/beta testing will hopefully keep you on an OK track though).

 

Sound wise, my thoughts are that the SID and Pokey were significantly different enough to cherish each for their features but not to waste any time wishing one had this and the other had that etc, sorry to sit on the fence - mostly where there was a C64 and Atari port of the same game and the music differs, e.g. Rob Hubbard titles, I prefer the A8 version - Warhawk, International Karate and others like Draconus - but then something like the Last Ninja III intro tune blew me away and don't see the Atari capable of doing that though as I said before it could be... done a slightly different way. Whether that would be better or not is a mute point for me, it would be dependent on the taste of the listener.

[Crazyace]

Funny...

I was looking a Nebulus/Tower toppler on Sunday... Have you looked at the Amstrad CPC version - they have a nice sprite defined at 160 pixels ( the screen mode is 160x 16colors/pixel )

( I originally saw a youtube of Amstrad Street Fighter II - which looked like a fake , but then I thought that the only reason it might be a problem on the CPC would be the cpu time - but it could work on the 7800 )

[Tezz]

I originally saw a youtube of Amstrad Street Fighter II - which looked like a fake

yea, strangely I saw that just the other day too, I think that must be fake.

Colour usage on the CPC was pretty free and there's some nice looking conversions. Ghost and Goblins looked pretty close to the Arcade in terms of the other 8-bit versions (apart from he didn't lose his armour when hit). Beyond the ice palace looked very good on the cpc I thought. well, lots of others that could be mentioned I guess.

 

I hear it was very difficult to achieve a lot of things on the cpc we take for granted on the A8 and C64 with it's lack of hardware however.

Edited December 1, 2008 by Tezz

[Tezz]

... not to say that these things couldn't be done on the A8 - but most of the time they'd need to be done a slightly different way

Yea, I would tend to agree with that too. In most cases a complete 1:1 looking conversion wouldn't be possible but taking things in the best way for the Atari it can sometimes have other areas of improvement and overall be very acceptable. In some cases with a lot of knowledge and extra effort some conversions are achievable to an impressive degree. You're def right in the fact that you'll not please everyone with the end result, as there will always be an ellement of it not being exactly as it was remembered but that'll often be the case with a popular title that has been converted as apposed to a new game without comparison. I'll look forward to Paradroid, it's one of the great c64 titles that I remember which seems very doable on the A8.

[atariksi]

Ah - makes sense ( also there's no animation ) - still seems quite expensive - I think that main sprite is 24 pixels high - so you need 24 copies for 1 line vertical movement - PMBASE has to be 2K aligned... so you've swallowed 48k of ram ( with 18k 'spare' in gaps ) and when you mirror the sprite you need to rewrite all the 24 PM definitions.

I'd just use the old fashioned method

 

It does move two multicolor sprites independently in the Y-direction given you have to use one of the methods I mentioned to resolve the zone conflict (vblank, grafn, ...). There are no missiles so you have 1K spare out of the 2K PMBase memory. For animation, you can just have another PMBase rather than update all the PMBases. In the example, they wanted it 8*16 multicolor sprites so RAM useage was 16K. Wasn't trying to do Bruce Lee sprites-- but that was where I was suggesting that they could have used an OR color if the sprites were multicolor.

[Wrathchild]

Hi Tezz,

 

An example in point was another title I only just downloaded and watched for the first time a couple of months ago and that is Konami's "Ping Pong". I don't actually play this, I just like watching the rolling demo where the computer plays against itself. The ball, being hi-rez, shrinks down to a small cross and the A8 would have to do that differently. Would that detract sufficiently from the gameplay? Maybe the sprites could be hacked in the original game to test the theory? The screen also shows a mix of hi-rez chars (crowd and scoreboard) and 4-colour chars (table) where again the A8 would probably compromise and put in its own coloured crowd. Otherwise the score screen was nothing fancy but on the title screen the little penguin is again hi-rez multi-colour and would need some thought.

 

Regards,

Mark

[Crazyace]

Ah - makes sense ( also there's no animation ) - still seems quite expensive - I think that main sprite is 24 pixels high - so you need 24 copies for 1 line vertical movement - PMBASE has to be 2K aligned... so you've swallowed 48k of ram ( with 18k 'spare' in gaps ) and when you mirror the sprite you need to rewrite all the 24 PM definitions.

I'd just use the old fashioned method

 

It does move two multicolor sprites independently in the Y-direction given you have to use one of the methods I mentioned to resolve the zone conflict (vblank, grafn, ...). There are no missiles so you have 1K spare out of the 2K PMBase memory. For animation, you can just have another PMBase rather than update all the PMBases. In the example, they wanted it 8*16 multicolor sprites so RAM useage was 16K. Wasn't trying to do Bruce Lee sprites-- but that was where I was suggesting that they could have used an OR color if the sprites were multicolor.

 

How many different PMBASE values do you need? It seems to me that this system would fail badly in any real situation. Why not just double buffer the PM list and display list ( interupts ) so you have the entire frame to fill the players and set up the interups to move/recolour them.

 

It would be interesting to see a demo though ? Have you got an XEX or ATR image