Project

General

Profile

Actions

Emulator Issues #13537

open

Broadband Adapter interrupt behavior

Added by mvanbem 14 days ago.

Status:
New
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Background

I have been developing new GameCube software from scratch, and I believe I've found a behavior difference between my physical Broadband Adapter and the emulated one in Dolphin. Between YAGCD, libogc source, Dolphin's source, the datasheets for the hopefully similar Macronix chips MX98726EC and MX98728EC, and spending a lot of time digging through MK:DD!! in Ghidra, I have fumbled my way into being able to reliably send and receive packets on hardware and on Dolphin. But the test program I tried out this morning is sensitive to how the packet-received interrupt is triggered.

  • Reference hardware:
    • GameCube DOL-001(USA)
    • Broadband Adapter DOL-015, L-DOL-A-S1B-USA
    • Picoboot IPL replacement modchip
    • Swiss launcher
  • Dolphin emulator:
    • 5.0.21088 DebugFast build
    • SP1 configured with Broadband Adapter (TAP)
    • Host platform is NixOS from nixpkgs 24.05.20240427.58a1abd

Interrupt behavior

My hardware and the Macronix datasheets seem to agree that the packet-received interrupt is edge triggered, firing when the receive ring buffer page pointers have been updated and a new packet's data is available to read. Writing 0x02 to the MX interrupt status register (mapped at 0x0009 by default) appears to acknowledge and deassert the interrupt.

Dolphin presents a level-triggered interrupt. The current implementation in EXI_DeviceEthernet.cpp has the comment, "raise back if there is still data," and reasserts the interrupt as long as the receive ring buffer's read and write page pointers are different. This behavior seems to have been introduced in July 2022 as part of a larger change to add new BBA features.

Effects

My test program tries to acknowledge any interrupts from the Broadband Adapter in the external interrupt exception handler, setting flags for a suspended asynchronous task to follow up after the interrupt handler returns. This test program works on hardware, printing the occasional message about receiving a packet to the screen, but on Dolphin it goes into an infinite interrupt loop, taking an interrupt again immediately every time it returns.

I wouldn't be surprised if Nintendo's driver worked with either interrupt behavior. It seems to like turning things off between uses. But I haven't tried modifying Dolphin to match the hardware behavior I've observed.

Questions

This leaves me with a bunch of questions.

How intentional and mature is this behavior in Dolphin?

What level of hardware verification is appropriate before proposing a change to emulated device behavior?

Are there multiple revisions of the Broadband Adapter that should be checked for possible compatibility hazards?

No data to display

Actions

Also available in: Atom PDF