AmiCube is alive

I wanted the new SDRAM to be useful to the Amiga, not simply present on the board. That meant getting both memory ranks, AutoConfig and optional Slow RAM working together. This early diagnostic caught an incorrect final memory descriptor and failed RAM checks. I kept the working candidate safe, rejected this result and continued toward the 2 MiB Chip + 120 MiB Fast profile.

Getting a picture was only the beginning. I worked through a black-screen problem and the hand-off between SDRAM and the display until the Picasso96 framebuffer could show a live Workbench without losing VGA output. Then I brought the redesigned F12 overlay into that same display path. The physical ARM still runs the menu; the FPGA supplies the Amiga and its graphics.

The cache and direct SDRAM path gave me a much bigger playground than the original Minimig memory system. This early SysInfo screen recorded 10.86 MIPS and a 14.22× A600 Chip Speed result with the instruction cache enabled. It is a snapshot of that setup, not a promised score for every core. Keeping the faster paths compatible with floppy, chipset and display traffic mattered just as much.

I brought the real-floppy controller into the full system with 2 MiB Chip, 120 MiB Fast, RTG, hardfiles and the ARM menu still in place. Reaching SysInfo on the actual board was an important integration checkpoint. I treated booting and reading a disk as separate tests: a healthy desktop was encouraging, but it did not yet prove that the new floppy path could read or write reliably.

After fixing the ARM-side disk encoder, I could copy from an ADF to a real drive—but verification started failing at cylinder 40. That very specific boundary gave me a useful clue about write precompensation and the physical disk timing. I kept this photograph as a record of the problem and continued testing with expendable disks. Original disks stayed write-protected throughout the read tests.

This was the moment the two floppy connectors became a practical disk-copying setup. I completed a direct DF0-to-DF1 copy across all 80 cylinders and both sides, with the SDRAM, cache, RTG and physical ARM running together. The unified P112 setup also passed an ADF-to-physical-drive copy. Real and virtual disks were finally part of one workflow, with separate drive choices and activity LEDs.

I put an authentic, write-protected Jurassic Park floppy in the drive and watched AmiCube reach the language-selection screen. This was the real board reading the original disk through the P112 data separator—not a prepared ADF. Alongside the copying tests, it brought the CPU, chipset, memory and physical media together in one working system. Reading the disks already on the shelf was always a big part of the point.

My first Fast-IDE integration reached 2,184,533 bytes per second in SysInfo, but the photograph also records a damaged filesystem. I rejected that build and worked on the write path and the floppy-copy regressions. The later R6 work restored physical copying in Normal and Fast modes; I then integrated seven reviewed AGA corrections and a RAM-ready handshake change. The fast number was a checkpoint, not the finish line.

I compared the newer working core with the earlier performance screen to understand what had changed in the CPU-to-memory handshake. This cost008 test recorded 7.27 MIPS and 9.46× A600 Chip Speed; the older screenshot was not an identical-settings comparison. I kept checking Workbench, floppy operation and SysInfo as the work continued. On 8 September I selected LQ42 as the working SOFT release and retained the earlier rollback.

After getting PiStorm, PiStorm68K and a physical 68SEC000 booting on the socket path, I worked on storage and graphics. H7 reached a reported 2,184 KB/s in the tested 60 MHz socket configuration. With H8, I then ran Workbench through AmiCube’s own Picasso96 RTG output using the driver from the soft-020 setup. The screen shows 800 × 600 at 65,536 colours—not the Raspberry Pi’s HDMI output.