tandy put their sound chip on the 1A interrupt?

[foone@digipres.club]

I finally found the two helper functions they use to get and set vectors!

all the 30 other places I've seen them set/get vectors, they do it manually, but hey, maybe they use the helpers too

[foone@digipres.club]

could also be that this is a compiler-provided bit of code, which is left in because the runtime needs it, or they just didn't eliminate dead code

[foone@digipres.club]

okay I've figured out there's a shared format they're using here. it chunks the file into chunks, which have a 16-bit ID (unique per file, but not globally), an offset, and 16-bit length

[foone@digipres.club]

so like, midisnd.dat will have 12 entries, and the first 11 are 200-500 bytes each, and then the last is 3k.
presumably it's each song and then some config info?

[foone@digipres.club]

cities.dat is very interesting. There's 30 cities in total, but 491 entries in it!

So they must be doing something odd there, that doesn't divide equally. Maybe one city-chunk gives IDs of the others?

[foone@digipres.club]

idea for a test: it's easy to spot which chunk in a city is the image, because it's the biggest. Here's a way to determine if it's looking up by IDs or offsets/indices: swap the IDs of two images

[foone@digipres.club]

darn. turns out you can't just renumber the chunks, because they have to be in increasing order.

so maybe I just need to leave the chunk indexes as is, and instead of moving the entries around, I move where they're pointing?

[foone@digipres.club]

Bingo! I'm in Athens, but I'm seeing the image for Baghdad, and apparently with the Baghdad palette?

So one of these other chunks must be the palette for a city. Or it selects from a selection of palettes? Maybe they've just got a couple defined.

[foone@digipres.club]

okay I figured out the cities.dat IDs:

They're all 1XXYY (in decimal):
XX is the city number (0-29), YY is the sub-chunk-id.

So like:
YY=0: City name
YY=2: City image.

They go between 00 and 22, and not all numbers need to be present.

[foone@digipres.club]

hmm, reading a buffer and then summing all the values of the bytes in it.

suspicious behavior.

[foone@digipres.club]

okay I think it has a very simple 1-byte CRC check on the chunks, which are optionally not run.
I can't make the math work but I'm reasonably sure that's what it is

[kawa@mas.to]

@foone Not with that attitude. If a GBA can do threading and DOS can run JavaScript, surely you can do threading in DOS.

[foone@digipres.club]

@kawa YEAH BUT YOU SHOULDN'T

[kawa@mas.to]

@foone SEE? ATTITUDE PROBLEM!

[foone@digipres.club]

@kawa I'LL PROBLEM YOUR ATTITUDE

[foone@digipres.club]

okay they're using a blit that's UI-aware, so it starts the coordinate system at (1,13). Fun!

[foone@digipres.club]

looking into the blitting code I managed to steal the world map out of RAM

[foone@digipres.club]

ugh. TODO for my eventual Good DOS Debugger:
Instant Video display.
I don't know exactly how DOSBox-X is doing it, but while single-stepping the debugger, the display never updates. I can dump the ram at A000:0000 and see what updated, but not on the screen in DOSBox

[th@social.v.st]

@foone someone alert CIAA (the Cartographers Industry Association of America)

[riley@toot.cat]

@foone Perhaps it only updates an internal SDL canvas, but never throws it on the actual screen.