The biggest obstacle in the development of the Majsta 68k CPU has been the size of the core. The existing architecture has grown too large, leaving very little room for further development, and without a major redesign, it has no real future.
Over the last 10 days, I have been working very hard on a new architecture that replaces separate instruction execution owners with shared hardware, particularly by introducing common AGU-based execution across different instruction families. So far, this concept has proven successful for LEA, MOVEA and MOVE, significantly reducing FPGA resource usage while keeping the Amiga booting successfully.

Size of the core including SignalTap before and after started optimization

My main priorities at this stage are compatibility and reducing the size of the core, not performance. Once the remaining instruction owners have been migrated and the architecture further optimized, I can focus on improving CPU performance. The goal is to build a much smaller, cleaner and faster 68k core with room for future development.


Current transitional architecture showing the migration from legacy owners to shared execution

Recent real-hardware testing with SysInfo helped identify the remaining instruction forms that were stopping the Majsta 68k from running it correctly. After implementing the missing MOVE cases, SysInfo now runs normally on the Vampire 600 V2 without rebooting.
The next step was enabling the onboard SDRAM as 4 MB of Zorro-II FastRAM. AmigaOS detects the memory at $00200000-$005FFFFF, and applications are already allocating and running from it.
The performance difference was immediate: SysInfo increased from about 0.25 MIPS to 0.66 MIPS, with no increase in the Majsta CPU clock. This clearly showed that the slow Amiga memory path was a major performance bottleneck, and that local FastRAM can dramatically improve the practical speed of the core.

Another important milestone for the Majsta 68k CPU core: SysInfo now loads and runs on a real Amiga 600 with Vampire 600 V2.
After reaching Kickstart and Workbench, the core is now moving into real Amiga software compatibility.
The current MIPS result is still low because performance optimization has not started yet. The priority remains correct MC68000 execution first, speed later.
For now, the important result is simple: Majsta 68k is running real Amiga software on real hardware.

SysInfo running on the Majsta 68k core.

Today feels like a historic day for me.
For around 3 years I have been working mostly in silence on a completely new 68K CPU core written in VHDL. During that time there were thousands of hours of development, simulation, debugging, failed ideas, rewritten parts of the core and an growing verification system.

In the last few months the project finally started moving from simulation into the real Amiga. First there was a simple write to the Amiga COLOR00 register. Then repeated bus transactions. Later came the first real Kickstart boot attempts: yellow screen, green screen, another yellow screen after getting further, and finally yesterday the machine was reaching almost all the way to the Kickstart screen before rebooting. Today everything changed.

The important discovery was that the final boot problem was not where I expected it to be. The CPU had already passed 1266 regression tests plus 3 performance tests, so I was becoming suspicious that the remaining problem might not be basic instruction execution. SignalTap finally showed what was really happening. During a memory read, the Amiga motherboard was presenting the correct data, but my hardware interface was sampling it too late. By the time the CPU captured the value, the data bus had already changed. This produced corrupted register values, bad jump targets and eventually exceptions and resets. The fix was to redesign the physical Amiga bus timing around a dedicated high-speed clock, synchronized to the original Amiga clock. Instead of trying to observe the 7 MHz bus from the much slower CPU clock, the bus controller now works from an exact 12× clock, giving deterministic timing for every Amiga bus phase. Basically same thing I was doing long time ago with my TG68 experiments. After that change I compiled the core again, programmed the Vampire 600 V2 and powered the machine.

For the first time, the Kickstart screen appeared. Even the floppy animation was there — with some wrong colors :) — but after so many months of looking at waveforms, VCD files and simulation transcripts, seeing that screen produced by my own CPU was something completely different.

And then came another surprise. A little later the same core booted all the way into Workbench. I opened a Shell and ran the CPU command: System: 68000 (INST: NoCache) At that moment this project stopped being only a CPU that passes tests in simulation. It became a CPU running a real Amiga operating system on real Amiga hardware. There is still a lot of work ahead. Compatibility is not complete. Some software already exposes things that still need investigation. Performance is still very low compared with where I eventually want this architecture to go. There is no cache yet, and there is a lot of architectural cleanup and optimization still planned.

But today none of that changes what happened. A completely new 68K CPU implementation, developed from zero in VHDL, is now running Kickstart and Workbench on a Vampire 600 V2 accelerator. For me this is an enormous morale boost. For 3 years I kept asking myself whether this was actually possible. Today I got the answer. :)

Kickstart screen Caption: September 24, 2026 — for the first time Majsta 68K reaches the Kickstart screen on real hardware.


Shell with CPU output

More progress today. The Majsta 68K now gets almost to the Kickstart screen before the system reboots. The previous yellow and green screens are gone, and the normal gray shades appear in the expected order, so the core is clearly getting further through the boot process. Still not there yet, but definitely moving in the right direction. :)

Another blocker from the boot sequence has been fixed, this time around CMP instructions. The core now passes hundreds more instructions and bus events before reaching a later yellow-screen failure. So although the screen color looks familiar, this is actually further progress through Kickstart. On to the next blocker. :)

After fixing several blockers from the first Kickstart boot attempt, the Majsta 68K now gets further and reaches the green screen. MUL/DIV and some other things are still missing at this stage, but this is clear progress compared with the previous yellow-screen result. Still not a boot, but moving in the right direction. :)

Majsta 68K progresses from the previous yellow screen to the green screen.

While working toward the first successful Kickstart boot, I also want to document the basic architecture of the Majsta 68K core. The current structure is intentionally different from something like TG68. Instead of implementing most CPU behavior inside one very large state machine, instructions are divided into separate functional owners. The basic flow is: Frontend → Decoder → Instruction Owners → Register/Commit → Memory Unit with a separate event/exception path handling interrupts and exceptions. At this stage this approach is not particularly efficient in FPGA resource usage. Many operations are still implemented directly in VHDL, and the separation between owners introduces logic that can later be simplified or shared. However, this architecture has been extremely useful during early development. Each instruction family can be developed and debugged relatively independently, and changes in one area are less likely to disturb unrelated instructions. A simple way to imagine the design is like water flowing through a pipe: instructions move from the frontend through decode, into the appropriate owner, and finally toward register commit or memory. The current design should therefore not be considered the final architecture. The plan after achieving a reliable boot is to keep the clean functional separation while reducing duplicated logic and FPGA resource usage. The second picture also shows how much the implementation has grown during the last months. For example, majsta_decode_pkg.vhd grew from roughly 18 KB to 172 KB as instruction coverage expanded. This is still very much an evolving CPU architecture, but the owner-based structure has made it possible to reach this stage.

Simplified Majsta 68K architecture during the September 2026 development stage: frontend, decoder, independent instruction owners, commit logic and memory unit.


The RTL had grown significantly as instruction coverage expanded; majsta_decode_pkg.vhd alone increased from about 18 KB from early 2025. to 172 KB now.

Yesterday I made the first real Kickstart boot attempt using the Majsta 68K core on Vampire 600 V2. It is still too early to call this a boot, because at this point instruction coverage is around 95% and several instructions needed by Kickstart are still missing. However, the result is an important milestone. The CPU now performs reset, starts executing code from the real Kickstart ROM, passes through the first initialization code and eventually reaches an instruction that is not yet implemented. This produces a vector 4 exception and ends with the yellow screen shown in the picture. Normally a yellow screen would not sound like good news :) but at this stage it actually is. The CPU is no longer running a small internal test ROM. It is now executing real Kickstart code on the real Amiga motherboard. The Quartus report also shows another problem that will have to be addressed later. The current implementation is very large, using approximately 86% of the Cyclone III EP3C40 logic elements. At this stage the core is mostly pure VHDL and makes almost no use of FPGA megafunctions apart from the PLL. For now the priority is correctness and reaching a successful boot. Once that is achieved, a major architectural cleanup and resource optimization phase will follow. Still not a boot — but definitely progress.

First real Kickstart boot attempt. The Majsta 68K executes ROM code until reaching an unsupported instruction and ends at the yellow screen.


Early Majsta 68K FPGA utilization: approximately 86% of the Cyclone III EP3C40 logic elements, before the planned architectural/resource optimization work.

Two days after the first visible hardware test, another important step was reached. The Majsta 68K core is now producing repeated writes to the Amiga custom-chip COLOR00 register at $DFF180 on the Vampire 600 V2. This is still not a Kickstart boot and the strange display shown in the picture is only the result of the test program repeatedly changing the color register. However, this is useful proof that the new CPU is no longer performing only one isolated hardware operation. It is continuously executing code and performing real bus transactions against the Amiga motherboard. At this stage the goal is not to make the screen look correct. The goal is to prove that the CPU-to-Amiga bus path works repeatedly and reliably enough that more complicated hardware tests can follow. Small progress, but another important step toward running real Amiga software.

Repeated COLOR00 writes from the Majsta 68K core producing the striped display on real Amiga 600 hardware

Tonight the Majsta 68K core reached an important hardware milestone for the first time. This is not a Kickstart boot yet. The core is running a very small program from an internal BootROM on the Vampire 600 V2, executing 68k instructions and writing directly to the Amiga custom-chip COLOR00 register. By changing the BootROM value to $000F, the Amiga screen changed to blue. SignalTap also captured the corresponding write to $DFF180, confirming that the CPU was really executing code and communicating with the actual Amiga motherboard. It is a very small test compared with what still needs to be done, but for me it is an important step: for the first time the new CPU has moved outside simulation and produced a visible result on real hardware. Small step, but a big one for this project.

First visible hardware result: Majsta 68K changes the real Amiga screen to blue.


SignalTap capture confirming the CPU write to COLOR00 at $DFF180.

Musashi running inside ModelSim (Step 1 kit)

Today I finished a small but important tooling milestone: a working setup where the Musashi 68k emulator is callable from a ModelSim testbench. This gives me a practical reference CPU inside simulation, which is useful for verification and for building repeatable regression tests.

To keep this easy for others to reproduce, I’m sharing a pre-made ZIP kit that contains: the folder structure, VHDL package/testbench files, and text instructions (manual steps).

Download

File: Musashi_ModelSim_Step1_Kit_manual_v1
What it is: a ready-to-unzip scaffold + manual build/run instructions.

What you need

• ModelSim (tested with ModelSim Altera / Quartus 13.x)
• MinGW (GCC) for building the Musashi reference DLL

Quick idea of how it works

• Musashi is compiled as a DLL that ModelSim can load.
• A small VHDL package exposes a clean interface from VHDL to the DLL.
• The included testbench can produce a simple execution/bus trace.

What you should see

• ModelSim successfully loads the Musashi DLL (no FLI/DLL errors).
• The testbench runs and produces a text trace file.
• You can open waves for the testbench signals (clock/reset/state/trace events).

Next steps

This Step 1 kit is only the foundation. Next I’ll use it to build a real verification flow:

• Step 2: standardize a bus/PC trace format (so runs are comparable)
• Step 3: run the same tiny programs on two models and diff the traces
• Step 4: turn it into a regression test that catches CPU/RTL bugs early

Credits

Musashi emulator by Karl Stenerud. This kit is only an integration scaffold + notes.

Notes / disclaimer

This is a developer tool and may evolve quickly. If something changes, I’ll publish updated kits as follow-up posts (Step 2 / Step 3).

ModelSim + Musashi reference running