Minimum Pokitto Library


#1

Does your project need every last byte of flash?
Do you need just the bare minimum to get your code running?
Do you want to write in a language other than C++ and need to get the hardware setup so you can do your thing?

Then here you go:

While PokittoLib/FemtoLib/MicroPython try to give you everything you could need to make a game, the minimum library gives you hardware initialization and 8 11 functions.
Here’s an example featuring the entire API:

#include "PokittoMini.h"
// size with -O3: 2448 bytes
// size with -Os: 2084 bytes

int main(){
    enableDAC(); // enable sound
    int i=0;
    int x=0, t=0;
    while(true){
        if(aBtn() || bBtn() || cBtn() || upBtn() || downBtn() || leftBtn() || rightBtn())
            writePixel(i++); // write a color to the screen
        if( !x-- ){
            writeDAC((t>>5)|(t>>4)|t++); // write some sound
            x = 500;
        }
    }
}

That’s it. If you need anything else, either re-implement it or rip it out of PokittoLib/FemtoLib.

To invoke the loader, hold C while turning the Pokitto on.


[WIP] Doom clone FPS
#2

Firstly, this doesn’t have a licence.
(If it was all pulled from the PokittoLib then it should still be BSD 3-clause.)

Secondly, what language and/or environment is this supposed to be for?
The .cpp file looks like a mishmash of C and C++ code,
and the header wouldn’t compile as C anyway.
(Because of the reinterpret_cast, not because of the bool. It could be made to compile as C with a few tweaks, e.g. including <stdbool.h>.)

Lastly you’ve got u8 in the header, which isn’t actually defined anywhere.
You’re also using uint32_t (without std::) but aren’t including any header to actually define it first.)

(Also now I think about it you seem to be defining cBtn twice as well. Once in the header, once in the .cpp.)


#3

Does this mean, I could configure a sort of transpiler for Groovy, how you made Javitto?


#4

I don’t know what the original licence for startup.cpp is. It’s based on mbed’s startup_LPC11U68.cpp. The intent is to phase that cpp file out completely, moving all of that code out to SystemInit.s.

SystemInit.s is going to be PD/CC0. I’ll have to add a LICENCE file saying so.

How’s this for a more C-compatible header?

inline bool aBtn(){ return *((volatile char*)(0xA0000000 + 1*0x20 + 9)); }
inline bool bBtn(){ return *((volatile char*)(0xA0000000 + 1*0x20 + 4)); }
inline bool cBtn(){ return *((volatile char*)(0xA0000000 + 1*0x20 + 10)); }
inline bool upBtn(){ return *((volatile char*)(0xA0000000 + 1*0x20 + 13)); }
inline bool downBtn(){ return *((volatile char*)(0xA0000000 + 1*0x20 + 3)); }
inline bool leftBtn(){ return *((volatile char*)(0xA0000000 + 1*0x20 + 25)); }
inline bool rightBtn(){ return *((volatile char*)(0xA0000000 + 1*0x20 + 7)); }
inline void writePixel(int color){
    volatile int *LCD = (volatile int*) (0xA0002188);
    LCD[124>>2] = 1<<12;
    LCD[ 0 ] = color<<3;
    LCD[252>>2] = 1<<12;
}

Defining cBtn twice isn’t a problem since its marked inline.
Jonne has pointed out that it would also be good to have a function for writing sound, so I’ll add that too.


From what I understand, Groovy isn’t going to transpile very well to C++. Maybe porting one of the microcontroller-based JVMs would be a better idea?


#5

I demand that! Seems like compiling the project right now is not out of the box.


#6

Updated the first post with a working FemtoIDE project.
Just drop that into your projects folder and build.
Also added:

  • enableSysTick() (but you have to supply your own systick function for time-tracking)
  • enableDAC() and writeDAC(unsigned char) for sound.

We are now at 11 functions.


#7

If it’s the one from mbed-os then it should be Apache 2.0.
(I looked and couldn’t find an overriding readme for LPC11U6X, though some other NXP chips have one.)

I have mixed feelings about that.
On the one hand it has the potential to produce smaller/faster code,
but on the other hand it’s easier to mess up assembly and harder to maintain it,
so it’ll need liberal commenting.

You’re still missing the includes, but otherwise it’s closer to C compatibility.

(Assuming C compatibility is an intention of course. Personally I’d rather have pure C++11 than a C/C++ mish-mash.)

It’s not a compilation problem, but it’s still a bit awkard (i.e. not very ‘DRY’).


I think the main problem with Groovy is that it’s dynamically typed and supports duck typing,
neither of which transpile well to C++.
That’s the kind of thing that only really works well on a VM or with lots of memory (to maintain hash tables).


#8

Love the concept on light lib.
just add the minimum and go :slight_smile:


#9

This library isn’t specifically meant for C/C++. “Library” might be a bit of a misnomer: once the startup.cpp code is translated to assembly, this would probably be closer to a bootloader, as its primary concern is to leave the hardware in a ready-to-run state. The header file, supplied for convenience, is not actually needed at all and can be removed (which is why startup.cpp has its own cBtn). An example of this is if someone were to try to make a game entirely in assembly, in which case this would be a great starting point and the header wouldn’t be needed.


#10

I really started to like asm/4k gamejam idea over this lib!
But I still think the next jam should be done with any programming language one chooses. But maybe after that we can have the ASM Jam.


#11

Then perhaps the other buttons should also (eventually) be implemented in assembly and the header should just act as a function declarer/exporter?


#12

I’ll be waiting until licensing is clear but am loving this, thank you very much :slight_smile: Could be very useful for my C projects. I also like the API, writing sound seems like Unix. Great job.


#13

Reading button state is litterally two ops:

LDR r0, =A_BTN
LDR r0, [r0]

Having a function for this is a bit odd. The proper way to do this in asm would probably be to use a macro instead of an actual function.
In C/C++, these functions would normally be inlined. Having them call assembly would prevent that, so I’d prefer to violate the DRY principle.


About the licensing, the updated lib specifies that SystemInit.s is in the public domain. The rest is going to be rewritten so it can be PD too, but it will take a while since it isn’t a top priority. Once it is rewritten, however, it will be compatible with the existing code so updating will be safe and painless.