Features of NES/Famicom Emulator

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Features of NES/Famicom Emulator
by on (#81473)
My opinion is that it would be good to have these features (some can apply for emulation of other systems too)
  • Accuracy
  • Speed
  • Memory viewer and modification
  • Quick save states
  • Enter cheat/debug codes of various types (even for NSF)
    • Modify ROM value persistently
    • Modify RAM value persistently
    • Modify RAM value conditionally
    • Watchpoint of RAM
    • Breakpoint of program code
  • Key configuration
  • Joystick support
  • Wii remote support
  • Network support
  • Load ROM from iNES file (or other formats)
  • Emulate system with external cartridge
  • Act as a cartridge
  • Famicom Disk System
  • Famicom Keyboard
  • Zapper
  • Connect any input device to any controller port (even if not normally used on that port)
  • NTSC/PAL switch
  • Record (and play back) a file with changes to a range of memory (including number of frames) with the range that the user can specify
  • Write Forth codes for various purposes
    • Override an existing mapper or program a new mapper
    • Make a new input device emulation
    • Make a expansion device emulation
    • Write macros
  • Emulate arcade system
  • Quick reload same ROM file (in case you have made changes)
  • View nametable, tiles, palettes
  • Record which positions of memory (including specifyable conditions, such as ROM banks) are used as instructions, operands to instructions, data, jump targets
  • Turn off individual audio channels
  • Emulate stereo NES modification
  • Turn off sprites/background individually
  • Copy text from nametables (using translation table specified by user)
  • Change aspect ratio
  • Crop the view, to see how it would work on TV screens that do not display the pictures on edges
  • Literate programming (such as Enhanced CWEB, for example; or INWEB if you prefer that one) to make the book of how the program works and all of its features and so on
  • License free-software/open-source
  • Include wiring diagrams
  • Debugger
  • Screen shot
  • Single frame advance
  • Paste Famicom keyboard input from clipboard
  • Support no-sprite-limit
  • RAM filter search (cheat code helper)
  • Low-level PPU debugging details
  • Software scaling (inhibit use of scaling interpolation causing blurry pictures)
  • In case of audio pass filter, allow disabling filters
  • Emulator should support properly-implemented VSync in windowed mode, as best as possible
  • Single instruction advance
  • Header editor

by on (#81475)
That's a pretty tall order here... FCEUX has many of these features, but still has some accuracy problems.

Some of these features are completely out of the question (Act as a NES cartridge?).

FCEUX even has the "Copy text from nametables" feature. (But you need to make a TBL file first)
Quote:
Erdrick, listen now
to my words.'

`It is told that in
ages past Erdrick
fought demons with a
Ball of Light.'

by on (#81476)
I'd trade half of the list to a debugger.

Also, screenshot and frame advance features not considered a must?

by on (#81477)
Shiru wrote:
I'd trade half of the list to a debugger.

Also, screenshot and frame advance features not considered a must?
I forgot those things now I will put them in.

I can think of a few uses of this kind of recording features, such as, make file of audio using NES/Famicom audio registers, record input to play back later, or even record RAM if you have a purpose to do so.

I have seen that FCEUX does have many of these features but not all, and some are difference anyways than this.

For using Forth codes to define a mapper (the built-in mappers would be defined in C, not Forth), the following words might be provided (in addition to standard Forth words):
Code:
'ROM@ - Variable storing XT of word taking ( mem-addr -- byte-value ) when reading cartridge memory
'ROM! - Variable storing XT of word taking ( byte-value mem-addr -- ) when writing cartridge memory
'CHR@ - Variable storing XT of word for reading CHR ROM ( mem-addr -- byte-value )
#FRAME - Returns number of frames
STATUS - Type text on the status area
FILE@ - Read byte from file using random-access

by on (#81479)
Please add the following to the list:

* Cheat code helper; specifically the one implemented in this version of FCEUX SP. It "makes sense" and is easy to use.

* Low-level PPU debugging details; internal scanline counter, things like that.

* Should support rendering to off-GPU buffer (e.g. system RAM), to inhibit use of scaling interpolation. Sometimes this is called "software scaling". (Some of us run emulators in "2x size" mode, where a 256x256 window is rendered as 512x512 and we don't like blurry graphics -- I much prefer the pixellated look!).

* Emulator should support properly-implemented VSync in windowed mode, as best as possible.

* If any audio filtering mechanisms (e.g. low-pass, high-pass, etc.) are offered, make sure they are toggle-able.

* .NES header editor (to toggle bits, etc.). Should support/work with NES 2.0 header format too.

* Should support "no-sprite-limit".

And I strongly agree with a frame-advance debugger option.

by on (#81480)
koitsu wrote:
And I strongly agree with a frame-advance debugger option.


By this do you mean the ability to "step" to the same PPU cycle in the next PPU frame? Or am I thinking something else? I think I'll add that to nesicide...easy 'nuff. Oh, and thanks for the reminder re toggleable sprite limiting.

by on (#81482)
PPU frame.

"Run until next NMI" would be another option, usually hand-in-hand with the aforementioned PPU frame description. I've run into situations where I need to watch what an individual NMI is doing each iteration yet can't when the emulator doesn't support it...

by on (#81483)
koitsu wrote:
"Run until next NMI"

This can be easily achieved with a breakpoint.

by on (#81485)
Which reminds me of something I had suggested for the debugger in NESICIDE: generalization of breakpoints into tintpoints, logpoints, soundpoints, etc.

by on (#81486)
And what emulator do you expect to see such billions of things? A WonderNES?

by on (#81487)
koitsu wrote:
Please add the following to the list:

* Cheat code helper; specifically the one implemented in this version of FCEUX SP. It "makes sense" and is easy to use.

* Low-level PPU debugging details; internal scanline counter, things like that.

* Should support rendering to off-GPU buffer (e.g. system RAM), to inhibit use of scaling interpolation. Sometimes this is called "software scaling". (Some of us run emulators in "2x size" mode, where a 256x256 window is rendered as 512x512 and we don't like blurry graphics -- I much prefer the pixellated look!).

* Emulator should support properly-implemented VSync in windowed mode, as best as possible.

* If any audio filtering mechanisms (e.g. low-pass, high-pass, etc.) are offered, make sure they are toggle-able.

* .NES header editor (to toggle bits, etc.). Should support/work with NES 2.0 header format too.

* Should support "no-sprite-limit".

And I strongly agree with a frame-advance debugger option.
I agree with these things (although I am unsure if .NES header editor is needed, but I will add it anyways).

Quote:
"Run until next NMI"

This can be easily achieved with a breakpoint.
Yes in most cases. (In cases where the NMI routine would be entered through something else, it won't; but if it is a game you wrote, you can recode it easily)

by on (#81494)
One of the reasons I requested a run-until-next-NMI option is because of games like Wai Wai World, which actually swaps out $C000-FFFF in real-time. The NMI vector contained in those PRG pages is not a consistent value. This really drove me apeshit. :-)

A breakpoint would be have to be changed rigorously by the individual doing the debugging. Otherwise you're absolutely right tokumaru, a breakpoint would be sufficient (but make it easy on the person doing the debugging; show NMI/RESET/IRQBRK vectors in the debugging window somewhere!)

by on (#81497)
koitsu wrote:
A breakpoint would be have to be changed rigorously by the individual doing the debugging. Otherwise you're absolutely right tokumaru, a breakpoint would be sufficient (but make it easy on the person doing the debugging; show NMI/RESET/IRQBRK vectors in the debugging window somewhere!)

In Nintendulator it's possible to put breakpoint on the NMI specifically (i.e. it's not dependant on the value of the vector).

by on (#81505)
koitsu wrote:
One of the reasons I requested a run-until-next-NMI option is because of games like Wai Wai World, which actually swaps out $C000-FFFF in real-time. The NMI vector contained in those PRG pages is not a consistent value. This really drove me apeshit. :-)

A breakpoint would be have to be changed rigorously by the individual doing the debugging. Otherwise you're absolutely right tokumaru, a breakpoint would be sufficient (but make it easy on the person doing the debugging; show NMI/RESET/IRQBRK vectors in the debugging window somewhere!)


In NESICIDE you can set a breakpoint:

1. When the PPU sets $2002.8 (although I broke this one recently...I'll fix it!)
2. When the PPU asserts NMI.
3. When the CPU vectors to the NMI handler.

The NMI breakpoints above are independent of the code location of the NMI handler. You can of course set a code execution breakpoint somewhere in NMI handler, too.

EDIT: Ok I fixed the first breakpoint type but me dang website be down...so no update available (yet).

by on (#81507)
Zepper wrote:
And what emulator do you expect to see such billions of things? A WonderNES?

Is that the new name for RockNES? :P

But seriously, my first guess was that someone was working on a "Comparison of NES emulators" article on wiki.nesdev.com, sort of a counterpart to the various "Comparison of..." articles on Wikipedia.

koitsu wrote:
One of the reasons I requested a run-until-next-NMI option is because of games like Wai Wai World, which actually swaps out $C000-FFFF in real-time.

Then put a breakpoint on reading $FFFA.

koitsu wrote:
show NMI/RESET/IRQBRK vectors in the debugging window somewhere!)

In FCEUX for Windows, scroll to the bottom of the "Hex Editor".

by on (#81509)
tepples wrote:
Zepper wrote:
And what emulator do you expect to see such billions of things? A WonderNES?

Is that the new name for RockNES? :P


Don't look at me.

by on (#81512)
tepples wrote:
koitsu wrote:
One of the reasons I requested a run-until-next-NMI option is because of games like Wai Wai World, which actually swaps out $C000-FFFF in real-time.

Then put a breakpoint on reading $FFFA.

I'm not sure if FCEUX works that way... I vaguely remember trying that and failing because internal CPU operations wouldn't trigger the breakpoint, only explicit operations performed by the game code would. This would be an interesting thing to test.

Quote:
koitsu wrote:
show NMI/RESET/IRQBRK vectors in the debugging window somewhere!)

In FCEUX for Windows, scroll to the bottom of the "Hex Editor".

I don't know about everyone else, but I always forget the order in which the vectors are specified.

by on (#81513)
tokumaru wrote:
tepples wrote:
koitsu wrote:
One of the reasons I requested a run-until-next-NMI option is because of games like Wai Wai World, which actually swaps out $C000-FFFF in real-time.

Then put a breakpoint on reading $FFFA.

I'm not sure if FCEUX works that way... I vaguely remember trying that and failing because internal CPU operations wouldn't trigger the breakpoint, only explicit operations performed by the game code would.

Have you tried reporting the bug?

tokumaru wrote:
tepples wrote:
koitsu wrote:
show NMI/RESET/IRQBRK vectors in the debugging window somewhere!)

In FCEUX for Windows, scroll to the bottom of the "Hex Editor".

I don't know about everyone else, but I always forget the order in which the vectors are specified.

Something you see often in at least my code:
Code:
.segment "VECTORS"
.addr nmi, reset, irq


Anyway, I took the liberty of reorganizing all these possible features by categories.

Machine variants:
  • NTSC NES (3 dots/cycle, NMI on line 241 of 262)
  • RGB NES with NTSC timing
  • PAL NES (3.2 dots/cycle; NMI on line 241 of 312)
  • Hybrid PAL famiclone (3 dots/cycle, NMI on line 291 of 312)
Executable formats:
  • Split PRG and CHR with separate board file
  • iNES
  • NES 2.0
  • UNIF
  • FDS
  • NSF
  • PKZIP
  • 7-Zip
  • Reload same executable
  • Edit header
  • Support for dumping devices
Mappers:
  • Common discrete mappers (A*ROM, CNROM, CPROM, G*ROM, U*ROM, Color Dreams)
  • MMC1, MMC3, MMC6, FME-7 (S*ROM, T*ROM, H*ROM, BTR)
  • MMC2, MMC4 (P*ROM, F*ROM)
  • MMC5
  • Famicom Disk System
  • Other more obscure mappers
  • Multicart mappers
Accuracy:
  • List of test ROMs essential for all emulators
  • List of test ROMs essential for emulators not running on limited (handheld) hardware
  • List of test ROMs needed for debugging emulators
Video quality:
  • Point-resampled 2x
  • EPX/Scale2x
  • NTSC artifact simulation
  • Scanline texturing (darken every second scanline)
  • Aspect ratio correction (8:7 NTSC, 1.39:1 PAL)
  • Widescreen TV simulation (aspect ratio 4:3)
  • Import TV border image to simulate overscan
  • Adjust brightness, contrast, saturation, tint, color temperature
  • Lack of tearing
Audio quality:
  • Low-pass filtering
  • Time warping or not when CPU and PPU are sped up
Speed:
  • Dhrystone MIPS to emulate one NTSC system
  • Simultaneously emulated machines
  • Maximum fast forward speed
  • 10 second skip button (for cutscenes and the like)
  • Slow down or speed up emulation
  • Wait for host vertical blanking without spinning so as not to hog battery
Save:
  • Save/load state, verified somehow(?)
  • Quick save/quick load
  • Rewind
Recording:
  • Log input after a saved state
  • SHA verification to make sure the ROM used for playback is identical to the one used for recording
Netplay is possible once recording is in:
  • Peer to peer or server based
  • NAT traversal
  • Spectators (live stream of logged input)
Media recording:
  • Screenshot: Log one frame of PPU to image file
  • Audio: Log APU to audio file
  • Video: Log PPU+APU to video file
Game patching/enhancement/cheating:
  • IPS
  • Game Genie ROM patches
  • Raw ROM patches
  • Action Replay RAM fixes
  • Raw RAM fixes
  • RAM cheat finder
PPU visualization:
  • Palette viewer
  • Pattern table viewer
  • Nametable viewer
  • OAM viewer
  • OAM viewer grouped by sets of sprites that touch (for making e.g. sprite sheets)
  • Update viewer on a given scanline
  • Show/hide emulated background or sprites
  • Sprite per line limit to 8, 16, or unlimited
  • Copy text from nametables using a user-specified character encoding
  • Show pixels in blanking areas (full 341x262 or 341x312)
  • Show current raster position when execution is stopped
  • Show points where PPU register writes take effect
APU visualization:
  • Waveform display
  • Show pitch of each channel as a note value (e.g. C-3 +2c)
  • Adjust channel volume and balance
Execution visualization:
  • Show heat map of RAM access
  • CPU and PPU memory hex editor
  • User-specified character encoding for hex editor
  • Log which memory areas are used as jump targets, other instructions, data, or DPCM samples
Debugging:
  • Step over one instruction
  • Step out of subroutine (stop execution when stack pointer increases past its current value)
  • Step over subroutine (stop execution on the instruction after this)
  • Load symbols from assemblers' listing files
  • Show internal registers of CPU, PPU, APU, and mapper
Breakpoint triggers:
  • Read address range
  • Execute (read opcode from) address range
  • Write address range
  • Write specific value to address range
  • Ranges may start at a numeric address or at a symbol name (for when symbols move after a recompile)
  • Raster reaches (x, y)
  • Specific interrupt source (vblank NMI, APU frame IRQ, DMC IRQ, mapper) asserts an interrupt
Breakpoint actions:
  • Write executed instruction to log file
  • Stop execution
  • Play a sound
  • Set the tint of the raster
  • Write value to address
  • Make a saved state
  • Run a script in Lua or Forth
Host input devices:
  • Keyboard
  • DirectInput joystick
  • XInput gamepad (Xbox 360)
  • Wii Remote
  • Mouse
Emulated input devices:
  • Standard controller
  • Controller with rapid fire
  • Controller with macros
  • Zapper (on either port)
  • Four Score
  • Famicom style 4-player (hardwired and expansion controllers)
  • Famicom mic
  • Vaus controller
  • Mouse (SNES or famiclone)
  • Keyboard (BASIC or famiclone) with clipboard support
Script capability:
  • Graphical overlays
  • Audio generation
  • Enough to emulate a mapper or input device
Embeddability:
  • Allow other applications to embed an emulator, with or without video output
  • Free software (DFSG) license

Some I didn't understand:
  • Act as a cartridge
  • Record (and play back) a file with changes to a range of memory (including number of frames) with the range that the user can specify
  • Literate programming (such as Enhanced CWEB, for example; or INWEB if you prefer that one) to make the book of how the program works and all of its features and so on
  • Include wiring diagrams

by on (#81514)
tepples wrote:
Something you see often in at least my code:
Code:
.segment "VECTORS"
.addr nmi, reset, irq

Sure, but when I'm debugging I don't have the source code. Of course I can quickly check the order, but I'd rather not.

by on (#81515)
tokumaru wrote:
I don't know about everyone else, but I always forget the order in which the vectors are specified.


Yep. Me too. I need to add this information to my CPU inspector...

by on (#81516)
For me the question is: What do you want your emulator do for the end-user?
I mean if the end user pretends to develop nes code on or it is just for playing games.
I mean this things get confused and at the and we see emulators at a middle stage, i mean they are not to good to play and not to good to dev too.
When Bill Gates tought in a operating system, he tought in the end user. Microsoft is always trying to do things easier for the end-user not getting bored him with technical things. That's the reason becouse there are "technicians".
If you want a completly solution to develop NES software, instead of making an emulator think in a whole thing, a good assembler, a good ide, an emulator spefically for that ide so you can test whatever bit you want, etc, etc.
If the user just want to play games is it too important too have a very cool dissassembler if he would never touch it?, But yes it is important too have a good Nes header editor, tile viewer, etc, etc if the person who use it is a nes developer.
I think we have 3 path here: dev, fun, personal interest.
I mean personal interest, maybe for the coder that is courious and wants to try to make an emulator and never realeses to the public.
But we all know that almost all writes wants they book to be read and that All musicians wants they songs to be listened.
Maybe you could say that it is out of the point, but even Kafka didn't burn his own writings and he told his friend to do it when he passed away. So why didn't he burn is own writings if suppously he didn't want people to read them and he told his friend to do it?
I remember the member WedNesDay putting (now he cleraed it) " ... the best emulator on the net" or something similar.
Do you want all people says XXX is the best NES emulator in the world and YYY done it? To say myself "i'm very important and all people who wants to play NES games use it!, ehem..."

You sould take into account the path you are taking, maybe at the middle you can change the path and that's not important.
The thing is wich one will you take?

by on (#81517)
Anes wrote:
If you want a completly solution to develop NES software, instead of making an emulator think in a whole thing, a good assembler, a good ide, an emulator spefically for that ide so you can test whatever bit you want, etc, etc.


Amen.

Yes, I realize the site is down temporarily...but it's the thought that counts. Riiight? :D

by on (#81518)
tepples wrote:
Anyway, I took the liberty of reorganizing all these possible features by categories.
Very good. You even added things I missed as well. You are correct as these things. (Note that I have specified logging instruction codes separately from instruction operands, in case some instructions overlap you can see which are used as both)

tepples wrote:
Some I didn't understand:
  • Act as a cartridge
  • Record (and play back) a file with changes to a range of memory (including number of frames) with the range that the user can specify
  • Literate programming (such as Enhanced CWEB, for example; or INWEB if you prefer that one) to make the book of how the program works and all of its features and so on
  • Include wiring diagrams
I can explain what I meant by these things.
  • Act as a cartridge = Read the .NES (or other format) file and emulate the mapper only, allowing other programs to do emulation - this is the kind of other way around than using an external cartridge and emulating the computer only (so the emulator does not need to know the mapper)
  • Record file with changes to a range of memory = For example, selecting range $4016 to $4017 on CPU memory can be used as an alternative to recording input (although it will fail if the program is changed). Range $4000 to $4015 can allow recording sound in a format that can be usable by NES. You could also have PPU memory and miscellaneous memory (such as for real input and so on).
  • Literate programming = Literate programming allows making the computer program which is also the book. The code is available together with texts, table of contents, index, etc. Some programs are written like this including TeX and many of my own programs.
  • Include wiring diagrams = For documentation, mostly. Does not affect the operation of the emulator.


Also, I suggest permanently assigning mapper ID number 255 to mean that it is a special mapper having no mapper ID number (a ID number for that mapper might or might not be assigned in the future).

by on (#81520)
cpow wrote:
Anes wrote:
If you want a completly solution to develop NES software, instead of making an emulator think in a whole thing, a good assembler, a good ide, an emulator spefically for that ide so you can test whatever bit you want, etc, etc.


Amen.

Yes, I realize the site is down temporarily...but it's the thought that counts. Riiight? :D


No if you want to close it well the site sould be up.
It would be better the "amen" alone. And have the balls to put it in the right size.

by on (#81522)
Anes wrote:
No if you want to close it well the site sould be up.
It would be better the "amen" alone. And have the balls to put it in the right size.


At least my response wasn't an insult. Balls? Really?

by on (#81523)
Image

Any idea when NESICIDE will be back up so we can see how many boxes it ticks? ;-)

by on (#81526)
An emulator could turn off the PC, or even warning a kid about his homework to do, using a mother's voice sample. Plus, another feature is the ability to transfer ROMs via bluetooth and create Ad-Hoc connections for two players. Don't forget the automated cartridge writer: a new cart in an eye blink!

/sarcarsm

by on (#81531)
tepples wrote:
Any idea when NESICIDE will be back up so we can see how many boxes it ticks? ;-)


No luck with the site yet. :evil:

Realistically, though, I can't tick that many...a swag:

+ definitely
~ sorta

Machine variants:

+ NTSC NES (3 dots/cycle, NMI on line 241 of 262)
RGB NES with NTSC timing
+ PAL NES (3.2 dots/cycle; NMI on line 241 of 312)
Hybrid PAL famiclone (3 dots/cycle, NMI on line 291 of 312)


Executable formats:

Split PRG and CHR with separate board file
+ iNES
NES 2.0
UNIF
FDS
NSF
PKZIP
7-Zip
+ Reload same executable
Edit header
~ Support for dumping devices


Mappers:

+ Common discrete mappers (A*ROM, CNROM, CPROM, G*ROM, U*ROM, Color Dreams)
+ MMC1, MMC3, MMC6, FME-7 (S*ROM, T*ROM, H*ROM, BTR)
+ MMC2, MMC4 (P*ROM, F*ROM)
~ MMC5
Famicom Disk System
Other more obscure mappers
Multicart mappers


Accuracy:

+ List of test ROMs essential for all emulators
+ List of test ROMs essential for emulators not running on limited (handheld) hardware
+ List of test ROMs needed for debugging emulators
(reference: test_roms.xml

Video quality:

+ Point-resampled 2x
EPX/Scale2x
NTSC artifact simulation
Scanline texturing (darken every second scanline)
Aspect ratio correction (8:7 NTSC, 1.39:1 PAL)
Widescreen TV simulation (aspect ratio 4:3)
Import TV border image to simulate overscan
Adjust brightness, contrast, saturation, tint, color temperature
Lack of tearing


Audio quality:

+ Low-pass filtering
Time warping or not when CPU and PPU are sped up


Speed:

Dhrystone MIPS to emulate one NTSC system
Simultaneously emulated machines
Maximum fast forward speed
10 second skip button (for cutscenes and the like)
Slow down or speed up emulation
+ Wait for host vertical blanking without spinning so as not to hog battery


Save:

Save/load state, verified somehow(?)
Quick save/quick load
Rewind


Recording:

Log input after a saved state
SHA verification to make sure the ROM used for playback is identical to the one used for recording


Netplay is possible once recording is in:

Peer to peer or server based
NAT traversal
Spectators (live stream of logged input)


Media recording:

Screenshot: Log one frame of PPU to image file
Audio: Log APU to audio file
Video: Log PPU+APU to video file


Game patching/enhancement/cheating:

IPS
Game Genie ROM patches
Raw ROM patches
Action Replay RAM fixes
Raw RAM fixes
RAM cheat finder


PPU visualization:

+ Palette viewer
+ Pattern table viewer
+ Nametable viewer
+ OAM viewer
OAM viewer grouped by sets of sprites that touch (for making e.g. sprite sheets)
+ Update viewer on a given scanline
Show/hide emulated background or sprites
Sprite per line limit to 8, 16, or unlimited
Copy text from nametables using a user-specified character encoding
~ Show pixels in blanking areas (full 341x262 or 341x312)
+ Show current raster position when execution is stopped
~ Show points where PPU register writes take effect


APU visualization:

Waveform display
Show pitch of each channel as a note value (e.g. C-3 +2c)
Adjust channel volume and balance


Execution visualization:

+ Show heat map of RAM access
+ CPU and PPU memory hex editor
User-specified character encoding for hex editor
~ Log which memory areas are used as jump targets, other instructions, data, or DPCM samples


Debugging:

+ Step over one instruction
Step out of subroutine (stop execution when stack pointer increases past its current value)
~ Step over subroutine (stop execution on the instruction after this)
+ Load symbols from assemblers' listing files
+ Show internal registers of CPU, PPU, APU, and mapper


Breakpoint triggers:

+ Read address range
+ Execute (read opcode from) address range
+ Write address range
+ Write specific value to address range
~ Ranges may start at a numeric address or at a symbol name (for when symbols move after a recompile)
+ Raster reaches (x, y)
+ Specific interrupt source (vblank NMI, APU frame IRQ, DMC IRQ, mapper) asserts an interrupt


Breakpoint actions:

~ Write executed instruction to log file
+ Stop execution
Play a sound
Set the tint of the raster
Write value to address
Make a saved state
Run a script in Lua or Forth


Host input devices:

+ Keyboard
DirectInput joystick
XInput gamepad (Xbox 360)
Wii Remote
+ Mouse


Emulated input devices:

+ Standard controller
Controller with rapid fire
Controller with macros
+ Zapper (on either port)
Four Score
Famicom style 4-player (hardwired and expansion controllers)
Famicom mic
+ Vaus controller
Mouse (SNES or famiclone)
Keyboard (BASIC or famiclone) with clipboard support


Script capability:

Graphical overlays
Audio generation
Enough to emulate a mapper or input device


Embeddability:

+ Allow other applications to embed an emulator, with or without video output
+ Free software (DFSG) license



Some I didn't understand:

+ Act as a cartridge
Record (and play back) a file with changes to a range of memory (including number of frames) with the range that the user can specify
Literate programming (such as Enhanced CWEB, for example; or INWEB if you prefer that one) to make the book of how the program works and all of its features and so on
Include wiring diagrams

Some I think are useless for an IDE, such as netplay. Now, that doesn't mean I won't consider adding support for it in the emulator DLL that is used by the IDE and the standalone emulator. The fact that the emulator is a DLL is why I took + credit for embeddability.

For the "act as a cartridge" idea, that is accomplished by providing the content of the PRG and CHR to the emulator DLL and then utilizing the PRG/CHR/SRAM/EXRAM get/set and mapper get/set routines. However, I don't use the DLL that way...I use the emulation APIs.

by on (#81532)
Thanks cpow for the rundown.

Zepper wrote:
An emulator could turn off the PC, or even warning a kid about his homework to do, using a mother's voice sample.

I believe parental controls in recent versions of Windows and Mac OS X can already do that.

Quote:
Plus, another feature is the ability to transfer ROMs via bluetooth and create Ad-Hoc connections for two players.

Set up IP over Bluetooth (aka "tethering") and use netplay.

Quote:
Don't forget the automated cartridge writer: a new cart in an eye blink!

That depends on Chinese companies providing blank NES carts and NES cart writers that are as easy to use as the GBA accessories they produced from about 2002 through 2006.

by on (#81536)
cpow wrote:
Anes wrote:
No if you want to close it well the site sould be up.
It would be better the "amen" alone. And have the balls to put it in the right size.


At least my response wasn't an insult. Balls? Really?


No, and you are right im a little bit impulsive sometimes, but nobody gets hurts reading that word or do you? (you->plural).
Sorry man i didn't want to insult nobody, anyway...

i think a better idea, why don't we make sorta kind of community and start developping the "WonderNes" as Fx3 says?

And im talking seriously, each person or two with his own emulator im bored of that, that could be a wonerfull thing developing a big project, having a central head, developers and contributors. Much like as KDE or something similar.

Now you would say: insted of "Amen" -> "Zzzzz....".

Its just an idea.

By the way another thing this "wonder" thing could do is to create executables for the target system using static and/or dinamic recompilation.
In the case static recompilation is not possible, have a runtime for the emulation part.

"Zzzzz...."

by on (#81542)
Anes wrote:
i think a better idea, why don't we make sorta kind of community and start developping the "WonderNes" as Fx3 says?


Sorta like this?

By all means, join us on #nesicide (on Freenode.net), sign up, become a nesicide-core-developer, and start contributing features/fixes/enhancements/whatever. More the merrier.

by on (#81549)
Quote:
Don't forget the automated cartridge writer: a new cart in an eye blink!
This is not a feature that belongs in the emulator. However, if the emulator is written as a set of modules, the separate program that does it could be using the same libraries.

Quote:
By the way another thing this "wonder" thing could do is to create executables for the target system using static and/or dinamic recompilation.
In the case static recompilation is not possible, have a runtime for the emulation part.
It is a good feature in case you can have an external file that has instruction trace information, and in case of self modifying code in RAM you can use the normal kind of emulation. (Instruction trace data can be partially created by static analysis)

I can possibly help with some of programming I prefer if it is a program written in (Enhanced) CWEB.