ggn
-
Posts
172 -
Joined
-
Last visited
-
Days Won
1
Posts posted by ggn
-
-
Hi,
when I open JiFFI to load a file to the Skunk, I hit the Source File button at the top, navigate to the file and select it. Then, hit the Send to Jaguar via Skunkboard button. A message pops up, "Please note that flashing a ROM will permanently erase your Skunkboard's bank. Press Yes only if you're SURE you understand this!"
Not sure I fully understand. If the sequence I posted to load a file is correct, I should be able to proceed without frying anything, right? The urgency of the message makes it sound like I'm going to wipe the Skunk and render it useless or something.
The message simply means that it will upload the file as a ROM file. This means that it will overwrite whatever's written in the flash chip, which means one could lose work - see it as a "are you sure you want to flash your skunkboard?". Anyway, that was included as courtesy, no harm done to the skunkboard whatsoever
-
Why are the gpu in main functions missing?
-
No direct relation to Jaguar, but Silly Venture close doors and release a lot of great Atari things, go to Dhs Silly Venture release
GT
People say there were 2 Jaguar releases there, so it's relevant
-
Happy birthday Nick!
-
Ok, here's a copy/paste from the readme file, just grab the ROM from our website and have fun!
Jaguar Hockey Legends 2013 (JHL13)----------------------------------
by Fredifredo of Jagware (ROM file analysing, experimenting, roster updating, testing)
and GGN of Reboot (editor programming, minor ROM file analysis)
About
-----
JHL13 is a hack of the very famous unreleased Jaguar game Brett Hull Hockey. This version features:
- Up to 32 players for teams
- new graphs
- Player Stats for 2011-12 season
- Hockey Legends players
- about 800 players with personal stats
- development started in January 2012, NHL Rosters updated up to 13th April 2013
- last player added: Jean-Gabriel Pageau of Ottawa
As most people know the game is playable but not 100% (there are some known bugs that can crash the game for example). What we did was maintain the compatibility while stretching the game engine as much as we could.
A huge chunk of work was done by Fredifredo alone, with a hex editor: he had to decipher a lot of tables and values, then make some changes to the ROM, uploading it to Skunkboard, testing... This was done a LOT of times until the game's patterns were deciphered.
Near the end of 2012, Fredi announced his ROM to Jagware and GGN started making an editor to speed up the process of editing a team. In the process, the team rosters were enhanced (originally it wasn't possible to add more players to one team, and a replaced player's name could not be bigger than the original one), a BPEG injector was developed (so you can replace a lot of the game's assets) and some other bits. The editor, as like with this ROM, is available from http://reboot.atari.org.
In closing, we hope you enjoy this release and stay tuned for more!
-
-
-
-
-
-
-
-
Poulpe birthday!
-
Last couple of months have been busy for Reboot, so here's a small recap of what's been released:
qUaKe, the qUICK uTIL aLLOWING kOLOSSAL eXHIBITIONS is a simple picture display viewer that combines 640x480 pictures. They are BPEG packed so lots can fit in a single 2 or 4mb ROM. Full source code and generator program are available, so there's no excuse - you can all create your custom shows now!
rmac and rln is a continuation of Landon Dyer and Alan Pratt's MADMAC assembler/ALN linker and Subqmod's smac/sln suite. On one hand running dosbox to assemble code isn't productive, and on the other hand we found a few bugs in smac/sln and it was a chore working around them. So, with Shamus (of Virtualjaguar fame) leading the attempt and quite a few people chipping in, we're trying to make a fast and reliable Jaguar assembler for modern machines!
Tripper: to quote the Atariage release thread:
Can 3 minutes and 34 seconds of audio and 23 320x240x256 colour pictures be compressed into a 4MB ROM? After a couple of days of fiddling around, the answer is "yes"!We were really deeply touched that a song has been written specifically about the Atari Jaguar (by Tripper Getem here), so we figured that the best we could do was to put it in a ROM and juxtapose some pictures to depict the song's lyrics. We used the ADPCM CODEC for the audio, and we think it's a good compromise for compression vs quality.
But wait, it gets better! Not only we want to share the resulting ROM with you (attached in this post), we also went ahead and released the source code for it, so everyone can make a ROM with the song of their liking and pictures of their own!
So feel free to grab the ROM and enjoy this unique piece of music!
(P.S. the timings are spot-on on real machines. For emulators YMMV!)
-
Sorry for delaying my reply so much - busy busy busy lately!
Since zerosquare's experiments confirm that the palettes are not exactly linear, I'll change strategies. Thanks to everyone here and on IRC for the suggestions and brainstorming
. -
Oops, people replied
. I'm sorry but I've been busy with other parts of the tool so I didn't notice...Now then...
What I'd do is work on 8 bit values for R, G and B (24BPP) until you absolutely need to convert them to 16BPP mode then weight them accordingly (in a final pass). Are stepr, stepg, stepb floating point variables in your code?Yup that's what I do.
maybe it's because Green is 0-63 where as Red/Blue are 0-31.For my palettes I personally keep 24bits colors and convert them on Jaguar in 16bits using a little 68k routine
Not an option here I'm afraid, a pre-computed palette is required.
maybe it's because Green is 0-63 where as Red/Blue are 0-31.I suggested this but maybe he'll listen if it's coming from someone like you rather than me
Well, I used to write code-that-does-everything-in-one-line like " col = (Shl&(Round(r1 + stepr * l / 8) And 255, 8 + 3) And $f800) + (Shl&(Round(b1 + stepb * l / 8) And 255, 3 + 3) And $7c0) + (Round(g1 + stepg * l / 4) And $3f)"but I find out that sometimes it led to strange behavior (missing parenthesis or compiler wrong interpretation)
Now I write a step each line, and then I can track the value after each computation and verify that I did everything right
just a suggestion %)
Yeah I know, I'm against franken-code like this, at the beginning it was a really simple line, but I kept adding stuff to it to see if it worked (as a proof-of-concept). I'll probably revisit that chunk of code tomorrow and make it less horrible!
Thanks for the tips, all (also on IRC)! Finally, for reference, here's a sample output for the r,g,b values using my routine (left) and the reference palette (right). I'll have another look tomorrow.
0 39 15 0 39 15 0 36 14 0 37 14 0 34 13 0 33 12 0 32 12 0 31 11 0 30 11 0 29 09 0 28 10 0 27 08 0 26 9 0 25 07 0 24 8 0 23 06 0 22 7 0 21 05 0 19 6 0 19 04 0 17 5 0 17 03 0 15 4 0 15 02 0 13 3 0 13 02 0 11 2 0 11 01 0 9 1 0 9 01
-
Hi,
I'm working on a "small" tool for the jaguar that's just about ready, apart from the following: I want to be able to create 16-colour gradients in paletted mode (5-6-5 RGB), from one palette entry (grad1) to another (grad2). Because I wanted an easy way for the user to pick colours, I used the Windows built-in col selector which is 32-bit, to select grad1 and grad2. I keep grad1 and grad2 32bit internally and when it's time to generate the gradients, I convert them down to 16bit. Here's the (ugly) code that does both the conversion and gradient creation (with some redundant crap removed):
r1 = grad1 And $ff : r4 = grad4 And $ff g1 = Shr%(grad1, 8) And $ff : g4 = Shr%(grad4, 8) And $ff b1 = Shr%(grad1, 16) And $ff : b4 = Shr%(grad4, 16) And $ff col = (Shl&(r1, 8) And $f800) + (Shl&(b1, 3) And $7c0) + (Shr&(g1, 2)) 'write beginning gradient (1) stepr = (r4 - r1) / 15 : stepg = (g4 - g1) / 15 : stepb = (b4 - b1) / 15 'calculate steps For l = 1 To 14 col = (Shl&(Round(r1 + stepr * l / 8) And 255, 8 + 3) And $f800) + (Shl&(Round(b1 + stepb * l / 8) And 255, 3 + 3) And $7c0) + (Round(g1 + stepg * l / 4) And $3f) 'write gradients 2-14 Next l col = (Shl&(r4, 8) And $f800) + (Shl&(b4, 3) And $7c0) + (Shr&(g4, 2)) 'write final gradient (15)
(so the code calculates the steps for r,g,b from the 8bit coefficients of grad1,grad4 and then creates the gradients by adding the step values to grad1's values, and then shifts them into place and masks them).
This nearly works, but there are some errors that are really visible on pure grey gradients; the green component seems to not keep in sync with the red and green, so some ugly stuff are being shown instead of shades of gray. From some reference palettes I have, I seem to be either spot-on or +/-1 when creating my palettes.
Anyone had any experiences with this? The only thing I wanted to try was to calculate the gradients using 16bit mode (5R,6G,5B) but I don't think that would change things much. Any input is appreciated!
-
Awesome release
-
I'll let mr Schulz do the talking:
-
Just out of curiosity I had a quick peek at the 68000UM and found the following ways to reset the machine:
- Double bus error (bus error when the corresponding vector will also cause a bus error)
-
move.l 0.w,sp move.l 4.w,-(sp) rts
(registers must be zeroed I guess)
- Issue a RESET instruction The RESET instruction does not cause a reset exception; it asserts the RESET signal to reset external devices, which allows the software to reset the system to a known state and continue processing with the next instruction.
(possible in conjunction with the above)
- Errr I dunno, I got bored searching around . Run a ppera patch - it should sort itself out
-
-
one must also send some cake!
So, happy +1 man! All the best
-
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).
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
. - Bug fixes:
-
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.
CAREFUL: IT DOESN'T WORK !!I thought I had a bug yesterday in my program, but it was my new version of lo_inp that wasn't working, it seems not to transfer the whole program and datas are missing at the end !
I don't know why, maybe if someone find where I did a mistake, the code I added is at the end of the file in the function relocate.
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)
Demo in Javascript !!!
in Miscellaneous
Posted
Fuck JS - name says all