tandy put their sound chip on the 1A interrupt?

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

[foone@digipres.club]

found a suspicious array, which goes:
[
(-1,0),
(-1,1),
(0,1),
(1,1),
(1,0),
(1,-1),
(0, -1),
(-1,-1),
(0,0)
]

POP QUIZ: why does the font renderer need this array? how are they being "lazy" with this array?

[foone@digipres.club]

there's also this code in the for-loop that steps through this array:

if index==8:
color=white
else:
color=black

[foone@digipres.club]

@riley could be. I may have to see if I can hack it so that stepping the debugger tails the main window to update somehow

[foone@digipres.club]

@th nice

[rappet@chaos.social]

@foone to draw the black shadow around the map?

[dividuum@chaos.social]

@foone „outlining by overdrawing“. I may or may not have used this technique in the past

[foone@digipres.club]

@rappet Nope. Remember, it's in the font renderer

[foone@digipres.club]

@dividuum bingo!

[foone@digipres.club]

@dividuum got it:

they're drawing the font 9 times, offset in each of the 8 directions, and in black. then they draw it in white, with no offset.

It's a pixel-outliner! By drawing their pixel font offset in each direction, they get a black outline on their font.

[riley@toot.cat]

@foone I've never gotten around to looking into how DOSBox actually does it, but from my last foray into SDL, I recall it had some weird ideas about graphics updates due to the path dependency of how it implemented multiple-buffering. On classic PC during ordinary operations, this might tie into the VGA's frame refresh interrupt; during human-stepping debugging, obviously, the target program just can't have access to all the frame refreshes, and something in DOSBox's emulation architecture might be doing something clever about it that just happens to break things.

Obviously, DOSBox's idea of how frame refresh works doesn't have to have anything to do with actual target-visible interrupts, but it might potentially give you a bit of information to let the software think it has a CGA, not a VGA. CGA, IIRC, didn't have support for proper frame interrupt, and a different synchronisation mechanism (status register polling?) might fail in a different, and perhaps illuminating, way.

[riley@toot.cat]

@foone I can't quite remember which way MCGA would have fallen, either. It was kind of a halfway between CGA and (a subset of) VGA.

[foone@digipres.club]

The Answer to the DRM questions for Where in the world is Carmen Sandiego? Enhanced (DOS, 1990) are, in no particular order:

23
Kent
dragon
calcium
1796
Warren
revenue
1792
Willard
1937
Crater
Tanzania
Hartford
Duluth
London
Gem
Silent
squeaker

[foone@digipres.club]

if ((0x80 >> ((byte)local_4 & 7) &
(int)(char)*(byte *)((int)((int *)param_1 + 1) + (local_4 >> 3))) != 0) {

COULD YOU USE SOME MORE CASTS MAYBE?

[foone@digipres.club]

oh it's because ghidra's near/far pointer support is shit.

I had param2 defined as a byte*32 and it was casting it to a byte* before using it

[foone@digipres.club]

if I define it as byte* and let the calling convention implicitly define it as 32bit, it doesn't do the cast