Raven. A homemade Atari-like computer

[PhilC]

I did have a quick look at the new PCB, is there a network chip built in this time too?

Looks great btw.

[dml]

$A0000C14 TXH/RXH
$A0000C18 TXM/RXM
$A0000C1C TXL/RXL

Ok, so the bytes are separated.

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.

Well I started writing a reply about bus sizing and 060's - then remembered there was a 68150 present - then wasn't sure how it works at all on a CT60 already without one.... and the detail below re: speed - and just deleted everything I had started writing. :)

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)

Yes pretty much. It's not going to make a big difference on 060 given most of the time will be sunk in the hostport itself.

Even on the Falcon with word/long move, the separate byte transfers underneath mostly dominate whatever you try to do to optimise it (not completely - since the 030 isn't all that fast - but still the slowest part is the 3 exchanges).

[mikro]

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
 ...

(ignoring the later clarification from Anders)

Does it really make sense to use hostport this way? I mean except P56 upload, it is usually much better to have your data prepared as 0x00HHMMLL and do a simple move.l (a0)+,(a1), isn't it.

[dml]

Hi Mikro,

For a 'baked' transfer, the results for a base Falcon are slightly in favour of the packed triplets with d-cache enabled. Keep in mind that you are reading effectively 25% more memory the other way - for anything more than a few words at a time - and from STRam that is expensive.

send 24bit (packed) -> 2.438 MByte/sec
send 24bit longs -> 2.318 MByte/sec
send 16bit words -> 3.034 MByte/sec

The difference is small but already measurable with Videl blanked. If using the hostport in 16bit colour or even 256c modes, they are skewed further because the instruction overheads shrink vs bus access.

The fastest method by some margin is 16bit move.w with d-cache disabled but this requires different code on the DSP side to capture it, if reassembling 24bit words. The reason for the speedup is losing the redundant bus-scaled byte transaction for the top byte.

On 68060 though things are different and probably also between Raven vs CT60 as I'm sure there is something funny going on with the latter to handle the byte ports.


It is also worth noting that many DSP/CPU transfers (for non-audio/non-streaming things at least) can involve temporary register state instead of memory blocks. That will be a bit more tricky here with extra swaps/rols etc. instead of just move.l/move.w - but again on 68060 much of that will just disappear into the exchange cost.


It will be interesting to see what the work-sharing profile could look like with DSP on a Raven and what things it will be good at vs the 060. The CPU has the benefit of a convenient floating point multiplier which is decently fast but it is not as bulk-efficient as the DSP multiplier if there is data to perform enough work on. I have a few ideas to try already but the obvious obstacle is building a whole new board :)

[mikro]

@dml oh you are completely right, I didn't think of "absorbing" the addq.l by bus access.

To be honest, reading about the DSP, especially the DSP we had been all dreaming about since the 90s... that really shakes my "beautiful but still an Atari clone" POV. ;-) @agranlund: that was an evil move, really. If Raven A3 gets Videl compatible graphics then I'm really pissed. ;-)

[agranlund]

I did have a quick look at the new PCB, is there a network chip built in this time too?

Looks great btw.

Thanks!
It did use to have a network chip onboard but then I got into my head I wanted some kind of multi processing to play with so it went out in favor of the dsp.
I figure the isa card with CF + extra IDE header will have an rtl8019 onboard anyway.

[Mikerochip]

Anyone keeping an eye on PicoMEM?

And, then, by extension, this!
https://github.com/ianhan/picograph

Pico based ISA video card!
The last update emulates a Cirrus Logic CL-GD5429

But, not just emulates it, gives some interesting hardware outputs, too.


And, unrelated!
Anyone trying the Silmarlis SDL engine?
https://www.atari-forum.com/viewtopic.p ... 0&start=25


... I should *really* get my ass in gear, and sort out RAM! One way, or the other! My board has been built for ... months now! :lol: :oops:

[agranlund]

So apparently Analog Devices has told all distributors that their products can no longer be sold to private individuals, only B2B sales.
And Mouser is complying with it.. meaning they happily accepted the order of my whole bom in the web interface and a day later emailed me saying they cancelled the four ADI parts from it.
Annoying, since I already ordered my board not expecting that.

Found several reports about this and Mouser specifically mentioned but no clear yes/no about Digikey or the other larger ones so I sent an order to Digikey and hope they'll send me those parts.
Otherwise, LCSC does stock some of these and I'm half assuming they wont care what Maxim says and will sell to anyone.

There is a drop in replacement for MAX3245 from Renesas but the remaining three items I should probably replace in some future revision if there is one, and then never touch ADI parts again as a hobbyist.
DS1307
DS1818R
MAX16054


But at least this is exciting:
Fingers crossed it actually works and my luck didn't run out with Revision A1 :lol:

Screenshot 2026-06-01 at 21.27.05.png

[Mikerochip]

So apparently Maxim has told all distributors that Analog Devices products can no longer be sold to private individuals, only B2B sales.

That's *really* annoying. :( Similar happened when I tried to order some meanwell PSUs earlier in the year/late last year.
Was told they wouldn't sell to an individual. (Both Mouser and Farnell)
Then, was told on the second attempt, they would, but, only if you had a registered VAT number.
(I can't remember which said they would, on the second attempt. One definitely still wouldn't)

Time for a Revision A1b and A2b, I think @agranlund
:|

[agranlund]

That's *really* annoying. :( Similar happened when I tried to order some meanwell PSUs earlier in the year/late last year.
Was told they wouldn't sell to an individual. (Both Mouser and Farnell)

Super annoying when they do this.

At least it looks like Digikey shipped my order no questions asked. And several other non-mouser places stock them, so I'm not going to stress about doing any rev changes at this point - but still worth a note-to-self about getting rid of ADI stuff.

In terms of replacing them it doesn't look as bad as I initially thought.

MAX3245:
ICL3245 drop in replacement

DS1307:
MCP7941x series and probably several other i2c RTCs of same size and pinout.
MCP79411 is especially interesting since it come with pre-programmed mac address in eeprom, making U407 and C415 redundant from A2 bom.
1k eeprom on top of the battery backed sram is a nice-to-have as well, making these arguably much more interesting than the old DS1307 anyway.
Software side would be different for all of them but since that is hidden in raven bios code and transparent for TOS and application code, that doesn't matter much.

DS1818R:
no direct drop in for this particular variant.
but several 4pin chips with same functionality exists from other manufacturers. eg, MIC6315
very small schematic and board change.

MAX16054:
don't know about similar chips. perhaps easiest to replace with 74 logic and few passives.