@zep:

Any chance we could get additional host interaction when we're in devkit mode? I like the idea of having a devkit mode, honestly, although right now it only enables the mouse.

With real devkits, you always have a lot more options for debugging and so on than you do with a retail console, so it's almost like it's less immersion-breaking to have it work the same way. :)

What got me thinking was a desire for clipboard support from Lua. It would be nice if we could programmatically fill or read the real OS clipboard. That way we could generate code or string tables, for instance, without needing to write external tools. External tools are a whole can of worms, needing to read/write .p8 files properly, not being easily portable+shared with other devs, etc.

Simple clipboard support would provide a nice way to keep working inside the machine itself, AND in a portable, shareable way. We could probably get by with very little, e.g. only textual clippings, and a very limited API:

    s=getclipboard() -- nil if nothing there
    setclipboard(s)  -- pass nil to clear it

Looks like SDL has easy access to it:

https://wiki.libsdl.org/SDL_HasClipboardText
https://wiki.libsdl.org/SDL_GetClipboardText
https://wiki.libsdl.org/SDL_SetClipboardText

Actually, I guess you already know that, since your own editors already access the clipboard.

Anyway...

Please? :)

im not sure about your use case for the clipboard. You know that you already can paste into Pico8?

I can paste into it. What I can't do is generate Lua code/strings inside PICO-8 with Lua.

Let's say I write my own custom animation editor, in PICO-8 Lua, that wants to save in the form of string data. I have no way right now of actually putting those strings in code, aside from printing them and laboriously typing them into the code editor. Whereas I could do this if I had an API like I mentioned:

function save_as_string()
  str = encode()
  setclipboard(str)
  print("Your data is now a string in the clipboard.")
  print("Load your program and paste it in.")
  stop()
end

function load_from_string()
  print("When your data string is in the clipboard,")
  print("press a button to load it.")
  while btn()==0 do end
  str=getclipboard()
  decode(str)
end

And yes, obviously an external tool would be able to do this, but my point is that I want to write tools inside of PICO-8. Many custom tools will encode their data as strings, but a tool inside PICO-8 has no way of actually exporting strings for use in source code.

One alternative would be to give us access to the Lua tokens in 0x8000..FFFF that are currently protected, maybe through lpeek() and lpoke(), but that just sounds like a nightmare in the making. Clipboard is so much simpler.

I like the idea of using small features to make a standalone Pico machine more useful for dev. Clipboard funcs might be neat, though it'd outstretch actual old platforms that didn't have clipboards.

Another solution to the same problem is to have some kind of API or memory access to the source code region. Maybe the ability to manipulate the code region as a large string, with some find and insert functions.

(Beside your point, but another plug for picotool which is intended to solve the cart manip problem in Python for tool building: https://github.com/dansanderson/picotool/ Reads .p8 an .p8.png, writes .p8, contains a full Lua parser and semantic APIs for all data regions. I feel bad promoting projects but I feel like we still have a findability problem with the current community tools.)

[Posted simultaneously with your most recent comment. :) ]

You may try to use function printh(), wich output strings in the console (if you launch it from command line). It's not perfect but it can be useful.
I also often use another cartridge with a program that poke strings to the memory and do a cstore(). I can then open the cart in a text editor and copy the memory to the final cart. It doesnt work for code obviously. It would be very nice to write autogenerative programs, if we had access to the code section from pico8.

Actually, on second thought, accessing the lua tokens wouldn't necessarily be a nightmare, and it would even be in line with oldschool computers where you could rewrite your asm or BASIC with peek and poke.

Some of the coolest C64 demoscene stuff uses self-modifying code...

I have a feeling that copy/paste might be a more realistic request though.

Yep, nice one -- access to the clipboard should be possible for 0.1.9. It probably wouldn't be part of the api, but rather a stat() to grab the clipboard as a single string, and an extra parameter to printh to write or append to the clipboard (or a file).

There's other clipboard stuff coming in 0.1.9 by the way: the ability to copy and paste sprites to and from bbs posts via text, which could also be 'abused' for tools, and also using "_clip" in place of filenames to load and save cartridges directly from the clipboard.

Trivia: Earlier on, PICO-8 transitioned from storing code as raw text (along with memory mapping!) to compressed text counted as tokens, because the former was pushing authors into minifying code -- both because there wasn't enough space in the first place, but also because it's a natural thing to do when you run out -- start deleting comments and shrinking variable names. With a compressed code section, mapping ascii data didn't make as much sense (and I never really wanted to expose the ascii mapping :p ), and things get pretty funky near the compressed size limit as the lz pattern matching can cause the compressed size to jump around unpredictably. I figured that when people want to really squeeze in as much data as possible, they can stuff base-64 encoded stuff into the source, which allow clipboard access would greatly simplify.

For future reference, you can use the following string for base-64 encoding. The compression favours the first 58 characters here and stores them as a single byte each when they aren't stored as part of a larger repeating sequence.

s=" 0123456789abcdefghijklmnopqrstuvwxyz!#%(){}[]<>+=/*:;.,~_-@$^|`"

Self-modifying code would be really nice, but it turned out to be a can of worms. It really needs a total vertical fantasy console (complete with machine code like DCPU-16) to work.

Woo, awesome! The extra stuff you mentioned sounds really great too. Pasting a sprite as text could be so useful at times, vs. having to screenshot, clip, save, upload, reference. Thanks, zep!

I have a question about one thing you said:

The compression favours the first 58 characters here and stores them as a single byte each when they aren't stored as part of a larger repeating sequence.

I just want to be certain I understood this correctly: regardless of base64 vs. any other encoding, we are always best off encoding primarily into those characters, especially in cases where the data is pre-compressed or at least of high entropy. Like, with the following two strings...

S1="`!`"
S2="'?'"

...the compressed source for the first assignment would be smaller than the second, as backtick and exclamation point are in the favored set, and regular tick and question mark are not?

Yes, document yourself on how pico8 cart are stored in the PNG file, chars are stored as token for most of them, but a few of them are store as two bytes (one to say "extented char" and the second which is the ascii value.)