I've been working on this project for a couple months and finally got it to a state where all of the API functions are mapped/stubbed out and it can run basic graphical programs. A large amount of functionality isn't present at all yet such as sprites and audio, but most of the underlying structure has been created.
It loads Playdate hardware compatible PDX directories, whether developed using the Lua API or the C API, and executes them as if on actual hardware. A virtual address space was created to mimic the physical device memory and facilitate interfacing with the runtime implementation using the help of a sketchy C++ template based translation layer that automatically converts between emulated Arm, native C++, and Lua data types.
A large amount of reverse engineering and testing was needed to replicate the exact behavior of the API functions, due to discrepancies, bugs, and missing details in the otherwise quite thorough documentation, but only a small percentage of the entire API surface has actually been tested, so a testing suite that covers every edge case is needed. There are countless tiny differences in behavior already, with regards to how Lua objects are represented and how native resources are managed, so plenty of room for subtle issues like the line drawing routine being different by a few pixels. In the parts of the API that haven't yet been implemented, the functions generally return null, typically causing an emulated seg-fault in C programs and a null reference error in Lua programs. Suffice to say, it's not ready for running actual games yet, but is a good amount of the way towards it.
The current main issues concern memory/resource ownership with the various APIs and how they behave over the Lua/C boundary, since dangling pointers are inevitable if the ownership isn't properly established. The large amount of audio and graphical effects to implement with few technical details is also a challenge to overcome.
