New hard lib for pokitto

1

My friend (a great coder) start to write a new lib for the pokitto.

We aim to have an full resolution 220x176 with 16 bits (565) and support the other bit mode (8 bits with infinity (well memory) palette, 4 bits ect…).

We just have some good result but for now i’ve some question to Jonne.

why setup the LCD in vertical ?
Did you have an init in horizontal working ?

We notice that actually writing 1 pixel is very consuming cpu (setup registre ect…) we want to make span rasteriser with direct lcd write.
Can you explain us how you map the lcd to the pokitto ?

Actually we just bind ur lib in the pokitto framework and compil with emblitz.
Jonne did you have a basic setup of the pokitto without the pokitto lib.

Just LCD init, Button Acces for some test.
ect… for testing only the raster ???

I’ve lot more question, but just a little last one, how did you link/valid the return to the loader with your projet (i miss something in the setup) ?
Acttuly you lib core star -> pokitto logo -> 3s to go loader -> sound seting -> project
but when i want to go back to pokitto loader i don"t find my loader.
I will be more easy to only test with sd card using the loader rather than allways flash :stuck_out_tongue:

See test video :

Working test on #pokitto for a new lib full resolution 220x176 with rgb565. pic.twitter.com/ykE8Vy6ecp

— Matthieu (@Aliandrana) 10 décembre 2017
2 Likes
2

Cool project! Definitely I will help you with a bare bones project.

I am very busy today but I will get back to this in the evening.

1 Like
3

ok thanks :slight_smile:

4
  1. because it was easy & reliable
  2. no i had some glitches
  3. pixel write can be done in sequence (dram pointer increments automatically)
  4. pixels are mapped in vertical rows. In 4-bit mode byte 0 includes pixels (0,0) and (1,0). Byte 1 is (0,1) (1,1), byte 2 is (0,2) and (1,2). Byte 176 is (2,0) and (3,0), byte 177 is (2,1) and (3,1).
1 Like
5

All subsystems can be used separately, example:

#include "Pokitto.h"

Pokitto::Buttons b;

int main() {
   b.begin(); //use only button functions
}

Now, even if you #include the “Pokitto.h”, only the functions that are used are linked into the file. Everything else is automatically discarded

If you want to use only the HW low level calls take a look at:

https://os.mbed.com/users/Pokitto/code/PokittoLib/file/fa6899411a24/POKITTO_HW/HWLCD.cpp/

Then, you can do

#include "HWLCD.h"
// and inside main:
Pokitto::lcdInit();
2 Likes
6

This is one of my favourite things about the official Pokitto lib.
Separation of concerns is an excellent principle to adhere to.

4 Likes
7

Many people also do not realise they are fully static classes (or actually, classes with only static members)

Pokitto::Core c;
c.begin();
c.display.print("Hello ");
c.display.println("World !");

is exactly the same as

Pokitto::Core c;
Pokitto::Display d;
Pokitto::Display e;
c.begin();
d.print("Hello ");
e.println("World !);

and will not cause any difference in memory consumption or performance, because they all point to the same structure in the memory

3 Likes
8

Actually I was pretty curious if I was creating 3 different instances for core, display, and buttons when I’d do this. Thanks for explaining!

9

i was wondering if the display is verticaly would hanving sprite data aligned verticaly increase speed in any way mainly for iterating over stuff

10

In hardware sprites the data should indeed be aligned vertically.

In RAM buffered modes it makes no difference. The vertical alignment only affects the transfer of pixels from buffer to screen.

I am happy to say I may have discovered a trick to speed up Pokitto considerably. It involves DMA trickery. But more on that later.

3 Likes
11

I’ve noticed that before.

To go a step further, it’s the same as:

Pokitto::Core::begin();
Pokitto::Display::print("Hello ");
Pokitto::Display::println("World !");

Or even

using namespace Pokitto;
Core::begin();
Display::print("Hello ");
Display::println("World !");

(Of course, using namespace should be used with caution, individual using Pokitto::Core;and using Pokitto::Display should be preferred.)

To be really pedantic though, there is one tiny exception.
Any variable, even when the class is empty, must have an address in some circumstances, so in those cases the ‘cde’ approach could use 3 bytes of memory.
Thankfully in most cases the compiler can effectively elide the instance variable because the instance itself technically isn’t used.

TL;DR:
I’ve been using C++ for too long :P
I know too many of the crazy rules.

1 Like
12

great, i am still figuring out layered direct draw stuff

13

@ThunderZ

Hi Matthieu, have you managed to move ahead with this or were there some questions that were not answered?

1 Like
14

i’ll will make some more questions for sure.

Actually we have 2 projects that will combine:

A new complete raster from Laxer3a my friend, that will let you have 220x176 mode with 16 bits support for the pokitto and that will support other mode (8 bits,ect…)

An nPok (Nano Pokitto Lib) that want to be a simple and slim acces for pokitto. (not specially with cool name or learning feature like the original pokitto lib, just the minimum for coder).

Actually those lib will be design as stb lib design in mind.
Ex :
1 unique file -> nPok.h and that all (.C + .H on a unique file)

2 Likes
15

Sounds really good. Once I get the last shipping done I will also be more involved in the code development.