OVERRiDE Posted April 18, 2023 Share Posted April 18, 2023 Hi Guys, I've just upgraded to JagStudio 1.11 and am really curious to see what is possible when unleashing the GD filesystem - in theory this can give us virtually unlimited storage space for our games, assuming we are going the digital-only route. Anyway, I have tested the existing demo project "jaguargd" and I noticed that it is not correctly displaying the sample graphic when you press 4 on the dpad - instead, its rendering a brown image, as if the file content is not being read correctly. I have the sample file "!LOGO.JAG" at the root of the SD card filesystem. My SD card is flashed to the most recent bios version which is compliant with the documented version requirements. I've done some further testing with text files, and can confirm that the files are being read from the SD card into RAM correctly, so the paths and pointers are correct. But when I try to load with my own sample graphics ( which have been converted to *bmp.gfxdata ), I am getting the same issue as the sample project - just a brown texture. So curious to hear any feedback, or if anyone else can confirm that the sample project is working correctly for them. Quote Link to comment Share on other sites More sharing options...
Sporadic Posted April 18, 2023 Share Posted April 18, 2023 Someone else did mention a similar issue in testing, but we couldn't replicate it. The jaguargd example works fine on my setup. Could you PM me a zip file of your own test project (not the jaguargd example) and I could try that on my GD. Then we can try and figure out what's happening. Cheers. Quote Link to comment Share on other sites More sharing options...
OVERRiDE Posted April 18, 2023 Author Share Posted April 18, 2023 (edited) Ok so I've been able to isolate this problem, and it is even occurring in the Raptor API example "EX-16 - Jaguar GD Functions", so it seems this is actually an issue with Raptor API GD functionality. There are two ways to run your program on the GameDrive, one method is working and the other is not: If you upload the program over USB via jaggd.exe, everything works correctly. I am able to copy any file type ( text, graphics, sound ) into RAM or ROM and can confirm the file content is correct. If you copy your program to the SD card and then launch it via the JagGD menu, File Reading is corrupted and GFX are not loading into RAM ( or ROM ) correctly I am assuming there is some GD re-initialization that needs to occur to get things to work when you launch from the GD menu. I've tried calling rapGDReset(GD_RESET_NORMAL) at the start of the code, but this seems to reset the entire hardware, not just the GD ( I was assuming our program would remain running in RAM, but this does not seem to be the case ) and the result is just an infinite loop of resetting lol. So I'm not exactly sure how this reset function is intended to be used. And one last note, which indicates that perhaps there is another issue at play, is text files seem to work just fine in both scenarios. So text files (ascii) work fine, but binary files do not work in the 2nd scenario ( and most critical scenario ). Perhaps the encoding is not being preserved, but why only in the 2nd sceario is beyond me. Extract this archive to the root of your SD card then launch gd.rom from the GD menu. The text file can be loaded correctly, but the GFX and Music will not. Next, upload the gd.rom via jaggd.exe and everything works. gd-test.rar Edited April 18, 2023 by OVERRiDE Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted April 20, 2023 Share Posted April 20, 2023 I have confirmed this and let SainT know. 1 Quote Link to comment Share on other sites More sharing options...
OVERRiDE Posted April 25, 2023 Author Share Posted April 25, 2023 (edited) Thanks @CyranoJ. Really hoping this can be patched ( via GD Firmware update or Raptor API ) as the GDFS is basically useless currently, but has so much potential for increased storage space for digital releases Another question I have is regarding the speed of file reads - in my rough profiling, we are getting less than 1MB/sec - is this expected? If so, is this an inherent limit of the GDFS, or is there any room for API optimization? Its hard to believe commercial CD games with FMV are not exceeding this bitrate and they don't seem to have any issues running directly from the GD (granted, when running this way they are not using the File System in the traditional sense, so there may be much less overhead ). I was thinking it would be cool to implement an FMV format similar to MJPEG using the Jags native image format, but with current bitrate throughput I can only squeeze like 3FPS with 240x240 resolution with current API / Firmware, so that is a no-go lol. Edited April 25, 2023 by OVERRiDE Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted April 25, 2023 Share Posted April 25, 2023 15 minutes ago, OVERRiDE said: Its hard to believe commercial CD games with FMV are not exceeding this bitrate The best you can get with the JagCD is about 350 kB/sec, as it's a 2x CD drive. And that's under ideal conditions. 2 Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted August 6, 2023 Share Posted August 6, 2023 I threw my Jaguar in the closet a while back coming back around to things again thanks to some nudging but curious if there has been any movement on this being fixed? Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted August 13, 2023 Share Posted August 13, 2023 Can't be fixed outside of the firmware, so waiting on SainT. Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted January 3 Share Posted January 3 @SainT any chance you could have a quick look at this please? We would love to be able to access endless amounts of assets using the GD. Or is it a bad news scenario that isn’t fixable? Quote Link to comment Share on other sites More sharing options...
SainT Posted April 12 Share Posted April 12 Looking at this now. 3 2 Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted April 12 Share Posted April 12 1 minute ago, SainT said: Looking at this now. Awesome, thanks Saint! 2 Quote Link to comment Share on other sites More sharing options...
SainT Posted April 12 Share Posted April 12 (edited) Ok, figured out what's going on, the GDBIOS is not being correctly initialised from Raptor. Not sure why yet. The bindings on GitHub call GD_Init on installing the GDBIOS. The test ROM above is not doing this. The only thing the init function does currently is to map the FIFO block into memory so it can be read directly for faster data transfers, which is why the data coming in is junk (or just FF in this case) when running from ROM. When running via USB upload it jumps to the code directly and the FIFO is still mapped in. The reason small files worked is that for transfers less than 32 bytes it does a byte by byte copy from the serial FIFO register rather than using the memory mapped FIFO. I'll liaise with @CyranoJ to get this fixed. Edited April 12 by SainT 4 3 Quote Link to comment Share on other sites More sharing options...
OVERRiDE Posted April 14 Author Share Posted April 14 @SainT awesome news! And that certainly explains precisely what I experienced, the text files working was due to the small file size as you explained. I know you and @CyranoJ will get this bug squashed! Thanks again guys! 1 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted April 14 Share Posted April 14 RAPTORGD.O Replace RAPTORGD.O in your RAPTOR/Jagstudio folder with the above file and bish, bash, bosh, all done. 5 2 Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted April 14 Share Posted April 14 Thanks guys, fantastic news! The feeling: 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.