Thank you! I've received my Developer Preview hardware so I'm gonna start playing with this all. 
. I downloaded the SDK and am reading through the docs now!
One question: is the simulator included in this release? I seem to have the pdc and pdutil binaries, but can't find the simulator.
The Linux simulator didn't land in the 0.10.2 SDK but here's the latest build from our CI server which does have it.
Please let me know how it goes. As I said earlier, it's had very little testing!
PlaydateSDK-0.10.2.zip (7.7 MB)
Thanks for including the simulator! A couple of notes for anyone else trying to use it on linux:
On first launch, the simulator couldn't find the PlaydateSDK. I had unzipped it to ~/playdate, so I edited ~/.Playdate\ Simulator/Playdate\ Simulator.ini as follows:
SDKDirectory=/home/dorthu/playdate/
SimulateDeviceAppearance=1
ShowConsole=1
(In this case /home/dorthu is ~ - the ini file requires an absolute path)
I also had to mkdir ~/playdate/Disk. With that done, the simulator runs great.
Additioanlly, I integrated it into my Makefile for easy testing:
PDC ?= ~/playdate/PlaydateSDK-0.10.2/bin/pdc
PLAYDATE_SIMULATOR ?= ~/playdate/PlaydateSDK-0.10.2/bin/PlaydateSimulator
PLAYDATE_SDK_PATH ?= ~/playdate/PlaydateSDK-0.10.2/
PDX_NAME ?= 'Big Head'
@PHONEY: build
build:
$(PDC) -sdkpath $(PLAYDATE_SDK_PATH) src/ $(PDX_NAME)
@PHONEY: simulate
simulate: build
$(PLAYDATE_SIMULATOR) $(PDX_NAME).pdx
In this case, my pdx is named "Big Head" - this can be changed to anything. I am assuming that all code and assets for the game live in a directory named src in the same folder as the Makefile.
With the above setup, I can run make simulate to build and run this in the simulator immediately. So far, no issues.
Thank you again for sharing this build, it's really nice to be developing on Linux 
Usage: pdutil <device> <action> [options]
device:
path to Playdate serial port, ie; /dev/ttyACM0
actions:
datadisk - Mount Playdate data partition
recoverydisk - Mount Playdate recovery partition
run <path> - Run .pdx from device's data partition
pdutil "install" command intentionally missing? Looks like I can upload stuff via datadisk and copying files around.
I've been installing games with something like this:
pdutil /dev/ttyACM0 datadisk
cp -r MyGame.pdx /media/$(whoami)/PLAYDATE/Games/
I haven't figured out how to correctly unmount the playdate through the console yet, which is why this is missing from my Makefile (the unmount button in Nautilus works though, I'm probably just missing something obvious).
I thought so too, but while umount /media/$(whoami)/PLAYDATE did unmount the filesystem, the playdate remained in datadisk mode - I assume there's another step I missed.
"install" is missing because I, as a fairly inexperienced Linux programmer, couldn't figure out how to determine the mount point for the disk (it's not /media on all distros). And I'm also not sure how to "eject" the disk, especially if umount doesn't do the trick. We'll keep looking into this, but if anyone happens to know, it might speed things up. 
You're correct, "pdutil install" is just a shortcut for datadisk, copying the file to the PLAYDATE volume, then ejecting the disk. So that is a workaround that can be used for now.
Yep, sudo eject /media/dorthu/PLAYDATE did it 
Sadly not really one standard to go by 
I might do a little more digging on what standard apps do, but I've done some hacks for now. It's standard for any app to use udev rules, at least. The mounting bits are less standard as linux doesn't really want non-root users to mount things by default.
/etc/udev/rules.d/80-playdate.rules
SUBSYSTEM=="tty", ATTRS{manufacturer}=="Panic Inc", ATTRS{product}=="Playdate" SYMLINK+="playdateACM%n", GROUP="dormando"
SUBSYSTEM=="block", SUBSYSTEMS=="scsi", ATTRS{model}=="Playdate ", SYMLINK+="playdate%n", GROUP="dormando"
May also need:
SUBSYSTEM=="tty", ATTRS{manufacturer}=="Panic Inc", ATTRS{product}=="Playdate", ENV{ID_MM_DEVICE_IGNORE}="1"
... as its own line or in the first line to avoid an issue opening the device when first plugged in.
Added to /etc/fstab:
/dev/playdate1 /mnt/playdate vfat noatime,noauto,group 0 0
... which creates some stable symlinks when the device is plugged in (for those of us who may have many ttyACM's...). The "group" option to the fstab line lets my user mount and unmount the device without sudo or root. eject also works.
A simple upload script would look like:
#!/bin/bash
pdutil /dev/playdateACM0 datadisk
sleep 2
mount /mnt/playdate
cp -R $1 /mnt/playdate/Games/
umount /mnt/playdate
eject /dev/playdate
... which you could then call from a makefile.
... I'll probably write a better script that waits for the devices to show up before doing things. There's also a bit of delay before you can re-run the mount routine (think I need another rule to disable the modemmanager). I also don't know if you're supposed to leave it mounted while testing or not 
easy enough to adjust the script if so.
Also depending on your distro it will automount somewhere via the label PLAYDATE once the datadisk command is sent. So the rest of this might not make sense.
[edit]: to expand a bit: all the various devices I have that are accessed under linux, either mount somewhere by default when plugged in (without being poked first, and then they stay mounted), or stream firmware over the /dev/ttyACM* device since distro's usually have a 'dialout' or similar group that it's easy to add your user to. Playdate seems to want to do both.
Just had a few minutes to poke today: compile/test/install lua games works okay. C does not out of the box.
on ubuntu: apt-get install gcc-arm-none-eabi is enough to run the compile for the on-device bin (almost) but the simulator one is calling clang with dylib stuff still, and isn't passing -lm to my main.c.
the cmake on my ubuntu 19.10 is apparently too old to rebuild the files and I haven't done any cmake in over a decade so I don't have time to go any further tonight. I'll try again tomorrow night but posting now in case anyone cares.
I also couldn't get the simulator's device dropdown to do anything, but didn't try very hard yet.
I haven't tried building C, but I can confirm the simulator's device dropdown doesn't do anything, and that I also didn't try very hard to figure it out.
The Linux build of the Playdate Simulator currently does not support:
We probably should have mentioned that earlier ... 
well then I could get compilation to work at least, but I guess there's no point for now. thanks for stopping me, heh.
my "mac" is a VM so getting it to talk directly to the playdate requires some work. Most of my projects have or are C as well. let us know if we can help with anything
Heyo, I've mostly got everything set up, with the help of those posts by dormando and dorthu, thanks to both of you.
Just wanted to report that the simulator screen doesn't show anything for me, it's just a blank screen. It runs the games just fine as I can see their console output when I run them. It's just strange since there is no error message or similar as far as I can tell in the console. I'm currently on Manjaro with Gnome.
However I can work around that for now by testing my games directly on the device. It's not as quick as with the simulator, but this will do for now.
Hi @toni, thanks for the report. I fired up a virtual machine of a basic Manjaro+Gnome x64 install in VMWare and I wasn't able to reproduce any display problems.
~/.Playdate Simulator after reproducing the issue?Yes, now that you mention it, I switched x11 with Wayland a long time ago because of some display issues I had with x11 (I think it was related to screen-tearing). And to nobody's surprise, after switching back to x11 everything works just fine.
Using Wayland, the screen is always blank, not even the clock screen renders, and I can see the interface just fine. Only the "virtual" screen is blank.
I doubt the log is any useful, since the log is exactly the same whether I use Wayland or X11, but just for completeness sake here it is: Playdate Simulator_issue.zip (540 Bytes)
For me personally, not supporting Wayland is fine too
That's great you found a workaround.
Interesting that the issue with Wayland is restricted to the virtual screen, as there shouldn't be anything substantially different about how it is rendered compared with the rest of the interface. Something to look into, thanks!