[Firmware updates for the original JagSD/GD]

20 hours ago, SainT said:

Yes, I've not posted it publicly as some of those with new units tend to ignore the instructions given to them and just download and try to use the old firmware and ask me why it fails. I'm trying to avoid this for the small percentage with the old carts. PM'd you a link.

That's understandable. Thanks for the link.

3 hours ago, str0m said:

I have one of the SD carts, "waves", i have the firmware with the initial CD support, think that's probably the most recent?

I think I currently have the firmware that was released around April, this one seems to be from October.

[Firmware updates for the original JagSD/GD]

Are there still going to be firmware updates for the original JagSD units?

 

I realised I hadn't updated my firmware in a while so I was looking on the website for it but I can't see it anymore.

[Command Line Tools]

I imagine using something like libusb will probably hide most of the USB magic and make it portable to any other platform that supports that, rather than natively try and support say, Linux and OS X's different USB frameworks.

 

Typing a $ isn't hard, it's just that the shell will try and interpolate a matching environment variable, so either escape it with a \ or quote it with single quotes so there's no interpolation. Having said that, I also prefer 0x notation to denote hexadecimal numbers ?

[Jaguar GD compatibility testing and questions]

On 6/14/2020 at 4:05 PM, Mr.T said:

Not being able to view the MRQ files on a PC makes it a bit trickier - hopefully someone can make a simple GUI for MRQ creation so you can view and change individual elements (change one screenshot, fix a spelling mistake etc.) individually on PC, instead of having to write out all that command line info each time?

I wrote an alternative MRQ tool (primarily because I'm not a Windows user) which does have the ability to view and edit existing files as well as create them.

 

There's a screencast showing the basic usage, feel free to give it a go: https://github.com/bodgit/retrohq

[MRQ File Format]

Yeah, I haven't run Windows for over 20 years which is what prompted me to write my own implementation. Golang makes it super easy to cross compile so it was just a reasonable set of OS/CPU combinations. Apologies to any Solaris owners!

[MRQ File Format]

Thanks for the explanation guys, very helpful. I've put my code up here: https://github.com/bodgit/retrohq

 

It's a small Golang library that does the hard work with a small CLI that wraps it. There are precompiled binaries for Linux, OS X and Windows. 

[MRQ File Format]

3 hours ago, SainT said:

Flags are --

 

Bit 1-2: EEPROM bye size (0:128, 1:256/512, 2:1024/2048)

What about the home-brew games that have both of these EEPROM bits set? Here's the relevant bytes from the various .mrq files in the Reboot pack:

 

00000060  00 00 00 00 32 30 31 32  00 06 00 00 00 00 00 00  |....2012........|

00000060  00 00 00 00 32 30 31 31  00 00 00 00 00 00 00 00  |....2011........| (128 byte size)

00000060  00 00 00 00 32 30 31 33  00 06 00 00 00 00 00 00  |....2013........|

00000060  00 00 00 00 32 30 31 33  00 06 00 00 00 00 00 00  |....2013........|

00000060  00 00 00 00 32 30 31 32  00 06 00 00 00 00 00 00  |....2012........|

00000060  00 00 00 00 32 30 31 32  00 06 00 00 00 00 00 00  |....2012........|

00000060  00 00 00 00 32 30 30 39  00 00 00 00 00 00 00 00  |....2009........| (128 byte size)

00000060  00 00 00 00 32 30 31 30  00 04 00 00 00 00 00 00  |....2010........| (1024/2048 byte size)

 

Is that 0x06 a valid value?

[MRQ File Format]

Pinging @SainT. Any help with those EEPROM flags much appreciated.

[MRQ File Format]

I think I have figured most of it out with a bit of trial and error:

• Offset 0: 4 bytes 'M', 'Q', 0, 0 (some sort of version here?)
• Offset 4: Title, 48 bytes zero padded
• Offset 52: Developer, 24 bytes zero padded
• Offset 76: Publisher, 24 bytes zero padded
• Offset 100: Year, 4 bytes zero padded (if necessary)
• Offset 104: Some sort of flag bit field, 16-bit value
• Offset 106: Load address, 32-bit value
• Offset 110: Exec address, 32-bit value
• Offset 114: Box art image, 88x124 pixels as 16-bit values, packed as RRRRRBBBBBGGGGGG
• Offset 21938: Screenshot image, 88x56 pixels, as above

Which gets you to 31794 bytes. All multi-byte values are interpreted as big endian.

 

The only part I'm unsure about is the flag bit field starting at 104. Setting a custom load/exec address seems to toggle 0x1 which makes sense, but setting the EEPROM to 128 bytes (0) doesn't seem to change anything, but setting it to 256/512 bytes (1) or 1024/2048 bytes (2) toggles 0x2 or 0x4 respectively in the flags. I can also pass the undocumented value 3 which toggles 0x6 in the flags (i.e. a combination of the two). Larger values seem to loop back around like the value is AND'd with 0x3 and then shifted left by one bit.

 

Some of the home-brew titles have this 0x6 value (HMS Raptor was one I found) so either the EEPROM values are actually 0 = no EEPROM, 1, 2, 3 are the various sizes, or it is 0, 1, 2 for the various sizes (and every game implicitly has at least a 128 byte EEPROM) in which case what does passing 3 signify given it's not mentioned in the tool help?

[MRQ File Format]

Hello,

 

I was wondering if it's possible to get a breakdown of the MRQ file format so I could write my own tooling to generate them. I can see all of the various strings are at the head of the file but it would be good to know how the box and screen images are packed.