EMUya - A emulation store for homebrew NES development

Hi all!

I'm putting together an emulator for the Ouya and this is a call out to all indie NES devs. I modeled the emulator after nemulator (cause its design is awesome!)

I had a crazy idea that instead of selling the emulator itself, it could be a marketplace for indie NES games.

If you guys think this is a good idea I can add an purchase option to the emulator to unlock your games (which I will store in an encrypted format).

The only rule for Ouya is that you have a demo that people can play for free before purchasing.

Let me know if your interested in selling your game to a large audience!

Best,
Jon

If people made games for purchase on it, it seems that it wouldn't be a NES, just a NES-like platform. The game would have to work properly on your emulator, since that's what people are paying to play it on, so any differences from NES would have to be accommodated by the games. And you could't fix emulator bugs since it would break previous games (unless you are able to tie each game to a specific emulator version). Even ignoring these unwanted sources of inaccuracy, since the emulator would be the only target, you'd want to add things to make split-screen easier, give more CPU time, etc. These are easy to do and make game development simpler.

It would be an interesting way to sell homebrew NES games without high production costs and without worries over unwanted sharing. In fact, worries over unwanted sharing would actually encourage making the emulator work somewhat differently than NES to prevent playing any leaked game ROMs on NES emulators or NES hardware. Simple approaches would be to change the memory map, e.g. RAM in a different place, PPU/APU registers elsewhere.

If there are desirable games, and an esoteric mapper, people will emulate it. (see Super Mario World or Final Fantasy 7).

Using an existing well-tested emulator core in NDK would help, as long as the emulator is at least as accurate as a common famiclone. I imagine the idea is that some games will be made available on Ouya and on an NES cartridge, and someone who owns both an Ouya and an NES might play the free demo on the Ouya Store and decide to buy it on cartridge.


Hence the different IOS binaries in the Wii system software and the emulator binaries in Virtual Console.


Hence the palette rearrangement in the 2C04 and the swapping of addresses of PPUCTRL/PPUMASK in the 2C05. "RAM in a different place" wouldn't work because the 6502-derived core in all 2A0x family CPUs depends on having the direct page at $0000-$00FF and the stack at $0100-$01FF.

Of course this whole plan would need to be modified if the Ouya Store distribution agreement has a non-compete clause like that of the App Store and Google Play Store that prohibits applications from acting as app stores themselves. In such a case, you'd need to distribute your emulator as a tool to package a single ROM, much like Virtual Console for Wii and Macifom for iOS.

An idea that I had not long ago (when I was thinking about XNA only to learn computer generated sounds is a no-go on the platform) was to add "achievement" support by watching a ceirtain RAM address... when the ROM program sets a watched flag to true, the emulator app must acknowledge it and display "you have unlocked a trophy: [TROPHY TITLE]" (search the respective trophy ID/Title on the emu's internal database) and then save it on a separate file.

They finally fixed that in XNA 4.

What if I make a game and want you to not make it encrypted, rather make it decrypted once purchased? It seems not so useful if you cannot copy it to a different system to play or modify. (Digital signature may be useful, though, in order to ensure working of achievements and so on.)

Sure that can be an option, np. I think the folks who sell cartridges only would however prefer the ROM didn't go into the wild though.

Such an option might be called "Export Game to CF for PowerPak". In that case, I wonder how easy it'd be to watermark the ROM on decryption by adding obfuscated copies of the IMEI or other buyer-identifying information in various parts of the ROM. For example, it could be hidden in an unused tile, a grass tile, etc. The buyer's name could be stored in the title screen. That way, a decrypted ROM inappropriately distributed to the public could be traced to the buyer. Apple does this with DRM-free M4A tracks sold through the iTunes store.

Couldn't this potentially put you into trouble, making a store within a store? Sure, I guess you could argue it's the IAP of the emulator, but being full-blown games I'm not sure the guys at Ouya would be happy about the idea.

It'd make more sense to just sell each game separately directly on the Ouya store and use the emulator as the means to get it running on the Ouya. You could even easily customize the interface of the emulator to each game.

Put ads in the emu that are downloaded off a server that show the other games, new releases, etc. So they're linked but separate entities.

People do this all the time on iOS and Android, I don't see why they would have a problem as long as they get their cut. If we tried to cut them out, they probably would not be very happy about it.

Also, I'll let you choose how much you feel the store is worth to you. So, if you want nothing to go to the store, the cut is between you and Ouya only. I think that is fair given all possible outcomes.

I've thought about something like this for selling a plain homebrew rom. When I told someone of that plan, they asked, "Yeah, so you know who did it. Then what?" What can you do as a solo person? Taking them to court is expensive. I mean... you could publicly shame them, maybe get them banned from the OUYA store, but I think that makes you look worse than them and doesn't undo the damage.

Put the ROMS online and have it download them from a server just to host them. I'm sure it's a lot harder to extract them if they're not in the file.

Replay or monkey-in-the-middle attacks are approximately as easy as cracking offline DRM, and doing that only makes it more annoying for legit users because the person now has to have a good connection to the interwebz whenever they want to play.

I think watermarking and maybe obfuscation are the best choices. You don't want to sue them anyway (you're not the MPAA...), so you just want it to be the minimum of difficulty to make it awkward for them to extract the image but still 100% reliable for you. Adding the visible watermarking means now they don't get a copy identical to the master, so there's no urge to hoard, and maybe a little bit of name-and-shame.

You could have these options available for whoever made the game, and also display them to the user before downloading the games (so that you won't cheat the user from their money):

• Encrypt (the file cannot be moved from the system)
• Watermark (the file can be copied to use with real hardware and any other emulators, but each copy is different and might be traced)
• Signature (the file can be copied to use with real hardware and any other emulators, and each copy is the same, but there is digital signature to verify it)
• Plain (the file can be copied to use with real hardware and any other emulators, and each copy is exactly the same as the master; some features (such as achievements) might be disabled if this is used, but other features (such as cheat codes and debugging) might be enabled only with plain ROMs)

You could also, say, have the code/ram/data be patched by the emu, like wait for a start up state or something. If it doesn't detect it, just make the game bad to play. Like earthbound did. Stupid hard, no final boss, erased save data, make "random" crashes, etc. I'd say random crashes triggered by a random program so it happens minutes in to the game would be great as you can make it as hard to trace as possible, and allow it to take a while to do and such.

One could implement some kind of required server communication with server side key verification. Maybe also include some kind of game expansion (code/data download) and/or high score database.

How is this any better than downloading the ROM every time? You need a guaranteed good connection to internet again.

Then allow for x executions without a connection. There is no other way that I can think of that can't very easily be hacked.
A game with code to connect and verify could still be hacked, but a loss of features changes things more than something that is just for copy protection.

Desire of total control raises a lot of problems, isn't? And the best thing it is hopeless, any protection will be broken, it is just matter of time.

I would rather think of alternative ways that based on total freedom rather than total control, it seems to be more perspective.

Put ads in the project, so even if they steal it, the other 1000 people who played and didn't steal helped make it okay?

I agree. At most you can just delay the inevitable, however delaying the inevitable isn't always a bad thing.

While I completely agree, I have suggested a compromise nevertheless.

Speaking of methods of tying a version of a game to a custom emulator, there is a simple thing to do that will introduce major headache to those who would like to hack it back to put on a cart.

There are plenty of unused/undocumented opcodes that aren't really used. Now, we can make them to do useful things in a custom emulator. Say, we'll add operation stz addr. In source code of the game we can have a macro that will do it either normal way, with few opcodes, or with this new custom opcode. It will be used all around code, and with simple recompile we can have a normal version and this 'protected' one. Even if a hacker will know what the new opcode does (by decompiling the custom emulator or just by a guess), he'll sure be able to hack an existing emulator to support it, if he aren't too lazy. But to make it work on the real hardware he will have to replace the opcode. Since it does job of few opcodes, a lot of code shifts and inserts will be needed, or a full disassemble to recompile - that's just too much of work and will take quite some time even for someone who is brave enough to do it.

Sounds like a neat idea I don't mind doing it if you feel it would be useful to you.

May as well just not make a NES game and make an Ouya game instead...

Of course that depends on how you see the learning curve for Java + Android + OpenGL ES development vs. 6502 + 2C02 development. Making an NES game and wrapping it with Emuya might actually be easier for some regulars here.

I should be ready in a couple weeks for a brave soul out there to beta test the in app purchasing with We would need to work out specifics on what they want to charge and what kind of encryption level they are comfortable with. Also, for those on the forums, I've decided to stick to my guns with the you decide how much % that goes to the store, even if that number is 0% for any number of copies you sell. It is more important for me to see a thriving NES indie development scene than it is for me to break even. I cannot however affect what Ouya takes (30%), so pad that ouya store tax into your prices.

Also for pricing you can reference: http://ouyaforum.com/showthread.php?749-How-much-do-you-think-you-would-be-willing-to-pay-for-the-average-OUYA-Game

I'd be interested in offering some of my Atari 2600 games if you could integrate yet another platform to your system.

Great! Yup, I'll let you know when the Atari emulator is ready. EMUya was always intended to be a multi-system, multi-platform emulator, just starting with NES and Ouya. I'll probably be able to start the Atari emulator in April or late March I think.

Yes! Please message me when ready. What are your terms? Can I still release the source and ROM online? How are royalties dealt with?

As a side this website is effectively endorsing piracy with EMUYa by telling people to go to CoolRoms:
http://www.oriku.com/emuya.html

If they really want to endorse your product they should recommend PDROMs.de for public domain homebrew.

No terms other than you have to be a US citizen. I'm not familiar with how to deal with out-of-country taxes and regulations, so for now I'd like to keep that simple. However, If I have to, I'll do the research and figure out what to do. You can release the source and ROM online additionally if you want. You set the price, but I would recommend keeping it under 10 dollars for acceptable and 5 dollars for optimal. Sivak's pricing for Battle Kid is going to be about 4.49 or 4.99. We'll test it out and see what the market will bear.

How are royalties dealt with?
I send you a check and a 1099 that you have to file with your taxes at the beginning of the calendar year.



Oriku is my brother's company that we'll be releasing EMUya under.

Thats a good point. I should update that w/ PDROMs.de.

I'm kind of torn about how to handle people wanting to play "classic" games. In order for people to open up EMUya in the first place to see your indie games, there needs to be a reason to do so and also a reason for people to come back regularly to see the new games that you put on the store. A store with 1 or 2 games in there is not enough to keep people's attention. And while eventually the store will be populated with many indie NES games, eventually may never happen as the store needs a launching point to get off the ground. So, I think at first, we need to have support in there for that, but eventually we can take it out if need be.

One idea is to change the name to BREWya or something like that, calling it EMUya will make people think that it's an emulator that plays romz for free and

BREW makes me think of this abomination from the feature phone era.

As I understand it, the games wouldn't be listed as "EMUya" in the store; they'd be listed under a title like "STREEMERZ: Super Strength Emergency Squad Zeta" with "Powered by EMUya" or something in the description.

For tax purposes, if you are a U.S. citizen, U.S. resident, U.S. partnership or U.S. corporation, please complete and upload the following form:
http://www.irs.gov/pub/irs-pdf/fw9.pdf

Otherwise, please fill out and upload the following form:
http://www.irs.gov/pub/irs-pdf/fw8ben.pdf

Fill em out, sign it and send it to me over the internets. jon.olick {@} gmail {dot} com

Seems like kind of a hassle to have to sell a rom though the emulator only especially with the taxing issues and such. Shouldn't the developer be able to somehow sell the rom on their own accord through OUYA and then it could be loaded in your emulator or others that were compatible? Why not do something like that as a possible option? Sure it may be easier for the rom to get undesirably distributed though piracy, but if the developer cared more about that than taxes through you it'd be worth it. You could even provide an encryption key with the rom that only allowed it to be unlocked in EMUya or whatever it gets named. Then one wouldn't have to worry about royalties but still have about the same amount of copy protection right? Especially if you're not charging anything to play a rom in your EMUya. In the case that you didn't charge you're basically dealing with the exchange of money and tax accounting of all game sales for NO income on your end. Doesn't exactly sound like a fun time to me, but perhaps your a programmer and hobby accountant...


With a 1099 you can't write off any of your expenses of development. All earnings are taxable income. Although I guess if OUYA is giving you a 1099 also then the only thing different is who it's coming from.

What makes you think that? Google 1099 expenses led me here.

Yeah I guess you're right. I must have been thinking of W-2.

If you want me to put the game on the store for free, then no you don't need to fill out any forms.

If however you make over $600 (which if you do sell your rom, I expect you probably will in great excess of), I have to report it to the government. What the W9 form does really is identify you as a specific individual to the government so that when I file a tax report to the government they know who you are.


A 1099 says that this is how much you made from what source. Its just informational purposes for the IRS and doesn't restrict deductions.

Something that Dave and I were talking about it was putting together time attack competitions Should be fun!

How hard is it to definitively detect the end of a game condition programmatically by inspecting ram or maybe when the PC hits a certain address?

Pics or it didn't happen?!

http://i.imgur.com/cywFI5j.jpg
http://i.imgur.com/qBCaF6V.jpg
http://i.imgur.com/nEArJ0A.jpg

Indie NES games take front stage with EMUya.

The emulator also does some quite amazing things, such as the ability to reverse time, braid style.

We are currently working on recording playthroughs which has an awesome twist when you combine it with time reversal. We will be bringing time attacks to the masses and hosting tool assisted time attack competitions =D

EMUya also emulates the NTSC signal, giving you a very authentic feel.

All games run locked at 60fps with attention paid to input lag.


[these pics were far bigger than my PC's monitor --MOD]
Edit: yeah they are quite big. Elgato capture device I suppose. I'll resize and re-upload.

Great news everyone!

EMUya has been approved and will be a day one launch title!!

We've also had some interest from the press about doing news stories on indie NES games and EMUya! =D Exciting times!

Will there be a way to optimize games for the analog stick or trackpad?

I loved that indie game. Better get permission from its author just to be sure it's OK to include it.

haha yeah, sorry. One of my favorite classic games there.

image removed

Just finished replay support. I did it quite a bit differently than most other emulators to have the ability to have replays still work even if the timing of the emulator changes due to a bug fix for this game or that. I'll post about it in nesemdev tomorrow

Video of EMUya here: http://www.youtube.com/watch?v=WEofmht2IZ8

Looks good! But are you sure you're mixing sounds right? Sounds like it has way too much noise channel.

I could simulate an input device for that. IIRC, doesn't the NES have a peripheral that is similar?

I very well may not be 100% correct in audio mixing. PPU is a lot easier to verify correctness on, APU is a bit harder.

For absolute position devices:
The Oeka Kids tablet, but almost nothing uses it, and we don't have hardware to test against.
The Arkanoid Vaus controller, but it's only one axis, and almost nothing uses it.
The Zapper, but extracting X coordinates in software kinda sucks.
You could do something goofy and treat the power pad as one where the X and Y axes are ludicrously low precision.
The power glove and U-Force also have absolute position modes, but they're not widely used.
For relative position devices:
the SNES mouse, the Subor mouse, and the Hori trackball

I don't necessarily remember an analog stick peripheral, but Thwaite includes support for the Super NES Mouse protocol, which I developed using an adapter that infiniteneslives had made for me. Perhaps the trackpad could emulate such a mouse, where the read values reflect differences in finger position from one read to the next.

NES and Super NES controller protocol is essentially SPI at 5.0 V. N64 protocol is PWM on an open drain line at 250 kHz at 3.3 V. The order of buttons in N64 controller report $01 is similar to the order of buttons in Super NES controller's report.

1. A, B, Z, Start, Up, Down, Left, Right
2. 0, 0, L, R, C Up, C Down, C Left, C Right
3. X coordinate, two's complement, MSB first, -80 (left) to 80 (right)
4. Y coordinate, two's complement, MSB first, -80 ($B0, ?) to 80 (?)

I apologize for not being able to determine the orientation of the Y axis, but several references like this make no reference to orientation, another states "I don't remember which are the directions for the Y-Axis", and the reference that it appears a lot of people had been using has gone 404 ("This page intentionally left blank."), and Wayback Machine has removed it due to robots.txt. I imagine that documentation authors have considered orientation unimportant because anyone programming the Nintendo 64 or constructing an adapter from N64 controllers to anything else would immediately recognize that the orientation is incorrect.

GameCube uses a similar protocol, except the buttons are in a different order.


EDIT: I just realized that 10011 of 110001 posts on this board are mine, and this isn't binary. I have no life.

Ok, lets do it with the SNES mouse then! This gives you guys a way to dev and debug with existing tools. I can implement that maybe in the next weekend or two? Depends on how long it takes me to set up the time-attack competition framework that I'm super excited about

Would you prefer the analog sticks be simulated as a mouse at the center of the screen? or as a literal value instead of a delta? maybe some other way? Also, which analog stick? the right or left?

I'll see about doing a SDL port as well as it will be easier for you guys to test on.

Edit: or wait! we can use the second controller to give the other analog stick input?! so we can have both sticks then!

More information for international devs and taxes: http://forums.ouya.tv/discussion/1008/e ... evs#latest

ARS Thechnica covers EMUya!

http://arstechnica.com/gadgets/2013/03/ ... emulation/

Funny how you call it "a legal emulator" and show pirated multicarts in the menu. :X

hahaha! I was thinking the same thing actually but it was 2am and I was tired so I uploaded it anyway. It didn't originally have that title, but I changed it to that after-the-fact.

Its the iTunes of legal emulation. iTunes has a thriving store, but you can still put MP3s into your library if you really want to. We just make it easier to do it legit than it is to do it any other way.

PS. I inherited some pirate multi-carts from my father-in-law! He got them when he was over seas in the Navy.

Well, legal emulator is redundant anyway, since all emulators are legal AFAIK.

For the people who release their games for free, how would you feel about setting up a donation button in EMUya where people could donate to you?

It's not always whether it's legal as much as whether you want to avoid being sued in the first place. Avoiding the cost of a trial and an appeal is why Red Hat leaves game console emulators out of Fedora even if ROMs under a free software license exist for the emulated platform.

I read about the bleem cases. It appears they didn't sue them for the emuator, they sued them for using screenshots on the box? Bleem won on all counts though. Its good legal precedent.

They sued them because it allowed PlayStation games to be played on non-Sony systems. They probably had some patents on it and such to back it up if needed. Even then, the biggest problem was that the discs were designed to be used exclusively with specific licensed games, so there wasn't even the excuse of homebrew there. Ironically, they probably got pure profit off that since they made money off game licensing and actually lost money on the hardware itself (Bleemcast still required the original CDs of the games to work).

I'm more surprised it wasn't Sega who sued them... Seriously, not only they broke into Sega's system, they dared to promote the emulator at freaking E3 =P

EDIT: also rereading that last post, um, actually Bleem won all the cases. They were forced into bankruptcy because of the costs of going through the lawsuits. If anything, the legal precedent set by that just made it stronger in favor of emulators, not against.

Yeah, sorry about that. I was saying Sony lost. I edited the post.

Maybe they were concerned that publishers would publish for Bleem and not pay Sony any licensing fees. It would be a loss of control over the platform.

Nah, it'd be a pain development-wise (not to mention Bleemcast wasn't perfect, even with the game specific hacks it was quite buggy). The problem is that it encouraged players to stay on the Dreamcast and that obviously was counterproductive for Sony.

Not like it was needed anyway because the Dreamcast died as soon as the PS2 was merely announced (all developers jumped ship simultaneously...).

Hey btw,

We have put the following games pre-installed in EMUya.

Battle Kid Demo (soon to be full game purchase)
Battle Kid 2 Demo
Nomolos Demo
Super Bat Puncher (with permission)
Blade Buster
Streemerz
Alter Ego
Driar
D+Pad Hero
D+Pad Hero 2

We will be adding a link to your website so that people can go directly to your site. (direct attribution)

If you have a specific website you would like us to point to, let me know so I can update the data.

Also, if you are one of the developers of these games and would prefer to have your games (or demos) not pre-installed or linked to, let us know and we will remove it right away.

Also also, if you give your game away for free and want me to put up a donate button, let me know!

Best wishes,
Jon

D+Pad Hero 1 and 2? I wonder how long until the music publishers get those games pulled on a copyright claim for all the cover songs they include.

Because they are interpretive and not literal, I think its technically fair use.

Because I'm not a lawyer, most of this is probably wrong in some subtle way, so please run it by your own lawyer first:

There are two different copyrighted works involved. One is the composition (called a "musical work" in the U.S. copyright statute) and the sound recording (the sound of a particular performance of the composition). The first sound recording of a given composition to be published is produced under license from the composition's copyright owner; subsequent recordings may be produced under a "statutory license" paid through a collecting society. The DPH games don't copy the sound recording, but they do copy the composition. Use of a copyrighted composition in an "audiovisual work" (motion picture or video game) ordinarily needs a "sync" license from the composition's copyright owner. Unlike a statutory license for a plain recording, sync licenses are purely negotiated, and copyright owners are under no obligation to grant a sync license. To use an existing recording in an audiovisual work, one needs both a master license for the recording and a sync license for the underlying composition.

You mentioned fair use, which the U.S. copyright statute defines in 17 USC 107. Given that DPH games use a cover version of an entire song, I don't see how it qualifies under "the amount and substantiality of the portion used in relation to the copyrighted work as a whole". And given the common practice of negotiating sync licenses, I don't see how it qualifies under "the effect of the use upon the potential market for or value of the copyrighted work".

The one thing worse than a cease-and-desist letter is a demand letter, which could bankrupt you because if you don't pay up, they'll sue. The music industry is known for using demand letters (Capitol v. Thomas). Again, I'd recommend getting a lawyer if you're going to be relying on a fair use defense for distributing DPH as a launch title for Ouya.

When I made Thwaite, on the other hand, I tried to make its music sound like parts of the Animal Crossing soundtrack, but I built it out of similar-sounding pieces taken from a composition by someone who's been dead more than 100 years: Ludwig van Beethoven's Piano Sonata No. 8 in C minor (called "Grande sonate pathétique" by his publisher).

Now I'm not trying to demean anyone's work. I just don't want to see EMUya getting taken down by the record industry on the front page of Slashdot, with the highest-rated comments expressing a sentiment that "He had it coming."

If you think that is the weakest link here and may give the RIAA an opening for a lawsuit, I'll pay my IP laywer to take a look and give some advice. Worst case I have to take it off the pre-install list.

I'm not a lawyer but I'm 100% sure that isn't fair use at all. Actually quite the opposite, they're derivative works made without permission and thereby outright copyright infringement no matter what.

Are covers of copyrighted music on youtube also copyright infringement then?

Ok, so from what I can tell, yes even covers on YouTube are copyright infringement. Well, I don't want to be painted as a target, so I'll be pulling those two games from the store. Its a shame really cause those games are really awesome IMO.

Yes, covers on YouTube are copyright infringement. In my experience, however, the copyright owner will usually just flag it as theirs and place ads on it to collect revenue (which is kind of a crappy default, since it screws the cover artist out of their rightful share of the revenue, which under other circumstances is usually about a 9:1 share for the cover artist, but this is the current state of things). The other things might sometimes happen are that they will request that it be taken down, or they will do nothing at all.

However, since these are publicly published songs, you can license them automatically by paying the mechanical royalty rates. In the US if I remember correctly this is roughly 9c per song, per download. There are services like limelight that can assist with this (for a fee). Of course, this royalty is required whether or not you're selling the download.

The mechanical license is only for distributing recordings, such as CDs or iTunes, not for including music in video games. You need a sync license for that, and sync licenses are purely negotiated.

Ah, yes, different rules may apply for video and/or video games. Well, never mind then.

Though, last time I looked it over, there is some amount of arbitrariness about the distinction between what qualifies for mechanical vs sync licensing. I don't think it specifically states the media type (CD or Tape, etc.) but I think there is language about whether it's "interactive"... trying to dig up what I read before but not having much luck.

At any rate it's probably not something you want to start distributing for free with your app.

DPH with the music replaced with original music or Mozart covers could work though.

Just read on NA you implemented a pay per minute cheat system....why? And more so, why would you put a utterly ridiculously price on the price for the minutes? You pretty much just probably lost business from every person who were relatively interested in this by doing that, you know?

tldr; We are changing it to pay-to-unlock. It was a bad idea.

Yeah, that was controversial. With Ouya being free-to-play we couldn't charge for the emulator itself so we had a couple options in mind to help make ends meet. We wanted to try this pay for cheating out first to see how it would work. We give lots of free minutes as well (lots of free minutes to start, daily play bonuses etc), so really it only affects super heavy users. The idea is the revenue would go to the developers of the games and also pay for the storage for the upcoming time-attack competitions (storage gets expensive and we can't do that for free). While we still have hopes that once competitions comes online that things might come around, especially once we balance the minutes per price, we are preparing changing it to a use X minutes of cheat time, then pay to unlock forever. However if we do that, then we must charge for entries to competitions.

What about using the emulator as a vehicle to sell homebrew? People would pay for the games they want and you could hook into the emulators memory to rip out high scores and put them on your own leader-board.

Individual games could be "sold" with micro transactions instead of app store prices. It'd make your product more about distributing (and encouraging) classic console homebrew rather than emulation with its association of piracy.

You could encrypt each homebrew ROM so it couldn't be ripped and "redistributed" to ROM dump sites.

As a side, any word on 2600 emulation? I've got some titles that I could give you approval to use.

That would work, but I did make a commitment to give 100% of game sales revenue to the developers. Which means we have to make some optional emulator features that we can sell on top of that (which is not a bad incentive). I wouldn't feel right backing out on that commitment though without everyone's consent.

So, what we are working on now is a pay-to-unlock certain features instead. Where If you want rewind/slomo, you can pay to unlock it. Same with game genie for a dollar, etc. For competitions, there would be a single entry fee per competition, that you can submit as many times as you like once you have entered once for free.

Or developers could opt in to sharing game sales revenue with you. I would, for example.

IGN demos BattleKid on Ouya

https://www.youtube.com/watch?v=S28GHNHsIDg

I really appreciate that, but there is plenty of time. Lets see if there is a way that I can help support you guys the very best while not receiving any of your hard earned revenue. This is the best case scenario (which may very well not be possible, but I have to try).

One option would be to open up NROM for free which covers most homebrews anyways. But then charge to unlock other mappers. Even still it seems like a challenging task to earn money off an emulator. Just based on the other devices out there capable of performing emulation it won't be long before someone is willing to offer an emu for free. Even if your emu is leaps and bounds better, to the average user they are pretty much indistinguishable. They either play your rom or they don't, that's all I knew 5 years ago.

Not that I have any game I'd like to release, so I'm speaking with little weight here. But it the fact your emulator is free and popular among users is a bigger advantage than letting me keep all the money from rom sales. I'd be concerned the unpopularity of the emu to it's users based on some sort of pay to play charges for the emu would stunt overall sales of my rom. In other words I'd rather share some small portion of $1000 of sales with you than have $300 of sales all to myself. Obviously I don't have any market data behind those numbers but that would be my concern/prediction as a developer. I know you 'promised' to not take any of the developers income, but I'd fear you'll soon be taken out in the OUYA emulation competition by someone who will... It's noble of you to not want to dip into the earnings of a developer, but it doesn't sound like a recipe for success.

Anyone with half a brain is going to get by with paying as little to no money as possible if they just want to play mario. The appeal of your emu is that they could then be introduced to a developers game via advertisement within you emu and be convinced to pay to download the new homebrew game. So if the emu is completely free the user isn't paying money to get advertised to about the developers game. But if you have some sort of pay to play structure on the emu alone, the developer is only able to advertise to people who are willing to pay money to be advertised to. Not a lot of people are interested in spending money to be advertised to...

Pay to play is only the case where the developers sell their games. Otherwise, all games are free to play. However, we are asking people to pay to unlock some forms of cheating. Save states are free, for example, but rewind/slomo is not.

The most popular NES emulators on Android are ad supported with pay to get rid of ads. We are also considering that, but I really really don't like advertisements - so thats probably the very last option on the table. I think we would even do donation based over that if we could.

The advertisements I was talking about would be more along the lines of when you open up the emu and select your rom there would be some homebrew demos pre-loaded into the emu that would get people's interest and have them try the game/demo. More of an indirect advertisement of exposing the roms that you/developers are selling.

Paying to unlock advanced features like save states and cheats/game genie type stuff sounds like a good approach too. Really all I was trying to say is that if/when I make a legit homebrew game I for one wouldn't be against sharing a portion of the sales with you. You're going through a lot of time effort to allow a developers games to be sold on this media and I don't think it's unreasonable for you to get compensation because of that.

Any word on the Atari 2600 side? I could see SaveKey emulation used to extract high scores and support save games. That could be another pay feature, methinks.
http://atariage.com/forums/topic/176797 ... ox-eeprom/

Sorry I've been pretty swamped with my normal job. We are doing open beta in a couple weeks for Firefall and I have a mountain of work. I get a few hours on the weekend to work on EMUya, but my next big target is MMC5 support. After that is game genie. Then NES emulation is "done" so far as I'm comfortable with the breadth of mapper support for a while. After that Atari 2600 is next on my list.

Ok, the latest EMUya was just rejected because apparently when I link to your website from inside the game ("Visit the developers website"), some of you have donation buttons on your website. This is apparently against their new TRC and they don't allow that. Since I can't control this - I can only allow links to sites which do not contain donation buttons on them. Until then I'll disable the button for people who have "donation solicitations". (personally, I think this is retarded, but I can't control Ouya's policies)

New version is live Thanks for everyone's patience!

Good news! After some back and forth, we got them to reverse their position on us linking to your websites (even if you have donate buttons on them)! =D This is fantastic of them. Ouya has really shown their good side IMHO.

EMUya on Wired.com!

http://www.wired.com/gamelife/2013/06/ouya-launch-games/#slideid-57721

More press for STREEMERZ/EMUya, made #4 on this list: http://www.gamesradar.com/best-ouya-games/

Fantastic! One of my favorites as well!

Now I have tried this aswell. Great NES emulator! Awesome that you included these great homebrews. I really like the idea.

I have not got any other roms to work yet. I tried putting them on a USB stick. In "roms" folder. But they don't show up. I just played with.my OUYA for a couple of hours. I guess I will figure it out.

Nova and I figured it out. You have to first install a file manager.

1. Under Make > Software, select the planet, which represents Android Browser.
2. Using the touchpad, drag around until the address bar appears. Moving your finger moves the mouse pointer, a tap produces a click, and a tap and move produces a drag.
3. Enter forums.nesdev.com into the address bar.
4. Browse to this post.
5. Click here to view the description page of Rhythm Software File Manager. (File Manager HD won't work.)
6. Click "Download". (The Google Play button won't work.)
7. Under Manage > System > Advanced > Storage > Downloads, select "FileManager.apk".
8. Under Make > Software, select File Manager.
9. Click Up repeatedly until it turns gray.
10. Select "usbdrive".

Do you see your files in the usbdrive folder? Or did you get hung up on a step?

Thanks! =D

I would recommend restarting the Ouya as its kind of finicky when it comes to USB sticks. Also, another possibility is that the connector pins are depressed in the USB connector on the Ouya. I've heard of that too.

I don't want to get anybody's hopes up entirely yet as the contracts are not yet final, but after many failed attempts, I believe I have convinced Sony to allow a form of EMUya on the PS4! =D

Holy s...., are you serious?!
I mean, it doesn't even sound real for some reason...
I mean...NES emulator, on. on sony ps4. I mean, approved. Will nintendo not do anything about it?
I'm clueless about lawsuits, so sorry If I'm making no sense.

If end users can't load their own ROMs, all ROMs would have to be approved as DLC by the console maker. Oriku could offer games under a free software license or other redistributable games, and Capcom, Konami, Namco, Sunsoft, Sivak, Faux Game Company, etc. would be able to offer their own games as DLC even if Nintendo chooses not to.

I haven't yet signed the contracts. As written Sony owns EMUya and anything else we develop on the PS4 out-right, for free. So, I can't sign the contract they want. However, assuming that we can get the contract issues worked out, yes, it should happen. Also, I'm not sure if they will approve EMUya if it allows side-loaded ROMs. I'll try, but I can't guarantee success. However, all the home-brew games will be available

I don't think you should be talking publicly about something like this, Sony will most likely pull back immediately o.O


They can't do anything about it unless their ROMs are involved. They can't even use the patent excuse since all patents are expired, and there isn't anything copyrightable on the NES itself that needs to be emulated (the only thing that comes to my mind is the lock-out chip, and why would you want to emulate that?).

If the init code or the controller reading code or certain nametable drawing code came from a library owned by Nintendo, this may affect a game publisher's right to distribute its own game on a non-Nintendo platform. But given Konami's release of the Castlevania and Contra compilation for PC, this isn't likely to pose a problem.

I didn't hear about this aspect of indie development from Sony. Might hurt their "we're the opposite of Microsoft" image if everyone knew they took all your rights away as a developer.

I could only assume that they would consider anything loaded under the EMUYa wrapper theirs too. This would be a problem as one of my games is based off of a movie which I personally do not own the rights to (just permission to use).

The sad part is I think this is their default contract that they make everybody sign. I've had two lawyers look it over and say the same thing. He also said that he didn't think that was in the spirit of the contract, but since the words of the contract quite literally actually do say that Sony owns it if there ever was a conflict you'd be sure they would use that against you and you should not sign it.

But then one of the services that lawyers offer to businesses is drafting an amended counteroffer that more closely represents the spirit of the contract.

ObNES: I seem to remember that one of the reasons that the FDS died was that Nintendo's FDS contract was discovered to be similarly overreaching, but Wikipedia editors can't seem to find a citation for this.

As far as I can tell, you still may be able to do something which isn't normally allowed by the Ouya contract as long as the program isn't distributed on Ouya, for example if it is on PDROMS. Of course this may not be suitable for many purposes, but it exists in case someone does need to do that, for example if someone makes some open-source NES/Famicom emulator for Ouya that can load external ROM images, it may be distributed on something else and the user will need to know how to install external software (although I believe documentation for doing this is provided, although it is probably more difficult than installing official software anyways, but I suppose that's OK).

This is not one of those situations, I assure you The entire contract is very one sided.

Sorry guys. Sony says the terms of the contract are non-negotiable - even after climbing the ladder and talking directly to Adam Boyes who is the head of the indie department. I can't in good conscience support a console company whose motives are questionable. They seem extremely anti-indie friendly the moment you step out of the PR and into reality. Their contract has many statements of varying 800 pound gorilla tactics severity, and I simply can't put my company and ultimately my family at risk for the sake of EMUya.



That means that anything we ship on the PS4 Sony owns (including your games maybe even). There are also terms in the contract which will quite literally bankrupt myself for life would worst cases (which are not impossible by any stretch) happen.

On the up side, Amazon is releasing a console this year as well. Their console is much more open, so I intend to ship EMUya on it.

Out of curiosity, how does the contract define "Next Gen Materials"?

And even before that, the Kindle Fire HD has Bluetooth, so you could probably whip up drivers for PS3 and iCade 8-Bitty controllers and toss EMUya on Amazon Appstore.

It's too bad the Ouya has controller lag like crazy. It doesn't only affect EMUya, but any fast paced game. At least for me.

Is it controller lag, or is it Android's well-known problem with audio lag plus the fact that TVs tend to have more lag in general than computer monitors? The real problem is that OUYA forces HDCP on its HDMI output, which interferes with several lag-killing solutions I could think of.

Essentially, anything and everything.

My TVs has a game mode which improves lag dramatically for me. You should check your TV too.

My Vizio VX32L is on game mode, but there's still a bunch of lag. On the OUYA main menu, for example, I can switch between PLAY and DISCOVER, see the highlight move, and hear the sound effect a quarter of a second later. Another problem is how to report emulation errors without being able to record and send video due to HDCP.

I have a movie ("replay") recording system built-in to EMUya. If you send me one of those files, I can easily repro errors

From what you say it seems that HDCP is the worse feature of OUYA, and that is probably correct; HDCP is the worse feature of many things (so is HDMI; someone suggested a VGA output and that probably would be a better idea (although better than VGA and HDMI, I think, is my own "Digi-RGB" design, which is sufficiently simple but nothing supports yet; if you want remote control and video/audio combined cable then you use also what I have made called "Digi-RGB-Plua")). It is Android system and they say is open source and standard screws, so maybe it is possible to remove HDCP (at least for some software; doing so might cause other software to stop working if it explicitly uses the HDCP features of the graphics chip).

EMUya is coming to a new platform soon Can't say much due to NDAs right now, but its going to be pretty darn awesome. Will tell more as soon as I can.