ArduGolf - 18-Hole Mini Golf

I am not a much knowledgeable person in terms of arduboy developing but I am sure there will be people willing to help you who has much more knowledge than me on arduboy support.
As far as I can see, your games are loved by a lot of people (including me) and people would gladly help to make your games accesible for more people

1 Like

I left this site for a year or so and WOW. The quality of the new games is incredible!!! This is one of the nicest-looking games on the system! Amazing work! I want to play this, today!

3 Likes

In the source I noticed you initialize FX using

FX::begin(FX_DATA_PAGE, 0);

Do you actually save to page zero or do you select a different save page later on in your code?

If data is saved to page 0 the flash cart will get corrupted and you’ll probably see the USB boot icon appear the next time in the loader (when testing the game in developer mode)

Yep, I’ll update that! I understood much less about building for FX at the time. I was using an older version of your fxdata-build.py script that didn’t handle save info, and when testing the game I had a script that built and wrote a mini flashcart with just my game to the hardware, so the isr table was patched. I didn’t mind this as I do more coding than gaming on my Arduboys… but I didn’t know there was a better way.

Now I have a little more knowledge of FX structure so I have abominations like this instead in current projects:

constexpr uint16_t FX_SAVE_PAGE =
    (FX_DATA_PAGE - 16 * NUM_SAVE_SECTORS) & ~15;

But I’ve noticed the script supports save sections now and outputs two different bin files. I’ve actually been meaning to ask you whether I’m correct in my understanding of the current dev flow. From looking at PoA’s fxdata.txt I’ve figured out the savesection thing, but PoA’s .arduboy distributable file has no ā€œflashsaveā€ designated in info.json – the save sector is combined into the main data bin.

  • Do flashcart builders now sector-align the start or end of the games’ fxdata?
  • If so, is it still possible to support save info that spans more than one sector (curious how the data/save pages are calculated)?
1 Like

I hadn’t looked at (and thought about) the .arduboyfile before. A single fxdata file with save data included will work when uploaded to the development area but not when the game is made part of a flash cart. The reason for that is that the builder scripts can’t detect how big the save data is and can’t patch the save ISR vector correctly. So yes the .arduboy file requires flashsave section.

  • the (read only) fx data is aligned on 256 byte pages and will always take up a multiple of 256 byte pages.

  • the (read/write) fx save data is aligned on multiples of 4K bytes because of the the minimal 4K block size for erase and will always take up a multiple of 4096 (4K) bytes because of that.

When stored in the development area, the save data is stored at the end of flash and therefore is always automatically aligned to 4K. the read only fx data is stored below the save data.

When the fxdata is part of a flash image. the save data will be stored after the read only fx data and will be 4K aligned resulting in a gap of 0 to 15 unused 256 bytes pages between the fx data and save data.

Yes, you can have as many 4K save blocks/sectors as you want but currently I have not implemented a save system that makes use of multiple 4K save

first the size of fx data is determined in 256 byte pages and then the save data is size is determined in multiples of 16 x 256 byte pages. For the fxdata-build python script this is done after the data is created from the fxdata.txt file. For the flash (cart) builder scripts the file size of the relevant files are used.

1 Like

Thanks a lot for the detailed answer! It makes complete sense now.