Hacked gsplus is here: https://github.com/stacksmith/gsplus

This hack provides shared memory at $100000000 (edit... $70000000 lately) make configurable); memory is also file-backed to a file called 'RAM.bin' (todo: make name configurable). I should probably unmap it when I quit - I can't remember if Linux unmaps shared memory when the process quits... But enough to get started.

EDIT: I tested it both ways - file and memory, and it works.

It took me a while to figure out that nothing is wrong. My test routines simply poked a character at $5BC, the center of the screen. Everything looked good - files opened, memory mapped, character written stored and read back fine. But I didn't see it on the emulator screen!
I finally realized that the emulator is not real hardware! Just storing a byte into screen memory does not make it visible - the emulator has to redraw the screen - and it doesn't know to do so. So reading the screen memory showed my character, but it just was not visible. So keep it in mind - you can't use this to blast a picture or text to the screen. But you can move code (or data) into the emulator and run it.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I wrote a simple utility to transfer a binary generated by 64TASS assembler directly into the RAM of the 'mulator:

https://github.com/stacksmith/gsslam

64TASS files must be in 'nonlinear' format, of the large, 3-byte variety using the -X switch. They consist of segments, prefixed by a 3-byte length, 3-byte address. If the length is 0, no other data follows.

gsslam requires a modded gsplus (see https://github.com/stacksmith/gsplus), fixed to expose its RAM as a file and shared RAM.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

As an aside, I've never had a GS before. It is a nice machine, but unfortunately the software is seriously contaminated by the dreaded Macintosh. I can't figure out an easy way to allocate a chunk of memory and slam some code there. Apple really went apeshit with the APIs (is that APIshit?), making writing code about as much fun as filling out tax forms. I totally forgot the many, many volumes of the Macintosh toolbox, (in)SANE libraries, UI style manuals and other such crap I wasted my money and my youth on.

At least linux got it right - process isolation, a small (~100 calls) kernel API, and everything else is in libraries. I know that memory management is not quite there on the 65C816, but it would probably work a lot better as multiple 64K tasks' or 'machines' with the option of claiming larger data buffers, and the ability to swap them out once disks became cheap and fast. The GUI could start in one of those, allowing one to create tasks/open applications, which could be GUI or anything they want.

I hope with the GS it is still possible to get off the GUI train by using an older ProDos or something. Right now I switch into BASIC, PR#3 to switch to 80-columns, and CALL-151 into the monitor. My reboot takes a couple of seconds, but it is still annoying to do all that every time. I am still stumbling in the dark trying to figure out something that works...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut