Slashdot Mirror
Licensed C64 Emulator Rejected From App Store
Miasik.Net writes "A fully licensed Commodore 64 iPhone emulator has been rejected from the App Store. The excuse Apple used is a clause in the SDK agreement which doesn't allow for applications that run executable code. It seems Sega is exempt from that clause, because some of its games on the iPhone are emulators running original ROM code."
It's not an "excuse", it's clearly against the terms of the *agreement* the developer *agreed* to *before* starting work on it.
You can argue that Sega ought to be treated the same way (and I'd agree with that), but to call it an "excuse" when the terms specifically and explicitly forbid it smacks of throwing one's toys out of the pram and screaming "waaaaaaaahhhh"! "I want, I want, I want!" is such an ugly character flaw when it's seen in "adults"...
Simon
Physicists get Hadrons!
...because I am tired of reports of apps not working on iPhone and other ways Apple limits it. If people care so much about freedom, why don't they stop using it?
What are they worried about, that a revival of BASIC will crowd out Apple market share...? Or did Sega maybe have a quiet word with Apple about the competition?
That which does not kill us makes us... st
An iPhone emulator that runs on a Commodore 64? Color me surprised!
Hopefully this means that I can upgrade my old boxes by emulating dual core processors on them. Links, anyone? ;)
-b
No offense, but I've stopped responding to AC's.
If I recall correctly, the limitation in the SDK license is that Apple will not allow an interpreter that runs arbitrary code. That would mean that an interpreter that executes a single hardwired game does not violate the license.
Apple is about quality first and they are just holding back the release date until the iPhone's cassette tape inferface is ready.
If you RTFA, you will find that Manomio contacted Apple Europe before developing the app and they "seemed really excited". So here we have yet another developer wasting time and money just to have Apple reject another application despite approving others that do the same thing. I really hope Manomio decides to port his C64 app to the Android instead so some of us can enjoy it.
So, another article on Apple rejecting an iPhone app without real cause, or via a rule / regulation that contradicts another application. The solution I see it is one of several: 1 - Apple allowing the new app through, gaining additional income and being named as "the good guy" in this situation. Except some yackass will start complaining about not getting royalties for their software being in use and someone else profiting from the potential to use it. 2 - Apple will continue block the new app, not really caring about consumer backlash (as per usual) 3 - Apple will block similar apps and go with the "Good spotting! We didn't realize this OTHER app conflicted with our policies! We'll remove it too!" And in all situations, some people will be up in arms, some people will applaud apple, someone will scream about why jailbreaking is required to have (more) control over their phone, many will say "Well, if you had a blackberry/ palm pre / g-phone, you wouldn't have this problem".... and no one will think of the children.
From Apples perspective, I don't see this as entirely unreasonable.
They want to manage customer experience by controlling the environment. An app which can host arbitrary code could lead to exploits or other badness.
Code from the original ROMs is pretty well bounded and not going to do anything unexpected or malicious.
Now, that doesn't mean a bunch of people won't howl about this. But, for the average person buying a iPhone, I doubt they'll care.
Cheers
Lost at C:>. Found at C.
The games may run in an emulator but if it only runs that game and nothing else then it is effectively one application and nothing else. The C64 emulator will allow you to run numerous applications even if they are old and outdated.
:P
Apple's app store policies are weak but I agree with the other commenter and think we've had enough of these sort of stories. Apple isn't going to change their mind because these stories get posted on Slashdot and any regular should be using an Android based phone anyway.
I think what Apple wants is to make sure you can't "add" more games without going to the appstore.
Individual games (eg the Sega ones referred to) are each a seperate app that you get from the App store. You arent getting a single "Sega" emulator which you can then get more roms (legit or otherwise) seperately from the app store.
Presumably the C64 emulator had no such limitation.
(I have an iPhone, its jailbroken and unlocked, and even though I can explain Apple's motivation for their restrictive policy, they can kiss my ass)
Yah, the summary was written by someone who wasn't thinking things through very well.
This isn't Apple using their broad unspecified powers to reject an app arbitrarily or for a moronic reason. If it were, I'd agree with you.
This is an app that should never have even been started, because it very clearly violates the SDK agreement, and anyone with half a brain would have known that Apple would reject it.
As for the assertion that Sega's games are just emulators...
So get the hell off your high horse already and live in the real world.
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
You gotta do it the Apple way or go home. We have seen this time and time again with the app store.
Bundle the individual games with the emulator, but don't provide a mechanism to install additional games.
It's not as if this is new behavior for Apple. There's been at least one other case of an app by a big developer breaking the SDK agreement and getting approved, even though they fully and publicly admitted to it.
Of course Sega is exempt; their programs are a single ROM, run via emulation. You don't buy a Sega hardware emulator and then download ROMs for it, so they can test it fully before allowing it to be released. An open emulator, able to run any ROM you give it, is essentially a way to run un-tested, 3rd party code on the platform. There's no way for Apple to be sure the programs stay within their virtual environment. In essence, it would be a way to circumvent the security and execution protection on the phone entirely; it's a jailbreaker.
I'm about as far from an Apple apologist as you can get, and can't wait for this app store bullshit to quiet down. But let's not start reviling them for merely following their stated policy. If these people want to release their emulator, they'll need to do what their competitors have: bundle it with specific games and sell THOSE instead.
Reject the one app that would have guaranteed me purchasing an iPhone.
The general pattern is:
1) App is arbitrarily rejected for some reason.
2) Angry story on Slashdot about rejection.
3) App is resubmitted and accepted with some minor change (or no change at all like in the case of the eBook reader).
The stories are lame because the review system is a little subject to the whims of any given reviewer now, after two submissions that fail then I'd start saying it might be worthy of a story.
That said, this rejection does not fall into this pattern. The development guidelines have been very clear about emulators, they are not allowed. This was widely reported. I personally think the person who submitted the app did do because they knew they would get rejected, knew they would then get publicity, and say "Hey, I'm releasing on the Cydia App Store".
So you are right to vote this down, but not for the reasons you think... this story is pure marketing.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Another slashdot article crying about Apple doing bad things without bothering to think things through.
Sega game - hardcoded rom - no big deal.
C64 emulator - run arbitrary executable code - big fucking deal.
There is a pretty significant difference between the two. Now...is the C64 emulator likely to cause problems...probably not...but it is far easier and more efficient to just slap a ban on any app that can run arbitrary external executable code and call it a day. So your scenarios are as follows. 1 - Allow the app through and set a precedence for people being allowed to violate the dev agreement while opening up everyone's phone to external code execution exploits and get named a bad guy and probably sued by other developers who had their apps rejected for other agreement violation reasons previously. 2 - Continue to block the new app that violates the terms, protect the users from code execution problems, protect themselves from lawsuits, while realizing that most of the "consumer backlash" is from a bunch of whiney shits, most of whom won't even buy the damned iPhone in the first place. 3 - Block other "similar" apps and get sued for removing previously approved apps that did not violate any terms of service.
The only change I can believe in is what I find in my couch cushions.
If you RTFA, you will find that Manomio contacted Apple Europe before developing the app and they "seemed really excited".
Which could mean anything down to "I went to an Apple reseller and blathered about my idea to a salesdroid, and he seemed to like the idea."
I think the C64 brings back bad memories from the home computer wars. Apple ultimately survived thanks to the Macintosh and DTP but CBM gave them fits in the low end market. In fact they were a high end company ever since.
Except that I'm not sure Apple knew exactly how they were going to implement this. An emulator with game packs, etc where the user couldn't arbitrarily upload his own ... anything may have flew. Perhaps they should have gone into some details and made sure their implementation wasn't outside the TOS. Or if they were counting of selectively enforced standards, gotten some assurance that they would be held under the standards they wanted before spending the dev time.
Remember, this is Apple we're talking about. They get nothing from a C-64 emulation, fully licensed or otherwise.
But Apple ][ on the other hand ...
"No matter how cynical you get, it is impossible to keep up." -- Lily Tomlin
I would submit again and provide other instances where submissions have been allowed.
I have a SID player on the iPhone which was approved. This is emulating C64 hardware.
The people looking at the app store submissions probably have varied opinions.
While technically possible, do you really think a developer went and 'blathered about his idea' in public, at an Apple store? Really?
That which does not kill us makes us... st
Last time I checked, the iPhone could not run C64 programs natively. So, essentially, the games are interpreted by the emulator (as it is with pretty much all emulators).
According to that logic, you'd have to ban any application with built in scripting (like, say, any office application that I'm aware of), hell, a PDF reader would be banned as well because PDFs may include scripts. If you want to go bonkers, you could pretty much ban any application that takes any kind of not built-in data because technically, this is interpreted by the application as well.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I hope so too. I'm not defending Apple here as much as defending the rightness of enforcing a contract. As I point out above, I don't believe he contacted Apple Europe anyway, because if he did he'd have something in writing along the lines of "Yes, you can develop your emulator and we will let you load it onto the iPhone".
Talking to someone from Apple marketing over the phone and getting a verbal "hey that sounds cool" is completely and utterly worthless. Getting written permission as above would give him a fully justifiable case (and probably a lawsuit). He's probably somewhere in the middle, but unfortunately unless you have the written permission, you have nothing.
Simon
Physicists get Hadrons!
"C64 emulator - run arbitrary executable code - big fucking deal."
What's the BFD? It runs it inside a completely isolated sandbox. There's no way you can exploit iPhone by coding in BASIC.
How is that different from JavaScript on webpages?
Continue to block the new app that violates the terms [..] while realizing that most of the "consumer backlash" is from a bunch of whiney shits, most of whom won't even buy the damned iPhone in the first place.
Actually, I suspect that most of the "bunch of whiney shits" certainly *will* hand over their money for an iPhone anyway- regardless of Apple's policies. Which in practice still means that Apple don't have to give a toss about them.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Perhaps you could explain precisely what a 6510 emulator could run? This "arbitrary code" claim is pure bullshit, and unless you're severely retarded (and maybe you are, most Apple fanboys are pathetic mental cases), you know it. I mean, we're talking about emulating a 30 year old processor and hardware nearly that old. I suppose it's remotely possible that, if the iPhone platform is sufficiently insecure as to allow an emulator to gain actual control of the underlying operating system, that this could be an issue, but I would think if that were the issue, someone wouldn't be retarded enough to put the effort into an emulator when they could fashion a more mundane program to do their dirty work.\
C64 emulators have been around for something like 20 years now. Have you ever heard of the underlying operating system being undermined because these emulators can run "arbitrary code" (by which we really mean 6510 machine code and Commodore Basic code)? If not, then about the only defense is "Apple don't that". Apple is run by pathetic, emotionally stunted turds, and the only thing more pathetic than the people who run apple are the semi-literate, semi-sentient cretins who post shameless apologetics on Slashdot.
The world's burning. Moped Jesus spotted on I50. Details at 11.
This article is extremely misleading, resulting in tons of off-target flaming.
Apple doesn't prohibit apps using emulation, they prohibit apps that download and run arbitrary code, bypassing the Apple Store. The mistakes that the developers made were (1) putting a C64 Store into the app, and (2) putting a BASIC interpreter in the emulator. If it's tweaked slightly so that the games are downloaded through the Apple Store 3, and the BASIC interpreter is removed (it's useless anyway), I'm sure that it would be approved.
The developers probably decided to push the boundaries a bit in order to generate some news/press coverage. Pretty clever, actually - now Slashdot and other geek news sites is promoting them, and their app will still get approved in a week or two.
Enable 3D printed prosthetics!
It's my right because I OWN the device.
Just because you have the right to do something doesn't mean the manufacturer has to support it.
You are perfectly free to jailbreak your iPhone and install all sorts of unapproved software on it. So far as I know, there's nothing illegal about it, and the jailbreak community is pretty good at keeping on top of updates that fix previous methods of jailbreaking. Personally, I'm pretty happy with the selection of apps available through the App Store, and don't consider the hassle of jailbreaking worth the extra functionality I would be able to get. For others, the calculation is different.
"Moral authority" doesn't enter into it, mate.
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
Look - here's the relevant part of the agreement:
"3.3.2 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. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and built-in interpreter(s)."
Particularly this part:
"No interpreted code may be downloaded and used in an Application"
Does the emulator allow users to download ROMs over the internet? If so, then there's a problem. If not - ie. there are a number of licensed ROMs embedded in the application, then there should be no problem. Simple. He just needs to release each game-pack as a self-contained app - that's all.
In the real world it's my damn phone, I paid for it (and not just a license to use it), and I ought to be able to run anything on it that I wish that doesn't bring down AT&T's network in the process.
Now what world were you living in again?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
The difference is that Apple wants a cut of every app sold for this platform and absolute control over everything that runs on it. Allowing anything not filtered through their review and sales process to execute on the phone, even in a sandboxed, virtualized environment, screws up their business model. And you know how companies get when you present a threat to their business model.
More like it's the understanding of an ex-C64'er. SID files are programs, and SID players are special emulators that run the code in SID files. In this way SIDs are decidedly different from say MODs or MIDI files.
Belief is the currency of delusion.
If a bug exists in the iPhone's operating system that allows a buffer overrun in any software (the boundary between emulator and any other software that runs a macro or a script is utterly artificial) to compromise the operating system, then that's not the emulator's problem, that's the operating system's problem.
I have never heard of anyone exploiting an 8-bit emulator on any platform to seize control of the underlying operating system. Have you? Has anybody?
What, fundamentally, is the difference between an emulator and a javascript interpreter?
The world's burning. Moped Jesus spotted on I50. Details at 11.
I don't have a iPhone so i don't know how that works, but are you stuck with getting stuff from the 'officially blessed' iStore or can you just get any random app from wherever you want?
If so, sounds like its time for a 3rd party store without such ridiculous rules....
---- Booth was a patriot ----
as potential programmers they are mentally mutilated beyond hope of regeneration.
What a stinky, steaming pile of horse crap!!! (Even if Holy Saint Dijkstra said it.)
Hundreds of thousands of programmers got their start writing C-64, TRS-80, Apple & Sinclair BASIC on their home computers before graduating to structured languages, and 10s of thousands of them turned out to e good or great programmers.
In fact, I know that it's perfectly possible to write good structured code in COBOL-74. You "just" need a good knowledge of the features of the language (in addition to the standard prerequisites required by all good programmers).
"I don't know, therefore Aliens" Wafflebox1
Ok. This thread is conspicuously lacking a car analogy...until now..
How would it be if, after you bought a car, you had to apply to the manufacturer if you wanted to use a window-mounted sat-nav ? Of if sat-nav makers had to apply to car manufacturers to ask for permission to develop a window-mounted sat-nav ? huh?
Is it sounding as though there's a bit of an imbalance of power when it comes to digital property, yet?
Requiem for the American Dream
I bet he could get is App approved if he used the now in place DLC mechanisms for additional licensed ROMs.
The main purpose I see from this is Apple trying to prevent an 'App Store' being created within the App Store. The App Store is controlled and imposes some quality control with the submission process. Their is potential for abuse on Apple's part but this isn't a case of that.
You can distribute your apps freely on a JB phone, or develop for Andriod, Mac OS X, Linux, Windows, or any other system. What you shouldn't be able to do is distribute your apps within the App Store bypassing the control and payment schemes, while also taking advantage of their distro system and marketing.
Its nice to have a system with controls, where you don't have to be too worried about malicious content or getting it junked up with fragmented distro systems.
I am speaking as a professional game developer. I enjoy developing for Steam, XBOX 360, PS3, Wii, iPhone, or any other system with the bare minimum of quality standards in a submission process. Everything else is just to big of a mess and for the most part financially impractical, taking into account both piracy and the fact your software is commingled with just a ton of garbage.
Now I've seen Everything
>In the real world it's my damn phone, I paid for it (and not just a license to use it), and I ought to be able to run anything on it that I wish
No, you idiot. Did the company supply you the software, schematics and the PCB layout? No. Did they say they would? No. And you knew that. Don't say you didn't. Feel free to hack away on it; no one will stop you. If you want to achieve what you are asking for, buy an openmoko.
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
Hey, I spoke to someone from Microsoft, and they thought it would be a good idea is Microsoft separated into two entities, their OS and applications. So I guess this is solid now, guaranteed, we can expect to see Windows on Linux any day now???
Or maybe you will figure out how little it means to say you spoke to someone from Apple Europe???
No. But about the only one person who speaks for Apple is Steve Jobs. Other than that, everyone else has their own opinions on what's cool and what isn't.
Last week at WWDC, I spoke to someone at Apple who was interested in an App I'm working on. The problem is, parts of it need to run in the background for the best user experience. He agreed with me. That does not mean if I submit said app, it would be approved. What that means is that one person agrees with me--that my App would be better if it could run in the background.
Where would I go from here? Well, I need to find out from that one person who I would talk to about getting my app approved--the person I talked to wasn't the one person who gets to decide these things. I would need to talk to that person and see if there was a way for my app to be approved. Perhaps fly to Cupertino, CA, and demonstrate the usefulness of my app and the benefits of it being able to run in the background. Discuss the deficits of my App running in the background in regards to reduced battery life and general slowness and how I can ameliorate these issues.
In other words, I need to work my ass off playing politics with Apple.
Now, let's say Apple "seemed really excited." Apple may have seen this as a development tool. Let's say I wrote a C64 game. I could conceivably buy this guy's software, package it up with my game, and sell it in the iTunes Store. That may be why Apple "seemed really excited" about this--not as an App but as a tool for BASIC programmers to develop iPhone apps.
For every level of abstraction whose mastery you think predicts greatness with all levels above it, we can undercut each other with levels lower until one of us is forced the conclude superiority on the basis of proficiency with an abacus.
When people make the "great programmers started with machine code" argument, my opinion is that they are often lamenting the wastefulness and lack of "machine sympathy" that higher-level languages and syntactic/semantic sugar facilitate.
Sooner or alter, anyone paying enough attention and facing a big enough programming challenge hits the limits of whatever programming candy (or teat) they're sucking on, but advances in software development tools and computing technology mean that most new programmers will never need to be weaned.
There are no karma whores, only moderation johns
"Arbitrary code" as in code that doesn't necessarily come from the App Store.
Actually, it is the reverse, in my experience. Most programmers I know started their craft with a Commodore 64, Apple II, or Atari computers; programming in BASIC. Only after realizing how limited and slow the language was were they even exposed to Assembly or Machine Language.
In my experience, then, programming in BASIC gave them the inspiration, the interest, and the impetus to learn the lower level languages, precisely because a good high-level language was not available. The fact that they knew BASIC, and could even exploit its intricacies, did not hinder their appreciation for other languages, nor their ability to learn or apply them.
-dZ.
Carol vs. Ghost
If it was clearly marked that you can only use manufacturer approved GPS units with the car, I think it would be ok. I would just buy a car that hasn't got this limitation. Or get my own GPS unit approved. Or jailbreak the car..
- Raynet --> .
How about if you buy a chair and it is clearly marked that you may only use manufacturer-approved cushions ?
Seriously; in what reality does 'manufacturer-approved' make sense?
Requiem for the American Dream
You cannot load executable code.
I'm not really sure how to interpret "load executable code". Is there non-executable code? What makes it code, then?
Browsers load and execute javascript. Is javascript not code, or is it not executed, or does it break the rules, or is there some option I'm missing?
Is GLSL also code? That means you can't run third party color filters like the compiz plugin which simulates colorblindness. I'm sure that's an important restriction... wait, what?
Can anyone explain to me what "load executable code" does and doesn't cover? And even better, what's the motivation for the distinction?
I most likely wouldn't buy such a chair.
And I can imagine a situtation where this might actually happen. Some famous designer makes a unique char and he makes you sign a contract where he limits how you can use the chair, like only allow you to use the cushion he designed as it otherwise wouldn't be as aesthetically pleasing as he would like. Some people would gladly sign the contract so they could say they own a chair by this famous person, others might not.
Ofcourse the government can (and does) limit what the manufacturer can require you do to, but I don't care as long as there is a better option to choose from. Which is why I have several Nokia phones that allow me to install any app I want and the SDK is free. I also have Openmoko phone and an iPhone and paid for the Apple SDK. 99USD wasn't that high price to pay to be able to run any kind app I want on the iPhone.
- Raynet --> .
I think you vastly overestimate the number of good/great programmers in the world. Think dozens, not tens of thousands of them, total. It's certainly possible that BASIC can be your first language and you get over it. FORTRAN was my first language and I got over that. But unless you happen to be lucky enough to start with a great language (e.g. LISP) , you will have to unlearn everything else first. Learning bad languages just means it takes longer for you to learn good programming paradigms.
-- I speak only for myself
Great point. Even more - the C64 binaries are executed in a virtual machine. This is not a modern VM, it's emulating a C64, what possible impact could it have on the rest of the iPhone apps? In that sense, a C64 emulator running binaries is way more secure than a browser running Javascript.
So why isn't Javascript banned?
The world's burning. Moped Jesus spotted on I50. Details at 11.
... where exactly is the line for "launch and execution"? Under a very broad interpretation of policy, this could apply to any situation in which an app must parse any kind of 3rd party data in order to work with or display it.
Simply seeking out identifiable markers in any data source and reacting to it accordingly could be defined as an execution of externally issued instruction.
In a sense, any time you open a file in an app that didn't create it, that app is operating on the data in emulation.
8==8 Bones 8==8
Windows Vista?
Before you mod me as a troll, ..
Screw it, call me a troll.
The US government have made it clear that we have no inalienable rights; any we do not defend vigorously will be taken.
. . . and no one is going to compete with iTunes by programming assembly on a C64 emulator on an iPhone.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
So go ahead and run what you want on the damn phone. No one is going to stop you, so stop feeling sorry for yourself and just go away.
So here's the real question:
If Apple then hires someone to write that very app, then puts their "in house" version on the apple store, what are the odds that the earlier developer is going to be able to afford to sue?
So much for getting an Apple IIgs emulator on the iPhone 3G S.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
Naa... written permission doesn't help, either, with Apple... it's always going to be the case of their being the bigger hammer.
I developed some hardware based on the PowerPC platform back in '96-'97. While attending a Be Developer conference, a few of us met with Apple. We were shown Motorola StarMax machines runing MacOS 7.6, we were given all kinds of details on the inner working of the MacOS and what was needed at the HW level to be "Mac Compatible" rather than just "Mac Clone", etc. We were strongly urged to develop our HW in a compatible way, paperwork and agreements were signed, etc. Eight months later, Jobs was back and they put the kebash on the whole thing.
This is simply Real Life when you're working in the Apple Universe. And precisely why the best and brightest put their stuff elsewhere.. people develop iPhone apps because they smell money. Sometimes greed bites you in the ass.
It's a shame, too, but then again, someone needs to do an Apple to Apple. For years, they've made all kinds of money doing a sometimes fairly minimalistic attempt at not-sucking, while everyone around them sucked. That's continued in the phone world... Palm fell of the edge of the tech world five years ago, Verizon works hard to lobotomize every phone they get their hands on, WinCE... I mean Windows Mobile, has continued to lull users to sleep, Symbian... I guess it's out there, but I haven't heard much news in the last two or three years. RIM was just for business critters.
But oddly, that's all changing this year. Apple's gone more closed than ever in the era of openness... they're sucking, more than usual. The new iPhone 3GS was same old, same old... yawn.
Palm's back in some curious-looking form, if Sprint's foolishness doesn't manage to kill them, and they can manage to not suck in ways Apple does suck, they might stand a chance. Hey, if you live in Baltimore, you can even get 4G networking on the new Pre... good luck getting 3G anywhere else, but hey, I'm sure I'll
Android's really compelling, being that at present, it's sucking less than nearly anything else, even though it's still kind of new and unsupported... but hey, that one, I might even bother coding for. The only big suck part there is T-Mobile... they sorta-kinda come in down the end of my driveway, but who wants to walk 1/4 mile just to make a call from home. I guess I could put in a nanocell... or fix the antenna on my roof left from a failed Verizon experiment a few years back. But it's also the idea that practically everyone's about to put out a new Android phone/device Real Soon Now. Motorola's reportedly got 150 people doing Android.
So, really, let Apple continue to suck... they so very desparately crave the competition, and they will hopefully get it.
-Dave Haynie
I love it... interpreted C64 BASIC running on interpreted 65xx code on interpreted Java on a real MSM7210A (ARM1136EJ-S main CPU with ARM9 and Qualcom proprietary DSP coprocessors) clocked at 528MHz... and that can't beat a 1.02MHz 6510? Hello? Ok... make the 65xx interpreter a JIT for Java byte code... probably illegal, but a cool hack if you can get it. Of course, anyone thinking about emulators knows very well it's not the 6510 that's the problem, it's emulating the VIC-II, the CIA registers, the SID, etc. But this did run on a 7.16MHz 68000 some time ago... one would hope even the interpreted Java goes faster than that.
It's also completely unnecessary, and in fact, a real problem, if you make the C64 go too fast. Back in those days, timing in programs was sometimes delivered by way of timer or video blanking interrupts... and sometimes (particularly in BASIC) the result of an empty loop. Back in my BASIC days (the late 70s), that's pretty much how it was done. After all, no one else is using the machine. Of course, if you want your emulator to behave, you pretty much have to deal with this NOT dragging the whole phone down.
I have a C64 emulator on my old Palm Treo 700p... it stopped being a useful phone some time back, but it still does the C64 thing. Nothing like an open operating system... I know better than Jobs what useless tripe belongs on my device, thank-you-veddy-much.
-Dave Haynie
It's good for Google, HTC, Nokia, Blackberry, Microsoft.... and all the other cellphone manufacturers that don't impose such draconian rules on their customers.
Run anything you want. Get stuff from Apple Store, Cydia/Icy.
Too scared to actually own your device, ok...
There is the whole notion of using private distribution of apps.:
http://bluxte.net/musings/2009/05/17/ad-hoc-distribution-iphone-application
And installers of 3rd party apps:
http://www.mactropolis.com/iphone/how-to-install-apps-on-iphone-without-jailbraking/
iTunes and the store is a great heap of crap. Not being allowed to have access in to something you paid for is reprehensible.
A warranty on a car will be invalidated if you put sand in the gas tank (put bad code in to the iPhone and it fries the board- same thing). However, if you want to pop a bloody home made led light in the cig lighter or add new seats- this should be legally protected and no EULA should be able to thwart that.
quis custodiet ipsos custodes
Perhaps they think this is safe because it runs in a 'safe' Javascript sandbox in a browser 'sandbox' despite iPhone unlocking hacks out there proving otherwise.
http://www.jac64.com/jac64-how-to-use.html
An important distinction here is that JavaScript code is known to be properly sandboxed by Apple and AT&T. This is also OK for the Sega games running as emulation of the original ROM; That is no different from a game app that has a data file in it. The problem comes when you allow users to load any code they want into a potentially unprotected environment. Then, this becomes a liability issue.
Apple wrote the JavaScript engine that runs on the iPhone. If there are flaws, they can push updates to fix it, or if it's severe enough disable some or all JavaScript until a fix can be made. The implications here are staggering - suppose a bug gets out into the wild which involves a JavaScript 'sploit followed by a 3G DDoS attack. AT&T's whole network becomes saturated, iPhone or not. This can disrupt E911 services. Because of a JavaScript bug, someone might die. It's unlikely, but if it happens it's a HUGE liability. Everyone from the family of the deceased to the state would have a stake in that lawsuit.
Apple has a failsafe here - they can shut it down before it spins out of control because they have access to the code. They can push updates out before their phones become an army of virus-spewing BlueTooth devices nailing ever PC (or even Mac) they come with in 30 feet of.
Now imagine it happens through a bug in this Commadore 64 App, or any other App that would allow executable code. Apple has little control over that, much less so than if a flaw was their own problem. Don't get me wrong, Apple has a good reputation for security, they build solid products, and what I describe here is very unlikely to happen.
...but it's not impossible.
CAn'T CompreHend SARcaSm?
> Get it in writing or you don't have anything.
There's an old saying that verbal contracts aren't worth the paper they're written on. Unfortunately it's complete bunkum and over the years must have persuaded hundreds of thousands of people to accept being ripped off. Verbal contracts *ARE* enforceable. They're just harder to prove, but it can be done with the appropriate documentation. All very well to say 'get it in writing' but a shady negotiator will stall this for as long as possible. So if you're dealing with a shark who keeps finding excuses not to put their signature on a contract while they wring concessions or "pre-work" from you make sure you document everything you do. E-mail is a good start. Personally I think you're better walking off at the first sign of trouble, but if you suspect foul play find and see a good laywer (IANAL) who can advise you of your rights. Remember many lawyers are sharks too so get a quote up from and be clear you won't authorize any work over what you've agreed in writing. Be very careful about this too. In other words: Trust no one.
I'm not really sure how to interpret "load executable code". Is there non-executable code? What makes it code, then?
>When people make the "great programmers started with machine code" argument, my opinion is that they are often lamenting the wastefulness and lack of "machine sympathy" that higher-level languages and syntactic/semantic sugar facilitate.
And it's a lack of empathy with that exact argument that gives GHz PCs that crawl along.
Open Source Drum Kit, LPLC deve board - mjhdesigns.com