Toolchain for the AV Macs' DSP3210 (assembler, disassembler, emulator)

[PappaDF]

I've put together an open-source toolchain for the AT&T DSP3210 - the 32-bit floating-point DSP on the logic board of the Quadra 840AV and Centris 660AV - and perhaps someone might find it useful.

The project is available here:

https://github.com/pappadf/dsp3210-sdk

What's in it:

• an assembler and a disassembler for the DSP3210 instruction set, using the AT&T syntax from the Information Manual
• an instruction-level emulator of the CPU core (two builds: a simple one, and one that models the 40-bit DAU arithmetic exactly in integers)
• a condensed, searchable programmer's reference for the CPU - the AT&T manual only seems to survive as page scans
• a test suite that cross-checks all three tools against each other, plus small example programs (loops, subroutine calls, DAU multiply-accumulate, interrupt handling)

Everything is plain C99 with no dependencies, MIT licensed, and builds with just make. To set expectations honestly: this is the CPU core only. It doesn't emulate a Mac, the Real Time Manager, or the DSP's on-chip peripherals (serial I/O, DMA, timer), and there's no C compiler - you write assembly, assemble it, and run it on the emulator, or use the C libraries to embed the core in something bigger. No cycle timing either; it's a functional model.

On correctness: during development the emulator was validated against real code - Apple's DSP kernel from the 840AV/660AV ROM boots on it, unmodified, through both of its boot handshakes into its idle loop; AT&T's mask boot ROM runs all three of its reset paths; and AppleSRC (the sample-rate converter Apple shipped as a DSP task module) runs on that kernel and resamples a test signal correctly. The disassembler reads all of the shipped DSP code in the AV ROM cleanly. None of that Apple/AT&T material is in the repository (it can't be redistributed) but the repo's own test suite is no afterthought either: the assembler and disassembler are independent implementations checked against each other across the entire cleanly-decodable opcode space (~12 million instruction words), and the example programs have hand-computed expected results.

In the interest of full transparency: AI tools were used in developing the code, tests and documentation. I know that's a red flag for some, and fully respect that.

Corrections and bug reports very welcome! (The DSP3210 also nearly made it into the Amiga 3000+ prototypes, so there may be some cross-community interest too.)

 

[gsteemso]

Very nicely done! Something along these lines, if much less ambitious, has been on my ever-lengthening To-Do list for decades – but I didn't see any realistic chance of ever actually getting to it before I keel over from old age in 40 years. Thank you for your work!

 

[pl212]

Wow, thanks! I had started assembling source materials and sample code I could find, with the aim of seeing what a coding LLM could do in 2026.

The use case I'd been thinking about was JPEG decoding, though I know others have mentioned mp3 playback.

 

[PappaDF]

Very nicely done! Something along these lines, if much less ambitious, has been on my ever-lengthening To-Do list for decades – but I didn't see any realistic chance of ever actually getting to it before I keel over from old age in 40 years. Thank you for your work!

Wow, thanks! I had started assembling source materials and sample code I could find, with the aim of seeing what a coding LLM could do in 2026.

The use case I'd been thinking about was JPEG decoding, though I know others have mentioned mp3 playback.

Thank you! It’s great to hear that you might find it useful. My immediate focus was emulator implementation (I have another emulator project that needed these tools) but I think that the tools should also be useful to anyone who wants to develop applications for the DSP3210. (I spent a ton of time searching for a toolchain first - I’m not sure why it was so hard to find).

 

[Arbee]

Neat! I'll be refactoring MAME's DSP32C emulation soon to support the Quadra AVs, so this will be a useful reference. (The DSP3210 is architecturally compatible with the DSP32C but the instruction encodings are not compatible, because AT&T).

 

[PappaDF]

Neat! I'll be refactoring MAME's DSP32C emulation soon to support the Quadra AVs, so this will be a useful reference. (The DSP3210 is architecturally compatible with the DSP32C but the instruction encodings are not compatible, because AT&T).

When you compare with DSP32C - if you find bugs in the DSP3210 implementation, please drop me a note!

Re. Quadra AVs - let me know if there is any information I can provide to help

(see my prev. experiments on Plain Boot and Video Digitizer)

 

[PappaDF]

I have another example on this very theme - applications that use the DSP3210 (in this case again in an emulated Quadra 840AV):

(I actually struggled quite a bit - it turned out that the acoustics of the microphone itself were a much bigger problem than anticipated)

 

[PappaDF]

As a complement to the dsp3210-sdk I posted about earlier, I've uploaded a Sail specification of the DSP3210 ISA:

https://github.com/pappadf/dsp3210-sail

Sail is a language for describing both instruction encoding and semantics of instruction set architectures - it's what the official RISC-V formal model is written in. The neat part is that the Sail compiler can even generate a working C emulator from the specification.

I mainly wanted it to have something to test the SDK against. A toolchain written based on one reading of a manual is self-consistent by construction, so a shared misreading passes every test it has. The SDK has a sail-crosscheck/ suite: a 37.5-million-word decoder-equivalence sweep, and lockstep co-simulation comparing full architectural state after every instruction.

Caveat: both repos are mine, so this isn't independent third-party validation. And as before, AI tools were used throughout.

Corrections welcome on either repo.

 

[terrier]

Figure this might be a decent place to ask, as these also used the 3210 - has anyone ever come across any shred of developer documentation for the Radius PhotoEngine DSP [daughter]cards?