BigMig 20261019 — Faster where it counts

BigMig — Release 2026-10-19

The headline is speed: the same machine, faster where it counts — BlitzQuake 1.50 goes from 34 to 42 fps, PiStorm3D's GLQuake port from 34 to 43 fps, SysInfo reads about 840 MIPS at 1.2 GHz. The core, the firmware, the Main and the guest disk change in this release. Replace the files together — a file kept from an older release is the first thing to undo if something behaves strangely. Your configs and saves are kept.

Installing and updating

With 20261010 installed, the OSD's Check Updates row finds this release and installs it. For a new install, or to repair one, run bigmig_update.sh from the menu's Scripts entry: it installs BigMig from nothing, updates it, and finishes an install that was left half-done (see the README's Install). The core's .txt and the script are unchanged.

On the Amiga side, mount the new guest disk and run its Install. It updates BigMig's minigl.library to 29.134 by itself (a MiniGL of yours is still kept as LIBS:minigl.library.orig and asked about); nothing else on the disk changed.

Highlights

The ARM's L2 cache now works for the Amiga too. The JIT's translated code uses two of the eight ways of the ARM's shared L2 cache, side by side with Linux, which keeps all eight. BlitzQuake 1.50's timedemo demo1 at 640×480 goes from 36.3 to 42.9 fps (about +18 %) from this alone; sound and disk keep up while a game runs.

A faster JIT.

• The 68k's condition codes stay in the ARM's own flags until something reads them, instead of being rebuilt after every instruction: SysInfo reads 837–842 MIPS at 1.2 GHz, up from 760–770.
• The FPU's condition codes are kept the same way, and FPU no-ops cost nothing: FPU-heavy loops run in 20–40 % fewer cycles. SysInfo's MFlops reading jumps from 70 to about 710 — its MFlops loop is mostly exactly those two instructions, so read that number as SysInfo's, not as ten times the FPU.
• A loop's copies inside one translated unit stop at about 512 bytes of ARM code: on this core a loop that fits the instruction cache runs faster (BlitzQuake 1.50 +7 %).

MiniGL 29.134 on the guest disk hands long vertex arrays to the 3D engine in pieces instead of one call per vertex: PiStorm3D's GLQuake port goes from 34 to 43 fps (timedemo demo1, 640×480), the Matrix Storm 3D screen blanker from 11 to 22 fps; BlitzQuake-3Dx2 is as fast as before.

Measured on our board — 68060+, Host Speed 1200 MHz, 3D GPU Wait on Auto, all at 640×480:

program	test	20261010	this release
CoW3D 6 (Alain Thellier's Warp3D demo, on the guest disk)	its 640×480 window	87	87
BlitzQuake-3Dx2 (on the guest disk, through our MiniGL)	timedemo demo1	45	46
BlitzQuake 1.50 (its own MiniGL 1.2 inside, our Warp3D underneath)	timedemo demo1	34	42
GLQuake (PiStorm3D's Quake 1 port, through our MiniGL)	timedemo demo1	34	43

The RTG picture no longer stays garbled after a screen-mode switch. The HDMI scaler could lose track of its own reads during a mode change and stay corrupted until the core was loaded again; it now recovers by itself.

The Linux core rests while the Amiga does. The hard-disk and Share services no longer poll: they sleep until there is work for them. With the Amiga idle, the disk service wakes ~50 times a second instead of ~4,400, the Share ~100 instead of ~1,150, and the Linux core is idle 5–7 points more of the time. Transfer speeds are unchanged, and the input loop (1 ms, as official Main) is untouched.

Fewer monitor resyncs on a screen-mode switch. BigMig's Main now programs one HDMI mode per switch — never a passing mode, never the same mode twice — and writes the new timing during the vertical blank. A monitor or a KVM switch resyncs once, not two or three times.

Indianapolis 500's intro colours are right again. At JIT speed, WHDLoad's takeover could stop the copper in the middle of the system's one-line colour setup, about one launch in three, and the intro came out brown and yellow. The firmware now lets the copper finish that line first.

Known issues

• Linux 6.18: stay on MiSTer's Linux 5.15 for now (see the README).

What's in the download

File	What it is	Goes to
BigMig_20261019.rbf + BigMig_20261019.txt	The FPGA core and its sidecar	/media/fat/_Computer/, same folder, same name — on the SD card
Emu68.img	The firmware: the JIT and the 3D engine, on the second ARM core (0.9.354)	/media/fat/linux/Emu68.img — on the SD card
MiSTer_BigMig	The Main — do not rename it	/media/fat/
Scripts/bigmig_update.sh	The installer, and what Check Updates runs (unchanged)	/media/fat/Scripts/
BigMig_Guest_20261019.hdf	The guest files on a small hard disk, with an Install script	with your disk images, e.g. /media/fat/games/Amiga/
quake106.zip (a separate download on this page)	id Software's shareware Quake 1.06, unmodified, for BlitzQuake-3Dx2	anywhere; see the README
README.md, RELEASE_NOTES.md	The manual and these notes	—

Notes

• Keep the core, its .txt, Emu68.img and the Kickstart ROM on the SD card. U-Boot loads the core from the SD card only.
• Use active cooling, always — even at the standard 800 MHz. Overclocking comes with no warranty.
• The firmware's source: Emu68-A964.

BigMig 20261010 — BigMig 3Dx2: A dual pipeline GPU for the Amiga

BigMig — Release 2026-10-10

The headline is BigMig 3Dx2: A dual pipeline GPU for the Amiga — two render units in the FPGA, a 3D engine in the firmware, and our own Warp3D.library and minigl.library on the guest disk. The core, the firmware, the Main and the guest disk all change in this release. Replace the files together — a file kept from an older release is the first thing to undo if something behaves strangely. Your configs and saves are kept.

Installing and updating

With 20260927 installed, the OSD's Check Updates row finds this release and installs it. For a new install, or to repair one, run bigmig_update.sh from the menu's Scripts entry: it installs BigMig from nothing, updates it, and finishes an install that was left half-done (see the README's Install). The core's .txt and the script are unchanged.

On the Amiga side, mount the new guest disk and run its Install. It now offers BigMig 3Dx2's libraries: a Warp3D or MiniGL of yours is kept once as LIBS:Warp3D.library.orig / LIBS:minigl.library.orig, BigMig's older builds are updated, and SetEnv BigMig3D 1 (or 0) answers the question in advance. The disk also brings the new MiSTer Share handler (below).

OMMX is now ON by default — also in a config saved by an earlier release, which comes up with it ON. Video, MP3 decoding and the 3D libraries depend on it. Turn it OFF only for a program that mistakes it for a Vampire's AMMX and goes looking for Apollo hardware.

Highlights

BigMig 3Dx2 — a dual pipeline GPU for the Amiga. A kind of compact Voodoo 3: Voodoo 3 features, performance between a Voodoo2 and a Voodoo3. A 3D engine in the firmware, on the ARM, takes a program's triangles, clips them and sorts them into screen bands; in the FPGA two render units (the "x2") — each a triangle-setup unit of ours in front of a pixel pipeline derived from ToNi3141's RasterIX — turn them into pixels. It draws in 16-bit colour with a 16-bit Z buffer, bilinear filtering, mipmaps, fog and blending, with 24 MB of texture memory; programs that ask which card they draw on are told a Voodoo 3.

• Warp3D 4.110 — for CoW3D and the games that draw through Warp3D, BlitzQuake 1.50 among them.
• MiniGL 29.133 — its OpenGL work (transforming, lighting, clipping) runs in the firmware's 3D engine on the ARM, a whole batch of commands in one call, so the 68k is left with the game itself.
• PiStorm3D's ports run. Our minigl.library implements both of PiStorm3D's MiniGL interfaces — the final MiniGL 29 and the earlier MiniGL Library Classic 27 — so programs built for either run unchanged. Tested: the Quake 1 port (GLQuake) and Hurrican; others need the original game's data.

Measured on our board — 68060+, Host Speed 1200 MHz, 3D GPU Wait on Auto, all at 640×480:

program	test	fps
CoW3D 6 (Alain Thellier's Warp3D demo, on the guest disk)	its 640×480 window	87
BlitzQuake-3Dx2 (on the guest disk, through our MiniGL)	timedemo demo1, 640×480	45
BlitzQuake 1.50 (its own MiniGL 1.2 inside, our Warp3D underneath)	timedemo demo1, 640×480	34

BlitzQuake-3Dx2 on the guest disk. Christian Michael's BlitzQuake 1.50, rebuilt so that its OpenGL goes through minigl.library, is in 3Dx2/BlitzQuake-3Dx2/ with its complete source (GPL v2) in src/. Start it with the drawer's play icon (or Execute play), which gives Quake the 1 MB stack it needs. Quake's game data is id Software's shareware Quake 1.06, included in this release, unmodified, as quake106.zip; the README says where its pak0.pak goes.

A faster processor. The JIT's new optimisations — joins of forward branches, inlined FPU branches, a faster lookup of translated code and an inline cache for calls through a register — are on by default: BlitzQuake 1.50 gains 12–15 %, and SysInfo reads 70 MFlops at 1.2 GHz, up from 27.

The HDMI pointer follows the picture. On RTG screens the pointer drawn over the HDMI output now scales with the screen, as it does on the analog output: it is no longer tiny on a 640×480 or 640×256 screen.

The MiSTer Share no longer hangs a program on an error. When the Main refused a read or a write, the previous handler never answered and the program waited forever; the new one (1.3) returns the error.

ZZ9000 Ethernet: an idle Amiga answers a ping in about 1 ms (up to ~20 ms before).

3D GPU Wait — a new row on the OSD's main page, below Emu68-A9. How the 3D engine answers a program's W3D_WaitIdle and W3D_UnLockHardware. Auto, the default, keeps the drawing queued and protects the picture's memory instead; Exact finishes the frame at every wait — use it if a title misbehaves under Auto. It applies live; (L) after the value means the engine is running and uses that mode now.

The OSD says whether a live change took. A JIT setting or 3D GPU Wait says <name>: applied when the firmware has taken the change and <name>: queued (no ack) when it has not answered.

A faster Picasso96 flip. While a flip waits for its 3D frame, the firmware answers the card's vertical-blank status at once: BlitzQuake 1.50 at 640×480 went from 25.6 to 30.9 fps.

RiVA plays its sound through MHI. The RiVA on the guest disk (0.55b-bm5) can send its sound to mhibigmig.library, which decodes it on the ARM; the disk's RiVA icon carries MHI=mhibigmig.library. mhibigmig.library 1.2 also decodes MP2 for AmigaAMP.

JIT and FPU fixes. MOVE #imm with a negative immediate could set Z wrongly for a following branch; DIVU.W/DIVS.W on an overflow could overwrite their destination and leave stale flags; NBCD on a memory operand could corrupt a following FMOVEM.X -(An); FMOVE.X/FMOVEM.X stores with the FPU control registers cached wrote through a wrong register (the 68060+ FPSP's pow() hang); the FPU ROM patches every copy of a maths library once.

Changed or removed

To make room for the GPU, the core lost three things it no longer needed:

• No Amiga-side scandoubler and no Amiga-side scanline effects. The ones the core generated itself, on the Amiga side, are gone, and with them the Scandoubler FX row. MiSTer's scaler keeps its own scanlines and filters — more modern and more advanced — exactly as before. An analog VGA monitor takes the scaled picture with vga_scaler=1 in MiSTer.ini (video_mode=6 for 640×480 at 31.5 kHz); a 15 kHz CRT keeps the native output.
• No HQ2x in the core.
• No Gayle IDE in the core. Storage goes through bigmigHD.device, as it has for a long time.

Known issues

• PiStorm3D's own MiniGL Library Classic 29.1, used on BigMig instead of ours, shows its own limitations on any Warp3D: no multitexture vertex arrays (GLQuake's textures come out wrong), no 2D vertex arrays (Hurrican's bright sprites vanish) and no keyboard through its window handle. Our minigl.library has none of them.
• Linux 6.18: stay on MiSTer's Linux 5.15 for now (see the README).

What's in the download

File	What it is	Goes to
BigMig_20261010.rbf + BigMig_20261010.txt	The FPGA core, with the 3D GPU, and its sidecar	/media/fat/_Computer/, same folder, same name — on the SD card
Emu68.img	The firmware: the JIT and the 3D engine, on the second ARM core	/media/fat/linux/Emu68.img — on the SD card
MiSTer_BigMig	The Main — do not rename it	/media/fat/
Scripts/bigmig_update.sh	The installer, and what Check Updates runs	/media/fat/Scripts/
BigMig_Guest_20261010.hdf	The guest files on a small hard disk, with an Install script	with your disk images, e.g. /media/fat/games/Amiga/
quake106.zip (a separate download on this page)	id Software's shareware Quake 1.06, unmodified, for BlitzQuake-3Dx2	anywhere; see the README
README.md, RELEASE_NOTES.md	The manual and these notes	—

Notes

• Keep the core, its .txt, Emu68.img and the Kickstart ROM on the SD card. U-Boot loads the core from the SD card only.
• Use active cooling, always — even at the standard 800 MHz. Overclocking comes with no warranty.

Licences of the new parts

The GPU in the core is our fork of RasterIX by ToNi3141, under the GNU GPL v3 like the rest of the core; its source is in this repository. BigMig 3Dx2's Warp3D.library and minigl.library are ours, and their sources will be released when considered complete; the 3D engine is part of the firmware. CoW3D is by Alain Thellier, under the GNU GPL; the guest disk carries its Aminet archive, source included. BlitzQuake-3Dx2 is GPL v2, its source in its drawer. Quake 1.06 shareware is © id Software, distributed unmodified and free of charge under its licence.

BigMig 20260927 — the 68060+, up to 770 MIPS, chip RAM twice as fast, and MP3 through MHI

BigMig — Release 2026-09-27

Every part of BigMig changes in this release — the FPGA core, its .txt, the firmware and the
Main — and the Amiga-side files now come as one small hard-disk image with an installer. Replace
all of them together; a file kept from an older release is the first thing to undo if something
behaves strangely. Your configs and saves are untouched.

Installing and updating: what changed

A new two-line .txt. The sidecar next to the core now has two lines, and BigMig starts even if
you have your own /media/fat/linux/u-boot.txt (MiSTer's own example file sets a v= line, which used
to push out BigMig's maxcpus=1). Rename it to your core's name, same folder, and keep it exactly as
released. If you added maxcpus=1 to u-boot.txt to get an earlier release running, take it out
again: there it applies to every core. And if BigMig still cannot start, the screen now says why.

The guest files are one mountable hard disk, with a one-click Install. BigMig_Guest_<date>.hdf
replaces the floppy and the loose folders of earlier releases. Put it in a free Disk slot on the
OSD's Drives page (BigMig HDs Board On) and Reset: it appears as BMG0:, volume BigMig, and
it never boots, whatever the slot — it cannot take the boot from your system disk, and its name cannot
clash with your DH0: or DH1:. Open it, double-click Install, then reboot. It installs the AHI
and ZZ9000 drivers (RTG and Ethernet), the four CD
drives, the MiSTer Share handler — and, if you say yes, SHARE: mounted at every boot — the MHI library
and RiVA.
It first looks at what your system has already, under any name or path, and it never replaces a file
of yours: your MountList, your User-Startup, your network settings, your icons and CD mountfiles
stay as they are. Your Picasso96Settings is left alone when it has screen modes for the ZZ9000; when
it has none, Install asks before replacing it (yours is kept as Picasso96Settings.pre-BigMig). BigMig's
SHARE: entry goes at the top of your MountList (a copy of your file is kept once as
MountList.pre-BigMig); if an older BigMig Install left SHARE: not working by gluing its entry onto the
end of yours, this one repairs it, with a small tool of its own on the disk (Tools/BigMigFixMountList),
never with an editor. The MiSTer Share handler it installs is BigMig's build, which also works on
Minimig: Install replaces the official Minimig for MiSTer handler and BigMig's older ones (a copy of the
one you had is kept once as MiSTerFileSystem.pre-BigMig), leaves the same or a newer BigMig build, and
asks about one it does not know. The ZZ9000 ethernet driver, ZZ9000Net.device, likewise replaces only an
older version (MNT's 1.x included). While it works, Install says what it is doing and adds a dot per step,
so a slow system never looks stuck. If nothing mounts SHARE: at boot yet, it asks before adding the mount
at the end of S:User-Startup (your old file is kept once as User-Startup.pre-BigMig). That mount runs
in the background, so it can never stop a boot, and a file named S:NoBigMigShare switches it off. It
also offers BigMig's mpega.library, the MP3 decoder RiVA's sound needs: it runs in every CPU mode
(68EC020 with or without the 68882, 68040, 68060+) and uses OMMX when OMMX is ON, the plain code
otherwise, and it fixes the crash of BigMig's earlier builds on LAME MP3s with a ReplayGain tag. Install
replaces those older builds by itself, and a standard mpega.library of yours is kept once as
mpega.library.pre-BigMig (it is in
mpega/ on the disk, with its credits and licence). It offers the wheel mouse driver and the Akiko C2P
that Minimig for MiSTer ships, by Alastair M. Robinson: WheelDriver and FreeWheel go to SYS:WBStartup,
SetAkiko runs at every boot from a marked block in S:User-Startup, and any of them you already have,
under whatever name, is left alone (the summary names the file it found). SetAkiko does not check for the
chip: if the same system disk also boots on an Amiga without Akiko C2P, create a file S:NoBigMigAkiko
there. At the end, one paragraph per notice, Install tells you only about what it did not find on your
system — Picasso96 for RTG, a TCP/IP stack for the network, MMULib's 68060.library for
68060+; the BigMig disk provides none of them. Everything the Install window shows also goes to a log file,
SHARE:BigMig-Install.log when the MiSTer Share is mounted, else RAM:BigMig-Install.log: read it
again there, or send it with a report. The tools stay on the disk for you to take. Contents.txt on
the disk lists the version and checksum of every file.

Install also checks your AHI. With AHI 6 it leaves it alone. With an older AHI (4.x), or none, it
asks before installing AHI 6.0, and keeps your old ahi.device, AHI Prefs and AHI settings first,
with a .418 suffix. After it: reboot, then open AHI Prefs, choose the mode of each unit again
and Save — AHI 6 uses a new settings format. AHI Prefs 6 is an MUI program, so it needs MUI.
The Toccata driver is on the disk too, for disks that also boot Minimig with its Toccata; Install
copies it only if you say yes (BigMig has no Toccata).

Check Updates needs one more file. Copy Scripts/bigmig_update.sh to /media/fat/Scripts/. It is
what the OSD's new Check Updates row runs (see below).

Highlights

Three CPUs to choose from: 68EC020, 68040 and 68060+. 68060+ is new: it presents a 68060 but,
unlike the real chip, keeps every instruction Motorola moved to software, so nothing traps. Under
68060+, AmigaOS expects a 68060.library in LIBS: (MMULib's, for instance), as on a real 060 — it
is what saves the FPU registers between tasks. Under the 68040 you do not need a 68040.library: with
FPU ROM on (the default) BigMig answers for it. Mac OS 8.1 under ShapeShifter needs the 68040
mode.

FPU ROM: AmigaOS's maths libraries on the FPU. A small ROM board of ours, listed with the Zorro
boards, points the IEEE single- and double-precision libraries and the FFP transcendentals at FPU
instructions the JIT runs natively. Programs that do their maths through the libraries get the FPU
without being rewritten: MathDoubTransTest went from 47.9 s to 2.3 s. On by default in the 68040
and 68060+ modes.

OMMX programs side by side. Each Amiga task now keeps its own OMMX registers — the firmware saves and
restores them as AmigaOS switches tasks, for up to 64 tasks that use OMMX — so two OMMX programs, a video
player and an MP3 decoder say, run at the same time.

The JIT keeps loops inside the translated code. Tight loops — DBcc loops included — now turn
inside their translated unit instead of going back to the dispatcher on every pass, and conditional
branches are inlined.

Chip RAM about twice as fast. The CPU now reaches chip RAM through a direct window: TestROM2 reads
7.6 MB/s at 607 ns an access, against about 3.1–3.3 MB/s and 1.2 µs before.

Chip Speed and Chip Cache, side by side on the Emu68-A9 page. Chip Speed is Fast (AGA), the
default, or Compat (68000), for timing-fragile OCS/ECS demos; it waits for a Reset. Right under it,
Chip Cache is the FPGA's cache for the CPU's reads of chip RAM: ON, the default, is faster, and
OFF is only for diagnosis. It applies at once.

MiSTer Share at full speed. A large copy runs at about 3 MB/s. The fast path a Main and a
firmware of different releases used to disagree on is now negotiated, so a mismatched pair falls back
to the classic path instead of hanging.

MP3 through MHI. Players that support MHI — AmigaAMP, for one — hand MP3 decoding to the ARM through
the new mhibigmig.library (on the guest disk). It needs ZZ9000 RTG and BigMig AHI/MHI on
(System page); with the row off, the player falls back to its own decoder.

CaffeineOS images mount as they come. A PiStorm/Emu68 SD-card image (.img) needs no
conversion: BigMig finds the Amiga disk inside the card's partition table and mounts it untouched, and
an RDB hard-disk image mounts as it is.

Emu68Info, and a new "Emu68 DevTree" row. Under System → Zorro Boards, OFF by default. With it
ON, BigMig offers devicetree.resource, which Emu68Info and the other Emu68 tools read. Like the other
boards, it takes effect at the next Reset (not live) and is saved with the config.

PiStorm distributions (CaffeineOS). BigMig mounts and runs them from their own
images, so the content they carry — demos, games, WHDLoad installs — is within easy reach; still, it is much
better to wait for their authors to make BigMig versions of them, or to build systems closer to what the
MiSTer is. Our Install is what makes them run reasonably well on BigMig — as they come, they are built
around hardware BigMig does not have.

• A PiStorm distribution: set Mode to 68040 (Emu68 on the PiStorm presents a 68040). Boot it the
  first time with Emu68 DevTree OFF, only to take Emu68's Raspberry Pi video driver,
  Devs:Monitors/emu68-VideoCore, away — delete it, or move it out of Devs:Monitors: with the device tree
  present it waits forever for the Pi's VideoCore. Then set Emu68 DevTree ON and, on the second boot,
  run Install from the guest disk.

They are not polished yet on BigMig: some things in them do not work as they should, and many of their
tools cost performance (frequent interrupts, and cache flushes that throw translated code away). In our
own comparison CaffeineOS felt slower than a Workbench 3.2.3 set up for BigMig. We keep working to make
them run better, but the good path is a system built on a modern AmigaOS 3.2.x — bring the distributions'
content across rather than their whole system.

RiVA 0.55b-bm4 on the guest disk. The MPEG-1 video player, as one program Install puts in
SYS:Utilities: it plays on any CPU mode (68EC020 included), and it uses BigMig's OMMX vector...

BigMig 20260905 — faster networking, a faster MiSTer Share, and a smoother desktop

BigMig — Release 2026-09-05

No FPGA core change in this release — the .rbf is identical to the previous one, so
this is a software update (firmware + Main + drivers). You can drop it in over your existing
install; your configs and saves are untouched. The .rbf is included anyway, for convenience.

Highlights

Faster networking. Ethernet throughput is dramatically improved — downloads that used to
crawl now run at full speed over the ZZ9000 network stack. If you tried networking on BigMig
before and found it slow, this is the fix.

Faster MiSTer Share, with a new handler. The MiSTer Share (host-folder access from the
Amiga side) is much faster on BigMig. It ships with a new file-system handler that is
backward-compatible: the same handler works when booted under Minimig, and switches
automatically to the fast path when booted under BigMig — so a single hard-drive image works
in both cores, only quicker on BigMig.

Stability & responsiveness fixes. Several core#0 bugfixes make the desktop experience
smoother and more robust over long sessions — the OSD, mouse and keyboard stay responsive, and
a memory issue that could build up over time is resolved.

Better behaviour behind HDMI switches / KVMs. BigMig now tolerates HDMI switches, KVMs and
AVRs that re-drive the hotplug line: those "clumsy" re-syncs no longer disturb the desktop's
responsiveness.

What's in the download

File	What it is
BigMig_20260905.rbf + .txt	The FPGA core (unchanged) and its sidecar
Emu68.img	The firmware (the JIT that runs on the second ARM core)
MiSTer_BigMig	The Main executable
BigMig_Guest_20260905.adf	Guest files, ready to mount — see below
mpega.library.040-ommx	Optional OMMX MP3 library — see below
bigmigAHI/, ZZ9000/, bigmigHD/, tools/, WheelDriverAkiko.adf	The same guest drivers as before, also laid out as files

Installing the guest files. Mount BigMig_Guest_20260905.adf on the Amiga side and copy
its contents into your system partition, keeping the layout (Devs/, Libs/, L/). It
contains the AHI audio driver, the ZZ9000 RTG + network drivers, the CD DOSDrivers, and the
new MiSTer Share handler (L/MiSTerFileSystem + Devs/MountList). Install.txt on the
disk has the short version. Everything on the .adf is also present unpacked in the folders
above, if you prefer to copy from there.

Optional: MP3 playback with more CPU headroom (mpega.library)

This release also includes an optional build of mpega.library that uses BigMig's OMMX
vector extension for MP3 decoding. It is not required — MP3 playback already works fine
with the standard library — but the OMMX build does the same work with more CPU left over,
which is nice headroom while music plays in the background.

To use it: rename the included mpega.library.040-ommx to mpega.library and replace your
existing one (keep a backup of the original). Skip this step entirely if you prefer; everything
else in the release works without it.

BigMig 20260831 — 16-bit audio, ethernet, and a 68040

A big release. BigMig gains 16-bit audio, ethernet, a 68040 personality, an open
vector extension, and a rebuilt OSD — and every board it offers can now be switched off.

New since 20260812

16-bit audio — the bigmigAHI card. A sound card of our own, modelled on ARM core #1 rather
than in the fabric: 8 streams, 16-bit stereo, mixed on the ARM and handed to the MiSTer audio
path. It comes with bigmigAHI.audio, the AHI sub-driver written for it, so AmigaAMP, Song
Player, RiVA and anything else that speaks AHI just work. Paula is untouched and still there.

Ethernet — the ZZ9000 network half. The ZZ9000 is one card with two halves, and the second
one now works: a real IP session, DHCP and inbound ping. You supply the TCP/IP stack; we supply
ZZ9000Net.device and a sample interface config.

A 68040 personality. The CPU the OS sees is now a per-config choice. SysInfo reads 68040 /
68040+68882 / MMU 68040, WhichAmiga reads MC68040, 68040fpu. The 68EC020 is still there and
still the default.

OMMX. An open vector extension for this machine. The AMMX instruction set is a subset of it,
so AMMX software runs.

A rebuilt OSD. Everything describing the CPU moved to its own Emu68-A9 page — Mode, JIT
Cache, 68882, OMMX, JITSTATS. System was reorganised around a Zorro Boards section: the
ZZ9000 graphics, the ZZ9000 network and the bigmigAHI card each switch ON or OFF, and OFF means
the board is not announced at all — the guest never sees it. Existing configs keep working and
default to what they did before.

Chipset fixes. CIA interrupts arriving while another source was already asserted could be
lost; they are now latched on the edge, which is what the hardware does.

CD drives — and the mountfiles to use them. Up to four, and the release now carries CD0
through CD3 for DEVS:DOSDrivers/, which 20260812 did not. Put a .iso, .cue or .chd in
a slot on the OSD's Drives page and the row switches itself to Removable/CD — no mode to
set. A drive is permanent and the image is the disc, so swapping images swaps discs with no
reset: the guest's drive task notices within a second and tells the file system. They need
L:CDFileSystem, which comes with Workbench.

The Toccata is gone from the gateware. Not switched off — removed. bigmigAHI replaces it.

Measured

SysInfo 4.4, same install, both personalities:

presented CPU	MIPS	MFlops	vs A600
68EC020 + 68882	520.16	20.51	~940×
68040	517.74	19.38	~930×

What is in the archive

Four files are the machine:

file	goes to
BigMig_20260831.rbf	/media/fat/_Computer/, or the card root
BigMig_20260831.txt	beside the .rbf, same name
Emu68.img	/media/fat/linux/Emu68.img
MiSTer_BigMig	/media/fat/ — a new file, already named as it must be; leave your official /media/fat/MiSTer alone

Then add to MiSTer.ini:

[BigMig]
main=MiSTer_BigMig

⚠ The Main in this archive is called MiSTer_BigMig, not MiSTer — a change from
20260812, on a tester's suggestion. It is the name the file must end up with, so copying it
straight to /media/fat/ does the right thing and there is no step where a stray MiSTer
could land on top of your official one. Do not rename it.

The rest is guest-side — it goes inside the Amiga's filesystem, and none of it is needed to boot:

file	goes to, inside the Amiga
bigmigAHI/Devs/AHI/bigmigAHI.audio	DEVS:AHI/
bigmigAHI/Devs/AudioModes/bigmigAHI	DEVS:AudioModes/
bigmigHD/Devs/DOSDrivers/CD0…CD3	DEVS:DOSDrivers/ — one per CD drive, install only what you want
ZZ9000/Devs/Networks/ZZ9000Net.device	DEVS:Networks/
ZZ9000/Devs/NetInterfaces/ZZ9000Net	DEVS:NetInterfaces/ — a sample, edit to taste
ZZ9000/Libs/Picasso96/ZZ9000.card	LIBS:Picasso96/ — the RTG board driver
ZZ9000/Devs/Monitors/ZZ9000 + .info	DEVS:Monitors/ — the RTG monitor
ZZ9000/Devs/Picasso96Settings	DEVS: — the RTG mode list
tools/jitstat	anywhere on your path — prints the JIT's own counters

⚠ Picasso96 itself is not ours to ship, and it is the one thing you have to fetch. Every
ZZ9000 RTG file is in this archive, but they are drivers for Picasso96, so install Picasso96
first. The last freely distributable version is Picasso96 2.0 (Aminet, 1999-11-17):
driver/video/Picasso96.lha.

⚠ The two bigmigAHI files are a pair. The driver alone offers no modes and the mode file
alone drives nothing. Install both or neither.

⚠ The .rbf and the .txt must sit together and keep the same name. The .txt is one line
of boot arguments that hands ARM core #1 to the firmware, and the loader finds it by the core's
own filename. Split them and the core starts with no CPU.

⚠ Do not mix releases. Gateware and firmware are versioned and tested together.

Checksums

03140c35  BigMig_20260831.rbf
d47267ac  Emu68.img
468b996b  MiSTer_BigMig

Full documentation is in the README.

BigMig 20260812

EDIT — 2026-08-12: the download in this release has been updated.
The Main binary was replaced. It now works with a custom main= configuration, and it
fixes an incompatibility in config handling between BigMig and Minimig.
The core and the firmware are unchanged.

If you downloaded this in its first hours, please download it again.

---

Install — as a second Main binary

This is the recommended arrangement, and what the updated Main makes possible:

1. Copy MiSTer from the zip to /media/fat/MiSTer_BigMig — a new file. Leave your official
   /media/fat/MiSTer alone.
2. In MiSTer.ini:

[BigMig]
main=MiSTer_BigMig

BigMig's Main then runs only when you load BigMig. Your official Main keeps serving
everything else, and the updater keeps maintaining it.

file	where it goes
BigMig_20260812.rbf	/media/fat/_Computer/, or the card root
BigMig_20260812.txt	beside the .rbf
Emu68.img	/media/fat/linux/Emu68.img
MiSTer	/media/fat/MiSTer_BigMig
WheelDriverAkiko.adf	wherever you keep ADFs
MiSTer_share.lha	copy to the Amiga and unpack

⚠ The .rbf and the .txt must sit in the same folder and keep the same name — the
loader finds the .txt from the core's own filename. Split them and the core starts with no CPU.

⚠ Emu68.img keeps that exact name, in /media/fat/linux/.

The board reboots once the first time it loads BigMig. That is normal — it is how ARM core #1 is
handed to the firmware.

About the Minimig config incompatibility

BigMig and Minimig share a config format, and BigMig's Main adds a few fields of its own to it
(per-slot floppies, the JIT Cache setting). If BigMig's Main is installed as your machine-wide
/media/fat/MiSTer, it also handles the Minimig core — and a Minimig config saved that way is
written in the extended layout, which the official Main then reads incorrectly.

Installing as a second binary, as above, avoids it: BigMig's Main never sees another core.

If a Minimig config is behaving oddly, load it under the official Main, set it up as you want,
and save it again. ⚠ Only Minimig-class cores are involved, and only the config metadata — your
.hdf files, ADFs and ROMs are untouched.

ZZ9000 RTG driver

Copy ZZ9000/ into SYS: keeping the folder names. Setup is then identical to the MiSTer Card,
so Minimig's own RTG instructions apply. The Monitor file is ours and is not in the upstream
ZZ9000 package — it is what makes the two set-ups the same.

---

Reporting something that does not work: Kickstart · Workbench · JIT Cache setting (or
"defaults") · WHDLoad with its version, or the ADF · what happened, with a snapshot.

⚠ Mouse wheel works. Akiko (CD³²) is on the same diskette but is untested on this core.

BigMig 20260812b — install with main=, do not replace your Main

Same core and firmware as 20260812. Main updated: it now works with a custom main=
configuration, and the FastRAM row no longer offers sizes this core does not honour.

Install — as a second Main binary

1. Copy MiSTer from the zip to /media/fat/MiSTer_BigMig — a new file. Leave your official
   /media/fat/MiSTer alone.
2. In MiSTer.ini:

[BigMig]
main=MiSTer_BigMig

BigMig's Main then runs only when you load BigMig, and the updater keeps maintaining your
official one.

file	where it goes
BigMig_20260812.rbf	/media/fat/_Computer/, or the card root
BigMig_20260812.txt	beside the .rbf
Emu68.img	/media/fat/linux/Emu68.img
MiSTer	/media/fat/MiSTer_BigMig
WheelDriverAkiko.adf	wherever you keep ADFs
MiSTer_share.lha	copy to the Amiga and unpack

⚠ The .rbf and the .txt must sit in the same folder and keep the same name — the
loader finds the .txt from the core's own filename. Split them and the core starts with no CPU.

⚠ Emu68.img keeps that exact name, in /media/fat/linux/.

The board reboots once the first time it loads BigMig. That is normal — it is how ARM core #1 is
handed to the firmware.

ZZ9000 RTG driver

Copy ZZ9000/ into SYS: keeping the folder names. Setup is then identical to the MiSTer Card,
so Minimig's own RTG instructions apply. The Monitor file is ours and is not in the upstream
ZZ9000 package — it is what makes the two set-ups the same.

---

Reporting something that does not work: Kickstart · Workbench · JIT Cache setting (or
"defaults") · WHDLoad with its version, or the ADF · what happened, with a snapshot.

⚠ Mouse wheel works. Akiko (CD³²) is on the same diskette but is untested on this core.