ProjectABE and large sketches

So far for Tackle Box FX, we have taken the approach of just let the sketch grow. ProjectABE handles sketches larger than 28kb just fine. However, I found it seems once a sketch crosses 32kb, ProjectABE fails to boot properly. You never see the “FM” logo at start, and it takes about 30 seconds or so for the Arduboy skin to show. Then from there the game never loads, just a blank white screen.

I’ve not looked into this in any depth yet. I plan to tonight. But starting the topic now in case anyone else has seen this? How are other games working with large sketches in the short term?

Ping @FManga in case you are aware of this. I’ll take a look tonight and see if I can figure anything out.

1 Like

FManga can’t see this, he isn’t a member of project Falcon.

1 Like

ah that’s not good. @bateske can we add FManga?

Here is a test sketch demonstrating the issue:

All it does is draw one dummy image to the screen, and that image has 28,327 frames:

I am finding if a sketch is 32,816 bytes or smaller, it loads fine in ProjectABE. If it is 32,818 bytes or bigger, ProjectABE hangs.

Basically that image with all those frames allows me to pad out the sketch. How much to pad is defined here:

The boundary is 32kb + 48 bytes

looks like maybe a hint in the hex file:

All those repeating 5’s are the dummy data padding out the sketch. After that there is more data. So it feels like maybe ProjectAbe isn’t able to get out to the data at the end of the sketch. I’m looking through ProjectABE’s source right now.

EDIT: the online version hangs in the same way

Well that was easy :slight_smile:

Changed src/atcore/Atcore.js, from

let core = new Atcore({
    flash: 32 * 1024


let core = new Atcore({
    flash: 64 * 1024

I edited www/app.js in my local ProjectABE installation and made the above change in the two places an Atcore is instantiated. This is by no means a good change for ProjectABE in general. But to enable big sketches in this short term period of waiting on FX to flesh out, it will do.


If you hadn’t figured it out I would have said contact FManga and tell him you want to try Mr. Blinky’s flash mod (since that’s what the FX is essentially based on).

Personally I’m half and half about bringing FManga in.
On the one hand he’s very skilled and turning ProjectABE into an FX emulator would be good,
but on the other hand we do have to draw the line somewhere,
otherwise we’ll end up with half the forum in TeamFalcon.

My main interest is finding a good dev workflow for FX. At least in these early days. We got lucky that the fix was so easy. But it’s possible other issues that are harder to fix come up. Also if we really start hacking on ProjectABE without FManga being aware, it’s a little strange.

IMO, the focus should be on making FX games as good as they can be, and if that means inviting more people, I think that’s the right way to go. But that’s just my opinion.


Open source licences are designed to allow that.

If someone isn’t comfortable with the idea that someone could start significantly modifying a copy of their code without telling them then they shouldn’t choose an open source licence.

Perhaps, but the line still has to be drawn somewhere.
12 people, 15 people, 20 people…

Wherever it’s drawn there has to be a cut off point,
otherwise there’s not much point keeping it all secret in the first place.

For what it’s worth, @filmote, @luxregina and I have discussed whether or not to ask for Keyboard_Camper to be accepted into TeamFalcon because he was our original beta tester.

I wouldn’t be surprised if some people think MLXXP should be involved because he’s the maintainer of the Arduboy2 library,
and of course there are lots of other good contributors that currently aren’t involved.

If anyone wants an online ProjectABE that supports more flash:

I set the flash limit to 256kb. My sketch is nowhere near that big (I’m at about 36kb), so no idea if problems will emerge. But it’s working great for my current sketch.

Supports the ?url=<url to hex> param just like the main one.


Yeah I reached out to him a bit ago but he was moving let me see if he is around and what he thinks about this.

1 Like

That’s perfectly ok for our ATmega32U4 if you try to upload a larger hex file (and we forget about that the bootloader is overwritten) that it larger than 32K it would wrap arround and overwrite the vector area again.

Maybe external flash support could be added to projectABE in the future. But until then we need to rely on the devkits.

True FX support in ProjectABE would be awesome.

Just to be clear, the flash size hack is just that, a hack. It’s just enough to allow writing a sketch that is too large for the Arduboy but still be able to run it on something. The change is not a good one, and the sketch that is too big is ultimately worthless. But for a very short term thing, it’s better than nothing.

I just invited @FManga welcome to the team :smiley:

1 Like

Thanks, looks like I’ve got lots of reading up to do. :slight_smile:


It’s all based on @Mr.Blinky flash mod

I started looking into this. From what I understand, I’ll have to make ProjectABE run the bootloader for things to work (right now it just runs the sketch), so it isn’t just a matter of adding support for one more chip. That means implementing the SPM instruction on the CPU, which wasn’t needed so far.

I’ll have to think about how to put things in the newly emulated flash as well. Drop in a hex and an image for development?

If that sounds about right to you all, I hope to get to it this weekend.


Awesome to have your support there is a lot of discussion in the other threads on how to allocate and define the expanded memory space.

Hey @FManga, have you had a chance to look at ProjectABE? I think this is crucial to being able to develop games efficiently :slight_smile:

Yeah, I started work on this but had to do some traveling and haven’t managed to finish yet. I hope to get some more work done this weekend.