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, macOS), 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 GCC (GNU Compiler
Collection), Clang or the Visual C++ compiler. GCC can be downloaded
from
https://www.gnu.org/prep/ftp.html. On GNU/Linux GCC is usually already
installed. Clang can be downloaded from
https://releases.llvm.org/download.html.
Visual C++ is part of Visual Studio. A free version of Visual Studio, Visual
Studio Community 2015, can be downloaded from
https://visualstudio.microsoft.com/vs/older-downloads/. 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 Windows port of GCC (and many other GNU
tools and libraries) named Cygwin is available from
https://www.cygwin.com/.
A Win32 port of GCC (and other tools) named MinGW is available from
https://mingw.osdn.io/. A Win64 port
named MinGW-w64 is available from
https://www.msys2.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: no)
- 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 https://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
(libusb-compat). If you do not have libusb you can get it from
https://libusb.info/. For Windows you
need libusb-win32. You can get it from
https://sourceforge.net/p/libusb-win32/wiki/Home/. For macOS it is
easiest to install libusb-compat through
MacPorts. After you have installed
MacPorts, install libusb-compat with:
sudo port install libusb-compat
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.
If the header file of libusb-compat, usb.h is installed in a non-standard
directory you will have to specify that directory to the configure script.
For example, on macOS after having installed libusb-compat through MacPorts,
by default usb.h will be present in the directory /opt/local/include. You can
specify that directory with the compiler flag -I. Compiler flags can be
specified with the environment variable CFLAGS. So, for macOS use a command
like this:
CFLAGS=-I/opt/local/include ./configure --with-libusb
--disable-parallel
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
uCON64 comes with the library discmage, but starting with version 2.2.1 it
will no longer be compiled by default. Discmage can be 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 want to compile discmage and you are using DJGPP you need the library
libgcc.a. This library comes with DJGPP 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 (if you passed the
option --with-libdiscmage to the configure script), type:
make
If you want to compile uCON64 only (even if you enabled support for discmage)
the last command should look like this for DJGPP, Cygwin and MinGW:
make ucon64.exe
Otherwise it should look like this:
make ucon64
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 may ask for your password (for sudo), 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 (configure option --disable-parallel) or if you configured it to
use ppdev (configure option --enable-ppdev), uCON64 need not be setuid root.
Just copy ucon64 to any directory you like.
You can override the default destination directory /usr/local/bin by setting
the environment variable DESTDIR. For example, in order to install uCON64 to
the directory /opt/local/bin use the command:
DESTDIR=/opt/local/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 (macOS) to it, so you may find
it easier to use it.
On BeOS this command will open a dialog window. Just follow the
instructions.
Clang
You can indicate that you want to use Clang by setting the environment
variable CC to clang. You can specify Clang at configuration time:
CC=clang ./configure
Or at build time:
CC=clang make
On macOS gcc may actually be Clang. However, by default uCON64 uses gcc and
will pass options to it that Clang does not understand, resulting in
warnings. So, it is better to specify that you want to use Clang.
If you have compiled uCON64 in the same directory before, first type:
make clean
If you want to compile the source code including discmage (if you passed the
option --with-libdiscmage to the configure script), type:
make
If you want to compile uCON64 only (even if you enabled support for discmage)
the last command should look like this:
make ucon64
If you specified a non-standard include directory at configuration time, for
example on macOS when using libusb-compat installed through MacPorts, you
have to specify the same directory at build time. In the case of
libusb-compat installed through MacPorts you will also have to specify the
directory where the library file is installed, by default /opt/local/lib.
You can specify that directory with the linker flag -L. Linker flags can be
specified with the environment variable LDFLAGS. So, for macOS use a command
like this (if you specified CC=clang at configuration time):
CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib make
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.
One extra command is needed (or simply handy):
make install
On UNIX this command may ask for your password (for sudo), 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 (configure option --disable-parallel) or if you configured it to
use ppdev (configure option --enable-ppdev), uCON64 need not be setuid root.
Just copy ucon64 to any directory you like.
You can override the default destination directory /usr/local/bin by setting
the environment variable DESTDIR. For example, in order to install uCON64 to
the directory /opt/local/bin use the command:
DESTDIR=/opt/local/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 (macOS) to it, so you may find
it easier to use it.
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%\..\..\VC\vcvarsall.bat" x86
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.
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 (if you have
removed the "//" in front of the line that defines USE_DISCMAGE in config.h
and removed the "#" in front of the line with "USE_DISCMAGE=1" in
Makefile.vc6), type:
nmake /f Makefile.vc6
If you want to compile uCON64 only (even if you enabled support for 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
https://upx.github.io/.
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, macOS) & 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 cannot run sudo, copy the uCON64 executable to a
directory in your PATH. If you can run sudo, 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. For
example, in order to install uCON64 to the directory /opt/local/bin use the
command:
DESTDIR=/opt/local/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 or
Power Archiver.
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
https://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 or
Power Archiver.
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 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
https://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
https://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 |
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
https://ucon64.sourceforge.io/#ucon64gui
Q16: Where do I get PPF, APS or IPS patches?
A:
Q17: Where do I get ROMs/Games?
A: https://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
https://emulationrealm.net/ or
https://www.romcenter.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
https://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 ToToTEK
Copiers 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 |
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 -a -G lp helanren
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), SRAM and ROM 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. Uploading data is unfortunately unlikely to succeed even with a value
as high as 30µs. However, for dumping saver, SRAM and ROM data 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,
SRAM and ROM with --xgd6r, --xgd6s and --xgd6 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.