- Category: Usage
You can change the input mapping of all keys during runtime using the OSD menu. Open the menu and find the entry "Input settings", then "Input Assignments (this system)" (0.249).
You will get a list of key mappings similar to this:
On the left side you can see the key in the emulation. Often, there are more than one character, which means that the key accepts a modifier, that is, Shift or FCTN. The x key, for instance, may produce a lowercase x normally, a capital X when pressed with Shift, and Cursor Down when pressed with FCTN. This key is mapped on the right side to the X key of the host keyboard.
Let's change the Alpha Lock mapping. We see that it is mapped to CAPSLOCK, which is not a good idea. We want it to be mapped to the left Windows key, which we don't need otherwise.
You can see that several keys on the host may be mapped to the same emulated key: For example, to make the emulated TI sense a pressed FCTN key, either the left or right FCTN key on the host keyboard will do - the TI does not distinguish them. On 105-key keybords, the right ALT key is usually named "AltGr".
First we remove the old mapping. Highlight the AlphaLock line as shown above (by moving the yellow marker with cursor keys or using the mouse and single-clicking on the entry). Hit DEL to remove the old mapping:
Next, we add a new mapping. Hit the RETURN key; the OSD will show two triangles, indicating that it waits for an input from you.
We now press the Left Windows key. Accordingly, this is shown on the menu:
We may now leave the OSD menu again.
By the way, if you wondered why there is a second Alpha Lock entry ("non-toggle"): This is handy when you connect a TI keyboard via a USB adapter. The Alpha Lock key is then held by its mechanics, and there must not be a toggle inside the emulator.
- Category: Usage
The Mechatronics mouse must be plugged into the joystick port of the TI console:
mame ti99_4a -joyport mecmouse [-mouse]
As said above, use the -mouse switch in the command line to capture the mouse.
Examples for Mechatronics mouse software
These two examples can be found on the companion disk of the Mechatronics mouse.
A simple calculator with a mouse pointer in the shape of a hand. The pointer is a sprite that is smoothly moved by the mouse. Use the left mouse button to type in a number or operation.
This is the well-known Breakout game with mouse support. Works quite well, press the mouse button after positioning the paddle below a number to enter the game at the desired level.
The third tool is a kind of graphical file manager. There are some bugs in the software, however: The program seems to be confused with 360K disks, and the mouse axes are swapped after clicking on a file.
- Category: Usage
In earlier MAME releases, the mouse was assumed to be connected, and the host mouse was mapped to that mouse. In Windows this meant that once you ran the Geneve emulation, your Windows mouse pointer was gone until you stopped MAME again. This is particular nasty when you just did not plan to use the mouse.
In order to avoid this, the mouse must be explicitly attached to the colorbus of the Geneve since release 0.213. If you don't use this, there is no mouse in the Geneve emulation, but you keep the mouse for the Windows desktop.
In Linux the mouse capture is not done automatically, so as said above, use the -mouse switch in the command line.
mame geneve -colorbus busmouse [-mouse]
When the -mouse switch is used, you will lose the pointer on your PC desktop, which also means you cannot use the mouse to close the emulation window. To leave the emulation, use the Esc key in partial keyboard mode (press ScrlLock, then Esc).
Examples for mouse usage
These two screenshots of the Fractals program demonstrate how the mouse is used in Geneve programs.
The small yellow box is a text cursor that moves over the screen when the mouse is moved. In this screen, a dialog for selecting a file is presented. The left mouse button allows the user to select a file or a file format. Note that the mouse can only sit on one of 80x25 screen positions; this means that the host mouse movement must be scaled down. This is done inside the Fractals program; for instance, 8 pulses in one direction means to move the text cursor by one row or column.
The arrow-shaped pointer can be moved with the mouse in order to define the drawing area. In this case, the mouse movement is directly used to move the pointer on the screen, where we have a resolution of 512x212 pixels. By clicking and holding the left button, the rectangle bounds can be defined when moving the mouse. Once the mouse button is released, the dimensions are passed to the drawing routine.
- Category: Usage
The general problem that we face is how to translate the real mouse movement into the emulated mouse movement. You might think at first that this is pretty easy; if the PC mouse is moved by a certain distance, just do the same in the emulation.
However, this does not work for multiple reasons.
- The emulation uses a special screen resolution that may be scaled by changing the emulation window size. Imagine that your host PC screen resolution is full HD (1920x1080); the emulated screen is 256x192 on the TI, or 512x212 on the Geneve. You most likely pulled the window borders to give you a larger display, but it still has the same emulated resolution. Now how is this supposed to be mapped into the emulation?
- The MAME framework has no idea of the resolution of the emulated screen and the screen mode. For instance, on the TI we could use text mode or graphics mode. When we move the mouse in text mode, this is a grid of 40x24 or 80x25 locations. In graphics mode, we can have the full 512x212 on the Geneve.
- The emulated system may have its own way of scaling the mouse movement. Imagine you write a program on the Geneve that uses the mouse, and you want to set the mouse speed. This is no problem; you simply get the mouse movement and calculate the effective movement from it by some factor. How could MAME possibly know that the mouse movement is scaled inside the emulated system? This is not only difficult, it is conceptually impossible.
So when you use the emulation in a window, it is just not possible to map the host mouse movement directly into the emulation so that the emulated mouse and the PC mouse run in sync. In other words, the mouse in the emulation will have its own speed, and if you have a mouse pointer in the emulation, it will not stay together with the host mouse pointer.
The figure on the left illustrates the problem. Suppose that you move a mouse pointer on your host desktop from left to right, crossing the emulation window. You may expect that the mouse movement is seamlessly translated into the emulation. However, we see that the emulation window does not use the same screen resolution as the host desktop, so a movement by 10 positions would seem like a much longer movement inside the emulation.
To make things a bit worse, we have to consider when the emulation is supposed to sample the host mouse movement. At every time, even when you are not using the emulation? Only when you focus the emulation window? - In MAME, the mouse movement is sampled when the host mouse pointer hovers over the emulation window. That means that you have to first move the host mouse pointer over the emulation window before its input is fed into the emulation. When you move the mouse, it is certainly not guaranteed that you reach all locations in the emulated screen before the mouse pointer leaves the emulation window.
The solution to these issues is simple and is also applied in many other emulations like VirtualBox or VMWare: The mouse must be captured. By this we mean that the host mouse pointer disappears, and only the emulated mouse seems to respond to the movements. This prevents the problem of activating or deactivating the mouse movement sampling, because it is always active as long as the mouse remains captured. When the emulation is stopped, the mouse is freed and returned to the host desktop system.
In MAME it is currently not supported to capture or to free the mouse during runtime. You can only specify that the mouse be captured when starting the emulation.
- Category: Usage
MAME emulates two types of mice:
- the Geneve busmouse, connected to the color bus of the video chip
- the Mechatronics Mouse, connected to the joystick port by a special adapter
The emulated mouse may be mapped to the real mouse movement in the OSD menu.
There are some general considerations when discussing the mouse usage in emulations.
Mouse in Linux or Windows
In Windows, the mouse is captured automatically when the emulated mouse is active. This means that you have to shut down the emulation in order to get the mouse pointer back.
In Linux, the mouse is not captured automatically. You must explicitly tell the emulation to capture the mouse at startup; this is achieved by the command line parameter -mouse.
In the OSD menu you can set the mouse parameters. You can find this menu when you open the OSD menu and look for the menu entry Input Settings > Input Assignments (this system). Mind that the submenu names have changed over time; this path belongs to the release 0.249.
Please verify that you have these values in the menu. If not, select the entry, press DEL to remove the setting, then Return to record a new setting. You should see two triangles, indicating that the emulator waits for your input.
For the mouse buttons, just click the respective button.
For the mouse movements, you just proceed as above, and then move the mouse in the direction. That is, X is left/right, and Y is up/down.
When you leave the menu, the settings are saved.
Just slightly different from the Geneve mouse; we have only two buttons.
- Category: Usage
The emulated keyboard is the directly hardware-emulated representation of the computer keyboard. This essentially means that the keyboard is emulated as what it is, a collection of switches with different keycaps on top.
This is the immediate kind of emulation, typical for MAME.
As described, there are three modifier keys for the TI keyboard: Shift, FCTN, and CTRL.
While Shift and CTRL are usually part of the normal PC keyboard, the FCTN key must be mapped to some other key, since a PC keyboard does not have a FCTN key. This is by default the Alt key (or AltGr).
The emulated keyboard mode emulates each of the keys as a separate switch. Accordingly, to type an exclamation mark, the switch labeled Shift and the upper left switch must be pressed. This is the typical assignment on PC keyboards as well.
The trouble with the keys
If we want to type a double quote, the FCTN key and the P key must be pressed. With the typical mapping, this means that you have to press Alt and P on your PC keyboard to get the quote, because the emulated TI wants to see those two switches pressed. And this is all the trouble with the emulated keyboard: The PC keyboards do not match this key assignment. What you see on your keycaps is not what you see in MAME.
Things may become worse. On QWERTY keyboards, many of the key mappings are similar to the TI keyboard. Me, for example, I'm using a QWERTZ keyboard, and this does not only mean swapped Y and Z keys, but many other keys being relocated. The double quote is assigned to Shift-2, where the QWERTY keyboards have the @ sign. The @ sign, in turn, is on AltGr-Q on my keyboard. So my dear American and English friends, when you complain about this mode, please remember those people who have international keyboard layouts.
Why can't we just take the PC keys? When we type a double quote, can't this just be fed into the emulation?
But that is not the way how MAME works. As I wrote above, MAME executes the original keyboard scanning routine of the TI, and this routine expects that you have pressed the FCTN key and the P key. There is a way, though, which I explain in more detail in the section about the natural keyboard.
The full mode defines all keys of the emulated system. That is, each key switch of the emulated system should be mapped to some key switch on the keyboard.
In this diagram you can see where you can find the TI keys on a common PC keyboard. To type a question mark, you have to press Alt (left of the space bar) or AltGr (right of the space bar) as the FCTN key, and the i key.
You can swap to the partial mode by pressing ScrlLock.
In the partial mode, some of the keys are reserved for MAME operation. One of the most surprising assignments is the Pause function on the P key. When you press P in partial mode, the emulation is paused, which means that it stops and ignores all further key inputs, and the screen output is dimmed. Lots of users falsely believed that the emulation crashed (and told other people that MAME crashed all the time, completely unstable). Pressing P again resumes emulation.
To swap back to the full mode, just press ScrlLock again.
The most important functions of the partial mode are to
- open the OSD menu: TAB
- stop the emulation: ESC
- reset the emulation: F3 (Shift-F3)
- make a screenshot: F12
- load a saved state: F7
- save a state: Shift-F7
The AlphaLock issue
The AlphaLock key is mapped to ShiftLock by default. However, I usually remap AlphaLock to another key, like the LeftWin key (between Ctrl and Alt).
The reason is that ShiftLock is a stateful key on the PC. This means it has two states which you can switch by shortly pressing the key; you don't need to keep it pressed. So when you work with MAME, you may want to push that key to have uppercase characters (the default on the TI). But then you notice something in your PC mail program and switch to that program, noticing you still have ShiftLock active, and release it, because you don't want to write your E-mail message in uppercase.
But MAME will not notice the change of the key state, since you unfocused its window (when you clicked on your other program). From now on, the key state is swapped in MAME.
Also, when you leave MAME, it will save the key state. When you start it later, it still assumes that state, regardless of the real ShiftLock state.
Hence, I highly recommend to remap the AlphaLock key.