Extensible Loader

[Cartaymon]

How awful
It could certainly do with a RAM disk in there somewhere

[Hanski]

@FManga

Just another idea…

• Mode 1, 20x20 1-bit icons (by mistake, should’ve been 24x24 :P).
• Using 2 dimensions makes it easier to find/select a game than a list
• 4-color Palette stored in EEPROM, can be edited by the user in a settings “app.”
• Screenshot is 110x88 full color, drawn directly to LCD.
• Text in the desktop is the 8-char file name, without the extension
• Text in the window is full name and author name.

I like the possibility to see the screenshot and other info before loading.

As this grid is what the people see first, and the showcase for Pokitto, I would like to have 16-color icons. Maybe also bigger icons, four in a row.

Edit: With the 48x48 size of icons there is just space for 4x3 grid with texts on the 220x176 screen, scrolling horizontally.

[Pharap]

My favourites (in no particular order):

[adekto]

i like the blue iconic version as its something diferent (also might be loading the least amount of data as you have to press into the an info box)
though some future proofing like 16 character titles or something would be nice
and maybe the abilaty to set the 1 bit sprite color

a question i have though could we sort the listing, so our favorite games be on top or on the first page?

[Vampirics]

I know we talk about the look a lot, but there’s a feature I would really like, and it’s deleting and renaming files from the loader

[adekto]

pffs cant delete, create or renaim files as i understand

[jonne]

True. But not all functionality should be crammed into the loader. We should have a file manager app exactly for this purpose. I believe @Vampirics is correct that this is something we need. But it should be an app, not in the core of the loader

[adekto]

yea if sdfilesystem is woking fine now it be an easy program to make, could probebly give it a rough text editor feature, and maybe the bmp viewer stuff aswell

(starts considering just making it myself XD)

[FManga]

PFFS can’t delete a file, but we could mark it as hidden. If a file was “deleted” by mistake, this would allow you to undelete without having to implement a recycle bin. On a PC it’s easy to see which files are hidden and actually delete them.

For favorites, the read-only or system attributes could be used. When you try to delete these files on a PC it would warn you, preventing you from deleting your favorite games unless you really wanted to.

Edit: Another option would be to use the file’s CRC and make a list of favorites in the EEPROM. If you rename a file or delete it then add it again, it would still know that it’s a favorite.

With the 48x48 size of icons there is just space for 4x3 grid with texts on the 220x176 screen, scrolling horizontally.

16 colors @ 220x176 means we can’t have a framebuffer and rendering the screen requires reading about 14kb of image data scattered around the SD. It can be done, but it might feel slow.

[Hanski]

Slowness is the last thing we want in the loader. We can also store image and other data in SD in a cache file, as typically the content of SD do not change often, but it is often read.

[FManga]

Today I got the loader to read /sd/loader/boot.pop into RAM then call it.

boot.pop doesn’t do much yet, other than refresh the screen continuously in mode 1. Mode 1 takes up too much RAM though, so I’ll probably switch to mode 2 (110x88, 16 colors) or draw directly on the LCD.

The filesystem API has been exposed so it’s easy to call from tiny programs in RAM or from games in flash.

Still needs more testing and bug fixing, but ideas are moving out of the “works theoretically” category and into “works.”

[spinal]

The filesystem API has been exposed so it’s easy to call from tiny programs in RAM or from games in flash.

So your new loader can be looked at as if it is a small OS of sorts?

[FManga]

So your new loader can be looked at as if it is a small OS of sorts?

When you activate the loader, then it behaves more like a bootloader: all it does is load a “kernel” (boot.pop) into RAM. Beyond that, I’m not yet sure how OS-like I’ll be able to make it due to the severe RAM constraints.

On the other hand, from a game’s point of view, this loader is just like a ROM API and it can be safely ignored at zero cost. So much so that one of the goals is to maintain compatibility with existing bins. In this situation, it’s not like an OS because it isn’t running in the background, games are still programmed “bare metal”.

I see the filesystem API as a bit of a stretch-goal. The priority is to make a modular loader that can do things that a “monolithic” loader can’t do in flash.
Games that want to use the loader’s API would do it like this:

    FSAPI &fs = *(FSAPI *) (0x40000 - sizeof(FSAPI));
    fs.init("sd");

    FILE *fp = fs.fopen("/sd/path/to/file.txt", "r");
    if( fp ){
        char buffer[256];
        fs.fread( buffer, 1, 256, fp );
        fs.fclose(fp);
    }

[FManga]

I finally got the details worked out. The FSAPI and “bootloader” is running in Flash, the heap is in SRAM1, data/bss/stack in SRAM2.

That means all of SRAM0 is free!

That also means the FSAPI will get along with games since they generally use only SRAM0.

Now to plan/write the “kernel.”

[Hanski]

That means all of SRAM0 is free !

That is great!

[FManga]

Another progress update:

• Made a nodejs script that reads a json file with tags and one or more bins and creates a ready-to-run POP file.
• Basic POP parser, successfully loaded a plugin from the kernel into RAM and called it.
• Drawing to the screen in Mode 2 (110x88, 16 colors).

I’m thinking of organizing things like this:

• The “kernel” (/loader/boot.pop, 0x10000100 to 0x10002000) can occupy up to ~8kb in RAM. That’s code and data, including the framebuffer and palette.

• A “window manager” (/loader/ui.pop, 0x10002000 to 0x10004000) occupies another 8kb and uses the kernel-provided API for drawing to the framebuffer.

• Helper/parser pops (/loader/parser/*.pop, 0x10004000 to 0x10007800) can take up to ~14kb for reading POP/GB/MPY/TXT/etc files and provide an API for reading metadata/images to be rendered by ui.pop. These are loaded/unloaded on-demand.

[jonne]

When you get to the point of jumping to the loader, take a look at how it is done in the current loader. The order in which peripherals are shut down and disabling interrupts is pretty critical

[spinal]

I have almost no idea what any of this means, but I am very excited that it is happening

[jonne]

Felipe is just going to bypass the arterior vernacular valve to the solar plexus in order to alleviate the limbic swelling of the poster nasal humbugudrum.

So no need for concern! Two pills and a salt-free diet for 3 days. No Nintendo.

[FManga]

When you get to the point of jumping to the loader, take a look at how it is done in the current loader. The order in which peripherals are shut down and disabling interrupts is pretty critical

Jumping to the loader? That bit is done by the PokittoLib and works with my loader without any changes. Or do you mean the initialization after the jump?