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/


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

You've basically described the dream workflow for a lot of retro developers. Having the edit-assemble-test loop all happen in one environment without swapping files around is a huge time saver.

It's awesome that "uso" actually built that functionality in the past with the integrated assembler and dynamic ROM generation. That proves the concept is not just possible, but genuinely useful. The fact they're thinking about extending it now with other content like Gameware and FPBASIC is really promising. It sounds like the groundwork is already there for someone to pick up and run with.

The real power, like you said, is in bridging the old and new. Being able to use modern tools like Git for version control on your source files, then seamlessly compiling and injecting the code directly into the emulator's memory or a disk image, is the best of both worlds. It keeps the classic feel of the machine but removes all the friction of the original development process.

I hope "uso" or someone else inspired by this picks up the torch. This is exactly the kind of feature that could become a standard for the next generation of emulators.


This is a response to the post seen at: http://www.jlaforums.com/viewtopic.php?p=697217128#697217128

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 8 Oct 2025, MummyChunk wrote:

You've basically described the dream workflow for a lot of retro developers. Having the edit-assemble-test loop all happen in one environment without swapping files around is a huge time saver.

It's awesome that "uso" actually built that functionality in the past with the integrated assembler and dynamic ROM generation. That proves the concept is not just possible, but genuinely useful. The fact they're thinking about extending it now with other content like Gameware and FPBASIC is really promising. It sounds like the groundwork is already there for someone to pick
up and run with.

The assembler would have been the part I'd have had to rewrite - though I *have* written my own 65SC02 assembler, it was a much more limited
assembler than CA65.

The real power, like you said, is in bridging the old and new. Being able to use modern tools like Git for version control on your source files, then seamlessly compiling and injecting the code directly into the emulator's memory or a disk image, is the best of both worlds. It keeps the classic feel
of the machine but removes all the friction of the original development process.

I hope "uso" or someone else inspired by this picks up the torch. This is exactly the kind of feature that could become a standard for the next generation of emulators.

This is a response to the post seen at: http://www.jlaforums.com/viewtopic.php?p=697217128#697217128

I just wish I could create a debugger as nice as AppleWin's... Having to
use WINE to run AppleWin, or MAME to get an almost-as-good debugger, is
still a bit painful.

GUI apps have never really been my specialty.

-uso.

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

You've basically described the dream workflow for a lot of retro developers. Having the edit-assemble-test loop all happen in one environment without swapping files around is a huge time saver.

I have never found that to be a problem. I write the code files in BBEdit on the Mac that Sweet16 is running on, then have a Favourite entry in SAFE2 on the emulated IIgs pointing to tthe folder on the Mac where the source files are saved.

It then takes seconds to copy the file or files over, and start the assembly in ORCA/M.

I donƒ??t of course need to run BBEdit on the same Mac. As long as the computer I am writing the source files on can be reached by FTP, that sequence works just the same...

Cheers - Speccie


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Ewen,

It always brightens my day to read your posts. I trust you are well these days.

Thank you for continuing to contribute here.

I too write my code in BBEdit on the Mac. Of course, I write in Merlin32 and have a BBEdit language module for it (for coloring and the like), rather than write in ORCA/M as you do.

I find BBEdit more than sufficient for my needs, as I've set up a 'droplet' to take the source and produce the binary to transfer to the emulator.

I suppose we all have our own procedures.

Regards,





Hugh Hood


On 10/9/25 2:07 AM, Speccie wrote:

You've basically described the dream workflow for a lot of retro
developers. Having the edit-assemble-test loop all happen in one
environment without swapping files around is a huge time saver.

I have never found that to be a problem. I write the code files in
BBEdit on the Mac that Sweet16 is running on, then have a Favourite
entry in SAFE2 on the emulated IIgs pointing to tthe folder on the
Mac where the source files are saved.

It then takes seconds to copy the file or files over, and start the
assembly in ORCA/M.

I donƒ??t of course need to run BBEdit on the same Mac. As long as
the computer I am writing the source files on can be reached by FTP,
that sequence works just the same...

Cheers - Speccie

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hugh,

I am indeed still here, but am merely watching these days...

I find BBEdit more than sufficient for my needs, as I've set up a 'droplet' to take the source and produce the binary to transfer to the emulator.

I think if you are not using an emulator, then the speed of a real IIgs or ][, is too slow these days for assembling large projects quickly. Spectrum was initially done that way, and I remember having to assemble parts, rather than the entire program, as it was tedious to assemble the entire app in one go.

An emulator changes things of course, so it now takes me very little time at all to assemble Spectrum for instance.

I suppose we all have our own procedures.

That will mainly be dictated by the hardware available I suspect.

Cheers - Ewen



--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

MummyChunk wrote:

You've basically described the dream workflow for a lot of retro
developers. Having the edit-assemble-test loop all happen in one
environment without swapping files around is a huge time saver.

Imagine an assembler (or compiler) that is so closely-coupled to the
emulator that you can set a breakpoint in the source, set the emulator
running, and then when program execution stops, that point is marked. You
can then single step through the instructions, see register values, etc. all synchronized with the source.

But why stop there? Why not allow patching the running executable too? If
you see some instruction that should be a NOP, you could easily insert it there, and continue your debugging or tracing. Or if you realize the next instruction should be a DEY, not a DEX, you can quickly make that change,
and have it synchronized both in the source file and in the running object
code in the RAM of the emulated Apple II.

--
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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/


--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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

--- PyGate Linux v1.0
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <10cps9j$52ns$1@dont-email.me>,
Hugh Hood <hughhood@earthlink.net> wrote:

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

To be clear, KEGS maintains all ProDOS attributes. But it does it using Cadius-style or "ProDOS" style filenames. The file STARTUP of type BAS
on ProDOS is named START,tbas on your hostmachine. Or a UTILS file of type
BIN file that loads at $300 is named UTILS,tbin,a$300. Cadius
style extensions like UTILS#060300 are supported as inputs as well.
And some file extensions, like .SYSTEM imply the type and so don't need
to be given, so BASIC.SYSTEM is stored as BASIC.SYSTEM,a$0000 (since ,tssys
is implied).

What I think you were asking for was that on a Mac, to maintain the
type in a Mac-specific way (I believe Finder-info on the Mac can encode
some ProDOS types). And I said I didn't really see the value of this,
but I could be convinced.

Kent

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

kegs@provalid.com (Kent Dickey) posted:

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

I've set up a project template that lets you assemble Apple II programs
on a modern computer using Merlin32.
It automatically injects the resulting binaries into a disk image via AppleCommander, and then launches on the Will Scullin's web based emulator.
The emulator linked in the project is a fork, where I've made a few modifications to improve its graphical capabilities - handy for testing different video modes like Composite, RGB and video card displays.
There is also an option to launch AppleWin, since the web emulator doesn't quite handle the more timing sensitive stuff like Vapor Lock,
although the AppleWin integration doesn't yet support live-reload.
Link: https://github.com/foumart/AppleII.Project.template

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)