Commodore 64 Emulator for the iPhone using SDK

Discussion in 'MacBytes.com News Discussion' started by MacBytes, May 9, 2008.

  1. macrumors bot

    Joined:
    Jul 5, 2003
  2. macrumors 603

    Rocketman

    #2
    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
     
  3. macrumors regular

    Joined:
    May 31, 2002
    Location:
    Tuscaloosa, Alabama
    #3
    Yeah, but is the Bluetooth adapter available for the cassette deck? Load Runner!!!!!
     
  4. macrumors member

    Joined:
    Apr 30, 2008
    #4
    Yeah, how am I going to access my 1541 disc drive? :rolleyes:
     
  5. Guest

    Darkroom

    Joined:
    Dec 15, 2006
    Location:
    Montréal, Canada
    #5
    no man, it's all about BRUCE LEE!... remember BRUCE LEE?!!!! that game owned!
     
  6. macrumors 6502

    Joined:
    Nov 30, 2005
    #6
    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:

    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.
     
  7. macrumors 6502

    Joined:
    Nov 29, 2007
    #7
    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.
     
  8. macrumors P6

    DoFoT9

    Joined:
    Jun 11, 2007
    Location:
    Singapore
    #8
    you guys are so sad lol...


    however, youve made my day :cool:
     
  9. macrumors 604

    gkarris

    Joined:
    Dec 31, 2004
    Location:
    "No escape from Reality..."
    #9
    TRS-80, please.... :eek:

    :D
     
  10. macrumors newbie

    Joined:
    Apr 12, 2008
    #10
    That's a big reason for me doing the port ;-) I also loved Bruce Lee. Played it on an Atari 800XL too.
     
  11. macrumors 6502

    Joined:
    Nov 30, 2005
    #11
    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.
     
  12. macrumors newbie

    Joined:
    Apr 12, 2008
    #12
    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 - 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
     
  13. macrumors 6502

    Joined:
    Nov 30, 2005
    #13
    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?
    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.
     
  14. macrumors 601

    BornAgainMac

    Joined:
    Feb 4, 2004
    Location:
    Florida Resident
  15. macrumors P6

    DoFoT9

    Joined:
    Jun 11, 2007
    Location:
    Singapore
    #15
    OMG
    sheepsaver mini!!!!

    YES PLEASE!!!!!
     
  16. macrumors newbie

    Joined:
    Apr 12, 2008
    #16
    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? :)

    In complete agreement with you.

    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.
     

Share This Page