Yay!!! 
for the new limit.
I’ll have a go at some detection code toninght when I’m back home. Easiest detection would be reading the manufacturer ID. But that does limit to the use of chips to a single manufacturer (Winbond in our case)
1 Like
I’m talking about what the Arduboy2 library does when you disable the USB stack:
If the USB stack is removed from either the FX or the regular Arduboy then that block of code will be in effect.
This is one of the reasons why I think the updated .arduboy format should be renamed .arduboyfx.
To make it obvious at a glance that a game is intended for FX.
(Without having to restrict how games themselves are named.)
That should be fine.
It should probably be the ‘down’ button to keep things consistent.
It’s a shame SPI devices don’t have ‘device classes’ like USB does.
To be honest I was just thinking of checking that there was something on the other SPI address,
regardless of what the device actually is.
Reading the manufacturer ID is probably a bit safer,
I wasn’t expecting that to be possible.
There can always be another ‘homemade’ version of the library for people using other manufacturers.
Speaking of bootloaders…
If some of the FX chips are going to be sold to as strips to modify existing arduboys,
doesn’t that mean those people will also have to flash their own bootloader?
And isn’t flashing the bootloader that complex procedure where you need two pairs of hands?
The JEDEC ID should be ok, right? If no flash is connected you will get 0xff. Assuming there is no ID with 0xff.
Oh I didn’t know you were talking about when the ARDUBOY_NO_USB macro is used.
Having FX appended to the name has the advantage that it will inform the user already it’s an FX game before downloading. Also a developper may just distribute a hex and bin file and not going through the trouble of making a .arduboyfx file
Yes I agree. Down to enter bootloader mode.
There is no other device hooked to SPI input (MISO) so there’s only noise. Could be 0x00 could be 0xFF or something else.
I’m also considering just to read the 1st location of flash memory which, when initialized reads 0x41 “A”
whatever leads to the smallest code size. In any case the test value(s) have to be read multiple times to ensure it’s not an unlucky static combination that matches the test.
Yes you need a ISP programmer to update the bootloader.
Depends on your creativity.
There’s no guarantee it’s 0xFF
1 Like
I was replying to @veritazz saying:
So presumably if the USB stack is removed the ‘down button to flash’ behaviour would remain intact,
which wouldn’t cause a problem on regular Arduboy.
The game’s main post should already make that clear.
Perhaps we should even have a separate category for FX games to simplify matters.
Either that or see if this version of Discourse supports tags.
(I don’t know if tags are built-in or an add-on.)
Most browsers are capable of telling you what the file extension of the file you’re downloading is,
though I suppose most probably hide it by default.
A developer may not bother to append FX to the name of their game,
ao it’s six of one, half a dozen of the other.
Reading just one byte would be small, but probably not particularly conclusive.
I think ideally it should read a few bytes,
because every extra byte significantly reduces the chance of a fluke.
(1 byte = 1/256, 2 bytes = 1/65536, et cetera.)
Hrm, that could hamper the updake of the ‘do it yourself’ FX upgrade.
“Requires ISP programmer (not included).”
I’m counting all forms of gripping tools as ‘hands’ for the sake of this.
And feet for that matter. :P
That’s the case when the ARDUBOY_NO_USB macro is used. When a bare minimal main() function is used to save a few more bytes it will not.( For FX the down feature is redundant in the NO_USB code,)
Thinking about it I may add a minimal NO USB feature to the library. as the FX detection code will enter bootloader mode on non FX Arduboys. The Arduboy FX has a built in press down to enter bootloader mode in case the auto start EEPROM flag has been set.
Thats true but it’s much easier to append FX after a game title than to make an .arduboyfx file
It’s one byte repeated for several times. I’ll have some more thought about it. I like to use functions are will also be used by the main program so no unneccesary PROGMEM gets wasted.
Thinking of it now I could use the Cart::readPendingUInt16 to test for “AR”
Don’t forget the other tools required are also not included 
and an ISP may be one of the cheapest tools required.
I’d probably stick some wires on the pads with tape and hold them down with some clothes pin 
So an FX program will have the USB stack disabled by default?
If not then just flashing normally should work fine.
To be honest I doubt people are going to be needing to resort to tricks like using a custom main to save progmem space with the FX.
Half the point of the FX chip is to avoid having to spend time squashing progmem down,
and even if people do have to start doing that there’s always plenty of tricks that can be done before people start throwing away features.
Technically yes, but in practice it’s not that simple.
People like to have creative control over their games, and that includes the game’s title.
Besides which it would get a bit samey.
Already the number of games that use a portmanteau of Arduino in their title start to sound generic after a while.
I think a separate category would probably be the easiest solution for when the games are actually published.
I think what we really need though is a tool to make creating .arduboy files easier.
Especially if it could be embedded in the forum.
E.g. a ‘submit your game’ form where you fill in all the details before posting (title, version, author, date (auto-generated if not specified) et cetera)
What’s the chance of noise staying steady at the same value?
What’s the change of several different bytes of ‘noise’ matching an expected pattern?
Which of those two chances is smaller?
I would have thought copying a block of data from the FX to RAM is going to be a common operation.
If not, I doubt reading sequential bytes in a loop will be particularly expensive.
As I said before, with most games having their data offloaded to the FX chip, progmem space is going to become less of an issue overall.
Not a small enough issue to not care at all, or to get wasteful,
but small enough that one loop probably isn’t going to hurt too much.
Hrm, I forgot it has to be soldered.
In which case, yes, anyone who’s capable of soldering the chip on should be able to write a new bootloader.
Bah, that’s too sensible.
I’d probably just make use of my feet to hold things.
(Humans are apes after all. :P)
2 Likes
No. I was thinking about an FX version of ARDUBOY_NO_USB.
I agree a tool would make it easier. Not sure about forum. You’d need to upload your files,fill in the fields and redownload the arduboy file.
I’ve played a bit with the cart detection code and ended up with a minimum of 72 bytes code (including exit to bootloader mode code, excluding library functions)
I’ll be adding this detection to the Cart::begin(programDataPage) and Cart::begin(programDataPage, programSavePage) because the program depends on data stored on the cart. The detection will not be added to Cart:begin() as a program does not use any data stored on the cart.
Here’s a video:
oh and chompies moves at 125fps in the vid
2 Likes
That’s cool! Also the logo is new, right?
So an FX game is burned on the device, and then you take out the flash and try to play it?
Question: If you burn a normal game on the Arduboy what happens when the cart is out? I haven’t actually tried this and my dev kits at the office.
It shows “usb boot”? and then will just run the game if you press either A or B?
Just demonstrating a FX program is burned and what happens when the program doesn’t find FX chip.
- If the EEPROM configuration is set to auto start the game will play
- If the EEPROM configuration is set to start with bootloader then USB logo is shown untill you press A or B to start the game.
*the USB logo will be shown also when an non initialized cart / FX chip is present.
Edit:
A nice side effect of being able to press B button to start a game also is that when you press B you are able to change the system sound settings (when supported by the program ofcourse)
@veritazz Yes it’s the latest concept logo.
1 Like
I guess, you wouldn’t actually run into a situation where you remove the flash cart because it will be soldered in, so you’d theoretically never see the USB boot logo, right?
Yes The only case when you would see the USB logo is
- when the cart is empty
- when someone corrupted the carts contents
Edit:
In case you want a different icon. Here’s the original 16x24 image:
1 Like
Hey @Mr.Blinky can we move the link to your python utilities to the head post of the threads where it is relevant? I think this one might be a good one.
1 Like
Okay I’ve added a link to head post here.
2 Likes
yes there’s always some overhead for each ‘tile’
How big do you want those balls? 
