Jump to content

Recommended Posts

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.

  • Like 1

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

'MQ' is the magic number for identification followed by 2 byte version. Current is 0.

 

Flags are --

 

Bit 0 : Custom load

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

 

Bit 0 must be set for the load and exec address to be used.

 

The rest is correct. :)

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
11 hours ago, bodgit said:

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?

 

Hmm, interesting, that's not currently used. I have a memory about it being used to indicate FLASH memory as used on the memory track, but that's not been implemented yet.

 

Share this post


Link to post
Share on other sites

Could be a leave over from when the original reboot games were released on cd and used the memory track to save?

 

  • Like 1

Share this post


Link to post
Share on other sites

Yeah, that does sounds sotra familiar... it was a while ago now. :)

Share this post


Link to post
Share on other sites

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. 

  • Like 1

Share this post


Link to post
Share on other sites

There's also an existing official Windows binary here --

 

 

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...