Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by ggn

  1. Updated Bjl Loader Program

    Bumpety bump Since I'm in the process of adding BJL support to JiFFI I thought I'd get the uploader from this thread for tests. Then I noticed Orion_'s abs enabled version which would suit my purposes better. Just had a look at the code - might I suggest uploading the whole file minus the header (which is $a8 bytes for $601b coff header and $24 bytes for $150 abs header)? Perhaps the header has wrong sizes stored! I'd test if I could, but no PC with parallel cable here! (BTW the BJL uploader for ST that I patched for COFF some time ago does exactly this and works fine)
  2. Hi, the repository has been updated and cleaned up a bit. You're welcome to check it out and report any problems or additions
  3. Another³ Birthday !!!

    This thread needs more happy birthday wishes and MOAR CAKE! Happy birthday monsieur Azrael
  4. 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
  5. 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 .
  6. 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 .
  7. AAAAAAAAAAAaaaaaaahiezhihfdhfhgf !!

    Dear Fredi, from me and all at Reboot
  8. Heh, glad you liked my additions! But next time don't be shy, feel free to suggest stuff
  9. 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: 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?
  10. Cinepak Jiffi?

    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 )
  11. BJL Packer

    Batchception - we need to go deeper!
  12. 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?
  13. BJL Packer

    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 .
  14. 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).
  15. BJL Packer

    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 )
  16. Sinewaves

    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 .
  17. 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?
  18. ARJ Compression for 68k

    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
  19. Burning Eproms

    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 )
  20. Burning Eproms

    Hello, just popping in with a small warning: 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 .
  21. What else ?

    Late wishes for a happy birthday from me
  22. SCPCD-day

    Here, le me post another:
  23. Happy Birthday sh3-rg

    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!
  24. About sprite positioning and video mode

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