Is it possible to run a cartridge on an emulator on your computer in theory?
Yes with a cartridge bus<->computer bus bridge.
That's what you're doing every time you play a game, though the "computer" is a combination of your PC, your cable modem, the Internet, and similar on the side of whoever originally dumped it. I take it you mean run the cartridge on an emulator which accesses the cartridge as the emulated game does. That can be done. An emulator could be modified to use one of those parallel port-based cartridge dumpers for every access.
- Looks pointless...?
I don't think you can run the pport things fast enough for that to really be viable, short of dumping it to memory ahead of time, which'd require knowing the mapper numbers.
Supporting IRQs properly probably isn't doable either, especially MMC3 ones.
Supporting IRQs properly probably isn't doable either, especially MMC3 ones.
There's the retrode. www.retrode.org
Not NES but it proves it can be done.
Not NES but it proves it can be done.
blargg wrote:
That's what you're doing every time you play a game, though the "computer" is a combination of your PC, your cable modem, the Internet, and similar on the side of whoever originally dumped it.
The step with the Internet and a remote dumper is what ROM copyright owners rightly complain about. It's legal under United States law if you use your own dumper (17 USC 117) but not if you use someone else's dumper. One problem is that the NES has two buses, and Retrode doesn't appear to directly support that.
Ahhh, I see. Even just the NES CPU access memory at 1.79 MB/sec. But you'd have to communicate the 16-bit address along with the data to be written/read over the parallel port, requiring 3 times that bandwidth at minimum. And then there's the PPU...
and polling the IRQ line properly
and broadcasting *every* ppu access over the thing to keep the MMC3 counter correct
and toggling M2 at 1.79MHz to keep the various cpu cycle based counters working
etc
Some sort of magical add-in card might do it, but there'd be a lot of complications to get sorted out in pipelining the reads and dealing with the clock domain issues, and that's after the (admittedly somewhat trivial) problem of level conversion.
and broadcasting *every* ppu access over the thing to keep the MMC3 counter correct
and toggling M2 at 1.79MHz to keep the various cpu cycle based counters working
etc
Some sort of magical add-in card might do it, but there'd be a lot of complications to get sorted out in pipelining the reads and dealing with the clock domain issues, and that's after the (admittedly somewhat trivial) problem of level conversion.
The Retrode seems to be simpler than that. I think basically all it has to do is read the whole cartridge sequentially a single time. After that the device would probably do nothing except wait for the emulator to write a save file.
CopyNES can do that already, but it's not conveniently automated like that. You also have to know what mapper you're dealing with, which is mostly a problem unique to the NES because of the hundreds of different boards.
That's way easier too than making some kind of super high-speed add-on card for a PC (though it would be cool).
CopyNES can do that already, but it's not conveniently automated like that. You also have to know what mapper you're dealing with, which is mostly a problem unique to the NES because of the hundreds of different boards.
That's way easier too than making some kind of super high-speed add-on card for a PC (though it would be cool).
Something like Retrode is the most practical if you want to use real cartridges. I guess for NES or SNES games with special chips it would be cool if you could somehow use them but I've heard that's impractical.
I wonder if they will make a Retrode for the NES. I suppose it'd be alittle harder with the mappers particularly if you were to support people using adapters for Famicom cartridges.
I wonder if they will make a Retrode for the NES. I suppose it'd be alittle harder with the mappers particularly if you were to support people using adapters for Famicom cartridges.
MottZilla wrote:
Something like Retrode is the most practical if you want to use real cartridges. I guess for NES or SNES games with special chips it would be cool if you could somehow use them but I've heard that's impractical.
I agree, that would be neat. Then the emulator would just focus on the base system and not memory maps and such, that have nothing to do with base hardware. Then most people could run bsnes at full speed since it no longer needs to emulate the cartridges.
The vast majority of the CPU time bsnes uses does not have to do with the cartridge. I'd go out on a limb and suggest that cartridge mapping emulation (outside of ones using the SA-1, or SuperFX) is almost completely negligible compared to PPU/SPC-700 time.
HJRodrigo wrote:
I agree, that would be neat. Then the emulator would just focus on the base system and not memory maps and such, that have nothing to do with base hardware. Then most people could run bsnes at full speed since it no longer needs to emulate the cartridges.
"Emulating the cartridges" isn't something that impacts emulation performance. Infact attempting to directly use the original cartridge would be terrible because of the inability to really interface with it in real time. It would be nifty if you could use the cartridges in real time yes, but there is nothing to be gained from it other than if you could use the original mappers for NES, or the coprocessors in SNES. But that would be an issue for some as precise console eumlation may be needed for some of these chips like MMC5 for NES and SA-1 for SNES.
ReaperSMS is right. The reason BSNES is so demanding is there is alot of processing time for the CPU,PPU,SPC, etc. Accessing the memory of the cartridge is hardly anything at all.
MottZilla wrote:
HJRodrigo wrote:
I agree, that would be neat. Then the emulator would just focus on the base system and not memory maps and such, that have nothing to do with base hardware. Then most people could run bsnes at full speed since it no longer needs to emulate the cartridges.
"Emulating the cartridges" isn't something that impacts emulation performance. Infact attempting to directly use the original cartridge would be terrible because of the inability to really interface with it in real time. It would be nifty if you could use the cartridges in real time yes, but there is nothing to be gained from it other than if you could use the original mappers for NES, or the coprocessors in SNES. But that would be an issue for some as precise console eumlation may be needed for some of these chips like MMC5 for NES and SA-1 for SNES.
ReaperSMS is right. The reason BSNES is so demanding is there is alot of processing time for the CPU,PPU,SPC, etc. Accessing the memory of the cartridge is hardly anything at all.
Real time reading of the cart is the whole point
, if it is not real time one might as well just dump the rom. bsnes system requirements increased when he added the ability to play one of these special chips. So saying ""Emulating the cartridges" isn't something that impacts emulation performance" isn't accurate at all. Some may have a minimal effect, but logically adding any more instructions to a code will have some effect.The add-on chips (SuperFX, SA-1) would be pretty much impossible to interface to properly through a cart adapter, given the aforementioned port rate issues.
Merging the video from a SuperFX in properly would also be a goddawful mess, as that's going to be running even faster.
For anything else, the added instructions don't have much of an effect, as the bulk of the added cost is in decoding teh address to figure out what to do with it (have to find out when the code is writing to PPU registers for instance) and the added cost is so miniscule as to not be worth mentioning. Adding a couple of instructions to the access, when you're burning a million+ cycles on PPU+APU+CPU emulation is completely meaningless.
Merging the video from a SuperFX in properly would also be a goddawful mess, as that's going to be running even faster.
For anything else, the added instructions don't have much of an effect, as the bulk of the added cost is in decoding teh address to figure out what to do with it (have to find out when the code is writing to PPU registers for instance) and the added cost is so miniscule as to not be worth mentioning. Adding a couple of instructions to the access, when you're burning a million+ cycles on PPU+APU+CPU emulation is completely meaningless.
I said accessing of cartridge memory. Not the impact of emulating a coprocessor. Ofcourse it makes BSNES need more computing power to emulate something like SA-1. But there is no practical way to use a real SA-1 in conjunction to take that load off.
If you are concerned about BSNES's performance, buy a new computer. It doesn't that that expensive of a PC to run BSNES well. Also the increased requirements are not due to adding the "special chips". Yes games that use them will take more than games that don't, but games that don't would have incurred minimal related increases. Other increases would be all the non-special chip code that gets changed and added.
If you are concerned about BSNES's performance, buy a new computer. It doesn't that that expensive of a PC to run BSNES well. Also the increased requirements are not due to adding the "special chips". Yes games that use them will take more than games that don't, but games that don't would have incurred minimal related increases. Other increases would be all the non-special chip code that gets changed and added.
MottZilla wrote:
If you are concerned about BSNES's performance, buy a new computer.
I'm looking to buy a new PC. But I'm into small form factor; I don't want a PC whose case is bigger than, say, an Xbox 360. Would bsnes work well on an Acer Aspire Revo (Atom CPU, GeForce 9300 GPU)? Or does it demand a full-size minitower PC?
Quote:
It doesn't that that expensive of a PC to run BSNES well.
I recently bought a Dell Mini 10. Does bsnes work well on low-end laptops? Or if I'm on a laptop, should I stick to developing game logic using the "inaccurate" emulators and then testing it on bsnes and a PowerPak once I come home to a full-size PC?
MottZilla wrote:
If you are concerned about BSNES's performance, buy a new computer. It doesn't that that expensive of a PC to run BSNES well. Also the increased requirements are not due to adding the "special chips". Yes games that use them will take more than games that don't, but games that don't would have incurred minimal related increases. Other increases would be all the non-special chip code that gets changed and added.
LOL, I run bsnes just fine on my desktop. Although I acknowledge there are ppl out there that are not as fortunate as me. The point is that it would be neat to play with actual carts. This issue came up years ago on the ZSNES forums (I think it was about 6) and data transfer/reading rate was already blamed/determined to be the reason nobody had tried or done it. BTW just a little nitpick issue, but byuu doesn't want it written as BSNES. He like the b to be lowercase for some reason.
Quote:
Would bsnes work well on an Acer Aspire Revo (Atom CPU, GeForce 9300 GPU)? Or does it demand a full-size minitower PC?
As far I know Acer == Low Cost crap. BSNES works fine with NTSC filter on my 14'' Lenovo laptop, so I guess it'll work with anything with about equivalent processing power, that is 2.6 GHz dual core.
bsnes doesn't work so well on my netbook with Atom N270, neither does Nintendulator; both achieve poor framerates.
A little bit off topic but what emulator would run well on an atom Z520 for nes/snes debugging, if any? That CPU seems a lot weaker than a N270.
When I went netbook shopping I opted for the Gateway Netbook with a 1.2 Ghz Athlon 64. It runs windows 7 just fine and it does Snes emulators just fine. Although I sometime can tell it's single core, it performs as if it were a 2ghz machine at least. I'm well pleased with it. I've seen a few Atom based netbooks that my customers have and I'm glad I went with the Athlon. I want to try it with a 64bit windows but I don't like the prospect of formatting it just to switch to a 64bit OS.
http://gizmodo.com/5300552/gateway-lt31 ... multitouch
http://gizmodo.com/5300552/gateway-lt31 ... multitouch