Raven. A homemade Atari-like computer

[agranlund]

Smiles and thumbs up from me too.
The reverb effect is ported from the Falcon DSP. Is it a case of playing back SND Player through an existing DSP realtime effects player, or is there more to it?

Yep, it came from an example in the old a56 package :)

On Raven, the output from the YM can switched to go into the DSP.
So this example is only loading a dsp program and letting that run, and it puts the effect on the whatever something plays on the YM.

I'm not sure how you would best accomplish the same on Falcon (I don't think the YM audio can be routed into DSP there?).
Perhaps an YM emulator inside the DSP would be the answer for something similar?
And then the host program would have to talk to that over the hostport rather than direct to real ym writes?

[dml]

I'm not sure how you would best accomplish the same on Falcon (I don't think the YM audio can be routed into DSP there?).
Perhaps an YM emulator inside the DSP would be the answer for something similar?
And then the host program would have to talk to that over the hostport rather than direct to real ym writes?

From what I remember, the YM audio path on Falcon is via the Codec A2D only (which can be demonstrated by changing the sampling rate and monitoring the effect on the YM output), so it can be routed towards the DSP on the input path of the crossbar at least. The DSP can be mapped to the Codec on the output path.

Not that I have tried this but I guess (by casting the appropriate runes at the crossbar) it should work.

[dml]

Yeah the relevant path is here - YM is mixed down to mono as AUDIOS.

This is then coupled to LIN2/RIN2 on the Codec, nowhere else. So it is always being digitized, in preparation for future Raven applications :D

ym.png

codec.png

[agranlund]

what was changed in DSP56001 asm in to run on DSP56303?

Not that much actually.
The DSP boot code is different since it has different things to set up, and the 56300 first-stage bootloader after reset expects a tiny header in the payload as opposed to the fixed 256 words the 56001 expects.
But then again this part is handled by the xbios rather than on the application level as long as you use Dsp_ExecProg

56001 dsp programs have a habit of starting at p:$40
56300 vector table is larger so a more suitable start address is p:$100, or possibly $80 if cramped on space since the last half are just user vectors.

interrupt vectors are different, as is the IO memory map, because the on-chip peripherals are not the same between 56001 and 56303.
Anything using SSI would need to be modified to use ESSI0 instead
Some of the more global registers have differences too. Interrupt enable and so on.

In terms of the actual hardware agnostic part of the code, which is the bulk of it, that runs unchanged (*)

(*) changed only because of toolchain differences.
I am using asm56k on my Mac as well as directly on Raven, so some work was done to port the dsp code which was written from a different assembler. not much, mostly just difference how macros work.

You could compile with asm56000.ttp or something else and it would be fine too, with one caveat;
asm56000.ttp tries to be helpful and wont reach the entire (bigger) IO area of 56300, spiting out error on code that is technically valid but wouldn't make sense on 56001. But for purely hardware agnostic code that doesn't touch IO you could still use it as long as you don't want any of the new 56300 instructions.
Motorolas asm56300 is windows only and wasn't ported to Atari as far as I know, so I'm sticking with asm56k for now.