Month: May 2011

I have now figured out how the game resources of Donald Duck’s Playground (DDP) are mapped to the disk and created a tool to extract them. The resource formats are identical to what they are in AGI v2 DOS-based games, except that the SOUND format is different. Also, there might be slight differences in the LOGIC scripts since this game is using the AGI version 2.001. I also started to document the booter games in ScummVM wiki.

The SOUND resource format is actually very straightforward although it is less structured than it is for the later interpreter versions. It consists of varying sized sequences or “rows” of bytes that each end with a zero. These bytes are simply the values that are to be sent to the sound chip in the IBM PCjr (SN76489; three square wave generators and one noise generator). Each row contains the data for all the generators and is fixed length in time. Since all the bytes are supposed to be sent to the same I/O port in the IBM PCjr, there are no restrictions to how they should be ordered (with the exception that some updates need two bytes and the chip expects them to come in order). In fact, a row often contains only one zero, which means no data is sent to the sound chip, effectively skipping the row.

I suspect this is the format for AGI v1 SOUND resources as well. I will update the wiki about the SOUND resource format once I have verified this.

What comes to the reimplementation, I have added the detection for this game to ScummVM’s AGI engine. I have also implemented the player for SOUND resources. The game works but there are problems in some parts because ScummVM does not yet support some AGI v2.001 specific things. Will come back to this at some later time.

Generally, once the BIOS, the start-up program of PC, has performed its initialization procedures and found a bootable device, in this case a floppy disk drive, it loads the first sector of a floppy to the address 0000:7C00 and transfers execution to that address (or any other address that points to the same physical location, I guess, which would mean that you cannot be sure of the exact Code Segment at this point). After this, the boot sector program loads the main program into memory, typically by using INT 13H to read sectors from disk, and finally begins to execute the main program.

I expected that the one 512-byte boot sector would be enough to load the main program into memory, but alas, all of the three games seem to be wastefully loading an intermediate program from another sector (or even sectors) to do the loading! By the way, the data on the disk is ordered so that the “head” is flipped after a track (9 sectors) is read. The disk format is 5.25-inch, 40-track, double-density (40 tracks, 2 heads, 9 sectors per track) with the total capacity of 360KB. There are probably a lot of details to be found about the loader program, some of them maybe explaining why it spans multiple sectors, but I figured it is easier to just let the loader do its job, and when the game is running use the DosBox debugger to dump the one 64KB segment, containing the whole main interpreter program, to a file.

A tested algorithm to find the AGI core with pointer tables to instruction handlers is to do the following in DosBox debugger: (1) Set breakpoints to memory locations that contain INT 13H (used to load data from disk), (2) in the game move to another room so that new data needs to be loaded, firing a breakpoint, and (3) step through, possibly using breakpoints, until the core is found.