exxos's Atari, Amiga & retro forum

yes, mainly smaller things;
- usb keyb/mouse
- sotware controlled volume for the ym output
- small amp and header for internal speaker
(mute control is Falcon compatible)
- ide port is now big endian
- pwm fan control
- argb lighting header
- and misc other minor things


The biggest change and what takes most space is the added DSP, and the RAM for it.
Which is not mandatory and the computer should work fine without it soldered.

For now, I've routed its two ESSI ports to one internal header each
That part is not set in stone but I don't know exactly what I want to do with them so this would provide an easy way to experiment.

One ESSI could for example be an I2S audio in+out, or provide three individual SPI ports.
Or something else entierly but realistically that's probably how you'd want to use them.

If I were to 'hardwire' it I on the board I would probably do something like that:
One SPI controlled codec for audi in + out, and then two SPI headers for playing around with random SPI modules (wifi perhaps?)

OpenOCD has support for its Jtag/OnCE debugger interface so that's on a header too.

Did you add a "clear" jumper for Nessi?

And/or maybe a diode, and header for it's JTAG, to let us program it inplace?
What with 3M discontinuing those sockets, probably better not to stress them in future...
AND. We (by which I mean I) can leave an RPi zero in situ, for programming :D

Actually, did you ever work out the lockups you were having with the I2S?

Mikerochip wrote: 26 Apr 2026 14:30 Did you add a "clear" jumper for Nessi?

And/or maybe a diode, and header for it's JTAG, to let us program it inplace?
What with 3M discontinuing those sockets, probably better not to stress them in future...
AND. We (by which I mean I) can leave an RPi zero in situ, for programming :D

Actually, did you ever work out the lockups you were having with the I2S?

You already have a JTAG header for programming Nessi.
It's in the top-right just above the chip and I leave my ATDH1150USB programmer plugged in.

An easy 'unlock' jumper would require too much hassle in getting a 12V trace up there so I dismissed it as not worth the effort.
Especially since you generally don't need it, and if you were able to build the board then a hotwire cable from a fan header should be a breeze anyway.

Ah, I just wondered if you'd looked at it, (the 12v) was all :P
It's only really necessary, if you do repurpose those 4 pins...

OK! Sounds ... fairly impressively rounded out, then.

Mikerochip wrote: 26 Apr 2026 15:45 Ah, I just wondered if you'd looked at it, (the 12v) was all :P
It's only really necessary, if you do repurpose those 4 pins...

OK! Sounds ... fairly impressively rounded out, then.

Ah, I see what you mean now!
Using the pins for other purposes? Yes that would indeed require an easy and convenient way rather than hotwiring.
I think for this version there are enough pins available, but maybe worth to keep in mind for future stuff.

Whaat, DSP?! That's exciting :) Tell us more!! :D

Is it a DSP56001? Would it then possibly be Falcon-compatible with SW utilising the DSP but not doing low-level graphics (directly via the VIDEL)?

Edit: Just saw that you already committed the changes to Github, and that it's a DSP56303 :) But given that it says that it's object code compatible with DSP56001 are you hoping for some level of Falcon compatibility still?

@agranlund wow, DSP is a big step forward. I wonder if the 56001 Falcon's code will be compatible with 56303 or if it requires modifications.

redpixel wrote: 26 Apr 2026 18:25 But given that it says that it's object code compatible with DSP56001 are you hoping for some level of Falcon compatibility still?

good question, but it may be problematic due to the lack of the DMA channels and the Matrix (where DMA channels are routed between RAM/DSP SSI/DAC/ADC/Ext DSP port).

Cyprian wrote: 26 Apr 2026 21:46 @agranlund wow, DSP is a big step forward. I wonder if the 56001 Falcon's code will be compatible with 56303 or if it requires modifications.

redpixel wrote: 26 Apr 2026 18:25 But given that it says that it's object code compatible with DSP56001 are you hoping for some level of Falcon compatibility still?

good question, but it may be problematic due to the lack of the DMA channels and the Matrix (where DMA channels are routed between RAM/DSP SSI/DAC/ADC/Ext DSP port).

I had a debate in my head around this and eventually comitted to DSP56303 which I think makes sense after factoring in all the things I could think of.


DSP56301 is arguably better in that it has a full 32bit host interface.
But the existing layout doesn't lend itself to routing a full branch of the entire bus out that side of the board. Should have been designed in from the beginning in that case.
The 8bits required for the DSP56303 host interface was already going out that way for the UART so 56303 (or older) is a good match given it being an incremental update to an existing board.


While the 56303 is object code compatible, I figure being able to run as-is dsp binaries isn't so crucial or even attractive for these reasons:
- to be sure you'd need the same dsp ram amount, layout and shadowing quirks as Falcon also.
- very likely the same cpu-side memory mapping of the DSP as Falcon too, since some host-side code might not go through xbios
- Falcon host-side code that is using the dsp, probably needs a Falcon for reasons other than the DSP also
- Some dsp stuff (probably) relies on exact cpu/dsp relative timing. eg, to push/pull data when stuff is 'known' to be ready on a configuration that is exactly an Atari Falcon, rather than spend cycles asking if things are ready.
- some dsp stuff that makes sense on a 16mhz Falcon stops being attractive on CT60 or similar.
- Falcon DSP code would audio-out in a different way than I would have anyway

So why even the DSP56303 then?
If not binary compatible with existing Falcon DSP binaries then one could argue that a TMS320C DSP with floating point would be a far better choice.
I was considering one of those at first but the following won me back to DSP56xxx

- easy-ish to port existing DSP56001/2 code
- the ability to compile DSP code on the machine itself. this is a big one
- I have a motorola badge on the chassis - if computer gets a DSP then of course it has to be one from Motorola :)


Limitiations and such:

- 8bit host port, so a quarter of the bandwidth compared to ram/rom but potentially one less waitstate. still pretty good.
- 384kb DSP ram. I did not bother adding the complexity of being able to make a 96kb memory layout like on Falcon, for most of the reasons above. If you're in the position of being able to port DSP code from source then you wont need that kind of help.
And if you're porting from say, Amiga Delfina (DSP56002) sources, then it's not at all relevant since they use a different memory layout than Falcon anyway.
- DSP56303 is about twice as fast as DSP56001 given the same clock. Has much more fast internal ram and instruction cache.
- input clock is going to be 22.5792Mhz which gives:
~90 Mhz core clock with pll set to x4
~112 Mhz core clock with pll set to x5 (overclocked)
divides down cleanly to the 44.1khz audio family for i2s

It feels like it could be a pretty good matchup with a 100-ish mhz cpu.
Neither too slow nor too fast to make thematically sense.

Personally I'm mostly interested in playing with it for doing 3D transform+lighting while CPU does something else.

And to make audio out of course. Will require some simple DAC board that would plug into one of the ESSI headers.
Or just dupont wires from the header to a breadboard and play with stuff there :)

@agranlund Have you considered something like putting a header for the DSP on instead of picking a single one?

If you did put a set of pin headers on the other side of the board, like the wiztronics dev falcon, you could potentially add a different kind of DSP, depending on what you want...

Or even a dsp isa card?
Or, is there not enough signals on the ISA bus? Would it need to be more tightly integrated with the CPU?

Mikerochip wrote: 27 Apr 2026 14:53 @agranlund Have you considered something like putting a header for the DSP on instead of picking a single one?

If you did put a set of pin headers on the other side of the board, like the wiztronics dev falcon, you could potentially add a different kind of DSP, depending on what you want...

Or even a dsp isa card?
Or, is there not enough signals on the ISA bus? Would it need to be more tightly integrated with the CPU?

Yes you can very easily put a DSP563xxx on an ISA card.
The chip has mode-pins that you wire up to specify what bus mode it should use and ISA is one of them.
(I've just wired it to for 68k bus mode since it sits directly on the 060 fast bus)
The benefit of having it where I have it is for speed mostly.


And a little bit to also knowing it's that exact one. Fixed hardware always makes it easier to integrate with hardware and software / drivers.

Even if the motorola ones kept object code compatible, they do have different features, register sets and memory maps (due to different internal sram sizes).
So I would probably think of it a bit similar to; a piece of generic 68k code can run on both Atari and Amiga no problem because the cpu is the same.
But as soon as the code tries to access things not internal to only CPU core you are toast.

Going from 560xx to 563xx means the old SSI port is gone. Replaced by the more advanced ESSI ports.
So if you have dsp code that outputs audio then that may need to be modified unless they kept the old registers the same, emulating the same behavior on ESSI (I don't actually know this - but the same would need to be investigated for any feature which isn't strictly the dsp-core just running instructions)


Wizztronic doing a header for DSP is really cool though.
Then it could be fitted with a card with something beefier, and if needed some external logic to translate back and from what the header expects (guessing DSP56001 style pins)