Low-hanging fruit (in the JTree)

18 Mar 2025
Computer Stuff

I’ve written a ton of little Swing-based Java (and in recent years, Kotlin) tools in my life, but I haven’t used tree views much. So I’m probably twenty years late to the game, but I just learned what you get when you add an empty (!) JTree component to your GUI:

Ravioli and bananas, included in the standard runtime – isn’t that adorable?

And no, that’s not a relict of an ancient JDK version I’m using. At the time of writing, it’s still included in the current OpenJDK…

Checkbox alert!

14 Mar 2025
Computer Stuff

All of a sudden, my shopping list wanted more attention than usual:

Marmalade and potatoes were not only checked, but dangerously checked! (Because, as we all know, yellow = danger!)

This little webapp is using the default Bootstrap style, which in turn uses the browser’s default checkbox color, blue. I was surprised by this change to yellow, as I haven’t touched the code in years.

After some unfruitful googling (“Chrome checkbox default color yellow” etc. only yields results where someone wants to change their checkbox colors), I noticed something: That yellow/orange is similar to my system-wide accent color! And sure enough, Chrome now uses the configured accent color for certain elements:

Hmm… bold choice. But also weird and irritating – the only other place where Chrome uses system colors is the 1-pixel thin window border. (The window title bar which would normally also display the system’s accent color is overwritten by custom code to render the browser tabs.)

Not sure if I like this change. But hey, at least my checkboxes haven’t turned into circles… yet. :)

Ecce puntatore

4 Mar 2025
Amiga Style

My work VM froze and I was staring at the mouse cursor for too long. Mouse pointers used to be a thing of beauty. And symmetrical! :)

Edit: Whoops, “ecce homo” is Latin, of course, “puntatore” is Italian. My modern-day Latin is a bit rusty, so… Ecce index?

Prototyping with native 68k code

25 Feb 2025
Amiga Style
Demo Scene

For my current Amiga project, I had a little prototyping chain like this:

Write a code module in JavaScript (table generator, display code, etc.)
Use <canvas> & co. for visualization
Use data structures similar to the target
Port the working prototype to 68k assembly
Test, debug, sprinkle in some logging, debug more, get angry, etc.

The turnaround times with an HTML prototype are nice, but the disconnect of prototype code and real code sucks. Why not write in 68k assembly from the start? With the help of a 68000 CPU emulator, I tried this:

Write a code module in 68k assembly
Write a simulation shim with a custom visualization or data table
Assemble, simulate, update visualization

Writing a custom code tester for each module seems convoluted, but the turnaround times are instant, and there is no need to write the code twice. Invoking vasm when you press CTRL+S is really fast, directly running the assembled binary as well. Here’s a texture generator in action:

Running a code simulation is as easy as:

// run "vasmm68k_mot -quiet -Fbin -o tx.bin tx.asm", then:

val STACK   = 0x00800
val CODE    = 0x10000
val SINTAB  = 0x60000
val TEXTURE = 0x70000

val mem = MemorySpace(512)
loadFileIntoMemory(File("sintab.bin"), mem, SINTAB)
loadFileIntoMemory(File("tx.bin"), mem, CODE)

val cpu = MC68000()
cpu.setAddressSpace(mem)
cpu.setAddrRegisterLong(0, TEXTURE)
cpu.setAddrRegisterLong(7, STACK)
cpu.reset()
cpu.pc = CODE

val addressAfterCode = CODE + File("tx.bin").length()
while (cpu.pc < addressAfterCode) {
    cpu.execute()
}

Of course writing the prototyping and design tools natively as well would be even cooler… But so far I’m quite happy, I quickly found some subtle irregularities, and texture code testing was a breeze.

Shout-out to Tony Headford for m68k!