Repository navigation
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