nesdev.org

Trade game items online using save games. You could program an emulator to modify its memory in specific manners in-game to reflect items obtained from other users. This would make non-multiplayer games multiplayer, in a way.

Player auto-translation. Offer a translation of all the lines in the game, grouped by area. The player scrolls through a list of untranslated lines, and upon clicking a line receives its translation.

How would trading game items online be compatible with the other common emulator feature of save states? Otherwise, I could just reload an old save state and set up a money faucet.

I don't see how the auto-translation would recognize the text on the screen. First the player would have to somehow figure out how the text is encoded in the ROM. If it's compressed, it won't be literal in the ROM, and if it's doing some sort of pseudo-bitmap trick (Faxanadu, Super Bat Puncher, and some things I'm working on), it won't be literal in the nametable.

FCUEXDSP-CE and FCEUX support text hooking, but you need to construct your own .TBL file first, and automatic translation sucks with Japanese when it's all katakana or hiragana with no kanji.
It might be better for English>Spanish translations, or other European languages.

The UI still needs a little work.

I had a lot of ideas that could work with many emulator programs in general:

• Record specified memory locations by time.
• Track uses of memory as instruction/data/operand/nothing.
• Breakpoints.
• Custom plugins for input/output/audio.
• Specify configuration profiles for individual games.
• Emulate unofficial opcodes (unless option is set to disable this and cause error instead; might be useful in case you are making something and might not work on other emulators, hardware clones, or newer version of hardware, or to find obscure bugs).
• Ability to load program from external media (for optical media, use the DVD-ROM drive of your computer (I believe many PlayStations emulators can do this); for ROM cartridge, you could use something like the UNIX block devices), in addition to possibility of loading from files.
• Loop test mode (possibly useful with NSF in order to find the length of a song).
• Ability to use cheat code with music files.
• Option to emulate NTSC color artifacts.
• Option to emulate battery levels.
• In case of multiplayer with multiple devices (such as GameBoy), allow an emulator to not only emulate multiplayer by itself, but also connect to other instances of the emulator and connects to the real hardware (for example, if you have a GameBoy game on a real GameBoy, you could connect it to a GameBoy emulator on computer to play multiplayers game).

zzo38, your list is more like a list of existing features from many emulators, not a list of new ideas.

Shiru wrote:zzo38, your list is more like a list of existing features from many emulators, not a list of new ideas.

Really, I don't know what has what. Some things I have seen only in very restricted cases. Possibly some are somewhat new things but similar to old ideas too.

zzo38 wrote:[*]Track uses of memory as instruction/data/operand/nothing.

Check this video. Also, similar feature was in a NSF tool.

[*]Breakpoints.

Pretty much every emulator with debugger has them.

[*]Custom plugins for input/output/audio.

This is a common thing in emulators of more complex consoles like PlayStation.

[*]Specify configuration profiles for individual games.

Not really needed in console/computer emulators, presented in many arcade emulators.

[*]Emulate unofficial opcodes (unless option is set to disable this and cause error instead; might be useful in case you are making something and might not work on other emulators, hardware clones, or newer version of hardware, or to find obscure bugs).

Emulation of unofficial opcodes is a very common thing.

[*]Ability to load program from external media (for optical media, use the DVD-ROM drive of your computer (I believe many PlayStations emulators can do this); for ROM cartridge, you could use something like the UNIX block devices), in addition to possibility of loading from files.

Yes, emulators of CD-based system often has option to use a real CD drive. There is Retrode as well.

[*]Option to emulate NTSC color artifacts.

Starts to be a common thing, also often implemented through video plugins.

Shiru wrote:

[*]Specify configuration profiles for individual games.

Not really needed in console/computer emulators, presented in many arcade emulators.

Possibly because a single arcade system board has numerous games with different kinds of controllers (except Neo Geo which standardizes the button layout). The NES has the same problem. Does a particular ROM expect a Zapper, a Power Pad, a mouse, a Vaus, a Power Glove, a Four Score, or something else?

I seem to remember you started another topic a few months ago about what features would be nice to have in an emulator.

For NESICIDE...

zzo38 wrote: [*]Record specified memory locations by time.

Yep. If by 'time' you mean CPU/PPU/APU cycle.

zzo38 wrote: [*]Track uses of memory as instruction/data/operand/nothing.

Yep. I have a very similar interface to the ICU64 that Shiru plugged...all I need is some OpenGL text help and it's done.

zzo38 wrote: [*]Breakpoints.

Yep. Break on just about anything occurring in the CPU, PPU, APU, or mapper or the memories associated with them.

zzo38 wrote: [*]Custom plugins for input/output/audio.
[*]Specify configuration profiles for individual games.

Nope.

zzo38 wrote: [*]Emulate unofficial opcodes (unless option is set to disable this and cause error instead; might be useful in case you are making something and might not work on other emulators, hardware clones, or newer version of hardware, or to find obscure bugs).

Yep.

zzo38 wrote: [*]Ability to load program from external media (for optical media, use the DVD-ROM drive of your computer (I believe many PlayStations emulators can do this); for ROM cartridge, you could use something like the UNIX block devices), in addition to possibility of loading from files.

Nope.

zzo38 wrote: [*]Loop test mode (possibly useful with NSF in order to find the length of a song).

I have a Test Executive that allows running any ROM with prerecorded inputs and comparisons of screen captures.

zzo38 wrote: [*]Ability to use cheat code with music files.
[*]Option to emulate NTSC color artifacts.
[*]Option to emulate battery levels.
[*]In case of multiplayer with multiple devices (such as GameBoy), allow an emulator to not only emulate multiplayer by itself, but also connect to other instances of the emulator and connects to the real hardware (for example, if you have a GameBoy game on a real GameBoy, you could connect it to a GameBoy emulator on computer to play multiplayers game).
[/list]

Nope.

I think that the text could be decoded by firstly knowing where on the screen the text appears. You'd scan this tile again and again for signs of kanji or kana. It would be fairly CPU intensive, having to be done once a frame. When you identified a kanji or kana, then you'd be in text comparison mode. From there, the text's character data would be progressively scanned and compared, character by character, with the translated strings until a match was found. The text output would then be replaced as soon as a match was possible. In theory, there would be Japanese script output until the matcher had narrowed down the phrase, then it would be blanked and replaced with the pre-translated text. It wouldn't look nice, but it would get the job done.

Is this the text hooker you were talking about, DWEdit?

cpow wrote:For NESICIDE...

Yep. Break on just about anything occurring in the CPU, PPU, APU, or mapper or the memories associated with them.

Recently I wanted a break on any JSR instruction that goes to a specific address. Any chance of that happening?

I don't like "brand new" features list. It's not the first time something pops up, like firing in all directions.

bunnyboy wrote:Recently I wanted a break on any JSR instruction that goes to a specific address. Any chance of that happening?

Put a breakpoint on that specific address and examine the stack. Or use the "step out" button in debuggers that support it.

Shiru wrote:There is Retrode as well.

One thing difficult to find, is does Retrode support a raw mode? (or a specification allowing writing user firmware programs)