Jump to content

new jaguar homebrew tool - JiFFI by GGN of Reboot


Recommended Posts

Another Jagware release :)


JiFFI is a tool for windows & Atari 16/32 by GGN that lets you convert between Jaguar homebrew formats and also to ROM & CD images. Read below for more info from the JiFFI doc:


Q: What it's all about?


A: In case you haven't figured it out yet, this is a program to convert between the various homebrew formats of the Atari Jaguar. More specifically:

- COFF/ABS (mac/aln and smac/sln)

- BIN/BJL (headerless, popular because of the BJL mod for the Jaguar)

- Jaguar Server (v2 and v3, special header produced by ST assemblers mostly)

- ULS (the phenomenally easy CD creator for homebrews from Reboot!)

- ROM (read below for more info)


Q: Why make such a program anyway?


A: Well, there are lots of reasons. Off the top of our heads:

- sh3 wanted to flash 2 homebrew titles on his Skunkboard and use it without lugging a pc with him to flash the games on the spot. To achieve this, GGN invented a (tiny) semi-automatic method to create a ROM file that booted the titles. We just thought it'd be a neat little program and expanded it further.

- We can't think of anything similar from what we've seen so far.

- With a few simple clicks, our collection increased 5-fold :lol:


There are thoughts for further development of this (complete Jaguar binary file management tool - let us know if you'd find this extra functionality useful or have any suggestions)


visit reboot.atari.org for more infos & download

Link to comment
Share on other sites

Looks like it could prove quite useful.


What does it do with the tables of debugging symbols in some of those formats? I know some people prefer to release things closed source, and a tool to help ensure you don't accidentally ship a symbol list with your compiled binary would probably be useful.

Link to comment
Share on other sites

Wow, someone actually found it useful? Thanks :)


Tyrant: As it stands, the symbol table is copied verbatim across formats. I pondered a bit about including such a feature, but decided against it.

Firstly, it'd require that I had a better look at the COFF format, which for the time being I don't have the time to.

Secondly, I feel that the programmer is responsible for everything he/she releases. It's much easier and safer to have a switch in the makefile (or build script) that turns debugging symbols on and off than me stampeding into the file removing stuff :).

Thirdly, I don't like making utils that have every feature including the kitchen sink. As it is, it's just some simple code to do simple format conversions. If I started adding stuff I didn't thought of before I starting coding, it'd potentially make the program kludgy and buggy.


Thanks for the feedback though! If such a tool is required by people I might sit down and code it, but as it is I can't justify including it in JiFFI :)

Link to comment
Share on other sites

Thanks for the feedback though! If such a tool is required by people I might sit down and code it, but as it is I can't justify including it in JiFFI :)

No that's fine, I agree with all three of your reasons, the third of which is very much in tune with my own thinking on tools.

Link to comment
Share on other sites

  • 1 year later...

Ok, here's the result of me messing out with the code for a few hours: JiFFI v1.3 is out.


Here's the full changelog:

  • Some minor UI fixes:

    • When ROM mode is enabled in undetected binaries, disable the unapplicable output buttons
    • Some typos corrected
    • - Switching from ROM to BJL in "Treat undetected as" now enables and disables the appropriate output check boxes
    • - Potential crash when the about music was not found
    • - Newer style buttons now included (tested in Windows 7). Make sure jiffi.exe.manifest is in the same directory JiFFI resides.
  • Output directory logic was slightly changed. Now the user can specify a default output directory instead of it being the same as the input directory. For this, a new check box was introduced to the user interface: "Generate output files in the source directory". This is on by default in order to mimic the pre-1.3 behaviour. When this box is unchecked then the "Output path" button is enabled and the user can then select the output directory.
  • Configuration file. This is created when JiFFI exits and saves the output path and the state of the "Generate output files in the source directory". If a valid configuration file is found (jiffi.cnf) in the same directory JiFFI resides when it's run, then it is read and parsed.
  • An "Overwrite all files" button was added (but not enabled by default). This simply suppresses warning messages when a destination file exists. Like the label of the check box says, use with CAUTION!
  • Starting with this version JiFFI introduces a new experimental algorithm to detect binaries. Some games released in ROM format can actually be converted to homebrew formats as coff, bjl etc. The new detection algorithm uses heuristics to try to detect this and extract the binary for conversion to other formats. At the time of writing the algorithm is in early stages and might give out false positives. If this happens please get in touch with us! It will generally get better with future versions of JiFFI.
  • Command line switches have been added, so JiFFI can now be added to a developer's build script, or can be used for batch conversion. The switches are:

    • -i Input filename. If you omit the path, JiFFI will assume the path it resides.
    • -o Output path. If omitted, JiFFI will assume the input file's path
    • -load Load address. If omitted, JiFFI will assume $4000 (unless the binary's format is known. In which case any value passed will be ignored.)
    • -run Run address. Ditto with Load address.
    • -rom Output a ROM file.
    • -bjl Output a BJL file (if possible).
    • -coff Output a COFF file (if possible).
    • -jagr2 Output a Jaguar server v2 file (if possible).
    • -jagr3 Output a Jaguar server v3 file (if possible).
    • -uls Output a ULS .cdi file (if possible).
    • -romh Output a headerless ROM file (if possible).
    • -j64 Output a J64 file (if possible).
    • -all Output all the above output formats
    • -treat-as-rom Treat undetected binaries as ROM (when applicable)
    • -overwrite Do not ask when destination file exists.
    Commands can be entered in any order. Note that if the input file is detected as a ROM, only three valid ouput formats are available. Also note that for this version no output is printed to the console, so any error messages are displayed as dialog boxes. This will hopefully be fixed in a later version.

    Some examples:

    jiffi -i c:\binaries\input.bin -o c:\output -load 4000 -run 5000 -bjl -coff -rom

    will open c:\binaries\input.bin, assume load and run addresses of 4000 and 5000 (however, if the file is detected as COFF, Jaguar server, ULS, JiFFI ROM or a plain ROM, these switches will be ignored), and then write BJL, COFF and JiFFI ROM files in c:\output

    jiffi -all -i testfile.ext -overwrite

    will open testfile.ext which must reside in the same folder JiFFI is run, assume the same directory for output, produce all possible output files and overwrite any existing file with the same name as those created.


Get it from the usual place and as always, report any bugs you might encounter!




PS: I'm mostly out of ideas on what to add to JiFFI, except one last: BJL and Skunkboard support, i.e. flash or upload the binaries directly without the need for conversion and of course if it's at all possible. Any thoughts on this?

Link to comment
Share on other sites

I'm guessing your ROM->BJL conversion is just detecting ROMs that start out by copying themselves into ram and then executing from there?


In theory there are probably some games that are compiled for cart-space but could fit into RAM... but then if they weren't designed to be relocatable or location independent, it's going to be a really hard job relocating them and most likely not worth the effort.

Link to comment
Share on other sites

I'm guessing your ROM->BJL conversion is just detecting ROMs that start out by copying themselves into ram and then executing from there?


In theory there are probably some games that are compiled for cart-space but could fit into RAM... but then if they weren't designed to be relocatable or location independent, it's going to be a really hard job relocating them and most likely not worth the effort.


Quite so. Also I imagine there are some games that the first thing they do is to copy a portion of themselves to ram and jumping there, leaving the rest of the data in ROM. With more advanced analysis one could detect up to what address the copy routine is copying and see if after that the ROM just contain zeros. And it's because it is getting rather complicated and I honestly spent 2-3 hours adding those features to JiFFI I thought I'd not spend too much time on it and release. Consider this as a toy feature that isn't too likely to be developed further :).

Link to comment
Share on other sites

  • 1 month later...

Well, since v1.3 was released, I was tinkering with JiFFI on and off in my spare time and now it's time for another release: v1.4 is out and here's the changelog:


  • Bug fixes:

    • Output dir in some cases could be blank when the user clicked "create".
    • All main form buttons are disabled when the user clicks "create" until everything is finished.
    • File size limits enforced: a binary loaded to RAM (such as COFF or BJL) can't be bigger than 2080768 bytes and a ROM can't be bigger than 6MB.
    • Small bug in the ROM detection code removed (would give false ROM positives of a random image).
  • When started from command line and run adress=0 and load address<>0, then run address is assumed equal to load address.
  • Conversion/creation routines rewritten. Noticable speed increase in ULS CD image creation.
  • Most of the homebrew titles and ROMs are now recognised by JiFFI because the input file's CRC32 is calculated and checked against a database of known titles. Many thanks to Shamus for allowing the use of his CRC32 table from Virtual Jaguar :).
  • Patches support. JiFFI gives the user the option to modify known titles it recognises with patches. For the time being only 3 patches are available (infinite lives for Tempest 2000, rotary menu enabled on Tempest 2000 from the get go, steering patch for Checkered Flag) but the framework exists now for any others that surface. Note that for the time being patched images are not recognissed by JiFFI as they don't exist in its CRC32 table.

    When a file is open and recognised and there are patches for it, then the button "Title extra options" is enabled and there the user can select which patches to apply. Note that for the patches to take effect, either a new file has to be created (using the "create file(s)" button) or it has to be sent to the Jaguar via Sunkboard or BJL. The source file is never modified.

  • JiFFI now supports uploading the binary directly to a Skunkboard connected to the machine. Harmless Lion's jcp.exe is called with the right parameters depending on what the user requires. Some examples:

    • Flashing a ROM.
    • Uploading a homebrew.
    • Uploading a homebrew as ROM (converted on the fly by JiFFI and then uploaded).
    • Applying patches to a ROM and then flashing it (again, you don't need to create any file, conversion is done on the fly).
    Prior to uploading/flashing, JiFFI can send a command to the Skunkboard to reset the Jaguar. This is enabled by the respective check box next to the "send to Jaguar via Skunkboard" button.

    As Harmless Lion has released everything Skunkboard related openly to the public, I have taken the liberty of including jcp.exe bundled inside JiFFI's archive. If this is not cool, contact me and I'll remove it. In any case keep jcp.exe in the folder JiFFI.Exe resides for the process to work. Finally, it is assumed that the Skunkboard driver is installed and working properly and the Skunkboard is connected to the PC and the Jaguar running prior to hitting "send" in JiFFI.

  • - JiFFI now supports uploading homebrews via Zerosquare's patched Lo_inp. This is included in the archive with permission from Zerosquare. You can switch on the 8bit uploader or turn off the switch command (similar to -n switch in lo_inp.exe). It is assumed that Lo_inp.exe and inpout32.dll are both inside the directory JiFFI.Exe resides.


v1.4 is probably going to be the last major update of this program, only bug fixes and additions to the CRC32 and patch tables are now planned. This program has come a long way till its humble v1.0 release and more or less every feature we (Reboot) have discussed about has been implemented. We do feel it's doing more than enough as is :).

Link to comment
Share on other sites

  • 2 weeks later...

I tried to upload a BJL binary using JiFFi and when it started lo_inp, the system just hang..

I had to ... Reboot :D

You hax0red my system don't you !!!111oneone1!!


Maybe it's a 64bits inpout32.dll problem ?

You should check here for a 64bitsable version:



Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...