VICE is the one and only Versatile Commodore Emulator. It providesemulation of the Commodore C64, C64DTV, C128, VIC20, PET, PLUS4, SCPU64 and CBM-II computerswithin a single package. The emulators run as separate programs, but havethe same user interface, share the same settings and support the samefile formats.
Important notice: If you have no idea what a Commodore8-bit computer is, or have questions about how these machines are used,how the file formats work or anything else that is not strictlyrelated to VICE, you should read the appropriate FAQs first, asthat kind of information is not available here. See section 19 Contact information. forinformation about how to retrieve the FAQs.
All the emulators provide an accurate 6502/6510 emulator, with emulationof all the opcodes (both documented and undocumented ones) and accuratetiming. Unlike other emulators, VICE aims to be cycleaccurate; it tries to emulate chip timings as precisely as possible anddoes so efficiently.
Please do not expect the C64DTV, C128, PET, PLUS4, SCPU64 and CBM-II emulators tobe as good as the C64 or VIC20 one, as they are still under construction.
Notice: This documentation is written for the Unix release of VICE, but is slowly being made universal.
1.1 Emulator features
1.1.1 C64 emulator features
As of version 2.3, two C64 emulators are provided: `x64' (fast)and `x64sc' (accurate). As of version 3.4 `x64' will no more getbuilt by default and is not contained in the default binary packages.
The fast C64 emulator, called `x64', features a fairly completeemulation of the VIC-II video chip: sprites, all registers and all videomodes are fully emulated. The emulation has been fully cycle-accuratesince version 0.13.0.
The accurate C64 emulator, called `x64sc', features a cycle-basedand pixel-accurate VIC-II emulation. This requires a much faster machinethan the old `x64'.
A rather complete emulation of the SID sound chip is also provided. Allthe basic features are implemented as well as most of the complex onesincluding synchronisation, ring modulation and filters. There are twoemulators of the SID chip available: first is the "standard" VICEemulator, available since VICE 0.12; the second is Dag Lem's reSIDengine. The reSID engine is a lot more accurate than the standard engine,but it is also a lot slower, and only suitable for faster machines.
Naturally, also both CIAs (or VIAs, in some cases) are fully emulatedand cycle accurate.
1.1.2 C64DTV emulator features
The C64DTV emulator, called `x64dtv', features emulation of C64DTVrevisions 2 and 3. The emulator is under construction, but most of theDTV specific features are already supported (with varying accuracy).
Video cache is disabled by default as it currently doesn't work withsome of C64DTV's new video modes. The new video modes have a simple"fake" video cache implementation that may give incorrect resultsand decreased performance.
1.1.3 C128 emulator features
The C128 emulator, called `x128', features a complete emulation ofthe internal MMU (Memory Management Unit), 80 column VDC screen, fastIEC bus emulation, 2 MHz mode, Z80 emulation plus all the features of theC64 emulation.
1.1.4 VIC20 emulator features
The VIC20 emulates all the internal hardware, including the VIA chips.The VIC-I video chip is fully emulated except NTSC interlace mode, so mostgraphical effects will work correctly.
The VIC20 emulator allows the use of the VIC1112 IEEE488interface. You have to enable the hardware (by menu, resource, orcommandline option) and then load the IEEE488 ROM (see forexample http://www.funet.fi/pub/cbm/schematics/cartridges/vic20/ieee-488/325329-04.bin, but you have to double the size to 4KiB for now).The IEEE-488 code is then started by SYS45065.
1.1.5 PET emulator features
The PET emulator emulates the 2001, 3032, 4032, 8032, 8096, 8296 andSuperPET (MicroMainFrame 9000) models, covering the whole series.The hardware is pretty much the same in each and that is why one singleprogram is enough to emulate all of them. For more detailed informationabout PET hardware please refer to the PETDoc file.
Both the 40 column and 80 column CRTC video chips are emulated (from the4032 onward), but a few of the features are not implemented yet (numbersof rasterlines per char and lines per screen). Fortunately, they arenot very important for average applications.
The PET 8096 is basically a PET 8032 with a 64KiB extension board whichallows remapping the upper 32KiB with RAM. You have to write to a specialregister at $fff0 to remap the memory. The PET 8296 is a8096 but with a completely redesigned motherboard with 128KiB RAM intotal. Of the additional 32KiB RAM you can use only some in blocks of 4KiB,but you have to set jumpers on the motherboard for it. VICE uses thecommand 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 32KiB for BASICtext and 32KiB for variables. See PETDoc for more information.
The PET 8296D is an 8296 with built-in 8250 low-profile dual disk drive.
The PET 8296GD is an 8296D with additionally a "HiRes Emulator" (HRE).This is a cheaper version of a "HRG" hi-res board which was based onThomson chips. This version instead uses no additional hardware supportapart from some memory mapping tricks. It has supporting software in thehre-*.bin rom files.
The SuperPET also is a PET 8032 with an expansion board. It can map 4KiBat a time out of 64KiB into the $9*** area. Also it has an ACIA6551 for RS232 communication. The 6809 CPU that is built into theSuperPET is now emulated, since release 2.4, including the 6702 donglechip.
The Super-OS-9 MMU expansion, developed by TPUG (Toronto PET UsersGroup) is also emulated.
The PET computers came with three major ROM revisions, so-called BASIC1, 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 ROMis horribly broken with respect to IEEE488 (they shipped it before theytested it with the floppy drive, so only tape worked. Therefore theemulator patches the ROM to fix the IEEE488 routines.
As well as other low-level fixes the 2001 patch obtains the load addressfor a program file from the first two bytes of the file. This allowsthe loading of both PET2001-saved files (that have $0400 as their loadaddress) and other PET files (that have $0401). The PET2001 saves from$0400 and not from $0401 as other PETs do.
Moreover, the secondary addresses used are now 0 and 1 forload and save, respectively, and not arbitrary unused secondaryaddresses.
To select which model to run, specify it on thecommand line with the -model MODEL option, whereMODEL can be one of a list of PET model numbers, alldescribed in see section 6.7.1 Changing PET model settings
1.1.6 CBM-II emulator features
The CBM-II emulator emulates several types of CBM-II models. Thosemodels are known under different names in the USA and Europe. In theStates they have been sold as B128 and B256, in Europe asCBM 610, CBM 620 (low-profile case) or CBM 710 andCBM 720 (high-profile case with monitor). In addition to thatnow an experimental C510 emulation is included. The C510 (also known asP500) is the little brother of the C600/700 machines. It runs at roughly1 MHz and, surprise, it has a VIC-II instead of the CRTC. Otherwisethe different line of computers are very similar.
These computers are prepared to take a coprocessor board with an 8088 orZ80 CPU. Indeed there are models CBM 630 and CBM 730 thatsupposedly had those processors. However these models are not emulated.
The basic difference is the amount of RAM these machines have beensupplied with. The B128 and the CBM *10 models had 128KiBRAM, the others 256KiB. This implies some banking scheme, as the 6502 canonly address 64KiB. And indeed those machines use a 6509, that canaddress 1 MiB of RAM. It has 2 registers at addresses 0 and 1. Theindirect bank register at address 1 determines the bank (0-15) where theopcodes LDA (zp),Y and STA (zp),Y take the data from. Theexec bank register at address 0 determines the bank where all other readand write addresses take place.
The business line machines (C6xx/7xx) have the RAM in banks 1-2, resp.1-4. All available banks are used for BASIC, where program code is separatedfrom all variables, resp. from normal variables, strings and arrays thatare distributed over other banks. The C510 instead has RAM in banks 0 and 1,and uses bank 1 for program and all variables. Bank 0, though, can beaccessed by the VIC-II to display graphics.
Many models have been expanded to more than the built-in memory. In factsome machines have been expanded to the full 1MiB. Bank 15 is used assystem bank, with only little RAM, and lots of expansion cartridge ROMarea, the I/O and the kernal/basic ROMs. Some models have been modifiedto map RAM into the expansion ROM area. Those modifications can beemulated as well.
The different settings are described in see section 6.8.1 Changing CBM-II model.
1.1.7 SCPU64 emulator features
The XSCPU64 emulator is a simulation of a C64 equipped with a SuperCPU64 V2B. Features:
- 20 MHz asynchronous single cycle 65816 CPU core with proper dummy and invalid cycle handling.
- 128 KiB static RAM, 0-16 MiB SIMM RAM, 64-512 KiB EPROM emulated and their respective timing details.
- All RAM optimization configurations supported with write buffer.
- I/O area access delays, write through to SRAM implemented.
- Memory mappings including cartridge and boot memory map and kernal shadow.
- Hardware registers and switches implemented.
- Replacement SCPU64 ROM compatible with the original to avoid distribution problems
- It's using the single cycle VICII core for accurate simulation
Still to do:
- Measure and verify VICII interrupt phase shift
- Measure and verify BA phase shift
- SIMM RAM extra 7.5 cycle refresh delay every 10us missing.
- CPU NMI support for "reset" button
The emulation is quite accurate but not perfect. If you code something timingintensive using this simulation please always check it on real hardware to avoidbad surprises.
The hardware itself is asynchronous in nature, therefore caution must be takento not do long timing loops without synchronization in 20 MHz mode. Also don'tsqueeze out the last remaining cycles without leaving a safety buffer.Synchronization points can be created by doing I/O reads or writes and leavinga few hundred cycles left each frame will not hurt.
Otherwise it can happen that the code is running on this version of VICE or mySCPU64 V2+C128D perfectly but nowhere else due to manufacturing variations andfrequency drifts.
1.2 The keyboard emulation
There are two fundamentally different ways of emulating the keyboard in VICE,both of which have their individual shortcomings and strengths:
Symbolic Mapping
The default way (symbolic mapping) is to map every key - as far as possible - in a way that inside the emulation the symbol that is printed on the host key is produced.For example, if you press *, which is bound to Shift-8 on aU.S. keyboard, in the C64 emulator, the emulated machine will have justthe unshifted * key pressed (as * is unshifted on theC64 keyboard). Likewise, pressing ' on the same U.S. keyboardwithout any shift key will cause the combination Shift-7 to bepressed in the emulated C64. This way, it becomes quite obvious whatkeys should be typed to obtain all the symbols. The key printed on the host keyboard will be pressed in the emulator. Note that while these mappings will allow easier typing if you are used to your host keymap, it might cause various problems in the emulation and not all emulated keys are accessible. If you encounter such problems, try the positional mapping.
- Some keys reallyneed to be mapped specially regardless (those that do not exist on a PCkeyboard). Some examples are the Commodore key, RUN/STOP, Clear/Home. The exact mapping depends on your host layout, but shouldfollow mostly the layouts shown below. If in doubt, you can read the keyboardmapping files.
- the emulator hasto "de-shift" (remove the shift modifier) from some keys. For example, if youwant to get a ":" on a german keyboard, you have to press "." and shift simulaneously.Then, the emulator sees the events "shift pressed" and ":" pressed. At the momentyou have pressed shift, the emulator does not know what key you are using next(or even if you are actually going to use another key before releasing shift again),so it has to deliver this state to the keyboard matrix. If you press ".", then shift,to achive a ":", the emulator has to take back the shift key although it is stillpressed, as the ":" is an unshifted key in the c64/c128 keyboard matrix.
- A similar problem exists when you press a key that is unshifted on the host keyboard,and the emulator must "shift" (add the shift modifier) for the emulated keyboard. Forexample on a US keyboard the brackets ([,]) are such a case. Unlike what would happenon the real C64 when typing, VICE "presses" the Shift key togetherwith the key to shift when the Shift must be forced. In most cases thisshould work fine, but some keyboard routines are quite picky (eg x128 in CP/M mode) and tend not torecognize the shift key because of this. For instance, F6 (which on thereal 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. Unfortunately it is less than trivial to fix 100%. Ifyou encounter any problems, please use a positional keymap as a workaround - thatshould always work as expected.
PROs:
- Mostly intuitive typing if your muscle memory is conditioned strong to your host keyboard.
CONs:
- Does not preserve the position of the keys.
- Due to how the key mapping may add or remove the SHIFT flag from individualkeys, strange side effects may occur (see above).
- SHIFT/LOCK is added to the emulated keys - which may give unexpected resultsdepending on your host OS and keymap (It is really emulating the SHIFT-LOCK key andnot working as a CAPS-LOCK like in your host OS anymore).
Positional Mapping
For the positional mappings first all keys are mapped at their exact positions,as far as possible, and then the remaining few (usually 2 or 3) will be mappedto other, yet unused, keys. This is the recommended mapping for playing games orother programs that require keys+modifiers (shift/control/cbm) to work exactlylike on the emulated machine. This way the keyboard is more comfortable to use in those programs (such as some games) that require the keys to be in the correct positions. On the other hand it can be quite confusing if you are notvery familiar with the original emulated keyboards. Also not all keys can bemapped exactly this way either, which means some of them still need to bemapped to other keys (see further down).
Like with symbolic mapping, some keys really need to be mapped speciallyregardless (eg RUN/STOP). The exact mapping depends on your host layout,but should follow mostly the layouts shown below. If in doubt, you can read thekeyboard mapping files.
PROs:
- Mostly intuitive typing if your muscle memory is conditioned strong to your (eg) C64 keyboard.
- Does preserve the position of (most of) the keys.
- Natural SHIFT and SHIFT/LOCK behaviour
CONs:
- Weird to use if you are not familiar with the emulated (eg) C64 keyboard.
Notes
We depend a lot on your support to improve the keyboard maps, as we can nottest all emulators in all possible configurations and using all host keyboardmappings. Please report any problems to us so we can fix them!
If you experience problems with 'accent' keys such as acute, grave, tilde, circumflex, diaresis (and possibly more/other, depending on your host keyboardlayout) try switching to a "no deadkeys" layout in your OS. Note that currentlySDL requires using a "no deadkeys" keyboard layout! In any case, pleasealso report these problems so we can fix them!
For more information on making your own keymaps (or helping to fix/update theexisting ones), see see section 3.2 Keymap files.
This mapping applies to the C64, SCPU, VIC20 and DTV emulators.
1.2.1.1 Symbolic (US)
1.2.1.2 Positional (US)
1.2.1.3 Symbolic (DE)
1.2.1.4 Positional (DE)
1.2.2 C128 Keyboard Map
This mapping applies to the C128 emulator. It is for a large part identical withthe respective C64 mapping, plus the added function- and extra keys.
Note that to use the numpad, you will have to disable the "allow keyset joysticks"setting.
1.2.2.1 Symbolic (US)
1.2.2.2 Positional (US)
1.2.2.3 Symbolic (DE)
1.2.2.4 Positional (DE)
This mapping applies to the Plus4 emulator
1.2.3.1 Symbolic (US)
1.2.3.2 Positional (US)
1.2.3.3 Symbolic (DE)
1.2.3.4 Positional (DE)
1.2.4 PET Graphics Keyboard Map
The PET2001 uses the original graphics keyboard made from "chiclet" keys:
The 3032 and 4032 use "real" graphics keyboard, which is based on the same keyboardmatrix and looks like this:
For practical reasons, there is no extra keymap for the chiclet keyboard - anyattempt to somehow reproduce that would end up too similar to what we are usingnow for the graphics keyboard anyway:
1.2.4.1 Symbolic (US)
1.2.4.2 Positional (US)
1.2.4.3 Symbolic (DE)
1.2.4.4 Positional (DE)
1.2.5 PET Business Keyboard Map
This Layout is used for the "big" PET models, like the 8032. The matrix is notcompatible to the graphics keyboard:
1.2.5.1 Symbolic (US)
1.2.5.2 Positional (US)
1.2.5.3 Symbolic (DE)
1.2.5.4 Positional (DE)
1.2.6 CBM2 Keyboard Map
This Layout is used for all CBM2 machines:
1.2.6.1 Symbolic (US)
1.2.6.2 Positional (US)
1.2.6.3 Symbolic (DE)
1.2.6.4 Positional (DE)
1.3 The joystick emulation
Joysticks can be emulated both via the keyboard and via a real joystickconnected to the host machine.
There are two keyboard layouts for joystick use, known as numpadand custom.
The numpad layout uses the numeric keypad keys, i.e., the numbers1...9 which emulate all the directions including thediagonal ones; 0 emulates the fire button.
The custom layout is configurable to your liking.
For some of the emulators there can be extra joysticks besides the built-injoystick ports, the following list provides the mappings for the currentlysupported joystick/joypad ports:
The internal joystick port 1 [x64/xscpu64/x64dtv/x128/xvic/xplus4/xcbm5x0] is mapped to joystick device #1.
The internal joystick port 2 [x64/xscpu64/x64dtv/x128/xplus4/xcbm5x0] is mapped to joystick device #2.
The CGA userport joystick adapter ports 1 and 2 (x64/xscpu64/x128/xvic/xpet/xcbm2) are mapped to extra joystick devices #1 & #2 respectively.
The PET userport joystick adapter ports 1 and 2 (x64/xscpu64/x128/xvic/xplus4/xpet/xcbm2) are mapped to extra joystick devices #1 & #2 respectively.
The C64DTV HUMMER userport joystick adapter port (x64/xscpu64/x128/xvic/xplus4/xpet/xcbm2) is mapped to extra joystick device #1.
The OEM userport joystick adapter port (x64/xscpu64/x128/xvic/xplus4/xpet/xcbm2) is mapped to extra joystick device #1.
The HIT userport joystick adapter ports 1 & 2 (x64/xscpu64/x128) are mapped to extra joystick devices #1 & #2 respectively.
The KingSoft userport joystick adapter ports 1 & 2 (x64/xscpu64/x128) are mapped to extra joystick devices #1 & #2 respectively.
The StarByte userport joystick adapter ports 1 & 2 (x64/xscpu64/x128) are mapped to extra joystick devices #1 & #2 respectively.
The Petscii userport SNES pad adapter port (x64/xscpu64/x128/xvic/xcbm2) is mapped to extra joystick device #1.
The Superpad64 userport SNES pad adapter ports 1, 2, 3, 4, 5, 6, 7 & 8 (x64/xscpu64/x128/xvic/xcbm2) are mapped to extra joystick devices #1, #2, #3, #4, #5, #6, #7 & #8 respectively.
The Inception joystick adapter ports 1, 2, 3, 4, 5, 6, 7 & 8 (x64/x64sc/xscpu64/x64dtv/x128/xcbm5x0/xvic) are mapped to extra joystick devices #1, #2, #3, #4, #5, #6, #7 & #8 respectively.
The MultiJoy joystick adapter ports 1, 2, 3, 4, 5, 6, 7 & 8 (x64/x64sc/xscpu64/x64dtv/x128/xcbm5x0) are mapped to extra joystick devices #1, #2, #3, #4, #5, #6, #7 & #8 respectively.
The SpaceBalls joystick adapter ports 1, 2, 3, 4, 5, 6, 7 & 8 (x64/x64sc/xscpu64/x64dtv/x128/xcbm5x0) are mapped to extra joystick devices #1, #2, #3, #4, #5, #6, #7 & #8 respectively.
The Ninja SNES pad adapter ports 1, 2 & 3 (x64/x64sc/xscpu64/x64dtv/x128/xcbm5x0/xplus4) are mapped to extra joystick devices #1, #2 & #3 respectively.
The Stupid Pet Tricks joystick adapter port (x64/x64sc/xscpu64/x128/xcbm2/xpet/xvic) is mapped to port extra joystick device #3.
The ProtoPad SNES pad adapter port is mapped to the same port it is attached to.
The Trap-Them SNES pad adapter port is mapped to the same port it is attached to.
The MicroFlyte analog joystick is mapped to the same port it is attached to.
The SID cartridge joystick port (xplus4) is mapped to extra joystick device #9.
1.4 The disk drive emulation
All the emulators support up to 4 external disk drives asdevices 8, 9, 10 and 11. Each of these devices can emulate virtualCommodore 1541, 1541-II, 1571, 1581, 2031, 2040, 3040, 4040, 1001, 8050, 8250,and D9090/60 drives in one of the following ways:
- using disk images, i.e., files that contain a dump of all the blockscontained in a real floppy disk;
- accessing file system directories, thus giving you the use of fileswithout having to copy them to disk images; this also allows you toread and write files in the
P00format. - accessing a real device connected to the host machine. This works using the OpenCBM library. You can get it from https://spiro.trikaliotis.net/opencbm.Make sure to pick the right library (32 or 64bit) for your system.
- To use it in the emulators, go to the drive tab in the settings and chooseeither "Virtual Device" or "IEC Device" and "Real Drive (OpenCBM)".Note that this will not work with all emulators right now. Also note that usingthe real drives like this provides only very limited compatibility in practise -it is recommended to transfer the disks to images and use the images with anemulated drive in the emulator.
- If you want to use OpenCBM with c1541:
- Use "opencbm" as filename (instead of the disk image name).
- With older linux drivers, that provide a device file, use that devicefile as filename (eg /dev/cbm).
When using disk images there are two available types of driveemulation. One of them the virtual drive emulation. It doesnot really emulate the serial line, but patches the kernal ROM(with the so-called kernal traps) so that serial line operationscan be emulated via C language routines. This emulation is very fast,but only allows use of standard DOS functions (and not even all ofthem). For real device access it is required to enablethis type of emulation.
The IEEE488 drives (2031, 2040, 3040, 4040, 1001, 8050, 8250, and D9090/60)do not use kernal traps. Instead the IEEE488 interface lines aremonitored and the data is passed to the drive emulation. To use themon the C64, you need to enable the IEEE488 interface emulation. Onlyif the IEEE488 emulation is enabled, those drives can be selected.
The other alternative is a true drive emulation. TheCommodore disk drives are provided with their own CPU (a 6502 as theVIC20 and the PETs) and their own RAM and ROM. So, in order to moreclosely emulate its features, a complete emulation of this hardwaremust be provided and that is what the hardware level emulationdoes. When the hardware level emulation is used, the kernalroutines remain unpatched and the serial line is fully emulated.The problem with this emulation is that it needs a lot of processingpower, mainly because the emulator has to emulate two CPUs instead ofone.
The PETs do not use a serial IEC bus to communicate with the floppydrive but instead use the parallel IEEE488 bus. This doesbyte by byte transfers, as opposed to the bit by bittransfers of the C64 and VIC20, so making it feasible to emulate theparallel line completely while emulating the drive at DOS level only.The IEEE488 line interpreter maps the drives 8-11 (as describedabove) to the IEEE488 disk units, and no kernal traps are needed.The same emulation of the Commodore IEEE488 bus interface isavailable for the C64 and the VIC20. With IEEE488 drives you can havetrue 2031 emulation at unit #8, and still have filesystem access atunits #10 or #11, because monitoring the IEEE488 lines does notinterfere with the true drive emulation.
The IEEE488 disk units 2040, 3040, 4040, 8050 and 8250 are Dual DriveFloppy Disks. This means that these devices handle two disks.The drives are numbered 0 and 1.
The Commodore 2040, 3040, 4040, 1001, 8050, 8250, and D9090/60 drives areso-called "old-style" disk drives. Their architecture includes notone, but two processors of the 6502 type, namely a 6502 for the filehandling and communication with the PET (IP), and a 6504 (which is a6502 with reduced address space) for the drive handling (FDC). Bothprocessors communicate over a shared memory area. The IP writescommands to read/write blocks to this area and the FDC executes them.To make the emulation feasible, the FDC processor is not emulatedcycle-exactly as a 6504, but simply by checking the commands andexecuting them on the host. This provides a fast FDC emulation, butdisallows the sending the FDC processor commands to execute code.Applications where this is necessary are believed to be ratherseldom. Only the format command uses this feature, but this ischecked for.
The dual disk drive 2040 emulates one of the very first CBM diskdrives. This drive has DOS version 1. DOS1 uses an own disk type,that is closely related to the 1541 disk image. Only on tracks 18-24DOS1 disks have a sector more than 1541 disks. DOS1 disk images havethe extension .d67.
The dual disk drives 3040 and 4040 use the same logical disk formatas the VC1541 and the 2031. In fact, the 4040 was the first disk withDOS version 2. The 3040 emulated here originally was the same as2040, only for the european 30xx PET series. As many of the originalDOS1 disk drives were upgraded (a simple ROM upgrade!) to DOS2, I usethe 3040 number for a DOS 2.0 disk drive, and 4040 for a revised DOS2 disk drive. It is, however, not yet clear whether the disks hereare write compatible to the 1541, as rumors exist that the write gapbetween sectors is different. But read compatible they are. As VICEemulates the FDC processor in C and not as 6504 emulation, this doesnot matter in VICE.
The drives 1001, 8050 and 8250 do actually have the very same DOSROM. Only the code in the FDC is different, which is taken care of byVICE. So for all three of those disk drives, only dos1001 isneeded. The DOS version used is 2.7.
The D9090/60 is the only Commodore branded hard drive produced forthe PET series computers, and were often used by C64 and C128 users fortheir significant storage capacity (29162/19441 free blocks).Just like the other IEEE drives before it, it uses a separateCPU as the FDC which in turn communicates with the SASI-to-ST506 bridge(which is controlled by an AM2910). The hardware design is very similarto the 8050/8250 drive.
Creative Micro Designs (CMD) produced the last drives for theCommodore 8-bit systems. They first released the hard drive (HD) line,and later the floppy drive (FD) line. The CMD HD series can support upto 4 GiB HDs with 255 separate partitions, while the CMD FD series cansupport up to 3.3 MB extended density floppy disks with 31 separatepartitions. The FD series are also backwards compatible with 1581media. The DOS for the FD series is stored on a ROM (dos2000and dos4000, the latest versions being 1.40).
The CMD HD uses a small boot ROM (dosCMDHD, the latest versionis 2.80) which loads the primary DOS (latest is 1.92) off the HDitself. This allows for easy upgrades and expandability. This is alsothe only drive to use the front panel buttons to control the mode ofthe drive on reset. There are three modes of operation: normal,configuration, and installation. VICE supports placing the drive ineither of these modes through the "Reset" sub-menu on the status barfor the GTK3 interface, and the "Reset" menu in the SDL interface.When creating a new DHD image, simply create an EMPTY file and VICEwill automatically place the drive in installation mode.The DOS will detect the drive as the size specified by "Drive#FixedSize"(or "-drive#fixedsize") which is 8GB by default.To use a specific sized disk, set this value to the maximum size, orset this value to "0" and set the image file on disk to the desired size(it should be a multiple of 512 bytes).Once the DOS is installed, the CMD "hd-tools" program can be used toconfigure various settings and partition the drive; this is done inconfiguration mode for safety.When in either configuration or installation mode, the device number isset to 30.Therefore, it is not suggested to place two or more CMD HDs in eitherof these modes on the same bus at the same time.When migrating from real CMD hardware, use any HDD imaging software ("dd"or GNU "ddrescue" on Linux) to copy the raw contents of a device to a file.The destination file should have a "DHD" extension.For those users with multiple disks, SCSI ID 0, LUN 0 should have theextension "DHD", but any other drives should have ".S<ID><LUN>" where <ID>is the SCSI ID and <LUN> is the LUN or logical unit.Place all the files in the same folder when attaching to the "DHD" file.The other files will automatically be scanned for and connected as well.The CMD HD boot ROM is used for partition management, and ALL versions havea known bug which corrupts data when deleting paritions across multipleSCSI drives.To avoid this scenario, it is highly suggested that another full DHDimage be created in VICE (on another unit) and all the files be copiedover from multi-disk configurations, using CMD "fcopy" for example, tothe new unit.This will allow the user to take advantage of all the CMD HD featureswithout the potential for data loss.
1.5 Supported file formats
VICE supports the most popular Commodore file formats:
X64orD64disk image files; Used by the 1541, 2031, 3040, 4040 drives.G64GCR-encoded 1541 disk image filesP64lowlevel NRZI flux pulse disk image filesD67CBM2040 (DOS1) disk image formatD71VC1571 disk image formatD81VC1581 disk image formatD80CBM8050 disk image formatD82CBM8250/1001 disk image formatD90CBM D9090/60 disk image formatD1MFD2000/FD4000 DD disk image formatD2MFD2000/FD4000 HD disk image formatD4MFD4000 ED disk image formatDHDCMD HD disk image formatT64tape container files (read-only)TAPlowlevel tape image filesP00program filesCRTC64 cartridge image filesTCRTtapecart image files
A utility (c1541, see section 13 c1541) is provided to allow transfersand conversions between these formats.
Notice that the use of the X64 file format is deprecated now.
You can convert an X64 file back into a D64 file with theUNIX dd command:
dd bs=64 skip=1 if=IMAGE.X64 of=IMAGE.D64
See section 16 The emulator file formats. for a technical description of the supported fileformats.
1.6 Common problems
This section tries to describe the most common known problems with VICE,and how to resolve them.
1.6.1 Sound problems
VICE should compile and run without major problems on many systems,but there are some known issues related to the sound driver.
If you are having sound problems, such as skipping, first monitor how much CPUtime the respective emulator is taking on your system. To run smoothly, on amodern system, it should really never go over 50% or so, except for very shortpeaks that should also stay well beyond 90%. If you see it takes more, trydisabling some of the most CPU intense features (disable CRT emulation, usefastsid instead of reSID, disable true drive emulation).
If the CPU usage is ok, try using a different sound driver. You may also tryincreasing the sound buffer size (although the default should be ok for modernsystems).
All platforms that can run the SDL port (like Amiga, BeOS, etc) should be ableto play sound via SDL.
1.6.2 Video problems
If you don't get video output, the problem may be that your system has nosuitable Open-GL driver - which is strictly required for the GTK3 port. Havea look at the logfile to see if this is the problem.
1.6.3 Printer problems
VICE supports the emulation of a printer either on the userport or asIEC device 4-7. Unfortunately the Commodore IEC routines do notsend all commands to the IEC bus. For example an OPEN 1,4is not seen on the IEC bus. Also a CLOSE 1 after thatis not seen. VICE can see from printing that there was an OPEN,but it cannot see when the close was. Also a "finish print job"cannot be seen on the userport device.To flush the printer buffer (write to print.dump or to theprinter) you can manually trigger a form feed in the printer settings.
1.6.4 PET keyboard problems
If you find that the German keyboard mapping (plus German charset)does not print uppercase umlauts, then you are right.The umlauts replace the [,\ and ] characters in the charset. The keysthat make these characters do not have a different entry in thePET editor ROM tables when shifted.Thus it is not possible to get the uppercase umlauts in the editor.Nevertheless other programs are reported to change the keyboardmapping table and thus allow the use of the shifted (uppercase) umlauts.
Anyway, the VICE keyboard mappings are far from being perfect and we are opento any suggestions.
Go to the first, previous, next, last section, table of contents.
