Commodore 64 games ported to the Apple II?

[PDog]

Were there any?

[Keatah]

Not many, if any. It was more difficult to port from a computer with superior sound and graphics to one with inferior capabilities. The Apple II series had no such thing as a custom sound or graphics chip. And games that used them were too tome consuming to re-develop for a system that had no custom chips.

 

The other way around was a lot easier, and it explains why some games on the C64 appeared to not make use of any custom chip functions or looked identical to the Apple II stuff.

[Rybags]

Depends what you count as "porting" - in some cases it's planned to do games on multiple systems and the C64 version was the first and used as basis of the others.

 

Impossible Mission came first on C64 - it wasn't really "planned" to be a game even on that system - started as an animation sequence which evolved into a game which was later ported or converted to multiple systems.

[+FujiSkunk]

Not many, if any. It was more difficult to port from a computer with superior sound and graphics to one with inferior capabilities. The Apple II series had no such thing as a custom sound or graphics chip. And games that used them were too tome consuming to re-develop for a system that had no custom chips.

 

The other way around was a lot easier, and it explains why some games on the C64 appeared to not make use of any custom chip functions or looked identical to the Apple II stuff.

 

Actually I've seen several games that were obviously coded originally for the C-64 and then recoded for the Apple II, or at least were coded with the intent to share code between the two systems. Mostly these are arcade ports, particularly Mindscape releases like Gauntlet, Paperboy and Indiana Jones and the Temple of Doom. EA's port of Marble Madness also qualifies. Needless to say, the results aren't pretty on the Apple II in most cases. Marble Madness is serviceable on the Apple II, but the other three I mentioned are just about unplayable, especially Paperboy.

 

Depends what you count as "porting" - in some cases it's planned to do games on multiple systems and the C64 version was the first and used as basis of the others.

 

Impossible Mission came first on C64 - it wasn't really "planned" to be a game even on that system - started as an animation sequence which evolved into a game which was later ported or converted to multiple systems.

 

Following from Impossible Mission, there are a lot of Epyx games that started on the C-64 and then saw an Apple II port as well. California Games and several other of the "Games" series are big examples.

[carlsson]

Is Paperboy on the Apple ][ worse than Paperboy on the BBC Micro, also a 6502 design? The latter almost seems to run a ZX Spectrum simulator with a very small viewport, someone mentioned it would take too much CPU time or memory to have a bigger sized scrolling display.

 

Edit: Screenshots here, but only the title screen from the IIgs version:

http://www.mobygames.com/game/paperboy/screenshots

 

On this page there are two Amstrad/Schneider CPC versions of which one says unknown developer. Could the one in black, yellow, red and blue actually be an Apple ][ screenshot mislabeled as Amstrad?

http://www.ythcal.de/beetle/

Edited April 25, 2014 by carlsson

[Rybags]

BBC actually has a nice speed advantage over most other 6502 machines - 2 MHz with video access interleaved, supposedly no cycle-steal losses.

But it loses out in that 32K is the usual config and once OS+screen use is considered doesn't leave much for the program.

Also means that optimisations such as pre-shifted softsprites+masks become a luxury.

[carlsson]

I found a reference that with the analogue joysticks and difficulty to read whether two keys were pressed at the same time, the ][+ not even being able to tell if a key remains held down, some games would be hard to control on the Apple series. For instance it is one suggestion why EA never commissioned an Apple port of M.U.L.E. which itself doesn't have graphics too hard to recreate, but control during the auction phase might be harder to implement. I don't know if it holds true though.

 

I suppose the question about original Atari 8-bit computer games ported to the Apple ][ would yield similar answers as with ports from the C64, perhaps even fewer.

[Rybags]

Unsure - MULE requires at least 1 joystick anyway. You would think 3 players wouldn't be out of the question, 2 joysticks + 1 on kb.

 

No idea about the reading of A2 keyboard, I would think there's some flexibility since many games there support kb control.

I'd have thought Atari has the weakness with keyboard in comparison to most since multiple presses for the most part aren't possible.

[Gunstar]

 

I'd have thought Atari has the weakness with keyboard in comparison to most since multiple presses for the most part aren't possible.

What are you talking about? Atari 8-bits have not such problem. I can hold down a key on any Atari 8-bit all day and it will keep repeating it all day long.

 

Unless I misunderstand your meaning of "multiple presses." which is confusing wording...

Edited April 25, 2014 by Gunstar

[R.Cade]

The Apple keyboard is just basically a serial connection that gets ASCII codes for a key when it's pressed. It did have a repeat that could be turned on that just resent the same key over and over with a 555 timer and cap drain. There is no way to detect that a key was "held down" other than check if you continued to see the ASCII code over and over. It's very limited as a game control option.

[Serguei2]

Is it possible to make apple 2 games who requiert a joystick?

 

Is it commun for apple 2 users to have a joystick?

 

Many c64 games need a joystick to play.

[+FujiSkunk]

Is Paperboy on the Apple ][ worse than Paperboy on the BBC Micro, also a 6502 design? The latter almost seems to run a ZX Spectrum simulator with a very small viewport, someone mentioned it would take too much CPU time or memory to have a bigger sized scrolling display.

 

Edit: Screenshots here, but only the title screen from the IIgs version:

http://www.mobygames.com/game/paperboy/screenshots

 

On this page there are two Amstrad/Schneider CPC versions of which one says unknown developer. Could the one in black, yellow, red and blue actually be an Apple ][ screenshot mislabeled as Amstrad?

http://www.ythcal.de/beetle/

 

I've never used a BBC Micro or an Amstrad CPC, but those versions of Paperboy do look very similar to what we got on the Apple II and the Commodore 64 in the States. It looks like that code got reused a lot, which is bad news for any system like the Apple II that doesn't have the hardware tricks to run the code efficiently.

[carlsson]

There is a Let's Compare video with just about all different versions. The Apple ][ one doesn't look bad on stills, but perhaps plays too jerky and the palette doesn't do Paperboy any good.

[TMR]

What are you talking about? Atari 8-bits have not such problem. I can hold down a key on any Atari 8-bit all day and it will keep repeating it all day long.

 

Unless I misunderstand your meaning of "multiple presses." which is confusing wording...

.

 

Multiple presses usually refers to multiple keys being pressed simultaneously, so picking through the keyboard input to respond to the keys for up, left and fire simultaneously.

 

I've never used a BBC Micro or an Amstrad CPC, but those versions of Paperboy do look very similar to what we got on the Apple II and the Commodore 64 in the States. It looks like that code got reused a lot, which is bad news for any system like the Apple II that doesn't have the hardware tricks to run the code efficiently.

The chances are the code was redone for each platform, getting BBC code working on an Apple II is a pretty non-trivial job (it uses two bits per pixel with four pixels a byte compared to the Apple II's seven pixels a byte with the colour coming from fringing) and the people handling these conversions tended towards the quickest and simplest path. That and the C64 version of Paperboy was developed in the UK by a couple of Elite's in-house bunnies so the source code probably never left the country! =-)

[desiv]

Is it possible to make apple 2 games who requiert a joystick?

Yep, it's possible..

Is it common for apple 2 users to have a joystick?

Interesting question.

I "think" it's fairly common for the people who have Apple 2's today to have a joystick.

I will admit tho, back in the day, I knew several people who didn't have joysticks for their Apple's.

 

desiv

[Keatah]

Getting a joystick was a big stink for me bitd. Then again I was still in diapers and mommy and daddy were weary about spending EVEN MORE money on stuff for the freshly bought computer.

[Great Hierophant]

I found a reference that with the analogue joysticks and difficulty to read whether two keys were pressed at the same time, the ][+ not even being able to tell if a key remains held down, some games would be hard to control on the Apple series. For instance it is one suggestion why EA never commissioned an Apple port of M.U.L.E. which itself doesn't have graphics too hard to recreate, but control during the auction phase might be harder to implement. I don't know if it holds true though.

 

I suppose the question about original Atari 8-bit computer games ported to the Apple ][ would yield similar answers as with ports from the C64, perhaps even fewer.

 

 

Unsure - MULE requires at least 1 joystick anyway. You would think 3 players wouldn't be out of the question, 2 joysticks + 1 on kb.

 

No idea about the reading of A2 keyboard, I would think there's some flexibility since many games there support kb control.

I'd have thought Atari has the weakness with keyboard in comparison to most since multiple presses for the most part aren't possible.

 

 

The Apple keyboard is just basically a serial connection that gets ASCII codes for a key when it's pressed. It did have a repeat that could be turned on that just resent the same key over and over with a 555 timer and cap drain. There is no way to detect that a key was "held down" other than check if you continued to see the ASCII code over and over. It's very limited as a game control option.

 

MULE is one of the very few classic computer games of the first 2/3rds of 1980s not to have an Apple II version.

 

The Apple IIe removed the REPT key of the Apple II/II+ keyboard and included a typematic repeat function in software. I can imagine EA would have received angry letters from users of Apple IIs who had to continually bang on their keys to play the game until the key broke.

 

MULE was ported to the IBM PC and PCjr., and supported four players on both. I am sure it was not easy for four people to huddle around the keyboard for the auction phase, but the main phase only required one person at the keyboard at a time. The PCjr.'s wireless keyboard was useful here to pass around, but its smallness and slow key decoding made the auction a pain.

[Charlie_]

Conan: Hall of Volta

http://en.wikipedia.org/wiki/Conan:_Hall_of_Volta

 

I can't find any evidence, but I always suspected Wavy Navy was an Apple II game 1st.

http://www.c64-wiki.com/index.php/Wavy_Navy

[The Usotsuki]

Well, it's Sirius... weren't most if not all Sirius games Apple ][-first?

[SoulBlazer]

Wavy Navy! Wow, that brings back memories. I played the hell out of that on my C64 as a kid.

 

And didn't MULE for the C64 support 4 players? I KNOW the NES version did, if you had the adapter.

[Charlie_]

Well, it's Sirius... weren't most if not all Sirius games Apple ][-first?

Evidence?

 

Quote from:http://www.c64-wiki.com/index.php/Wavy_Navy

 

"As "Bullet-Time" had not yet been invented in 1983, this needs to be seen as a technical deficiency of the game and again a nasty foreboding creeps in that, as yet so often, a direct, unoptimized portation of a game was made here, which originally had been designed for a system that is rather inept for action games."

[+FujiSkunk]

There is a Let's Compare video with just about all different versions. The Apple ][ one doesn't look bad on stills, but perhaps plays too jerky and the palette doesn't do Paperboy any good.

 

The sound isn't all that hot, either. Apple II Paperboy actually tries to play background music during the game, and the results are disastrous.

 

The chances are the code was redone for each platform, getting BBC code working on an Apple II is a pretty non-trivial job (it uses two bits per pixel with four pixels a byte compared to the Apple II's seven pixels a byte with the colour coming from fringing) and the people handling these conversions tended towards the quickest and simplest path. That and the C64 version of Paperboy was developed in the UK by a couple of Elite's in-house bunnies so the source code probably never left the country! =-)

 

I'm speculating, of course, and after seeing the Micro version in action on YouTube, I agree now there probably wasn't too much shared between the Micro version and other 8-bit releases (though the Micro's Paperboy neighborhood still looks quite similar to that of the C-64 and Apple II versions, right down to the dozens of tombstones between each house). On the other hand, the C-64 and Apple II versions not only share virtually the same graphics (compensating for the Apple II's woefully small color palette), they also share other characteristics, including the same not-quite-arcade game theme... or rather, they share the theme as much as the Apple II hardware allows (you can listen to samples of both here). So, I'm still inclined to believe there was quite a bit of code shared between those two versions, and Paperboy wasn't the only game to show evidence of this.

[TMR]

On the other hand, the C-64 and Apple II versions not only share virtually the same graphics (compensating for the Apple II's woefully small color palette), they also share other characteristics, including the same not-quite-arcade game theme... or rather, they share the theme as much as the Apple II hardware allows (you can listen to samples of both here). So, I'm still inclined to believe there was quite a bit of code shared between those two versions, and Paperboy wasn't the only game to show evidence of this.

The C64's assets have been repurposed for the Apple II (although some elements appear to have gone missing in the process) and there does appear to be at least some shared game logic too, but the code doing the real donkey work for the scrolling, object handling or control input is all bespoke simply because it has to be.

[+FujiSkunk]

The C64's assets have been repurposed for the Apple II (although some elements appear to have gone missing in the process) and there does appear to be at least some shared game logic too, but the code doing the real donkey work for the scrolling, object handling or control input is all bespoke simply because it has to be.

 

No argument there, and really that's my point: the Apple II version suffers because of the shared code. Perhaps the developers figured they could plug the C-64 graphics and sound code into some pre-existing Apple II engines for scrolling and sound to save some time, when really those engines just weren't meant for stuff with that much detail.

[TMR]

No argument there, and really that's my point: the Apple II version suffers because of the shared code.

The shared code is just "under the hood" stuff, it governs things like how long the RC car waits before changing direction or which block of background data to look at for the next house (since they can be in one of two states) and so on. It'll be the bespoke code where the problems you're identifying are coming from so the scroll, sprite engine, control input, things like that. Replace that code and it won't make any real difference.

 

(The only exception is the music driver, i know Mark Cooksey's routine was resource hungry but can't be sure how much of that was down to the SID wangling part which won't have been used.)

 

Perhaps the developers figured they could plug the C-64 graphics and sound code into some pre-existing Apple II engines for scrolling and sound to save some time, when really those engines just weren't meant for stuff with that much detail.

The scrolling routines tend to be pretty specific to job and if they can handle a certain amount of data going through each refresh that means they were designed for that amount of data regardless of how much time it takes; lowering the detail level of the existing graphics won't make that code any quicker (even with the source code to reassemble the game around the new data) because it still has to chunk the same amount of bytes around the screen.