[wip] Mixed screen mode

Possibly, it wasn’t a plan though.

I am having a little trouble with 8bit scanlines, Am I doing this right?

            for(x=0;x<220;){
                uint8_t t = *d++;
                uint32_t color = uint32_t(paletteptr[t])<<3; scanline[s++]=color; scanline[s]=color; x+=2;
            }

Should the second scanline[s++] be like this also? Now the next iteration writes with the same index value s.

Sorted it. The issue was more to do with the way I was detecting the scan lines (typo).

1 Like

hmmmmm, I’m starting to think that this idea is completely impossible :frowning:
I don’t think that the pixel layouts can be merged into a single buffer. Either that or my math skills are nowhere near up to the task.

[Edit] got everything sorted out. Just need to tidy it up and re-implement it into a newer pokittolib then PR it.

OK, I currently have a different palette for each ‘mode’ That’s a total of 276. I am currently doing this by extending the mode13 palette, I don’t think it will effect any other modes. I’m just trying to come up with a nice demo to show it off.
Although, a lot of the gfx routines might be completely unusable in this mode.

1 Like

Here is a small update…
A test file, all it does right now is show a couple of images.

mixMode.bin (69.5 KB)

The demo is a little slow as it is redrawing the full screen twice each frame, Once for the 256 colour image, then again for the 4 colour image. This could easily be changed to only draw part of each image.

8 Likes

That looks seriously sexy

Edit: I’d love to have “Pokitto Workbench” as a program, where you could arrange, set favourites etc for the game binaries. If I were to add that functionality to the loader, it would make the loader too big.

Clock and calculator obviously would also be needed. Analog clock.

3 Likes

oh a windowing system, so want that even if its inpractical for the hardware.

looking good

4 Likes

I would love to make the loader look better in some way. But I assume there’s almost no space for something like this in it’s place. Perhaps Pokitt-OS could be a stand alone app that could be loaded only if the user wants it?

1 Like

A windowing system would almost certainly be possible.
The diificult parts would be making it work on multiple screen modes and deciding how to best handle the memory allocation.

If the windows were specified at compile time then they could be statically allocated, but if dynamic features were needed (e.g. adding and removing controls/widgets at runtime) then dynamic allocation would be needed, and that would complicate matters.
It’s hard to judge whether dynamic allocation would use more or less memory.
On the one hand it means the data for a window is only loaded into RAM as and when it’s needed, but on the other hand there’s overhead involved in managing dynamic memory, and running out of memory at runtime is a more serious issue than not having enough memory at compile time

One way to do it would be to remove the loader GUI and change the functionality so that instead of activating the loader GUI, pressing C at the start instead looks for PokittOS on the SD card and loads it if it’s present (and if it isn’t, it frowns and continues with the game).

That would give people a bit more room for writing games and have PokittOS handle all the important stuff:

  • Selecting a game to load
  • Managing the ‘cookie’ system
  • SD card management (rename files, move files etc)
  • Setting the time and date (with a more friendly UI than the current one)
  • Maybe a small hex editor for editing game save files on the go?
  • @jonne’s calculator (and of course, it would have to support programmer operations like XOR, LSH, RSH, ROL and ROR)
  • Utilities to do stuff with hats (e.g. send and receive IR messages with an IR hat, edit wifi settings for a wifi hat, blink the LED on an LED hat :P)

A keyboard hat would really help here, but it’s not impossible to pull off without one.

Digital is superior :P


A somewhat unrelated anecdote:

Several years back when I was still a rookie programmer I was doing Lua programming with the Minecraft mod ComputerCraft.
I decided to try making my own GUI-based OS to replace the default OS (which was basically just a non-graphical terminal).

It was an interesting experiment.
I think I tried to go a bit OTT with it though.
Long story short, I tried to add a proper process and threading system after reading a book called “Operating Systems Demystified” (very good book,very interesting) and for whatever reason I put the project on hold and moved on to a different project.

I think I’ve still got most of the code lying around somewhere.

I Think I have done a valid PR to get this added to pokittolib. It might be in a future update for all to use!

3 Likes

You did a valid PR all right.

Your mixmode demo is too good for words. Makes me want that mouse-hat for Pokitto so bad.

mixmode.bin (55.6 KB)

1

4 Likes

I’m half tempted to see if 110x88x16 and 220x176x2 would be worth doing as a second mixed mode using half the buffer size…

I’m trying to use mixmode in the mbed online compiler but I’m getting a black screen. Can anyone test if it’s working properly for them?

With what example code?

I only tried examples/mixmode example.

hmmm, can’t seem to port mixmode to the sim. It compiles OK, but just crashes the sim straight away after the volume screen.

1 Like

After that it setups the gfx mode and starts to use it. Put a breakpoint where it first draws the new mode gfx to the screen

Got it mostly working, palette not working though, I wouldn’t expect that to be any different.

1 Like

Fixed and updated :+1::stuck_out_tongue_winking_eye:

4 Likes