DOS/4GW mapping all of the things you'd do on a 16-bit machine into the first megabyte of linear address space is really nice. I have a feeling I'm discovering this information about 30 years too late for it to be of any use, but I have still discovered it.

I just spent a couple of hours typing in a listing from a book and then didn't test it because this laptop has a fresh DOSBox install and I didn't have enough mental capacity left to go and sort out the OpenWatcom paths on it...

Self-inflicted I know, but I can't help but think this would go a lot quicker if I wasn't trying to make a vaguely accurate emulation of early '90s MPEG video.

The heat exhausts my reserves of go significantly faster than a regular day. I should be doing some video editing but... no.

(This may also be me getting a good runup at the idea that one of the shots I want to do requires spending actual money with iStock again)

Also I ran out of registers. A lot. I'm sure this could be planned better by someone who knows what they're doing but I suspect in vintage programming days there would have been a lot of pointing and laughing at how often I need to use the stack and how slow that's going to be.

Show thread

I wonder if there's value in constrained instruction sets and paradigms that force you to think in terms of registers and stack usage to get things done as a teaching language.

I found that what I was doing was a lot more "programming" in terms of solving a problem using a set of tools that was small enough to memorise, rather than searching for the one method in a gigantic framework which would solve the problem for me.

Show thread

16-bit x86 is also an interesting platform to work on. The segmented memory model is a constant pain in the arse. Storing pointers, accessing memory, even making sure a variable reference actually points at the variable rather than some random bit of memory which could be anywhere.

On the other hand, memory-mapped I/O is great. I swear this is the easiest time I've ever had of writing straight to video memory! (Admittedly, 13h chunky mode is easier than most PC graphics modes)

Show thread

I wish I'd done more assembly programming when it was a vaguely current and useful thing to be doing.

It's hopelessly unproductive and slow but I like the way you have this small number of instructions and a bunch of constraints, and have to figure out how to accomplish things with them.

Some people would have things like a "schedule" and a solid idea of what's achievable within given production timescales.

Me, I'll edit for several solid nights in a row and go, "may as well put it live once the HD sign lights up".

youtu.be/3iHfb1lprgI

After a lot of time spent on something that clearly isn't going to be a useful video any time soon, this evening I have finished an exceptionally sweaty recording and sound editing session for something more "normal".

Doesn't need anything technically difficult for the visuals, but it does require gameplay footage from ALL OF THE GAMES. Including some bits which are very close to the end of particular games, where I really hope I still have appropriate save files...

Reaching that mind-wandering part of technical documentation where my brain goes, "the API is written in Go and runs on AWS Lambda. It dislikes spoons, orange vehicles and people called Trevor. It has an unusual fascination with soap. It is possible to make API requests on a Tuesday but for the sake of the development team, please don't. Nobody knows where the API came from or who made it. Some contend that it merely is, and always has been."

Spoilers, Stranger Things 4 

I think they would have been better sticking to 49-minute episodes and being forced to edit out some of the clutter that goes nowhere. It might not have ended up with so many threads to tie up at the conclusion they couldn't write their way out of it, and had to cop out with a "some time later..."

It's starting to feel like one of those things where people are allowed to do whatever they feel like unchallenged, which never ends well.

Show thread

Spoilers, Stranger Things 4 

I was half-expecting them to to build up to a huge, "El burns out her powers reversing time before defeating Vecna" ending, but it was just, "nah, we wrote ourselves into the low point then couldn't figure out the moment of awesomeness required to recover it".

I found the ending of Eddie's character arc extremely unsatisfying. The basketball jocks they'd built up all season were also wasted as nothing more than some generic extra menace with no growth or change.

Show thread

Spoilers, Stranger Things 4 

Watched the final episode this weekend. That was a bit frustrating.

What's the point in having a sodding two hour long episode if you still get 15 minutes from the end and go, "crap, time to go, better pack everything up".

"2 days later" may as well have read, "we couldn't figure how to write our way out of this". It's particularly jarring to skip like that after a series that has been quite baggy and drawn-out in places, thanks to those enormous episode lengths.

I know this because something about my reverse-engineered version breaks this mechanism for certain input parameters, making it instead believe the VGA memory starts somewhere in the middle of the data segment.

This goes very badly when it then proceeds to overwrite the function pointers for all the soundcard handling routines.

(As in, good luck trying to execute what's supposed to be on the screen next timer interrupt. Geoff Crammond's Revs this is not.)

Show thread

TD3 has the most ridiculously convoluted method to get the start address for graphics memory. It uses a jump table of functions which, depending on graphics mode, then loads a value from a reference table into a global variable, which gets used by the various "copy to display" methods.

Graphics memory starts at 0xA0000 on every single adapter the game supports. They could have just used a constant.

I would not have figured this out if I hadn't taken a quick look at Sourcer's disassembly of the executable, because while Sourcer is quite old and misses a lot of things the newer disassemblers and decompilers can do, it is excellent at picking up weird things people did with DOS PCs.

So what was being picked up as '17h' or 'loc_C200' by other disassemblers, Sourcer immediately shoved in an equate called `keybd_flags_1`, rather a useful hint.

Show thread

Vaguely related, one of the things which has been absolutely kicking me in the teeth with this disassembly is the keyboard handler.

I have just worked out what it does.

First, set es (the "extra" segment register) to 0x40. This is equivalent to 0000:0400. On x86 we have memory-mapped I/O, so this is pointing not to actual memory but the "BIOS data area".

It reads memory locations es:17h, es:18h and es:97h - which store flags about the current keyboard state. (Ctrl, Shift, Caps Lock etc.)

Test Drive 3 has the most utterly sociopathic way of accessing memory. Why use an ordinary far pointer when you could pick the location of a random bit of code in the segment you want, subtract the offset of another random bit of code to give a segment-local offset, then add a constant which in theory gets you to the right bit of data providing nothing has changed about the program?

(This might be just A Thing which Microsoft C does. Needs further investigation.)

One trick I've learnt is to get multiple executables of slightly different versions. By disassembling them all and running a diff on the results, I can see which numbers are address references and which are constants.

(Address references will be different for any addresses past the first code difference, whereas constants will generally be the same across multiple versions)

Show thread
Show older
Top Spicy Crew

LGBTQIA+ friendly community. Lots of retro games, bad movies. Keep it supportive, keep it kind.