{"id":558,"date":"2026-06-26T20:53:35","date_gmt":"2026-06-26T20:53:35","guid":{"rendered":"https:\/\/www.r3tr0.net\/?p=558"},"modified":"2026-06-26T20:53:35","modified_gmt":"2026-06-26T20:53:35","slug":"wondermca-gone-before-we-looked-the-model-57s-early-cd-setup-and-the-pos-register-that-never-answered","status":"publish","type":"post","link":"https:\/\/www.r3tr0.net\/index.php\/2026\/06\/26\/wondermca-gone-before-we-looked-the-model-57s-early-cd-setup-and-the-pos-register-that-never-answered\/","title":{"rendered":"WonderMCA: Gone before we looked, the Model 57’s early \/CD-SETUP and the POS register that never answered"},"content":{"rendered":"\n
\n\n\n\n

The card that vanished from setup<\/h2>\n\n\n\n

WonderMCA had been enumerating cleanly across the PS\/2 matrix for weeks. POST passed, the option ROM checksummed, the adapter ID showed up in the reference-diskette setup. Then I sat down at the IBM PS\/2 Model 57<\/strong> \u2014 the 8557, a 386SX desktop \u2014 booted it, and the card was simply not there<\/strong>. No adapter, no slot, nothing. POST didn’t even complain; from the chassis’s point of view there was no WonderMCA in the bus at all.<\/p>\n\n\n\n

That’s a particular kind of frustrating. A crash gives you a code. A disappearance<\/em> gives you nothing. The card was clearly alive \u2014 the screenpad lit up, Core 0 was running, the UART banner printed \u2014 but the one thing it had to do during the first second of POST, answer the POS scan<\/strong>, it wasn’t doing.<\/p>\n\n\n\n

What the card is supposed to do<\/h2>\n\n\n\n

A quick refresher on Micro Channel’s Programmable Option Select. When a PS\/2 powers on, the planar walks the slots one at a time. For each slot it asserts that slot’s dedicated \/CD SETUP<\/strong> line and reads the eight POS bytes at I\/O 0x100<\/code>\u20130x107<\/code>. Adapter ID, enable bit, ROM base \u2014 all of it comes back over those eight reads, but only<\/em> while \/CD SETUP is asserted to that slot. Outside setup, 0x100<\/code>\u20130x107<\/code> belongs to nobody and reads back as float.<\/p>\n\n\n\n

So WonderMCA’s job is dead simple in principle: when the chassis reads 0x100<\/code>\u20130x107<\/code> and our \/CD SETUP is asserted<\/strong>, put the right POS byte on the data bus. Miss that, and the chassis decides the slot is empty.<\/p>\n\n\n\n

On WonderMCA the bus is handled entirely by Core 1 of the RP2350B, running a tight hand-written loop out of SCRATCH_X. \/CD SETUP arrives on GPIO 45<\/strong>, buffered (and inverted) by a U8 SN74LVC240, so at the pin it reads active HIGH<\/strong> = asserted. The POS gate was, on the face of it, trivial:<\/p>\n\n\n\n

if (io_device == DEV_MCA_POS) {\n    if (gpio_get(PIN_CD_SETUP))            <em>\/\/ asserted?<\/em>\n        dev_mca_pos_ior(addr_lo, &MCA_Data);\n    else\n        MCA_Read = 0;                      <em>\/\/ not our setup cycle<\/em>\n}\n<\/code><\/pre>\n\n\n\n
Read the pin. If high, answer. What could go wrong?<\/p>\n\n\n\n
The first wrong turn: blame the UART<\/h2>\n\n\n\n
The very first thing I noticed looked damning. On WonderMCA, GPIO 45 does double duty: it’s PIN_CD_SETUP<\/code>, but the build also had it declared as PICO_DEFAULT_UART_RX_PIN=45<\/code>. The SDK’s stdio_uart<\/code> requires<\/em> a real UART-RX-capable pin, and there’s no spare GPIO on this board, so the console RX had been parked on the CD-SETUP pin.<\/p>\n\n\n\n
That smelled like the whole bug. stdio_init_all()<\/code> configures the default UART pins \u2014 if it grabbed GPIO 45 as UART RX, gpio_get()<\/code> on the POS gate would be reading a pin owned by the wrong peripheral. And worse, stdio_init_all()<\/code> was being called three times<\/em>, one of them after<\/strong> multicore_launch_core1()<\/code> \u2014 i.e. after Core 1 had already reclaimed GPIO 45 as a plain input.<\/p>\n\n\n\n
I fixed all that, and it needed fixing: stdio now initialises exactly once, before the launch<\/strong>, Core 1 reclaims GPIO 45 as SIO with a pull-down, and the redundant post-launch stdio_init_all()<\/code> is skipped on WonderMCA. I even left a rule in CMakeLists.txt<\/code>: never add a post-launch stdio_init_all()<\/code> on this board.<\/p>\n\n\n\n
And the card still wasn’t detected.<\/p>\n\n\n\n
That’s the part worth dwelling on, because it’s a trap I fall into constantly: the first plausible cause that is genuinely wrong<\/em> and does<\/em> deserve a fix is not necessarily the<\/em> cause. The UART collision was real. It just wasn’t why the Model 57 couldn’t see the card.<\/p>\n\n\n\n
Instrumenting the gate<\/h2>\n\n\n\n
When a theory dies, stop guessing and count things. I added three counters to the POS path and a rate-limited heartbeat from Core 0:<\/p>\n\n\n\n
    \n
  • pos_ior_count<\/code>\u00a0\u2014 POS reads we actually\u00a0served<\/strong><\/li>\n\n\n\n
  • pos_iow_count<\/code>\u00a0\u2014 POS writes served<\/li>\n\n\n\n
  • pos_cd_low_count<\/code>\u00a0\u2014\u00a00x100<\/code>\u20130x107<\/code>\u00a0cycles that\u00a0reached Core 1<\/strong>\u00a0but were gated off because the CD-SETUP read came back LOW<\/li>\n<\/ul>\n\n\n\n
    The whole point was to split three failure modes that look identical from the outside:<\/p>\n\n\n\n
      \n
    • ior > 0<\/code>\u00a0\u2192 POST is reading our POS regs, gate open, we’re fine.<\/li>\n\n\n\n
    • cd_low > 0<\/code>\u00a0with\u00a0ior = 0<\/code>\u00a0\u2192 cycles reach us, but the gate is shut.<\/li>\n\n\n\n
    • all zero \u2192 the cycle never even arrives \u2014 a decode\/CPLD problem, not the gate.<\/li>\n<\/ul>\n\n\n\n
      I flashed it, booted the Model 57, and watched the serial console:<\/p>\n\n\n\n
      [mca_pos] ior=1 iow=0 cd_low=345 cd_setup=0\n[mca_pos] ior=1 iow=0 cd_low=365 cd_setup=0\n[mca_pos] ior=1 iow=0 cd_low=380 cd_setup=0\n[mca_pos] ior=1 iow=0 cd_low=407 cd_setup=0\n<\/code><\/pre>\n\n\n\n
      There it was, in three numbers.<\/p>\n\n\n\n
      The cycles were arriving<\/strong> \u2014 cd_low<\/code> climbing into the hundreds means the chassis was hammering 0x100<\/code>\u20130x107<\/code> and the address decode was routing every one of them to our POS handler. So the decode was fine. But gpio_get(PIN_CD_SETUP)<\/code> read LOW on every single one<\/strong>. We served exactly one<\/strong> POS read, ever (ior=1<\/code>, almost certainly a fluke), and rejected the other 345+.<\/p>\n\n\n\n
      The gate was slamming the door on every POS read the Model 57 sent us.<\/p>\n\n\n\n
      “It’s inverted” \u2014 and then the real timing<\/h2>\n\n\n\n
      My first reaction was polarity. If the buffer wasn’t inverting the way I thought, asserted would read LOW and the gate would be backwards. I nearly flipped it. But the comments, the pull-down, and a quick check all said the same thing: U8 does<\/em> invert, asserted is<\/em> HIGH at GPIO 45, and the gate sense was correct.<\/p>\n\n\n\n
      So I put the logic analyzer on the actual \/CD SETUP line and the GPIO, and that’s when the Model 57 showed its hand:<\/p>\n\n\n\n
      \n
      On the Model 57, \/CD SETUP asserts very<\/em> early \u2014 before \/ADL \u2014 and deasserts in the middle<\/em> of \/CMD.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
      \"\"<\/figure>\n\n\n\n
      <\/p>\n\n\n\n
      <\/p>\n\n\n\n
      Read that again, because it’s the whole bug. \/CD SETUP is not held for the duration of the command phase on this chassis. It goes active before the address strobe and is already gone halfway through the command<\/strong>.<\/p>\n\n\n\n
      Now look at when<\/em> our gate read it. The Core 1 loop polls for \/ADL, latches the address the instant \/ADL fires (call that T=0), then runs through a FIFO wait, the IO_Index_T<\/code> lookup, the A_AB mux restore, and finally branches into the C-level IOR handler \u2014 where gpio_get(PIN_CD_SETUP)<\/code> lived. That read happens somewhere around T+20 cycles and beyond<\/strong>, deep into \/CMD.<\/p>\n\n\n\n
      On a well-behaved chassis that holds \/CD SETUP flat across the whole cycle, reading it at T+20 is fine. On the Model 57, by T+20 it had already deasserted.<\/strong> We were reading the pin a clean ~70 ns after<\/em> the signal we cared about had vanished. The card wasn’t broken, the gate wasn’t backwards, the polarity was right. We were just looking too late.<\/strong><\/p>\n\n\n\n
      The fix: catch it on the way past<\/h2>\n\n\n\n
      The address is already captured early \u2014 the ASM grabs it right at \/ADL. The answer was to grab \/CD SETUP at the same<\/em> moment, while it’s still asserted, instead of re-reading the live pin 70 ns later.<\/p>\n\n\n\n
      GPIO 45 sits in the RP2350’s high GPIO bank (32\u201347), which you read in one shot with mrc p0, #0, Rd, c0, c9<\/code>. GPIO 45 is bit 13<\/strong> of that word. So right in the I\/O dispatch path, at roughly T+8<\/strong> \u2014 early in \/CMD, while \/CD SETUP is still solidly asserted \u2014 I take a single high-bank snapshot and carry it out of the ASM:<\/p>\n\n\n\n
      "5:"\n"   mrc  p0, #0, r0,      c0, c8   "   \/\/ address (low bank)      T+7\n"   mrc  p0, #0, %[iohi], c0, c9   "   \/\/ RAW high-bank snapshot   T+8  <-- \/CD SETUP still asserted\n"   ubfx r0, r0, #DBASE, #12       "   \/\/ addr_lo\n<\/code><\/pre>\n\n\n\n
      The C handler then just decodes the bit out of the frozen snapshot instead of touching the pin:<\/p>\n\n\n\n
      bool io_cd_setup = (io_hi >> (PIN_CD_SETUP - 32)) & 1u;  <em>\/\/ latched at T+8, not re-read mid-\/CMD<\/em>\nif (io_device == DEV_MCA_POS && io_cd_setup)\n    dev_mca_pos_ior(addr_lo, &MCA_Data);\n<\/code><\/pre>\n\n\n\n
      It’s a couple of instructions on the I\/O path \u2014 which is CHRDY-extended, so there’s budget to spare \u2014 and it changes nothing about the address or data timing. It just samples the signal when it’s there<\/em>.<\/p>\n\n\n\n
      Confirmation<\/h2>\n\n\n\n
      Same console, next boot:<\/p>\n\n\n\n
      [mca_pos] ior=28 iow=9  cd_low=520 cd_setup=0\n[mca_pos] ior=34 iow=11 cd_low=566 cd_setup=0\n[mca_pos] ior=42 iow=38 cd_low=600 cd_setup=0\n<\/code><\/pre>\n\n\n\n
      ior<\/code> climbing in steps as the chassis walks our eight POS bytes \u2014 and iow<\/code> climbing too, which is even better: that’s the BIOS not just reading<\/em> our adapter ID but writing<\/strong> the POS option bytes, enabling the card and programming its ROM base. The Model 57 saw WonderMCA in the slot, configured it, and moved on. (cd_low<\/code> keeps rising because it counts every 0x100<\/code> cycle for the other<\/em> slots, where our \/CD SETUP is correctly deasserted \u2014 that’s expected, not an error. And cd_setup=0<\/code> in the print is just the Core 0 heartbeat sampling the pin asynchronously, nowhere near our brief selection window \u2014 the ior<\/code>\/iow<\/code> counters are the real measure.)<\/p>\n\n\n\n
      Card detected.<\/p>\n\n\n\n
      The same trap, two more signals<\/h2>\n\n\n\n
      Once you’ve been bitten by “the signal was gone before the C code looked,” you start seeing it everywhere \u2014 and rightly so. Two more bus qualifiers live in that exact same high-bank snapshot, and both had the same latent risk:<\/p>\n\n\n\n
        \n
      • \/TC<\/strong>\u00a0(terminal count, end-of-DMA) on\u00a0GPIO 39<\/strong>\u00a0= bit 7. On the scope it asserts\u00a0+10 ns after \/ADL<\/strong>\u00a0\u2014 so our T+8-ish snapshot catches it cleanly, while the old\u00a0gpio_get(PIN_R_TC)<\/code>\u00a0deep in the DMA consume path was reading it ~90 ns later, right at its deassert edge. That late read was almost certainly part of why the real \/TC EOT had always been flaky enough that we’d fallen back to a byte-count.<\/li>\n\n\n\n
      • DMA grant<\/strong>\u00a0on\u00a0GPIO 38<\/strong>\u00a0= bit 6. Grant can drop\u00a0as the transfer ends<\/em>, so a late read risks missing the capture on exactly the\u00a0last (\/TC) byte<\/strong>\u00a0\u2014 the one that matters most.<\/li>\n<\/ul>\n\n\n\n
        Both now come from the same mrc \u2026 c9<\/code> word, sampled the instant they’re valid. One register read, three signals, all frozen at the moment the cycle begins instead of whenever the C handler happens to get around to them.<\/p>\n\n\n\n
        What I took away<\/h2>\n\n\n\n
          \n
        • A signal you can read is not a signal that’s still there.<\/strong>\u00a0On a bus,\u00a0when<\/em>\u00a0you sample is as much a part of correctness as\u00a0what<\/em>\u00a0you sample. The Model 57 holds \/CD SETUP for a narrower window than the chassis I’d been developing against, and 70 ns of handler latency was the whole difference between a card and an empty slot.<\/li>\n\n\n\n
        • Latch at the edge, decode at leisure.<\/strong>\u00a0The address was already captured early; the qualifiers should have been too. Grabbing one high-bank GPIO word the moment \/ADL fires, and pulling the bits out in C later, costs almost nothing and removes an entire class of “deasserted-before-we-looked” bugs.<\/li>\n\n\n\n
        • A necessary fix is not always the fix.<\/strong>\u00a0The UART-on-GPIO-45 collision was real and got cleaned up \u2014 but it wasn’t the reason. Counting beats guessing: three counters turned an invisible disappearance into “the cycle arrives, the pin reads low, every time,” and that sentence wrote the fix.<\/li>\n<\/ul>\n\n\n\n
          Different MCA chassis assert the same signals with surprisingly different timing, all of it legal under the IBM spec. WonderMCA now samples the bus qualifiers when they’re guaranteed valid, not when it’s convenient \u2014 and the Model 57, at last, knows the card is there.<\/p>\n","protected":false},"excerpt":{"rendered":"
          The card that vanished from setup WonderMCA had been enumerating cleanly across the PS\/2 matrix for weeks. POST passed, the option ROM checksummed, the adapter ID showed up in the reference-diskette setup. Then I sat down at the IBM PS\/2 Model 57 \u2014 the 8557, a 386SX desktop \u2014 booted it, and the card was simply not there. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[20],"tags":[],"class_list":["post-558","post","type-post","status-publish","format-standard","hentry","category-ibm-ps-2"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/posts\/558","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/comments?post=558"}],"version-history":[{"count":1,"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/posts\/558\/revisions"}],"predecessor-version":[{"id":560,"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/posts\/558\/revisions\/560"}],"wp:attachment":[{"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/media?parent=558"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/categories?post=558"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/tags?post=558"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}