From Newsgroup: comp.emulators.apple2

Here's an idea for the Apple II emulator authors: why don't we have
emulators with an integrated assembler? The assembler would produce object
code copied directly in the RAM of the emulated machine. Or the object code would be copied to a ProDOS or DOS 3.3 disk image.

Furthermore, why not integrate a C compiler or some other high-level
language? Output options would be the same: the object could would be
written directly to the emulated RAM, ready for execution. Or it could be copied to a disk image.

I think that these features would speed up cross-development considerably.
It would be a lot easier to interchange source files with the host
environment, across the Internet, and in version control systems.
--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

On Tue, 7 Oct 2025, D Finnigan wrote:

Here's an idea for the Apple II emulator authors: why don't we have
emulators with an integrated assembler? The assembler would produce object code copied directly in the RAM of the emulated machine. Or the object code would be copied to a ProDOS or DOS 3.3 disk image.

Furthermore, why not integrate a C compiler or some other high-level language? Output options would be the same: the object could would be
written directly to the emulated RAM, ready for execution. Or it could be copied to a disk image.

I think that these features would speed up cross-development considerably.
It would be a lot easier to interchange source files with the host environment, across the Internet, and in version control systems.

One of my abandoned projects, which was written by me and Holger Picker, actually did have an integrated assembler and even used it to roll the
slot ROMs on the fly. I thought of rewriting the code so it wasn't just a binary blob, but never got around to it.

Now that I have other content, like Gameware, and most of FPBASIC is fair game, this could be extended even further.

-uso.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

In article <alpine.DEB.2.21.2510080804400.25129@sd-119843.dedibox.fr>,
Steve Nickolas <usotsuki@buric.co> wrote:

On Tue, 7 Oct 2025, D Finnigan wrote:

Here's an idea for the Apple II emulator authors: why don't we have
emulators with an integrated assembler? The assembler would produce object >> code copied directly in the RAM of the emulated machine. Or the object code >> would be copied to a ProDOS or DOS 3.3 disk image.

Furthermore, why not integrate a C compiler or some other high-level
language? Output options would be the same: the object could would be
written directly to the emulated RAM, ready for execution. Or it could be
copied to a disk image.

I think that these features would speed up cross-development considerably. >> It would be a lot easier to interchange source files with the host
environment, across the Internet, and in version control systems.

One of my abandoned projects, which was written by me and Holger Picker, >actually did have an integrated assembler and even used it to roll the
slot ROMs on the fly. I thought of rewriting the code so it wasn't just a >binary blob, but never got around to it.

Now that I have other content, like Gameware, and most of FPBASIC is fair >game, this could be extended even further.

-uso.

There are other ways to get into and out of emulators. You can use
Ethernet to mount an SMB volume, and dynamically change files from your
host computer. This is https://github.com/sheumann/smbfst, but is IIgs
only. I'm not sure what else is there, if you can take the time to set
up a Netatalk server, using Ethernet emulation can let you mount APFS
file servers (this seems to be tricky to setup, though).

Most emulators allow easy loading of external files into memory, and
this can be scripted. So you build on your host machine, then load
the binary into the emulator.

Tools like CiderPress2 https://github.com/fadden/CiderPress2 and
Cadius https://brutaldeluxe.fr/products/crossdevtools/cadius/index.html
allow easy creation of ProDOS volumes of files from your host system.

KEGS allows mounting a directory on your computer as a ProDOS volume, where
it is just a plain ProDOS volume to any emulated code. I called it
DynaPro. You need to restart emulation if you change a file, to make sure
it sees the change. As best as I can tell, no one uses it.

Kent

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

Kent Dickey wrote:

Most emulators allow easy loading of external files into memory, and
this can be scripted. So you build on your host machine, then load
the binary into the emulator.

That's true, and that would be a good starting point for some extensions to
aid development. But imagine a closely-coupled assembler where you could set
a breakpoint in the source file, and then start the emulated machine
running. As soon as execution reaches that breakpoint, there is a marker in
the source, and you can single step through the object code and see all register values, etc. No more tracing through the Monitor, instead you trace through your assembly source.
--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.emulators.apple2

On 10/8/2025 2:38 PM, Kent Dickey wrote:

KEGS allows mounting a directory on your computer as a ProDOS
volume, where it is just a plain ProDOS volume to any emulated
code. I called it DynaPro. You need to restart emulation if you
change a file, to make sure it sees the change. As best as I can
tell, no one uses it.

Kent,

I've got a DynaPro folder for KEGS on my MacOS install.

The main reason I use it infrequently (whether to put files into KEGS or get files out of KEGS) is due to the loss of ProDOS file type attributes (file type / aux type).

I think at one time we may have discussed your adding attribute preservation, and that it would require KEGS implementing xattrs or named streams (or MacOS metadata), and that you didn't see that demand for that particular feature justifying the time required to implement it, which I can certainly understand.





Hugh Hood
--- Synchronet 3.21a-Linux NewsLink 1.2