microcat - The ultimative ARM based handheld game console

[CKH4]

Wow that sounds great. That is a massive specs boost.

[novenary]

Yes indeed, although the ram is pretty small and is likely to be a limiting factor. We'll see what it can do.

[DarkestEx]

Yes indeed, although the ram is pretty small and is likely to be a limiting factor. We'll see what it can do.

Well for the small size and display, the RAM should be okay I think.

Games should be linked to the builtin API in flash - I have sadly no clue how so any help is greatly apprechiated (see below).
The person who helps me getting an executable that I copy from the SD to RAM to execute while using the shared API in flash gets a console for free (only when we get the thing kickstarted though).

[novenary]

Gotta look at the datasheet, but it should be feasible. Which compiler are you using ? I assume GCC ?

[DarkestEx]

Gotta look at the datasheet, but it should be feasible. Which compiler are you using ? I assume GCC ?

Well we will be using gcc for ARMv7.

Basically we want one application at once (so no multitasking and multithreading).
OS sometimes gets called by ARM events or interrupts or though the OS API.
It normally does nothing though.
C should probably be enough though C++ would be really awesome.
Also the API (graphics, OS, file system, network, etc.) will be in the flash.
We will make a .h API. The games need to be shared linked to this. The positions in flash do only change on firmware updates - there is no filesystem in flash, just bound into address space. We have a FAT32 filesystem on the SD card (interfaced though the HSMCI interface).
When the console boots, it should run the OS from flash (like normally) and allows the user to select an executable from the SD card (I am doing that part).
Then the executable needs to be copied into RAM and jumped to it. Because of the small amount of RAM we have, we don't want a static API in that executable, but the API should be entirely in flash and shared linked to that.
It should also be (relatively) easy for a user to make games. So any makefile or so would be good then (remember some of the targeted people don't know too much about linking and such things).

I hope that is feasable. Thanks to everybody who can help.
The first solution that I like will be the winner and he or she gets a free console when the kickstarter is over and the project funded. (One of the first consoles)

[novenary]

How about having a jump table in flash to keep api functions at the same location ? that would vastly simplify things. You can then use the syscall interrupt to call the api from flash, just have a tiny handler statically linked into the executables and it should be fine. That should remove the linking problem entirely.
Have a look at this : http://wiki.osdev.org/ARM_System_Calls

[DarkestEx]

How about having a jump table in flash to keep api functions at the same location ? that would vastly simplify things. You can then use the syscall interrupt to call the api from flash, just have a tiny handler statically linked into the executables and it should be fine. That should remove the linking problem entirely.
Have a look at this : http://wiki.osdev.org/ARM_System_Calls

How do you mean that?
Also how do i then use e.g. int32_t do_something(uint_8t x, uint32_t) from a .h file?
How do I link that with gcc?
Jumptable makes sense, but how do I link that to the .h files?
And how do I place that inside of the flash api always at the same position in flash?

[novenary]

You need to write custom linking scripts (they should ship as part of your toolchain).
For every api call you need to write an assembly stub that will pass control to the api code in flash. Shouldn't take more than a couple instructions per function.

[DarkestEx]

You need to write custom linking scripts (they should ship as part of your toolchain).
For every api call you need to write an assembly stub that will pass control to the api code in flash. Shouldn't take more than a couple instructions per function.

I will do that. Thanks for helping. But you might understand that I can only choose you as the winner when it works. And it might be more fair to just give you 50% discount for there suggestions. But we will see

[novenary]

Glad I could help, I've done a lot of low level stuff on arm, including bare metal on the raspberry pi and all my experimentations with ndless. Knowledge is meant to be shared, not kept secret.

[DarkestEx]

So I decided to start with the OS.
After some thinking I decided to not make it closed source. It will be licenced under the New BSD 3 clause licence.
You can track progress here: https://github.com/ninjabyte/ClawOS

[Dream of Omnimaga]

I unfortunately cannot help nor provide much feedback on the hardware side of this project, simply because I am completely illiterate about that stuff, so all I can do is suggest technical specs, which looks like I won't need to do, from the first post. 

However, I support this project and while I was skeptical at first, it seems you have gotten your stuff together quite well despite the fact that most of those projects end up being vaporware. This is why at first I suggested to not launch a Kickstarter campaing or something too early, if you ever need one.

Glad that you are making the OS open-source. It's your decision in the end, but TI community members tend to prefer open-source platforms and ones that aren't overly locked-down like the TI-82A or TI-Nspire CX. Also make sure that if you don't support ASM nor C that you include support for languages that are fast enough  for  this platform (eg not Visual Basic )

Anyway good luck and make sure to continue planning stuff ahead.

Knowledge is meant to be shared

Don't you also mean "Sharing is meant to be known"?

[DarkestEx]

Glad that you are making the OS open-source. It's your decision in the end, but TI community members tend to prefer open-source platforms and ones that aren't overly locked-down like the TI-82A or TI-Nspire CX. Also make sure that if you don't support ASM nor C that you include support for languages that are fast enough  for  this platform (eg not Visual Basic )

Anyway good luck and make sure to continue planning stuff ahead.

Thanks!
Well we are not doing the VM anymore as I said a few posts above. The hardware is finally good enough for having games in C or Assembly

[Dream of Omnimaga]

Cool to hear. I thought it still didn't support ASM/C.

[DarkestEx]

Huge feature upgrade:
The console's screen is now way bigger.
It was 96x64 pixels @ 16 bpp before.
Now its 128x128 pixels @ 8 bpp!
But it allows for direct 16 bit drawing.
This does probably slightly affect the price of the console.
It will be about 2 EUR more than it used to be. But it is now way more usable.