Q1: Who develops uCON64?

Q2: How can I take part?

Q3: How do I get the source of uCON64, using CVS as an anonymous user?

Q4: How do I connect to the CVS repository as developer with read/write access?

Q5: How do I create a patch from the CVS repository?

Q6: How is the source of uCON64 organized?

Q7: What coding style is preferred?

Q1: Who develops uCON64?
A: Written/modified by:
1999 - 2009 NoisyB
2001 - 2005, 2015 dbjh

Additional developers:
2002 - 2004 John Weidman <jweidman AT sonic.net>
Contributed several SNES-related features like Game Doctor & Super UFO support, the second version of the BS (Broadcast Satellaview) detection code, SNES cracks & NTSC/PAL fixes.

2002 - 2004 Jan-Erik Karlsson
Maintainer of the Amiga ports.

2003 - 2004 JohnDie
Also contributed several SNES-related features like Pro Fighter support and Super Wild Card transfer code improvements.

uCON64 uses code (or at least ideas) from:

Chicken & chp ronaldm AT netcom.com (chp) original uCON
Silo / BlackBag APS patcher
madman IPS patcher
The White Knight / ATX BSL patcher
Icarus / Paradox PPF patcher
WyrmCorp http://wyrmcorp.com Game Genie "codec"
Marat Fayzullin fms AT cs.umd.edu
some Famicom Disk System routines and NESLIST
Andreas Sterbenz stan AT sbox.tu-graz.ac.at N64 checksum algorithm
Kami m-kami AT da2.so-net.ne.jp
NES emulator for Game Boy
Gilligan / DC-S show info for Neogeo Pocket
LaC N64 makesram
Jeff Frohwein info AT devrs.com
Flash Advance Linker transfer code
Omar Kilani gbautil AT aurore.net Game Boy Advance SRAM patching and "crash patching" code
Richard Davies richard AT debaser.force9.co.uk
PSX memory card code
Caz turok2 AT currantbun.com
I/O port driver for BeOS, SWC help and Super UFO SRAM header format
Cowering hotemu AT hotmail.com old BS ROM detection, BS checksum, some PC-Engine info & code and more
Jerremy Koot jkoot AT snes9x.com
old interleave detection and old deinterleave code (SNES)
Gary Henderson gary AT snes9x.com
old interleave detection and old deinterleave code (SNES)
Evan Teran emt3734 AT ritvax.isc.rit.edu lib_unif (NES)
NSRT authors joecool22us AT yahoo.com
checksum algorithm for Momotaro Dentetsu Happy, their SNES add-on chip information page, SNES cracks (thanks to CL), third version of BS detection code (thanks to Nach) and general help and ideas
Gilles Vollant info AT winimage.com unzip.c & unzip.h
Tiptonium http://www.tiptonium.com donated a Super Magic Drive (SMD)
FluBBa maker (publisher) info for SNES, GB, CGB & GBA
gc-nfo.com GameCube image specs
ToToTEK Multi Media rayman AT tototek.com
MD-PRO, SMS-PRO/GG-PRO & PCE-PRO transfer code (Delphi) and help with that code
timofonic uCON64 PR work ;-)
Felipe XnaK felipe AT ComPorts.com
some info from his Genesis ROM format document
Ulrich Hecht uli AT emulinks.de
F2A (USB) code
David Voswinkel d.voswinkel AT netcologne.de F2A parallel port & Quickdev16 code
Ryan Underwood libcd64
Mike Pavone mask_of_destiny AT hotmail.com
Genesis/Sega CD transfer code
Cyan Helkaraxe cyan AT emulationzone.org
Cyan's Megadrive ROM copier transfer code
Parasyte Support for remaining N64 CIC algorithms (6101, 6103, and 6106)

and others...

Q2: How can I take part?
A: Install CVS and checkout the latest version from http://ucon64.sourceforge.net. Then make your changes, email ucon64-main AT lists.sourceforge.net and you will be named in this file and in the sources of course. Just the typical way of open source software development.

Q3: How do I get the source of uCON64, using CVS as an anonymous user?
A: For read-only access you must have CVS installed. First you have to login. To login, type:
  cvs -d:pserver:anonymous@ucon64.cvs.sourceforge.net:/cvsroot/ucon64 login
Then CVS will ask you for a password. Since you are logged in as anonymous you do not have a password, so just press the enter key at the password prompt. To download the uCON64 source, type:
  cvs -d:pserver:anonymous@ucon64.cvs.sourceforge.net:/cvsroot/ucon64 checkout -PR ucon64
The uCON64 source will then be downloaded to the directory ./ucon64.
It can be very busy at SourceForge which may result in a message like:
  cvs [login aborted]: recv() from server ucon64.cvs.sourceforge.net: EOF
  cvs [checkout aborted]: recv() from server ucon64.cvs.sourceforge.net: EOF
If you get that message simply try again.
You can speed up the download by using the option -z with a compression level parameter. For example:
  cvs -z 9 -d:pserver:anonymous@ucon64.cvs.sourceforge.net:/cvsroot/ucon64 checkout -PR ucon64
If you want to get up to date with the newest source code later, enter the directory ucon64 and type:
  cvs update -PRd

Q4: How do I connect to the CVS repository as developer with read/write access?
A: For read/write access you must have CVS and SSH installed and set the environment variable CVS_RSH=ssh. To download the source code, type:
  cvs -z 9 -d:ext:<username>@ucon64.cvs.sourceforge.net:/cvsroot/ucon64 checkout -PR ucon64
<enter password at prompt>
If you never logged on to ucon64.cvs.sourceforge.net before you may get a message (from SSH) like:
  The authenticity of host 'ucon64.cvs.sourceforge.net (' can't be established.
  RSA key fingerprint is 13:f1:65:c3:6c:b7:7e:a5:f0:f3:f5:19:f4:42:9c:4a.
  Are you sure you want to continue connecting (yes/no)?
Type yes (the whole word). SSH will respond with a message like:
  Warning: Permanently added 'ucon64.cvs.sourceforge.net,' (RSA) to the list of known hosts.
Now all files will be downloaded. Afterwards you can simply cd into the top level directory and continue by just typing:
  cvs update -PRd
  cvs commit -R
  cvs add <file>
  cvs remove -f <file>
You don't need to specify -d:ext:<username>@ucon64.cvs.sourceforge.net:/cvsroot/ucon64 anymore, because that information is stored in the CVS directories then.
If you use the update command in combination with (-)d, never forget to also use the option -P or you will get a lot of crap.

Q5: How do I create a patch from the CVS repository?
A: As developer:
  cvs -d:ext:<username>@ucon64.cvs.sourceforge.net:/cvsroot/ucon64 diff -Nau >mychanges.patch
<enter password at prompt>
As anonymous:
  cvs -d:pserver:anonymous@ucon64.cvs.sourceforge.net:/cvsroot/ucon64 login
<just press enter at password prompt>
  cvs -d:pserver:anonymous@ucon64.cvs.sourceforge.net:/cvsroot/ucon64 diff -Nau >mychanges.patch

Q6: How is the source code of uCON64 organized?
A: The heart of uCON64 is ucon64.h/st_ucon64_t. This struct is designed to hold all workflow relevant informations and it has pointers to different structs which will be != NULL depending on which type or format uCON64 did detect for the current ROM. libdiscmage (if compiled) is involved in this process as well.

uCON64 starts with the name of a ROM and possibly some arguments. Then it checks if a configuration file exists and creates one if that is not the case. For example the value of ucon64.parport, the variable that contains the I/O address of the parallel port, will initially be set to the value that is found in the configuration file.
After these initial functions every ROM will be processed.

Processing a ROM.
The command line will be scanned for switches. Switches are command line arguments that will not result in an action by themselves, but they influence the other type of command line arguments, options.
uCON64 sets some other values in ucon64.h/st_ucon64_t, based on the switches. This code can be found in ucon64_opts.c/ucon64_switches(). This is also the place where ucon64.c/ucon64.quiet is set. This variable determines whether or not uCON64 displays ROM information.
Then uCON64 starts scanning the command line for options. This code can be found in ucon64_opts.c/ucon64_options(). From this code almost all operations of uCON64 are executed. On UNIX this is also the point where root privileges are given up with a call to misc.c/drop_privileges().
First uCON64 tries to find out what console system the ROM belongs to using for example the init function for SNES (console/snes.c/snes_init() or console/nes.c/nes_init() for NES). Each init function tries to determine if the ROM file belongs to its console type. If that is the case it returns 0, otherwise -1.
Some ROM file types contain information such as the internal name, country and creator of the game that can be used to fill ucon64.c/main()/rom. SNES ROM files are an example of this type of file. For other ROM file types this information is not present inside the ROM file. NES ROMs are an example of that type. In that case uCON64 uses the DAT files in the data file directory. That makes it possible to display the full name of the game. ucon64.c/ucon64_rom_handling() calls the function ucon64_dat.c/ucon64_dat_search() that uses the CRC32 of the ROM file data to find the required information in the DAT files. If the information could be found ucon64_dat.c/ucon64_dat_search() fills ucon64.c/ucon64.dat with it. ucon64.c/ucon64_rom_handling() copies the name to ucon64.rominfo->name.
After that if ucon64.c/ucon64.quiet has a value smaller than 1 uCON64 will call ucon64.c/ucon64_nfo() which displays the values and strings of ucon64. For some options it doesn't make sense to display ROM info. If one of those options has been specified on the command line (ucon64.c/ucon64.flags & WF_NFO) will be zero.
After all this the option will be executed (ucon64_opts.c/ucon64_options()).

Q7: What coding style is preferred?

Always put a space after a keyword. That includes the keyword sizeof.

Two spaces instead of a real tab. The curly braces of functions should not be indented.
If an if statement has an else part, that part should be aligned with the if part. For a do-while compound statement, do and while should also be aligned.
If else is immediately followed by an if statement, the if keyword together with the condition statement should be put on the same line as the else keyword. Example:

   if (...)
   else if (...)
Note that this doesn't apply to the case where else is followed by a curly brace.

New lines
The statement(s) for if, while and for should always start on a new line. That also applies to one-line statements.

Compound statements
The curly braces should be indented and the code of the compound statement should be indented again. The only exception is the switch statement. The labels inside a switch statement should be aligned with the curly braces. Example:
   function (int value)
     if (value < 0)
         printf ("Invalid argument: %d\n", value);
         exit (1);
     switch (value)
       case 0:
       case 1:
       case 2:                                     // falling through
         puts ("lesser than or equal to 2\n");
       case 3:
       case 4:
         puts ("lesser than or equal to 4\n");
         puts ("greater than 4\n");

     return 0;
A do-while compound statement should have this layout:
   while (...);

Function calls should contain one space after the name of the function. Every parameter of the function should be separated from a previous one with a space after the comma.
For a function implementation the return type should be specified on its own line. This doesn't apply to function prototypes. If a function needn't be known at global scope it should be declared or defined as static. Function implementations should be separated from each other by two new lines.

Variables of the same type should be defined in one group. Example:
   int x, y = 0, z;
   char str1[] = "xyz", *str2;
Variables that need to be known at file scope but not at global scope should be defined as static. Variables that do need to be known at global scope should be defined in a source file, not in a header file. The header file should contain an extern statement for the variable.

Types (structs)
A struct tag of a struct should have the prefix "st_". A new type based on a struct should have the same prefix and the suffix "_t". Example:
   typedef struct st_unif_chunk
     unsigned long id;
     unsigned long length;
     void *data;
   } st_unif_chunk_t;

Line length
The length of lines shouldn't be much longer than 90 characters. This doesn't necessarily include the length of comment. Longer lines should be broken into several shorter ones. Example:
   static const int unif_prg_ids[] = {PRG0_ID, PRG1_ID, PRG2_ID, PRG3_ID,
                                      PRG4_ID, PRG5_ID, PRG6_ID, PRG7_ID,
                                      PRG8_ID, PRG9_ID, PRGA_ID, PRGB_ID,
                                      PRGC_ID, PRGD_ID, PRGE_ID, PRGF_ID};

Single or two-line comments should use //. Comments that need more lines should use the pair /* and */. A two-line comment should signify that it is one two-line comment instead of two one-line comments by putting one extra space after the //. Single or two-line comments should start at column 49 if that's possible. Example:
   char buf[SIZE_INFO], number[80];              // 4 should be enough, but don't
                                                 //  be too sensitive to errors
Long comments should use the same indentation as the code that follows it:
   if (deinterleave)
       This is a bit of a hack, i.e., putting the following code in this
       unsigned char *data;
       int size, n = 0, prg = 0, chr = 0;

Preprocessor directives
Preprocessor directives should not be indented. This does not only apply to #include, but to all preprocessor directives.
For #if and #ifdef blocks that are complex or enclose many lines of code the corresponding #else, #elif or #endif should contain a comment that signifies to which #if or #ifdef it belongs. Example:
   #ifdef  __unix__                                // wait 32 milliseconds
     usleep (32000);
   #elif   defined __MSDOS__                       // __unix__
     delay (32);
   #elif   defined __BEOS__                        // __MSDOS__
     snooze (32000);
   #endif                                          // __BEOS__
Standard system header files should be included by specifying the name of the header file between angle brackets. Non-standard header files should be included with the name between double quotes. Example:
   #include <stdio.h>
   #ifdef  __unix__
   #include <unistd.h>
   #include "ucon64.h"

Header files
Header files should be protected against being included multiple times by putting the entire file inside an #ifndef block. Define the constant for which the #ifndef checks inside the #ifndef block. For example, for the file swc.h:
   #ifndef SWC_H
   #define SWC_H
   #endif // SWC_H
Header files should only contain information about their corresponding source file that may be needed by other source files. They should not include information about variables or function definitions that are used only inside the source file.

Platform-specific function calls, variable types and #includes of header files should be put inside #ifdef or #if blocks. For an example see the first code example in the section Preprocessor directives.