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.
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.
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.
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.
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
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.
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
On 10/20/2025 2:05 PM, Kent Dickey wrote:
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).-a And I said I didn't really see the value of this,
but I could be convinced.
{As a side note: I think Kelvin once mentioned being able to do
something similar on Windows using named streams, but AFAIK,
CiderPress(2) doesn't support that, so there's probably no point}.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 54 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:55:47 |
| Calls: | 743 |
| Files: | 1,218 |
| Messages: | 187,760 |