The Icon Bar: Games: Gaming on the Pi
| |
Gaming on the Pi |
| |
This is a long thread. Click here to view the threaded list. |
| |
|
Señor Nueces |
Message #122313, posted by gaula92 at 16:59, 22/4/2013, in reply to message #121522 |
Member
Posts: 43
|
Now that Aemulor is available for Raspberry Pi, I've been trying some games with it, with discouraging results 
-Nebulus: black screen. Tittle screen music on the backgroud.
-Mad Professor Mariarti: Same black screen + music.
-Speedball 2: Intro is correctly displayed. Black screen when trying to start a game.
-Pacmania: Black screen.
...and so on. I was using a MDF for an old Acorn monitor whose resolutions are displayed in my monitor with no problems at all, and has 320x256 and 640x480 modes.
It seems impossible for the Raspberry Pi to be configured in 8bpp modes, so I guess it's a no-go for Aemulor games.
If someone proves other way, please tell me. |
| |
 [ Log in to reply ] |
| |
|
VinceH |
Message #122314, posted by VincceH at 08:52, 23/4/2013, in reply to message #122313 |
 Lowering the tone since the dawn of time
Posts: 1600
|
Now that Aemulor is available for Raspberry Pi, I've been trying some games with it, with discouraging results I've never used Aemulor, but AIUI, the software is really just designed to make 26-bit software run when the host machine doesn't have 26-bit support. Full screen games are very likely to push the hardware it was written for in ways that Aemulor just doesn't provide for.
It seems impossible for the Raspberry Pi to be configured in 8bpp modes, so I guess it's a no-go for Aemulor games. I don't think that's the issue. I can run full-screen, MODE 15 stuff without a problem, for example. MODE 15 is 640 x 256 pixels in 256 (ie 8-bit) colours. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122857, posted by sirbod at 20:08, 26/11/2013, in reply to message #121522 |
Member
Posts: 563
|
I've made a start on the Pi support and have 4-bit MODE support and the OS redirecting to DA2.
Zarch, Jet Fighter and Terramex are all working, I've posted some photos on the JASPP forum |
| |
[ Log in to reply ] |
| |
|
Señor Nueces |
Message #122871, posted by gaula92 at 20:53, 2/12/2013, in reply to message #122857 |
Member
Posts: 43
|
It's happening AT LONG LAST!! New hardware for Archimedes games!
how comes this thread has no answers to what Jon Abbott is managing to do??? It's AWESOME! |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122876, posted by sirbod at 13:46, 13/12/2013, in reply to message #122871 |
Member
Posts: 563
|
I'm making good progress and have posted some screenshots of games running under the JIT. Phase 1 is now coded and I've done some speed tests with Zarch.
I've yet to test on a StrongARM, however running games under the JIT on a RiscPC with ARM610, they're running at about half speed compared to native on an ARM610.
To put that into perspective, when running on a 200 Mhz StrongARM it should be equivalent to the game running natively on a 100MHz StrongARM. ie way quicker than it needs to run, so games will still need slowing down.
Speed will vary between games as it will depends on how many instructions need re-interpreting into codelets. All BL's and anything that touches or uses PC all need re-interpreting.
[Edited by sirbod at 13:49, 13/12/2013] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122877, posted by sirbod at 23:55, 13/12/2013, in reply to message #122876 |
Member
Posts: 563
|
I should probably add that I've done no optimizations yet. For example, every instruction will generate an Undefined Instruction as it's loaded by the CPU for the first time. The JIT doesn't yet run ahead to cut down the amount of aborts occurring.
There's also a lot of unnecessary code being added on the StrongARM, as I've coded it for the PSR being outside the PC. For example, MOVS PC, R14 is currently re-interpreted into 20 instructions, it need only be 3 on SA when its in 26bit mode! Once I've confirmed all the ARM11 recoding works, I'll go back an SA optimize it. ADFFS has already been split into three versions, IOC, IOMD and 32-bit for this purpose.
Adding support for self-modifying code will slow writes though. Essentially, every write to pages with code in will generate an Abort, the abort handler then looks up the corresponding location(s) in the re-interpreted memory, if it/they contain an instruction, the re-interpreted instruction is changed to regenerate an Undefined Instruction the next time it's seen by the CPU. If there's no instruction(s) the original write allowed.
This will only affect memory pages where code and data are intermixed, it shouldn't affect data such as sprites, music etc - pages are changed to read only when an Undefined Instruction occurs in them.
[Edited by sirbod at 00:01, 14/12/2013] |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #122878, posted by swirlythingy at 14:06, 14/12/2013, in reply to message #122877 |
Posts: 460
|
ADFFS has already been split into three versions, IOC, IOMD and 32-bit for this purpose. If and when you add ARMv7 support, will you need a fourth version to trap unaligned accesses as well? |
| |
[ Log in to reply ] |
| |
|
Michael Drake |
Message #122879, posted by tlsa at 14:08, 14/12/2013, in reply to message #122877 |
Posts: 1097
|
Sounds very impressive Jon. Will it work with desktop software as well as games?
Would it be worth making this software compatibility layer a separate application from ADFFS? Since it should be useful beyond just for software mounted from floppy disc images. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122880, posted by sirbod at 18:07, 14/12/2013, in reply to message #122878 |
Member
Posts: 563
|
ADFFS has already been split into three versions, IOC, IOMD and 32-bit for this purpose. If and when you add ARMv7 support, will you need a fourth version to trap unaligned accesses as well?
Correct, a fourth version would be needed which replaces every LDR instruction with a codelet that loads the address with the bottom two bits cleared and used to ROR the loaded word. It's very trivial to add this to the JIT, as is adding a fourth version.
Once I have some games running on the Pi, I can add this and make public for people to test. I don't have suitable hardware to test unfortunately.
Sounds very impressive Jon. Will it work with desktop software as well as games? I'd advise Aemulor be used for desktop software as it has a suitable front end for managing them, however there's no reason why it wouldn't work with desktop software, I'd just need to seperate the JIT from the Video Memory remapping - they're currently tightly integrated.
It's also memory hungry, requiring 27.5mb for every app. If the apps memory requirements are known up front, this requirement could be reduced. For speed, I've hardcoded it for the time being, 16mb was the limit for original Archimedes, so the JIT uses 16mb-27.5mb for the running code.
Would it be worth making this software compatibility layer a separate application from ADFFS? Since it should be useful beyond just for software mounted from floppy disc images. You don't need to use floppies to use the extra functionality ADFFS adds. Things like 1/2/4-bit mode support, legacy video memory support, frame rate limiting and the JIT can all be used independently - they just happen to be bundled together in ADFFS because they all hook into the same software / hardware vectors to work.
I did consider splitting bits out, but each requires around 8 vector hooks, so it just doesn't make sense to do so. Think of ADFFS as a hypervisor, acting as a middle layer between the running software and the host OS/hardware. Things that work are allowed, things that don't are corrected or handled separately.
The only one I'm seriously considering creating as a separate module is the 1/2/4 bit MODE support. It's so trivial it could easily be included in the OS ROM. With the VIDC1/20 support stripped out, it's probably around 100 instructions. Ideally it needs one bit of functionality adding to RISCOS before this would be possible, namely a means to get the physical address of the GPU framebuffer - that's the only bit that I've had to trick the HAL into providing, everything else uses standard OS/HAL methods.
I'm hoping to get a beta public by Christmas, once I've added SA support its not too much additional work to get things running on the Pi.
I've already coded the VIDC1/20 translation and video blitting, the only thing left to finish off is hardware scrolling (haven't seen a game that actually uses hardware scrolling yet!) and support for the display start being possible unaligned - important for scrolling games, but unused otherwise.
Terramex is fully working, Pacmania is almost there. It just needs the JIT so the sprite collision works, so they'll be the first two to be released for the Pi. |
| |
[ Log in to reply ] |
| |
|
Xavier Louis Tardy |
Message #122881, posted by Zarchos at 19:17, 14/12/2013, in reply to message #122880 |
Member
Posts: 47
|
Jon, you say ' (haven't seen a game that actually uses hardware scrolling yet!) and support for the display start being possible unaligned - important for scrolling games, but unused otherwise'
It's surprising ... I can't think of any other way than usage of hardware scrolling for Scorpius ... or maybe it's your ending ')' which was not at the right place ...
If you want to test a very basic, one part only, demo using hardware scrolling why not trying with mine ?
The code was not crunched or protected so for you it should be even easier to understand.
Click 'show more' in the description of
http://www.youtube.com/watch?v=cA8Xgjlqcdw
as there's the link to download it.
It's a pity I was unable to find the working source code for it, but since then I rewrote the basic tiles display and hardware scrolling routines.
Steve has got it so you can ask him a copy or I can send it to you.
It is the full source with comments and all necessary data.
I also redefine the cusor and use it full heigth and width (but it conflicts with the RISC OS redefinition, and I'd be happy to get rid of that, some day  ).
Hats off to you again for your fantastic job ... I hope you'll further develop it to also run most demos ... as the Archies had pretty impressive demos.
Games ... demos ... it's the same entertainement spirit, isn't it ?
[Edited by Zarchos at 19:41, 14/12/2013] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122882, posted by sirbod at 20:36, 14/12/2013, in reply to message #122881 |
Member
Posts: 563
|
Jon, you say ' (haven't seen a game that actually uses hardware scrolling yet!) and support for the display start being possible unaligned - important for scrolling games, but unused otherwise'
It's surprising ... I can't think of any other way than usage of hardware scrolling for Scorpius ... or maybe it's your ending ')' which was not at the right place ... Probably my wording, I'll explain...
Hardware scrolling first...I'm sure there are games that use hardware scrolling, I've not come across one yet though. All the games I've tested so far shift the screen left / right by up to 16 bytes using an oversized screen, so that 14 bytes worth of pixels are off screen at any one time.
This surprised me, as I was expecting every sidewise scrolling game to use hardware scrolling as intended. All the testing I've been doing with hardware scrolling support is being done with code Steve wrote. It's coded, although crashes Red Squirrel at the minute...oddly physical hardware was working. I believe Red Squirrel has a bug in the VIDC20 code when the Vinit register is changed. I see the same crash randomly when changing MODE, my hardware scrolling triggered it every time though!
Scene demos are a different matter, they use the hardware to its full extend and even push beyond it in some cases...as you well know
Display start being unaligned...to provide horizontal scrolling by less than 16 bytes, HDSR and HDER are shifted left/right by two pixels. This means that the display blitting code has to start part way through a word or byte depending on the bit depth. Ignoring 1/2 bit MODES for the minute, a 4 bit MODE starts on a byte aligned address ... not word aligned. I've yet to code this, the blitter currently only handles word aligned screen starts.
Regards the cursor issue you're having, Caverns had the same problem. It was setting a full width/height cursor and RO was restricting it back, after many hours of debugging I tracked the issue down to an OS_Byte call, follow the link above for details...unless you're referring to the fact the restriction is there in the first place, in which case I don't understand why they restricted it below what the hardware was capable of either. It could be fixed by replacing a few SWI's, but it's easy to get around if you reset the cursor every VSync. |
| |
[ Log in to reply ] |
| |
|
Xavier Louis Tardy |
Message #122883, posted by Zarchos at 21:42, 14/12/2013, in reply to message #122882 |
Member
Posts: 47
|
Thanks for your explanations.
Thanks also for the link provided, I'm sure it'll help me to solve the issue.
[Edited by Zarchos at 22:50, 14/12/2013] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122884, posted by sirbod at 00:31, 16/12/2013, in reply to message #122883 |
Member
Posts: 563
|
I now have the ARM3 JIT running on StrongARM and the Pi and have taken some photo's of Zarch running under it on both, which show the FPS, instructions seen / re-encoded and cache flushes required. |
| |
[ Log in to reply ] |
| |
|
Xavier Louis Tardy |
Message #122885, posted by Zarchos at 16:41, 17/12/2013, in reply to message #122884 |
Member
Posts: 47
|
Awesome job !
Congratulations to the whole team. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #122892, posted by adrianl at 11:51, 21/12/2013, in reply to message #122314 |
Member
Posts: 1637
|
The initial release of Aemulor Pro for Pi is not being recommended for games, only desktop applications. There have also been OS changes which break Aemulor's emulation of low-colour modes (< 8bpp) from working properly, thus breaking a number of older games. Jeffrey Lee has kindly made changes to maintain compatibility with Aemulor Pro, he tells me, although they obviously won't be in current release ROMs.
Aemulor Pro does - or did - run a very large selection of games, including full video and sound support, IOC/IOMD emulation, VIDC/VIDC20 emulation, and emulation of low-colour modes not supported by modern graphics hardware, but still requires that the MDF include suitable mode definitions for the required resolutions.
With the R-Pi, RISC OS's view of the graphics hardware is actually a virtual interface via the VideoCore multimedia subsystem, and thus supports almost any resolution. IIRC it even supports low-colour modes, but I suspect they are not available via the RO HAL and/or the ARM<->VC messaging protocol. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122895, posted by sirbod at 01:07, 22/12/2013, in reply to message #122884 |
Member
Posts: 563
|
Self-modifying code support is now added to the ARM3 JIT, below are speed comparisons of it running on three machines, with your ship left on the launch pad and 1 ship buzzing around:
ARM710 40 MHz
Native: 96 fps
JIT without self-modifying code support: 24 fps
JIT with self-modifying code support: 21 fps
StrongARM 200 MHz
Native: 125 fps
JIT without self-modifying code support: 109 fps
JIT with self-modifying code support: 96 fps
ARM11 800MHz (Pi)
Native: 714 fps
JIT without self-modifying code support: 424 fps
JIT with self-modifying code support: 352 fps
In terms of their ARM3 equivalent speed:
ARM710
Native: 40 MHz
JIT without self-modifying code support: 10 MHz
JIT with self-modifying code support: 8 MHz
StrongARM
Native: 50 MHz
JIT without self-modifying code support: 44 MHz
JIT with self-modifying code support: 38 MHz
ARM11 (Pi)
Native: 285 MHz
JIT without self-modifying code support: 170 MHz
JIT with self-modifying code support: 140 MHz
It's impressive to see how well the StrongARM scales, considering it's seeing 10,000 Data Aborts every second with self-modifying support enabled.
I was hoping to have a beta released before Christmas, but it's looking unlikely as I've hit various bugs in both RO5 and extAsm which need resolving before I can finalise the code. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122902, posted by sirbod at 23:57, 30/12/2013, in reply to message #122895 |
Member
Posts: 563
|
We've released a beta of ADFFS with Pi support and Pac-mania to try out.
It may also work on X-Scale and OMAP4 but is untested on both, feedback would be useful. Note this is a beta and work in progress, so make sure you have a backup of your CMOS (on the Pi its in the ROM image) just in case the CMOS gets corrupt.
You can read how it works in detail on the JASPP development forum, however in summary:
- All instructions are analysed in real-time, harmless instructions are copied and instructions that are not 32bit compatible or use relative addressing are changed to codelets
- After an instruction has been seen once, its not touched again unless it's been self-modified. Very quickly code is running natively on the host system
- RISC OS is made to fall back to DA2 for the screen and frames are blitted to the GPU at the games FPS rate, or monitor refresh rate if the game doesn't frame-swap. 1/2/4bpp MODE's are changed to 8bpp as they're blitted
- Various SWI's are Hypervised, including OS_WriteS and most vector related SWI's
- VIDC1, VIDC20, MEMC and IOC are all emulated
[Edited by sirbod at 02:10, 4/1/2014] |
| |
[ Log in to reply ] |
| |
|
Señor Nueces |
Message #122903, posted by gaula92 at 15:24, 31/12/2013, in reply to message #122902 |
Member
Posts: 43
|
AWESOME WORK, Jon!!!!
I enter the JASPP every day (even several times a day!!) just to read about your progress. I read every detail and try to understand what you do, and drool over any pics your upload with games running, showing FPS and PC 
Trying this today! YOU, Jon, are making Risc OS a much, much more interesting operating system.
What's a good OS without great games and demos to run on it semi-natively? 
A million thanks for what your are doing!! |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122905, posted by sirbod at 10:28, 1/1/2014, in reply to message #122903 |
Member
Posts: 563
|
Glad to see your interest in the project, please provide feedback on the JASPP forum and highlight any issues or improvements. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122914, posted by sirbod at 02:49, 4/1/2014, in reply to message #122902 |
Member
Posts: 563
|
ADFFS 2.29 beta is now available. It now abstracts VSync from the hardware so it's at 50Hz as it would be on an Acorn machine running on a TV. This fixes various speed issues from general game speed to music.
Initially for the Pi, I discovered it sorted out issues on original Arc's as well, so it's implemented on all versions of RO.
The 32-bit version does it by suppressing GraphicsV 1, IOMD and IOC do it by suppressing EventV 4.
[Edited by sirbod at 12:30, 10/1/2014] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122917, posted by sirbod at 10:41, 10/1/2014, in reply to message #121522 |
Member
Posts: 563
|
ADFFS 2.30 beta is now available with lots of bug fixes to the JIT.
This release also contains the an updated IOC version of ADFFS, which is stripped of all IOMD and 32-bit related code.
[Edited by sirbod at 12:30, 10/1/2014] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #122918, posted by sirbod at 00:37, 12/1/2014, in reply to message #121522 |
Member
Posts: 563
|
ADFFS 2.31 beta is now available, Magic Pockets now works.
Thanks go to Martin Bazley for highlighting where the issue was.
[Edited by sirbod at 00:46, 12/1/2014] |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #123079, posted by sirbod at 13:40, 27/2/2014, in reply to message #121522 |
Member
Posts: 563
|
ADFFS 2.38 beta is now available, both Jahangir Khan World Championship Squash and Xenon 2: Megablast now work on the Pi. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #123290, posted by sirbod at 17:58, 13/7/2014, in reply to message #121522 |
Member
Posts: 563
|
ADFFS 2.43 beta is now available
Been a whilst since I last posted an update on here, there's about 20 games now working on the Pi. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #123474, posted by sirbod at 16:15, 13/1/2015, in reply to message #121522 |
Member
Posts: 563
|
ADFFS 2.47 beta is now available
About 35 games now working on the Pi. This version adds Bouncer, Cannon Fodder, Chuck Rock, Gods and Heimdall to the list. |
| |
[ Log in to reply ] |
| |
| Pages (2): |< <
2
|
The Icon Bar: Games: Gaming on the Pi |
|
