I kind of like having it as an optional thing.


I’ll be honest, I don’t feel comfortable with it being the default, to be honest. Please make it optional, as @torbuntu said

It’s totally irrational, and I can’t explain it well. I guess I just want my Pokitto to operate at its nominal speed for some reason :stuck_out_tongue: (I never overclocked my PC or felt the need to for the same unknown reason I guess).

Also, I’d like to know the effects on the battery as well, if that could be possible to measure. I think overclocking is OK (turbo mode!) when you really need temporary power (like for generating our stuff, or simulating heavy things), but if that’s for doing some kind of while(!hasFrameEndedYet()); 99% of the time, it’s just kind of silly in my opinion


The issue I have with it being optional is that enabling it is a bit of a hassle:
In Java, you have to put
"--defsym=_OSCT=2" inside SFlags -> Pokitto and "-D_OSCT=2", inside CPPFlags -> Pokitto.
This feels at odds with how simple and easy everything else is.
Ideally we’d just call Game.goFaster() or something, but that complicates things internally.

As for wanting the Pokitto to run at its nominal speed… there isn’t one, really. While the data sheet describes it as a “32-bit MCU family operating at CPU frequencies of up to 50 MHz.”, that number is more of a TL;DR. There are various parts in the chip that can have different speeds and limitations. The SPI bus, for example, can’t go above 25mhz.
It is also possible to underclock the CPU.

On a PC, overclocking means you risk damaging something by overheating.
On the Pokitto it just means that it isn’t running at the same speed used by the default mbed startup code. It’s 100% safe and well tested: GB and MicroPython games have been running at 72mhz for a while now.

About battery life… the reason we haven’t looked into sleep modes for decreasing power consumption is the elephant in the room: the screen consumes far more power than the CPU.
If someone wants to make a Tamagotchi that’s always on, the #1 priority would be implementing some way to turn the screen on/off.

In summary, while overclocking only to get stuck in a while(...); loop might seem silly, it has no negative consequences or waste. Since the majority of games benefit from higher framerates, it’d make sense that overclocking be on by default and we’d use a flag for underclocking in exceptional situations.


During the python compo, when the OSCT=2 was introduced, I noticed that the game I was working on, had some artifacts due to the overclock. The game have high contrast sprite and the some sparkling pixels were visible on Hardware display with full moving scenes.
Not sure if later, the problem was fixed by reducing SPI frequency or simply I get used to.


“Sparkling” afaik is caused by transitions between command/data modes while writing to LCD controller. When the CPU is overclocked, some LCD controllers (its individual) can not handle the higher signal transitions and begin to cause errors.


Release v0.1.1

  • IDE: New CPU Profiler
  • IDE: Run now restarts the emulator if it’s already running
  • IDE: Fix error in autocomplete
  • Java: Overclocking support
  • Java: Optimized float (23.8 fixed point) multiplication
  • Java: Fixed crash with new in property initializers
  • Java: Fixed bug in __inline_asm__
  • Java: Fixed bug with parenthesis not returning the right type ((expr).method() failed)
  • Java: Fixed bug with return or continue used in an if+else without a block.
  • FemtoLib: new function screen.getPixel()
  • FemtoLib: new function Game.limitFPS()
  • FemtoLib: Optimized fillTriangle
  • FemtoLib: Optimized drawHLine
  • FemtoLib: Optimized image.draw (1 of 8)
  • FemtoLib: Prompt popup can now be customized
  • FemtoLib: Fixed crash in image.draw and sprite.draw
  • FemtoLib: Fixed bug in drawHLine and drawVLine in Direct mode


Where does the map file go? i need to look at the ROM consumption.


It becomes a const char array in ROM. Not sure I understood the question.


He means the actual .map file that is generated by the compiler


Oh… it’s in the maps folder.


I mean the linker map file.

Cannot still find it. In the TEMP folder there is only:

PS C:\Users\hannu\AppData\Local\Temp\XYjccr> dir

    Directory: C:\Users\hannu\AppData\Local\Temp\XYjccr

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        27.9.2019     13.12            124 1.d
-a----        27.9.2019     13.12          25204 1.o
-a----        27.9.2019     13.12           4496 2.o
-a----        28.9.2019     14.30           1315 3.d
-a----        28.9.2019     14.31        2657368 3.o
-a----        29.9.2019     13.44            124 4.d
-a----        29.9.2019     13.44          25204 4.o
-a----        29.9.2019     13.44           4496 5.o
-a----        29.9.2019     13.44           1315 6.d
-a----        29.9.2019     13.44        2657372 6.o
-a----        29.9.2019     13.45       50000000 fs.img
-a----        29.9.2019     13.44         771594 generated.cpp

PS C:\Users\hannu\AppData\Local\Temp\XYjccr>

It is neither In the project directory:

PS C:\bin\FemtoIDE\IDE-windows\projects\ZombieFlock> dir zombieflock.*

    Directory: C:\bin\FemtoIDE\IDE-windows\projects\ZombieFlock

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        29.9.2019     13.45         209208 ZombieFlock.bin
-a----        29.9.2019     13.45         302636 ZombieFlock.elf

Also, is there a log of C++ compiler & linker output somewhere?


Oh, you mean the linker script? The path to it is in your project json, it should be something along the lines of /javacompiler/pokitto/link.ld.


I got the map file generated. I added "-Wl,-Map=${projectPath}/${projectName}.map"to the Project.json, in the “LDFlags/Pokitto” section. Now, it generates “ZombieFlock.map” file in the same folder as the bin file.


Unfortunately the separate frame data of the sprites is not visible in the map file. I suppose the are all included in this:
.rodata 0x000211e0 0x10e50 C:\Users\hannu\AppData\Local\Temp\ccKenERh.ltrans3.ltrans.o


The frame data is in local variables. Those don’t show up in the map, do they? :thinking:


I found the way to get the ROM bitmap data size information from the ELF file (in Windows). You can use the readelf tool that comes with Femto:

  • Open a command prompt in the project folder

  • ..\..\windows\arm\bin\arm-none-eabi-readelf -sW zombieflock.elf | findstr "OBJECT" | findstr "CastleDay" | findstr "getImageDataForScreen"

  • This outputs:

  424: 0002561c  1962 OBJECT  LOCAL  DEFAULT    1 _ZZN12uc_CastleDay21getImageDataForScreenEPN8up_femto7up_mode15uc_HiRes16ColorEE4data
  • The third value (1962) is the size of the static data[] array in the function uc_CastleDay::getImageDataForScreen(), which contains the image data.


I do not know if this has been there before, but I just noticed that:

  • If I copy a text(ctrl-c), press ctrl-f, and paste the text (ctrl-v) to the find dialog, the text goes also to the code.


Thanks for the report, I registered the issue here.


New feature coming in the next release (already in bleeding edge, if anyone wants to try it):

Relevant code:

import sprites.Dog;
    Dog dog = new Dog(); // an animated sprite imported from Aseprite
    dog.run(); // "run" is one of the animations in the spritesheet
    dog.x = 110;
    dog.y = 88;
    dog.setRecolor(recolor); // will be xor'd onto the color index of each pixel
    dog.rotozoom(screen, rotationAngle, spriteSize); // angle in radians, spriteSize is a radius


This come really unexpected. Is a great addition to FemtoLib and looks incredible accurate.
Your tool is making Pokitto better and more fun to play at every release.