Data structure of Display in Fate - Gates of Dawn v1.6

[Rangerous the Second]

It's been a real education to begin to learn about Fate's image structure. For starters, I have been trying to discover, decompose, and reconstruct Fate's main display, within the memory structure of WinUAE.

Along the way, I discovered that the Amiga's image structures do not bear that much resemblance to how we store images today.

Summarizing, Fate v1.6 under WinUAE holds the display in memory from 0x459FC through 0x50E73. Within WinUAE debugger (SHIFT-F12), hit F2 to get a clear screen, then type m 459FC F8 to list out the first bit of it.

I have now built an Excel sheet that offers WinUAE debugger command line entries which, when pasted and entered, provide the memory listings to paste back into Excel. Then the Excel formulas build the display from that raw memory data. This wouldn't be all that interesting, because you've already seen what the display looks like, but it does show you, piece by piece, how the display is structured within memory.

Rather than storing its graphics as bit mapped and color coded pixels, like a BMP file, the Amiga instead stores them as layers of one-bit pixels, like leaves stacked on top of one another. I haven't measured it, but it seems that Fate's console should be 320 bits wide by 231 bits high, because Fate uses 5 different layers of 9240 bytes each, with each row comprised of 320 bits (40 bytes).

Layer 1 extends from 0x459FC through 0x47E13
Layer 2 extends from 0x47E14 through 0x4A22B
Layer 3 extends from 0x4A22C through 0x4C643
Layer 4 extends from 0x4C644 through 0x4EA5B
Layer 5 extends from 0x4EA5C through 0x50E73

As an aside, 14,000 bytes of character data (500 for each of 28 characters) begins at 0x50e74, immediately following the display memory.

Back to the display: within each of these display layers, each pixel is represented by only 1 bit. To recover the color value for any given pixel, you have to pick bits from across all 5 layers to concatenate them together at any given pixel location. Each concatenated 5-bit value, 0 through 31, matches one of the 32 color registers in the Denise chip. Those registers map the 5-bit image data to 12-bit color data, which allows the display to show just 32 out of a palette of 4,096 possible colors.

This color map is accessible within WinUAE's debugger by typing the letter e followed by return, on the command line. This lists a number of registers which include COLOR00, COLOR01, COLOR02, ... COLOR31.

Together, the memory listing command (m followed by the hex address) and the register listing command (e) provide all the information you need to reconstruct the display.

As noted, you've already seen the display, but this information becomes more interesting and helpful when you see something interesting in the display and decide to search all of memory for its matching instance.

I'm currently exploring hosting options in order to make spreadsheets, images, and lists available, since I've reached my upload limit. However, my work on web authoring has been unimpressive, so time will tell how this works out.

Until then, I appreciate the opportunity to summarize my findings in this forum. Although I imagine it is much more interesting and exciting to me, I hope it's not too terribly boring for at least a few fellow Grognards.

With the greatest respect,
Rangerous the Second

Edit: This display decoding spreadsheet is available at:
https://drive.google.com/open?id=18-noS ... L14li96-1k

Because conditional formatting was not automatically preserved converting from xlsx to ods, and because it takes a very long time to enter 32 conditional formats, I haven't taken the time to create an ods version of this spreadsheet.

The conversion from Amiga memory to Excel display pushes Excel's abilities somewhat. On my machine with 8 GB of RAM, it takes a few minutes to open properly.