Q1: Who develops uCON64?

Q2: How can I take part?

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

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

Q5: How do I create a patch with Subversion?

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 - 2021 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 - 2005 Jan-Erik Karlsson
Maintainer of the Amiga ports.

2003 - 2004 JohnDie
Also contributed several SNES-related features like Pro Fighter and Super Flash support and Super Wild Card transfer code improvements (e.g. dumping special chip cartridges).


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
http://www.komkon.org/fms/		 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
http://www.playoffline.com		 NES emulator for Game Boy
Gilligan / DC-S show info for Neogeo Pocket
LaC N64 makesram
Jeff Frohwein info AT devrs.com
http://www.devrs.com		 Flash Advance Linker transfer code
Omar Kilani gbautil AT aurore.net Game Boy Advance SRAM patching and "crash patching" code
Caz turok2 AT currantbun.com
http://www.infernal.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
http://www.snes9x.com		 old interleave detection and old deinterleave code (SNES)
Gary Henderson gary AT snes9x.com
http://www.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
http://nsrt.nachsoftware.org/files.php		 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
http://www.winimage.com/zLibDll/minizip.html		 crypt.h, ioapi.c, ioapi.h, 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
http://www.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
http://www.classicgaming.com/launchtool		 some info from his Genesis ROM format document
Ulrich Hecht uli AT emulinks.de
http://www.emulinks.de/software.html		 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
http://www.retrodev.com		 Genesis/Sega CD transfer code
Cyan Helkaraxe cyan AT emulationzone.org
http://www.emulationzone.org/projects/cyan/docs		 Cyan's Megadrive ROM copier transfer code
Parasyte Support for remaining N64 CIC algorithms (6101, 6103, and 6106)
Revenant d AT revenant1.net
http://revenant1.net		 Super UFO Pro 8 SD header and USB communication information and code from his GitHub Roswell repository.

and others...

Q2: How can I take part?
A: Install Subversion and checkout the latest version from https://sourceforge.net/p/ucon64/svn/. 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 Subversion as an anonymous user?
A: For read-only access you must have Subversion installed. To download the uCON64 source, type:
  svn checkout svn://svn.code.sf.net/p/ucon64/svn/trunk/ucon64/ ucon64
The uCON64 source will then be downloaded to the directory ./ucon64. If you want to get up to date with the newest source code later, enter the directory ucon64 and type:
  svn update
To see what other options Subversion has type:
  svn help

Q4: How do I connect to the Subversion repository as developer with read/write access?
A: For read/write access you must have Subversion and SSH installed. To download the source code, type:
  svn checkout --username=<username> svn+ssh://<username>@svn.code.sf.net/p/ucon64/svn/trunk/ucon64/ ucon64
<enter password at prompt>
If you never logged on to svn.code.sf.net before you may get a message (from SSH) like:
  The authenticity of host 'svn.code.sf.net (216.34.181.157)' can't be established.
  ECDSA key fingerprint is SHA256:FeVkoYYBjuQzb5QVAgm3BkmeN5TTgL2qfmqz9tCPRL4.
  Are you sure you want to continue connecting (yes/no)?
Type yes (the whole word). Now all files will be downloaded. Afterwards you can simply cd into the top level directory and continue by typing commands like:
  svn update
  svn commit
  svn add <file>
  svn delete --force <file>
To see what other options Subversion has type:
  svn help

Q5: How do I create a patch with Subversion?
A: Just type:
  svn diff >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 non-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.
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?
A:

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

Indentation
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 (...)
     {
       ...
     }
   else
     {
       ...
     }
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:
   int
   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");
         break;
       default:
         puts ("greater than 4\n");
         break;
       }

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

Functions
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
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};

Comment
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  __MSDOS__                               // wait 32 milliseconds
     delay (32);
     ...
   #elif   defined __unix__                        // __MSDOS__
     usleep (32000);
     ...
   #elif   defined __BEOS__                        // __unix__
     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>
   #endif
   #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.

Portability
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.