There are approximately 5 formats per system (not counting disk images), which gives us about 40 formats to document...
If format is well-known, just put a link to a spec or a free program that can read it. Altho a summary, and eventually complete description wouldn't harm either.
If there is a better place to document a format, consider first using that place.
All DOS formats are known at this point. They are documented in the DOS Game Modding Wiki.
Format is very close to DOS, with some alterations happening 0x8CA, and a result of 1 extra byte. Also, big-endian WORDs.
https://github.com/lclevy/ADFlib
http://segaretro.org/BIN - Raw binary dump of the game cart.
Nothing to see here.
64x64x4 bytes, starting at 0x1AA8E. The indexes are the same as in the DOS version.
Small extraction utility: https://pastebin.com/2wjHAC34 .
Worldmap (and combatmap) tiles seem to be compressed. It's very likely, that the algorithm is http://segaretro.org/Nemesis_compression
Note: There is an LGPL library https://sourceforge.net/projects/genesiscomp/ that can uncompress it.
However, nothing is confirmed, no offsets are known, etc.
http://segaretro.org/YM2612
There is no uniform format, so code that pulls the YM2612 registers must be found. No offsets are known as of now.
Note: There are two popular formats to represent YM2612 rips - GYM and VGM. VGM is a general-purpose chiptune format, which is not of particular interest to this project, GYMs however are much closer to what actual raw music looks like in the ROM. In either case, making in-memory representation of YM2612 music follow one of those format wouldn't harm. Just saying.
This one is interesting. The whole game state is packed into a 57-byte string. Some kind of cypher is applied making it harder to crack. Nothing else is known at this point.
http://www.mjmwired.net/kernel/Documentation/filesystems/hfs.txt
Mac filesystems allowed each file to have 2 "forks" - "data" (for arbitary raw binary) and "resource" (for structured MAC-defined datatypes).
The game kept all of it's data in the resource fork. So, this can be seen as grouping in regards to that platform.
"Resource fork" reading is a solved problem as part of librsrc of hfsutils.
http://www.mars.org/home/rob/proj/hfs/
Note: as of 0.0.2, librsrc (and libhfs) are bundled with openkb.
Some graphics were kept in Mac PICT format. The format is said to be hard to parse, as it consisted of "commands" to MAC display API - "QuickDraw". Emulating the whole of QuickDraw is likely an unpleasant task, but the good news is, the game probably uses only one command and that is "plot bitmap", which would be easy to do.
No particulars are known at that point.
Some other graphics are apparently kept in a different format. Not much is known.
All formats in one table.
Known Well-known Tools Implemented ZIP Generic archive [x] [x] [x] [ ] C64 Disk Image [x] [x] [x] [ ] C64 Graphics [ ] [ ] [ ] [ ] C64 Sounds [ ] [ ] [ ] [ ] C64 Saves [ ] [ ] [ ] [ ] C64 World Data [ ] [ ] [ ] [ ] AII Disk Image [x] [x] [x] [ ] AII Graphics [ ] [ ] [ ] [ ] AII Sounds [ ] [ ] [ ] [ ] AII Saves [ ] [ ] [ ] [ ] AII World Data [ ] [ ] [ ] [ ] DOS Disk Image [x] [x] [x] [ ] DOS Grouping [x] [ ] [ ] [x] DOS Graphics [x] [ ] [ ] [x] DOS Sounds [x] [ ] [ ] [x] DOS Saves [x] [ ] [ ] [x] DOS World Data [x] [ ] [ ] [x] AMI Disk Image [x] [x] [x] [ ] AMI Graphics [ ] [ ] [ ] [ ] AMI Sounds [ ] [ ] [ ] [ ] AMI Saves [x] [ ] [ ] [ ] AMI World Data [x] [ ] [ ] [x] MAC Disk Image [x] [x] [x] [ ] MAC Grouping (RSRC) [x] [x] [x] [ ] MAC Graphics A [ ] [x] [ ] [ ] MAC Graphics B [ ] [ ] [ ] [ ] MAC Sounds [ ] [ ] [ ] [ ] MD ROM Image [x] [x] [x] [x] MD Graphics A [ ] [ ] [ ] [ ] MD Graphics B [ ] [ ] [ ] [ ] MD Music [ ] [ ] [ ] [ ] MD Saves (password) [ ] [ ] [ ] [ ] MD World Data [ ] [ ] [ ] [ ] PC98 Disk Image [x] [x] [x] [ ] PC98 Grouping [ ] [ ] [ ] [ ] PC98 Graphics [ ] [ ] [ ] [ ] PC98 Music/Sounds [ ] [ ] [ ] [ ] PC98 World Data [ ] [ ] [ ] [ ] PC98 Saves [ ] [ ] [ ] [ ] FMT CD Image (iso) [x] [x] [x] [ ] FMT Grouping [ ] [ ] [ ] [ ] FMT Graphics [ ] [ ] [ ] [ ] FMT Music/Sounds [ ] [ ] [ ] [ ] FMT World Data [ ] [ ] [ ] [ ] FMT Saves [ ] [ ] [ ] [ ] * "Known" means format was understood / or was already well-known. * "Well-known" refers to IT community at large. * "Tools" are third-party open-source tools that can read it. * "Implemented" denotes if that format is part of openkb codebase. ZIP is a file archival format, that has nothing to do with King's Bounty. However, since most files are distributed in that way, it would be nice to get zip-reading into openkb. NOTE: Some additional formats might arise, some might get squashed.