exxos's Atari, Amiga & retro forum

Cyprian wrote: 27 Apr 2026 23:43 @Suavek plans to put DSP (56001 32Mhz and also 56002 66MHz) on the daughterboard in his Re-Falcon https://re-falcon.com/

DSP_ReFalcon.jpg

Smart move, and it makes perfect sense, then it can support the custom version used only in Atari Falcon as well as standard off the shelf versions.

I wanted to share that RVSND works fine on Hades with an ESS card.

artik-wroc wrote: 01 May 2026 08:18 I wanted to share that RVSND works fine on Hades with an ESS card.

Oh that's awesome, thank you for sharing!
I'm kind of hoping many of the things made for Raven will be usable on the other clones, where it doesn't take too much extra effort in doing so, but have no way of testing myself.

Does the Raven have any type of bus expansion port ?

As I was looking at audio related changes for Rev.A2 I stumbled across a misstake at the YM2149 stereo output mix.

Capacitors C601-C604, the four electrolytics near the audio jack, has polarity oriented the wrong way.

Should be pretty low risk and, I believe, the worst case being degradation over time.
Recommended would be to replace them with new ones oriented opposite of what the silkscreen says.
(I haven't done so myself and not panicing to do so - will do next time board has a reason to come out of the chassis)

peters wrote: 02 May 2026 08:59 Does the Raven have any type of bus expansion port ?

Only the ISA sockets, which of course limits how fast you could talk to that expansion device.

Unless you count the simm slots and venture into mad-scientist territory :)
Determined enough, one could put something else in one of them.
Or perhaps share something on SIMM3 since ROM doesn't use the entire 16MB address space of the slot.
(simm slots sit directly on 060 bus, meaning they are 32bit only with no support for dynamic bus-sizing)

Oh, and there is the i2c bus exposed on a header but probably not what you were asking for.


A real fast expansion slot would be nice for some future model.
I would want a VLB socket if doing a big-changes different machine rather than incremental revision upgrade.
Alternatively a custom socket but VLB could make sense for being able to use such graphics cards.

Not incredibly far off, the rest should (hopefully) be mostly easy routing for here.

At first I was planning on taking the quick route and just expose both ESSI ports on headers.
But seeing as I would want to use one for audio anyway it's better to just integrate that on the board directly.
Integrates better with the rest of the stuff, cleaner, and I wouldn't need to make a separate board.

So only ESSI1 is now on a header, and could be used for different expansions.
Most interesting usecase might be 3x fast SPI ports.
Or as a second external I2S audio in/out.

ESSI0 connects directly to onboard DAC + ADC and audio generated by the DSP should come out the same header (or jack) as usual.
The output from YM2149 can either mix directly on the output, or be told to take a detour through the DSP.
That could be quite interesting for playing around with Reverb or Chorus on the YM audio.
Or just for doing spectrum analysis and sending that data to the host for fancy graphs :)

@agranlund Based on the PGUSINIT v3.9.0 updates from PicoGUS source to work with v4.1.0 and above firmware and my modifications to make it Raven friendly, I have updated the Raven related source code and have submitted a pull request to add these updates to the Raven Github repository. Pull request does not include the PicoGUS firmware source code changes, only the PGUSINIT changes to create PGUSINIT.PRG (v3.9.0a Raven060).

So, my productivity has been boosted big time now that I've set up networking in both MiNT and MagiC.

In MiNT, my Synology shared folders mount automatically as NFS mounts and are aliased to drive letters, so I can use the NFS mounts as drives. Very cool.

MagiCNet just works. Gluestik allows STIK clients to work, and the iConnect gateway allows for the ASH programs to work. No mounted shared folders, though. But awesome.

I am yet again so impressed with the level of compatibility with the Raven. Super stable, and I run exclusively on CopyBack cache mode.

I have been running the latest release for a few days, and while everything works fine, there is a major bug in the SVGA drivers. I suspect it's the result of @agranlund tweaking for the performance gains earlier. I can confirm the performance gains, btw.

Attached is a zip containing capture footage of the issue I have with the updated drivers. I've only noticed it in the Boxkite file listing. Notice how, with the old drivers, the listing is cleared and updated when traversing folders. With the new drivers, the listing is updated only for the files that exist in the folder. If the previous folder had a long list, those files don't get cleared when entering a new folder. Super annoying.

I'm still running the latest RNOVA.PRG in Auto, so it's just the contents of SVGA that are causing this.

Atarian Computing wrote: 16 May 2026 06:45Super stable, and I run exclusively on CopyBack cache mode.

I was just telling @kodak80 the other day that yes, this should be Raven's default setting for TT RAM, all Atari computers (and clones) with 040+ assume that TT RAM is copy-back, this has been true for decades. So setting TT RAM as write-through is something which never should be done, it unnecessarily cripples your computer's performance.

From the top of my head I can't think of a case where this could be useful. The usual case, a program which runs from TT RAM and uses self-modifying code is not the case here because that is a instruction vs. data cache coherency issue which write-through mode wouldn't solve.