I'm still working in Pico-8 code on my own project, hopefully I'll be able to post it pretty soon.

In the meantime, I was checking out MESEN which is a good emulator for the 8-bit Nintendo and wondered if there was a way to convert a Pico-8 program to 8-bit NES (Nintendo) or SNES (Super Nintendo) format ?

The advantages would be high. There are so many good NES and SNES emulators for every single cellphone, tablet, many portable gaming consoles, and computers out - it would greatly increase the traffic and desire for Pico-8, not just for those who want to play the games, but those people who want to program market their games for these unique formats making them available worldwide and for more than just Java/ Macintosh/ Windows/ HTML executable and runtime.

It would also add the ability of load/save state, rewind, hacks, cheat search, audio improvement (echo + surround), graphics (filters such as HQ4x, xBRZ, 2xSai, SuperEagle, and standard bilinear interpretation) as many of the more popular NES and SNES emulators include these abilities and functions.

I think it's a good question since a lot of Pico-8 games look like they could have run on retro hardware. Unfortunately the reality is that this would be very difficult to achieve.

While Pico-8 recreates the feeling of hardware restrictions, they are actually quite different from the ones found on a NES/SNES. I'm not an expert on NES/SNES, but here are some examples.

NES/SNES games have a limit for number of sprites on each horizontal line on the screen. Any more than that would cause that flickering effect you might have seen. There were also limitations on the number of colors each cell of a sprite could contain depending on graphics modes. They had separate background layers for things that didn't move as much except maybe scrolling. Pico-8 can use the SPR command to draw a lot more sprites per frame.

Pico-8 also runs a scripting language that is interpreted line by line. Converting this into equivalent assembly instructions also isn't trivial. Especially if the variables change type or increase in size. The cost of each operation in Pico-8 would almost definitely not have the same performance cost on an NES/SNES even if it was converted. You could build a script interpreter for the NES/SNES but I don't think it would be able to run fast enough without some additional hardware to help out.

I'm not saying it's impossible for someone with a lot of time and skill. But I feel like the Pico-8 game would have to be developed with the conversion in mind and would probably require custom work per game.

So, all of what kerneliron said is a problem. However, more fundamental, I think, is pico-8 being 32-bit and generally too modern with regards to math. I just looked up the the MOS 6502, which is not quite the same core that the NES used, but it was the core that Ricoh "second-sourced" when supplying cores for Nintendo (meaning they used the same design with permission). It had a basic ALU with 4-4 fixed point mode, a signed bit mode, and a carry flag. Beyond that though, it mainly had addition, subtraction, logical operators, and single bit-shifting. That's enough that you could do math on more than 8 bits successfully, and the manual explains how in detail, but that it'd be a tedious process to do any higher math. Most likely, division, trig, square roots, etc. would need lookup tables with a very low degree of accuracy and no interpolation at all to keep them running fast enough. Even multiplication would be expensive. This is then compounded by the issue that the maximum clock rate was 1.79 MHz. Pico-8 is 8 Mhz.

The SNES is a little better, in that it had a maximum clock rate of 3.58 MHz, but could be upped to around 10 Mhz with a chip extension. It was also 16-bit, which would mean much less operations to emulate 32-bit, especially in pico-8's case where the 2 words so often have different meanings. Hardware multiplication and division are good leaps too, and could probably be used for fast square root algorithms, like late 90's fps's used. Still, trig functions would likely still need lookup tables, as the simplest fast-trig algorithms I'm aware of still do a lot of division. The ability to multiply and divide would allow for properly interpolating though.

There's also another consideration: available memory. Pico-8 2 MB of RAM is enormous in the context of old consoles. Apparently, NES cartridges were capable of containing more than the NES itself used, which makes sense given that game cartridges are literally extra circuit boards being plugged into the system. However, that would come at some cost, and apparently the most any actual game used was 1 MB.

Really, what it all comes down to is that Pico-8 is a fantasy. It uses deliberate restrictions, whereas all the old actual consoles had restrictions based on hardware costs in specific contexts. In that regard, its restrictions are actually closer to what old PCs used rather than game consoles, in that it prioritizes math and memory over graphics and audio.

Well, let's expand the scope then, guys. We can count out Turbo GFX, Sega Genesis, Gameboy, Game Gear, and Gameboy Color as I think those also have hardware sprite limitations.

Yet this does leave Gameboy Advance, Gameboy DS, Sony PSP, N64, Macromedia Flash, Gamecube, and Sony PS1 on the table.

How about any of those ?

you have to fully remake pico8 games to make them work on any of these consoles.

Well now @merwok, I think there was something about the PSP that let you run LUA code:

https://en.wikibooks.org/wiki/PSP_Development/Lua

If you want a lua interpreter on any of these consoles, then that changes things to whether pico-8 itself can be ported. I suspect at least a limited version can be ported to GBA, because there's already a lua interpreter project that targets it (Blind jumP core engine on github, which lacks a lot in documentation but which I can verify is at least a functional way to get lua on GBA).

For PSP, that link basically says what would be obvious if you've tried looking through the conf file in the lua source. However, there's still the difficulty of converting it to Pico-8's dialect. For that, you'd need to correctly parse the extra shorthand and then also load the correct library, since Pico-8 doesn't use the standard library. Most pressingly, you'd have to change or overload things to use the correct numerical formats. I highly suspect that if you don't care too much about speed and accuracy, that can all be done with a very carefully made preprocessor that includes replacing operators with custom math functions. Regardless, it definitely can be done, and in a way that makes it look like the games run natively on PSP to users who don't know better.

Regarding the other consoles on the list, my own experiments trying to get 5.4 to run in dosbox showed me that 5.4 at least has hidden difficulties with 16-bit variable systems. I don't know about 5.3 though, which I think is what pico-8 is based on. I was looking at porting my own game engine, which is very different, so it might be easier than I realized. Anything 32-bit with at least 3 MB of memory and either an open platform or a dedicated homebrew community is almost certainly going to have a way to port pico-8 to it. It's also probably good if it can be programmed using C or C++ (lua source has a header to eliminate the difference), since that's what the lua source is in, but I don't know if that's strictly necessary. I'm pretty sure by the "4th generation" consoles were all giving that option anyway, since C had become so popular by then.

So, going down the list you gave:

• DS is basically a 32-bit GBA with higher specs. You're good. It could also run any GBA ports.

• PSP is well more than needed in every category. It's not quite a modern laptop, but it's getting there. It could also run any PS1 ports natively due to basically using the same core.

• N64 is 4 MB RAM but with a 64-bit core. I'm not sure if that would be a problem, but just having a 64-bit core at all would make math stuff harder. I doubt it's impossible though, as the rest of the specs are good.

• Flash? Really? Is HTML not good enough? Whatever. The actual programming language that uses is ActionScript, which would need a port for the lua interpreter first. Probably not hard since there's an open source compiler, but I think you'd need a really hardcore person to bother.

• Gamecube is N64 but much easier. They went back to 32-bit core for various practical reasons.

• PS1 is just barely under the specs of pico-8. 2 MB of RAM and 1 MB of VRAM, in a 16-bit core. Just like with GBA, though, I suspect it could be done with just some of the more intense games not working.

Flash is just convenient for me, @kimiyoribaka, as I have collected nearly 1,000 Flash games and videos in my time as native .SWF files and they run perfectly well in Macromedia's own Flash player before it was mysteriously declared unfit to continue.

I have definite ideas this is a conspiracy favoring STEAM yet that topic is saved for a later date. :)

As for the Gameboy Advance, that would be ideal as there are great GBA emulators the world over now. I did program in GBA years ago, getting as far as writing a fairly comprehensive NOTEPAD program, yet for Pico-8 to run would really require some serious work on the part of the coder.

DragonBASIC comes to mind.
https://github.com/uli/dragonbasic

Yet that language is nowhere near the simplicity and elegance that is Pico-8.

PICO-8 is something of a magic trick. You can use it to produce games that look, sound, and play like games on old platforms, and it's much easier to program for than those old platforms. The trick is how it achieves this: by using substantial amounts of computing power on a modern architecture. It leverages computing power to prioritize developer comfort.

Take spr() for example. Relative to PICO-8's artificially-slowed code execution environment, spr() acts like a feature of the underlying hardware, performing like a single machine code instruction. It's actually doing a ton of work that vintage video hardware could never do as fast or as flexibly, let alone CPU-driven graphics effects. We call them "sprites" abstractly, but spr() is much more powerful than any hardware sprites in vintage hardware. It's more like highly sophisticated direct memory access. It's only because PICO-8 is dipping into the modern host computer's power to do it that spr() feels like a simple hardware operation.

You're asking about implementing a full PICO-8 runtime, not porting specific games, so we can speak generally. A full PICO-8 runtime must support a 128x128x4 60 fps display, a full Lua interpreter, and all PICO-8 primitives at speeds comparable to a RaspPi Zero W (which I use as a baseline because that's the smallest platform where I've seen PICO-8 struggle a bit on complex games but otherwise work fine). PICO-8 games tend to cls(), redraw every graphic object, and recalculate screen effects on every frame. Games for vintage platforms don't do that, at least not as generally: they do what they can fit to the contours of the specific hardware.

Coding for vintage platforms requires exploiting much clunkier and less flexible graphics and memory primitives, often with clever and complex code, to achieve only a fraction of the result. Comparing PICO-8 to vintage platforms becomes apples and oranges very quickly, even though it looks like they're producing similar results. To host a PICO-8 runtime, it is nowhere near enough that a target platform supports a 16-color 128x128 display, has six buttons, and seems to be able to play similar kinds of games. It looks like it should be enough, but it isn't. That's the trick.

It is a bit of work granted, undoubtedly it was a lot of work to port a compiler for Pico-8 to both build a Windows EXE and Macintosh executable, yet it was done.

Granted APK compilation will seriously boost its usage across the internet and world, yet I still think PSP could do it.

PSP resolution is 480x272. This means the screen can be a neat 128x128 doubled yielding 256x256 pixel display in the center of the device with only 8-pixel bars top and bottom.

Audio could use whatever audio method is done with other PSP and PS1 games. As for the physical controller on the PSP, you have 4-action buttons. The first two could be 🅾️ and ❎ while the other two could be auto-fire for that.

Start could active normal Pico-8 start and the Select button on the PSP would bring up a menu specific to the PSP and its emulation of the current Pico-8 cart.

I admit these are some pretty far-fetched ideas, yet years ago having built a fully functional BBS in QBasic and a completely usable RPG Maker in GFA for Windows 3.1, I have come to believe nothing is truly impossible.

If there is a desire, someone will build it. That is the gist of this thread, pointing out something that may be remarkably easy for them to code but difficult for anyone else.

If you can build a compiler compile Pico-8 to Gameboy Advance .GBA file or Pocket Sony Playstation .ISO or Playstation One *ISO, we're looking for you !

psp and many more running pico8 is already done, see:
https://github.com/jtothebell/fake-08
(not official/not complete but certainly a starting point)

Superb work that, @freds72 ! Now we just need a direct export ability:

export game.iso

What you need for older platforms isn't really a compiler. It's a base rom/iso of a pico-8 engine port with a known marker for where the pod file should go. That way, exporting to those platforms is simply a matter of copying the base and rom-hacking it with a script. Otherwise the toolchain would simply be too big. For the part where someone makes the engine port to begin with, any c/c++ compiler that targets those platforms will do. The real challenge is making the pico-8 port to begin with, since it's not standard lua and SDL2 doesn't have an easy way to build for all platforms. I followed freds72's link and found a project for a pico-8 dialect interpreter, but it didn't work out due to the creator's incompetence. (I normally wouldn't say such a thing because of my own lack of confidence in my programming, but I can't conclude otherwise after seeing code that didn't appear to know that c and c++ are different languages with different standard library headers)

I've spent a good portion of my day fiddling out of curiosity. I've found that DevkitPro can just compile lua for GBA as is, as long as you link it to the libm.a library. From there it's just a matter of deciding how you want it to fail to live up to standard pico-8 (I'd recommend just sticking everything in thumb memory since it's bigger, using mode 5 for the fastest bitmap usage and just accepting the 1/4 as much memory and much slower graphics)

For PSP, I'm not sure .iso is even the format you'd want. The cave story PSP port is an EBOOT.pbp file and a data.csz file. Also maybe look at the link more closely before responding. The ports in that project all allow running p8 files through a pico-8 emulator ported to said platforms.

@freds72 psp and ps vita are two different things.

Hi @kimiyoribaka. The PSP has 2-executable file formats, *.ISO (compressed is *.CSO or *.CSZ ), and *.PBP .

The *.PBP if I remember correctly is just the conversion of a PS1 game to where it will run on the PSP. This emulation also cannot be done on a computer, only a real PSP so *.PBP to my knowledge cannot be run on a computer emulator or PPSSPP. Only *.ISO , *.CSO , and *.CSZ can run on a PSP emulator.

your best shot is Pemsa - an almost 100% pico8 emulator.
https://github.com/egordorichev/pemsa
Try to port to the platforms you want to play with?