131–140 of 143 posts
Earlier quoted context omitted.
Your comment would IMHO be a lot better without the first paragraph speculating about other commenters.
The comments would be a lot better without seeing 6-7 completely reasonable posts being mass-downvoted and greyed out with a bunch of people complaining and seeing their comments solidly in the black. So no, I disagree with your premise, hence why I posted it in the first place.
This hits on something I've wondered about for a long time. Since carts did not just include data, but also mappers and coprocessors, how do you write an emulator that can accurately play an arbitrary ROM dump? Does your emulator have to have knowledge of every single game, and what mappers and/or "helper" chips each had, and emulate just the ones appropriate for a given game?
NES mapper numbers were standardized among emulator authors. Look for "NES mapper list". Some very early games didn't use a mapper (that's what mapper 0 is).
Earlier quoted context omitted.
Less clickthroughs = more engagement = better viral loop Thats the why, since you asked
Somehow I don’t think that’s foone’s motivation at all.
There is a patreon page linked right on his twitter page. He may not be exchanging time for food and shelter, but he is playing the same marketing game as anyone else for a personal high score.
linking to a blog he has to maintain would drop engagement off a cliff
Earlier quoted context omitted.
The most hilarious enhancement chip is the SA-1, used in the Super Mario RPG and other games. https://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_... It's essentially the same exact chip as the SNES's main CPU. Except three times faster. Imagine buying a game for your 3ghz PC that ships on a flash drive. And that flash drive also contains a 9hz (edit: whoops, 9ghz, haha) Intel Core i9 CPU.
A 9hz microprocessor would indeed be something. Start the game up, come back 10 days later and one frame would almost be rendered...
This hits on something I've wondered about for a long time. Since carts did not just include data, but also mappers and coprocessors, how do you write an emulator that can accurately play an arbitrary ROM dump? Does your emulator have to have knowledge of every single game, and what mappers and/or "helper" chips each had, and emulate just the ones appropriate for a given game?
That brings up another interesting point. foone says the ROM data dumped would be identical, but that’s disingenuous. The DSP firmware is part of the cartridge, too, and it is clearly different. byuu has proposed catenating the DSP image to the base ROM for this reason. Of course, the Pilotwings case was unique, being the only game to ship with two different DSP firmwares.
A lot of people are complaining about twitter as the delivery method for this kind of content. I actually really like it, having things broken up like this makes it much easier for me to digest because of my ADHD
This hits on something I've wondered about for a long time. Since carts did not just include data, but also mappers and coprocessors, how do you write an emulator that can accurately play an arbitrary ROM dump? Does your emulator have to have knowledge of every single game, and what mappers and/or "helper" chips each had, and emulate just the ones appropriate for a given game?
If you're talking about an MSX game, then yes. Nothing about the carts are preserved in the ROM images, and you need a per-game database, or you'll need some kind of "cartridge type" list that the user has to choose from when booting the game.
If you're talking about the NES, sort of yes. People stick a fan-made "iNES" header at the top of the ROM data, but they made the format before all the details of the NES were known. So using that information is not enough for many titles, and so you need a database for those titles to work properly.
For the SNES and Genesis, the games have internal headers that tell you most of the details of the games, but not enough for complete emulation. SNES emulators in the past have been able to add bizarre tricks that just so happen to line up with the existing commercial games to not need a database, but it really turns out to be a mini database disguised by being obtuse. Example: "if the ROM is larger than 2MB, and has save RAM data, and has 32K bank granularity, then map the save RAM data to a smaller area of memory." Rather than "if the game is Fire Emblem, treat it differently than Ys 3."
For the Game Boy Advance, emulators and flash cart tools will scan the ROM looking for signatures from code libraries from Nintendo that handle save memory, like "FLASH512_V", "EEPROM_V", "SRAM_V", etc. Developers wised up and started including fake strings to fool them, so once again ... you end up needing a database.
There's very, very few cartridge-based systems where only the ROM dump is all you need. If I had to name one, I'd say the Neo Geo Pocket is one.
There are even cases like Mega Man X (Japan), where they made a mistake with the copy protection, and to fix it, resorted to wiring a resistor right onto the back of the PCB of every cartridge released to change the memory map.
And databases + heuristics fall apart when it comes to homebrew, fan translations, ROM hacks, etc.
True preservation requires games include a detailed description of the entire PCBs of these games, not just the ROM chips. But unfortunately, after trying for 15 years, I've not been able to come up with a stable, simple format for every system in the world that doesn't rely on emulator-specific design decisions.
I mean, how do you represent every possible circuit board configuration on the planet in a text file, that isn't going to make emulator authors for just the NES or just the Game Boy balk?
Earlier quoted context omitted.
A 9hz microprocessor would indeed be something. Start the game up, come back 10 days later and one frame would almost be rendered...
It might even be longer than that... I wonder how long it would take to render one frame of a modern game by hand if everyone on the planet joined in (let's make it easy and render at 160x120).
One floating point calculation for a human would probably take on the order of 2 minutes. That's 1/120 FLOP. Let's round it to 1/100. It's not like we're accurate here.
Let's say a GPU is 1 TFLOP. That means the GPU is 100 trillion times faster than a human. With 10 billion humans on earth (again, let's just round these numbers), that makes the GPU 10000 times faster than the combined power of all humans.
I don't think computational requirements scale linearly with resolution, but let's just assume it does. Your regular 1080p screen has roughly 100 times the pixels compared to your 160×120 screen. 10000/100 = 100, which means that the framerate of your manually computed game will be 1/100 of the performance of a regular GPU playing in 1080p.
I welcome someone else to make the same calculation. It'll be interesting to learn if I'm close to a reasonable answer.