Sin wave seems cleaner to me.
The txt one is not so nice, maybe some border to close it?
Just my opinion.
I think both of them are beautiful. We can open poll for this 
actually my vote goes to sine wave.
I agree with you on the txt one. I just didnât want to make the txt huge. I will tweak it in a bit.
As for the sound one, I am happy with either. Piano is more âuser friendlyâ but sine is much more representative to what the file will be. It can also inspire people to research what it is, while with piano, people who do not know about trackers might try to run it to âplay a pianoâ etc.
As for custom app icons, I think 1 bit would work fine for 24x24 icon (look at original mac or GeOS icons).
1 Like
I messed with it again, have I gone too far yet?
4 Likes
I like it, but we would need to see it on the actual screen.
The frame around the files might make it harder to read, as we are losing a lot of âwhite spaceâ and thatâs what helps with legibility.
Edit: Also, the âfilled inâ text file.
2 Likes
looks pretty good.
though some things is you can really go to the edge of the screen with your border lines, the screen itself has a black plastic border so it works.
would it be ecstatically pleasing to stack the time and date on top each other?
could show more entities in the file viewer
it looks nice but i think we need to minimize the amount of graphics or reuse as much as possible since this would be in some games that want to have it build in (maybe all games idk)
1 Like
Was any more thought put into the use of folders at all? I understand that there will be issues with RAM/flash usage, but itâll gett awfully messy on the SD card without them.
1 Like
Yes Iâve started looking at this. I have just gotten @Initgraph 's Chip-8 thingy working and thereâs like 30 ROMs on the card and the messiness of using root folder only is clear. I agree folders should be added, perhaps not for bootloading but for game data it would be very nice.
Major breakthrough on the loader.
It can now initialize SD card, open file, read binary, write binary to flash memory while in IAP mode and then reboot automatically.
Technical background:
Accessing the SD card is not simple when you want to do IAP (in-application programming) at the same time. This is because interrupts can cause the existing program to jump to a memory area that you intend to write / are overwriting. There are many ways to solve this, my way was to make the SD card access such that no interrupts are needed. In my solution, interrupts and SysTick are disabled when the flash memory is written.
This means a Gamebuino-style game loader (the type that loads a âloader programâ into flash on every game switch) is already within reach. The problem however is, that I donât like the idea of overwriting the flash twice every time the program is switched (twice means that you first write the loader program into memory and then write another time to fill the memory with the game you selected.)
I intend to still investigate if I am able to locate the SD card routines into a special memory area in such a way that the same routines are accessible from both the loader and your own code. In this way the sd card routines are not duplicated in memory (as in Gamebuino), and you get SD access for âfreeâ in your own programs. Furthermore, I would like to make the loader so, that information about the progress of the flash programming is written on the screen as it happens, so that the user knows whats going on. All of this may be technically too challenging at the moment, and if it is, I will switch to plan B which is a resident, Gamebuino-style loader that needs to be loaded firs before the app can be switched.
Below is a screengrab from J-mem that shows the âAAAAAAAâ that was read from SD card and written to Pokitto flash memory in IAP mode.
3 Likes
Yes! Now the loader is jumping through the SD card files and writing AA.BIN, BB.BIN, CC.BIN in turns after each automatic reset. So first it fills with AAAA⌠from file AA.bin, then BBBBB⌠from BB.bin, then CCCC⌠from CC.bin and each time it resets, examines memory and jumps to the next file, overwrites and resets.
Now I know this is going to work. Its just down to writing a nice interface.
2 Likes
Nice, im not sure i understand all of it but still nice work !
2 Likes
Thatâs OK. All that matters is that the loader app is going ahead and its looking positive.
I like to report this stuff because I know there are people here who like know about technical details.
In two years time youâll be doing this stuff yourself, laughing at how easy embedded electronics is! Thats the magic of Pokitto. I know because I started from zero myself - I am not kidding. I have no formal training in this stuff. And now I am pointing out technical mistakes in the datasheets to NXP (has happened twice).
Edit: the second time was pretty funny. I was at our booth in Maker Faire Bay Area and an asian guy (Japanese I think) comes to the table and as I explained the technology he said âI have designed that chipâ (ofcourse its always a team effort). His english was pretty poor, but he was from NXP. He didnât know that they have a mistake in the Code Read Protection routine (ROM bootloader overwrites the chip even when CRP is set).
2 Likes
I donât. Usually ttf versions donât scale properly. I usually just grab a char set image from google image search.
If you donât have anything by the time I get home later, Iâll hunt out the source code for Frodo 3ds, I have a bitmap arranged in ascii order, I think it was 1bpp so it should be really easy to use for other projects.
luckily im learning a lot from the posts on this site, but i am no stranger to programming.
I used to write small games in Basic (years ago on the MZ-800) an more recently started working in VB 6.
I am aware this is old code but i already surpassing my coworker in using it for a production machine.
And although the syntax of the languages are different the basic logic still applies. (if/then/else etcâŚ)
Next up C++, so i can play around with Pokitto.
Sofar i am enjoying the ride
1 Like
If you donât mind looking for it it would be nice. I am writing the loader interface at the moment, am too busy to search for the font. If it is as some sort of header file in Frodo, please post that as well. May be it is already in correct orientation.
Here is a gif of the charset if ascii order. When I looked at the frodo source, it seems I used the font as a binary file and it was 16x16 for some odd reason, I donât think it was the font I originally intended to use.
As you can see, itâs missing the first 32 characters, I donât think that they are usually printable anyway.
oh, here is the full charset from the c64 in whatever non-ascii order commodore used⌠it has all the characters I used for the mockup screen.
Thanks
FYI, found this also:
http://style64.org/c64-truetype
Edit: forget that, the license is really stupid. I will use your bitmap instead
Edit2: the reason why the license is really stupid is because the demo group is from USA and:
Typefaces, fonts, and their glyphs raise intellectual property considerations in copyright, trademark, design patent, and related laws. The copyright status of a typefaceâand any font file that describes it digitallyâvaries between jurisdictions. In the United States, the shapes of typefaces are not copyrightable
Iâm not 100% sure, but apparently typefaces arenât allowed to by copywrited because just like clothes, they are considered more utilitarian that art.
So I guess as long as you create the font file yourself, there shouldnât be an issue.
1 Like
I got a call while I was writing my edit. Yes you are correct. And what makes it even dumber is they are not the original creators of the typeface in any case.