Raven. A homemade Atari-like computer

[arf]

[…]
I have it configured for writethrough rather than copyback cache.
Copyback is faster of course but at this moment, for me, I don't feel the gain is worth the hassle and uncertainty of what software may or may not crap out because of CB.

Thank you! Is the challenge in hard-/firmware, or towards the OS? MagiC is used to be run in Writeback mode, AFAIK (040 on the Macs, Milan?).

[agranlund]

Thank you! Is the challenge in hard-/firmware, or towards the OS? MagiC is used to be run in Writeback mode, AFAIK (040 on the Macs, Milan?).

It's more me not wanting to introduce another unknown, as well as not having enough experience to know which Atari programs to avoid when using CB.
EmuTOS and MiNT themselves are completely fine with copyback but some Atari programs may not be and can cause issues if they modify cache setting without flushing the CB.
XControl is one of them, though the version that was patched to work on CT60 with copyback enabled can be used on Raven too.
Gembench doesn't like it either.

It's set up so you can change cache mode independently for the ST and TT ram regions through the bios menu so the ideal setup is probably to have writethrough on ST-RAM and copyback on the larger TT-RAM area.
That way you could force copyback incompatible programs to run from ST-RAM. Or that was the thinking anyway, right now I'm quite happy with the speed as-is so for now I'm playing it safe with writethrough on all memory.

[mikro]

the ideal setup is probably to have writethrough on ST-RAM and copyback on the larger TT-RAM area.
That way you could force copyback incompatible programs to run from ST-RAM. Or that was the thinking anyway, right now I'm quite happy with the speed as-is so for now I'm playing it safe with writethrough on all memory.

It's not only ideal, it is also a necesarry setup. ST RAM must be WT because otherwise nothing would work - write access to video ram, sample playback etc. So CT60 does the same and so does the FireBee.

However I'm shocked that you have settled for WT in TT RAM, so much performance gone, oh no! I've been using CT60 hardware for 20+ years now and I have never had a memory issue which couldn't be solved by "run/allocate from ST RAM only".

[agranlund]

It's not only ideal, it is also a necesarry setup. ST RAM must be WT because otherwise nothing would work - write access to video ram, sample playback etc. So CT60 does the same and so does the FireBee.

However I'm shocked that you have settled for WT in TT RAM, so much performance gone, oh no! I've been using CT60 hardware for 20+ years now and I have never had a memory issue which couldn't be solved by "run/allocate from ST RAM only".

I agree. One of these days I should toggle CB back on for TT RAM.
I'm slightly hesitant in making it the default setting since I'm going to feel responsible for the burden of explaining CB, its potential incompatibilities with random programs, how to run in ST-RAM and so on.

[agranlund]

Just added a Windows-esque OPL Midi driver to the release package.
It'll work with anything that plays midi using the standard Atari bios API and can be found in "raven/drivers/oplmidi".
(ie; it works with the mxplay midi plugin, piano player, doom, scummst and any other cleanly written midi program)

Useful if you want midi music but don't have a wavetable card or external synth, or if you're just a weirdo like me and enjoy how (crappy) midi sounded through a Soundblaster or Adlib card in Windows3/95

Tested on a Soundblaster clone with OPL3 but should hopefully work on OPL2 based cards too.
(it should work on ISA equipped Atari's other than Raven too)

[mrbombermillzy]

(it should work on ISA equipped Atari's other than Raven too)

Great work!

... or if you're just a weirdo like me and enjoy how (crappy) midi sounded through a Soundblaster or Adlib card in Windows3/95

Thats called nostalgia!

[kodak80]

Just added a Windows-esque OPL Midi driver to the release package.
It'll work with anything that plays midi using the standard Atari bios API and can be found in "raven/drivers/oplmidi".
(ie; it works with the mxplay midi plugin, piano player, doom, scummst and any other cleanly written midi program)

Useful if you want midi music but don't have a wavetable card or external synth, or if you're just a weirdo like me and enjoy how (crappy) midi sounded through a Soundblaster or Adlib card in Windows3/95

Tested on a Soundblaster clone with OPL3 but should hopefully work on OPL2 based cards too.
(it should work on ISA equipped Atari's other than Raven too)

Thank you for this.

It was the missing piece for the PicoGUS v1.2 (self-build) which doesn't have a wavetable onboard.

The PicoGUS v1.2 in GUS mode passes MIDI through the MIDI TRS 3.5mm connector and needs an external MIDI device.

In SB mode, the Pico onboard processes the MIDI through OPL and audio is output through the onboard DAC 3.5mm output. I have now confirmed that my v1.2 boards work in the Raven.

[agranlund]

In SB mode, the Pico onboard processes the MIDI through OPL and audio is output through the onboard DAC 3.5mm output. I have now confirmed that my v1.2 boards work in the Raven.

Nice! Thank you for confirming on the Pico v1.2

[agranlund]

Some very quick hacking about with a Gameboy emulator.

It's not a super high-performing emulator out of the box (Gnuboy) but very portable and the speed appears quite good after only some minor tweaks.
I still have sound disabled though and I'm considering if I should perhaps let OPL or maybe even YM approximate the Gameboy sound chip rather than generating PCM data from an accurate emulation of it. I saw there was an emulator really going for speed on 386/486 do that with OPL.

Anyways, playing this again was a blast from the past to say the least... 26 years ago!

raven_pm1.jpg (29.36 KiB) Viewed 702 times

raven_pm2.jpg (16.92 KiB) Viewed 702 times	raven_pm3.jpg (16.68 KiB) Viewed 702 times

I'm obviously partial, and full of nostalgia, but I think it was quite neat for what it was. Basically a Puyo-Puyo clone but with the addition of items, environmental puzzles and sometimes a bad monster.
What I remember most was hardcoding all the level-specific logic/script in z80 assembly, one by one and for all 50 levels.
I did make an MS-DOS based level editor but it was mostly for layout and the core common stuff.

I think I was averaging some 3-5 levels per evening depending on complexity before I had to go to bed since I had a "normal" day-time job too while working on that game.. Good times indeed!


Update: oh wow, apparently sells for quite a chunk nowadays due being fairly rare. Funny since I think it didn't sell all that well back in the days.
I need to take better care of mine.. I think I have one or two copies still in shrink-wrap somewhere in my "box-of-old-junk"

[mikro]

Whaaat :-O You are full of surprises.