site banner

Friday Fun Thread for October 21, 2022

Be advised; this thread is not for serious in depth discussion of weighty topics (we have a link for that), this thread is not for anything Culture War related. This thread is for Fun. You got jokes? Share 'em. You got silly questions? Ask 'em.

7
Jump in the discussion.

No email address required.

This adlib tracker I'm working on is turning out to be a larger project than I at first intended.

UI programming is a pain in the dick in assembly. Even in humble 80 column mode. I learned the hard way you really want to use definitions for all the screen coordinates of your UI elements. So that was an afternoon's refactoring. Then I split them all off to a definitions file which gets included in the assembly file, just for readability and management's sake.

I did finish the adlib channel configuration page. Lets you change about 20ish settings for the selected channel? Basically everything that is exposed by the registers. I think the actual music composition screen might turn out to be easier, but we'll see. Still thinking through how I want it laid out, and how I'll use what I learned doing the channel configuration screen to do it better.

I did "discover" some interesting uses for a few assembly commands. AAM and AAD, or Ascii Adjust (after) Multiply and Ascii Adjust (before) Division. All the plebian documentation I see says to use these commands only after multiplying two unpacked BCD digits, or before dividing two unpacked BCD digits. In reality, all they functionally do is unpack or pack two BCD digits into a binary byte value. Which is handy if you need to take a byte value that ranges less than 99, and need to display it on the screen. Or accept user input that ranges less than 99, and convert it to a byte value. Which I did a good bit on the channel configuration screen. Lots of values that range 0-15 or 0-63. I'm sure at some point, when more people did assembly, this was well known.

The NuXT I ordered finally showed up today! Put a bunch of old RPGs on it. Ultimas, Might & Magics, Bard's Tales. Also threw Gateway to the Savage Frontier on there, along with Treasures of the Savage Frontier, since I own them and haven't played them yet. And most of those early Gold Box games technically run on a Turbo XT.

In fact, I went through this user collection on Archive.org called goodolddays.net, and they have a massive archive of floppy images. So I've been downloading the ones that look interesting, and throwing them on a used Gotek Floppy Emulator I scored cheap and locally. Even took out the 7 segment panel and replaced it with a fancy OLED screen which shows the actual name of the selected image. That increased it's usability about 1000%.

The only downside is I tried a booter version of Wizardry 1, and it appears it's copy protection rejects the Gotek. I had noticed this even using 86box, where the game only properly launched when it was mounted in an emulated 360k, 5 1/4 floppy drive. I have no idea what the Gotek is doing, but it's mounted in the system as a 3.5" 1.44 MB floppy drive, even though it mounts all sizes of image with no problems. Trying to change the BIOS to a 5.25" 720K drive to "match" the image the Gotek is emulating only breaks things entirely. So oh well. Other booter versions of games have worked with no problems.

I actually have a non-booter version of Wizardry from The Ultimate Wizardry Archives. But it's known, or at least extremely strongly suspected, to be bugged. Many of it's game formula's differ significantly from all other versions of the game. Most obviously, how stats increase or decrease when you level up. The chance for stats to decrease in this version of the game are much higher. Which is rather crippling in an already difficult game. So I'm thinking of going in and hex editing the formulas to correct them. Should be possible with the debug version of dosbox, and setting some memory breakpoints around the character data.

UI programming is a pain in the dick in assembly.

To be fair, programming literally anything is a pain in the dick in assembly.

Yeah, but some things are worse than others.

Right now I'd rank UI Programming as the worst. Although I'm developing a sense for a style that works more formulaically and facilitates changing the layout at will.

Some things I actually find really convenient, thanks to x86's exposed BCD and "string" instructions. Likewise, it's loop and rep instructions.

Then there are the things that simply aren't possible with most platforms today. FM synth is a great way to programmatically create music, and directly programming the registers of an OPL chip is relatively straightforward in assembly. I guess it's not easier than telling Unity or Unreal engine to play an MP3. But if you were trying to build up something from scratch, it's a million times better.

Same thing goes for graphics programming. EGA or VGA aren't that bad. You set some registers, then start writing to memory space. The equivalent "hello world" for DX12 of Vulkan is many times larger and more complex. Which says a lot when you are comparing it to assembly! Once again, there are libraries which dumb it back down. You could use SDL if all you want is to throw pixels up on a screen. And there are always engines like Unity or Unreal. But once again, if you feel the compulsion to build from scratch...