Can you tell me what the hardware specification is so that a custom firmware can be written by the users? (I am not likely to purchase one if it lacks this feature)
Sure! The controller is an AT90USB646, and the slots are wired directly to ports A-F. Write away :)
Thank you for the information! (I do understand that this will void the warranty; of course I won't change it if I need the warranty!) If I purchase this device, I might write a raw-mode firmware, making the computer program do interaction, and allowing add-on chips in the cartridges to be used; so that the computer doesn't emulate mappers. Of course this requires emulators and/or dumping software that can do this. Obviously not everyone will want this; you can (and definitely should!) keep your own firmware installed by default, but a user could install this one (if I write it, it will certainly be open-source) and possibly void their warranty if they don't care about the warranty.
Sounds like a cool plan; I'd be seriously impressed if you manage to pull this off! You'll definitely be in for some hard work, though. Not only will you need a complete re-write of the R2 firmware, but you will also have to re-invent at least 70% of the emulator side. Furthermore, I see the following potential issues:
Pinout - The Retrode doesn't connect to the 2x8 expansion pins that are used, for instance, by the Super FX or SA-1.
Clock rate - The Retrode is clocked at 8 MHz; replacing the crystal will only get you as fast as 16MHz. Even if you change the wiring to deal with special chips, you will have to underclock them.
Transmission speed - Is Full-Speed USB (12Mbps) even fast enough for real-time emulation? I mean, both in terms of raw data rate and response time (minimum data packet sizes).
I'll be happy to provide you with more detailed wiring information as your plan evolves.
Cheers,
Matthias
I'm not sure what zzo38 has in mind, but what I'd like to see is a "proxy" firmware - which executes commands from the host and does nothing more, no fancy mass storage.
emulators usually read complete rom before they even start emulation. thus, modifications to any emulator would be trivial, a hook to fopen would do the trick :)
I can't help but thing that it will be much easier to write such firmware if Matthias_H shared his code, cough, cough :)
Quote from: madmonkey on 25/Jan/2012 10:23:16 PM
I can't help but thing that it will be much easier to write such firmware if Matthias_H shared his code, cough, cough :)
Dear madmonkey,
I just spent a lengthy e-mail to explain to you why I'm hesitant to release the source to the general public. You know that I have shared the Retrode code with quite a bunch of people, but you also know that if all you have in mind is to poke around without a serious intention to help (e-mail proof withheld for the time being), you won't be one of them. Going open source doesn't only mean a significant risk but also a MAJOR effort if you want to make it a success (just because the source is there doesn't mean anyone gives a damn, let alone improves on it). In its current form, the could would need major rework before it could be released to the public.
That said, if someone can come up with a (serious) roadmap to transition to open source, I'll be all for it. Obviously, a significant background in embedded programming is a must, and you'd definitely need a record of successfully run open-source projects to convince me.
Matthias_H, there is no need to be so defensive, I'm not your enemy. If you don't want to share the source, just don't, nobody can force you to do it. And I definitely don't want you to share it with me personally, expecting some kind of "dedication" in return. I just honestly told you that I can't promise anything.
that said, it seems to me you're misunderstanding the purpose of open source
Quote from: Matthias_H on 26/Jan/2012 06:32:49 AMGoing open source doesn't only mean a significant risk but also a MAJOR effort if you want to make it a success (just because the source is there doesn't mean anyone gives a damn, let alone improves on it). In its current form, the could would need major rework before it could be released to the public.
risk, maybe, I'd say there is very little, but you should know better than me.
but otherwise open source isn't there for everyone to give a damn and improve on it, it's there so you can use it if you need it. it doesn't have to be "perfect" - there is no such thing as perfect code, so I'm not sure why you'd need a "major rework".
but personally I'd be very happy with just the aforementioned "proxy" firmware, and I don't care who writes it :)
Quote from: madmonkey on 26/Jan/2012 09:36:25 AM
but otherwise open source isn't there for everyone to give a damn and improve on it, it's there so you can use it if you need it.
Except that this is exactly the status quo without open source. Whoever needs it gets it :)
Quote
but personally I'd be very happy with just the aforementioned "proxy" firmware, and I don't care who writes it :)
Yeah, I think you got the latter point across very clearly.
Quote
it doesn't have to be "perfect" - there is no such thing as perfect code, so I'm not sure why you'd need a "major rework".
Dude, I wrote that code you're talking about. Why don't you just believe me that it contains some things that are fundamentally uncompatible with an open source release? I'm not talking about a few rough edges here.