AHAHAHAHAHAHAHA

NO REFERENCES, NO CARGO, NO DRINK BREAKS!

#Asspull3X

PCX reader in #Asspull3X Paint. Might add a PCX writer too, but let's get API writing in first.

(warning: you cannot round-trip a PCX without some loss of detail as the palette is irrecoverably changed from 24 to 16 bit.)

A third option regarding the #Asspull3X real time clock is to drop time_t as a register entirely, be it 32 or 64 bit, and replace it with a single pair of index/data registers, both 8 bits, working like your average DS1287 or MC146818 RTC chip:

REG_RTCINDEX = 0x04;
int hours = REG_RTCDATA;

REG_RTCINDEX = 0x0B;
REG_RTCDATA &= RTC_24HR;

Need a time_t value? Calculate one maybe.

Considering the real time clock on the #Asspull3X runs at an offset from the host's reported time and defaults to January 1 1984 (you're supposed to reset it), and considering this is the only 64-bit register on the system... I wonder if that's worth the effort?

GCC actually has to pull in some extra support routines just to let the time functions handle such a large value.

If I make its time_t 32-bit it'll cut its range, but it'll look more contemporary and simplifies the compiled code.

If I read these docs on the #Lemmings level format correctly, you can have up to 114 lemmings in a level, plus up to 32 potentially animated objects, including the gate and exit.

The #Asspull3X supports up to 256 sprite objects at a time.

That sounds like I could use hardware sprites for both lemmings and objects, but I can't really do that, can I? Because potentially each lemming and object can have a different frame and I have only 512 8x8 sprite tiles.

Today I'm overthinking the feasibility of #Lemmings on the #Asspull3X.

For example, I know from the paint project that I can have large off-screen bitmaps and pan them around well enough. But does the A3X offer enough hardware sprites to cover a full lemming army, animated background elements, *and* the cursor, would I need to make them flicker, or render the lemmings in software?

Things like that, y'know?

If I had to describe the #Asspull3X in three words, I'd say... "Atari Super MSX Drive."

"Drive" as in Sega Mega Drive/Genesis, being a 68k system with OPL capability.

"Super" as in Super NES, as it has the better graphics support, but still misses several effects.

"MSX" as in, well, MSX, as it can also function as a PC, with disk drives along with cartridges, with mouse and keyboard, printer, further extensibility, and even MIDI output.

@foone That's the #Asspull3X codepage, not the Felinese conlang.

*This* is the conlang. 👇

Observations on emulating the #Asspull3X on Linux via Wine:

1. Menu item icons are a fuck -- solved by detecting Wine and not setting any.
2. Menus don't pull up until a selection is made. Don't know why, can't fix.
3. Dark mode is broken (see pic). What even is going on there?
4. No sound. Note the empty "MIDI device" list, but PCM is also silent. Is it my VM settings or something more sinister?

Three of these could be fixed by rewriting it to Dear ImGui, but I don't think I will.

Does the #Asspull3X emulator run on something *other* than Windows?

Yes, it turns out Wine has reasonable support for it 🍷

The #Asspull3X can *decode* RLE streams used in its bespoke image format, but I didn't have an *encoder* yet. And I'd need one to save in my paint program.

So I wrote one.

This is the raw result, compared against the original. Decompress, unpack from 4 to 8 bits per pixel... then repack and re-compress.

Any differences would be shown in red, as it did when I accidentally repacked the wrong way around.

#Asspull3X paint program now has fill support.

That pinstripe effect is still there. I should clean that up.

KaBOOM! The #Asspull3X paint program actually sorta-kinda functions like a paint program now!

#Asspull3X paint program progress: even more UI work, but I also hooked up those <- -> buttons underneath the palette.

yey

#Asspull3X

Who can tell me why there's a pinstripe pattern where the menu bar should go?

#Asspull3X

Rate my meshwork. #blender3d #Blender #Asspull3X

Okay so one thing I should probably consider for the built-in file manager on the #Asspull3X is that the text viewer's wrapping function should *not* just break at 80 characters.

That seems pretty damn obvious, really.

Rather, it should *word* wrap. Like Norton Commander's viewer does, really.

Seems like a nice challenge.

Turns out putting #imgui on top of shader-enriched video output is easier than I expected. Still not sure if I should keep #Asspull3X as a Win32 app, or rework it into ImGui for portability, yet throw away all the UI work so far...

Comparatively, the Amiga uses a bunch of pointers to different libraries. "IIntuition->CloseWindow(wind)", to quote a random example, is only *one level of indirection away* from what the #Asspull3X does.

And the A3X? Well, by my count a single "interface->textLibrary->ClearScreen()" call takes... eight instructions, 16 bytes. Load "interface" into A0, grab "textLibrary" from there, then "ClearScreen", then "jsr %a0@".

🧵