Raven. A homemade Atari-like computer

[agranlund]

Yes, I agree, it makes sense to have it on by default.

The difference is not at all the same as you'll be used to from CT60 but still very much worth it.
Synthetic write benchmarks will likely show CB as slower than WT but on average and running applications it'll be a win.
The cache-hit performance offsets the worst-case penalites and on average you'll end up on top.
Less on top, on average, than on CT60 but still so.


Not sure if this is at all interesting;

I'm assuming CT60 can burst write cachelines in the style of x,y,y,y where x is the longer initial waitstate and y are faster subsequent bursts.
Raven, being the scruffy black sheep of the birds, of which i have no shame :) , will do x,x,x,x for that same cacheline write.

Actual numbers are surely different but lets use 4,1,1,1 for illustrative purpose.

Worst case CB penalty = you only write 4 bytes to a line, before it is evicted because cpu needs it for somewhere else.
= you paid for 16bytes of bus access for 4bytes of data

CT60 ends up with less of a CB penalty here:

Code: Select all

CT60 CB: 4,1,1,1 = 7
CT60 WT: 4       = 4

RAVN CB: 4,4,4,4 = 16
RAVN WT: 4       = 4

Sequence of linear longword writes.
CT60 benefits. Raven does not.

Code: Select all

CT60 CB: 4,1,1,1 = 7
CT60 WT: 4,4,4,4 = 16

Ravn CB: 4,4,4,4 = 16
Ravn WT: 4,4,4,4 = 16

In short, Raven does benefit massively from CB cache-hits, as in writing to same mem locations several times before their line ends up evicted, but only that. It does not share the other benefit, and the worst-case penalty is larger.

Luckily, programs have a habit of writing to the same memory locations rather than randomly and scattered all over the place.

I run mine with CB for the TT-RAM region and it probably makes sense if that was the default setting.

[agranlund]

actually the numbers posted above are 'nicer' than reality since the line would fill first before the write in the worst cases.

worst case. writing 4 bytes, no reuse before line evicted:
clear win for WT on both. but this is a very low-frequency scenario other than if benchmarking specifically for it.

Code: Select all

CT60 CB: 4,1,1,1,4,1,1,1 = 14
CT60 WT: 4 = 4

RAVN CB: 4,4,4,4,4,4,4,4 = 32
RAVN WT: 4 = 4

linear write at least 16 bytes, also not considering reuse:
fairly common if your're just copying data from a to b.

Code: Select all

CT60 CB: 4,1,1,1,4,1,1,1 = 14
CT60 WT: 4,4,4,4 = 16

Ravn CB: 4,4,4,4,4,4,4,4 = 32
Ravn WT: 4,4,4,4 = 16

even with those numers you still come out usually a little bit on top (*) on average with CB instead of WT on Raven.
i suppose memory is generally re-used enough before evict to make up for the fairly large CB overhead.
(*) non scientifically tested. purely based on Gnuboy running faster with CB enabled :)

Wonder if it's maybe worth testing real-world use with CB but with WA disabled?
So only triggering cacheline fills on reads. Meaning write to a non-cached line ends up the same as WT, while if something already touched the area for a read then writes to it will behave like CB)
That makes no sense for a CT60 but might do on machines with no burst benefit to offset the CB cost like Raven.

[agranlund]

Rev.A2 "done", as in schematic, routing, ERC and DRC.
I'll let this sit for a week or so and come back with completely fresh eyes for the final sanity checks before ordering myself a board.

@Atarian Computing , is it ok that I use your raven picture on the silkscreen there in the bottom right?

Screenshot 2026-05-24 at 18.13.40.png

[Atarian Computing]

Rev.A2 "done", as in schematic, routing, ERC and DRC.
I'll let this sit for a week or so and come back with completely fresh eyes for the final sanity checks before ordering myself a board.

@Atarian Computing , is it ok that I use your raven picture on the silkscreen there in the bottom right?

Oooh, nice. Of course it's ok! I'm honored :)

[dml]

...have been distracted with Transputers but...

- is the DSP host port on rev A2 wider than 8 bits?
- if not, are the 8bit fields mapped contiguous as they are on Falcon, or separated as with the StarTrack/TT DSP board? contiguous is good.
- is there a DMA path to/from the DSP? (I guess this one is a no but curious anyway)

:)

[agranlund]

...have been distracted with Transputers but...

To say I'm a little bit jealous is an understatement :)

- is the DSP host port on rev A2 wider than 8 bits?
- if not, are the 8bit fields mapped contiguous as they are on Falcon, or separated as with the StarTrack/TT DSP board? contiguous is good.
- is there a DMA path to/from the DSP? (I guess this one is a no but curious anyway)

The host port is only 8bit on the 56303. The bigger brother 56301 has a 32bit host port but I deemed it too impractical to try and retrofit on the existing layout as an incremental rev update.

Host port registers are memory mapped longword aligned from the cpus point of view (D31-D24)
Accessing register $7 triggers the actual transfer. I haven't used the 56001 but I believe it's similar or the same?

$5 RXH/TXH Receive/Transmit High Bits 23-16 of 24-bit word
$6 RXM/TXM Receive/Transmit Mid Bits 15-8 of 24-bit word
$7 RXL/TXL Receive/Transmit Low Bits 7-0 of 24-bit word

Base clock is 22.5792mhz which divides neatly to 44.1khz audio family. With PLL multiplier set to 4 you end up with a 90mhz core clock which is within specs. Multiplier 5 would make 112mhz which is >10% overclocked but I have no idea how well these things take to overclocking.
There is no cpu<->dsp DMA. Though the 56303 has 6 internal DMA channels and the host port is double buffered. If I read the manual correctly you should be able to set up a DMA channel to automatically have it move data into a dsp-ram ringbuffer as it enters the host port, and the other way around.

With that, I assume you'll be able to hammer the host port quite fast albeit of course limited by the narrow width.

External ram is 64kword shared by Y and P and another 64kword for X.
Internal ram is 8kword total with the X,Y,P segments somewhat configurable.

To avoid some transfer penalty I'm guessing you probably want to pre-upload some frequently used stuff to DSP ram.
Maybe vertices in modelspace. Send matrices over, run T&L and bring back worldspace or screenspace result depending on what kind of sorcery you're doing?

I'm really quite hyped to play around with that thing and I suspect there's a risk you'll get tired of me asking DSP programming questions, in which case feel free to tell me to go away :)

[dml]

Thanks for the detailed reply...

The host port is only 8bit on the 56303. The bigger brother 56301 has a 32bit host port but I deemed it too impractical to try and retrofit on the existing layout as an incremental rev update.

Ok that makes sense yes.

Host port registers are memory mapped longword aligned from the cpus point of view (D31-D24)
Accessing register $7 triggers the actual transfer. I haven't used the 56001 but I believe it's similar or the same?

That seems to be the same as with the Falcon so it also helps. :)

It's normally possible to write longwords and hit all 3 registers at once, with the low byte triggering transfer for all 3. With this you can transfer 3 bytes at a time, with something like:

Code: Select all

 move.l (a0),(a1)   ; copy src to host24
 addq #3, a0        ; inc src
 move.l (a0),(a1)   ; copy src to host24
 addq #3, a0        ; inc src
 ...

...which works ok on 030+ with the datacache enabled. or this, with dcache in either state...

Code: Select all

 move.w (a0)+,(a1)   ; copy src to host16
 move.w (a0)+,(a1)   ; ...
 move.w (a0)+,(a1)   ; 

Base clock is 22.5792mhz which divides neatly to 44.1khz audio family. With PLL multiplier set to 4 you end up with a 90mhz core clock which is within specs. Multiplier 5 would make 112mhz which is >10% overclocked but I have no idea how well these things take to overclocking.

The 56001 seemed to be pretty good for OC margin but no idea about these :)

There is no cpu<->dsp DMA. Though the 56303 has 6 internal DMA channels and the host port is double buffered. If I read the manual correctly you should be able to set up a DMA channel to automatically have it move data into a dsp-ram ringbuffer as it enters the host port, and the other way around.
With that, I assume you'll be able to hammer the host port quite fast albeit of course limited by the narrow width.

Interesting.

External ram is 64kword shared by Y and P and another 64kword for X.
Internal ram is 8kword total with the X,Y,P segments somewhat configurable.

That's already a huge improvement over the 56k. Trying to fit everything there was always tough. Even just adding some tables could put a lot of pressure on space for code or buffers.

To avoid some transfer penalty I'm guessing you probably want to pre-upload some frequently used stuff to DSP ram.
Maybe vertices in modelspace. Send matrices over, run T&L and bring back worldspace or screenspace result depending on what kind of sorcery you're doing?

Yes this will help. In the last thing I worked on, the scene had to be partly organised on the host side to minimise state changes, transfer only meaningful changes (including a change in transform, if any), then draw geometry affected by that state and so on. Being able to retain things on the DSP side reduces the need for some of that.

I usually try to build a spanbuffer on the DSP so the last thing which is returned in spans to draw, in a chain. However its a constant fight for space to collect that much data on the DSP side and flush it out. It so far has required programs to be upload in pieces as overlays, between stages of drawing - with just intermediate buffers persisting between stages - all due to lack of space.

The more RAM there is, the easier it is to organise what happens in each stage and when stuff has to be returned, or just keep code between stages instead of replacing it.

I'm really quite hyped to play around with that thing and I suspect there's a risk you'll get tired of me asking DSP programming questions, in which case feel free to tell me to go away :)

It should be a lot of fun. Looks like now I will need to build *another* Raven :)

I'll be happy to help with any questions (feel free to ping me!) but I'm sure you'll have figured out most of it as you move things along anyway!

[Cyprian]

It's normally possible to write longwords and hit all 3 registers at once, with the low byte triggering transfer for all 3. With this you can transfer 3 bytes at a time, with something like:

Code: Select all

 move.l (a0),(a1)   ; copy src to host24
 addq #3, a0        ; inc src
 move.l (a0),(a1)   ; copy src to host24
 addq #3, a0        ; inc src
 ...

...which works ok on 030+ with the datacache enabled. or this, with dcache in either state...

Code: Select all

 move.w (a0)+,(a1)   ; copy src to host16
 move.w (a0)+,(a1)   ; ...
 move.w (a0)+,(a1)   ; 

How does this byte transfer work for "move.l" ? Does Falcon's DSP or the PAL itself tell the CPU that the HostPort is 8bit and the word/longword must be split?

[agranlund]

Code: Select all

 move.l (a0),(a1)   ; copy src to host24
 addq #3, a0        ; inc src
 move.l (a0),(a1)   ; copy src to host24
 addq #3, a0        ; inc src
 ...

Host side memory map will look somewhat like this:
$A0000C00 ICR
$A0000C04 CVR
$A0000C08 ISR
$A0000C0C IVR
$A0000C10 ----
$A0000C14 TXH/RXH
$A0000C18 TXM/RXM
$A0000C1C TXL/RXL

Having the DSP on the 68150 bus would have been convenient from a programming perspective as it could have looked like exactly as on Falcon with the 030's built-in bus sizer.
But physical placement forces it on the 060 bus, so no dynamic bus sizing available.

probably, you end up with a small loop like this?
with the instructions and branch in cache, and a sourcedata L1 miss every 16'th byte.
in Raven's case, this is probably not worse than than letting the sizer split a move.l write into individual byte cycles.

move.b (a0)+,(a1)
move.b (a0)+,(a2)
move.b (a0)+,(a3)

[agranlund]

How does this byte transfer work for "move.l" ? Does Falcon's DSP or the PAL itself tell the CPU that the HostPort is 8bit and the word/longword must be split?

I'm probably the wrong person to answer since I don't even have a Falcon but I'd guess some part of Falcons bus logic knows the DSP is an 8bit peripheral and DSACK's the cpu for that size. Then the 030's built-in sizer would end up splitting the move.l into four individual bus cycles.