::

I don't see why you'd need _console or _version. PICO-8 is supposed to just be PICO-8 and offer the same exact features despite running on Windows or OS X or Linux or rpi or C.H.I.P.

The only reason I could see _console is because of GPIO space being different between the various devices. But accessing the GPIO area is something that requires Administrator or root access so, it's probably not the highest of concerns.

::

I do remember that 0.1.8 had 30fps exports, but ... does adding _version help you with that at all? Nope. The BBS gets automatically updated to the latest versions and if you want to be able to open newer carts that use newer features you'll have to download the latest version of PICO-8. It's not even that the cart will function partially, but more that PICO-8 outright refuses to run it because the version number in the cart itself is newer than what your version accepts.

So, is _version for the times when the internal cart version number isn't incremented and you have a user who hasn't updated their PICO-8 yet?

It makes sense for PocketCHIP since they're not updated yet, but it's not like it's intentional, zep's stated that NTC's working on some other stuff atm iirc. Eventually they should be both brought back up to the same version.

::

It might help some people if code is ever listed in a format outside of .p8 or .p8.png, like text for instance.

I know the PET computer had to do this a few times for some complex commands when they posted their code in a magazine. In their case, they PEEKED a binary number to determine the hardware specs on how to handle the display.

::

I'm not sure what _console would be good for. If you want GPIO detection, it would be far better to have a gpio_enabled() API function to let you know that GPIO is available on this platform, and the user has run pico8 as root so the cart can read and write. I can't think of anything else you'd use it for (game difficulty?) that wouldn't be better done in game UI.

::

I suspect that adding a way to detect host platform / version number would do more harm than good. It means that cartridge authors become responsible for whatever problems that would solve, when they should really be solved by PICO-8 itself. The 60fps inconsistencies will be resolved before too long, GPIO address are already mapped to a standard 0x5f80..0x5f87 for both raspi and CHIP, and I think labelling buttons X and O is less confusing than some carts adaptively changing button name strings.

I realise the inconsistencies between 0.1.7 (CHIP) and 0.1.8 call for a short-term work-around, and @josefnpat & @gamax92's detection method should be good for that. But in general, I'm planning on the version syncing across platforms being much tighter. Are there other reasons for doing it?

::

@zep I'm just worried mostly about backwards and forwards compatibility.

Forward compatibility - I'm not sure how often the PocketCHIP debian jessie users will update - with so many new functions, and functions having the way they work change, I imagine that many carts in the future will not easily work on older versions of pico8.

Backward compatiblity - Already there are threads on the CHIP forums saying that quite a few of the older pico-8 carts do not work. While I don't mind updating my own stuff, I imagine that with a normal churn rate of a community, not everyone is going to update their own stuff.

At the end of the day, it's always fair to say, "it's not 1.0, eat dirt". At the end, it's a question of how many historical carts do we want to keep in the catalogue.

::

Personally, as for the GPIO, I think those should be accessible via an API, rather than being exclusive to PocketCHIP and RPi, and have an additional program/whatever included with the PocketCHIP and RPi version that integrate into the API. One example this could be used for is using PICO-8 as an interface for a simple music player script I have running elsewhere. When I open the music player, it would open PICO-8 with a special cart that uses the GPIO ports. When the cart loads, the script uses the API to send PICO-8 a list of the available songs, which PICO-8 presents to the user. After the user selects a song in PICO-8, it sends the selected song back through the GPIO, making the script start playing the song, and PICO-8 shows music controls.
(Another example, though, could be the Twitter client already made by another user (sorry, I forgot who you are D:) that uses a program rather than JavaScript on an exported HTML5 page)