tandy put their sound chip on the 1A interrupt?

[ongion@mendeddrum.org]

@foone not sure if you could use it for older programs, but have you ever used Time Travel Debugging?

[foone@digipres.club]

GOT YOU, YOU SON OF A BITCH! I FOUND YOU.

[foone@digipres.club]

@Ongion I've not, no. It sounds awesome, but sadly it doesn't seem it's usable for my usual ancient-software-reversing tasks

[foone@digipres.club]

it's in a function I already found, temporarily named "blit_related".

I guess they don't decode the image until RIGHT before it needs to go up on the screen!

[foone@digipres.club]

if definitely decompresses and then blits the image as two parts, which aren't evenly sized, and it starts from the bottom

[foone@digipres.club]

I think they're just trying to keep their RAM usage down by not having both halves in memory at once

[rakslice@mastodon.social]

@foone this sounds like a job for whatever scripting the debugger supports?

[foone@digipres.club]

@rakslice
new side project: add scripting to this debugger

[foone@digipres.club]

wait is this image format vertically interlaced!?

[foone@digipres.club]

It loads the half-width version, then a few functions later, it's been replaced with a full-width version.
Strange!

[foone@digipres.club]

wait no, the colors are wrong... I bet I'm seeing it decompress the binary, but that's using the full width of the bytes. it then gets expanded out to a 16-color image.

[foone@digipres.club]

well the good news is that I think I've found the decompress_image function. the bad news is that now I have to reverse engineer it

[foone@digipres.club]

it's currently doing the obvious thing for a decompressor to do:
write the byte 04 every 69 bytes

[foone@digipres.club]

oh sweet jesus, that's the left two pixels of the image.
it's loading the image vertically!

at least it's top to bottom.

[foone@digipres.club]

yeah, doom did that too, but Doom was a 2.5D image that had to do pseudo-raycasting.

THIS GAME DOES NOT

[lethal_guitar@mastodon.social]

@foone it's the most efficient way to render images in planar EGA/VGA video modes. So clearly that's what you need to use for a game that's mostly static screens

[foone@digipres.club]

@lethal_guitar yeah. I guess it's faster to draw, but given that it's static scenes... The disk access is gonna take longer!

[foone@digipres.club]

it allocates a 1024 byte buffer, then makes a pointer to the end of it, minus -0x42?

why would you need a link to the end of a new, freshly cleared buffer, minus 62?

[foone@digipres.club]

I think the memory allocation system here is that every malloc returns 2 extra bytes, which is a pointer to the previous block.
unless it's an odd number, in which case it's a free block. and pointer to the previous block, once you make it even again

[foone@digipres.club]

I hate dealing with the internals of memory allocation systems. I prefer to leave that to smarter people than me