Small graphics demo for BeagleBoard/Iyonix available

Hello everyone.

As noted in this thread, I’ve been working on a small graphics demo for the BeagleBoard.

This has mostly been done for fun, and to fulfill an old dream of mine of doing 3D graphics programming on RISC OS.

It may also be a fun thing to try for all you people who are working so hard on the BeagleBoard port, to see some nice 3D graphics on the platform… :)

It’s nothing particularly advanced: It displays 30 3D Gourad-shaded RGB cubes, with random positions, sizes and orientation, all rotating on the screen.

On my system (a 600 MHz BeagleBoard), I get about 30 FPS in 1280×1024 24-bit coulur mode. It could be interesting to know what other people with different systems get, so if any of you test this on another BeagleBoard version, or maybe the Iyonix, then I’d liked to hear what FPS you are getting.

Note that to get maximum performance, you should increase the screen memory in the Task Manager to the maximum (as the demo uses multi-buffering). Presently, this has to be done manually, as noted in the above mentioned thread.

The application will also give a message about this if it doesn’t find enough memory for minimum three screen buffers, but it will still run even with just one buffer, although the display will then flicker.

Furthermore, it currently needs a minimum resolution of 1280×1024 to run. If this is impractical for some, I could easily reduce the minimum resolution and upload an alternative version.

The demo can be found here.

P.S. What may impress you more is that the whole demo is only 4 KB. This includes all code for transformation, projection, rendering and animation.

Doesn’t work on Iyonix. :-(

The first thing which struck me is that it makes no attempt to change into the screen mode it requires – it simply takes the current desktop mode and complains if it’s too small.

The second thing is that, apparently, the screen memory bar in the Task Manager on the Iyonix is apparently always at 0K.

I can only assume that this is because the entire thing is driven by hardware, namely the NVidia graphics card.

Whenever I run your program, no matter what I’ve dragged the screen memory to, it always sets it right back to 0K – and then complains that I should increase it!

Whether this is relevant, I don’t know, but the one thing which is certain is that whenever I (successfully) run it, it produces a static messed-up picture on the screen, makes some noise, and completely refuses to do anything else. Even Alt-Break and Ctrl-Break don’t work. The only answer is the reset button.

So I wouldn’t advise Iyonix owners to try this demo for the time being!

EDIT: And, quite frankly, looking at the code:

ADR R13,&21408
ADD R13,R13,#&32C ; = &21734
STMDB R13!,{R14}
SWI "OS_WriteS" ; write contents of memory
                ; following SWI to screen!
LDMIA R13!,{R2} ; &04 &00 &BD &E8 - so the
                ; above does a VDU 4
LDMIA R13!,{R14} ; ... what?!
BL &81C4
...

...I’m not surprised. It looks like utter garbage to me! (Also, &21734 is well after the end of the executable, and have you ever heard of an AIF header – without which your executable is deprecated?)

Hi Martin.

The first thing which struck me is that it makes no attempt to change into the screen mode it requires – it simply takes the current desktop mode and complains if it’s too small.

Yes, that is by design, as with the different platforms and mode files out there (especially for the BeagleBoard), you can’t assume that a particular mode/resolution is available, and furthermore I didn’t want to tie it to a particular mode.

The second thing is that, apparently, the screen memory bar in the Task Manager on the Iyonix is apparently always at 0K. I can only assume that this is because the entire thing is driven by hardware, namely the NVidia graphics card.

Yes, I figured that might be an issue, here…

Whether this is relevant, I don’t know, but the one thing which is certain is that whenever I (successfully) run it, it produces a static messed-up picture on the screen, makes some noise, and completely refuses to do anything else. Even Alt-Break and Ctrl-Break don’t work. The only answer is the reset button.

It sounds like a resounding success on the Iyonix, then… ;)

The demo uses event-driven screen bank switching, so if something goes wrong there, there’s a good chance of a lock-up, yes.

It’s not supposed to make any sound, though, so that’s probably because the system has gone astray.

EDIT: And, quite frankly, looking at the code:

ADR R13,&21408
ADD R13,R13,#&32C ; = &21734
STMDB R13!,{R14}
SWI "OS_WriteS" ; write contents of memory
                ; following SWI to screen!
LDMIA R13!,{R2} ; &04 &00 &BD &E8 - so the
                ; above does a VDU 4
LDMIA R13!,{R14} ; ... what?!
BL &81C4
...

...I’m not surprised. It looks like utter garbage to me! (Also, &21734 is well after the end of the executable, and have you ever heard of an AIF header – without which your executable is deprecated?)

The demo is meant to only do something relatively simple, and it doesn’t check that much of its environment (apart from the required screen resolution and colours). Thus, it just assumes that the “Next” slot (i.e. the slot it’s running in) has at least a few tens of KB (enough for its run-time data, including tables, as well as its stack).

From this perspective, it should make sense that the stack pointer is set to point outside the executable – there’s no point in storing the area for the stack with the executable, so it simply assumes that memory exists at that point, and below.

The STMDB R13!,{R14}/LDMIA R13!,{R14} are mostly spurious but harmless: These originate from using macros in the assembly, which saves all registers used (such as R14, here), making it possible to use them anywhere (for debugging). The above code is generated by the following assembly code:

Print “<4> ...”; Calls the “Print” macro, which uses OS_WriteS.

I simply used these macros for the few places I needed to print text, mostly as a convenience, rather than using OS_WriteS directly.

Yes, I’ve heard of the AIF header, but, no, I didn’t know it was deprecated to use an executable without it.

So, to summarise your complaints of the code:

1) The strange stack pointer position, which just assumes there’s enough memory.

2) The apparently reduntant saving of R14.

3) Missing AIF header.

As I said in the posting, I did this mostly for fun, so the code does very little checking of its environment (although it shouldn’t crash on a BeagleBoard, unless it has a very small task slot). Furthermore, 2) was done of convenience, and I wasn’t aware of 3), but it doesn’t matter here. The reason for that is that this is only meant as a simple demonstration, not an industrial-strength application.

Apart from that mentioned lack of environment checking, and a few convenience-macros for text printing, the code should be of professional quality.

EDIT: I can also add that the reason for not making this demo more polished was that this is as far as I intend to go with pure assembly programming. From now on, I intend to continue the computer graphics development using C++, probably using GCC rather than the Norcroft compiler.

I’ve been working on a small graphics demo for the BeagleBoard.

Shame my Beagle’s down at the moment :-( but I can’t wait to try it sometime soon! Could this be the starting point for a 4KB Beagle demo challenge?

Doesn’t work on Iyonix. :-(

Well, someone had to be the first to try it on an Iyonix – I can understand your disappointment in the above results. But perhaps it can be coaxed into working. Going by the thread title, the demo doesn’t seem intended to be Beagle exclusive. And the screen memory issue has been reported to be a tricky OS bug . I’m sure that the brains contributing to this forum will get to the bottom of this – so if you’re unable to help then maybe just wait patiently.

Shame my Beagle’s down at the moment :-( but I can’t wait to try it sometime soon! Could this be the starting point for a 4KB Beagle demo challenge?

Yes, I found it quite amusing that it happened to end up as 4 KB in size, and was reminded of those 4 KB demo competitions… :)

I guess this is one of the first demos to be made for the BeagleBoard, as well. It’s my little gift to the community – especially those of you with Iyonixes… :) (if you want a locked-up computer, that is…)

Well, someone had to be the first to try it on an Iyonix – I can understand your disappointment in the above results. But perhaps it can be coaxed into working. Going by the thread title, the demo doesn’t seem intended to be Beagle exclusive.

True, it was intended to work on the Iyonix, as well, so it doesn’t use any features beyond those available in ARMv5.

However, I haven’t got an Iyonix myself, anymore, so I’m reliant on others to test it. I do have a friend in Norway with an Iyonix, though, and together with him, I might be able to get it to work also there.

I’ll also test it on the VirtualAcorn, when I get home today.

P.S. I’ll also post a screenshot from the demo.

P.S. What may impress you more is that the whole demo is only 4 KB. This includes all code for transformation, projection, rendering and animation.

If you want to impress me you’ll have to cut it down to 2KB (or maybe even 1KB) and make the code behave itself :)

Could this be the starting point for a 4KB Beagle demo challenge?

Yes please! Although I don’t have enough spare time to take part :(

From now on, I intend to continue the computer graphics development using C++, probably using GCC rather than the Norcroft compiler.

I can’t blame you, really – modern computers are so fast and complex that if you want to do anything more than a small demo it would take a massive amount of time and effort to write it all in assembler and get the best performance out of the machine.

If you want to impress me you’ll have to cut it down to 2KB (or maybe even 1KB)

I doubt that can be done, by feel free to impress me by doing that… :)

Anyway, I see you’re not easily impressed… Maybe you could send me one of your own 4 KB (or less) RISC OS demos…? :)

and make the code behave itself :)

Now that should be doable… :)

Could this be the starting point for a 4KB Beagle demo challenge?

Yes please! Although I don’t have enough spare time to take part :(

Quite frankly, I’d be happy with any demo, as the RISC OS demo scene is completely gone…

Along with most of the developers/users…

Fortunately, there are a few left… :)

From now on, I intend to continue the computer graphics development using C++, probably using GCC rather than the Norcroft compiler.

I can’t blame you, really – modern computers are so fast and complex that if you want to do anything more than a small demo it would take a massive amount of time and effort to write it all in assembler and get the best performance out of the machine.

Indeed. When the extASM assembler was made, we were using 8 MHz ARM2 processors (the Archimedes computer), and assembling a 350 KB source code using several passes in a reasonable amount of time (15 seconds) was really only doable by writing the assembler itself in assembly.

However, things have changed in several important ways (as you note, yourself):

1) Computers have become way more powerful: Now we have microprocessors that are hundreds of times faster than those days.

2) Today’s compilers are much more optimising than they used to. When I tested the Norcroft compiler last (about 10 years ago) I was disappointed by the quality of the resulting code. For example, access to struct/class members always went through a pointer, instead of the members being held in registers. Modern compilers does a much better job, rivaling or exceeding hand-coded assembly in terms of efficiency.

3) Today’s processors can be hard to write hand-optimised assembly code for, because of the complexity involved when it comes to things like superscalar out-of-order execution, speculative execution, branch prediction, etc.

So why did I write this small demo in assembly? Well, like I said, it’s been a dream of mine to program 3D graphics on RISC OS, so I wanted to make a few routines for that, and I wanted to be confident in that I could actually write this in pure assembly code, mostly for the thrill of it… :)

Now that this dream has been fulfilled (making a small graphics demo in assembly), I want to pursue the larger dream: Computer graphics programming in general, and as you note yourself, while it can be fun to program in assembly code, and it’s cool to have complete control, and complete transparency, it’s very time-consuming to write anything larger than small routines using assembly code.

High-level languages attract me in a different way: The ability to write elegant code with high-level abstractions, so that’s another reason I intend to leave assembly code largely behind (except perhaps a few hand-coded routines the compiler doesn’t handle well enough, and for things like vector and matrix libraries, which may be implemented efficiently using VFP/NEON).

(By the way, how do you do nested quoting here?)

and make the code behave itself :)

Now that should be doable... :)

Yes please! Although I don’t have enough spare time to take part :(

Quite frankly, I’d be happy with any demo, as the RISC OS demo scene is completely gone...

Along with most of the developers/users...

Fortunately, there are a few left... :)

When you’re happy with it, do you intend uploading to pouet.net or similar?

(By the way, how do you do nested quoting here?)

Cheat .

29 FPS on my Devkit board with 1280×1024 @ C16m (57Hz).

If you want to impress me you’ll have to cut it down to 2KB (or maybe even 1KB)

I doubt that can be done, by feel free to impress me by doing that… :)

Yes, perhaps 2KB was a bit harsh. But since your demo is actually 7KB, maybe you can just make a 4KB version instead? :) (Remember that it’s the size of the executable that counts, not the size of the compressed archive!)

Anyway, I see you’re not easily impressed… Maybe you could send me one of your own 4 KB (or less) RISC OS demos…? :)

You mean like these? Although only a few are graphical demos, and the ones that are aren’t particularly impressive!

I’ve also got a 1K web browser to go with the 1K HTTP server, but I want to try and expand it to a more useful 2K or 4K version before releasing it.

(Remember that it’s the size of the executable that counts, not the size of the compressed archive!)

How much space does a suitable decompression routine occupy? (E.g. I thought that most floppy-based demos used to decompress their own code upon execution.)

Though the Demo does not run on the Iyonix it did run on VRPC on a Mac returning FPS=62

Though the Demo does not run on the Iyonix it did run on VRPC on a Mac returning FPS=62

Quite interesting, that’s twice the FPS I get on the BeagleBoard… But then again, the VRPC uses a just-in-time compiler for higher performance (than corresponding interpreters).

This might be a useful benchmarking application for other platforms, like the BeagleBoard Xm, or the PandaBoard…

If we do get support for multiple cores, it should be possible to use that quite simply, here, by splitting the amount of objects to draw over the cores.

Naturally, if we could use the PowerVR graphics accelerator, that would have been great, but as long as we don’t have any drivers, software rendering is the only option…

This is also a reason for going to higher level languages: If we do get PowerVR drivers, sometime, then only the low-level routines in a graphics system would need to be swapped with calls to the PowerVR.

Anyway, I see you’re not easily impressed… Maybe you could send me one of your own 4 KB (or less) RISC OS demos…? :)

You mean like these? Although only a few are graphical demos, and the ones that are aren’t particularly impressive!

Yes, perhaps 2KB was a bit harsh. But since your demo is actually 7KB, maybe you can just make a 4KB version instead? :) (Remember that it’s the size of the executable that counts, not the size of the compressed archive!)

Ah, yes, I hadn’t actually noticed that difference… I’ll look into that… :)

In any case, I’ve never had a fetish for making demos as small as possible… For me, what matters most is how good a demo is, not what size it is… Also, I suspect that compression can easily lead to unreadable garbage code, and that would certainly not impress me… :)

However, for fun, I’ll try to shrink this one even further, without compromising readability or efficiency.

When you’re happy with it, do you intend uploading to pouet.net or similar?

Currently, it’s a rather simple demo, and as mentioned in another posting, I don’t really intend to do much more with it (apart from possibly making it work on the Iyonix), and I don’t really consider it in the same league as other demos.

However, for its size, maybe it’s not that bad. I’ll look into what other comparable demos are there.

One thing I possibly could do to make it a little more interesting is to have the spinning cubes move around, bump against the sides of the screen, and so on. That would be very little extra development.

Also, thanks for the block quote tips.

Yes, perhaps 2KB was a bit harsh. But since your demo is actually 7KB, maybe you can just make a 4KB version instead? :) (Remember that it’s the size of the executable that counts, not the size of the compressed archive!)

Ah, yes, I hadn’t actually noticed that difference… I’ll look into that… :)

So, for reducing the executable to 4 KB: Consider it done. ;)

Interestingly, this one compresses 0%... I only put it in a zip file to preserve the filetype of the executable.

I’ve now uploaded a new version which includes the source code and a screenshot, for anybody interested.

I’ve also increased the robustness of the demo, by installing an error handler, so that it cleans up after itself if something goes wrong.

(Sorry for the multiple posts)

When you’re happy with it, do you intend uploading to pouet.net or similar?

Unfortunately, pouet.net doesn’t have a category for RISC OS or any RISC OS-based system, and it appears that Icebird’s excellent Acorn demo archive is no longer online…

Does anyone know about a working RISC OS application archive, that is, where the system for uploading software actually works? Or alternatively, an archive where you may submit a link to an application?

I take it that you missed this list of Acorn demos, then :)

http://www.pouet.net/prodlist.php?platform%5B%5D=Acorn

Terje – that new version of the demo almost runs on an Iyonix. The only problem is that you’ve used MLS in Check_Draw, which was only added in ARMv6T2. After swapping it for MLA (and changing SUB R3,R3,R0 to SUB R3,R0,R3) everything is fine. Shame that it only manages 7fps due to the slow access to PCI RAM!

I take it that you missed this list of Acorn demos, then :)

http://www.pouet.net/prodlist.php?platform%5B%5D=Acorn

Doh! Yep, I did. :) I looked for “Archimedes” and “RISC OS”, and missed that one… It never occurred to me that “Acorn” would be listed as a platform…

Terje – that new version of the demo almost runs on an Iyonix. The only problem is that you’ve used MLS in Check_Draw, which was only added in ARMv6T2.

Ah, yes. I also got a report from Jan-Jaap van der Geer about an undefined instruction exception on the Iyonix, and found it to be the MLS… I thought I had only used instructions available in ARMv5, but I didn’t think of that one…

After swapping it for MLA (and changing SUB R3,R3,R0 to SUB R3,R0,R3) everything is fine.

Great! :)

The application uses the amount of screen memory to configure the number of buffers used for rendering, and since the Iyonix screen memory setting is permanently at 0 KB, it won’t use any screen buffers at present.

Because of this, I guess the display flickers on the Iyonix?

If it does, then I could modify the application to use double-buffering, even when it reports no screen memory, which might still work.

Shame that it only manages 7fps due to the slow access to PCI RAM!

No surprises there...

I figured the FPS would take a dive on the Iyonix because of the PCI RAM access bottleneck; I just didn’t know how much… Well, now we know!

If designed specifically for the Iyonix, it would probably have been better to render to RAM, and then copy each frame (possibly using DMA) to the screen buffer.

Thanks for the testing!

EDIT: In the version up to now, the cubes have rotated in a somewhat “jerky” motion, due to too low numerical precision in the calculations. That has now been corrected, and the jerkiness is gone.

Just another update to say that I’ve now updated the demo to use double-buffering also on the Iyonix, and I’ve got confirmation from a tester that it now works there.

...(a 600 MHz BeagleBoard), I get about 30 FPS in 1280×1024 24-bit coulur mode… hear what FPS you are getting.

33FPS on BB-xM (clock speed not altered ATM). Nice demo :-)

5fps on an Iyonix!

...almost runs on an Iyonix… manages 7fps…

5fps on an Iyonix!

Jeffrey, does this mean that you’re running your Iyonix overclocked?