Whole-known-network
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@gamingonlinux" class="u-url mention">@<span>gamingonlinux</span></a></span> The Best Zelda getting even better? Oh boy!</p>
<p><span class="h-card" translate="no"><a href="https://cloudisland.nz/@r" class="u-url mention">@<span>r</span></a></span> it's unclear how or if GBA exposes JTAG pins, nobody has been able to do this afaik</p>
<p>Zelda 64: Recompiled (Majora's Mask) adds modding support, texture pack support, optimizations and more <a href="https://www.gamingonlinux.com/2025/05/zelda-64-recompiled-majoras-mask-adds-modding-support-texture-pack-support-optimizations-and-more/" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://www.</span><span class="ellipsis">gamingonlinux.com/2025/05/zeld</span><span class="invisible">a-64-recompiled-majoras-mask-adds-modding-support-texture-pack-support-optimizations-and-more/</span></a></p><p><a href="https://mastodon.social/tags/Zelda" class="mention hashtag" rel="tag">#<span>Zelda</span></a> <a href="https://mastodon.social/tags/Nintendo" class="mention hashtag" rel="tag">#<span>Nintendo</span></a> <a href="https://mastodon.social/tags/OpenSource" class="mention hashtag" rel="tag">#<span>OpenSource</span></a> <a href="https://mastodon.social/tags/Gaming" class="mention hashtag" rel="tag">#<span>Gaming</span></a> <a href="https://mastodon.social/tags/PCGaming" class="mention hashtag" rel="tag">#<span>PCGaming</span></a></p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> <span class="h-card" translate="no"><a href="https://digipres.club/@abrasive" class="u-url mention">@<span>abrasive</span></a></span> It was possible to implement an 1149.1 compliant client for the protocol by switching from SHIFT-DR back to RTI and into SHIFT-DR for each 32-bit word. The FPGA side didn't care. It just allowed this optimized version if your probe could handle it.</p><p>And I was already building my own MIPS-1 CPU (this predated the widespread use of RISC-V by quite a bit, it was circa 2011), gdbserver, interconnect, etc. in order to test all of the weird stuff I needed for Antikernel.</p><p>I created scopeclient (the GTK based, fully software rendered, horribly slow ancestor of glscopeclient) to interface with the custom logic analyzer IP I wrote because ChipScope for ISE was a paid block I didn't have the money for, and while gtkwave was an OK waveform viewer it had no trigger integration.</p><p>So a custom debug probe on top of that was just excessive. (I was already making custom FTDI dongles but not full custom drivers/protocols)</p>
<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> <span class="h-card" translate="no"><a href="https://digipres.club/@abrasive" class="u-url mention">@<span>abrasive</span></a></span> technically this is 1149.1 noncompliant but it definitely works</p><p>(oooor you could be like me and implement your own debug probe, not beholden to inefficiencies of FTDI :3)</p>
<p><span class="h-card" translate="no"><a href="https://digipres.club/@abrasive" class="u-url mention">@<span>abrasive</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> I loaded USER1 into IR (this was a Spartan-6 FPGA) and then entered SHIFT-DR state.</p><p>And free-ran TCK.</p><p>The debug bridge would constantly shift in idle words if you had no data to send, and check the response data from the DUT for a preamble. As soon as it saw a 55 55 55 D5 it knew the DUT was sending traffic and would parse it appropriately.</p><p>So you effectively had two independent unidirectional streams of 32-bit words sent bit serial, each synchronous to TCK but with no tight coupling to each other. This let me use large bulk transfers over the MPSSE and completely eliminated polling, which was far more efficient.</p>
<p>Road trip management RPG Keep Driving added controller support, working on being Steam Deck Verified <a href="https://www.gamingonlinux.com/2025/05/road-trip-management-rpg-keep-driving-added-controller-support-working-on-being-steam-deck-verified/" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://www.</span><span class="ellipsis">gamingonlinux.com/2025/05/road</span><span class="invisible">-trip-management-rpg-keep-driving-added-controller-support-working-on-being-steam-deck-verified/</span></a></p><p><a href="https://mastodon.social/tags/KeepDriving" class="mention hashtag" rel="tag">#<span>KeepDriving</span></a> <a href="https://mastodon.social/tags/Gaming" class="mention hashtag" rel="tag">#<span>Gaming</span></a> <a href="https://mastodon.social/tags/SteamDeck" class="mention hashtag" rel="tag">#<span>SteamDeck</span></a></p>
<p><span class="h-card" translate="no"><a href="https://digipres.club/@abrasive" class="u-url mention">@<span>abrasive</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> Especially for reading data - you'd have to poll a status register to find out data was ready, then read the data itself after round tripping, etc.</p><p>So my next version of the debug interface completely sidestepped all of that and did unholy things with JTAG instead.</p>
<p><span class="h-card" translate="no"><a href="https://digipres.club/@abrasive" class="u-url mention">@<span>abrasive</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> So the high level concept is that the debug interface was bridging datagrams in the on-chip interconnect out to a TCP socket on the client PC.</p><p>Essentially each client (unit test, logic analyzer, etc) connected to the debug server would get a virtual device ID that it could use to send and receive packets to on-chip devices as if it were a very slow on-chip IP.</p><p>The bus words were all 32 bits wide so the natural implementation over JTAG would be a single 32-bit scan register that you'd hit over and over to send multiple words.</p><p>The problem is, this is slooow especially if you're using FTDI things that run over USB 2.0 with large bulk transfers etc.</p>