Path: csiph.com!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: D Finnigan Newsgroups: comp.sys.apple2.programmer Subject: Re: Integrated development on emulators: The next step Date: Tue, 14 Oct 2025 19:14:39 -0000 (UTC) Organization: Mac GUI Lines: 24 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 14 Oct 2025 19:14:44 +0000 (UTC) Injection-Info: dont-email.me; posting-host="afcd13583c0682a10d6bba7dd27eb390"; logging-data="3334683"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/do8tKr7GeUbQQX29gsI2l" User-Agent: Mac GUI Usenet Cancel-Lock: sha1:fRwOwIbvY4Lpto2HumurLhNQVUw= In-Reply-To: Xref: csiph.com comp.sys.apple2.programmer: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/