Let's get started with a Pandora port

This is excellent news. :) Star Fighter 3000 was my favourite Archimedes game (like Elite was on the BBC Micro).

Just think what we could do using OMAP’s PowerVR SGX graphics accelerator… :)

An example from YouTube: http://www.youtube.com/watch?v=aeT3Fqrgmws

It doesn’t say which platform the demo runs on, though, but there are also demos from Pandora, etc.

It’s unlikely that the DMA will be of much help in computer graphics, except for simple things like rectangles.

It’s unlikely that the DMA will be of much help in computer graphics, except for simple things like rectangles.

I’m not sure where you get this idea. In theory (and certainly on the Iyonix) primitives such as lines, rectangles, etc should be accelerated by video card instructions. DMA typically doesn’t help much here, since the instructions are so small.

DMA can be a huge deal for games when plotting sprites, etc, as many do. This is certainly the biggest bottle neck in many newer games on RiscPCs.

Anyway, riscos.info games should work on BB:

http://www.riscos.info/downloads/packages/SectionIndex.html#Games

With regards to Star Fighter, the only thing which DMA is likely to be useful for is copying the rendered scene to the screen. But I’ve got no idea whether it would give a performance boost – some not entirely scientific tests I did a few days ago suggested that the CPU can write to screen memory at 400MB/s, which means redrawing the window Star Fighter is running in probably takes less than one millisecond (assuming an 8bpp desktop and no scaling).

The DMA controller in the OMAP does support rectangle copies, fills, and colour-key based transparency (for transparent sprites), so could be useful in speeding up the rendering of the desktop and 2D games, but it’s almost entirely useless for 3D games.

When I finally get round to downloading GCC 4 I’ll try compiling Quake 2 and see how it runs. I think there were reports from the Pandora community that it ran quite well, even with software rendering and using GCC’s software floating point. It would be a much better benchmark to find out what performance we can reasonably achieve from the system.

Hi Peter.

It’s unlikely that the DMA will be of much help in computer graphics, except for simple things like rectangles.

I’m not sure where you get this idea. In theory (and certainly on the Iyonix) primitives such as lines, rectangles, etc should be accelerated by video card instructions. DMA typically doesn’t help much here, since the instructions are so small.

DMA can be a huge deal for games when plotting sprites, etc, as many do. This is certainly the biggest bottle neck in many newer games on RiscPCs.

It seems to me that you’re saying the same I did (and which Jeffrey said in the following posting), so I don’t understand what you disagree with.

Yes, it may also be used for plotting sprites, but that is also a case of drawing rectangles (possibly with a mask).

Regards,

Terje

Hi, I just received my BeagleBoard order last night, and have RO running as per your instructions – thanks! – but can’t persuade it out of 640×480 256-colour mode at the moment, beyond dropping back to the old numbered modes. LoadModeFile seems to work fine, but attempting to enter any of the new modes just leaves me in the current mode. Have I missed something?

Obviously my first priorities are to get Geminus and Cino updated, then possibly Aemulor and/or the abort handler we discussed a long time ago.

Cheers for the great work.

Hi, I just received my BeagleBoard order last night, and have RO running as per your instructions

Excellent! It’s good to have you aboard :)

but can’t persuade it out of 640×480 256-colour mode at the moment, beyond dropping back to the old numbered modes.

This is because RISC OS still relies on *vidcbandwidthlimit, even though it’s mostly useless in the HAL world. If you use the “HardDisk4” boot sequence/disc image from here then it should set a new value for you (same as the official Iyonix boot sequence does). We should probably fix it so the HAL handles that setting at some point.

(Note to self – update setup guide to mention the disc image!)

Obviously my first priorities are to get Geminus and Cino updated, then possibly Aemulor and/or the abort handler we discussed a long time ago.

Regarding Geminus and Cino – the current video driver for the OMAP3 port is very basic and doesn’t let you use any of the advanced features which would be required for Geminus/Cino. The plan was that Simon Wilson was going to write a new video driver in C as a module, and to disable the code that’s currently in the HAL (but retain it in the source for debugging). I tried mailing Simon a week or two ago to see if he’d made any progress but haven’t had a reply yet (He’s had the task for a few months, but AFAIK hasn’t had the time to actually get started on it yet). If you aren’t able to raise him yourself then I’d be more than happy for you to take over the task, since it’s a critical task if we want to get the port running on devices with integrated screens (Touch Book, Pandora, etc.)

Aemulor and the abort handler would be good as well, of course, so feel free to take your pick from the available tasks.

Actually there’s one other thing that might be limiting your choice of video modes – the video controller is rather restrictive about the signal timings it supports. At the moment the driver is running in “strict” mode, so it will refuse to change to a mode that doesn’t have suitable timing values. So it may be that whatever MDF you’ve loaded doesn’t contain any usable modes. There’s a set of modes at the bottom of the video driver page that should work OK (assuming your monitor supports them!)

I did a new set of autobuilds last night. The most notable change will probably be that unaligned loads now cause an exception in the OMAP ROM build.

Adrian: is there any chance that something could be done with Geminus so I can run my dual displays at their native resolution? ISTR there was some feature of the nVidia driver that needed tweaking – the source code has been available for a while so maybe this could go on the ToDo list? :)

https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/Video/HWSupport/NVidia/

Did you know that there is a BeagleBoard clone with 720MHz, 512 MB RAM and Ethernet on Board (plus wifi and bluetoth)? Do you think the current port would just work on this board, too?

http://igep-platform.com/shop/index.php?main_page=product_info&cPath=1&products_id=23&zenid=adb00b5dcc2a70e96d0d288315a93872

Of course I understand that the original BeagleBoard port should be completed first, I just found this on the web and wanted to share the info in case you have not seen this before.

Did you know that there is a BeagleBoard clone with 720MHz

Yes, there are a few clones:

http://www.riscos.info/index.php/BeagleBoard#Derivatives

Do you think the current port would just work on this board, too?

I think it is very likely with no, or very small changes.

Hi, just a quick announcement: I have DMA rectangular copies and fills working in prototype code, so it shouldn’t be too much longer before I can roll it into either a module hanging off GraphicsV, or directly into Geminus which can accelerate sprite plotting, including masks etc too.

Re the mode changing, the 1280×1024x57Hz mode doesn’t work at all on my C3 board – which was part of the confusion. I also think VIDCBandwidthLimit may need to be issued before entering the desktop which I do now (haven’t proven that, though). The picture glitches every now and then about 3/4 the way down the 1280×1024x50Hz,16m mode too, though. Thanks for the MDF.

I have DMA rectangular copies and fills working in prototype code, so it shouldn’t be too much longer before I can roll it into either a module hanging off GraphicsV, or directly into Geminus

Sounds good!

My current plan is for DMAManager to be in control of most of the DMA channels (and have them all mapped to one IRQ), leaving the remaining channel(s) and IRQ lines free for graphics acceleration. The details of these channels (address of DMA controller, IRQ number, etc.), and the details of the video controller, will then be exposed to RISC OS via a HAL device, so the video driver/Geminus/etc. can get the details in a safe manner. Sometime within the next week I’ll try and write some code to deal with this, and get it all checked in along with my current HAL/DMAManager changes.

I also think VIDCBandwidthLimit may need to be issued before entering the desktop which I do now (haven’t proven that, though).

Yeah, I’m fairly certain it gets issued before entering the desktop in the standard RISC OS 5 boot sequence. You should really grab a copy of the HardDisk4 disc image and use that.

The picture glitches every now and then about 3/4 the way down the 1280×1024×50Hz,16m mode too, though.

I’m hoping this is just a problem with our graphics FIFO/DMA settings, and that it will go away if someone tweaks the values a bit (The glitching seems to be caused by the CPU or other devices putting a heavy strain on the memory bus). It’s probably something that’s easiest to fix once the new video driver has been written (using a * command to tweak settings is a lot quicker than recompiling a ROM image!)

Okay, working (for me at least!) prototype code at: http://adrianl.drobe.co.uk/alpha/omapgraphics.zip

This DMA accelerates the OS’s rectangle fills and copies, and lends further support to your theory that the pixel FIFO is underrunning under heavy bus/memory traffic, since dragging large windows around the screen causes the picture to break up badly in hi-bw modes.

I’ve not attempted to measure the performance yet, but it feels more like the A9home than IYONIX pc to me, to be honest. I suppose that’s to be expected from an unified memory architecture, though there may be some small improvements to be had from further tweaking the DMA setup too.

I’ve now got smooth scrolling in Netsurf. :)

Reducing the frame rate helps. I’ve got mine set to 45Hz. With this I only get the occasional picture break up.

Adrian: I’ve finally checked in my changes, so there’s now an “OMAP3 video controller” HAL device, containing the logical address & IRQ number of the video controller, along with the logical address of the DMA controller, mask of available channels, and the IRQ they are assigned to. Really crap documentation here, with the main HAL device documentation here (which you’ll have to read at least some of to work out how to find the device!) Feel free to suggest/make any changes you need to the source/documentation as you develop your code (in particular fleshing out what the HAL should do for the Activate/Deactivate/etc. entry points – e.g. I’d expect the HAL to be in charge of board-specific stuff like enabling the DVI framer on the beagleboard/DevKit8000)

As an unrelated change, DMA is now used to clear RAM on boot, which shaves several seconds off the boot time.

As an unrelated change, DMA is now used to clear RAM on boot, which shaves several seconds off the boot time.

Is it necessary to clear the RAM on boot? Also, I’d have thought that it was pretty cleared on startup, anyway.

Is it necessary to clear the RAM on boot?

RISC OS programs don’t make any assumption as to the content of their newly-allocated RAM, but it looks like RISC OS does. As an experiment to check that the RAM clear was working I changed the code to fill memory with a nonzero value. The machine hung right after RISC OS enabled interrupts – so there’s at least once piece of code in the OS which expects RAM to be clear on boot.

Also, I’d have thought that it was pretty cleared on startup, anyway.

I’d expect most of it to be clear, but certainly not all of it. At the least there’ll be a copy of u-boot, and there’ll probably also be a second copy o the ROM image (since the ROM relocates itself to the top end of RAM in order to avoid fragmenting the physical memory map). I’m also not sure what happens to the board when it goes through a reset – it might be that the RAM remains powered and so retains its previous content.

A general update for everyone:

• As discussed in this thread the HAL now supports different board configs, via use of multiple entry points. This means that if you’re not using a beagleboard, the next time you get/build a ROM image you’ll want to grab this zipfile of boot scripts from my website and start using the appropriate script for your machine type, otherwise you’ll be stuck using the beagleboard config.
• As usual I seem to have missed out on the autobuild by just a matter of hours, so the current ROM image available to download (2010-01-24 02:19:34) won’t contain the above changes, and if memory serves will actually enter an infinite loop if you try using anything other than the beagle boot script. So if you can’t build a ROM image yourself then you’ll have to wait a few days until ROOL do it for you. I don’t think there are any significant functional differences (apart from for the DevKit8000, which will now be able to read EDID data via GraphicsV), so it’s not a big deal if you don’t immediately switch to a ROM using the new board config system.
• So far there are boot scripts for the BeagleBoard, DevKit8000, IGEPv2, Pandora and Touch Book – so if you’ve got a device that isn’t listed then let me know and I’ll try and track down the relevant docs to let me write a board config for it. Also the non-BeagleBoard configs aren’t guaranteed to be 100% working, since I’ve got no way of verifying them ;)
• The 2012 date fix has been merged into the Cortex branch of the kernel. Although the beagleboard didn’t exhibit the bug, the bad code was still there, and would infact have triggered if we had CMOS/NVRAM support by now. I’ve updated the RTC HAL device docs with the relevant details for how HALs should indicate their RTC limitations.
• The video driver can now be built in ‘passive’ mode, in order to produce a driver that doesn’t alter the video output settings. Sometime later on today I’ll upload a build with it enabled so our Touch Book owners can try it out and see if RISC OS shows any signs of life.

I’ve updated the OMAP ROM build on our downloads page and included a copy of your scripts in the archive (adding a link to your originals so people can find them). Would you like to add these scripts to cvs?

I’ve updated the OMAP ROM build on our downloads page

The new ROM doesn’t boot, before anyone else tries it. I managed to miss a file out of my checkin. I’ll report back once I’ve made sure that the code in CVS does work this time.

...and included a copy of your scripts in the archive (adding a link to your originals so people can find them). Would you like to add these scripts to cvs?

Yes, that would make sense. I’ll see if I can get the mkimage tool to compile on RISC OS (or via the cross-compiler), so that the binary versions of the scripts can be built as part of the build process. Having a copy of mkimage that runs on RISC OS would also allow us to easily package the ROMs as uImages, if we desired.

The code that’s in CVS works now. I’ve uploaded a working ROM image here if people want to try it out.

Also, as promised, here is a ROM image using the hacky “pasive” video driver, for people with Touch Books to try out. Since this is just a quick hack, the screen will be cropped at the right/bottom if you use a screen mode larger than the display size (i.e. 1024×600). I’ve also included a copy of the ARMv7-safe command line unzip tool, as I remember Bryan Hogan didn’t have any way of extracting zip files for his TB. Hopefully sometime today I’ll get the source patches sent back to infozip.

Also for both of those ROM images I’ve got a special hack enabled – to save on desk space I’ve been using my beagleboard with a mini keyboard + trackball. The trackball only has two buttons, so in my copy of the USB drivers I’ve remapped the Windows key to act as the Menu button (I was actually aiming to remap the Menu key, but I found the Windows one first!) This should hopefully mean that, assuming the ROM boots, the “AI” keys on the Touch Book should operate as the Menu mouse button. Hopefully the trackpad works as well.

I think – judging by the timestamps – ROOL re-ran the autobuilder last night, so the autobuilt ROM should work again.

Also I’ve uploaded a standalone copy of unzip here (set type to absolute), to save people downloading the big archive I posted above.

I’ve just tried the passive ROM with the Touchbook script using AI’s MLO and u-boot. The Touchbook gives a blank/pulsating screen but ironically the same SD card appears to boot on the Beagle (I got as far as the Supervisor being displayed on the monitor). I downloaded MLO and u-boot from AI’s update site a few minutes ago. Also, I’ve tried a USB keyboard but with no response.

Hmm, it looks like this is going to require some hands-on debugging to get it working. Which means we have three choices:

1. Someone brave wires up a serial cable so we can get some proper debug output
2. Someone with half-decent knowledge of assembler pokes around in the source code until they find where it’s getting stuck, allowing someone more experienced to propose a fix (As a very primitive form of debug output we should be able to change the screen colour – so it’s basically just a case of moving the colour change code around until the exact location of the problem is discovered)
3. Or we wait until my Touch Book (or perhaps ROOL’s) arrives so someone more experienced with the code can take a look (And hopefully not have to resort to the time-consuming trial-and-error approach of #2!)

For the time being I’m planning on focusing on the video driver – it could easily take several months to write, and the Touch Book port won’t be properly usable without it. If my Touch Book arrives before anyone works out why RISC OS doesn’t boot then I suspect I’ll shift my focus and work out what’s wrong, but until then you’ll have to mostly rely on yourselves if you want to see that familiar grey desktop appear ;)

Hi.

I just want to express once again, on behalf of all BeagleBoard/Touch Book, etc. owners who hope to be able to run RISC OS on them (which you already can, on the BeagleBoard) my gratitude for all the hard work especially you, Jeffrey, but also ROOL, are putting into this port…

I recently got a confirmation mail saying that my Touch Book was about to be shipped, so hopefully soon, there will be yet another “guinea pig” for testing out RISC OS on the Touch Book… :)

When I get it, I’ll try it out, and contribute what I can, to the port efforts…