Base64 fx68k gateware — v1.2.2

Bug fix release. A RESET instruction now resets the board's autoconfig
state, so a software reset re-enumerates cleanly instead of leaving the
expansion chain in a half-configured state.

If you have any other autoconfig board in the machine — an IDE controller, a
RAM card, anything that takes a Zorro II address — this one matters.
Without it, every loadmodule, every software reset and every reset from
inside a test tool dropped the machine to the insert-disk screen with no boot
device, needing a Ctrl-A-A to continue.

Everything in v1.2.1 is unchanged: 42.5 MHz
cycle-exact fx68k on PAL (about 43.0 MHz on NTSC), 24 MB of fast RAM, mapROM
from boot, SD card boot, cold boot from power-on, and sfsd.device 2.4.
Requires Base64 carrier board Rev C and an iCESugar-Pro module.

---

What changed

The symptom. On an A500+ with Diego and a Ripple IDE card, every
loadmodule in the startup-sequence and every software reset dropped straight
to the Kickstart insert-disk screen without even trying the hard drive. Two
loadmodules meant two manual Ctrl-A-A interventions to reach Workbench. A guru,
or a reset from inside AmigaTestKit, did the same. A keyboard reset always
worked.

The cause. The board reset its three autoconfig functions only when
/RESET and /HALT were asserted together. That is correct for the CPU — a
68000 RESET instruction drives /RESET alone, and must not reset the processor
that issued it — but it is wrong for the Zorro boards. A Zorro II board resets
from /RESET; /HALT is not even on the connector.

So after a RESET instruction the fast RAM, the autoconfig ROM and the SD card
stayed configured, stayed shut up, and kept decoding their old base
addresses. Kickstart then re-ran the whole expansion configuration from
scratch, found them silent, and handed the first free Zorro II base to the
next board in the chain — on top of a window the fast RAM was still claiming.
No usable IDE controller, straight to the insert-disk screen.

Ctrl-A-A pulls /HALT as well, which reset everything properly. That asymmetry
was the entire diagnosis: the warm path and the cold path differed by exactly
one signal.

The fix. One line. Our own reset pulse pulls the /RESET pin, so the boards
now reset alongside every other board on the bus. The Zorro II window and
mapROM drop for the duration of the pulse, which is what a real board does —
and it is why ColdReboot runs from ROM with no stack between the RESET and
the JMP. The mapROM shadow is a verbatim copy of the ROM it shadows, so
instruction fetch is unaffected when it switches off mid-stream.

Also in this release

• The /RESET pulse length is now a parameter (RST_HOLD_7M, default 132 7M
  clocks = 18.6 µs, against the 68000's specified 124) with a counter wide
  enough to reach ~144 µs. It was not the fix here and should not be mistaken
  for one, but some expansion hardware wants a longer pulse than the CPU does,
  and the question can now be answered with a test rather than a rebuild.
• The reset distribution net is registered. As combinational logic it fed 107
  loads inside one 85 MHz clock, and that build met timing on only one
  place-and-route seed in six. One flip-flop fixed it.

Build

Fmax	89.103 MHz against the 85.900 MHz constraint
Timing	0 setup errors, 0 hold errors
SLICEs	5059 of 12144 (42%)
Registers	3074 of 24879
Block RAMs	21 of 56
I/O	116 of 197 PIO sites

The widest timing margin and the highest Fmax this design has had.

---

Testing

Machine	Result
A500+ with Diego + Ripple IDE	Fixed. Boots through both loadmodules, survives a reset from AmigaTestKit
EATX2000	Boots
A500 Rev 6A	Unchanged, works as before
B2000 (Rev 4.4 modified to 6.2)	Does not boot — see below

Thanks to the testers who found this one and chased it down with enough detail
to make it diagnosable. The "Ctrl-A-A works but a software reset doesn't"
observation is what made it solvable.

---

Installing

Plug a USB-C cable into the FPGA module. The on-board iCELink appears as a
virtual disk — drop the .bit file onto it and wait a few seconds while it
writes the SPI flash.

⚠ Do this with the module OUT of the Amiga

There is no protection on the module between its 5V rail and USB 5V.
Plugging in USB while it is seated ties the Amiga's 5V to your PC's with
nothing in between, and whichever is higher back-drives the other. If USB
has to stay attached while the module is installed, use a data-only
cable with the 5V conductor cut, leaving D+, D- and GND.

MapROM from v1.1.0 is unchanged and works with this bitstream, so there is
no need to replace it.

---

Known limitations

Carried over from v1.2.1: no DMA into the Zorro II fast RAM (set the mountlist
Mask to 0x001FFFFE), passive mode untested, and place-and-route variance
comparable to the timing margin.

Open, and recorded rather than glossed over:

• A B2000 (Rev 4.4 modified to 6.2) does not boot. Reported while testing
  this build. It is not known whether any earlier version booted on that
  machine, so this may be a long-standing incompatibility rather than a
  regression, and it is not caused by the change in this release. Under
  investigation. If you have an A2000 of that vintage, a report either way
  would help.
• Rämixx500 is still unconfirmed for the v1.2.1 CIA fix. Its tester hit
  unrelated problems with that board and could not run a comparison. The same
  fix is confirmed on an A500++ replica and on A500 Rev 5 and Rev 6.
• Removing the /CFGIN jumper does not cleanly disable autoconfig. The
  machine should boot to Kickstart with no fast RAM and no SD card; instead it
  fails intermittently. The autoconfig decode itself has been checked and is
  correctly gated, so the suspicion is bridge timing under sustained
  motherboard-only cycles rather than anything to do with configuration.
  Nobody runs the board this way deliberately, so it is a robustness issue
  rather than a functional one.

---

Checksums

SHA256  8e8f56b8b7d549eda0dded1abfd6d7d04aabb918cfc8bc68d84b0e22bfb0ccc8  base64_fx68k_v1.2.2.bit

Base64 fx68k gateware — v1.2.1

Base64 fx68k gateware — v1.2.1

Bug fix release. Holds /VMA past E's falling edge in the 6800-synchronised
bus cycle, so CIA register writes are no longer at risk of being dropped.

On some motherboards the previous builds could silently lose a write to a CIA
register. Whether it happened came down to board layout, which is why it never
showed on original Commodore boards here but broke on a replica. Recommended
for everyone — a dropped CIA write is silent, and the affected path carries
every CIA, serial, parallel and floppy-control register access the machine
makes.

Everything in v1.2.0 is unchanged: 42.5 MHz
fx68k, 24 MB of fast RAM, mapROM from boot, SD card boot, cold boot from
power-on, and sfsd.device 2.4. Requires Base64 carrier board Rev C and an
iCESugar-Pro module.

---

What changed

The symptom. On an A500++ (bobsbits A500 replica), AmigaTestKit 1.21's CIA
Timer Test reported every tick count correct — within 0.005% — and every
interrupt count zero:

Expect 1421031 Ticks and 21-22 IRQs during 100 VBLs:
CIAATA 1420966 -> OK;  0 IRQs -> FAIL
CIAATB 1420702 -> OK;  0 IRQs -> FAIL
CIABTA 1420702 -> OK;  0 IRQs -> FAIL
CIABTB 1420702 -> OK;  0 IRQs -> FAIL
CIAA TOD IRQ Failure!
CIAB TOD IRQ Failure!

The timers were counting E correctly, so E, VMA/VPA handshaking and CIA reads
were all working — but no timer interrupt was ever raised. Putting the original
68000 DIP back in the socket made the test pass, which placed the fault here
rather than on the motherboard.

The cause. An 8520 latches a write on E's falling edge, with its chip select
still asserted. Gary gates the CIA chip selects with /VMA. The RETIME path was
negating /VMA on the same 85.13 MHz clock edge that E falls — both are
flip-flops clocked by that edge, so the designed hold time was zero, and
whether /VMA survived E's fall at the CIA came down to Gary's VMA→CS
propagation racing the E distribution path. That is a board-layout property,
hence the same bitstream passing on one Rev 8A and failing on another. A real
68000 negates VMA in S7, with E already low, and has no such race.

What made it hard to see is that the only register write ATK's CIA timer test
performs is the CIA interrupt mask. Lose it and the timers keep counting
perfectly while the CIA never raises /IRQ — all ticks OK, all IRQ counts zero,
and an otherwise completely well machine.

The fix. /VMA is now held to the next half-7M tick, 70 ns past E's falling
edge, which is what the bridge FSM already did before the RETIME path replaced
it. Deferring the ack along with it also holds /AS, /UDS, /LDS, R/W, the write
data and the address, because the core cannot negate AS until it has seen
DTACK. Measured in simulation: 0 ns before, 70.8 ns after. It costs 70 ns on a
cycle that already takes about 1.4 µs, so there is no throughput change — CIA
access is E-rate limited either way.

New VMA_HOLD parameter in base64_top.sv, default 1'b1. Setting it to
1'b0 restores the old behaviour, which is useful for reproducing the fault and
for nothing else.

Only base64_top.sv changed, by eight lines. The RTL elsewhere, the ROM images,
the autoconfig layout and the product IDs are all the same, mapROM is unchanged,
and sfsd.device still binds unmodified.

Build

Fmax	88.629 MHz against the 85.900 MHz constraint
Timing	0 setup errors, 0 hold errors, 99.41% coverage
SLICEs	5080 of 12144 (42%)
Registers	3077 of 24879
Block RAMs	21 of 56
I/O	116 of 197 PIO sites

---

Testing

Board	Result
A500++ (bobsbits replica, Rev 8A)	ATK 1.21 CIA test all passed — was all-IRQs-zero before
A500 Rev 5	ATK CIA test all passed
A500+ Rev 8A (original)	unchanged, all passed
A500 Rev 6A (original)	unchanged, all passed

Thanks to Matt Harlum (LIV2) for the original report and for testing the
fix on the A500++, and to the tester who checked Rev 6 and Rev 5.

The failure was found by AmigaTestKit by Keir Fraser, which is the only
thing sharp enough to have caught it — DiagROM reports interrupts as OK on an
affected machine.

---

Installing

Plug a USB-C cable into the FPGA module. The on-board iCELink appears as a
virtual disk — drop the .bit file onto it and wait a few seconds while it
writes the SPI flash.

⚠ Do this with the module OUT of the Amiga

There is no protection on the module between its 5V rail and USB 5V.
Plugging in USB while it is seated ties the Amiga's 5V to your PC's with
nothing in between, and whichever is higher back-drives the other. If USB
has to stay attached while the module is installed, use a data-only
cable with the 5V conductor cut, leaving D+, D- and GND.

MapROM from v1.1.0 is unchanged and works with this bitstream, so there is
no need to replace it.

---

Known limitations

Carried over from v1.2.0: no DMA into the Zorro II fast RAM (set the mountlist
Mask to 0x001FFFFE), passive mode untested, and place-and-route variance
comparable to the timing margin.

New, and worth recording honestly:

• Rämixx500 is not confirmed. It was one of the two boards that originally
  reported the failure. The tester hit unrelated problems with that board and
  could not run a reliable comparison, so whether this fixes that board is
  still open. If you have one, a CIA test result either way would be welcome.
• One detail of the old failure is unexplained. The ICR mask write was
  being lost while the TOD register writes a few lines later in the same test
  landed correctly — and a per-board timing race ought to affect every CIA
  write equally. The fix widened the hold on /VMA, /AS, /UDS, /LDS, R/W, the
  write data and the address all at once, so which of those was actually being
  clipped is not established. The hold violation was real and removing it fixed
  the fault; the mechanism is recorded as not fully pinned down rather than
  presented as understood.

---

Checksums

SHA256  f2d7f555c5aa3cee6de9b1e6110153a7509bd0e07ce7c9994e2f5c8c11258855  base64_fx68k_v1.2.1.bit

Base64 fx68k gateware — v1.2.0

Base64 fx68k gateware — v1.2.0

Updates the embedded SD card driver to sfsd.device v2.4, which is
noticeably faster.

Drive speed measured with SysInfo goes from 1,310,720 to 1,759,355
bytes/sec — about 34% — on otherwise identical hardware and gateware.

No gateware changes. Everything in
v1.1.1 is unchanged: 42.5 MHz fx68k, 24 MB
of fast RAM, mapROM from boot, SD card boot, cold boot from power-on.
Requires Base64 carrier board Rev C and an iCESugar-Pro module.

Driver by Matt Harlum (LIV2), maintained at
LIV2/amiga-par-to-spi-adapter.

Only the driver ROM baked into the bitstream changed. The RTL, the autoconfig
layout and the product IDs are the same, and sfsd.device still binds
unmodified. The SPI clock is unchanged, so the gain is entirely
in the driver.

---

Installing

Plug a USB-C cable into the FPGA module. The on-board iCELink appears as a
virtual disk — drop the .bit file onto it and wait a few seconds while it
writes the SPI flash.

⚠ Do this with the module OUT of the Amiga

There is no protection on the module between its 5V rail and USB 5V.
Plugging in USB while it is seated ties the Amiga's 5V to your PC's with
nothing in between, and whichever is higher back-drives the other. If USB
has to stay attached while the module is installed, use a data-only
cable with the 5V conductor cut, leaving D+, D- and GND.

MapROM from v1.1.0 is unchanged and works with this bitstream, so there is
no need to replace it.

---

Known limitations

Unchanged from v1.1.1: no DMA into the Zorro II fast RAM (set the mountlist
Mask to 0x001FFFFE), passive mode untested, and place-and-route variance
comparable to the timing margin.

---

Checksums

SHA256  a34202d763e2d80f6bb2a34652dc794711e43a33fc85b360970abfa5074e4bac  base64_fx68k_v1.2.0.bit

Base64 fx68k gateware v1.1.1 — PFS/PDS boot fix

Base64 fx68k gateware — v1.1.1

Bug fix release. Updates the embedded SD card boot ROM to fix booting from
PFS/PDS filesystems.

No gateware changes — everything in
v1.1.0 is unchanged: 42.5 MHz fx68k, 24 MB
of fast RAM, mapROM from boot, SD card boot, cold boot from power-on.
Requires Base64 carrier board Rev C and an iCESugar-Pro module.

---

What changed

The SCSI emulation in sfsd.device used structs for the SCSI CDBs, and vbcc
padded them — producing code that attempted word reads on odd addresses.
Those are address errors on a 68000, so booting a PFS/PDS volume failed. The
fix uses byte reads instead.

Thanks to Matt Harlum (LIV2) for tracking it down and fixing it upstream:
the commit.

Only the boot ROM image baked into the bitstream changed. The RTL, the
autoconfig layout and the product IDs are all the same, and sfsd.device
still binds unmodified.

---

Installing

Plug a USB-C cable into the FPGA module. The on-board iCELink appears as a
virtual disk — drop the .bit file onto it and wait a few seconds while it
writes the SPI flash.

⚠ Do this with the module OUT of the Amiga

There is no protection on the module between its 5V rail and USB 5V.
Plugging in USB while it is seated ties the Amiga's 5V to your PC's with
nothing in between, and whichever is higher back-drives the other. If USB
has to stay attached while the module is installed, use a data-only
cable with the 5V conductor cut, leaving D+, D- and GND.

MapROM from v1.1.0 is unchanged and still works with this bitstream, so
there is no need to replace it.

---

Known limitations

Unchanged from v1.1.0: no DMA into the Zorro II fast RAM (set the mountlist
Mask to 0x001FFFFE), passive mode untested, and place-and-route variance
comparable to the timing margin.

---

Checksums

SHA256  1c584aa57191229987d24a52030a3fa241ddec9b7d04fe55aa13298de833ef2a  base64_fx68k_v1.1.1.bit

Base64 fx68k gateware v1.1.0 — mapROM

Base64 fx68k gateware — v1.1.0

Adds mapROM: Kickstart is shadowed into SDRAM at boot and served from
the FPGA instead of the motherboard, so it runs at fast RAM speed.

Everything in v1.0.0 is unchanged: 42.5 MHz
fx68k, 24 MB of fast RAM, SD card boot, cold boot from power-on. Requires
Base64 carrier board Rev C and an iCESugar-Pro module.

---

mapROM

Kickstart lives on the motherboard and answers at 7 MHz with a wait state,
while the core runs at 42.5 MHz. Since most of what the OS executes is ROM
code, this is the largest speedup left in the design.

Measured with bustest on the $F80000 bank:

	before	after
readw	583.2 ns	278.2 ns
readl	1169.5 ns	400.8 ns
readm	1270.9 ns	293.6 ns
bandwidth	3.4 MB/s	up to 13.6 MB/s

bustest fast on the Zorro II fast RAM gives readw 282.8 ns — so Kickstart
now runs at the same speed as fast RAM, which is the point.

It happens automatically. The board's autoconfig ROM does the copy during
expansion configuration, before DOS and before anything loads from disk. There
is nothing to run and nothing to add to your startup-sequence. It costs about
half a second of boot time and produces no visible sign that it happened.

Tested on Kickstart 1.3 and on a 1 MB Hyperion 3.1.4, from cold boot.

How it works

1 MB of the 32 MB SDRAM is reserved as the shadow. It is reachable from no CPU
window — the only way in is through the gateware, using two control bits:

• LOAD — writes to $F80000-$FFFFFF and $E00000-$E7FFFF land in the
  shadow. Reads are untouched, so they still come from the real ROM.
• ACTIVE — reads come from the shadow.
  So the copy is an ordinary move loop with both pointers at $F80000: the read
  fetches motherboard ROM, the write goes to the shadow. Same address, different
  destination.

Both banks are always copied verbatim, with no attempt to work out what is in
them. Whatever the motherboard returns — real ROM, an alias of the other bank
because the chip has no A19 to tell them apart, or nothing at all — is
reproduced exactly, so switching over cannot change what the machine sees.

The switchover checksums the shadow against the ROM with interrupts disabled.
On a mismatch it turns mapROM back off and the machine boots from the
motherboard ROM as before, having never executed a byte of a bad shadow.

No second reset is needed, unlike mapROM on a Blizzard with BlizKick. This
shadows the same Kickstart rather than loading a different one, so nothing
the system has built from ROM goes stale — which is also why it can be
switched on and off on a running machine.

---

MapROM (optional tool)

Not needed for normal use. It is there for checking and for A/B comparisons.

MapROM STATUS     report, change nothing
MapROM OFF        switch back to the motherboard ROM
MapROM            copy and switch over

Straight after boot, MapROM STATUS should say active on. If it says
active off, the shadow did not verify and the machine is running from the
motherboard ROM — no harm done, but worth reporting.

Copy it anywhere on your boot volume. If AmigaDOS refuses to run it, the
executable bit was lost in transit: protect MapROM +e.

---

Timing

This build closes with 0 setup errors and 0 hold errors, 87.222 MHz
against the 85.900 MHz constraint.

v1.0.0's notes described the margin as thin and warned that rebuilding might
not close. That turned out to be a constraints bug rather than a design limit.
The condition-code paths in the fx68k ALU run from enT3 to enT3 — a whole
microcycle — but three of the four register combinations were never given a
multicycle exception, so they were being held to four times tighter than
required. They are now stated correctly, and the previously critical paths
have around 11 ns of slack rather than being marginal.

The worst-case path is still close to the line, and place-and-route variance
between builds remains comparable to the margin, so a rebuild from source may
still land differently. The underlying constraint is the -6 speed grade of
the part on the iCESugar-Pro.

---

Installing

Plug a USB-C cable into the FPGA module. The on-board iCELink appears as a
virtual disk — drop the .bit file onto it and wait a few seconds while it
writes the SPI flash. No adapter, no drivers, no extra tools.

⚠ Do this with the module OUT of the Amiga

There is no protection on the module between its 5V rail and USB 5V.
Plugging in USB while it is seated ties the Amiga's 5V to your PC's with
nothing in between, and whichever is higher back-drives the other. In
practice USB sits closer to a true 5.0V and the Amiga nearer 4.9V, so the
result is your PC powering the Amiga's 5V rail — which is not what you want
either.

If USB has to stay attached while the module is installed, use a data-only
cable with the 5V conductor cut, leaving D+, D- and GND.

Program it, then seat it in the SO-DIMM socket.

---

Known limitations

• DMA into the Zorro II fast RAM is not supported. A Zorro II DMA device
  targeting that range will hang. Set the mountlist Mask so the filesystem
  bounces through chip RAM — 0x001FFFFE — which is needed for the 32-bit
  fast RAM regardless, since Kickstart 1.3 has no MEMF_24BITDMA.
• Passive mode is untested. The gateware will hand the bus over to a
  second accelerator that asserts and holds /BR, but that path has not yet
  been exercised on hardware.
• Place-and-route variance, as above.

---

Building from source

See fx68k/BUILD.md. Two things worth knowing:

• The four .mem files (microrom, nanorom, turbomem, sfsd) must be
  members of the Diamond project, typically reside in the impl1 folder.
• The fx68k submodule points at
  fredrequin/fx68k, which needs three
  bug fixes applied before it will boot on an Amiga. Without them you get a
  deterministic Guru 81000005 during Exec init.
  mapROM in the autoconfig ROM is a build option: make rom DIAG_MAPROM=1, then
  make install-mem. It is off by default in the source; the released bitstream
  has it on.

---

Credits

• Jorge Cwik (ijor) — the fx68k core.
• Frédéric Requin (frenchshark) — the fx68k performance and size rework
  (PR #6) that makes 85 MHz possible.
• Niklas Ekström and Matt Harlum — the SF2000 SD card design and
  sfsd.device, ported here unchanged.
• Alastair M. Robinson — the parent project, and the TG68k gateware that
  shares this repository.

---

Checksums

SHA256  aa90ca65eb5472dd31f591d108720825b23238631bbfea5b54936b6bda3239f7  base64_fx68k_v1.1.0.bit
SHA256  648d9ea521249383ae53b76f79666664e66b83cc3f86b255f33ba8d1f4730bce  MapROM

Base64 fx68k gateware v1.0.0 — first release

First release of the fx68k gateware for the Base64 carrier board. Turns a 68000 Amiga into a ~42.5 MHz machine with 24 MB of fast RAM and SD card boot, using a cycle accurate 68000 core.

Requires Base64 carrier board Rev C and an iCESugar-Pro FPGA module.

---

What you get

• fx68k cycle accurate 68000 at an 85 MHz master clock, 42.5 MHz effective
  — 6x a stock A500.
• 8 MB Zorro II fast RAM, autoconfigured, offered in descending sizes so it
  works on every Kickstart.
• 16 MB fast RAM at $08000000 in 32-bit CPU space, added to the free pool at
  boot. Together that's 24 MB usable, including under Workbench 1.3.
• SD card boot. A port of the SF2000 design, so the unmodified
  sfsd.device binds to it without a driver fork.
• Boots from cold power-on, no manual reset needed.
  Tested on an Amiga 500 with Kickstart 1.3 and Kickstart 3.1.4, including a
  1 MB Hyperion ROM.

Autoconfig boards

Manufacturer	Product	Board
5194	13	Zorro II fast RAM
5194	14	AutoConfig ROM (adds the 16 MB at boot)
5194	11	SD card

IDs 13 and 14 are registered to Base64 with the Open Amiga Hardware Repository. Product 11 is deliberately shared with the SF2000, so its driver binds unmodified.

---

Installing

Plug a USB-C cable into the FPGA module. The on-board iCELink appears as a virtual disk — drop the .bit file onto it and wait a few seconds while it writes the SPI flash. No adapter, no drivers, no extra tools.

⚠ Do this with the module OUT of the Amiga

There is no protection on the module between its 5V rail and USB 5V.
Plugging in USB while the module is seated ties the Amiga's 5V to your PC's
with nothing in between, and whichever is higher back-drives the other. In
practice USB sits closer to a true 5.0V and the Amiga nearer 4.9V, so the
result is your PC powering the Amiga's 5V rail — which is not what you want
either.

If USB has to stay attached while the module is installed, use a data-only
cable with the 5V conductor cut, leaving D+, D- and GND.

Program it, then seat it in the SO-DIMM socket.

---

Known limitations

• DMA into the Zorro II fast RAM is not supported yet. A Zorro II DMA device
  targeting that range will hang. Set the mountlist Mask so the filesystem
  bounces through chip RAM — 0x001FFFFE — which is needed for the 32-bit fast
  RAM regardless, since Kickstart 1.3 has no MEMF_24BITDMA.
• Passive mode is untested. The gateware will hand the bus over to a second
  accelerator that asserts and holds /BR (an SF2000 on the A500 expansion edge,
  for instance), but has not been tested much yet.
• MapROM is not implemented yet. It is the next thing being worked on.
• Timing margin is thin. This build closes at 86.911 MHz against an 85.900
  MHz constraint, so about +0.135 ns. Place-and-route variance between builds
  is comparable to that, so rebuilding from the same source may not produce a
  bitstream that closes. See the build notes.

---

Building from source

See fx68k/BUILD.md. Two things that will otherwise cost you a build:

• The four .mem files (microrom, nanorom, turbomem, sfsd) must be members of the Diamond project, and Diamond's Clean deletes them from the implementation directory.
• The fx68k submodule points at fredrequin/fx68k, which needs three bug fixes applied before it will boot on an Amiga — PR to that fork. Without them you get a deterministic Guru 81000005 during Exec init. FPGA utilisation, for reference: 8238 of 24288 LUT4 (34%), 5067 of 12144 slices (42%), 3083 registers (12%), 21 of 56 block RAMs.

---

Credits

• Jorge Cwik (ijor) — the fx68k core.
• Frédéric Requin (frenchshark) — the fx68k performance and size rework (PR #6) that makes 85 MHz possible.
• Niklas Ekström and Matt Harlum — the SF2000 SD card fw, design and sfsd.device, ported here unchanged.
• Alastair M. Robinson — the parent project, and the TG68k gateware that shares this repository.

---

Checksums

SHA256  1d2b781d415e1e9357f9f33d3075648ce4f8f6e2cccad83bc13fd74b1186e4e6  base64_fx68k_v1.0.0.bit