Recently, I hear often voices "why don't you try XXX on an emulator if you don't have access to your hardware". Here I'm trying to give an answer, and I'm also trying to give hints how to make "emulation right" because I believe that there's currently a lot wrong with all the emulators I've seen (e-uae,uae,fs-uae). Having written emulators (though for other systems) as well, I'm hopefully able to provide some positive critique.
1) The keyboard. Not everybody is using a US keyboard, and even with local keyboards permitted, users are free to redefine keys. The Amiga keyboard has an extra key, the backslash/vertical bar key on the top right that is not present on standard layouts, but this key is still essential for programming. Write a C program without the backslash is challenging. I usually have caps lock and control interchanged, but the emulator does not get track of that. Instead, it maps caps lock where it believes it should be, but where it isn't. Result is a non-functioning keyboard.
Solutions: Yes, this is hard. Two keyboard layouts are involved. The PC keyboard, and the Amiga keyboard. The solution I have found in "atari++" is: If the key maps to a regular printable character, perform the mapping by position. If the user presses the "Z" key, emulate the key that is at the same position as on the Amiga keyboard. This way, local keymaps work. If the key is a function key, i.e. "shift" or "caps lock", perform the mapping by function, not by position. Caps and Control are always the same position on a PC keyboard, no matter which national layout is used, so allow the user to change the position of these keys. Kes that are not on the PC keyboard should be emulated in an obvious matter. Backslash: AltGr+? for a German keyboard, hence "map by function". Simply *not* mapping this key is not helping.
2) Mouse grab. This is really anoying. In the window, you have either two mouse pointers, or you have one mouse pointer and do not know how to leave the window. Even if you enter the configuration menu of FS-UAE, you do not have your mouse. What do you do to regain control? I didn't know the magic word (F12+g) so I killed the emulator from a console. Yuck!
Solution: a) If the user clicks into the window, make the "native" mouse pointer non-intrusive. A single point is good enough. If some configuration menu is shown that requires user interaction, un-grab the mouse to allow configuration. And finally, use a well-accepted key-combination for ungrabbing. VMWare has set the standards (Ctrl+Alt), so why the heck not simply use that. Or, at least, show the mapping how to ungrab as soon as the mouse is grabbed. This should be the minimum standard.
3) Configuration: With uae, I have a magic text file. Bad, but doable. FS-UAE adds a graphical menu which allows to configure some, but not not all properties, and a graphical launcher that allows again to configure some other, but not all properties. Worse, if you check the internet for what the options are, you find some incomplete documentation. If you check where you have to *put* the configuration file, you get inconsistent results, and the right place (the current directory) is not even mentioned.
Solution: If you make the emulator configurable, expose *all* configuration items to the user by its interface. They need not be reachable by a single click, but there should be some GUI *within the emulator* to modify them. Text files are fine, but please put them in one consistent place that is acceptable by the system standards. On linux, this is: a dot-file in your home directory, and a default file in /etc/. Do*not* use other directories ($HOME/.config or $HOME/Desktop are bad places, unless you're part of a GUI framework that uses the same convention). Avoid "starters" or separate "configuration programs". Make command line options consistent with the GUI elements, and finally: Provide proper documentation with all options explained, and documentation that is up to date. A man page is fine. A web page is fine. But please, provide it.
4) Make it working. Or at least, mark options that are not working as "experimental". FS-UAE has an option to emulate a 68040 MMU. Nice. Try to use it with the mmu.library and see it hang. Not nice. Wouldn't that be the obvious test case for an MMU emulation? Apparently, not. Ok, if that's not what it is good for, what else? Maybe the code isn't quite debugged or complete yet. That's fine. But then, please mark it as such so that the average user can avoid it.
Resolution: Mark experimental configuration options as experimental. To make something stable, make at least the obvious tests.
5) Bad performance. Yes, there's probably little you can do about it. This is here a (old, but not so old) 2.6Ghz Athlon. Yet, emulation speed is probably something in the ball-park of a 68030@25Mhz. Slow, and even worse, inconsistent. Audio hick-ups, so audio is not exactly usable. Booting up the machine, and the emulation crawls. It gets better after a minute, I don't know why. It's probably good enough to play a game for an unexpanded 68K, but it's not good enough for power users - if there are any left. Apparently, emulator writers see the Amiga as a "games machine". Probably that's what it was, or how CBM sold it, and that's why it died. Amiga was actually a tad more than that, and emulation should try to catch up with some of these uses.
Resultion: Yes, that's hard, I understand, and there's little that can be done. My solution is not to go for software emulation in first place. Use an FPGA, you get guaranteed performance.
In the end, every time I tried emulation, I felt disappointed. It was simply not usable for me. The keyboard issue is the worst. I can't work without a working keyboard. In the end, I still power up the real hardware if I have access to it, and if I need to do some Amiga work.