tandy put their sound chip on the 1A interrupt?

[foone@digipres.club]

ok I ran my dosspin tool to gibberish every byte of the save game file (it's only 102 bytes, so this is easy!) and none of them change where you start. very interesting... I'm guessing either the values are spread out too much for my gibberishing to reach, or you need to modify multiple bytes at once

[foone@digipres.club]

huh, I found a hidden(?) key: if you hold down either shift, it skips all the pauses in the printing. so it goes at MAX CPU SPEED

[foone@digipres.club]

ahh good. it's always fun to find code that looks like:
do{

while(variable!=0);

some one has a custom tick handler that's permutating a global!

[foone@digipres.club]

can't be threading, this is 16-bit DOS. There is no threading.

[re@fuzzies.wtf]

@foone enbies are allowed to commit any crimes they want, i support this /s /lh

[nil@furry.engineer]

@foone but there are interrupts

[foone@digipres.club]

@nil exactly!

[foone@digipres.club]

@re exactly. I can steal what I want!

[munin@infosec.exchange]

@foone

....yeah but what if you wrote your own TSR swap engine :3

[foone@digipres.club]

looking at interrupts, and I think I found a bug.
they set handlers for various CPU errors, but they accidentally set 10 (COPROCESSOR ERROR) twice, instead of the 05 (BOUND check)/10 (COPRPOCESSOR) interrupts they save

someone copy-pasted and missed a bit

[foone@digipres.club]

@munin THEN I DESERVE WHAT I GET

[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.