Hardware development is always a dialogue with the "metal" through code. While testing various FPGA subsystems for the Aleste LX, many assembly tests had to be written. Their number grew, code duplicated, and their logic differed. The question arose: how to organize this chaos?

Thus, an idea was born that seemed almost absurd at the time — to write a BIOS for a machine that wasn't even fully operational yet. To create a single hub for all low-level operations.

The Philosophical Choice: Revolution or Pragmatism?

At the start, there were many ideas, including borrowing elegant principles from the Plan 9 OS. However, a lack of time and the desire to keep things simple led to a paradoxical solution.

It was necessary to look to the origins. The original Aleste 520EX had a seemingly crude but ingeniously simple principle: the ROM contained the CPC software and a small bootloader — the BIOS itself. This loader could pull everything else from the disk: BDOS, COMMAND.COM, drivers. That is, only a tiny piece of code in the ROM was stable and immutable, while the entire system was dynamic, living on the disk.

This approach seemed ideal for conditions where time and energy were in short supply. It was a pragmatic foundation to build upon.

The Development Environment as a System

The Aleste developer's disk contained a compiler and all system source code. If you needed to add a function to the graphics driver or BDOS, you made the changes and recompiled the dependencies. This approach fits perfectly at the initial stage and might even remain the primary one. The plan can always be "crystallized" into a more finished user platform. This software environment is called Aleste LX.

The main tool is z88dk, which works with a driver layer and compiles code starting from address C000h.

Architectural Possibilities: 4 MB per Slot is Room for Maneuver

Now for the most interesting part. The challenge is to decide how to properly organize the BIOS memory structure. The fact is, in the third slot where it resides, there is 4 MB of memory available. That's a vast amount, and there's no need to think about total scarcity.

This opens up intriguing possibilities. Theoretically, each driver could have its own page or even several. For example, the graphics output driver for each video mode could place its data and code in a separate 16-KB page, while maintaining a common jump table (jumptable) for uniform calls. Drivers could operate without overlap, living in isolated spaces.

The main question now is not "how to squeeze in," but how to ensure architectural simplicity and elegance within such expanse.

Two main starting paths are envisioned:

1. Page 3 (C000h and above) — constant. This holds the jumptable and all the code for calling driver functions. Page 0 is switchable, containing interrupt vectors and the code of the currently active driver.
2. The opposite: Page 0 is the permanent kernel with vectors. Page 3 is mutable, loaded on demand.

The final decision on how to best utilize this wealth is yet to be found in the process.

The System Skeleton: What Exists Now

This week, the skeleton — the system core — was assembled. A small main C file and a set of drivers, which includes:

• Graphics (Video) Driver
• Sound Driver
• NVS (Non-Volatile Storage) Driver
• Network Driver
• Keyboard Driver
• System Information Driver
• Memory Manager
• Interrupt and Timer Driver
• File System Driver

This is a raw skeleton that needs testing and debugging. But the key point is that it can be easily changed and rebuilt in the spirit of Aleste.

The New Boot Order

Originally, in the Aleste, the CPC software would find its ROM on startup and run it. Now the approach is different: the Aleste LX BIOS always starts first. It performs the necessary setup and then, if needed, loads the Amstrad CPC ROM and transfers control to it.

What's important: slots 0 and 1 are reserved for Amstrad only by "convention." In native mode, all slots (0, 1, 2) are identical. Different software environments can be run in them. For example, MSX DOS for development tools in one, and also MSX but for running target applications in another.

Conclusion: The Tool That Made It Possible

It's fair to say that one would hardly undertake such a task solo without the existence of modern AI tools. They have become indispensable assistants, allowing one to quickly "glue" cohesive pieces of code from disparate libraries. This BIOS is largely the result of a symbiosis between classic knowledge and new technology.

The work is just beginning. Ahead lies debugging, optimization, and the search for that ideal architecture. Stay tuned for updates!