Raven. A homemade Atari-like computer

[agranlund]

AROS on Atari/Raven would be interesting, but I wouldn't expect much.
Many Amiga applications use hardware registers directly, and expect specific Amiga hardware like copper, sound dma, blitter interrupts etc. Also Amiga hardware does not support Supervisor/User privilege modes, so applications and OS do not either. You can write to any hardware register in user mode as well as to protected addresses like $0.
But maybe @agranlund could adopt Castaway to this somehow.

I agree, expecting it to be something like an emulator that can run fun software would end up in dissapointment.
But it would still be interesting in the way EmuTOS on Amiga is interesting :)
As you said, any program expecting Amiga hardware would fail, same as if a GEM program expected Atari hardware under EmuTOS-Amiga.
Perhaps binary compatibility with some OS clean programs. Or at the very least very high source-level compatibility.

ExecBase always expected to live at address $4 wouldn't be a problem if one was ok with such Aros port requiring an MMU to circumvent that address being ROM on Atari.
Which is maybe fair, I think Aros-Amiga68k requires a fairly beefy 68k anyway to be usable?
With MMU you could also do hypervising to a degree, or as a way to protect hardware registers, but at some point I at least think that stops making sense and an emulator is a better choice -- if what you wanted was an emulator for running Amiga stuff, not an alternative OS that is source-level compatible with (some) Amiga stuff :)

EmuTOS has been used for some homebrew 68k computers needing an OS. Haven't seen Aros68k used in the same way, perhaps it's more of a beast to port.

[Mikerochip]

Last time I checked (and before the Apollo/Vampire fellas got involved, and forked it) Aros68K was unusable, really, on a 68K machine.
IDE was dog slow. (about floppy drive speed, if memory serves).

I vaguely recall though, talk of a patch though....

It might be an open source Amiga OS, but, it's nowhere near EmuTOS level of usability or compatibility.
(Or wasn't, anyhow)

[agranlund]

Last time I checked (and before the Apollo/Vampire fellas got involved, and forked it) Aros68K was unusable, really, on a 68K machine.
IDE was dog slow. (about floppy drive speed, if memory serves).

I vaguely recall though, talk of a patch though....

It might be an open source Amiga OS, but, it's nowhere near EmuTOS level of usability or compatibility.
(Or wasn't, anyhow)

Ah, didn't know that :)
I've only used the Apollo fork on a Vampire (and the x86 version a long time ago)

[Mikerochip]

As a matter of interest, do you know if the Apollo fellas do upstream patches?

I'm not really an Amiga fan, but, I do have an A2000/500/600/1200. Because.... Reasons :P

[Oldskool]

Blasphemy!!


It's big, bulky, slow and ... ???

A dx2 Blasphemy? No it’s heresy… Heretic i mean and Doom.

[Badwolf]

We need an Amiga emulator :lol:

I've "run" UAE under Basilisk on an 030 Falcon...

BW

[PhilC]

We need an Amiga emulator :lol:

I've "run" UAE under Basilisk on an 030 Falcon...

BW

Multiple nested emulators :D

[agranlund]

Updated release package, these are the recent changes:

Code: Select all

20260215:
  rvnova:   added settings file
  rvbios:   updated nova settings panel
20260213:
  rom:      updated EmuTOS (#65a71f3 @ 20260202)
  rvnova:   better 1280x720x8bpp quality on Cirrus
20260209:
  rvnova:   1280x720x8bpp for Cirrus and WDC

I would upgrade these:

• either delete and replace entire c:\nova folder or:
  • delete c:\nova\default
  • update c:\nova\svga

• update c:\auto\rvnova.prg

• update c:\auto\rvbios.prg

• delete c:\auto\xmenu.inf

• update c:\rvga.inf

There's not that much changed in EmuTOS since last time. Mainly looks like fixes for playing nice when multiple disk drivers are active at the same time and in charge of different drives.


For now c:\rvga.inf doesn't contain very much but there is an mclk setting under the Cirrus section that can be fun to play with (@Atarian Computing )

Some vgabios can be quite conservative by default and my GD5434 can be overclocked to $2c before starting to poop pixels on the screen.
I saw that old Xfree86 mentions clocking up the '34 to $22 by default so I'm assuming most of them should handle at least that -- but our driver just leaves it at whatever the vgabios wanted unless you specifically set it to something in rvga.inf

[Atarian Computing]

For now c:\rvga.inf doesn't contain very much but there is an mclk setting under the Cirrus section that can be fun to play with (@Atarian Computing )

Some vgabios can be quite conservative by default and my GD5434 can be overclocked to $2c before starting to poop pixels on the screen.
I saw that old Xfree86 mentions clocking up the '34 to $22 by default so I'm assuming most of them should handle at least that -- but our driver just leaves it at whatever the vgabios wanted unless you specifically set it to something in rvga.inf

Oh! Very cool. I played around with it and turns out that my initial clock was less than $1c it seems as the following shot show some gains at $1c compared to previous stock.

1c.png

Looks like $22 is the max my card can do without artefacts (that I can see so far).

22.png

This is exciting. Can't wait for what's next.

[agranlund]

SVGA driver now has rudimentary and very work in progress support for Tseng ET4000AX and W32 cards.
Had some card laying around that wouldn't work with any of the NOVA Tx drivers, but works with this.

Was quickly put together and there are many limitations compared to the real ones:
- no hardware acceleration on w32
- no support for 16bpp or higher
- no 1280x720 yet
- 1024x768 is sketchy, my card goes to 84hz interlaced. Driver force progressive but that means 42hz which is not great but still better than interlaced which wont work on the lcd anyway.
(measuring and picking a faster clock, if available, for proper 60hz at >1024 resolutions would be next on the list of what this driver needs)

But other than that.. should hopefully just work and maybe it's of some use, or maybe not :)