ggn

Hi,

the repository has been updated and cleaned up a bit. You're welcome to check it out and report any problems or additions

This thread needs more happy birthday wishes and MOAR CAKE!

Happy birthday monsieur Azrael

- Since a ROM file wastes a flash on skunkboards (or any other flash carts), could you include an option to create a COFF version or similar?

 

Possible, but I'm not sure how to coax a COFF file out of the VBCC compiler system. I could just rewrite it to be 100% assembler which would allow a multitude of different output formats. The blank space in the padding is full of 0xFFs which is the default state of any modern erased flash device so any good programming algorithm would just kip 16 bit words of 0xFFFF in the source image.

Well Zerosquare beat me to the universal header, so here's how I create COFF files in JiFFI: I take my binary file, figure out load and run addresses. Then strip off any headers at the front and slap the attached file instead. In that header, offset $24 has the load address and offset $28 has the run address. And presto, you've created a valid COFF! (disclaimer: this is the result of my hackery, I've never read any docs on the subject... BUT for 2 years no I had 0 complaints about it so I assume it's ok!)

coffheader.bin

Cool stuff .

A couple of suggestions, if I may (feel free to ignore them at will!):

- Could you include the universal ROM header at the start of the ROM? It can help people identify that it's a ROM a lot.

- Since a ROM file wastes a flash on skunkboards (or any other flash carts), could you include an option to create a COFF version or similar?

- Are you using dithering when converting from 24bpp to 16? (I had some experience of as I was involved in a product that displayed 16bpp bitmaps and they looked better with dithering during conversion).

I can understand that this is a quick util for your convenience hacked up quick, so again ignore my suggestions if you want to move on .

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 .

Dear Fredi,

from me and all at Reboot

BJL Packer integration ?

I'll consider it

yeahh ! \o/

this version fix all the stuff I wanted to see in JiFFi !

and even more, heuristics detection is an ossom idea !

 

nice job

Heh, glad you liked my additions! But next time don't be shy, feel free to suggest stuff

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?

Right, since my name has been mentioned here, I suppose I'd better give an answer on my behalf! (apologies to sh3 for having to post as my PR representative ).

All CD tools we have made for the Jaguar so far have had a very weird development cycle. At the beginning only sh3 had a JagCD unit, which meant that to test the encrypter program, both sh3 and me had to be online and available (after all we live only live 3500km apart ). I would fiddle with the code a bit, then send it to sh3, he'd run it locally and tell me how far the program got or what colour the background has turned to. This took 2 days of back-and-forth until we managed to get it working. Then it was CJ's turn with the ULS CD and loader which took a few days (and quite a few coaster CDs) to make.

At the time of writing, I still don't have a JagCD. CJ does but has zero interest in doing something with Cinepak. So the only way for me to do anything would be to have someone testing what I write on the fly and give me precise feedback (sh3 is really short for time at the moment. Although that should change soon, it doesn't mean we'll both be available - I also have my projects I want to dig into and so does sh3!). Also have a stack of CDs ready for burning and of course allowing for JagCD read errors from CDs it doesn't fancy reading, even if the code should work in theory. Also, I'm not sure if I'll have to transfer whole Cinepak'ed .cdi images over the internet for testing, which would mean lots of MBs transfered and of course a very slow code/test/crash/debug cycle (a real motivation killer). So, personally, until I get hold of a working JagCD and the inspiration to do it, I'll have to pass on the idea of making an automatic Cinepak creator program.

(that said, I've heard that offering people $500 cash prizes in open competitions can do wonders for Jaguar productivity, so you never know )

Nothing prevents you from calling a batch file from another batch file

Batchception - we need to go deeper!

Hmm, seems to me that we were magically teleported back to 1995, where a 300 files directory listing seemed huuuuuge to people! Sorry guys, but your suggestions would apply for a site that had 20000 files or so. We're talking about the Jaguar here - it's not like we're up to our necks in releases . Every binary appears 5-6 times in there, it's the same file with different extension, so if you use this magic thing called a mouse wheel you can actually scroll by the list pretty quick.

Again, let me stress that this is meant as a dumping ground for homebrews (damn, I really hate that word, I'll stick to PD methinks ). It was supposed to be the back end and we were to make a front end that would have lots of neat features and info etc etc. But we simply lack the time to do it. So consider this as a "We give up for the moment! But instead of letting things go to waste, give the files to the people" .

As for the group/project/version/colour of underwear they were wearing when released/phase of the moon/exchange rate of euro to dollar/files/ scheme, what can I say... again I find it too much! Also as a counter example, consider the root directory of the FTP. Most of the binaries are marked as "unknown" atm for me, so I'd have to create directories like "Unknown group 1/what probably is the name of the project/version approximately/" and place the files there? How is anyone going to find anything there? We're back again to "needs front end", which won't happen any time soon from us. And if anyone is inspired and does make a front end, linking to this FTP (which won't bother me one bit), which would be easier: linking to files in the root directory or linking to a structure of 5-6 subdirectories?

Honestly, unless people help identifying the files and removing the dupes etc, that's the way the FTP structure is going to stay. Sorry, but I don't want to spend hours after hours doing something that might be unusable or pleases a couple of people. It's better to have all the files in 1 dir and hitting control-f to find something in my humble opinion.

So, anyone fancy helping identifying files?

It is possible to "pass through" parameters in batch files. Here's an example.

 

If you save the following piece of code to test.bat :

prog1 %1 %1.tmp

prog2 %2 %3 %4 %5 %6 %7 %8 %9 %1.tmp

del %1.tmp

 

and then execute "test file.bin option1 option2 option3", here's what happens :

- "prog1 test.bin test.bin.tmp" is executed

- "prog2 option1 option2 option3 test.bin.tmp" is executed

- "test.bin.tmp" is deleted

 

If prog1 is your packer, and prog2 your BJL uploader, then you've made a BJL uploader that compresses programs before sending them, and still allows you to use the same options as the original uploader

Yes, because calling "bjlpack gametoupload.bjl -n -8 -b 0x10000" and having to remember it each time is much easier than "bjlpack gametoupload.bjl" and stuffing the bjl upload parameters in the .bat file .

but maybe giving all the version of a file is a bit too much ? (especially when cdi takes that much space)

As Jiffi is here to do the job, maybe keep the original file and let the user use jiffi to convert the file in desired format. (I doubt for example that a lots of people will use the jagserver files)

 

Because it begins to get a bit messy in the folder :/

Well, the initial plan was to have a website front-end with a table that could pack each binary's links in one line. But we're thinking of doing that for a couple of years now, which is safe to assume that it won't happen any time soon!

And well, using an FTP client like Filezilla or Total Commander it doesn't look too cluttered to me. Things will improve though as more files are moved to folders (just need to identify the author of each one).

Great effort Orion_! This of course will be handy for the people that own Skunkboards and get 7k/s transfer speeds .

Also, adding the command to upload the binary using the bjl loader in the .bat files will make this totally automatic! (I guess this might not work out of the box because of the various parameters the bjl uploader takes, but it can be left as an exercise to the user )

Hello,

Some of you might be aware of this FTP location: ftp://ftp.untergrund.net/users/ggn/Jag%20PD%20collection/. Historically it was created as a stress test of JiFFI and Virtual Jaguar, and of course as a sort of final solution for me to avoid searching for Jaguar releases all over the Internet (not to mention having to figure out how to run them! I'm sure most of you will have really bad experiences).

Today I took another shot at updating it and uploading stuff that weren't there before. As I'm writing this binaries are still being uploaded. I also thought of organising the files a bit in folders as the directory was getting too chaotic to make any sense of. So, this post/thread was created to announce this, and also as a call to help. Here are some of my thoughts for the future of that FTP:

1. All files are present in all formats that are possible. .ROM files are headerless or with header, abs/coff/bjl/bin/uls/etc are converted using JiFFI to all other formats.
2. I've tried to rename the files to have a sensible filename instead of the one that was officially given by its creator. If this sounds confusing for you and you don't want to download dupes to mix with other collections, don't use this FTP! Of course I'll take renaming suggestions under consideration and apply them if they make sense. (short version: I'm a reasonable man, but don't come asking for TOSEC naming scheme - you will be ignored!)
3. Found any duplicates? Please report them and I'll sort it out.
4. Found any file(s) in wrong place(s)? Again, report them!
5. Found any wrongly named files? Don't keep it to yourself!
6. Found something that's not on the FTP? You know how the 'Reply' button works!
7. Can you identify any of the binaries in the root folder and tell me their authors? Tell me and I'll probably make a folder so they can be placed neatly inside.
8. Are you an author and want me to add some files not present? Send them in!
9. Any suggestions in general? Speak your mind!

Another point I'd like to make is that you do not have to download the whole archive file for file, even for the collection! For the non-ROMs, grabbing the abs/coff file is more than sufficient for modern emulators and homebrew carts like the Skunkboard. At a stretch you can download the .CDI files if you fancy burning a CD and you can't run JiFFI (or don't have it handy!).

That's all I can think of for the time being. Note that I might not respond to any replies to this thread immediately (or take action in a JiFFI, har har!) but I'll do my best to keep the FTP tidy.

Finally, many thanks to www.untergrund.net for the gracious hosting!

Just curious if someone can give me the break down on using sinewaves for object position.

Usually it's not very practical to store the object's position using polar coordinates AKA rho,theta (ρ,θ) or at a stretch of the definition, sine waves. What is rather useful though is to use polar coordinates for expressing the movement vector or speed for X and Y axes in layman's terms.

Let's assume that you have an object at (100,200) and you want it to move with a speed of 5 pixels/frame 30 degrees north-east. The pair (5 pix/frame,30°) is exactly a representation of the movement vector in polar coordinates. If we were to add this every frame to the coordinates of the object (which are expressed in the Cartesian system), we'd get the desired motion. Since our object's position is expressed in Cartesian coordinates and we can't change the way the hardware stores coordinates, it follows that we have to convert the movement vector to the Cartesian system as well. We can do this relatively easy using the 2 following formulas:

Δx = r * cos(θ) = 5 * cos(30°)

Δy = r * sin(θ) = 5 * sin(30°)

If we were to add this pair of equations to our coordinates we'd get the coordinates of the object for the new frame, thus:

new_x= Δx + 100 = 5 * cos(30°) + 100

new_y= Δy + 100 = 5 * sin(30°) + 200

One final thing to notice is that actual Cartesian coordinates have the x axis pointing right and the y pointing up, but screen coordinates have the y axis pointing down (the pair of coordinates (0,0) is at the top left corner instead of the bottom left because of this), so if we were to add the above, the object would head to the bottom right instead of top right. So we have to adjust the 2nd equation like so:

new_y= -5 * sin(30°) + 200

And all will be well.

Apologies if that wasn't what you asked for and it's common knowledge for you, but this is what I understood you were asking in the first sentence of your question. Of course, if this is what you asked for and something's not clear in my answer, feel free to ask further .

Another gift from Glenn Bruner : technical documents about the MPEG 1 decoding cartridge

Good thing you mentioned the archive's name, because otherwise with source code names such as SUCK.S and PUSSY.S one might get the wrong idea

Seriously, was that thing ever made and/or works?

(ggn can you post this here ? thanks !)

Sure . Thanks for making this more automated process and for the extraction tool!

I'd also like to take this opportunity to say that ARJ modes 4 and 7 don't exist on the normal ARJ (maybe mode 4 but I think not). They were coded by Hans Wessels AKA Mr Ni! of the TOS crew. So I think it's only fair that if any gentlemen use these 2 packing methods, kindly credit Hans for his amazing work .

mode4new.s

Hello,

I suppose I'd better share the results of my experiments here since they seem to work .

Yesterday I took a shot at updating JiFFI since OMF sent us a report that some ROMs he generated from homebrew titles using it wouldn't boot when written to EPROMs (of course it was verified working on Skunkboards, but its BIOS has some set-up code from what I remember). At first I just wanted to bolt on the code that Matthias posted in this thread and be done with it, but it seemed to me that most of it wasn't needed. After consulting CJ quickly, I took a deep breath and added this on top of my code:

move.w  #$2700,sr           ; kill all interrupts
move.w  #$7fff,$f0004e      ; no VI

and sent it to OMF for testing. He tried burning half a dozen titles (maybe more) and he had 100% success! So, for anyone wanting to do something similar, the above 2 instructions as well as your copy loop will do the trick of copying ROM to RAM and executing without worries! (although you could always use JiFFI and not give it another thought )

Hello, just popping in with a small warning:

                  move.l a0,usp

If you assemble using smac, this will get wrongly assembled as

                  move.l a0,sp

which means your stack will point at $0, and your program might crash if you're not setting the stack afterwards! I found this the hard way a couple of years back .

Late wishes for a happy birthday from me

Here, le me post another:

One of those spare heads (which are Kryten's btw) is celebrating his birthday today

Also, happy poulpe birthday to the author of:

Have some cake guys!

This whole thing reminds me of Videl init a little (especially since the OP and Videl share some variables' names)