Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #6329 > unrolled thread

Integrated development on emulators: The next step

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Integrated development on emulators: The next step D Finnigan <dog_cow@macgui.com> - 2025-10-07 14:47 +0000
    Re: Integrated development on emulators: The next step Steve Nickolas <usotsuki@buric.co> - 2025-10-08 08:09 -0400
      Re: Integrated development on emulators: The next step mummycullen@gmail-dot-com.no-spam.invalid (MummyChunk) - 2025-10-08 13:31 -0400
        Re: Integrated development on emulators: The next step Steve Nickolas <usotsuki@buric.co> - 2025-10-08 20:36 -0400
        Re: Integrated development on emulators: The next step Speccie <someone@somewhere.com> - 2025-10-09 08:07 +0100
          Re: Integrated development on emulators: The next step Hugh Hood <hughhood@earthlink.net> - 2025-10-09 10:44 -0500
            Re: Integrated development on emulators: The next step Speccie <someone@somewhere.com> - 2025-10-10 08:01 +0100
        Re: Integrated development on emulators: The next step D Finnigan <dog_cow@macgui.com> - 2025-10-14 19:14 +0000
      Re: Integrated development on emulators: The next step kegs@provalid.com (Kent Dickey) - 2025-10-08 19:38 +0000
        Re: Integrated development on emulators: The next step D Finnigan <dog_cow@macgui.com> - 2025-10-14 19:18 +0000
        Re: Integrated development on emulators: The next step Hugh Hood <hughhood@earthlink.net> - 2025-10-15 23:28 -0500
          Re: Integrated development on emulators: The next step kegs@provalid.com (Kent Dickey) - 2025-10-20 19:05 +0000
        Re: Integrated development on emulators: The next step Noncho Savov <user10020@newsgrouper.org.invalid> - 2025-10-26 20:49 +0000

#6329 — Integrated development on emulators: The next step

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/

[toc] | [next] | [standalone]

#6330

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.

[toc] | [prev] | [next] | [standalone]

#6331

> 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

[toc] | [prev] | [next] | [standalone]

#6333

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.

[toc] | [prev] | [next] | [standalone]

#6334

> 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

[toc] | [prev] | [next] | [standalone]

#6335

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
> 

[toc] | [prev] | [next] | [standalone]

#6336

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

[toc] | [prev] | [next] | [standalone]

#6337

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/

[toc] | [prev] | [next] | [standalone]

#6332

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

[toc] | [prev] | [next] | [standalone]

#6338

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/

[toc] | [prev] | [next] | [standalone]

#6339

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

[toc] | [prev] | [next] | [standalone]

#6340

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

[toc] | [prev] | [next] | [standalone]

#6341

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web