You said in another post about your new emu that you were open to suggestions. Here are mine. Many of us run the emulators in a cabinet and use a front end. Personally I use MameWAH. To be truly cabinet friendly an emu requires a few things.
The ability to remap ALL the keys
Exit with the ESC key (or the ability to map your own exit key)
The ability to receive a rom name as a commandline parameter and launch full screen.
The ability to exit with a single key press (Escape)
Also nice would be the ability to either handle keyboard input(cabinet control panel) and/or a gamepad simultanously. Very few due this now. ZSNES for Super Nintendo comes to mind.
That’s all I can think of for now. Good luck in your development cycle.
John
The keymaps and gamepad are good ideas. Here’s what I’d also like to see:
* One of the reasons I liked Nesticle was it had features noone else had (back then). I found the OSD sound waveform good, as well as the ability to turn off different sound channels. I also liked the ability to increase/decrease the frameskip, and view/edit the chars/palettes all while viewing the results realtime.
* Like jcrouse said, gamepad support would be sweet. If you use the now (reasonably) standard SNESpad interface, it would mean you could add support for real NES/SNES/VB controllers.
* If you are including multi-console support (more than one VB being emulated at once), include the ability to emulate the link port, and multiple SNESpad support.
* And finally, the ability to test link cable support by mapping the link port to any remaining LPT port IO pins.
Thats all I can think of, for now… π
I agree, game pad support would be great, also the ability to emulate two VBs at once and play link games against each other sounds like a great idea!
Other (not that important) things I can think off are:
* Video/sound recording
* screenshot capture options like format, size, pallet…
And of course, all the nice things RB and RD had to offer, like the cheats system or the debugging options.
Cheat support… I forgot about that…
Make it as versatile as possible. It’s no use just adding something you can only search for values with (like RD), or can’t edit cheats after you make them (like another emu I’ve forgotten).
The best options for a cheat system are:
* ability to search in 8/16/24(?)/32 bit, using hex or dec.
* >/>=/<=/==/!= support for specified value or previous RAM values
* ability to add cheat results into the cheat list
* ability to add, EDIT and delete cheat list entries
* ability to enable/disable selected/all cheats
* ability to save cheats to custom filenames (and load them)
Thats all I can think of. Look at VirtuaNES for an excellent example of what a cheat system should be like.
...And as for debugging, of course this would be handy. We are going to be using this for development after all. π
Features like tracing, jumping, editing RAM/ROM/CPU values are also good, however a feature I’d like to see more is to be able to log (and halt) on reading/writing from specific (or specified ranges of) addresses, ROM RAM or otherwise.
That kind of feature would help me out a lot with finding the BS Zelda map data… …Know of any modded Z/SNES/9x that support it?
EDIT: It would also be nice to use the debugger in either normal or realtime.
A feature I also find nice in VirtuaNES is the ability to edit RAM realtime. It’s a quicker way of finding where some stuff is located. π
Oh, and auto-IPS patch support would be nice too.
Post Edited (04-28-05 06:44)
Oi…. ;(
I’ve never liked VirtuaNES. So when some friends and I needed some debug tools for NES, we built them into FCE Ultra. I’m sure our “debug builds” of the emulator are not so difficult to find, depending on where you look. (*cough* ZD) The tools available there far outdo anything from any other emulator. Ever.
Some of those suggestions are good, but they certainly don’t hold priority. That would go exclusively to emulation accuracy. On the other hand, debugging tools contribute significantly to working on accuracy.
On final note, the last thing I did with VUE32 was the CPU core. As far as I could tell, it was running with decent speed and accuracy, though incomplete. No I/O is emulated (including controllers, audio, video…) but it has a running core, anyhow! Actually, there is a bit of video emulation, (framebuffer display) but it’s really quite insignificant.
Also, as far as I/O is concerned, I see that Reality Boy supports controllers hooked to external port such as com and lpt ports. Be aware the the gentelman at this site, http://www.sealiecomputing.com/retrozone/index.html, is making me a USB chip.conversion for the original VB controller. It will be seen as a Windows device and hence will require Direct Input code in the emulator.
Just an FYI,
John
The emulator is written in SDL, so it will be capable of using any device labeled as a “joystick” or “gamepad” by Windows.
As a hack developer myself, not that your a hack :), I usually don’t ask this but since I kind of collect VB stuff now and there really isn’t a great emulator available I will ask. What is the projected release? Are we talking weeks, months or a year or two? Feel free to give me the normal response of “when its ready”
Thanks,
John
Depends on how much you’re willing to pay him. π
Its not really a thing you can rush. Life tends to take priority over VB (unfortunately). π