bodgit

That's understandable. Thanks for the link. I think I currently have the firmware that was released around April, this one seems to be from October.

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.

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 ?

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

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!

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.

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?

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

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?

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.