VICE is the one and only Versatile Commodore Emulator. It allows you to emulate the Commodore 64, 128, VIC20 and PET 8-bit computers with one single package. The emulators run as separate programs, but have the same user interface, share the same settings and support the same file formats.
Important notice: If you have no idea about what a Commodore 8-bit computer is, or have questions about how these machines are used, how the file formats work or everything else that is not strictly related to VICE, you should read the appropriate FAQs first, as this kind of information is not available here. See section 12 Contact information for information about how to retrieve the the FAQs.
All the emulators provide an accurate 6502/6510 emulator, with emulation of all the opcodes (both documented and undocumented ones) and accurate timing. Unlike other emulators, the emulation of all the chips is cycle accurate, and tries to emulate timings as precisely as possible while trying to use as little processor power as possible.
Please do not expect the VIC20, C128 and PET emulators to be as good as the C64 one, as they are still under construction.
The C64 emulator, called `x64', features a fairly complete emulation of the VIC-II video chip: sprites, all registers and all video modes are fully emulated. Since version 0.13.0, the emulation is fully cycle-accurate.
Moreover, a rather complete emulation of the SID sound chip is provided. All the basic features are implemented as well as most of the complex ones including sync, ring modulation and filters.
Of course, also both CIAs are cycle-accurate and fully emulated.
The C128 emulator, called `x128', features a complete emulation of the internal MMU (Memory Management Unit), plus all the features of the C64 emulation. The following things are missing, though:
The VIC20 emulates all the internal hardware, including the VIA chips. Only part of the VIC-I video chip features are emulated, so some graphical effects will not work correctly.
Sound is implemented, but is still at the experimental stage. If you think it does not sound right and know how to improve it, feel free to contact us (see section 12 Contact information).
The PET emulator emulates the 2001, 3032, 4032, 8032, 8096 and 8296 models, which almost covers all models of this kind of machines. The hardware is pretty much the same and that is why one single program is enough to emulate all of them. For more detailed information about PET hardware please refer to the `PETdoc' file.
Both the 40 column and 80 column CRTC video chips are emulated (from the 4032 onward), but a few of the features are not implemented yet (numbers of rasterlines per char and lines per screen). Anyway, those missing features are not very important for average applications.
Sound is available for the PET as well, but like the VIC20 it is still under construction.
The PET 8096 is basically a PET 8032 with a 64k extension board, that
allows remapping the upper 32k with RAM. You have to write to a special
register at $fff0 to remap the memory. The PET 8296 is a
8096 but with a completely redesigned motherboard with 128k RAM in
total. Of the additional 32k RAM you can use only some in blocks of 4k,
but you have to set jumpers on the motherboard for it. VICE uses the
command line options `petram9' and `-petramA'
instead. Also the video controller can handle a larger address range.
The PET 8x96 model emulations run the Commodore LOS-96 operating system
- basically an improved BASIC 4 version with up to 32k for BASIC
text and 32k for variables. See `PETdoc' for more information.
The PET computers came with three major ROM revisions, so-called BASIC 1, 2 and 4, all of which are provided. The PET 2001 uses the version 1, the PET 3032 uses version 2, and the others use version 4. The 2001 ROM is horribly broken in the IEEE488 part (they shipped it before they tested it with the floppy drive, so only tape worked - which is not supported in this emulator) so the ROM is patched to fix the IEEE488 routines.
What the 2001 patch basically does is (amongst more low level fixes) get the load address for a program file from the first two bytes of the file. This allows loading of PET2001-saved files (that have $0400 as load address) and other PET files (that have $0401). The PET2001 still saves from $0400, not from $0401 as other PETs do.
Moreover, the secondary addresses being used now are 0 and
1 for load and save, and not arbitrary unused secondary
addresses.
To select which model to run, you specify the model on the
command line with the -model MODEL option, where
MODEL can be one of a list of PET model numbers, all
described in ...
There are two ways of emulating the keyboard in VICE.
The default way (symbolic mapping) is to map every X11 key combination to the corresponding key combination on the real machine: for example, if you press *, which is bound to Shift-8 on a U.S. keyboard, in the C64 emulator, the emulated machine will have just the unshifted * key pressed (as * is unshifted on the C64 keyboard). Likewise, pressing ' on the same U.S. keyboard without any shift key will cause the combination Shift-7 to be pressed in the emulated C64. This way, it becomes quite obvious what keys should be typed to obtain all the symbols.
There is one problem with symbolic mapping, though: some keys have to be mapped specially anyway. The most important execption is that, in the VIC20, C64 and C128 emulators, CTRL is mapped to Tab and the Commodore key is mapped to the left Control).
The second way (positional mapping) is to map every key on the "real" keyboard to the key which has the same position on the keyboard of the emulated machine. This way, no Shift key is forced by the program (with the exception of the function keys F2, F4, F6 and F8, which require Shift on the Commodore keyboards), and the keyboard is more comfortable to use in those programs (such as some games) that require the keys to be in the correct positions.
Warning: unlike the real C64, VICE "presses" the Shift key together with the key to shift when the Shift must be forced. In most cases this should work fine, but some keyboard routines are quite picky and tend not to recognize the shift key because of this. For instance, F6 (which on the real C64 is obtained with Shift + F5) could be recognized as F5. In that case, use the shift key manually (i.e. type Shift + F5 in the example). Yes, we know this is a bug.
Joysticks can be emulated both via the keyboard and via a real joystick connected to the host machine (the latter only works on GNU/Linux systems).
There are two keyboard layouts, called numpad and custom layouts respectively.
The numpad layout uses the numeric keypad keys, i.e. the numbers 1...9 which emulate all the directions including the diagonal ones; 0 emulates the fire button.
The custom layout uses the keys q, w, e, a, s, d, z, x, c for the directions and space for the fire button instead.
All the emulators support emulation of up to 4 external disk drives as devices 8, 9, 10 and 11. Each of these devices can emulate virtual Commodore 1541 drives in two ways:
comp.emulators.cbm FAQ);
P00 format (again, consult the
comp.emulators.cbm FAQ for more info).
Moreover, there are two available types of 1541 emulation for the first kind of emulation. One of them the DOS level drive emulation. It does not really emulate the serial line, but patches the kernal ROM (with the so-called kernal traps) so that serial line operations can be emulated via C language routines. This emulation is very fast, but only allows use of standard DOS functions (and not even all of them).
The other alternative is a hardware level drive emulation. The Commodore 1541 disk drive was provided with its own CPU (a 6502 as the VIC20 and the PETs) and its own RAM and ROM. So, in order to more closely emulate its features, a complete emulation of this hardware must be provided and that is what the hardware level emulation does. When the hardware level emulation is used, the kernal routines are no longer patched and the serial line is fully emulated. The problem with this emulation is that it needs a lot of processing power, mainly because the emulator has to emulate two CPUs instead of one.
The hardware level emulation is only available on the VIC20 and C64 emulators, and can only be used to emulate one drive at a time. As a consequence, it is only available for unit 8 and disables all the other drives when activated.
On the other hand, the PETs don't use a serial IEC bus to communicate with the floppy, instead they use the parallel IEEE488 bus. This bus transfers byte by byte, as opposed to bit by bit as the C64 and VIC20 do, so in this case it is feasible to emulate the parallel line completely while emulating the drive at DOS level only. The IEEE488 line interpreter maps the drives 8-11 (as described above) to the IEEE488 disk units, and no kernal traps are needed. The same emulation is available in the C64, to emulate the Commodore IEEE488 bus interface.
VICE supports the most popular Commodore file formats:
X64 (preferred) or D64 disk image files;
G64 GCR-encoded 1541 disk image files;
T64 tape image files (read-only);
P00 program files;
An utility (c1541, see section 9 c1541) is provided to allow transfers
between these formats.
Notice that the native format for disk images is X64; this
means that, although the emulators and utilities can both read and write
on D64 disk images, they never produce D64 files.
You can convert an X64 file back into a D64 file with the
UNIX dd command:
dd bs=64 skip=1 if=IMAGE.X64 of=IMAGE.D64
This section tries to describe the most common known problem with VICE, and how to resolve them.
VICE should compile and run without major problems on many UNIX systems, but there are some known issues related to the sound driver. In fact, sound is the least portable part of the emulator and has not been thoroughly tested on all the supported platforms yet.
Linux, AIX and SGI systems should play sound without any problems; if you are running Linux please use the new 2.x kernels, as VICE needs some features that were not implemented in older versions of the Linux sound driver.
On the other hand, HP-UX and Solaris machines are known to cause troubles. If you think you can help debugging the code for these systems, your help would be really appreciated. We are having troubles finding HP-UX and SUN consoles to work at...
If you cannot start VICE, because you get errors about shared memory, try to run it with the `+mitshm' command-line option (see section 6.4.2 Video command-line options). This will completely disable usage of the MITSHM extensions, that are normally used to speed up the process of updating the emulation window. Of course, this will also result in a big loss in speed.
Reasons for this failure could be:
If you want to avoid running the emulator with `+mitshm' every time, run it once with `+mitshm' and then choose "Save settings" from the right-button menu.
Go to the first, previous, next, last section, table of contents.