These changes come from @rondoval - a very welcomed programmer who contributes to Emu68 with several improvements and new drivers - e.g. xHCI driver for Pi4, wired ethernet for Pi4/CM4 and GIC400. Many thanks to @rondoval for his amazing work! The changes mentioned here are necessary improvements to Emu68 allowing his drivers to work correctly. Not only that, they open possibilities for other drivers in the future.

Classic PiStorm flashing

This is the change provided by @captain-amygdala the creator of PiStorm himself. This change allows one to write flash of classic PiStorm directly from Emu68. No need to run linux on raspberry first just in order to flash the CPLD. Many big thanks Claude for this contribution!

New Zorro3 board

With Emu68 1.0 every single driver or support library for Emu68 was put on a separate Zorro 3 card. Due to the way autoconfig mechanism work, this wasted approximately 16 MB of address space (RAM) for every Zorro 3 card. Now, all drivers and support libraries are put together in a single Zorro3 card, saving space and allowing to use less restrictive compiler flags for the libraries.

No need for 2GB memory limit

Even if AmigaOS cannot use memory above 2GB, Emu68 can. Therefore, the memory limit set previously in config.txt is not necessary anymore. If the Raspberry Pi has more than 2GB of RAM, part of the memory above 2GB will be used for JIT caches and internal Emu68 needs, giving you even more free RAM to AmigaOS.

Source code cleanup

In 1.1 branch the source code of Emu68 is being intensively reworked. The code has been cleaned up, slowly moving to a point where e.g. a C to C++ transition for the whole code base is possible. Don't be scared - actually the C++ here allows for even cleaner code and does not have any negative impact on performance.

Overlays

Instead of adding more and more keywords to the codline.txt, making it very hard to maintain, Emu68 1.1 introduces the concept of device tree overlays known e.g. from Linux. One can load given device tree overlay from the config.txt file and configure it on load through well-defined parameters. Currently three overlay objects are provided: unicam (for framethrower), diagnostic (for triggering buptest or memory benchmark) and emu68 (for adjusting JIT parameters for Emu68 on boot). Once 1.1 will reach final stage release, the cmdline.txt will be declared obsolete and support for it will eventually be removed in further Emu68 versions. Details on usage of overlays will be given soon.

4-way set associative JIT cache

The JIT cache got a small but significant upgrade. Apart from a large hash table for JIT which was used since very beginning, Emu68 contains now an additional 4-way set associative JIT cache with 128 sets. The cache provides faster lookup for the JIT blocks which associates only the m68k entry address with corresponding aarch64 entry address. This cache is enabled when CPU Instruction Caches are active and is fully transparent to AmigaOS. Depending on the code, this may give speed boosts from 0% up to 20-30%. Some prominent examples benefiting from this new caches are some First-Person 3D games such as Heretic II.

JIT Dumpster

This is the second very significant change. In Emu68 1.0, when CPU instruction cache was flushed, all the JIT translated blocks were flushed too and had to be recompiled again when necessary. This was a big waste of CPU resources especially for the bits and pieces of code which were not changed at all between cache flushes. And that happens rather frequently, since every executable loaded by AmigaOS forces ful cache flush upon load. Users of Macintosh emulators, such as Shapeshifter or Fusion suffered even more since there the operating system is flushing caches rather periodically (sometimes 10 times per second or faster). Now, with Emu68 1.1 it is different. The translated blocks remain in cache and can be reused after a short verification of a fingerprint and crc32 checksum. This change results in much better usage of JIT cache, significantly improved boot time (up to 2x speedup) and huge improvement in case of Apple emulators, where operating system boot is not few times faster and the system is much more responsive.

PowerPC

The last significant change, although not enabled yet by default. One of unused AArch64 cores can be now used to run a "brother" of Emu68 - second independent instance which, instead of m68k code, translates PowerPC code to AArch64. This is currently a work-in-progress subproject written in C++ and as such is not yet enabled nor usable, but it is already there in the Emu68 binary. Once completed, it will provide WarpOS-like support library allowing you to run warpos binaries PPC code on Emu68.

Bugfixes

Finally, Emu68 contains a huge pile of bugfixes. Some of them related to the gcc compiler of choice - new gcc versions are more fragile against the hacks used in Emu68 previously. Other bugfixes repair issues which were present in Emu68 since the very beginning.

WARNING!

• This version of Emu68 requires VideoCore.card version 1.5, which will be available as downloadable file within this release. VideoCore.card version 1.5 is not compatible with Emu68 1.0 and, therefore, is not yet available in Emu68-tools package.
• Framethrower users are advised to use the unicam overlay instead of enabling framethrower through cmdline.txt. Add following line to config.txt in order to activate the Framethrower and turn it on on boot:

dtoverlay=unicam,boot,smooth

the parameter boot is the same as previously used unicam.boot in cmdline.txt, the smooth option is the same as unicam.smooth from cmdline.txt.

SECOND WARNING

This is an alpha-quality pre-release. It is stable for me and is stable for people who were testing it already. Nevertheless, expect to have some issues or instabilities with it. If you decide to test it, please report the issues here, on GitHub.

THIRD WARNING

The file names have changed now:

Emu68-pistorm-classic.zip - this is the archive for classic (A500, A1000, A2000) PiStorm based on CPLD Emu68-pistorm.zip - this is the archive for PiStorm32lite and for PiStorm16 Emu68-raspi.zip - you don't want to use that one unless you want to play with bare-metal m68k based raspberry pi :)