August 2026
A new CPU feature
August 28 machine chombimon
The Chombimon prototype can now disassemble and assemble programs!
Coming next will be ability to run programs, whose simplest form is jumping to an address with an uninitialized CPU. In the original design, the kernel returned by pushing io::cpu_event_ip and io::cpu_event_fp onto the program's own stack. But what if you want SP to be zero, like a cold boot? Then the stack could not be used this way.
To handle this scenario, we've introduced with context which modifies pop ip so that it also restores SP and flags. This enables an event handler to fully restore the CPU state.
Some other refinements came with this change: WF and SF are now cleared as part of event invocation, to avoid interfering with the handler's code. The invocation timing cost was reduced from 5 cycles to 3 cycles to better reflect the underlying sequence of actions. When an instruction modifies a conventional register (IP, SP, GP, or FP), the CPU now defers the change until after all operands have been read; as a result, if a fault occurs, the event handler sees a more consistent CPU state. Opcode $01 now serves as a no operation (NOP) instruction with mnemonic if always.
Palix theme color indexes
August 21 machine chombimon
We made a minor change to Palix's default theme set, so that unmapped indexes now default to color #0 (Clear) instead of nonexistent system palette indexes (which rendered as black). The docs clarify this using a new term virtual theme color indexes.
This improvement arose from thinking about Chombimon's bitmap font. Based on the Hybrix framework font, it has a well-known ROM address in case a debugged program wants to use it. Since the monitor console can display in front of the debugged program's output, its font benefits from black outlines like TV subtitles. With this theme improvement, the outlines are clear by default, essentially identical to the Hybrix framework's font. The monitor "opts-in" to enabling outlines by writing to the theme table.
Chombimon is coming
August 18 chombimon
In the tradition of Commodore 64 machine language monitors, we've started work on an new project called Chombimon! It's a Hybrix ROM cartridge that will allow you to disassemble, assemble, and debug assembly language programs using the virtual machine itself. Besides being a fun demo, Chombimon should provide rigorous validation of many advanced event handler mechanics.
Chiptune file format improvements
August 16 jamdac
The Jamdac chiptune file format was improved, in anticipation of a future feature called "hosted" chiptunes (where a song player program can load chiptunes into arbitrary locations in RAM). Besides introducing a new work block concept and more robust way of specifying the song index to play, the documentation itself got many clarifications.
Chombit Chess
August 8 chess roms
We've posted the initial release of Chombit Chess in the gallery!
We've also created a new GitHub repo writenrun/hybrix-chess with source code for the game and chess_engine API. The computer "robot" plays using Micro-Max 3.2, whose fully explanation can be found on H.G. Muller's chess pages. The sprite artwork was created by ZaniPixels.
Backlog fixes
August 6 language designer
A collection of small fixes from the backlog:
- Fixed a small memory leak in
list<t>.clear(). - Pretty-printer improvements for: array elements, comma alignment when a line wraps, and new
constscenarios. - Designer fixes for: renaming of sounds, the "Sort Clips" button, and validation errors updating your user nickname
- A subclass may now redeclare a constant declared by its base class.
This last bullet is a consequence of a rule that was already documented but not fully implemented: constants are namespace members, so unlike member variables and member functions, they are not inherited. Internally the compiler had been storing them alongside the inherited members, which meant a subclass could not declare a constant whose name was already used by its base class.
What's it useful for? We're considering to change chess_engine::name to be a constant, so that engine names can go into a data table without having to create an instance of each class. For example:
class my_chess_engine extends chess_engine
const name is "My Chess Engine 1.0"
end class
...but if you extend better_chess_engine from my_chess_engine, then better_chess_engine::name should be a different string.
New repos on GitHub
August 5 framework
The writenrun/hybrix-framework and writenrun/hybrix-vscode-extension repositories have moved from GitLab to GitHub. Coming next, an open source repository for the chess source code!