| |
8bpp modes on Pandaboard and Beagleboard |
| |
gaula92 (17:45 7/9/2012)
helpful (21:20 7/9/2012)
Phlamethrower (21:34 7/9/2012)
sirbod (00:05 8/9/2012)
Phlamethrower (01:22 8/9/2012)
sirbod (06:26 8/9/2012)
Phlamethrower (00:05 9/9/2012)
sirbod (06:54 9/9/2012)
sirbod (06:54 9/9/2012)
Phlamethrower (09:16 9/9/2012)
sirbod (11:10 9/9/2012)
gaula92 (11:23 9/9/2012)
Phlamethrower (11:50 9/9/2012)
adrianl (15:17 9/9/2012)
sirbod (09:28 10/9/2012)
Phlamethrower (11:18 10/9/2012)
gaula92 (11:53 10/9/2012)
swirlythingy (17:30 10/9/2012)
jeff-doggett (07:04 11/9/2012)
swirlythingy (13:11 11/9/2012)
grannyg (06:47 8/9/2012)
|
| |
|
Señor Nueces |
Message #120993, posted by gaula92 at 17:45, 7/9/2012 |
Member
Posts: 43
|
Hi all,
I'm new to the forum, and Risc OS in general (but I learn a couple of things this last week).
I have a Pandaboard as Risc OS machine, and I'm registered as a Pandaland user in R-Comp service, but what I want to do with this OS seems to be a bit out of their scope.
I have both ArmEm, wich produces outstanding tearing effects that ruin (in my opinion) the experience of old Archimedes games, and Aemulor Pro.
However, even if I CAN set a 320x256@50HZ-8bpp mode for the desktop (I have copied this common mode from the old Acorn monitor profiles), games don't seem to like running in 8bpp modes: all I get in ANY 8bpp mode is a black screen or a very corrupt one.
So I'd need someone who knows more than me about the OS and games on newer hardware, so they can give me any idea of the cause for this. Is the Pandaboard 8bpp incompatible? Only partially compatible?
Even native ArmV7 games like Doom will ONLY display in 16bpp and higher modes.
PS: Of course I have Aemulor Pro module correctly instaled, I have played around with it's CPU and VDP settings, etc. The problem seems to be 8bpp support on the Pandaboard. |
| |
 [ Log in to reply ] |
| |
|
Bryan Hogan |
Message #120996, posted by helpful at 21:20, 7/9/2012, in reply to message #120993 |
Member
Posts: 254
|
Welcome!
For running old games I doubt Aemulor will be much help. It is not a hardware emulator.
The 256 colour modes on the Archimedes were "interesting". There were only 16 palette registers so the 8 bits were divided into 4 that accessed the palette and 4 that passed straight through. So games are only going to expect to program 16 registers and something else will have to simulate the effect of the remaining bits.
And that's before we even get onto games that changed screen sizes, over scan, palette switching on interrupts, etc.
ArcEm is your last, best hope! |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #120997, posted by Phlamethrower at 21:34, 7/9/2012, in reply to message #120993 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
However, even if I CAN set a 320x256@50HZ-8bpp mode for the desktop (I have copied this common mode from the old Acorn monitor profiles), games don't seem to like running in 8bpp modes: all I get in ANY 8bpp mode is a black screen or a very corrupt one. Thinking about it, that might be down to the way the OMAP handles the VSync interrupt and the display controller registers. Basically on OMAP the VSync interrupt occurs after the display controller has already decided what DMA base address to use for the next frame. So compared to VIDC hardware, where all you had to do was set the new addresses before the first display row was reached, on OMAP hardware all buffer flips will occur one frame too late. For a game which just uses double buffering this will lead to you always seeing the buffer the game is drawing to instead of the finished image.
However I'm not sure why the problem would magically fix itself by using a 16bpp mode instead. Perhaps there is a Pandaboard-specific issue at work? |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120998, posted by sirbod at 00:05, 8/9/2012, in reply to message #120997 |
Member
Posts: 563
|
Basically on OMAP the VSync interrupt occurs after the display controller has already decided what DMA base address to use for the next frame. Assuming there's an OMAP driver, shouldn't that account for this hardware difference?
As a workaround, can RISC OS not be fooled into displaying the opposite frame to what's being requested? By inverting the value passed to OS_Byte 112 / 113 for example. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #121002, posted by Phlamethrower at 01:22, 8/9/2012, in reply to message #120998 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Assuming there's an OMAP driver Well if there wasn't a driver, you wouldn't get any video output at all 
shouldn't that account for this hardware difference? Probably! The problem is that it needs to be done before the VFP period, which doesn't leave much time between the last display pixel being output. We could generate a fake VSync earlier than that, but then you run the risk of the bottom few lines being overwritten because the game/program thinks they aren't being displayed anymore.
FWIW, as far as I can tell the Iyonix suffers from the same problem, with games needing to use triple buffering instead of double buffering to avoid issues. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #121005, posted by sirbod at 06:26, 8/9/2012, in reply to message #121002 |
Member
Posts: 563
|
FWIW, as far as I can tell the Iyonix suffers from the same problem, with games needing to use triple buffering instead of double buffering to avoid issues. And inverting the value passed to OS_Byte 112 / 113? Would that work, possibly in conjunction with modifying the address returned via OS_ReadVDUVariables 148 / 149?
Assuming the game is tracking the screen mode and only calling OS_ReadVDUVariables up front, redirecting OS_Byte 112 to 113 should do the job.
I can add that to ADFFS easy enough. |
| |
[ Log in to reply ] |
| |
|
Chris Gransden |
Message #121006, posted by grannyg at 06:47, 8/9/2012, in reply to message #120993 |
Member
Posts: 52
|
A lot of games won't display correctly unless you're in mode '28'. You can type the mode number directly in display manager.
Even doing this there are still problems running the games under Aemulor. The lowest sample rate the Pandaboard supports is 44100Hz. All the games I've tried the sound plays too fast.
The Pandaboard also has problems switching from low resolution 256 colour modes to high resolution. More often than not you will get a freeze or no display at all. Especially with high resolution 256 colour modes.
Other than that the games that do run seem to work ok.
I think you're best bet is waiting for improvements made to !Arcem/!Acornmode as it's a more complete machine emulation. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #121015, posted by Phlamethrower at 00:05, 9/9/2012, in reply to message #121005 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
FWIW, as far as I can tell the Iyonix suffers from the same problem, with games needing to use triple buffering instead of double buffering to avoid issues. And inverting the value passed to OS_Byte 112 / 113?
It'll work, but it'll be a bit fiddly to deal with games which don't run at full framerate. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #121017, posted by sirbod at 06:54, 9/9/2012, in reply to message #121015 |
Member
Posts: 563
|
Oops .. Duplicate post
[Edited by sirbod at 07:55, 9/9/2012] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #121018, posted by sirbod at 06:54, 9/9/2012, in reply to message #121015 |
Member
Posts: 563
|
And inverting the value passed to OS_Byte 112 / 113? It'll work, but it'll be a bit fiddly to deal with games which don't run at full framerate.
Provided the VDU hardware is always displaying the memory not being written too, the only tearing will come from switching it mid-frame. That is only going to happen if the game isn't issuing the request timely, on a VSync, which is unlikely as if a game is flipping frames it's almost certainly going to use VSync.
In the unlikely event that a game is flipping frames without VSync, the fix is to buffer the VDU hardware changes and issue independently on a VSync. Zarch may be an example of this behaviour (speaking of which, I need advice on how to remap the VDU memory to the pre RO3 address to fix some really old games)
I need to add VSync code to ADFFS to allow games to be slowed down, so I can also add VDU change buffering whilst I'm at it.
So, the next question is, under ArcEm/Aemulor is the VSync passed though the abstraction layer immediately? If not, the only way to fix is at the layer up in the emulator. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #121019, posted by Phlamethrower at 09:16, 9/9/2012, in reply to message #121018 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
So, the next question is, under ArcEm/Aemulor is the VSync passed though the abstraction layer immediately? Not sure about Aemulor, but at the moment ArcEm doesn't make use of the host machines VSync at all. If the emulated program waits for VSync it'll wait for the emulated VSync, and that's all. Also ArcEm doesn't make use of multiple screen banks, partly due to this flip timing issue, and partly to keep the code portable. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #121023, posted by sirbod at 11:10, 9/9/2012, in reply to message #121019 |
Member
Posts: 563
|
at the moment ArcEm doesn't make use of the host machines VSync at all. That rules out a fix then. |
| |
[ Log in to reply ] |
| |
|
Señor Nueces |
Message #121024, posted by gaula92 at 11:23, 9/9/2012, in reply to message #121023 |
Member
Posts: 43
|
So, using host's vsync is planned to be implemented? I know it's only a matter of what you're interested in, I'm not asking you to do it... but it would make it enjoyable for me.
I will however understand it if you don't want to add this featute. But it would be so nice to have smooth scroll like in a real Archimedes machine!  |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #121026, posted by Phlamethrower at 11:50, 9/9/2012, in reply to message #121024 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
It's on my todo list. But so are a couple of hundred other things. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #121031, posted by adrianl at 15:17, 9/9/2012, in reply to message #121018 |
Member
Posts: 1637
|
Aemulor does provide enough hardware emulation of IOC and VIDC to allow a lot of pre-RiscPC games to run fine on the IYONIX pc, provided that the graphics card and - as has been pointed out - audio hardware can cope.
The VSync interrupt is passed straight through to the 26-bit code so the behaviour under Aemulor should be exactly the same as on earlier machines.
It is fundamentally a compatibility layer, not a machine emulator, though, and over time it will become more and more impractical for keeping alive older applications as the newer architectures become less compatible with older hardware. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #121036, posted by sirbod at 09:28, 10/9/2012, in reply to message #121031 |
Member
Posts: 563
|
So it sounds like Aemulor may solve the bulk of the OP's tearing issues.
Can anyone confirm if the VDU buffers also need to be inverted, to fix the OMAP VSync issue under Aemulor?
over time it will become more and more impractical for keeping alive older applications as the newer architectures become less compatible with older hardware. It's a sad irony, that as more ARM based machines come out and RISC OS is further modified and extended, more harm is done than good to keep RISC OS and legacy games alive.
There comes a point where its pointless trying to get software running on physical and you have to switch to full machine emulation under a non-ARM, as ARM is not powerful enough yet.
It would be better to cease all development of RISC OS and branch a new OS from it, as it is a good OS from a programmers perspective.
One of the aims of the Archimedes Software Preservation Project is to get games running on modern kit, however, due to the large variety of hardware variations and constant OS modifications this is going to be near impossible as there are hundreds of combinations to check and its a moving target. I'm actually considering designing a machine to solve the problem, so the OS and hardware are in a known state. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #121037, posted by Phlamethrower at 11:18, 10/9/2012, in reply to message #121036 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
There comes a point where its pointless trying to get software running on physical and you have to switch to full machine emulation under a non-ARM, as ARM is not powerful enough yet. I beg to differ about ARM performance; ArcEm may struggle a bit on an Iyonix, but can happily reach ARM3 speeds on a Pandaboard. For RiscPC emulation (where compatability with self-modifying code isn't such a big requirement) a JIT engine can be used instead of an interpreter, so we won't need 5GHz super beasts in order to run RiscPC software (look at what Aemulor Pro could do on an Iyonix, for instance).
It would be better to cease all development of RISC OS and branch a new OS from it Cease development and then continue development in a branch? How's that going to solve anything?
as it is a good OS from a programmers perspective. Now I know you're crazy! |
| |
[ Log in to reply ] |
| |
|
Señor Nueces |
Message #121038, posted by gaula92 at 11:53, 10/9/2012, in reply to message #121036 |
Member
Posts: 43
|
I have moved my Aemulor on Pandaboard tests to the Aemulor thread in the "General" section.
[Edited by gaula92 at 08:52, 12/9/2012] |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #121040, posted by swirlythingy at 17:30, 10/9/2012, in reply to message #121038 |
Posts: 460
|
The patch is here:
http://jeffd.drobe.co.uk/ No, it's NOT. That's a dead site, and the version of the patch on it is an old one with a bug in it! You want this site:
http://sites.google.com/site/jeffreyadoggett/
It must be run inside Aemulor (The patch, NOT the patched game itself: the patched game runs native). I'm pretty sure I successfully ran the patch on a BeagleBoard, but then again it's possible I had alignment exceptions turned off.
-Lemmings...
2)The game will run on windowed mode, but switching to fullscreen hangs the Pandaboard completely.
Note that 8bpp 320x256 mode works perfectly for Twinworld, so it's Aemulor what causes these hangs when switching to low-res 8bpp modes on the Pandaboard. Lemmings also does that on my RiscPC. I'm pretty sure it's not Aemulor that's at fault, but Lemmings. |
| |
[ Log in to reply ] |
| |
|
Jeff Doggett |
Message #121042, posted by jeff-doggett at 07:04, 11/9/2012, in reply to message #121040 |
Member
Posts: 21
|
The patch is here:
http://jeffd.drobe.co.uk/ No, it's NOT. That's a dead site, and the version of the patch on it is an old one with a bug in it! You want this site:
http://sites.google.com/site/jeffreyadoggett/
It looks like the drobe site will stay dead. I've asked Chris to delete it to avoid confusion.
The Riscosopen site currently won't let me edit the wiki (clicking on edit takes me back to the index) to change the links.....
Jeff |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #121049, posted by swirlythingy at 13:11, 11/9/2012, in reply to message #121042 |
Posts: 460
|
The Riscosopen site currently won't let me edit the wiki (clicking on edit takes me back to the index) to change the links..... You're probably attempting to edit it with NetSurf. The wiki needs JavaScript to work.
The irony of this is, apparently, lost on ROOL... |
| |
[ Log in to reply ] |
| |
|
