The whole point of a Sound Blaster emulation is that it streams 8-bit PCM sample data from RAM to the DAC without the CPU babysitting every sample. That stream goes through DMA (Direct Memory Acces). On an ISA Sound Blaster the DMA is pretty simple \u2014 there’s a single 8237 DMA controller on the chassis, you wire the card’s DREQ\/DACK pins to one of its channels, and the controller’s hardware does the rest. Total mental load: 30 seconds.<\/p>\n\n\n\n
MCA is not ISA. MCA has no 8237. MCA has CACP<\/strong>.<\/p>\n\n\n\n The Central Arbitration Control Point is what IBM substituted for the 8237 when they designed MCA in 1987 \u2014 a fully multi-master bus arbiter. Every device that wants the bus (including CPU, refresh, floppy controller, DMA-using card) participates in a 4-cycle priority arbitration. The winner gets the bus for one or a handful of cycles, then has to release. There’s a per-arbitration 7.8 \u00b5s deadline<\/strong>: if a card holds the bus longer than that, the chassis fires NMI POST 113 and the OS halts. Trust me I know pretty well the error 113. On MCA Bus, DMA is complex, picky, undocumented, specific to PS\/2 model. A pure concentrate of nightmare to have something to work.<\/p>\n\n\n\n In the WonderMCA case, the Sound Blaster emulation will be managed with our card to be DMA Slave (and not DMA Master). It means that the WonderMCA never owns the BUS, it request and capture. simple no ? <\/p>\n\n\n\n On the WonderMCA, we have the following actors: <\/p>\n\n\n\n After many (many many) attempt, and RP2350 PIO trial, I decided to shift from pure RP2350 and to combine it with a CPLD. The Arbitration process is not complex but combinational and requires a processing time that the RP2350 can not provide without losing the MEM \/ IO Path.<\/p>\n\n\n\n I started a small proof of concept with and ATF22V10C, with the algorithm provided in the IBM specifications. Using my preferred Logic analyser, I was able to see the mecanism of the arbitration.<\/p>\n\n\n\n Given the need for CHRDY signal based on Address line decoding, tight timeframe for raising from M\/IO, S0, S1, I decide to combined both CHRDY and DMA in a single CPLD with enough macrocell for my needs. <\/p>\n\n\n\n The CPLD would provides enough GPIO (macrocells) to manage: 24x Address lines, 16 MCA Bus signals (\/ADL, \/CMD, M\/IO, \/S0, \/S1, \/PREEMPT, ARB\/BNT, MADE24, SBHE, CHRDY, ARB0-3, BURST, TC), and interfaced GPIO between the RP2350. Plus I need a CPLD easy to reprogram meaning with dedicatd GPIO. Last but not least, we need a CPLD 5V compliant. <\/p>\n\n\n\n Putting all this into the shaker and you get very few option, and one good option is the ATF1508 that exist in PLCC84 format. The bad news, it is not produced anymore or difficult to source.<\/p>\n\n\n\n ATF1508 and a TagConnect 2050 is the perfect combo to be able to reprogram the CPLD using WinCUPL without removing the CPLD from the WonderMCA. <\/p>\n\n\n\n The ATF1508 exists in 7ns, 10ns, 15 ns, 20ns, 25ns grade. After doing some test, beyond 10ns on some chassis (IBM P70) you start getting mis assertion of CHRDY.<\/p>\n\n\n\n I bought a stock of ATF1508-10 on aliexpress that seems to work so far…<\/p>\n\n\n\n Going back to the DMA process, this is the step performed between the PS\/2 and the WonderMCA: <\/p>\n\n\n\n Sounds simple, on the paper yes, but in reality it is more than painful. Every single timing mistake or \/CHRDY holding the bus too long trigger a NMI… What is funny with error 113 (DMA timeout), it wait for the current DMA cycle end to trigger, so you never know which DMA req has pulled the trigger… If you keep \/PREEMPT more than 50 ns asserted after the GRANT phase -> 113. And there are tons of undocumented case like these ones. And every error 113, you have to do a cold start, boot the system, prepare for the test and do it again and again… Nice ride.<\/p>\n\n\n\n That’s what we had to build, in hardware (CPLD), firmware (RP2350), and just enough copper on the PCB to make it all reach the bus.<\/p>\n\n\n\n Early on we made a key design call: the CPLD handles arbitration, The RP2350 is a 150 MHz dual-core M33 with PIO. It’s plenty fast for sustained 22 kHz audio (\u224845 \u00b5s per sample = 6750 PIO cycles), but its GPIOs are way too slow to participate in MCA’s nanosecond-scale arbitration timing directly. The ATF1508 CPLD is a 10 ns PLD \u2014 perfect for handshakes; awful for streaming.<\/p>\n\n\n\n The first PCB version of the WonderMCA has to ATF1508-10 and no PLCC84 footprint… However I put MCA Bus signal replication via pin-header on the side of the board. This is not ideal in term of capacitance, but very useful (mandatory) to debug via Logic Analyzer. <\/p>\n\n\n\n <\/p>\n\n\n\n To validate the use of the CPLD, I have create a small daughter board and asked JLCPCB 5x sample. I bridged the pin Header with the daughter board. I had to put a few bodge wire between the RP2350 and the CPLD.<\/p>\n\n\n\n The first prototype now looks like a spaghetti plate and I have time to time connectivity issues, but still good for testing. <\/p>\n\n\n\n Division of labor:<\/p>\n\n\n\n That keeps the latency-critical handshake inside 10 ns silicon and the bulk-data path in software. Clean.<\/p>\n\n\n\n Three GPIOs link the two:<\/p>\n\n\n\n I plugged in the first WonderMCA WM10 PCB, programmed the CPLD with a The chassis’s The CPLD’s pin 49: pulsing correctly when REQ went high. Output was fine, just not reaching the chassis. I traced the PCB and found a mistake in the schematic: CPLD pin 49 (the Out came the soldering iron. A 30-gauge enamelled wire from CPLD pin 49 to MCA A21 on the back of the card, soldered in by hand under a microscope. Forty-five seconds of work, one of the more important pieces of metal in the project.<\/p>\n\n\n\n After the bodge: The CPLD source is compiled with WinCUPL. Between May 12 and June 4, the .pld went through more than 30 revisions trying to make the DMA path work cleanly across all chassis (8550Z \/ 8555 \/ 8556 \/ 8557 \/ 8570 \/ P70 \/ 8580). Most of those revisions did one thing each. Three of them taught me something I didn’t already know.<\/p>\n\n\n\n Symptom: SBDSP I\/O reads at base 0x220 always returned The CPLD source had:<\/p>\n\n\n\n That looked right. Except. Four of those signal polarities were inverted on the actual silicon<\/em> compared to my mental model \u2014 the WinCUPL fitter had selected a target product term that needed inversion, but the original CUPL equation read the bare signals. Net effect: Fixed in rev 40 by re-deriving the equation against the actual chassis bus signals (rather than what I’d assumed the bare CPLD inputs looked like). Lesson: the CUPL source isn’t the silicon \u2014 CACP needs I tried the obvious:<\/p>\n\n\n\n It compiled clean. It didn’t work. After hours staring at LA captures, I read the WinCUPL docs more carefully and found the issue. You cannot use the same signal as both the input to a pin equation AND as its The pattern that works:<\/p>\n\n\n\n Two named signals \u2014 one for the value, one for the OE control, no self-reference. That’s the OD-emulation pattern.<\/p>\n\n\n\n While I was at it, rev 48 also added a 10 k\u03a9 external pull-down on Rev 48 was the first build where single-byte AND multi-byte DMA both worked end-to-end. I ran Between rev 48 and rev 57, something kept tripping us up: NMI 113<\/strong>.<\/p>\n\n\n\n Anyone working on MCA cards knows the dread of NMI POST 113 \u2014 “Card arbitration timeout, system halted.” For days I assumed POST 113 fires during<\/em> a too-slow cycle: the chassis sees you holding the bus past the 7.8 \u00b5s deadline mid-arbitration, gives up, NMIs. So I went after every microsecond of latency inside the cycle handler. Tightened the data drive. Pre-computed responses before REP_REL assertion. Bisected the firmware path. Recoded the CPLD wait-state logic three different ways. Each round I felt sure I’d fixed it; each round POST 113 came back, often after hundreds of perfectly clean cycles had already streamed through.<\/p>\n\n\n\n The breakthrough came when I finally instrumented the chassis side The 7.8 \u00b5s CACP budget isn’t a deadline you have to finish each<\/em> cycle by. It’s a deadline by which you have to release the bus<\/strong>. The cycle itself can be fast \u2014 sub-microsecond even \u2014 but if you hold on for too long after<\/em> the cycle’s data transfer is over, the chassis decides you’ve timed out. Whether you’re actively driving data or not is irrelevant. What CACP cares about is “have you given the bus back yet.”<\/p>\n\n\n\n So we had a release problem, not a cycle-speed problem.<\/p>\n\n\n\n With that reframing, the actual bug fell out in twenty minutes. I captured a long burst of streaming IOWs and noticed something specific: one IOW out of every few hundred wasn’t dropping CHRDY at the end. The data byte got through. The chassis even latched it. But our CPLD’s The proximate cause was a race in The general lesson sat there glowing: POST 113 tells you what Rev 56 fixed POST 113. For a moment everything was great \u2014 TADA Wolf3D’s first level loads level data off disk on demand. It also plays a digital gun-shot sample (~50 ms at ~11 kHz) every time you fire. The sample loops through the same SBDSP DMA path we’d just made stable. By itself: fine. Walk through a door, fire the gun, hear it cleanly.<\/p>\n\n\n\n But when the player fired while the next room was loading off the HDD<\/em>, the chassis crashed within seconds. Not POST 113. Not silence. A hard freeze, sometimes preceded by a Wolf3D error message about corrupted level data.<\/p>\n\n\n\n It took me longer than I’d like to admit to realize the twosymptoms were one bug. The disk reads were returning garbage, and the DMA cycle immediately before each disk read was the cause.<\/strong><\/p>\n\n\n\n Here’s what was happening, in the order the bus saw it:<\/p>\n\n\n\n So the chain was:<\/p>\n\n\n\n POST 113 fix in rev 49-53 \u2192 CHRDY removed from DMA path \u2192 bus-handler state-machine never sees its expected CHRDY-release event on DMA IOWs \u2192 leaves stale state \u2192 next non-DMA cycle (typically the disk-read MEMR) inherits the bad state \u2192 wrong byte on the bus \u2192 silent data corruption \u2192 eventual app or OS failure.<\/p>\n<\/blockquote>\n\n\n\n The disk crashes only showed up under Wolf3D because Wolf3D was the first thing I tried that mixed sustained DMA with concurrent disk activity<\/strong>. SBDIAG plays TADA but does nothing else on the bus \u2014 no disk, no other I\/O. So SBDIAG looked clean while the bug Rev 57 fixed it by restoring CHRDY for DMA IOW cycles specifically, via a parallel Two separate decoders, fed from the same logic but with different After rev 57: gun shot played, disk reads stayed clean, level loaded, Wolf3D ran. The chassis didn’t NMI. The cross-contamination between the DMA path and the rest of the bus handler was finally gone.<\/p>\n\n\n\n The deeper lesson here, beyond CHRDY-on-DMA-IOW: the RP2350 bus handler is a state machine that spans multiple cycles<\/strong>. If one cycle leaves it in an unexpected state \u2014 even a cycle that looks “complete enough” from the chassis’s perspective \u2014 the next cycle inherits the contamination. CHRDY isn’t just a wait state for the chassis; it’s also the firmware’s “OK I’m done, you can advance” synchronization signal. Drop it on one cycle type and you corrupt the next.<\/p>\n\n\n\n Hardware was now stable. The remaining mile was firmware pacing.<\/p>\n\n\n\n The SBDSP emulator on the RP2350 uses a Pico hardware timer to fire at the configured sample rate (8 kHz \/ 11 kHz \/ 22 kHz \/ 44 kHz). Each timer fire calls The CPLD then runs the full arbitration + IOR\/IOW cycle and the firmware’s That A It’s worth drawing the whole loop end-to-end, because the IRQ at the end is what closes it. Without the IRQ the DOS app has no idea its buffer played; without the streaming the IRQ never fires; without the release pulse CACP NMIs you. All three have to land in order.<\/p>\n\n\n\n The whole loop runs continuously for the duration of audio playback. At 22 kHz with a 4096-byte buffer, step 3 through step 8 fire 4096 times before step 9-11 fire once. At 44 kHz with the same buffer, it’s 4096 times in ~93 ms.<\/p>\n\n\n\n Each of those steps has a window where things can break:<\/p>\n\n\n\n Every one of those windows produced a unique class of debugging sessions, with its own LA capture and its own forehead-on-desk moment. Getting all 11 right at the same time is what “MCA audio works” actually means.<\/p>\n\n\n\n June 3, 2026. The 8556 ran\u00a0 That same evening Wolf3D’s gun fired cleanly. <\/p>\n\n\n\n The chassis matrix turned green:<\/p>\n\n\n\n First sustained MCA audio on a Pico-based card. Probably 30 years Why this was hard When I started WonderMCA \u2014 a PicoMEM-style RP2350-based card for the IBM PS\/2 MCA bus \u2014 the obvious “killer app” was Sound Blaster emulation. FreddyV has worked hard to bring the PicoMEM a working SBDSP emulator for ISA Bus; on MCA we get the same software base. Except for one little […]<\/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_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-433","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/posts\/433","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=433"}],"version-history":[{"count":6,"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/posts\/433\/revisions"}],"predecessor-version":[{"id":452,"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/posts\/433\/revisions\/452"}],"wp:attachment":[{"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/media?parent=433"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/categories?post=433"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.r3tr0.net\/index.php\/wp-json\/wp\/v2\/tags?post=433"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}MCA is not ISA. MCA has no 8237. MCA has CACP<\/strong>.<\/h2>\n\n\n\n
\n
\n
\n
The architecture<\/h2>\n\n\n\n
the RP2350 just streams data<\/strong>.<\/p>\n\n\n\n![\"\"](\"https:\/\/www.r3tr0.net\/wp-content\/uploads\/2026\/06\/IMG_1797-Large-768x1024.jpeg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.r3tr0.net\/wp-content\/uploads\/2026\/06\/Screen-Shot-2026-06-11-at-11.14.16-1024x970.png\")
<\/figure>\n\n\n\n\n
RP_DMA_REQ<\/code>), raise \/PREEMPT<\/code>, drive arbitration code, claim grant, drive \/ADL<\/code>\/\/CMD<\/code> for one IOR\/IOW cycle, release.<\/li>\n\n\n\n\n
RP_DMA_REQ<\/code> (out): RP2350 raises HIGH when it wants the next byte<\/li>\n\n\n\nRP_DMA_GRANT<\/code> (in): CPLD pulses HIGH when arbitration wins<\/li>\n\n\n\nRP_TC<\/code> (in): CPLD pulses HIGH at terminal count<\/li>\n<\/ul>\n\n\n\nBodge wire #1 \u2014
\/PREEMPT<\/code> doesn’t go anywhere<\/h2>\n\n\n\n
freshly-written at1508-wincpl.pld<\/code>, fired up dmatest<\/code>, and watched the logic analyzer.<\/p>\n\n\n\n\/PREEMPT<\/code> line: rock solid HIGH. Never moved.<\/p>\n\n\n\n\/PREEMPT<\/code> output) was not routed to MCA edge connector pin A21<\/strong>. The trace ended in a via that went nowhere.<\/p>\n\n\n\n\/PREEMPT<\/code> started reaching the chassis. Now we could actually request the bus.<\/p>\n\n\n\nCPLD revision purgatory<\/h2>\n\n\n\n
Rev 40 \u2014 the blk_220 decode bug<\/h3>\n\n\n\n
FF<\/code>. From the
RP2350 side, the byte WAS being driven onto the bus correctly. Something between us and the chassis was masking it.<\/p>\n\n\n\nblk_220 = !A11 & !A10 & A9 & A8 & A7 & A6 & !A5 & !A4;\n<\/code><\/pre>\n\n\n\nblk_220<\/code> was decoding 0x180<\/code> instead of 0x220<\/code>. Our “SBDSP at 0x220” was actually “nothing at 0x220, something else mysterious at 0x180”.<\/p>\n\n\n\n
always verify the decode with an LA capture before assuming logic errors.<\/p>\n\n\n\nRev 48 \u2014 the WinCUPL output-enable footgun<\/h3>\n\n\n\n
\/PREEMPT<\/code> to be open-drain \u2014 multiple masters share the line, anyone can pull it LOW, no one drives it HIGH. The ATF1508 has no native OD pin mode, so you emulate OD with the .OE<\/code> (output enable) attribute: drive 0<\/code>when you want LOW, tri-state when you want HIGH, and the bus has external pull-ups.<\/p>\n\n\n\nPIN 49 = !PREMPT_OUT;\nPREMPT_OUT.OE = PREMPT_OUT;\n<\/code><\/pre>\n\n\n\n\/PREEMPT<\/code> either floated or stayed HIGH \u2014 never asserted.<\/p>\n\n\n\n.OE<\/code> controller.<\/strong> The fitter silently produces dead logic.<\/p>\n\n\n\nPIN 49 = PREMPT_INT; \/* drive whatever this signal is *\/\nPREMPT_INT = 'b'0; \/* always-LOW intent *\/\nPREMPT_INT.OE = some_cond; \/* but only enable when some_cond *\/\n<\/code><\/pre>\n\n\n\nRP_DMA_REQ<\/code><\/strong>. Without it, between RP2350 boots and CPLD program, the line floated and CACP saw spurious REQ assertions. Pull-down fixed it.<\/p>\n\n\n\nsbdma 384<\/code> (384 samples at 22 kHz) and got my first burst of “real” audio: a 16 ms square wave tone through the I2S DAC. Tinny, brief, and the most satisfying noise I’ve heard in months.<\/p>\n\n\n\nHours of debugging what POST 113 actually means<\/h3>\n\n\n\n
properly \u2014 capturing the exact tick at which the chassis port 0x90 bit
5 (the CACP “arb timeout” status bit) went HIGH and tracing back along
the LA capture. POST 113 wasn’t firing during a slow cycle. It was firing AFTER a full, otherwise-clean cycle that should have ended.<\/strong><\/p>\n\n\n\nCHRDY_IO<\/code> signal stayed asserted (LOW) past the cycle’s natural end \u2014 adding a phantom 8-10 \u00b5s wait state to the next<\/em> arb window. Those extra microseconds, added to the normal ~5 \u00b5s cycle time, were just enough to push the total bus-hold past CACP’s 7.8 \u00b5s
release deadline. POST 113 fired several<\/em> cycles later, because that was when the chassis’s next attempted re-arbitration noticed we hadn’t actually let go.<\/p>\n\n\n\nCHRDY_IO<\/code>‘s self-latching feedback
term \u2014 under specific timing conditions it would re-assert itself a
clock after HANDLED_IO<\/code> cleared, briefly stretching its release. Killing the self-feedback in rev 56 closed that window. After rev 56: 30-minute Wolf3D sessions with no POST 113.<\/p>\n\n\n\n
condition was violated, but not when or why.<\/strong> Always trace back from the chassis-side status bit, not forward from the cycle you think caused it.<\/p>\n\n\n\nRev 57 \u2014 Wolf3D’s gun, and the bus-handler contamination<\/h3>\n\n\n\n
played, test waveforms streamed cleanly, the chassis stopped NMIing.
Then I tried Wolf3D.<\/p>\n\n\n\n\n
RP_DMA_REQ<\/code>.<\/li>\n\n\n\n0xFFFC<\/code> (the CDMA data port). Per rev 49-53’s “clean dreq_gated” change, CHRDY was no longer asserted on this DMA IOW<\/strong>. The cycle still completed \u2014 the chassis CDMA latched its byte off D0..D7 \u2014 but our RP2350 bus handler never got the CHRDY-released event it was waiting on to advance its internal handshake state machine.<\/li>\n\n\n\nHANDLED_IO<\/code> cleared on time, but RP_REL<\/code> (the “I’ve released the bus” gate) hadn’t been driven by the CHRDY-release path that normally co-fires it.<\/li>\n\n\n\nRP_REL<\/code> state. The address-latch sequence read a previous cycle’s address bits instead of the new MEMR’s, so we drove the wrong byte onto the bus.<\/li>\n\n\n\n\n
was latent.<\/p>\n\n\n\nio_match_chrdy<\/code> signal that includes the DMA terms while keeping the REP_REL path clean:<\/p>\n\n\n\nio_match = blk_2A0 # blk_100 # blk_320 # blk_300 # blk_220 # blk_388;\nio_match_chrdy = io_match\n # (blk_FFFC & active_grant)\n # (active_grant & MIO);\n\nsfdbk_internal = (io_match & valid_io) # (mem_match & valid_mem);\nCHRDY_IO = !RP_REL & !HANDLED_IO\n & ((io_match_chrdy & valid_io) # CHRDY_IO);\n<\/code><\/pre>\n\n\n\n
selectivity. SFDBK stays clean (DMA grants don’t trigger card SFDBK responses, which would confuse the chassis). CHRDY extends DMA IOW cycles so the firmware bus handler sees its expected handshake sequence and leaves clean state for the next MEMR\/MEMW to inherit.<\/p>\n\n\n\n![\"\"](\"https:\/\/www.r3tr0.net\/wp-content\/uploads\/2026\/06\/Screen-Shot-2026-06-13-at-12.05.36-1024x857.png\")
<\/figure>\n\n\n\nThe firmware side<\/h2>\n\n\n\n
wm_dma_start_write()<\/code>:<\/p>\n\n\n\n\n
req_pending = true<\/code>.<\/li>\n\n\n\nRP_DMA_REQ<\/code> HIGH (which the CPLD sees as “next byte ready,
please arbitrate”).<\/li>\n<\/ol>\n\n\n\niow_handler_done<\/code> runs after the cycle completes:<\/p>\n\n\n\n\n
RP_DMA_REQ<\/code> LOW (one byte done, no more for now).<\/li>\n\n\n\n\/PREEMPT<\/code> HIGH for ~20 \u00b5s<\/strong> (= 920 NOPs at 150 MHz).<\/li>\n\n\n\n\/PREEMPT<\/code> post-cycle pulse is critical. CACP’s 7.8 \u00b5s arbitration deadline isn’t a per-cycle limit \u2014 it’s a per-grant limit. If we hold the bus continuously across multiple cycles, we
exceed it. The 20 \u00b5s pulse forces CACP to release us at the end of every IOW, run a fresh arbitration round (which the CPU usually wins on idle systems, but only briefly), then re-grant us for the next sample.<\/p>\n\n\n\ntc_latched<\/code> back-pressure check in wm_dma_start_write<\/code> and a
3-miss watchdog in pm_cmd.cpp<\/code> close the loop: if the IOW never fires (CDMA stalled, bus contention, anything), we don’t infinitely re-raise REQ.<\/p>\n\n\n\nThe full picture: SBDSP DMA cycle from app to ear<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.r3tr0.net\/wp-content\/uploads\/2026\/06\/sbdsp_dma_flow-1024x1016.png\")
<\/figure>\n\n\n\n<\/code><\/pre>\n\n\n\nStep-by-step<\/h3>\n\n\n\n
\n
OUT 0x22C, 40h<\/code>\u00a0(set time-constant command) then a second\u00a0OUT 0x22C<\/code>\u00a0with the rate byte. Pico’s SBDSP emulator translates that to a hardware-timer frequency.<\/li>\n\n\n\nOUT 0x22C, 14h<\/code>\u00a0(DSP command 14h = 8-bit single-cycle DMA output) followed by two bytes for the buffer length (-1, low + high). The emulator does NOT touch CDMA directly here \u2014 it just records the playback parameters and arms its internal timer. The app is also responsible for having already programmed the chassis CDMA controller (via\u00a0OUT<\/code>\u00a0to ports 0x18-0x1F) with the source memory address + count + mode.<\/li>\n\n\n\nRP_DMA_REQ<\/code> to tell the CPLD “I want one bus cycle now.”<\/li>\n\n\n\n\/PREEMPT<\/code>\u00a0LOW. Chassis sees the request and queues an arbitration round.<\/li>\n\n\n\nARB[3:0]<\/code>\u00a0in parallel; the chassis grants the bus to the highest-priority. Our card uses a low priority (CPU-friendly), but on an idle chassis we win quickly.<\/li>\n\n\n\nM\/-IO=0<\/code>, pulls\u00a0\/ADL<\/code>\u00a0then \/CMD<\/code>\u00a0LOW, holds CHRDY LOW for a few extra ns (rev 57’s wait state) so the chassis CDMA controller has guaranteed data setup time, then watches CDMA latch the byte off D0..D7.<\/li>\n\n\n\n\/CMD<\/code>\u00a0HIGH,\u00a0\/ADL<\/code>\u00a0HIGH, CHRDY HIGH, byte delivered.<\/li>\n\n\n\niow_handler_done<\/code>\u00a0drops RP_DMA_REQ<\/code>\u00a0LOW (no more bytes pending right now) and pulses\/PREEMPT<\/code>\u00a0HIGH for ~20 \u00b5s, forcing CACP to release us and re-arbitrate. The CPU usually wins the next round on an otherwise-idle chassis; we wait for the next timer fire.<\/li>\n\n\n\n\/TC<\/code>\u00a0on the bus for one cycle. CPLD latches that into RP_TC<\/code>\u00a0and the Pico’s SBDSP emulator knows the buffer is done.<\/li>\n\n\n\nINT 0Dh<\/code>\u00a0(or whatever the SB IRQ vector maps to) to the DOS app’s registered ISR.<\/li>\n\n\n\n0x22E<\/code>\u00a0to clear the DSP’s IRQ flag, then either programs the next buffer (single-cycle mode) or leaves the DSP to keep streaming (auto-init mode where the DSP re-loads count\/address itself).<\/li>\n<\/ol>\n\n\n\n\n
up next cycle<\/li>\n<\/ul>\n\n\n\nFirst TADA<\/h2>\n\n\n\n
SBDIAG \/A220 \/I5 \/D1<\/code>. The autodetect passed. The Sound Blaster Diagnostic test played TADA. I had to play it three times to convince myself it was real audio and not a test pattern I’d memorized from the LA capture.<\/p>\n\n\n\n\n
since IBM gave any thought to whether such a thing was possible.<\/p>\n\n\n\nLessons<\/h2>\n\n\n\n
\n
.pld<\/code> source instead of the LA.<\/li>\n\n\n\nPIN N = !X; X.OE = X<\/code> looks right, compiles clean, and produces dead logic. The right pattern is two named signals.<\/li>\n\n\n\ndreq_gated<\/code> perfectly clean by removing DMA terms from io_match<\/code>. That broke CHRDY on DMA writes, which corrupted audio. Rev 57 split into two decoders \u2014 one clean for SFDBK, one inclusive for CHRDY \u2014 and got both. Sometimes the right answer is two equations, not one cleverer one.<\/li>\n\n\n\n\/PREEMPT<\/code> bodge wire stayed in for six weeks before the WM11 board revision picked it up in copper. Patch wires aren’t ugly \u2014 they’re the fastest way to move forward when copper is wrong.<\/li>\n\n\n\n
slow”.<\/strong> I spent days chasing nanoseconds inside the cycle handler before I realized the chassis was unhappy about a CHRDY self-latch that briefly re-asserted after the cycle’s natural end \u2014 extending the release<\/em> window past the deadline. The cycle itself was fine. Don’t optimize what the symptom doesn’t actually blame. When you see POST 113, trace back from the chassis-side status bit (port 0x90 bit 5), not forward from the most recently-completed cycle.<\/li>\n\n\n\nRP_REL<\/code>, HANDLED_IO<\/code>, address-latch registers). If one cycle leaves that state half-set \u2014 because we silenced a signal it was waiting on, like CHRDY on DMA IOW \u2014 the next<\/em> cycle inherits the contamination, and the wrongness shows up there instead of on the cycle that actually caused it. Wolf3D’s “disk read corruption” was really “the DMA IOW immediately before each disk MEMR left the handler in a bad state, so the disk MEMR read the wrong byte.” Always trace one cycle backward when debugging “this cycle is wrong” \u2014 the cause is often the one before.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"