I missed out on the delightful thread others are referencing, however I did eventually read it all after the lock. puzzledude had some very strange ideas that only got stranger as that one went on.
I was linked http://sm64-hacks.square7.ch/?p=97
a while back around here which was a very amusing read to me.
I mainly come from the GBA and DS world where to the best of my knowledge there are no emulator only hacks (the hardware was pretty accurately emulated from day 0 really owing to leaked hardware docs ahead of time), give or take what people might have done with the Lua supporting emulators. Some say that non hardware support is outside the scope of RHDN and maybe it is, the Lua folks I would strongly argue to not be tarred with that brush and welcomed as any other hackers/skilled types might be.
For me the GBA and DS probably represent the pinnacle of 2d game playing hardware, though the SNES (and NES if you like the 8 bit aesthetic) is certainly no slouch and some of the software defined libraries that the PC can and does do these days utterly eclipse both -- https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true
is a great read and covers the hardware developments that made for the differences. Ultimately they can and do have means to create fantastic games that hold up today. The N64 hardware was questioned at the time ( http://www.actsofgord.com/Propaganda/chapter02.php
) and time has not been kind at all and to that end I can support emulator only/emulator enhanced stuff there. Some of the N64 (and GC/Wii, possibly also PS2 but I have not gone deep there) folks have some very odd ideas -- the 800 meg texture replacement hacks that are just for translation purposes where about hour 2 of learning ROM hacking would have covered text systems and also spared the troubles with a branching storyline... but that is something I can treat as an unhappy accident.
Emulator only as some kind of anti repro measure... fuck that, possibly with the proverbial rusty spork. You want to put up screens saying "if you paid for this you...", protect those screens by in hardware capable technical means (so probably some kind of checksum or simple compare check), put in text in the game saying the same, possibly have your own kind of anti piracy game breaking/tweaking thing (enemies 10 times harder, no rare drops....), some kind of hardware capable obfuscation (I have seen people trash lookup tables and rebuild them during runtime)... it is all good. If you get in the way of cheat making/game tweaking I might not be happy but eh really and that one is on you. I do not really share the near visceral dislike that some around here seem to have for it, though at the same time if you want to document messing with their auction listings, hosting, the results of adding late game traps in code, laughing at the poor understanding of electronics and inflated egos (some seem to think they are doing good electrical engineering, I content my blind monkey with the alcohol shakes could do most of what I see for the NES and SNES stuff, some of the more modern GBA stuff you might need someone versed in basic electronics repair though) then I will be there with my popcorn and a high five, and similarly I am not going to be caught helping them excise said protections/frustrations.
Back towards the topic the option to expand the ROM is one I would have to accept as nice -- again I come from the GBA and the GBA has 32 megabytes of directly memory mapped ROM (no mappers, no banks, no windows -- all there directly in CPU/standard memory bus in every dumped game*), the average GBA game is 16 or less. The DS is even better (worse?) in that you can expand a ROM into the gigabytes and probably not so much as have to know what a pointer is, if you want to expand a sub file to the large sizes you might have trouble as some do use 16 bit pointers for internal sizes/locations but that is still not usually that troubling (if you are adding megabytes of text you probably already know what you are doing, and if you are adding megabytes of graphics you will probably have run out of VRAM long before).
The NES and SNES used hardware driven expansions at the time though and though space might not be such an issue if you know what you are doing it is far from unheard of for it to be one. To that end I have to at least consider how emulation and modern electronics (my $10 arduino would probably trounce an expensive 1990's FPGA and certainly the CPLD or PAL chips of the day) might help matters of expansion. On the other hand getting people to agree on a header format or other software defined things is a pain so I hold no hope of any hardware based/implementable standard coming to pass.
When most spoke of such things before it was usually dealing with either bugs or less strict emulation -- assuming you had what is basically an infinite stack to shuffle graphics or audio into for the SNES I believe it was. You want something like that and it is lua or equivalent or nothing for me.
*shrek and shrek 2 came as full films under the GBA video banner and those are undumped, they are presumed to be using some kind of bankswitching as the other (32 megabyte) GBA videos are considerably shorter than a full film. Likewise some homebrew could break the limit with certain flash carts (pogoshell if you want to go looking). In the end though nothing that really matters. I probably should mention Mother 3 though and say it is probably the only game, unless some new beta for something gets unearthed, that uses all the space and does not have a generous amount of padding available to play with (the 32 megaabyte, or 256 Mbit if you go around in GBA circles, list is short enough that I have looked at basically all of them in some capacity).
To further confuse my position, or make it more complex if you are being nicer, then for the most part I am all about the results from a game playing/game theory perspective. Some have something of a wary disposition when it comes to tool driven hacking, and it does send the signal to noise ratio way into too much noise territory, but one of my favourite hacks in general was a tool made one for pokemon* and was kind of a boss rush (it used a starter save to set things off at a baseline) and pretty highly polished at that -- no grinding, no mass of items, just having to know the way to beat things. By the same logic though I have to wonder if something more emulator only could not get something done.
*some around here are not fans of pokemon. I do not like the games (the GBA sported far better "clones" in the form of medabots RPG and robopon to name but two) and have been staff in various forms on GBA flash cart and emulation forums/sites for years so I am pretty sure my dislike is higher.
In the end I am not sure where I sit with regards to expansion. If it is something obvious like you have two extra storage banks but use a 2 bit command to select and thus have two redundant commands that could mean you have four banks then I could probably see my way to criticising most emulators (if you have to have the entire ROM in memory on a low memory system then maybe but those are getting a bit thin on the ground of late -- 512 megs is considered a crazy low amount of memory for a phone after all) and maybe even some flash carts for not including it. I am less keen about someone managing to bolt on some crazy modern ARM or MIPS processor (or I guess a FPGA with a decent gate count), even if the results are pretty cool, and then criticising things. If RHDN wanted to adopt some kind of hardware or lua only policy then that would not be a bad thing, at the same time I am not going to call for that. I will call things that will likely not ever be playable in hardware poor form though.
So as ever I have waffled for far too many paragraphs and at best my contribution will have been to link up some sites that see people have a wasted morning in reading them, though acts of gord is far more amusing than tvtropes or wikipedia for that one.