I've been playing with Apple 2GS 'mulators, (mostly GSplus 0.14) as I am away from my lair. Now that I have a stable setup, I am ready to bang out some assembly code. A few instructions assembled in the monitor is fun, but to get any real code in is more difficult.

I am spoiled by VirtualBox, which allows mapping of IO to Linux files or pipes, mapping drives to Linux files or volumes, drag and drop file transfer, etc. I definitely need to lower my expectations, but I see very few options:
* Just use Merlin16;
* Make disk images and mount them (kind of painful)
* Use the 'paste' feature to transfer code into the monitor (At high speed, 16-bytes-per-line pastes work fine )

Am I missing something? What is your workflow like? Thank you.

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

I've seen a workflow where an IDE is scripted up so it can run the assembler, write a disk image, and fire up an emulator session to test the result. That relies on a cross-assembler, I suppose. Without that, you'd want your IDE (or editor) to put your sources into a disk image and fire up the emulator. Perhaps you could arrange that disk to auto-start the (native) assembler on the sources?

You are so right. Broken workflow is a common problem.

I have written emulators. I have written cross assemblers and compilers. But I have not implemented the "missing link," an IDE to connect them together. I have little interest in developing tools to run natively within a vintage environment and having to deal with limited available memory.

Bypassing the hassle of virtual disks is why my first 6800 and 6809 FLEX emulators did not load FLEX but emulated the FLEX API and used the native DOS file system. Unfortunately, there were some major limitations with that approach...

I was not alone. 22NICE used the same approach for CP/M.

Because I write very little code - small ditties - I have often pasted my code, sometimes into an emulator and sometimes over serial into my Beeb. So, for modest projects, that might be fine.

If you have a favourite assembler which runs on retro machinery, but you want to assemble more quickly and conveniently, rigging up some sort of minimal headless emulator might be fruitful. I see a recent tool uses lib6502 to run BBC Basic for related purposes. The thing about emulators to run tools is that they don't need all the difficult handling of sound and video and disk controllers, and of course they can run at full speed. Perhaps search for 'workflow' on stardot:
https://stardot.org.uk/forums/search.ph ... s=workflow

(It's also fine to want to develop fully in the retro environment, of course.)

I have a IIgs emulator running on a RaspberryPi 4. I installed it using Ivan X's Rasplle 2 (A2CLOUD and A2SERVER)
http://ivanx.com/raspberrypi/
There's nothing I can think of that can beat a 65816 (emulated) with 16 megabytes of memory running upwards of 25 megahertz.
There is of course Merlin16; There's also Merlin32
https://brutaldeluxe.fr/products/crossdevtools/merlin/.
There's also the ORCA package
http://www.byteworks.us/Byte_Works/Morgue.html
Also GNO/ME: http://www.gno.org/

There's a lot of development tools for the 8 bit Apple.

If you're looking to transfer files to a homebrew project look at VSDRIVE
http://adtpro.sourceforge.net/vdrive.html
https://github.com/ADTPro/adtpro

or just use "print"

If you happen to like pascal there's Apple's USCD Pascal or Kyan Pascal.
If you like C there's Aztec C or Hyper C.

This is the archive to find just about anything: http://mirrors.apple2.org.za/

Cheers,
Andy

That's great!

Those are great resources, but not helpful to me. I am still trying to get a simple way to get files from my Unix host into a running apple 2gs emulator (restarting it with every change would drive me mad).

Is it really not possible to have a 'virtual serial port card', and just do IN#x and receive data from a Linux terminal, for instance? Or a virtual native drive?

I may just give up and run something on the gs. Merlin16 seems like a complete pain to use - I am not sure I want to use it. qforth or some other forth is promising,if I can figure out how to get .shk files over there. I almost did but lost the filetype and somehow need to make it executable...

Interesting: it is the modern code that is completely inadequate and presents most limitations.

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

Depending on the code, sometimes a named pipe can be what you want.
https://linux.die.net/man/1/mkfifo

One process can write data, another can read it: much like a serial connection.

BigEd: yes, pipes are great for this, except... the 'mulator writers did not use them. Shared files work. Shared memory works well too - I'd love to be able to slam code right into the RAM of the gs. But it seems that none of the 'mulators support that.

I thought there was some promise with something called FST (file system translation?) - GSplus v.014 has a place where you can point FST to a host path, but it seems to be a dead end.

The last time I used a real Apple ][, I simply hooked up the serial port, entered the monitor, IN#'ed it to act like a keyboard, and sent it monitor commands to fill memory etc. I wrote a simple interactive assembler (on the Linux host) which generated monitor-compatible output and force-fed the Apple code and commands to run or debug. All this was one-way, host-to-apple. I would have to reboot the Apple and #IN very often, of course.

At the time I thought it was a pain in the ass. Surely, working with a 'mulated system would be a breeze - after all, it's all right there, with everything completely accessible. Sheesh.

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

Got a qforth prompt. What a trip: it came as a .shk file; the trick is to get shrinkit onto the GS and run it there - unshrinking it in Linux loses the file type. However to get shrinkit to GS is not easy. I had to use a terrible Java program (for some reason called Apple Commander) to build a ProDos disk, drop shrinkit.sea onto it, then change its type to S16, and save the 'disk'. I could now execute the self-executable on the GS to unpack itself as a shrinkit app. Then, the same thing with qforth files, followed by unpacking with shrinkit. But at least I have a forth running on the GS, which makes me a little happier.

Short of hacking GSplus I still see no easy communication path to the host. It should be possible to use shared memory as I am sure the 'mulator allocates a separate chunk of 'mulated RAM. Perhaps I could even make it a file-backed chunk, which would be easier for debugging should the system crash, and maybe even allow sessions to persist to disk...


P.S. Looks like there is a simpler program called 'to_pro' which is not Java and can be run from a command line to assemble a ProDos disk image from a list of files. But it does not allow file type changes...

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

For interacting with Apple II disk images, there's also https://paleotronic.com/diskm8/. It seems to be written in Go, which should be a plus point for those of us who would rather avoid Java.

I concur that having the emulated memory exposed as a file-mapped shared memory segments sounds like a good idea, and an obvious thing to do; unfortunately, the people who actually write emulators do not seem to agree.

I noticed you're using GSPlus; I am using GSPort. It was included in A2CLOUD.

https://david-schmidt.github.io/gsport/

Cheers,
Andy

Finding a command line tool to deal with disk images is a good step forward!

> Short of hacking GSplus...

It will probably be possible, but might not be ideal, to connect to the emulator with the debugger gdb, find the address of the iigs memory image, and plonk in some hex bytes. If that can be done at all, it can very probably be scripted up.

In a recent conversation about workflow, someone mentioned that they have customised the emulator they use - in their case to help with debugging - so it is one of the possible paths forward. Hurrah for open source!

(Of course I do recognise that one doesn't want to need to do any of these things.)

GSplus hacked successfully. About 10 lines of code.

I found the allocation site, and substituted mmap where calloc was used. New allocator simply maps a file-backed block of 8.25MB for GS RAM. File 'RAM.bin' is created the first time through.

I like GSplus as it allows me to double the screen size; along with 25% scanlines it looks very authentic! I invoke it with:

Unfortunately, sw and sh parameters include the overscanned borders and it is not obvious how to exactly double the screen size. I found empirically that 1408 is a good width, and Y seems to affect it; 1000 seems to work with a little border...

Click to see full-size, and note the log entry below, showing the mapped memory!

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

Oh, well done!