`Q1: Why uCON64?
Q2: How do I get started using uCON64?
Q3: How do I compile/build uCON64?
Q4: How do I install uCON64?
Q5: Sometimes my terminal seems to be locked after "ucon64 -xswc <file> | more"
Q6: How do I make uCON64 only display information about a ROM?
Q7: I have two parallel ports in my PC and my Flash Advance Linker is connected to the second. However, when I try to use uCON64 to send a demo to the FAL something goes wrong. What happened?
Q8: I tried to dump a SNES cartridge using a Super Wild Card connected to my PC with an interlink cable, but it did not work. What is wrong?
Q9: I have a SNES ROM of which GoodSNES says it is good, but uCON64 says it is bad. Who is right?
Q10: I have a SNES ROM of which Snes9x and ZSNES say it is bad, but uCON64 says it is good. Who is right?
Q11: I have a SNES ROM of which uCON64 said it was bad, so I used the -chk option. Now uCON64, Snes9x and ZSNES all say the ROM is good, but GoodSNES still says it is bad. How can that be, I did fix the ROM, right?
Q12: Some SNES games do not work on my Super Wild Card. What can I do about that?
Q13: Which backup devices are supported by uCON64?
Q14: I use Windows XP (NT/2000). When I try to run ucon64.exe in command.com (start -> Run... -> command) uCON64 crashes. What do I do wrong?
Q15: I do not like the command line. Are there graphical frontends available?
Q16: Where do I get PPF, APS or IPS patches?
Q17: Where do I get ROMs/Games?
Q18: What does "[ROM|IMAGE|SRAM|FILE|DIR|ARCHIVE]..." mean in the help?
Q19: Why is my backup unit (still) not supported?
Q20: How do I specify a bank number for the GB Xchanger?
Q21: What is the difference between the Flash Advance Linker options -xfals and -xfalb <n>?
Q22: uCON64 exits with the message "ERROR: Flash card erase failed" when I try to write a multi-game file to my Flash Advance Linker flash card. What is wrong?
Q23: Where can I get that Flash Advance Linker loader or "game pack" file?
Q24: What is the meaning of the -col option (SNES)?
Q25: Why does uCON64 create ucon64.cfg (DOS executable) or .ucon64rc (Win32 executable) files all over the place on DOS and Windows 9x (command.com)?
Q26: When I try to create a multi-game file on Windows I get the message "The system cannot execute the specified program." (or something similar). What does that mean?
Q27: I tried to run a Win32 executable of uCON64 but Windows gave an error message that cygwin1.dll, cygz.dll or zlib.dll could not be found.
Q28: How do I make uCON64 display one help screen at a time?
Q29: I tried to send a ROM dump to my backup unit on Windows XP (NT/2000), but uCON64 crashed. What is wrong?
Q30: I want to convert a NES ROM in iNES format to UNIF. How do I know what board name to use?
Q31: How do I convert a NES ROM from Pasofami to FFE? Or from UNIF to Pasofami?
Q32: How do I specify dumper information when converting to UNIF?
Q33: How do I specify that a NES game in UNIF format supports multiple controller types?
Q34: How do I enable or disable colors in the display output of uCON64?
Q35: When I try to convert a large number of files using wildcards, uCON64 will only convert the first file. Is this a bug?
Q36: Does uCON64 support DAT (RomCenter/GoodXXXX) files?
Q37: Some SNES games do not work on my Super Pro Fighter Q(+). What can I do about that?
Q38: uCON64 displays too many lines for my DOS-box. What can I do about that?
Q39: When will the next version of uCON64 be released? I have heard the next version is able to crack my favourite SNES game, but I do not know how to use Subversion or a compiler.
Q40: What is the format of the snes*.txt files?
Q41: Is it possible to force uCON64 to send or dump (an) SRAM (file) instead of that it depends on whether the file exists?
Q42: Why does uCON64 support DAT files?
Q43: How should the option --mkdat be used?
Q44: What tools do you recommend besides uCON64?
Q45: What is an interleaved ROM?
Q46: The pre-compiled GNU/Linux binary does not work on my system, while a binary compiled by me works fine. How can that be?
Q47: I use Windows XP (NT/2000) and every time I run uCON64 I get this error message about ntuser.dat. What does it mean?
Q48: Is there any way to make uCON64 convert a ROM dump to Game Doctor SF3/SF6/SF7 format and split it, in one command?
Q49: How do I use the command line?
Q50: I configured uCON64 to use ppdev and tried to send a file to my backup unit as a regular user. I got an error message that the parallel port device could not be opened. What did I do wrong?
Q51: What do I need to do before I can upload files to my Flash 2 Advance?
Q52: What is the option --xreset for? In what case should it be used?
Q53: I am trying to use a PCIe parallel port card, but while uCON64 can communicate with an older backup unit like my Super Wild Card it cannot communicate with my MD-PRO, which requires EPP. Can this be solved?
Q54: My PCIe parallel port card has its ECP Extended Control register at a lower I/O address than its Data register. How do I specify a negative ECP Extended Control register offset in the configuration file?
Q55: Why is uCON64 unable to communicate with my Doctor V64 or Game Doctor SF6/SF7?
Q56: I installed a DAT file, but every time I run uCON64 it warns that the DAT file is meant for a console unknown to it. What is wrong?
Q57: I installed a Nintendo 64 DAT file from DAT-o-MATIC, after converting it to RomCenter 2.50 format, but uCON64 does not display DAT information for verified Nintento 64 ROMs. What is wrong?
Q58: I tried to upload a game to my Super UFO Pro 8 SD (on Windows), but uCON64 only produced an error message. What is wrong?

Q1: Why uCON64?
A: uCON64 is designed for people who want to play all the games on the original hardware. Here you got a powerful tool to backup, restore games and for many other operations. It is just a keep-old-hardware-alive tool :-)
uCON64 is also useful for people without backup units as it can be used to manage ROM collections (it can be used to identify, rename, patch or convert files) and it can operate as an intelligent frontend for every available emulator.

Q2: How do I get started using uCON64?
A: On the uCON64 homepage you can find a link to a download section. There are two types of packages, binary and source. You can tell a package is a binary package if it has "bin" (without the quotes) in its name. The source code packages have "src" in their name. Unless you are a software developer you probably do not need to download any of the source packages.
Choose a binary package for your system. GNU/Linux users should choose a package with "linux" in its name, BeOS users a package with "beos" in its name and DOS users a package with "dos" in its name. Windows users can choose any or all of the packages with "win32" or "dos" in their name. Normally, they should choose a package with "win32" in its name. The DOS version also runs on Windows, but has some limitations. For example, the DOS version cannot handle long command lines. The Cygwin version does not have any serious limitations compared to the "normal" Win32 versions, but behaves a bit more UNIX-like than Windows users might want. Users accustomed to UNIX might prefer the Cygwin version.
For installation instructions (for all versions) see question 4.

Q3: How do I compile/build uCON64?
A: Unless you are a software developer you probably do not need to compile it. Just download one of the pre-built binary distributions and proceed to question 4.
uCON64 can be compiled for UNIX (GNU/Linux, FreeBSD, OpenBSD, NetBSD, Solaris, Mac OS X), DOS, BeOS, Windows (95/98/ME/NT/2000/XP/2003/Vista/7/8/8.1/10) and AmigaOS (PPC/68K).
To compile uCON64 you need a compiler :-) You can use either GCC (GNU Compiler Collection) or the Visual C++ compiler. GCC can be downloaded from http://www.gnu.org/order/ftp.html. On GNU/Linux GCC is usually already installed.
Visual C++ is part of Visual Studio. A free version of Visual Studio, Visual Studio Community 2015, can be downloaded from https://www.visualstudio.com/products/visual-studio-community-vs. In order to compile uCON64, in the set up program of Visual Studio you need to select at least Programming Languages -> Visual C++ -> Common Tools for Visual C++ 2015. If you want to build a version of uCON64 that can run on versions of Windows as old as Windows XP, also check "Windows XP Support for C++" (Programming Languages -> Visual C++ -> Windows XP Support for C++). There are many versions of Visual Studio, but we only support building uCON64 with Visual Studio Community 2015 (with Update 1).
A DOS port of GCC (and other GNU development tools) named DJGPP is available from http://www.delorie.com/djgpp/. A Win32 port of GCC (and many other GNU tools and libraries) named Cygwin is available from http://www.cygwin.com. Another Win32 port of GCC (and other tools) named MinGW is available from http://www.mingw.org. We have tested the MinGW-built version of uCON64 more extensively than the other Windows versions. The MinGW-built version can run on versions of Windows as old as Windows 95.
Configuring uCON64
Some features of uCON64 are configurable (only) at compile time. They are:
- whether uCON64 will produce debug output (default: no)
- whether uCON64 will have support for parallel port backup units (default: yes)
- whether uCON64 will use the ppdev interface for parallel port I/O (default: no)
- whether uCON64 will be able to use color in its display output (default: yes)
- whether add-on libraries will be dynamically loaded or linked (default: loaded)
- whether uCON64 will be able to use the discmage library (default: yes)
- whether uCON64 will have support for the CD64 (default: no)
- whether uCON64 will be able to read .gz and .zip files (default: not if a Makefile "template" is used, see below)
- whether uCON64 will use libusb/have support for USB devices (default: no)
The presence or settings of these features is controlled by the header file config.h in combination with the makefiles. There are two ways to create a config.h and makefiles for uCON64:
(Before executing one of these steps read the sections below concerning gzip & zip and USB support)
1.) Run the configure script "configure".
If you want default settings type:
./configure
Otherwise you have to pass options to the configure script. To see which features can be controlled with the configure script, type:
./configure --help
2.) Copy a tried-and-tested config.h "template" to a file config.h and copy a Makefile "template" to a file Makefile.
The first way does not work in command.com or cmd.exe as these shells cannot (directly) execute Bash shell scripts. command.com is the default shell on Windows 9x, cmd.exe is the default shell on Windows NT/2000/XP/2003/Vista/7/8/8.1/10.
So, for DOS (DJGPP) copy config.h.orig to config.h and to libdiscmage/config.h, config.mak.orig to config.mak and libdiscmage/Makefile.orig to libdiscmage/Makefile. You can do the same for Cygwin, but in Cygwin you can get the same effect much easier by just running the configure script.
For Windows (Visual C++) copy config.h.vc6 to config.h and to libdiscmage/config.h. Do not copy any of the Makefile.vc6 files. You may do so, but do not complain if these instructions do not seem to be right after having done that.
To save us some work, for MinGW we only support configuring and building uCON64 from within MSYS (MinGW's POSIX build environment, a port of Bash).
Support for files in gzip (.gz) or zip format (.zip)
For gzip & zip support you need zlib. If you do not have zlib you can get it from http://zlib.net/. There are two ways to get gzip & zip support for uCON64:
1.) When using the configure script.
By default gzip & zip support will be enabled if configure can find zlib on your system. If you want to disable the feature, pass the option --without-zlib to the configure script.
2.) When using config.h and Makefile "templates".
By default gzip & zip support is disabled. If you want to enable it you have to define the constant USE_ZLIB in config.h and libdiscmage/config.h (remove the "//" in front of the line that defines it) and in config.mak and libdiscmage/Makefile (GCC) or Makefile.vc6 and libdiscmage/Makefile.vc6 (Visual C++) (remove the "#" in front of the line that defines it).
Support for USB devices
By default USB support will be disabled. For USB support you need libusb-0.1. If you do not have libusb you can get it from http://libusb.org/. For Windows you need libusb-win32. You can get it from http://libusb-win32.sourceforge.net/. There are two ways to get USB support for uCON64:
1.) When using the configure script.
If you want to enable the feature, pass the option --with-libusb to the configure script.
2.) When using config.h and Makefile "templates".
If you want to enable it you have to define the constant USE_USB in config.h (remove the "//" in front of the line that defines it) and in config.mak (GCC) or Makefile.vc6 (Visual C++) (remove the "#" in front of the line that defines it).
If you want to change other things in config.h or the makefiles do so before proceeding to the next step.
You have finished the configuration steps now. The following instructions will tell you how to compile uCON64 with the settings you just made.
Compiling uCON64
By default the library discmage will also be compiled. Discmage is used for several CD-related functions in uCON64, but is not required for non CD-related functions. For example, you will not need discmage for any of the SNES functions. Skip the next step if you do not want uCON64 to use discmage.
If you do not have a reason not to compile discmage and you are using DJGPP, Cygwin or MinGW you need the library libgcc.a. This library comes with those compilers but is usually not located in the standard library directory. However, the compiler needs to know where to find it. There are two possible ways to solve this problem:
1.) Copy the file libgcc.a to the standard library directory.
2.) Edit the file libdiscmage/Makefile so that the variable GCCA_DIR points to the directory containing libgcc.a.
The first option (copying the file) is preferred.
Now read the relevant section for the compiler you are using.
GCC (including DJGPP, Cygwin and MinGW)
If you have compiled uCON64 in the same directory before, first type:
make clean
If you want to compile the source code including discmage, type:
make
If you do not want to compile discmage the last command should look like this for DJGPP, Cygwin and MinGW:
make ucon64.exe
Otherwise it should look like this:
make ucon64
If you use Mac OS X and get an error message that dlfcn.h cannot be found, please install the library dlcompat and try again.
On UNIX systems other than GNU/Linux you might need to use "gmake" (GNU make) instead of "make". If the last make command has been successfully executed you can find the executable in the directory where you ran make. For DOS, Cygwin and MinGW you are now ready to proceed to question 4. For the other platforms one extra command is needed (or simply handy):
make install
On UNIX this command will ask for root's password, because uCON64 needs to be setuid root for parallel port access and because regular users usually do not have write access in the default installation directory, /usr/local/bin. If you configured uCON64 without support for parallel port backup units or if you configured it to use ppdev, uCON64 need not be setuid root. Just copy ucon64 to any directory you like.
On Mac OS X it is usual to install programs in /usr/bin. You can override the default destination directory /usr/local/bin by setting the environment variable DESTDIR. So, in order to install uCON64 in the directory /usr/bin use a command like:
DESTDIR=/usr/bin make install
This works also on other UNIX OSes.
"make install" also creates a configuration directory for uCON64 and copies discmage.so (UNIX and BeOS) or discmage.dylib (Mac OS X) to it, so you may find it easier to use it.
On BeOS this command will open a dialog window. Just follow the instructions.
Visual C++
Start a command shell or "prompt" and go to the correct directory. In order to be able to run the Visual Studio tools, first type:
"%VS140COMNTOOLS%"\vsvars32.bat
If you want to build a version of uCON64 that can run on versions of Windows as old as Windows XP, remove the "#" in front of the line with "WINXP_TARGETING=1" in Makefile.vc6, libdiscmage/Makefile.vc6 and backup/libcd64/Makefile.vc6. Be sure to have Windows SDK v7.1A installed or else enabling WINXP_TARGETING will have no effect. The easiest way to install Windows SDK v7.1A is to download the ISO image of Visual Studio 2012 Update 4, VS2012.4.iso from https://www.microsoft.com/en-us/download/details.aspx?id=39305. Open the ISO image with a program like WinRAR and extract the directory packages/XPSupport/. In the extracted directory you will find the file Win_XPSupport.msi. Install it by double-clicking on it.
If you have compiled uCON64 in the same directory before, type:
nmake /f Makefile.vc6 clean
If you want to compile the source code including discmage, type:
nmake /f Makefile.vc6
If you do not want to compile discmage the last command should look like this:
nmake /f Makefile.vc6 ucon64.exe
On GNU/Linux, DOS and Windows you could use UPX to compress the executable. UPX is available from http://upx.sourceforge.net.

Q4: How do I install uCON64?
A: It depends on what operating system you use. First read the information specific for your operating system. Then continue to the section "How to configure the uCON64 executable".
UNIX (GNU/Linux, FreeBSD, OpenBSD, NetBSD, Solaris, Mac OS X) & BeOS
Start a command line shell like Bash. Then extract the binary package. To extract or unpack a package in .tar.gz format use a command like this:
tar xvzf ucon64-1.9.8-1-linux-bin.tar.gz
Old versions of tar might not support the option z. In that case use a command like:
gunzip -c ucon64-1.9.8-1-linux-bin.tar.gz | tar xvf -
To unzip a .zip file use a command like this:
unzip ucon64-1.9.8-1-beos-bin.zip
You should replace the filename with the name of the file you downloaded for your operating system. Unpacking or extracting a package does not have to be done on the command line. You could also use a program with a GUI (Graphical User Interface) like KDE's ark or a similar program.
After you have extracted the package install uCON64 by running the install script. On UNIX, if you do not have root access, copy the uCON64 executable to a directory in your PATH. If you do have root access (i.e., know the root password), run the shell script install.sh. On BeOS just run the script install_beos.sh. For UNIX do something like this:
cd ucon64-1.9.8-1-linux-bin
./install.sh
By default install.sh will try to copy ucon64 to /usr/local/bin. You can specify another directory by setting the environment variable DESTDIR. On Mac OS X programs are usually installed in the directory /usr/bin. Users of that OS might want to install uCON64 with a command like:
DESTDIR=/usr/bin ./install.sh
For backup unit I/O BeOS users will need Caz's driver inside ioport.zip. You only need this driver if you will use uCON64 for communication with a backup unit. ioport.zip is included with the binary release. Continue on BeOS with:
cd ucon64-1.9.8-1-beos-bin
./install_beos.sh
After the last command a dialog window will come up. Simply follow the instructions.
Now continue to the section "How to configure the uCON64 executable".
32-bit Windows (95/98/ME/NT/2000/XP/2003/Vista/7) & DOS
On 32-bit Windows, unpack the package with a program like WinZip, WinRAR, Power Archiver or UltimateZip. On plain DOS (DOS without Windows) use a program like PKUNZIP.
We recommend to extract the package to a directory (or folder) of its own. The zip file contains a directory, but you need not use that directory.
Windows NT/2000/XP/2003/Vista/7 users need a driver for backup unit I/O. You do not need a driver if you use Windows 95, 98 or ME. A driver is also not needed if you will not use uCON64 to communicate with a backup unit.
You could use a driver like DlPortIO, io.dll or inpout32.dll. You can download DlPortIO from the uCON64 homepage. You can find io.dll in a file named io.zip at http://www.geekhideout.com/iodll.shtml and you can find inpout32.dll in a file named inpout32_source_and_bins.zip at http://www.logix4u.net. io.dll is included with the binary release. We recommend DlPortIO and io.dll. To install DlPortIO simply start port95nt.exe. After the installation is completed, copy DLPORTIO.dll from the Windows system(32) directory to uCON64's configuration directory. To install io.dll or inpout32.dll, put them in uCON64's configuration directory. See the section "How to configure the uCON64 executable" for more information about the configuration directory.
uCON64 displays a message if it finds DLPORTIO.dll, io.dll or inpout32.dll before communicating with a backup unit. It displays this message before it displays file information, so you might want to use the command line switch -q. Only the Windows versions of uCON64 are able to use DLPORTIO.dll, io.dll or inpout32.dll. If more than one I/O driver is present in the configuration directory, uCON64 will first try to load DLPORTIO.dll. If that fails it will try to load io.dll. If that also fails it will try to load inpout32.dll.
It is possible to use the DOS version of uCON64 as a transfer tool on Windows XP without an I/O driver. We have received reports from people who were able to send and receive ROMs on Windows XP as a regular user (no Administrator rights and not "Power Users").
64-bit Windows (XP/2003/Vista/7/8/8.1/10)
On 64-bit Windows, unpack the package with a program like WinZip, WinRAR, Power Archiver or UltimateZip. We recommend to extract the package to a directory (or folder) of its own. The zip file contains a directory, but you need not use that directory. Please note that we do not release a 64-bit version of uCON64. The 32-bit Windows versions of uCON64 run fine on 64-bit Windows.
64-bit Windows users need a driver for backup unit I/O. You do not need a driver if you will not use uCON64 to communicate with a backup unit.
You could use a driver like giveio64 or a suitable port of inpout32.dll. You can download giveio64 at https://www-user.tu-chemnitz.de/~heha/, directly at https://www-user.tu-chemnitz.de/~heha/hs/free.var, at http://www.codeproject.com/Tips/985807/Enable-I-O-Access-From-User-Mode or from the uCON64 homepage. You can find a suitable port of inpout32.dll in a file named InpOutBinaries_1500.zip at http://www.highrez.co.uk/Downloads/InpOut32/default.htm. giveio64 and inpout32.dll are included with the binary release. To install inpout32.dll, put it in uCON64's configuration directory. See the section "How to configure the uCON64 executable" for more information about the configuration directory.
If you choose to use the mentioned port of inpout32.dll, the first time you want to use uCON64 to communicate with a backup unit, you need to do so as Administrator (by running uCON64 from an instance of cmd.exe that was started as Administrator). After uCON64 was successful in communicating with a backup unit, you can use it as a normal user. Using inpout32.dll on 64-bit Windows is much less reliable than running uCON64 on GNU/Linux or 32-bit Windows. giveio64 is better in that regard, but you need to start it as Administrator at least once in every Windows session during which you want to use uCON64 to communicate with a backup unit.
uCON64 displays a message if it finds inpout32.dll before communicating with a backup unit. It displays this message before it displays file information, so you might want to use the command line switch -q. If more than one I/O driver is present in the configuration directory, uCON64 will first try to load DLPORTIO.dll. If that fails it will try to load io.dll. If that also fails it will try to load inpout32.dll. Since DLPORTIO.dll and io.dll do not work on 64-bit Windows, you have to manually delete them if they are present. A nice thing about the mentioned port of inpout32.dll is that it works on both 32-bit Windows (NT/2000/XP/2003/Vista/7) and 64-bit Windows (XP/2003/Vista/7/8/8.1/10).
The command line environment
uCON64 is a command line program and is usually started from a program like command.com (Windows 9x/ME) or cmd.exe (Windows NT/2000/XP/2003/Vista/7/8/8.1/10). You can start command.com or cmd.exe by choosing the option "Run..." from the start menu. You have to type the word command.com or cmd.exe yourself. command.com and cmd.exe are command line interpreters. That means that they will try to interpret any command you type followed by a press on the enter or return key. When you type a command, the command line interpreter will first look in the current directory and if it cannot find a program file with the correct name it will search the so-called "path". This means that the program file of uCON64 (ucon64.exe) must either be present in the current directory or in one of the directories of your path. It is really comfortable to have ucon64.exe present in your path, because you can simply use the name ucon64 from any directory without first having to copy ucon64.exe to that directory.
The path is defined by the environment variable PATH. You can check the current value of that variable with the command:
echo %PATH%
You could copy uCON64 to one of those directories. However, we recommend putting ucon64.exe in a directory of its own (on Windows). So, you should modify the value of PATH. On Windows 9x/ME you should do that in the following way. Edit the file C:\autoexec.bat and add a line like:
set PATH=%PATH%;C:\ucon64
Replace C:\ucon64 with the drive and directory where you extracted the uCON64 files to. Save the modified C:\autoexec.bat and reboot. On Windows XP (NT/2000?) you should press the buttons or icons start -> Control Panel -> System -> Advanced -> Environment Variables and edit the value of path in the section System variables or else in the section User variables. You have to start a new instance of cmd.exe before the changes take effect. After you have made your changes (and have rebooted your PC if you are using Windows 9x/ME or DOS) check the value of PATH again. It should now list the directory you just added.
For information on how to use the command line see question 49.
How to configure the uCON64 executable
First run uCON64 once. Use a command like:
ucon64 -version
If you have not run uCON64 before you should see a message that it created a file with a name like ucon64.cfg (DOS version) or .ucon64rc (all other versions). If you are using GNU/Linux and uCON64 crashes see question 46.
Then search for the line that starts with "configuration file". It should say "present" between the parentheses. The filename after the colon is the name of the configuration file. The configuration file may contain names of variables that influence the behaviour of uCON64. Here follows a table of the variable names uCON64 recognises:

`variable name` | `meaning`
--- | ---
`version` | `version of configuration file`
`backups` | `uCON64 will create backups of the files it modifies if it is 1`
`ansi_color` | `uCON64 will use color in its display output if it is 1`
`parport_dev` | `name of parallel port device (AmigaOS or GNU/Linux with ppdev)`
`parport` | `hardware address of parallel port (AmigaOS: port number)`
`ecr_offset` | `offset of ECP Extended Control register relative to Data register (parport)`
`gd6_send_byte_delay` | `Game Doctor SF6/SF7 specific: delay in microseconds to simulate synchronizing (based on reading bit 1 of the parallel port Control register) before sending a byte. Also signifies that all synchronization involving reads from the Control register should be simulated. Do not simulate, but read from the Control register if it is 0`
`n64_dat_v64` | `calculate CRC32 value of Nintendo 64 ROM in Doctor V64 format for DAT files if it is 1. Use Mr. Backup Z64 format if it is 0`
`discmage_path` | `path to discmage DLL`
`ucon64_configdir` | `name of configuration directory of uCON64`
`ucon64_datdir` | `name of DAT file directory of uCON64`
`emulate_<console>` | `command line to use to start emulator for <console>`
`emulate_<CRC32>` | `command line to use to start emulator for file with that CRC32 value`
`emulate_0x<CRC32>` | `command line to use to start emulator for file with that CRC32 value`
`f2afirmware` | `path to F2A USB firmware`
`iclientu` | `path to GBA client binary (for USB code)`
`iclientp` | `path to GBA client binary (for parallel port code)`
`ilogo` | `path to iLinker logo file`
`gbaloader` | `path to GBA multi-game loader`
`gbaloader_sc` | `path to GBA multi-game loader for Super Card`

Each of these variables can also be set in the command line environment. If they are they take precedence over the values set in the configuration file. For example, if you set the environment variable ansi_color to 0 while the configuration file sets it to 1 uCON64 will not use color. In command.com or cmd.exe you can set an environment variable with the command "set", in Bash you should do it with the command "export". For example:
export ansi_color=0
Some variables can be overruled with command line switches. For example, to disable the use of color even if both the configuration file and the environment have the variable ansi_color set to 1, use the switch -ncol:
ucon64 "Rock Fall (PD).zip" -ncol
The variable ucon64_configdir is only really important for the Windows versions of uCON64. To install the I/O port driver io.dll or inpout32.dll place it (or both) in the directory that uCON64 lists as its configuration directory.
If you use DOS or Windows 9x and do not want uCON64 to create ucon64.cfg or .ucon64rc files all over the place (current directories) see question 25.
You might also want to make use of DAT files. See question 36 for more information.

Q5: Sometimes my terminal seems to be locked after "ucon64 -xswc <file> | more"
A: You are right, it seems to be locked, but the only thing that happened is that the character echoing of the terminal is disabled by more. Just do not do that ;-)

Q6: How do I make uCON64 only display information about a ROM?
A: If you want to display information about a ROM just run uCON64 with the name of the ROM as the only argument. Sometimes you will have to specify the console type for uCON64, because the ROM dump is damaged or simply not detected correctly by uCON64. For example:
ucon64 -snes "Super Aleste (J) [t1].swc"

Q7: I have two parallel ports in my PC and my Flash Advance Linker is connected to the second. However, when I try to use uCON64 to send a demo to the FAL something goes wrong. What happened?
A: Well, many things could have gone wrong, but uCON64 only detects your first parallel port (it stops probing for a parallel port if it finds one). So, you should specify the address of the second parallel port on the command line. For example:
ucon64 -xfal demo.gba -port 0x278
The I/O address of the parallel port could be 0x3bc, 0x378 or 0x278. If you do not want to type the address of the parallel port every time you want to transfer something to your FAL (or another backup unit) edit .ucon64rc or ucon64.cfg (for the DOS version) and remove the hash symbol in front of the line that starts with "parport=" (without the quotes). If that line is not present add one. You do not have to use the prefix 0x. For example:
parport=278
You can also set an environment variable with the name parport to the right value. The value of the environment variable takes precedence over the value in the configuration file.

Q8: I tried to dump a SNES cartridge using a Super Wild Card connected to my PC with an interlink cable, but it did not work. What is wrong?
A: You should not use an interlink cable, but a standard bidirectional parallel cable, i.e., a cable with male DB-25 connectors at both ends where the pins are connected in such a way that pin 1 on one end is connected to pin 1 on the other, pin 2 on one end to pin 2 on the other and so forth, for all 25 pins. Pins 2-9 are used for output, pins 10, 12, 13 & 15 for input, pins 1, 11, 14, 16 & 17 for protocol and pins 18-25 are ground.

Q9: I have a SNES ROM of which GoodSNES says it is good, but uCON64 says it is bad. Who is right?
A: It depends.
If uCON64 displays the text "Checksum: Bad" GoodSNES might be right.
There may be several reasons why uCON64 reports that the checksum is bad. It could have made a mistake while determining if the ROM is a HiROM or a LoROM dump. Try the switches -hi and -nhi and see if uCON64 reports the checksum differently. Sometimes ROM dumps are detected as not being interleaved while they actually are. Try the switches -int and -int2 and see if you get better results. It could also be that uCON64 detects the ROM as interleaved while it is not. The switch -nint might help in that case. If the checksum is reported as good it is likely that the ROM is really good. Alternatively, you may want to convert the ROM to a non-interleaved format with -dint and run uCON64 on the converted ROM. Luckily you will not find many interleaved ROM dumps that uCON64 cannot handle, probably because Snes9x and ZSNES often cannot handle them either.
Perhaps "OK" looks nicer than "Bad", but it is far more important that uCON64 displays DAT file information. If you installed a SNES DAT file (see question 36) and uCON64 does not display a line with the text "DAT info:" then the ROM dump could not be identified. It could be that you have an unknown ROM dump, but it is more likely that you have a modified, i.e. bad, dump or an overdump. GoodSNES 0.999.5 does not use the CRC32 algorithm to identify files, so if uCON64 does not display DAT information, but GoodSNES identified it as good then uCON64 is right. For reasons see question 42.

Q10: I have a SNES ROM of which Snes9x and ZSNES say it is bad, but uCON64 says it is good ("Checksum: OK"). Who is right?
A: uCON64, probably :-)
Neither Snes9x 1.39 nor ZSNES 1.36 calculate the checksum correctly for BS ROMs, so you can be pretty sure the ROM is good if it is a BS ROM. See previous answer.

Q11: I have a SNES ROM of which uCON64 said it was bad, so I used the -chk option. Now uCON64, Snes9x and ZSNES all say the ROM is good, but GoodSNES still says it is bad. How can that be, I did fix the ROM, right?
A: No, you did not. When you use -chk uCON64 changes four bytes in the ROM dump, so that they match with the calculated checksum. However, the ROM stays just as bad as it was.
Use -chk with care. -chk might be useful if you want to store a ROM somewhere without using a database with its checksum. You can then later check if the ROM is still the same as it was when you stored it by using the checksum that is stored in the ROM.
That said, it is a much better idea to create a DAT file from your ROM collection if you plan to store it somewhere. See question 42 for reasons and question 43 for information on how to create a DAT file.

Q12: Some SNES games do not work on my Super Wild Card. What can I do about that?
A: You can do several things. First make sure the original game cartridge does not contain any special chips that your Super Wild Card does not support (look at the ROM type information). For example, if you are trying to run a game like Super Mario Kart (which uses a DSP chip) your Super Wild Card should have an extension with the correct DSP chip (or have the right cartridge with that chip plugged in your SWC). Then make sure you are using a good dump (look at the checksum information). After you have done that, check if the file is interleaved (look at the line that starts with "Interleaved/Swapped:"). If the file is interleaved convert it to Super Wild Card format (deinterleaved) by using the option -swc. Also verify that the backup unit header is correct. The option -dbuh can be helpful with that. You can make uCON64 rewrite the header also with -swc. uCON64 uses the information in the ROM dump's header when sending the file to the Super Wild Card, so this is important! You can also try to rewrite the header while using one of the switches -hi or -nhi to force uCON64 to handle it as a HiROM or a LoROM dump. Additionally you could use one of the switches -hd, -nhd or -hdn to specify the backup unit header size. For example:
ucon64 -swc -nhi -hd "Batman Revenge of the Joker (U).swc"
There are many (good) ROMs on the internet with incorrect headers, so this might well solve the problem.
Several games contain a copy protection that prevents them from running on a backup unit, so this can also be a reason why the game does not work. You can try -k to remove that protection. Several games also check if they are running on a PAL or an NTSC SNES. Use -f to remove that form of copy protection. Some other games check the ROM speed. You can use -l for those. Some games have more than one type of copy protection, so it could be necessary to use uCON64 several times with a different option.
See question 39 and question 40 for more information about a new feature in uCON64 1.9.8beta8 that can be used to update or improve the options -k, -f and -l without having to (re)compile the source code.
Some games seem to work, but after a while it becomes clear that they do not run as was intended. Two examples of such games are Demon's Crest and Mega Man X. Here follows an explanation on how to get them to work. All credits go to Gideon Zhi for sharing this info on cherryroms. Start with ROM images in SWC format.
Demon's Crest:
ucon64 -stp "Demon's Crest.swc"
cat "Demon's Crest.swc" "Demon's Crest.swc" > "Demon's Crest (SWC-fix).swc"
ucon64 -swc "Demon's Crest (SWC-fix).swc"
Mega Man X:
ucon64 -stp "Mega Man X.swc"
ucon64 -padn=2097152 "Mega Man X.swc"
cat "Mega Man X.swc" "Mega Man X.swc" > "Mega Man X (SWC-fix).swc"
ucon64 -swc "Mega Man X (SWC-fix).swc"
WinDOS users without the program cat should use the command copy. For example:
copy /b "Mega Man X.swc" + "Mega Man X.swc" "Mega Man X (SWC-fix).swc"
However, starting with version 1.9.8beta6 the method described above is not necessary anymore for Demon's Crest. Use the option -k instead. For Mega Man X you will need version 1.9.8beta7 or later.
Finally, you could have a look at an incomplete Super Wild Card compatibility list on the uCON64 homepage (it can also be found in the source package) to see if it is possible to run a certain game on a Super Wild Card 2.8cc 32 Mbit PAL.

Q13: Which backup devices are supported by uCON64?
A: See hardware.html.

Q14: I use Windows XP (NT/2000). When I try to run ucon64.exe in command.com (start -> Run... -> command) uCON64 crashes. What do I do wrong?
A: You should not use command, use cmd instead. However, starting with version 1.9.8 uCON64 should run fine in command.com.

Q15: I do not like the command line. Are there graphical frontends available?
A: Yes, have a look at http://ucon64.sourceforge.net/index2.html#ucon64gui

Q16: Where do I get PPF, APS or IPS patches?
A:

Q17: Where do I get ROMs/Games?
A: www.ebay.com

Q18: What does "[ROM|IMAGE|SRAM|FILE|DIR|ARCHIVE]..." mean in the help?
A: The pipe symbol ('|') should be read as "or".
The square brackets indicate that "ROM|IMAGE|SRAM|FILE|DIR|ARCHIVE" is optional. For many options you have to specify either a ROM or a CD image or an SRAM file or some other file or a directory or an archive. However, there are a few options that do not need any of those arguments.
The ellipses indicate that you may specify one or more ROMs, CD images etc. Several options even support combinations of ROMs, directories and archives.
For the current version of uCON64, archive should be read as "ZIP file".

Q19: Why is my backup unit (still) not supported?
A: Get us the protocol or the sources of existing transfer tools and you will see what happens. uCON64 already supports all important backup units which were and are available. Manufacturers of devices which are still not supported are welcome to contact us.

Q20: How do I specify a bank number for the GB Xchanger?
A: Separate the bank number from the option -xgbxb with either a space or an equal sign. For example:
ucon64 -xgbxb 0 "Pokemon (Green).sav"
or:
ucon64 -xgbxb=0 "Pokemon (Green).sav"

Q21: What is the difference between the Flash Advance Linker options -xfals and -xfalb <n>?
A: When saving -xfals saves all 256 kB while -xfalb <n> saves only the 64 kB of bank n. When restoring -xfals starts restoring the SRAM in bank 1 while -xfalb <n> starts in bank n. For example, if you have Super Mario Advance 2 (J) on your flash card in "ROM bank" 4 and would like to save/restore SRAM bank 4 you should do something like:
ucon64 -xfalb 4 "Super Mario Advance 2 (J).sav"
The file size determines how many bytes are restored, even when you use -xfalb <n>. So, if the file is greater than 64 kB more than one bank will be written to.

Q22: uCON64 exits with the message "ERROR: Flash card erase failed" when I try to write a multi-game file to my Flash Advance Linker flash card. What is wrong?
A: The multi-game file you created is too large for your flash card. When you make a multi-game file do not forget that the loader or "game pack" file also needs some space (32 kB) on the flash card. Do not pass a size to -multi that is larger than your flash card. Passing a smaller size is correct though. For example, to create a multi-game file that fits on a 128 Mb (16 MB) card use a command like this:
ucon64 -gba -multi=128 loader.bin rom1.gba rom2.gba rom3.gba rom4.gba multi.bin
You can also send it directly by using -xfalmulti:
ucon64 -xfalmulti=128 rom1.gba rom2.gba rom3.gba rom4.gba
Please note that when using -multi you have to specify a loader and the name of the multi-game file to create, while when using -xfalmulti you must omit them. -xfalmulti uses the variable gbaloader to find the loader. See "How to configure the uCON64 executable".
Just like sometimes happens with Visoly's tool it is possible to get the same message when the multi-game file is small enough. It will probably work when you try again (with the same multi-game file).

Q23: Where can I get that Flash Advance Linker loader or "game pack" file?
A: It is in a file named preboot32.zip and you can find it on the uCON64 homepage.

Q24: What is the meaning of the -col option (SNES)?
A: Back in the days stupid people released games with green blood. You can use a GFX or HTML editor to find an identical green color and write down the color values in HTML style (#RRGGBB). Now you run "ucon64 -col #RRGGBB" and it will calculate the hex value for the corresponding SNES color. OK? No? Then you do not need this option :-)

Q25: Why does uCON64 create ucon64.cfg (DOS executable) or .ucon64rc (Win32 executable) files all over the place on DOS and Windows 9x (command.com)?
A: uCON64 needs to know where it can find the configuration file or a directory where it can create one. It checks the environment for a variable with the name UCON64_HOME, HOME, USERPROFILE or HOMEDRIVE and HOMEPATH (in that order). On UNIX HOME is normally set. On Windows XP and 2000 (NT?) USERPROFILE, HOMEDRIVE and HOMEPATH are usually set. If uCON64 cannot find one of those environment variables it will look for the configuration file in the current directory. If it cannot find a configuration file it will create one. On DOS and Windows 9x none of those environment variables are usually set. So, if you run uCON64 on DOS or Windows 9x in a directory where no configuration file exists it will create one there. If you do not like this behaviour you should set one of the mentioned environment variables yourself. You can do that by adding the following line to the end of the file C:\autoexec.bat:
set UCON64_HOME=C:\ucon64
and reboot. You can also type that line on the command line. The directory C:\ucon64 must exist, of course. If you want uCON64 to use another directory you should change C:\ucon64 to a directory of your choice. You should not let the last character of the environment variable be a forward or backward slash.
If you have Cygwin installed, the Cygwin runtime system will create an internal environment for the uCON64 executable with HOME set to Cygwin's home directory if it has not already been set. You can override this value with the method mentioned earlier. However, if you set UCON64_HOME this does not matter as the value of HOME will not be checked if UCON64_HOME is set.
You can check which configuration file uCON64 uses by specifying the option -version on the command line.

Q26: When I try to create a multi-game file on Windows I get the message "The system cannot execute the specified program." (or something similar). What does that mean?
A: You can get that message with the DOS executable if you pass more than 127 characters as argument to uCON64. There are two solutions:
1.) Use a Win32 executable (download one from the uCON64 homepage).
2.) Rename the ROMs so that their combined names are short enough to fit into 127 characters.

Q27: I tried to run a Win32 executable of uCON64 but Windows gave an error message that cygwin1.dll, cygz.dll or zlib.dll could not be found.
A: The Cygwin-compiled Win32 executable of uCON64 needs cygwin1.dll and cygz.dll in order to run. The Visual C++-compiled Win32 executable needs zlib.dll. You can download these files from the uCON64 homepage. Copy the file(s) to the same directory as the uCON64 executable or to a directory in your PATH.
Starting with version 2.0.1 all files necessary to run uCON64 are included with the binary packages.

Q28: How do I make uCON64 display one help screen at a time?
A: Pass the output of uCON64 to a program that waits for a key after one screen of text. You could use the program "more" or "less". In order to pass the output of uCON64 to more you have to use the pipe symbol, '|'. On an international keyboard you can type this symbol with the same key you use for the backslash ('\'). For example:
ucon64 -help|more
To get only help on the options for a specific console, specify the console on the command line. For example, to see only the help on Game Boy Advance options:
ucon64 -help -gba|more
Press the space bar to see the next help screen, the enter key to see the next line or q to quit.

Q29: I tried to send a ROM dump to my backup unit on Windows XP (NT/2000), but uCON64 crashed. What is wrong?
A: If the message looks like this (for the Win32 (Cygwin) executable):
0 [main] ucon64 356 handle_exceptions: Exception: STATUS_PRIVILEGED_INSTRUCTION
5570 [main] ucon64 356 open_stackdumpfile: Dumping stack trace to ucon64.exe.stackdump
or like this:
Illegal instruction (core dumped)
then you did not install an I/O driver (correctly). In this case "install" means that the I/O driver is running at the time uCON64 tries to access the parallel port. See question 4.
You will also see this message (with a Windows version of uCON64) if you tried to enable EPP mode for the FAL on Windows XP (NT/2000), i.e., you specified the switch -xfalm, without an appropriate I/O port driver. UserPort is inappropriate for this, because it enables access to I/O ports up to 0x3ff. However, in order to enable EPP mode the FAL code tries to access an I/O port with an address higher than 0x3ff. If you want to be able to use EPP mode try io.dll or inpout32.dll.
Starting with version 2.0.0 uCON64 will not crash anymore if it cannot access the parallel port at start up (unless you use UserPort in combination with a Windows version of uCON64).
Starting with version 2.1.0 uCON64 will by default try to use EPP for options that can use it. So, UserPort can no longer be used (uCON64 will display an error message and exit cleanly when using UserPort). Also, the meaning of the switches -xfalm, -xgbxm and -xplm has been reversed.

Q30: I want to convert a NES ROM in iNES format to UNIF. How do I know what board name to use?
A: The file boardtable.txt contains a table where you can find what game uses what board. The file boardnames contains a list of all known board names.

Q31: How do I convert a NES ROM from Pasofami to FFE? Or from UNIF to Pasofami?
A: Use iNES as intermediate format. So, to do the conversion Pasofami -> FFE, do this conversion instead: first Pasofami -> iNES and then iNES -> FFE.
To answer the second question, to do the conversion UNIF -> Pasofami do this: UNIF -> iNES and then iNES -> Pasofami.

Q32: How do I specify dumper information when converting to UNIF?
A: Create a text file with three lines. The first line should contain the name (or "handle") of the person who dumped the cartridge. This line may be 99 characters long at maximum. The next line should contain the date when the cartridge was dumped. The format is dd-mm-yyyy. Instead of the hyphen ('-') you may also use the slash ('/'). If day or month is smaller than 10 you may use 1 or 2 digits, for example:
02/02/2002
or
2-2-2002
The third and last line should contain information about the dumping means that was used. This line may also contain 99 characters at maximum. Here is an example info file:
Me <me@web.net>
26-7-2002
Custom built hardware
To get this information in a UNIF file, you should use the -dumpinfo switch in combination with the -unif option. Say you store the dumper information in the file info.txt. This would get the info in a UNIF file:
ucon64 -unif smb.nes -mapr NROM -dumpinfo info.txt
If you already have a UNIF file the command looks almost the same:
ucon64 -unif smb.unf -dumpinfo info.txt
For an existing UNIF file you need not specify the board name, but you might want to specify it if you want to change the board name in the file. Afterwards run uCON64 on the newly written ROM to see if you were successful. uCON64's display output should contain a dump info section then.

Q33: How do I specify that a NES game in UNIF format supports multiple controller types?
A: Use the -ctrl switch multiple times on the same command line. For example, to specify that a game supports the controller types "regular joypad" and "power pad" you should use a command like this:
ucon64 -unif smb.nes -mapr NROM -ctrl 0 -ctrl 4

Q34: How do I enable or disable colors in the display output of uCON64?
A: For the Windows and UNIX executables colors are enabled by default. For the DOS executable ANSI.SYS must be loaded. On DOS and Windows 9x ANSI.SYS can be loaded by adding a line to the end of C:\config.sys of the format "device=<full path to ANSI.SYS>". Say ANSI.SYS is located in the directory C:\windows\command, then the line would have to look like this:
device=C:\windows\command\ansi.sys
Changes made to config.sys on DOS and Windows 9x will become active only after a reboot.
On Windows XP/NT you should add a similar line to your %SystemRoot%\system32\CONFIG.NT:
device=%SystemRoot%\system32\ansi.sys
The use of color can be disabled by specifying the switch -ncol on the command line. You can also add the following line to the configuration file:
ansi_color=0

Q35: When I try to convert a large number of files using wildcards, uCON64 will only convert the first file. Is this a bug?
A: No, it is not. uCON64 versions before 1.9.8beta7 just do not support wildcards. For example, to convert all files with the suffix (M$ speak: extension) .mgd to Super Wild Card format, try this in Bash:
find -name \*.mgd -exec ucon64 --snes --swc {} \;
or this in command.com or cmd.exe:
for %f in (*.mgd) do ucon64 --snes --swc "%f"
However, this functionality has been added to uCON64 1.9.8beta7. With that version you can do the same thing with:
ucon64 --snes --swc *.mgd
In case something goes terribly wrong and uCON64 crashes it might still be necessary to use one of the previous methods, because every file will be processed and not only the files before the crash.

Q36: Does uCON64 support DAT (RomCenter/GoodXXXX) files?
A: Yes, starting with version 1.9.8beta8 it does. First use the option -version to see which configuration file uCON64 uses (see question 25). Then open that file in an editor and look for a line that starts with "ucon64_datdir=" (without the quotes). If that line is not present add one. For example on UNIX:
ucon64_datdir=~/.ucon64/dat
or on Windows:
ucon64_datdir=C:\ucon64\dat
You can use the tilde ('~') also on DOS and Windows. It will be interpreted by uCON64 as the "home directory". The home directory is the directory specified by the environment variable HOME or USERPROFILE or HOMEDRIVE and HOMEPATH. If none of those environment variables are set, the current directory will be handled as the home directory. Again, see question 25.
You can also set an environment variable with the name ucon64_datdir. The value of the environment variable takes precedence over the value in the configuration file.
Then copy all DAT files you have into that directory. You can download DAT files from sites like http://emulationrealm.net/, http://www.romcenter.com/ or http://www.rommanager.com/. You can also find some DAT files on the uCON64 homepage. A more up-to-date resource is the nice DAT-o-MATIC at http://datomatic.no-intro.org/, but you have to convert the DAT files before uCON64 can use them. See question 56.
uCON64 will automatically create index files which speed up access to the DAT files dramatically. Now uCON64 uses the information inside the DAT files to identify or rename ROMs without an internal header.
Starting with version 1.9.8beta8 uCON64 does not have an internal database anymore, so you will need DAT files for files like NES ROM dumps.
You can check which DAT files are used by uCON64 with the option -db. You can view or list all DAT entries with the option -dbv. You can search for a specific CRC32 value with the option -dbs. The force-console-type options can be used in combination with -db, -dbv and -dbs. For example, to see which DAT files are used to identify SNES ROM dumps, type:
ucon64 -db -snes
If uCON64 reports that it found 0 DAT files you did not install the DAT file(s) correctly.

Q37: Some SNES games do not work on my Super Pro Fighter Q(+). What can I do about that?
A: First read the answer to question 12. Starting with versions after 1.9.8beta8 you can send (and dump) games with the option -xfig. It could be that some games need to be in Super Wild Card format in order for them to work correctly what SRAM concerns if you load them from diskette. So, instead of converting them with -fig you have to use the option -swc. For example Earthbound and "Lufia & The Fortress of Doom" have all sorts of problems when they are in FIG format, but not when they are in SWC format. Other games work best when you convert them with -fig. For example Seiken Densetsu 3 will run best when converted with -fig.
There seems to be a bit of an overheating problem with some Super Pro Fighter Q(+) models. After playing half an hour or so, this may result in reboots or other strange behaviour. We have received a report of one user who solved this by removing the case of the Super Pro Fighter Q(+) and placing a CPU fan on top of the SPFQ's RAM chips.

Q38: uCON64 displays too many lines for my DOS-box. What can I do about that?
A: You can do several things:
1.) Change the number of lines that can be displayed at once with this command:
mode con lines=50
2.) Use the program "more". See question 28.
3.) Redirect the output of uCON64 to a file. For example:
ucon64 rom.swc > output.txt
You can then open the file output.txt in an editor.

Q39: When will the next version of uCON64 be released? I have heard the next version is able to crack my favourite SNES game, but I do not know how to use Subversion or a compiler.
A: We know when we will release a new version only just before we do so. But starting with uCON64 1.9.8beta8 this is not a problem for you at all. The only requirement is that you are able to read and use a text editor ;-)
First visit the uCON64 homepage and from there follow a link to the uCON64 SourceForge page. You should be able to find a page where you can browse the SVN repository. Download the latest version of the file snes.c. Open the file in an editor and search for the text snes_k. If you are looking for NTSC or PAL fixes search either for snes_fix_pal_protection or snes_fix_ntsc_protection, depending on what you need. For example, you will have to search for snes_fix_pal_protection, if you want to fix a game so that it will run on an NTSC SNES.
Then read the comment to see what "code" your game requires. However, surely not every game will be mentioned in the comments. In that case search for the corresponding "line" a bit below. For example, for Mega Man X you will find this text in the comments:
af/bf XX 80 00 cf/df XX 80 40 f0
=> af/bf XX 80 00 cf/df XX 80 40 80
Then you could search for the sequence \x80\x40\xf0. It is just a subset of the search pattern with each element prefixed with "\x". Searching for \xaf/\xbf will not bring you far. Searching for \xXX\x80 neither. It takes a bit too much text to explain all the details, so just follow the directions. Note that I did not advise to search for \x80\x40\x80, because that is what the sequence should be after uCON64 has cracked or fixed the game.
For Mega Man X you will find the lines:
n += change_mem (buffer, bytesread, "!*\x80\x00!*\x80\x40\xf0", 9, '*', '!', "\x80", 1, 0,
"\xaf\xbf", 2, "\xcf\xdf", 2);
Now open the file snescopy.txt. If you are trying to get uCON64 support new NTSC or PAL cracks open snesntsc.txt or snespal.txt respectively. Then copy the parts "!*\x80\x00!*\x80\x40\xf0", '*', '!', "\x80", 0, "\xaf\xbf" and "\xcf\xdf" to a new line in that file. Note that 0 is the 9th parameter. Also note that "\xaf\xbf" and "\xcf\xdf" are all parameters between double quotes after the 9th parameter.
Remove the double and single quotes and separate the parts by a colon. Then replace the prefix \x with a space. If you followed the directions the line will look like this:
!* 80 00!* 80 40 f0: *: !: 80: 0: af bf: cf df
You are almost done now. Only one thing has to be done. Look at what the "wildcard" and "escape" symbols are. They are defined by the 5th and 6th parameter of change_mem(), respectively. In our example the 5th parameter is '*', so the wildcard character is: *. The 6th parameter is '!', so the escape character is: !. And now the last step: replace the wildcard and escape characters with a (hexadecimal) number that does not occur in the rest of the character sequence (except other wildcards and escape symbols or values). Be sure to have at least one space between the numbers. In our example we could choose the values 1 and 2. In that case the finished line would look like this:
2 1 80 00 2 1 80 40 f0: 1: 2: 80: 0: af bf: cf df
If for example the 5th parameter would have been \x01, the wildcard would be 01. In that case you would not have to change it, because it is already a number.
Now save the changed file and place it either in the directory from where you will run uCON64 (this is not necessarily the same directory as the one where the uCON64 executable might be located!) or in uCON64's configuration directory. Use the option -version to find out which directory that is. Then try if uCON64 is able to crack your game. uCON64 will display a warning message if it detects an error in your new line. If you made a mistake with escape symbols uCON64 might very well crash. You can use the switch -v (in combination with -k, -f or -l) to make uCON64 display what information it reads from the file.
If you cannot find which line you need you will either have to add a line to snescopy.txt, snespal.txt or snesntsc.txt for every code that is not already mentioned in those files or ask someone else to do it for you. For example on an emulation web forum like the cherryroms copier and hardware forum.

Q40: What is the format of the snes*.txt files?
A: Zero or more lines of the following format:
<search> : <wc> : <esc> : <new> : <off> [: <set>]*
Where search is the search pattern, wc the wildcard value, esc the escape value, new the replacement byte sequence, off the offset and set a set of bytes for each escape value in the search pattern. uCON64 does not accept this information to be specified across several lines. All values should be specified in hexadecimal, except the offset.
If the search pattern does not contain any escape bytes, you need not specify a set as it will not be used. If it does contain escape bytes you will have to specify a set for each one of them. Take for example the pattern:
01 00 01 00 42 84 ff 75 : ff : 00 : 02 03 : -6 : 22 11 : 19 75
This will match amongst 1020 others with the following byte sequences:
01 22 01 19 42 84 19 75
01 11 01 19 42 84 91 75
01 22 01 75 42 84 00 75
01 11 01 75 42 84 ff 75
A wildcard value in the search pattern matches with any value.
Using the above search pattern, uCON64 will search and replace two bytes six bytes "back" from the end of any matched byte sequence. For example, any occurence of the byte sequence 01 22 01 19 42 84 19 75 will be changed into 01 02 03 19 42 84 19 75.

Q41: Is it possible to force uCON64 to send or dump (an) SRAM (file) instead of that it depends on whether the file exists?
A: No, but you could use a simple script or batch file to force sending or dumping. Here is an example batch file to force dumping SRAM with a Pro Fighter:
@echo off
if exist %1 goto error
ucon64 -xfigs %1
goto exit
:error
echo %1 already exists, use a different name
:exit
Save that text to a file that ends with ".bat" (without the quotes). Say you save it to a file named dumpsram.bat. Then you can dump the SRAM of the Pro Fighter with a command like:
dumpsram save1.sav
You do not have to check if save1.sav exists anymore as the batch file will do it for you.
Here is the Bash script equivalent of the above batch file:
#! /bin/bash
if [ -e "$1" ]; then
echo $1 already exists, use a different name
exit
fi
ucon64 -xfigs "$1"
You do not have to give the file a specific name. Just do not forget to make the file executable. Say you name it dumpsram, then you could make it executable with:
chmod +x dumpsram
Now you can dump the SRAM with:
./dumpsram save1.sav

Q42: Why does uCON64 support DAT files?
A: uCON64 supports DAT files for two reasons:
1.) In order to reliably identify ROM dumps.
2.) In order to rename ROM dumps to their "official" name.
Some ROM dump formats contain enough information to identify them, but none of the formats supported by uCON64 can be reliably identified.
The checksum algorithms that are used to calculate the internal checksum of the files that have one is a simple addition of a range of bytes. So, several bytes can be swapped and still yield the same checksum. Even the range can be different and produce the same checksum. The latter case often occurs with overdumps. Some ROM dump formats do not even use the entire file for the checksum calculation...
uCON64 solves these problems as it uses the CRC32 algorithm for file identification. The CRC32 algorithm will produce a different checksum if bytes are swapped or if the range is different. When uCON64 is run on a ROM dump it first calculates the CRC32 value of that file and then searches in its DAT files for that CRC32 value. If it is present uCON64 will display the information it found in the DAT file. If uCON64 could not find the CRC32 value it will not display DAT information.
At the risk of stating the obvious I might add that even if all formats used a checksum algorithm like CRC32, DAT files would still be necessary as it is not possible to reliably identify a file without an external reference.

Q43: How should the option --mkdat be used?
A: With care ;-)
Seriously, let me first state that it would not be helpful if people would start creating DAT files from their ROM collections and publish them without some form of coordination. At the time of this writing (2 June 2003) Cowering's GoodXXXX utilities are the standard for most consoles.
In order to create a DAT file first make sure that all the ROMs you want to create a DAT file from, have the name you want them to have. This is important as DAT files are used not only for identification, but also for renaming files (when using the option --rename). Also make sure all the files have a suffix (or "extension"). Then start uCON64 with the --mkdat option. For example, to create a DAT file from all the SNES ROM dumps in the directory C:\snesrom use a command like:
ucon64 --mkdat=snes-02062003.dat C:\snesrom
In this case a DAT file named snes-02062003.dat will be created. When you copy this file to uCON64's DAT directory uCON64 will use it to identify SNES ROMs. Note that the name ends with ".dat". uCON64 will only see DAT files if they have a name that ends with ".dat". Note also that the name starts with "snes". uCON64 will use all DAT files (in its DAT directory) that start with "snes" to identify SNES ROM dumps. The letter case is not important, so you could also use a name that starts with "SNES" or "Snes". If you use an incorrect name uCON64 will not use the DAT file, but will print a warning message each time you run uCON64 on a ROM dump. Here follows a table to see which name uCON64 uses for what console:

`console` | `DAT filename prefix`
--- | ---
`"Atari hardware"` | `Good2600, Good5200, Good7800, 2600, 5200 or 7800`
`Coleco` | `GoodCOL or Coleco`
`Game Boy Advance` | `GoodGBA or GBA`
`Game Boy (Color)` | `GoodGBX or GBX`
`Genesis or Mega Drive` | `GoodGEN or GEN`
`Intellivision` | `GoodINTV or Intelli`
`Jaguar` | `GoodJAG or JAG`
`Lynx` | `GoodLynx or Lynx`
`"M.A.M.E. hardware"` | `MAME`
`Neo Geo` | `Neo-Geo`
`Neo Geo Pocket` | `GoodNGPX or NGP`
`NES` | `GoodNES, NES or FDS`
`Nintendo 64` | `GoodN64 or N64`
`PC-Engine` | `GoodPCE or PCE`
`Sega Master System and Game Gear` | `GoodSMS, GoodGG, SMS or GG`
`SNES` | `GoodSNES or SNES`
`Vectrex` | `GoodVECT or Vectrex`
`Virtual Boy` | `GoodVBOY or VBOY`
`WonderSwan` | `GoodWSX or swan`

You can create a DAT file from a subset of the files in a directory by explicitly specifying the files on the command line:
ucon64 --mkdat=snes-02062003.dat C:\snesrom\*.swc
uCON64 uses the first file to determine for which console a DAT file is meant. So, if you want to create a DAT file from a set of ROMs of several consoles, the first file uCON64 encounters will determine the DAT file type. You can do two things in such a case to be sure for which console the resulting DAT file will be meant:
1.) Specify one extra ROM dump as first file on the command line. For example:
ucon64 --mkdat=n64-02062003.dat C:\rom\mario64.v64 C:\rom
2.) Use a force recognition switch. For example:
ucon64 --mkdat=sms-02062003.dat C:\rom --sms
The second option should only be used when you are sure all the files are for a certain console and uCON64 fails to recognise some.
You can control what information uCON64 displays when creating a DAT file with the switches -v and -q. --mkdat uses three levels of verbosity:
1.) When the switch -v is specified uCON64 will display a warning if it could not determine the console type for a file. uCON64 will also display a warning if it encounters a file that has the same CRC32 value as a file uCON64 already processed (a "duplicate").
2.) When neither -v nor -q is specified uCON64 will display a warning only if it finds a duplicate or if the console type of the first file could not be determined.
3.) When -q is specified uCON64 will display a warning only if the console type of the first file could not be determined.
If you had to specify a first file you could suppress the warning about a duplicate by using the switch -q. For example:
ucon64 --mkdat=n64-02062003.dat C:\rom\mario64.v64 C:\rom -q

Q44: What tools do you recommend besides uCON64?
A: For SNES, only NSRT (Nach's SNES ROM Tools). That is, starting with version 3.0 Release Candidate 1. NSRT has some features that uCON64 does not have. The two most interesting features are arguably that it is able to fix some hacked ROM dumps and that it has an internal database on which a lot of effort has been spent to have it contain only correct entries (as opposed to GoodSNES and the GoodSNES DAT files). What the second feature is concerned let us remind you that the quality of uCON64's ROM database support stands or falls with the quality of the DAT files. So, if you would create a DAT file of a ROM dump collection processed with NSRT uCON64 would get a SNES database that is similar to the one in NSRT. See question 43. Another advantage NSRT has over uCON64 (as seen from a SNES user's viewpoint) is that it is written only for SNES. NSRT also handles some strange formats that uCON64 does not handle.

Q45: What is an interleaved ROM?
A: Strictly speaking, interleaved ROMs do not exist. Interleaved ROM dumps do. Or perhaps it is better to say ROM dumps in interleaved format. The meaning of "interleaved" depends on the console type. Interleaved formats exist for NES, PC-Engine, Genesis, SNES and Nintendo 64.
Deinterleaving is the opposite of interleaving a ROM dump. It is the process of converting the data to "binary" format. Binary in the sense that each successive byte in the ROM dump will be mapped to a higher address in the console.
ROM dumps can be interleaved (not for NES) and deinterleaved with uCON64.
NES
NES dumps can contain two types of data, "PRG data" and "CHR data". Interleaved NES dumps have the PRG data stored at the even offsets in the file and the CHR data at the odd offsets. Non-interleaved dumps first contain all the PRG data followed by the CHR data (if present).
Cannot be interleaved with uCON64.
Can be deinterleaved with uCON64 using the option -dint.
PC-Engine
Interleaved PC-Engine or TurboGrafx-16 dumps are not produced by a specific backup unit. It depends on the HuCARD (PC-Engine/TurboGrafx-16 game cartridge). American HuCARDs produce an interleaved dump, because the 8 data pins are reversed compared to Japanese HuCARDs. Perhaps "bit-swapped" is a better word to describe the format, but using the word interleaved prevents confusion (as bit-swapped implies a non bit-swapped reference).
Can be interleaved with uCON64 using the option -mgd, making the game suitable for a TurboGrafx-16. You can use the option -swap afterwards if you want to play the game on a PC-Engine.
Can be deinterleaved with uCON64 using the option -msg.
Genesis
Interleaved Genesis dumps are produced by the Super Magic Drive and the Multi Game Doctor 2.
For the SMD: for each block of 16384 bytes of the ROM all bytes at even offsets are stored in the upper half of the dumped block. The bytes at odd offsets are stored in the lower half. So, each dumped block first contains 8192 "odd bytes" then 8192 "even bytes".
For the MGD2: all odd bytes of the file are stored in the first half of the file, all even bytes in the second half.
Can be interleaved with uCON64 using the option -smd or -mgd.
Can be deinterleaved with uCON64 using the option -bin.
SNES
Interleaved SNES dumps are produced by the Game Doctor and the Super UFO when dumping a HiROM cartridge. The simplest interleaved format first contains all upper halfs of each 64 kB block of the ROM (HiROM "banks"), then all lower halfs. There are several interleaved formats, but except for one they all share the principle of dividing each 64 kB block in two.
SNES ROMs contain a block of 48 bytes, some call it the internal SNES header, that contains information about the ROM. Information like game name, checksum, size and the bank type. There are two bank types, HiROM and LoROM (as far as we know these are terms not used by Nintendo). HiROM ROMs have banks of 64 kB, LoROM ROMs have banks of 32 kB. The first bank contains the internal SNES header at a fixed offset relative to the end of the bank. However, because the bank sizes differ for HiROM and LoROM the absolute locations differ for the two in non-interleaved dumps. If dumps are interleaved the absolute locations are the same.
The interleaved format was probably introduced so that a backup unit can (the Game Doctor does only if the dump has no header) always check the same location in a dump to tell whether it should handle it as a LoROM or a HiROM dump.
Can be interleaved with uCON64 using the option -mgd, -mgh, -gd3 or -ufo.
Can be deinterleaved with uCON64 using the option -dint, but it is better to use one of the regular conversion options -smc, -swc, -fig and -ufosd. Some SNES tools erroneously interleave LoROM dumps. These dumps can be deinterleaved with the options -mgd, -mgh, -gd3 and -ufo as well as with the aforementioned (SNES) options.
Nintendo 64
Interleaved Nintendo 64 dumps are produced by the Doctor V64 and the Doctor V64 Junior. Perhaps "byte-swapped" is a better term for Nintendo 64 dumps. For each two bytes the first and the second byte are swapped.
Can be interleaved with uCON64 using the option -v64.
Can be deinterleaved with uCON64 using the option -dint, but it is better to use the regular conversion option -z64.

Q46: The pre-compiled GNU/Linux binary does not work on my system, while a binary compiled by me works fine. How can that be?
A: If you get this output on the command line:
libgcc_s.so.1: cannot open shared object file: No such file or directory
Or when the command "ldd discmage.so" gives output that looks like this:
libz.so.1 => /usr/lib/libz.so.1 (0x4002b000)
libgcc_s.so.1 => not found
libc.so.6 => /lib/libc.so.6 (0x40039000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
(note the text "not found") then you are experiencing a binary incompatibility problem with the add-on discmage library. You can either remove the discmage library from the directory where uCON64 looks for it (see question 4) or compile the library yourself (see question 3).

Q47: I use Windows XP (NT/2000) and every time I run uCON64 I get this error message about ntuser.dat. What does it mean?
A: If you see lines in the display output of uCON64 that look like these:
Create: ntuser.idx
ERROR: Cannot open "C:\Documents and Settings\NoisyB\ntuser.dat" for reading
you should modify the configuration file so that ucon64_datdir points to another directory.
By default uCON64 versions before 2.1.0 will use the home directory as the directory where it searches for DAT files (the "DAT file directory"). uCON64 handles all files in the DAT file directory that have a name that ends with ".dat" as DAT files. ntuser.dat seems to be a standard file in a Windows XP user's home directory (and should not be removed), but it is not a DAT file for use with uCON64. See question 36 for more information on how to configure uCON64 so that it uses "real" DAT files. If you only want to get rid of that error message either make ucon64_datdir in the configuration file point to an existing directory that does not contain any files with a name that ends with ".dat" or make an environment variable with the name ucon64_datdir point to such a directory. Do not forget that the environment variable will not be set the next time you start a DOS session.
Starting with version 2.1.0 the DOS and Windows versions of uCON64 will by default use the subdirectory dat of the subdirectory ucon64 of the home directory (~\ucon64\dat\) as DAT file directory.

Q48: Is there any way to make uCON64 convert a ROM dump to Game Doctor SF3/SF6/SF7 format and split it, in one command?
A: Not directly, but it can be done with the help of a shell script or batch file. See question 41 for some information on how to make a shell script or batch file run. Here is a Bash script:
#! /bin/bash
usage ()
{
echo "Usage: $0 file_to_convert_and_split"
exit
}
GD3DIR="convert"
SPLITDIR="split"
if [ ! -n "$1" ]; then usage; fi
if [ ! -e "$1" ]; then usage; fi
if [ ! -e "$GD3DIR" ]; then mkdir "$GD3DIR"; fi
if [ ! -e "$SPLITDIR" ]; then mkdir "$SPLITDIR"; fi
rm -f "$GD3DIR"/*
rm -f "$SPLITDIR"/*
ucon64 -q -gd3 "$1" -o "$GD3DIR"
ucon64 -q -s "$GD3DIR"/* -o "$SPLITDIR"
And here is a batch file:
@echo off
set GD3DIR="convert"
set SPLITDIR="split"
if .==.%1 goto usage
if not exist %1 goto usage
if not exist %GD3DIR% mkdir %GD3DIR%
if not exist %SPLITDIR% mkdir %SPLITDIR%
del /q %GD3DIR%\*
del /q %SPLITDIR%\*
ucon64 -q -gd3 %1 -o %GD3DIR%
ucon64 -q -s %GD3DIR%\* -o %SPLITDIR%
goto exit
:usage
echo Usage: %0 file_to_convert_and_split
:exit
Say you saved the batch file to the name cs.bat, then you can convert a file to Game Doctor format and split it with:
cs somegame.swc
Afterwards you can find a file in Game Doctor format in the directory convert and the split parts in the directory split. Modify the scripts above if you want them to make uCON64 write its output to other directories. Do not make GD3DIR or SPLITDIR point to the current directory or to your SNES ROM directory as the scripts will remove all files in the directories pointed to by GD3DIR or SPLITDIR. Starting with empty directories is the main reason why the scripts work (actually, this is only true for GD3DIR).

Q49: How do I use the command line?
A: There are some commands that are very common when using uCON64. I will only explain how to use those. Search the internet if you want to know more.
First read the section "The command line environment". The first principle you should understand is how the space on your hard disk(s) is organised. Before an operating system is able to use a hard disk it needs to have a file system. A hard disk can contain several file systems. On DOS and Windows each file system is called a "drive" and gets assigned a drive letter. A file system can store files and directories. Directories can be seen as special files that themselves "contain" files and directories. By using directories it is possible to quickly oversee the structure of a file system and keep it organised. On GNU/Linux file systems are visible in the directory structure (e.g. /mnt/windows). With Windows XP it is possible to make file systems visible/accessible in the same manner.
When using the command line there is something called the current directory. The current directory is like an implicit directory. Several commands and programs use the current directory when a directory is not explicitly specified. For example, the command dir (UNIX: ls) lists the contents of a directory. When you do not specify a directory it will list the contents of the current directory. You can change the current directory with the command cd. For example, to change the current directory to "roms" on drive C: type:
cd C:\roms
On DOS and Windows there is also a current drive. You can change the current drive by specifying the drive letter followed by a colon. For example to change the current drive to D: type:
d:
On DOS and Windows the current directory is a bit different than it is on UNIX: each drive has its own current directory. It is possible to change the current directory of a drive while the current directory of the current drive is not changed. The first example with cd does just that when C: is not the current drive. When C: was the current drive you would not have to specify the drive letter as the command line interpreter would assume you intended to change the current directory of C:. When a text refers to the current directory on DOS and Windows the author usually means the combination of current drive and current directory. In other words, when directed to change the current directory to C:\ucon64 you actually have to change the current drive to C: and the current directory on C: to ucon64.
Let us assume you have the following directory structure:
C:
+--roms
| +--snes
| | +--gd3
| +--n64
+--tmp
D:
+--roms
+--sms
To change the current directory (of drive C:) to C:\roms\snes\gd3 type:
cd C:\roms\snes\gd3
You can see that each directory is separated from its parent by a backslash ('\'). On UNIX (or Bash on Windows) you would refer to the same directory by replacing the backslashes with forward slashes and perhaps replacing "C:" with the appropriate mount point (e.g., /mnt/windows/roms/snes/gd3). Note that "C:" is a valid directory name on a GNU/Linux file system.
You can refer to the other directories (and files) in a relative manner. Say C:\roms\snes contains the file Secret of Mana (U).swc. You can make uCON64 display information about that file with:
ucon64 "C:\roms\snes\Secret of Mana (U).swc"
but also with:
ucon64 "..\Secret of Mana (U).swc"
The quotes are necessary or else uCON64 would handle Secret, of, Mana and (U).swc as separate files. This is usual behaviour for command line programs, it is not specific to uCON64.
".." is a special directory. Each directory contains two special directories, "." and "..". "." refers to the current directory, ".." to the directory one level higher in the directory structure. For example, to see the contents of the directory "roms" you could type:
dir C:\roms
but also:
dir ..\..
Or on UNIX:
ls ../..
C:\roms\snes is called a path. To be more specific, an absolute path. It is the path to follow in the directory structure to get to the file Secret of Mana (U).swc. "..\.." is a relative path. In C:\roms\snes "..\.." refers to another directory than in C:\roms\snes\gd3 (C:\ and C:\roms respectively). To change the current directory to C:\roms\snes type:
cd ..
Say you want to convert Secret of Mana (U).swc to Game Doctor format, place the converted file in C:\roms\snes\gd3, split that file in pieces, place those pieces in C:\tmp and transfer the pieces to a Game Doctor SF7. You could type the following commands:
ucon64 -gd3 "Secret of Mana (U).swc" -o .\gd3
ucon64 -s gd3\sf16Sec -o C:\tmp
ucon64 -xgd3 ..\..\tmp\SF16SECA.078
Besides dir (UNIX: ls) and cd there are some other commands that you may find useful:
del (UNIX: rm) to delete or remove a file
xcopy (UNIX: cp) to copy a file
md (UNIX (and Windows): mkdir) to create a directory
rd (UNIX (and Windows): rmdir) to remove a directory
set (UNIX (Bash): export) to set (and export) an environment variable
rmdir cannot remove a directory if there are still files (or directories) in it. On DOS and Windows you can get more information about these commands by using the option /?. On UNIX the equivalent is --help. For example, if you want to get more information about del you could type:
del /?
Here follows a final example that uses the commands mentioned above:
cd \
md test
cd test
xcopy "C:\roms\snes\Secret of Mana (U).swc" mana.swc
set parport=378
ucon64 -xswc mana.swc
del mana.swc
cd ..
rd test
First the current directory is changed to C:\. Then the directory "test" is created. Then the current directory is changed to "test". Then the file C:\roms\snes\Secret of Mana (U).swc is copied to the file mana.swc. Then an environment variable with the name parport is set to the value 378. Then uCON64 is used to transfer mana.swc to a Super Wild Card while using parallel port address 0x378. Then the file mana.swc is removed. Finally the directory "test" is removed.

Q50: I configured uCON64 to use ppdev and tried to send a file to my backup unit as a regular user. I got an error message that the parallel port device could not be opened. What did I do wrong?
A: There are two possibilities:
1.) You specified an incorrect parallel port device in the configuration file.
In most cases the correct device is /dev/parport0. Only change the device name if you are sure /dev/parport0 is not the device associated with the parallel port your backup unit is connected to. Try for example /dev/parport1 or /dev/parport2.
2.) You do not have the required privileges.
It is true that regular users can transfer files to and from their backup units (without the executable being setuid root), but that does not mean any user can do that. It is quite common that only users in the group "lp" have access to /dev/parport<n>. So, you should add yourself to that group. Say your login name is helanren. User root could use the following command to give you the privilege to use /dev/parport0:
usermod -G `id -Gn helanren | sed "s/ /,/g"`,lp helanren
Explanation:
usermod -G <groups> helanren is used to make helanren a member of those groups.
id -Gn helanren lists the groups helanren is currently a member of, separated by spaces.
sed "s/ /,/g" replaces all spaces with commas.
You may have to log off and on again, before the changes take effect.

Q51: What do I need to do before I can upload files to my Flash 2 Advance?
A: Download the package that contains the support files from the uCON64 homepage. Extract the package and update the configuration file. See "How to configure the uCON64 executable". If you want to use the parallel port version of the F2A, you should set at least the variable iclientp. If you want to send multiple files to your F2A, also set gbaloader. If you want to see a different background while uploading, set ilogo.
The USB version of the F2A is currently only supported on GNU/Linux. If you want to use the USB version, you should set at least the variables f2afirmware and iclientu. If you want to send multiple files to your F2A, set gbaloader. Additional requirements are:
- libusb (included in recent GNU/Linux distributions)
- usbdevfs has to be mounted (most (?) distributions have usbdevfs mounted by default, but you can do it manually with "mount -t usbdevfs none /proc/bus/usb")
- if you use Linux 2.4 or older then the EZUSB2131 firmware upload driver has to be loaded, see http://ezusb2131.sourceforge.net/
- if you use Linux 2.5 or later fxload should be present in /sbin
- you need to have read/write access to /proc/ezusb and /proc/bus/usb, so you have to run uCON64 as root (or setuid root) for the USB version of the F2A
By default, uCON64 tries to access a parallel port to communicate with an F2A. In order to make uCON64 communicate with an F2A connected to a USB port, use the switch -port. For example:
ucon64 -xf2a "Wario Ware Inc.zip" -port=usb
uCON64 detects to which USB port the F2A is connected, so you do not have to specify a specific port.

Q52: What is the option --xreset for? In what case should it be used?
A: Simply put, this option removes power from the parallel port, until you next use the parallel port (it sets all data lines low, to avoid latch-up).
Before running uCON64, power is sometimes present on the parallel port. If power is present and you connect a device that is not switched on, power will "back-feed" into the device from the parallel port, potentially damaging the device and the PC.
By using the --xreset command before attaching your device, power is removed from the parallel port, eliminating the hazard.
Likewise, a danger exists when you have finished using your device and switch the power off. In this case, use --xreset before switching the device off.
Additionally, after switching the device off, aim to disconnect it as soon as possible. Printing, rebooting, and running certain applications may cause power to be re-applied to the parallel port -- a back-feed hazard.

Q53: I am trying to use a PCIe parallel port card, but while uCON64 can communicate with an older backup unit like my Super Wild Card it cannot communicate with my MD-PRO, which requires EPP. Can this be solved?
A: First make sure EPP is enabled for your PCIe parallel port card. Try different settings for the parallel port in the BIOS, UEFI or configuration software. "ECP and EPP 1.9" should give the best results. This may already solve the problem.
If the above did not solve the problem and you are using ppdev on GNU/Linux then it looks like your PCIe parallel port card is not fully supported by the version of GNU/Linux you are using. The problem could be caused by your PCIe parallel port card requiring to enable EPP through the ECP Extended Control register while that register is mapped to a non-standard offset relative to the Data register. Fortunately, starting with uCON64 2.1.0 this problem can be solved for all supported platforms on which the parallel port can be accessed directly. So, GNU/Linux, all Windows versions (including Windows 10), MS-DOS, FreeBSD, OpenBSD, NetBSD and BeOS. First determine the offset of the ECP Extended Control register relative to the Data register.
On GNU/Linux use lspci -v to find out what I/O ports are being used by your PCIe parallel port card. On Windows you can use Device Manager. You should see two I/O ranges. One of them should start with the I/O port you specified when communicating with your Super Wild Card. That is the I/O address of the Data register. The other starts with the I/O port of the first ECP configuration register. Add 2 to get the I/O address of the ECP Extended Control register. To get the offset subtract the I/O address of the Data register from the I/O address of the ECP Extended Control register, in that order.
Find the line starting with ecr_offset= in the configuration file and update it with the value you just calculated.
Another way to determine which of the two I/O ranges is the ECP range is by looking at the size. The ECP range is likely 4 bytes, while the other is 8 bytes.

Q54: My PCIe parallel port card has its ECP Extended Control register at a lower I/O address than its Data register. How do I specify a negative ECP Extended Control register offset in the configuration file?
A: See question 53. Use a calculator and set it to hexadecimal (base 16). After you subtract the I/O address of the Data register from the I/O address of the ECP Extended Control register you will see a lot of leading Fs ending in different characters, probably 02. Note the last 4 digits. Find the line with ecr_offset=402 in the configuration file and replace 402 with the 4 digits.

Q55: Why is uCON64 unable to communicate with my Doctor V64 or Game Doctor SF6/SF7?
A: The communication protocols of the Doctor V64 and Game Doctor SF6/SF7 involve reading specific values from the parallel port Control register. However, the Control register was intended as a write-only register. Many old parallel ports support input from this register, but most newer ones do not. You may happen to have a parallel port that does not support using the Control register for input.
Another possibility may be that you configured uCON64 to use ppdev on PC. For PC the developers of ppdev decided to target the lowest common denominator and to not support reading from the Control register, which is unhelpful to say the least. So, even if your parallel port supports using the Control register for input, ppdev will not let you. This means that you cannot use ppdev in combination with a Doctor V64, unless you modify ppdev. For PC try replacing the body of parport_pc_read_control() with:
return inb (CONTROL (p));
Then compile ppdev or Linux depending on whether ppdev should be a module or part of the kernel.
For the Game Doctor SF6/SF7 a workaround exists by using the Game Doctor SF3 protocol, but you will lose the saver (RTS) transfer and SRAM dumping functionality. Of course, on PC you can also avoid this by not configuring uCON64 to use ppdev.
Alternatively, starting with uCON64 2.1.1 you can try your luck with the variable gd6_send_byte_delay which works even in combination with a stock ppdev. Transferring ROM data is unfortunately unlikely to succeed even with a value as high as 30µs. However, for dumping saver data and SRAM the functionality is good enough. Start with a larger value like 30 to be on the safe side, i.e., the delay is long enough for the Game Doctor SF6/SF7 to be ready for the next byte. 22 has been used successfully on GNU/Linux running on a Raspberry Pi 2B, a Raspberry Pi 3B+ and a Raspberry Pi Zero with a pi-parport in combination with a Game Doctor SF7. 25 has been used successfully on Windows 7 with giveio64 also in combination with a Game Doctor SF7. 14 has been used successfully on plain DOS in combination with the same Game Doctor. Note that on DOS the value is a rough approximation of the delay in microseconds and the actual delay can vary between different machines. On the same machine the delay is constant for a particular value. You may have to try a few times before a transfer succeeds. Uploading a ROM with --xgd3 greatly increases the chance of successfully dumping saver data and SRAM with --xgd6r and --xgd6s respectively.

Q56: I installed a DAT file, but every time I run uCON64 it warns that the DAT file is meant for a console unknown to it. What is wrong?
A: The name of the DAT file. See question 43.
In case you downloaded a DAT file from DAT-o-MATIC, do not only rename the file, but convert it first. You can use DatUtil to convert such a DAT file to RomCenter 2.50 format, which is the only format uCON64 supports. For example, to convert the file "Nintendo - Super Nintendo Entertainment System (20170927-100457).dat" in order to use it with uCON64, use a command like:
datutil -f rc2 -o snes-20170927.dat "Nintendo - Super Nintendo Entertainment System (20170927-100457).dat"
You can then move snes-20170927.dat to uCON64's DAT directory.

Q57: I installed a Nintendo 64 DAT file from DAT-o-MATIC, after converting it to RomCenter 2.50 format, but uCON64 does not display DAT information for verified Nintento 64 ROMs. What is wrong?
A: Nintendo 64 DAT files used to contain CRC32 values of ROMs in Doctor V64 format. However, DAT-o-MATIC produces Nintendo 64 DAT files with CRC32 values of ROMs in Mr. Backup Z64 format. Starting with version 2.1.0 you can control what format uCON64 uses to calculate CRC32 values with the variable n64_dat_v64. By default it is 1, meaning Doctor V64 format, for backward compatibility. Set it to 0 for Mr. Backup Z64 format if you want to use a Nintendo 64 DAT file produced by DAT-o-MATIC.

Q58: I tried to upload a game to my Super UFO Pro 8 SD (on Windows), but uCON64 only produced an error message. What is wrong?
A: If this is the error message:
ERROR: Could not open Super UFO USB device with vendor ID 0x1292 and product ID 0x4653
then you should add support for libusb-win32 with Zadig.

`