Assembly

[lockblade]

I've ordered my Pandora, and though my wallet is crying, my soul is satisfied Anyway, I was thinking about emulation of more powerful consoles (Dreamcast, PSP, DS) and came up with a solution: programming the bare metal to play the game instead of going through the OS. Does anyone have any info on assembly on the OMAP3? Or should I just look for a general ARM assembly guide?

 

[Adventus]

.... What do you mean "going through the OS" ? The OS doesn't really produce much, if any, overhead for standard operations. The exception is RAM usage, which would probably be better managed by a swap file. You would have a hell of a time coding without an OS.

About the assembly, standard ARMv7-A (or lower) will work fine. I suggest these ARM ASM tutorials:

http://www.heyrick.co.uk/assembler/

 

[lockblade]

The OS doesn't really produce much, if any, overhead for standard operations. The exception is RAM usage, which would probably be better managed by a swap file.

But that little bit of performance could push the last bit needed for emulating another console. The point is that while it may not use a lot of resources, it still uses some, and many of the things you don't need. Take the wireless drivers for example. Let's just say that you produce a single player game that doesn't need to connect to the internet at all. When they are loaded by the normal OS, it takes up system resources, though it is a tiny portion of them. But by combining all those little gains, you come up with a measurable increase in performance. You also avoid a (very) small lag between input and the game sensing it.

You would have a hell of a time coding without an OS.

That is the second point. It's more of a "because I can" or "I just need a bit more power" than a cure-all. It wouldn't enable you to play the one game that may or may not be set on an island, but allow for that extra frame that'll just push your emulator over the 60FPS mark.

 

[Exophase]

No emulators need "a bit more power", it's the difference between a small amount of frameskip or no frameskip. Which is not a big difference at all. How likely is it that anyone's going to do an emulator that's reeeeal close to fast enough but not quite, after being optimized in every other conceivable way. Throwing out the OS is insane, you need device drivers on a platform as complex as Pandora. Of course, saying that having unneeded drivers resident is taking up performance is pretty silly.

You should try saving saying "because I can" for when you actually can ;P

 

[Adventus]

QUOTE
It's more of a "because I can" or "I just need a bit more power" than a cure-all.
I would be most impressed if you can.

Its unrealistic to think this will ever happen. We do not (and probably never will) have sufficient hardware documentation.... especially for the SGX.

Consider this, How would you:
1. Write/read from the SD card
2. Instruct the LCD, IVA or DSP
3. Get input
4. Output sound
5. Use the SGX
6. Use any USB device
7. Etc.

You would basically have to write your own drivers for every bit of hardware. This has been discussed a few times before, all with the same basic conclusion.... it's too hard and may give a very slight performance increase.

You would have spent you time much more constructively if you instead optimised your own codebase.

 

[burito]

It's already been said that the nice folks putting together the pandora for us are under NDA's for significant amounts of hardware details. Heck they're not even telling us what wifi chip it is using.

The only way you can write code without using the provided OS is if you forget about things like the 3d chip, the sound, the wifi. Probably a few more crucial bits. The alternative would be to reverse engineer the provided kernel, which would probably make Texas Instruments unhappy, which would make the hardware makers unhappy, which would make the entire community unhappy. At you.

Please don't do it.

 

[sindbad]

RAM is the only resource that you may save a bit of if you remove the OS. However, if you just use a swap file, the OS will figure out what memory is not used at the moment and move it to swap.

Stuff like copy-on-write and shared libraries pretty much negate the RAM usage of the kernel itself, but if you really wanted to get a bit more, you could kill X (which leaves you without 3d acceleration btw) and unload some kernel modules.

 

[Squidge]

We have already developed emulators that "programmed the bare metal" to test hardware before there was a suitable kernel available. It really wasn't noticably faster, and due to the fact that the power management driver was very simple (the driver in the linux kernel is a LOT more complicated), even when the emulator was sitting at a menu, it was eating up 100% CPU and drawing large amounts of power from the battery.

So throwing out Linux just isn't worth it, plus it would create a huge amount of inconsistency. For example, all of a sudden, you would have apps that ignore user settings, refused to sleep when the lid was closed, used up much more power than necessary, perhaps even caused physical damage (eg. If a certain pin on the processor is meant to be an input and is usually given an low signal, and your app drives it high, it would cause a conflict which could in turn cause the OMAP (or another hardware part) to overheat and malfunction).

 

[Klepto]

I actually did a little of something similar on the GP2X, and I plan to on the Pandora as well. For fun (and probably 'cos I'm mental) I wrote a cross-assembler, a simple boot loader, the beginnings of a native Forth and a serial driver so I could talk to it. It was great fun, and I learned a lot about Forth, the GP2X and ARM assembly. I wouldn't recommend it if you want to get anything non-trivial finished. My excuse is that these devices are intended for entertainment, and what I did I found entertaining. None of my stuff was ever published (or publishable IMO), but if you get fed up with gasp macros and would rather code your assembly in an arcane undocumented homegrown Forth assembler that uses RPN syntax then let me know and I'll send you a copy

 

[Svartalf]

None of my stuff was ever published (or publishable IMO), but if you get fed up with gasp macros and would rather code your assembly in an arcane undocumented homegrown Forth assembler that uses RPN syntax then let me know and I'll send you a copy

I wouldn't say that I am tired of gasp macros (I generally don't use 'em...) but the Forth sounds at least remotely interesting. That'd be one of my pet programming languages when I was getting my undergrad. Most of the Forths around now either are waaay spartan or lack the panache FPC brought to the DOS world.

QUOTE

self.foot gun SHOOT!



Ah, shooting oneself in the foot, eh? At least Forth would allow you to do it in almost the most efficient way possible.