Mindsad

Ever heard of bacon bak kwa? Well now you have---that was dinner. I bought 300 g of it some days back to share with my parents, and I just finished the last slice for dinner today.

Well, part of dinner. The other part is a nice Jack Daniel's on the rocks. I know that I said that I had drained off the hard liquor I have, but I still had a bunch of small bottles of heavy stuff lying around, and today felt like the day to break open one of them.

I felt rotten, that's why I was in a drinking sort of mood. The reason of the rottenness feeling is that gut-punch one feels when one realises that the future is really quite bleak if one wants to stand by one's principles. Nothing remains untainted by egoism and its associated consequences. If I really wanted to stick to my principles, I would probably not work ever again.

Hmmmmmmmm... tempting.

But anyway, since the last update, I fixed an issue that I had with the FilePak that I didn't talk about---the inability to store STRING variables. I hacked a string-to-integer-array subroutine to do the save, but it had two issues: it doubled the amount of memory needed, and it made all string data be even lengthed, whether or not they were to begin with.

The solution, as it turned out, was from reading the documentation. All STRING data is stored in the DGROUP segment of the MS-DOS segment convention. And there exists a function that I've never used before, SADD(), that returns the offset of the passed string in it. With that, it was easy enough to whip up a fix to handle STRING directly.

Relatedly, there exists another function, SSEG() in Microsoft BASIC Professional Development System (or what we would call QBX from the IDE or PDS 7.1) exists that returns the segment for a STRING. If, by any chance, I decided to use the PDS 7.1 compiler, I might want to take that into account. It's not likely though---PDS 7.1 does not offer enough useful features for LED2-20 to be worth considering. The ON LOCAL ERROR GOTO ... construct is quite tempting, but ultimately insufficient to justify changing the toolchain to something that heavy. The next thing on my list might be to think about how to handle the far parallax background, or more specifically, how to generate them. The idea here is to start with some wide background image, convert it to the 16-colour EGA palette, cut them up into individual vertical strips, and then use those strips to simulate the slow parallax movement of the background. That ``convert it to the 16-colour EGA palette'' also includes scaling it to 200 px height among other things, and it might require me to break out some other modern tool to get it done---I really don't see a need to write my own damn image parser in QuickBASIC when I can do it easily with Pillow.

I also re-ran the SPEEDTST.COM with no load using the ``long'' option, and came up with 3.7M parrots under maximum single-core speed (corresponding to 5.0 GHz clockspeed with no other load) against 26k parrots using the default 3000 cycles setting.

That's a theoretical multiplier of about 142×, about 20% to 48% faster than when I had VLC running at 2× replay speed and Minecraft running in the background. Nearly 38 years of improvement in single-core processor efficiency, and we're hitting 142× as compared to the 80286 then, or roughly 13% improvement year-on-year. Realistically though, we haven't had much single-core improvements in general since the current trend is to cater to multi-threaded/multi-process environments, i.e. putting more processing cores into the same die, sometimes with deliberate specialisation to also take care of the overall power consumption of the chip. So fun.

In other news, I had some issues with my over-flow auto-sorter in Minecraft. The problem here is that my 5--6 double-chest storage array was going to run out of space for some items (bamboo), and I wanted the excess to overflow over into auto-incineration. So I did the obvious thing of extending out from the original overflow chest into its own auto-sorter for items that I don't mind incinerating, before sending what is left back to the storage chest system for those items.

It didn't work. I don't know why. I'm currently dealing with it by using a manual red-stone switch shunt to bring the excess bamboo down a hopper chain into the incinerator directly. I'm going to debug that and see what's wrong after this post goes live.

Anyway, time to load up on more Jack Daniel's and figure out what's wrong with the over-flow auto-sorter. Till the next update.