PDA

View Full Version : Commodore 64 Emulator for the iPhone using SDK


MacBytes
May 9, 2008, 05:38 PM
http://www.macbytes.com/images/bytessig.gif (http://www.macbytes.com)

Category: 3rd Party Software
Link: Commodore 64 Emulator for the iPhone using SDK (http://www.macbytes.com/link.php?sid=20080509183811)
Description:: none

Posted on MacBytes.com (http://www.macbytes.com)
Approved by arn

Rocketman
May 9, 2008, 07:15 PM
This is a HUGE technological step forward. So far, in fact, it went all the way around the planet and came back.

Does the original corporate overlord, and assigns thereof, of C-64 exist still?

Rocketman

Chisholm
May 10, 2008, 10:33 AM
Yeah, but is the Bluetooth adapter available for the cassette deck? Load Runner!!!!!

wwjdjoe
May 10, 2008, 02:09 PM
Yeah, how am I going to access my 1541 disc drive? :rolleyes:

Darkroom
May 10, 2008, 03:59 PM
Yeah, but is the Bluetooth adapter available for the cassette deck? Load Runner!!!!!

no man, it's all about BRUCE LEE!... remember BRUCE LEE?!!!! that game owned!

Thomas Harte
May 11, 2008, 04:59 AM
The former Commodore assets have long ago fractured and been sold off in different parts to different companies. As I understand it, the legal position is that they'd only need to obtain permission for the ROMs, so it doesn't matter where any hardware rights to unique chips like the SID have gone, if anywhere. To that end there could potentially be some problems — unless I'm mistaken, didn't the standard Commodore 64 ship with a ROM version of Microsoft BASIC? That said, many other companies seem to have released commercial C64 emulators with no problem.

Technically, it's not a very surprising development — and not even very difficult. That's probably why the author picked it as an SDK acclimatisation practice.

However, as ever this clause of the SDK license is troublesome:

An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise.

If the emulator were able to open disc/tape images from anywhere then it would be "launch[ing] other executable code by any means". If the emulator is limited so that it comes with a bunch of games and won't play any others then the emulator author will need to obtain permission to redistribute those also. The only other alternative is to release the application source/packaging details so that end-users can bind in their own games, but then 99% of them have no way to get the thing into their iPhone.

EDIT: oh, and I forgot to add — ZX Spectrums are much better than Commodore 64s anyway. I cite as evidence: some stuff I heard in a playground once.

foobarbaz
May 11, 2008, 07:23 AM
If the emulator were able to open disc/tape images from anywhere then it would be "launch[ing] other executable code by any means".

I'd say it wouldn't. The code isn't executable on the iPhone at all, so it is only "interpreted code", for which the agreement only says that it mustn't be downloaded. So the question is: Can users transfer files (ROMs) by other means than downloading.

DoFoT9
May 11, 2008, 09:02 AM
you guys are so sad lol...


however, youve made my day :cool:

gkarris
May 11, 2008, 12:11 PM
you guys are so sad lol...


however, youve made my day :cool:

TRS-80, please.... :eek:

:D

scarnie
May 11, 2008, 12:56 PM
no man, it's all about BRUCE LEE!... remember BRUCE LEE?!!!! that game owned!

That's a big reason for me doing the port ;-) I also loved Bruce Lee. Played it on an Atari 800XL too.

Thomas Harte
May 11, 2008, 03:43 PM
I'd say it wouldn't. The code isn't executable on the iPhone at all, so it is only "interpreted code", for which the agreement only says that it mustn't be downloaded. So the question is: Can users transfer files (ROMs) by other means than downloading.
Right, but the term has been widely interpreted to include any Java interpreter that wasn't bound to a specific application, and Java bytecode is no more or less "executable code" than 6502 machine code. I think they threw the word 'executable' in there to distinguish between anything you could download from the App Store that would potentially allow other software to be obtained from places other than the App Store, and applications that just process some sort of formal language with no flow control, e.g. a doc viewer.

scarnie
May 11, 2008, 05:07 PM
Right, but the term has been widely interpreted to include any Java interpreter that wasn't bound to a specific application, and Java bytecode is no more or less "executable code" than 6502 machine code. I think they threw the word 'executable' in there to distinguish between anything you could download from the App Store that would potentially allow other software to be obtained from places other than the App Store, and applications that just process some sort of formal language with no flow control, e.g. a doc viewer.

I feel Apple put that in the contract to give them some control over what can be released. It's pretty fuzzy, as 'executable' could mean many things. You can bet that general runtimes for enterprise development, such as Mono and Java are out, even Flash because people could source applications from something other that the 'App Store'. I would argue that most applications of any worth today interpret some input, whether it be textual or binary that could be argued as 'executable' code. Even processing XML often involves interpreting the document, causing your program to behave differently depending on the contents - and XML can be downloaded from the internet.

Another example is Unity (http://unity3d.com/company/news.html#Unity-is-Coming-to-the-iPhone) - it's a cross platform game development platform, which they are bringing to the iPhone / iPod Touch platforms. Like many other modern game engines, typically all your 'game logic' is run by an interpreter such as Lua. It just so happens that Unity uses Mono. What's to stop someone writing a 'game' for Unity that allows other mini-games to be downloaded?

I'm not too worried about it - ultimately, I'll be releasing the source code, so if it can't get on the App Store, there will still be a C64 for your iPhone...

Cheers,

Stu

Thomas Harte
May 11, 2008, 05:47 PM
It's pretty fuzzy, as 'executable' could mean many things ... I would argue that most applications of any worth today interpret some input, whether it be textual or binary that could be argued as 'executable' code.
I don't really think that interpretation of 'executable' is really the sticking point. The term isn't about all executable code, it's about 'other' executable code, i.e. executable code that is not part of the application. Per the term, such code may not be launched, or installed (which I read to be made part of the application so as to no longer be 'other' code). So it's not necessarily the nature of the code or the steps through which you have to jump to execute it, it's where the code is located.

If an emulator only uses files included in the application, as would be the case if Nintendo put out a series of Virtual Console-style downloadable NES games for example, then that would be fine. If it could load files elsewhere then per the strict wording, it wouldn't be.
Even processing XML often involves interpreting the document, causing your program to behave differently depending on the contents - and XML can be downloaded from the internet.
The terms define what Apple will allow applications to do, not what the iPhone hardware will allow applications to do. So why is it relevant that XML can be downloaded from the internet?
... What's to stop someone writing a 'game' for Unity that allows other mini-games to be downloaded?
The license agreement. Its whole purpose is to place limits on what you may do with the SDK that are not an inherent part of the form or function SDK itself. If it added no limits whatsoever then it would not need to exist. So again, it's not relevant to discuss what the software included with the SDK can be used to do what's relevant is what Apple will allow you to do with it.

What I think is your main point is probably the most insightful, i.e. that Apple have included a term that could be used to bar emulators but that the term itself in isolation doesn't spell out their intentions. Until they explicitly make a judgment, we can't really be sure.

I really wish emulators would be allowed as they're the main thing that I'd be interested in porting to the iPhone.

BornAgainMac
May 11, 2008, 10:11 PM
Mac OS 9 for the iPhone please.

DoFoT9
May 11, 2008, 10:12 PM
Mac OS 9 for the iPhone please.

OMG
sheepsaver mini!!!!

YES PLEASE!!!!!

scarnie
May 12, 2008, 12:51 AM
I don't really think that interpretation of 'executable' is really the sticking point. The term isn't about all executable code, it's about 'other' executable code, i.e. executable code that is not part of the application. Per the term, such code may not be launched, or installed (which I read to be made part of the application so as to no longer be 'other' code). So it's not necessarily the nature of the code or the steps through which you have to jump to execute it, it's where the code is located.

If an emulator only uses files included in the application, as would be the case if Nintendo put out a series of Virtual Console-style downloadable NES games for example, then that would be fine. If it could load files elsewhere then per the strict wording, it wouldn't be.

The terms define what Apple will allow applications to do, not what the iPhone hardware will allow applications to do. So why is it relevant that XML can be downloaded from the internet?
Yes, I should have been clearer about the XML statement. I was just attempting to point out that it's not uncommon (or unlikely) for XML to be interpreted as some form of code. Many applications will likely download this data ('code') from the internet. Arguably, this could be considered in violation of Apple's license agreement depending on how strict they plan to enforce it. Don't get me wrong, as I'm just as dubious as you, and only time will tell...

I did think about the 'internet' clause, and considered the possibility that if iFrodo had no feature to download from the internet, but I provided a simple little application for 'syncing' files from your machine (via WiFi), would this be in violation of their contract? :)

The license agreement. Its whole purpose is to place limits on what you may do with the SDK that are not an inherent part of the form or function SDK itself. If it added no limits whatsoever then it would not need to exist. So again, it's not relevant to discuss what the software included with the SDK can be used to do what's relevant is what Apple will allow you to do with it.
In complete agreement with you.

What I think is your main point is probably the most insightful, i.e. that Apple have included a term that could be used to bar emulators but that the term itself in isolation doesn't spell out their intentions. Until they explicitly make a judgment, we can't really be sure.

I really wish emulators would be allowed as they're the main thing that I'd be interested in porting to the iPhone.
Emulators are an interesting beast, which is why I started this little project - also it was an easy way to get into XCode and begin learning the environment.