Q1: Why uCON64?
A: uCON64 was 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 :-)
But besides this it can operate as an intelligent frontend for every
available emulator.
Q2: How do I compile uCON64?
A:
To create a DOS executable you'll need DJGPP,
a DOS port of gcc and other GNU development tools.
To create a Win32 executable you'll need Cygwin,
a Windows port of gcc and many other GNU tools and libraries.
If you use a Bash compatible shell first enter the following line:
./configure
Pass the option --with-zlib to the configure script if you want to enable gzip & zip
support. zlib is available from
http://www.gzip.org/zlib/.
If you use a Bash incompatible shell (like command.com or cmd.exe), copy config.h.orig
to config.h and Makefile.orig to Makefile.
Now you can optionally open config.h in an editor and change the defines. Then enter
the following lines:
make clean
make
make install
Under Unix the last command will ask for root's password, because uCON64 needs to be
setuid root for parallel port access. Under BeOS the last command will open a dialog
window. Just follow the instructions. Under DOS and Windows (but also under Unix and
BeOS) you can find the executable in the directory where you ran make.
You could use UPX to compress the executable. UPX is available from
http://upx.sourceforge.net.
On Unix systems other than Linux you might need to use 'gmake' instead of 'make'.
Q3: How do I install uCON64?
A: You already did if you followed the directions in the previous answer (you
downloaded the source package). If you don't use WinDOS run install.sh (Unix) or
install_beos.sh (BeOS) and edit $HOME/.ucon64rc. If you use WinDOS you may
want to copy ucon64.exe to a directory in your PATH and maybe edit ucon64.cfg.
If you use DOS or Windows 9x and don't want uCON64 to create ucon64.cfg or .ucon64rc files
all over the place (current directories) see question 24.
For copier I/O BeOS users will need Caz's driver inside ioport.zip or available at
http://www.infernal.currantbun.com.
Windows NT/2000/XP users might also need a driver. You could use giveio or UserPort. At
http://www.devrs.com/gba/files/mbv2faqs.php
you can find links to those programs. They are also included with the binary release. With giveio sending
ROMs goes faster than with UserPort, but UserPort is a bit easier to use.
It is possible to use uCON64 as a transfer tool without giveio or UserPort under Windows XP. We
have had reports from people who were able to send and receive ROMs under Windows XP as a
regular user (no Administrator rights and not "Power Users").
Q4: 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 don't do that ;-)
Q5: How do I make uCON64 display only 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. Note that 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"
Q6: 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 0x278
The I/O address of the parallel port can be 0x3bc, 0x378 or 0x278. If you don't want to
type the address of the parallel port everytime you want to transfer something to your FAL
(or another copier) 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
isn't present add one. You don't 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. Note
that the value in the configuration file takes precedence over the value of the environment
variable.
Q7: I tried to dump a SNES cartridge using a Super Wild Card connected to my PC with an
interlink cable, but it didn't work. What's wrong?
A: You shouldn't 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 the
following way:
pin 1 <-> pin 1
pin 2 <-> pin 2
pin 3 <-> pin 3
pin 4 <-> pin 4
pin 5 <-> pin 5
pin 6 <-> pin 6
pin 7 <-> pin 7
pin 8 <-> pin 8
pin 9 <-> pin 9
pin 10 <-> pin 10
pin 11 <-> pin 11
pin 12 <-> pin 12
pin 13 <-> pin 13
pin 15 <-> pin 15
pin 25 <-> pin 25
The other pins may be left unconnected. Pins 2-9 are used for output, pins 10-13 & 15 for input
and pin 25 is ground.
Q8: I have a SNES ROM of which GoodSNES says it's good, but
uCON64 says it's bad. Who is right?
A: GoodSNES.
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. A bigger problem is that the interleave detection code
(stolen from Snes9x ;-) is not reliable. Especially BS ROMs are often
detected as not being interleaved while they actually are. Try the switches
-int and -int2 and see if you get better results. If the checksum is
reported as good it is very 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. That gives the best results.
Luckily you won't find many interleaved ROM dumps that uCON64 can't
handle, probably because Snes9x and ZSNES often can't handle them either.
Q9: I have a SNES ROM of which Snes9x and ZSNES say it's bad, but uCON64 says it's good.
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's a BS ROM. See previous answer.
Q10: 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's 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.
Q11: Some SNES games don't 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 doesn't contain any special chips that your Super Wild Card
doesn't support (look at the rom type information). For example, if you are
trying to upload 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). Also verify that
the backup header is correct. You can make uCON64 rewrite the header with
-swc. uCON64 uses the information in the ROM dump's header, so this is
important! You can also try to rewrite the header in combination with the
switch -hi or -nhi to force uCON64 to handle it as a HiROM or a LoROM dump.
Additionally you could use the switch -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 doesn't 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.
Note that some games have more than one type of copy protection, so it might
be necessary to use uCON64 several times with a different option.
Some games seem to work, but after a while it becomes clear that they don't
run as was intended. Two examples of such games are Demon's Crest and Mega
Man X. For completeness 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"
Q12: Which backup devices are supported by uCON64?
A: See hardware.html.
Q13: I use Windows XP (NT/2000). When I try to run ucon64.exe under command.com (start -> Run...
-> command) uCON64 crashes. What do I do wrong?
A: You shouldn't use command, use cmd instead. However, starting from version 1.9.8 uCON64 should run fine
under command.com.
Q14: I don't like the command line. Are there graphical frontends available?
A: Yes, have a look at http://ucon64.sourceforge.net/index2.html#ucon64gui
Q15: Where do I get PPF, APS or IPS patches?
A:
Q16: Where do I get ROMs/Games?
A: www.ebay.com
Q17: Usage: What does --rom and --file stand for?
A: Enter "ucon64 -help | more" and look at the top where it says:
Usage: ucon64 [OPTION]... [--rom=]ROM [[--file=]FILE]
--rom and --file take an argument, --file is mostly optional.
Q18: Why is my backup unit (still) not supported?
A: Get us the protocol or the sources of existing transfer tools and you'll
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.
Q19: How do I specify a bank number for the GB Xchanger?
A: ucon64 -xgbxb <0> "Pokemon (Green).sav" wouldn't work. You should
leave out those angle brackets. This should work:
ucon64 -xgbxb 0 "Pokemon (Green).sav"
Q20: What's 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) in your Flash Card in "ROM bank" 4
(GBA Pack) and would like to save/restore SRAM bank 4 you should do something like:
ucon64 -xfalb 4 "Super Mario Advance 2 (J).sav"
Note that 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.
Q21: uCON64 exits with the message "Flash cart erase failed!" when I try
to write a multirom to my flash card. What's wrong?
A: The multirom file you created is too large for your flash card. When you make a
multirom file don't forget that the loader or "game pack" file also needs some space (32
kB) on the flash card. Don't pass a size to -multi that is larger than your flash card.
Passing a smaller size is correct too. For example, to create a multirom that fits on a
128 Mb (16 MB) card use a command line like this:
ucon64 -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 loader.bin rom1.gba rom2.gba rom3.gba rom4.gba
Just like sometimes happens with Visoly's tool it is possible to get the same message when the
multirom is small enough. It will probably work when you try again (with the same multirom).
Q22: Where can I get that loader or "game pack" file?
A: You can get it from Visoly's site.
It's in a file with a name like preboot32.zip.
Q23: What is the meaning of the -col option (Super Nintendo)?
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
Super Nintendo color. Ok? No? Then you don't need this option :-)
Q24: Why does uCON64 create ucon64.cfg (DOS executable) or
.ucon64rc (Win32 executable) files all over the place under 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 HOME, USERPROFILE or HOMEDRIVE and HOMEPATH (in that order).
Under Unix HOME is normally set. Under Windows XP and 2000 (NT?)
USERPROFILE, HOMEDRIVE and HOMEPATH are usually set. If uCON64 can't find
one of those environment variables it will look for the configuration file
in the current directory. If it can't find a configuration file it will
create one. Under DOS and Windows 9x none of those environment
variables are usually set. So, if you run uCON64 under DOS or
Windows 9x in a directory where no configuration file exists it will
create one there. If you don't 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 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. Note that 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.
Q25: When I try to create a multirom under Windows I get the message
"The system cannot execute the specified program." (or something like that).
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 the Win32 executable (download it from the uCON64 homepage).
2.) Rename the ROMs so that their combined names are short enough to fit into 127 characters.
Q26: I tried to run the Win32 executable of uCON64 but Windows gave an
error message that cygwin1.dll or cygz.dll could not be found.
A: The Win32 executable of uCON64 needs those DLLs in order to run. You can download
them from the uCON64 homepage.
Copy the files to the same directory as the uCON64 executable or to a directory in your PATH.
Q27: How do I make uCON64 display one help screen at a time?
A: Just as is stated in the last few lines of the help, pass the output of uCON64
to a program that waits for a key after one screen of text. You could use the program
"more". 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 GameBoy 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.
Q28: I tried to send a ROM dump to my copier under Windows XP
(NT/2000), but uCON64 crashed. What's wrong?
A: If the message looks like this (for the Win32 executable):
0 [main] ucon64 356 handle_exceptions: Exception: STATUS_PRIVILEGED_INSTRUCTION
5570 [main] ucon64 356 open_stackdumpfile: Dumping stack trace to ucon64.exe.stackdump
then you didn't install an I/O driver (correctly). See question 3.
Q29: I want to convert a NES ROM in iNES format to UNIF. How do I know
what board name to use?
A: The file
http://www.parodius.com/~veilleux/boardtable.txt contains a table where you can
find what game uses what board. The file
http://www.parodius.com/~veilleux/boardnames contains a list of all known board
names.
Q30: 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.
Q31: 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:
Dirk <noisyb@gmx.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 line looks almost the same:
ucon64 -unif smb.unf -dumpinfo info.txt
For an existing UNIF file you needn't 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.
Q32: 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 would use a command line like this:
ucon64 -unif smb.nes -mapr NROM -ctrl 0 -ctrl 4
Q33: 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. Under 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 of 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
Under 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 config file:
ansi_color=0