# R7 TF storage investigation

**Release follow-up, 2026-09-16:** the owner suspected the CF card, retested
the exact original R7 image, reported it works and requested release promotion.
R7 is now the unified TF030/68000 release. No new numeric benchmark or confirmed
storage root cause was supplied. The investigation below is retained as
historical evidence; see the [dated hardware record](r7-hardware-results.txt).

## Reported behavior

The same R7 image boots TF534 in Normal, and the user subsequently reported
TF030 Turbo operation. Storage on the TF card then measured approximately
5 KB/s in Turbo and 364 KB/s in Normal. The user expects closer to 2,000 KB/s.
The user confirmed **SysInfo on the same TF534** for both speeds. The installed
CPLD firmware, adapter, SysInfo version and destination memory are not yet
confirmed. The earlier TF536 clock-filter review is background evidence and
does not explain this confirmed TF534 result.

The 72.8-fold Normal/Turbo difference is an unresolved Turbo-dependent throughput problem.
The expected 2,000 KB/s is a target rather than a measured baseline for this
configuration. R7's binary and RTL remain unchanged during this investigation.

## Findings from the TF sources

Both inspected designs clock the ATA interface from the card's CPU clock.
For TF534, schematic review subsequently established that JP1 can select either
the onboard oscillator or the socket clock as the source of that CPU clock.
Thus the earlier inference that IDE timing is independent of socket Turbo is
conditional on the oscillator setting. The initial frozen review predates this
schematic finding. The user has now confirmed trying both the onboard 50 MHz
oscillator and socket pass-through, and reports that 60 MHz is too aggressive
for the 030 to boot. The precise jumper position used for each reported
throughput measurement has not been restated.

Local IDE and Gayle accesses suppress motherboard address strobe, so overlapping
IDE addresses alone do not establish a collision. Interrupt service and uncached
ROM execution still involve motherboard transactions. If JP1 selects the socket
clock, changes to that clock can also affect local CPU and ATA timing.

- **TF534:** original Stephen Leary commit
  `1347d50d013757474e8a998e62e322a0d1793411`, preserved before Atari changes in
  the agranlund fork, directly clocks the host interface from socket `CLK7M`.
  Its [bus constraints](https://github.com/agranlund/tf534/blob/1347d50d013757474e8a998e62e322a0d1793411/boards/tf534r2c/tf534r2c_bus.ucf)
  specify a 139 ns socket period. R7 Turbo supplies approximately 16.58 ns.
  This exceeds that firmware's stated timing model; it does not prove which
  path fails on the installed card.
- **TF536:** official commit `31adbc6ea97e2567a34f43e3a011f042fdcf90da`
  [filters the socket clock](https://github.com/terriblefire/tf536/blob/31adbc6ea97e2567a34f43e3a011f042fdcf90da/rtl/clocks.v)
  using a 100 MHz local oscillator. Forty-eight ideal RTL cases show a
  60.297 MHz socket input becoming an irregular 8.095–8.115 MHz host clock,
  while its independent local CPU clock remains 50 MHz. This source is not
  established as the user's installed firmware, and the simulation excludes
  CPLD propagation delay and metastability.

The full review, source identities and clock results are retained under
`reports/r7/tf-storage/`. Local reproduction files are in
`build/tf-ide-review/clock-filter` in the main repository checkout.

## Comparison with AmiCube

The selected H20 implementation does forward its selected clock profile to the
socket pins. Its internal motherboard service schedule stays on the fixed
Normal boundary. R7 Turbo changes both the socket clock and internal service
schedule. Thus the user's AmiCube 50/60 MHz success remains a relevant reference;
the TF source's original clock assumptions do not disprove that hardware result.
Exact H20 file/line references are in the
[write-retirement review](../reports/r7/tf-storage/write-retirement-review.txt#h20-clockcommit-comparison-source-anchors).

H20 also requires a local register write to commit before external acknowledgment.
R7's existing Turbo write-release bound assumes the SEC000 bus sequence. This
motivated testing whether TF534 teardown could precede Q0 custom-register capture.

**That hypothesis did not reproduce with the tested TF534 sequence.** The
original author `bus_top.v` passes acknowledgment through additional socket and
local CPU stages before allowing the 68030 to finish. A bounded sweep passed
80 cases and 5,120 INTENA/INTREQ set/clear writes across unchanged R7 and a private
post-commit-ACK control. It covers Normal/Turbo, two local CPU frequencies, five
phases and two ACK delays. Even releasing CPU AS and data immediately on TF DSACK
left R7's earliest modeled release 10.963 ns after Q0 in Turbo and 4.443 ns after
Q0 in Normal. Bypassing the TF retirement stages and releasing directly on host
ACK produces the expected invalid-data failure, demonstrating test sensitivity.

This is a digital result for that source revision, not electrical qualification
or a full TF firmware/driver simulation. It argues against changing R7's write
ACK as the explanation for this report. The private control is not a new core
candidate. Evidence is retained under `reports/r7/tf-storage/`; the runnable
local experiment is `build/tf-write-retirement-probe` in the main checkout.

## Performance scale

R7 adds about 564 ns to a Normal uncached read in the paired timing fixture.
For illustration, 256 such extra waits total about 144 microseconds, whereas a
512-byte sector at 5,000 bytes/s takes 102.4 milliseconds. This is not a whole
driver throughput model, but fixed handoff latency alone does not explain the
reported slowdown. TF-local bulk ATA accesses bypass the R7 read pipeline in
the inspected sources, although TF534's selected CPU-clock source still matters.

The next hardware comparison uses the confirmed TF534 and the same read workload
after fresh Normal and Turbo boots. Driver/ROM placement and buffer memory also
matter when interpreting the lower-than-expected Normal result. No firmware or
RTL fix has yet been established for either throughput figure.

## AmiCube Kick Turbo history: the remembered cache change

The user's cache recollection is supported by AmiCube commit
`4a7710d88329dabb830bc918712567811f6d4834` (September 9): the same-card
comparison recorded **Kick Turbo ON: over 2,000 KB/s; OFF: about 800 KB/s**
on the TF030's own storage. See that revision of
[the TF030 feedback](https://gitlab.minimig.ca/ranko/AmiCube_V11_Codex/-/blob/4a7710d88329dabb830bc918712567811f6d4834/cores/HARD/TF030/README.md).
The earlier 1,600-to-2,184 KB/s report also changed the system/card, so it is
weaker evidence of the cache's contribution. Clock, benchmark version and
repetition details were not fully specified in that historical report.

The implementation began in H6, commit
`5fb102b3` ([H6 description](https://gitlab.minimig.ca/ranko/AmiCube_V11_Codex/-/blob/5fb102b3/fpga/hard_rom_cache_h6/README.md)).
It admitted post-overlay Kickstart reads at `$F80000–$FFFFFF` to AmiCube's
existing native SDRAM/cache frontend. H9 exposed controls for existing
acceleration; it did not accelerate the TF's local ATA controller.

Selected H20 still enables this path. External socket reads use the cache's
8 KiB data side, with two ways and 16-byte lines. R7 already has a 4 KiB
direct-mapped word cache for Kickstart and eligible slow RAM. H6 explicitly
describes following original Minimig's ROM-cache idea. Thus ROM caching is
not a wholly missing feature to port back. AmiCube's burst fills and faster
SDRAM backend also cannot be copied directly to this SRAM platform.

Both implementations hold cached data before acknowledgment and through bus
release. The cache architecture can affect throughput, but these source
differences do not establish the cause of the roughly 73-fold Turbo slowdown.
The [source and capacity comparison](../reports/r7/tf-storage/amicube-cache-comparison.txt)
records exact active-path references and hashes. R7 has two block RAMs and
20 slices free; naively doubling its current cache would require one block
RAM more than the device contains. A larger cache needs a different layout
and a measured implementation fit.

## TF534 interrupt-read handover result

The original TF534 bus and RAM CPLD logic, coupled to R7's actual bridge,
Gary, Agnus and Paula, passed **64 cases / 2,560 reads**, including
**1,024 patched INTREQR reads and 256 cache hits**. The test exercises local
Gayle interrupt set/clear, cached-ROM/slow-RAM predecessors, Normal/Turbo,
independent 50 MHz or socket-following local CPU clocks, and differing
data/output-enable/ACK delays. Removing the TF's bit-3 interrupt patch makes
the CPU receive exactly `4001` instead of `4009`, as required by the negative
control.

No cached-ROM-to-interrupt-read fault was reproduced. This is a bounded
digital result, without actual CPU instruction execution, SD payloads,
electrical IPL sharing, metastability or CPLD placement timing. It does not
qualify storage performance. The source-provenance, summary and test review
are retained in `reports/r7/tf-storage/intreqr-*`; the runnable local fixture
is `build/tf-intreqr-handover-probe` in the main checkout.

## Next cache comparison

R7 has an existing cache-hit bypass: `Minimig1.v` connects `scanline[1]` to
the bridge's `blk` input. This is a **stored OSD configuration bit**, not a
beam-position signal; it does not turn caching off on alternate scanlines.
`Userio.v` sets both scanline bits from SPI command `1010--SS`; Amber uses
only bit 0. With bit 1 set, ROM and slow-RAM hits are bypassed while Turbo
clocking remains active. Fills and write-through behavior remain active.

The user subsequently recalled a cache control associated with the video/VGA
option. The preserved ASB140501 ARM firmware matches that description:
Video → Scanlines cycles **VGA alike / TV alike / Cache Off**. Its
[menu source](https://github.com/samowitsch/minimig-arm-controller-0805/blob/307dc044c87413de1c285ab58540edbdb15aa0ee/firmware/ASB140501/ARM/src/menu.c#L81)
assigns Cache Off index 2; `ConfigScanlines` sends that value in the low bits
of the scanline SPI command. The installed firmware version is still not
independently identified, but the menu recollection supports using this
existing control. Local source snapshots are in
`build/r7-cache-menu-reference` in the main checkout.

The requested comparison is: TF onboard 50 MHz oscillator, core Turbo,
Video → Scanlines → Cache Off, then an Amiga reset and the same SysInfo drive
read test. Compare against the original VGA alike/TV alike setting with
another reset. No FPGA BIN or ARM update is required. Keep the storage, memory
settings and clock choices fixed.

**Hardware result: unchanged.** The user reports Cache Off gives 364 KB/s at
7 MHz and 5 KB/s at 60 MHz. Cache-hit responses are therefore not supported
as the cause of this slowdown. A separate actual-SPI/bridge fixture confirms
that A2 bypasses ROM and slow hits without changing Turbo, survives ordinary
reset, and returns correct data (14 reads plus a disconnected-bypass negative
control). Increasing cache capacity is not the next diagnostic.

TF-local ATA payload accesses do not traverse Minimig in the inspected source.
A whole disk operation can still execute motherboard ROM code, service
interrupts through custom/CIA registers, or copy into chip RAM. Destination
memory and driver placement matter. The motherboard socket clock also feeds
the TF534 host interface independently of the local-oscillator CPU-clock
choice. Thus a locally attached drive can be affected by motherboard timing;
this does not identify which dependency explains the present result.
