Apple2 development toolchain

[mark.l...@gmail.com]

As I look around the corner past the Nox Archaist: Lord of Storms expansion, at the never ending quest for more memory, it occurs to me that I haven't really revisited the Nox toolchain since putting it together in 2015, and I've been so focused on coding I haven't really kept up on new developments in the community in this area.

In a nutshell the Nox build process calls a cross-assembler to generate binary files, uses Cadius to load the binary files onto ProDOS ordered disk image(s), then copies the disk images to the AppleWin folder. I use Ciderpress if I need to look at files inside a disk image or manually add/remove files for diagnostic purposes.

As a general question, I am wondering if there are new (relative to 2015) tools anyone is aware of that may be worth considering?

A more specific question - I work on both Windows and Mac, but the Nox build process currently runs on Windows. Are there tools on the Mac side now to setup an automated build process? For some reason that didn't seem possible in 2015 (without custom development) though I don't recall why.


Thanks much for any thought anyone may have!

-Mark

[D Finnigan]

mark.l...@gmail.com wrote:
>
> A more specific question - I work on both Windows and Mac, but the Nox
> build process currently runs on Windows. Are there tools on the Mac side
> now to setup an automated build process? For some reason that didn't seem
> possible in 2015 (without custom development) though I don't recall why.
>

On Mac OS X there is a command line utility that can add files to disk
images. I don't remember the name, which makes my response to you less
helpful than it could have been, but no doubt someone else will know it.

[David Schmidt]

On 4/5/23 9:21 PM, mark.l...@gmail.com wrote:
> A more specific question - I work on both Windows and Mac, but the Nox build process currently runs on Windows. Are there tools on the Mac side now to setup an automated build process? For some reason that didn't seem possible in 2015 (without custom development) though I don't recall why.

There's nothing that beats CiderPress on Windows. That's just the way
it is. It's the gold standard. That said...

What I do on Mac is us the command line of AppleCommander
(https://applecommander.github.io/ac/), which is Java - harking back to
my days long before 2015 and the environments I was comfortable in. It
can provide some of what CiderPress does in this context, namely:
extracting and adding files to disk images via command line. I wrap
that all in ant build scripts, but that's less important and more legacy.

[Michael 'AppleWin Debugger Dev']

On Wednesday, April 5, 2023 at 6:21:42 PM UTC-7, mark wrote:

Mark, one thing not mentioned is that the build process is a bunch of Windows batch files (which is why the build process currently only runs on Windows.)

I'm a fan of ye-olde Makefile.

Michael

[D Finnigan]

David Schmidt wrote:
>
> What I do on Mac is us the command line of AppleCommander
> (https://applecommander.github.io/ac/), which is Java

This is the tool that I was referring to.

[fadden]

Out of idle curiosity, is there anything more that you'd want from a command-line tool?

[David Schmidt]

On 4/6/23 11:10 AM, fadden wrote:
> Out of idle curiosity, is there anything more that you'd want from a command-line tool?

Written in a portable language that was unencumbered with runtime
constraints (not looking at you, Python/Perl/Java/anything interpreted)
- so my suggestions are C/C++/Go

[Richard]

[Please do not mail me a copy of your followup]

"mark.l...@gmail.com" <mark.l...@gmail.com> spake the secret code
<6e990edc-0ecc-41e6...@googlegroups.com> thusly:

>As a general question, I am wondering if there are new (relative to
>2015) tools anyone is aware of that may be worth considering?

I don't think they have the runtime environment setup for Apple ][
yet, but this project is serious and being worked on:

<https://llvm-mos.org/wiki/Welcome>

Jason Turner did a video on it recently:
<https://www.youtube.com/watch?v=R30EQGjxoAc>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Joshua Bell]

For A2D, builds are done on macOS (locally) or Linux (github actions); no-one has pursued Windows successfully yet.

* cc65's ca65 cross-assembler
* Makefiles
* Cadius
* nulib2 for SHK files (optional)
... and lots and lots of bash scripts.

"make" produces the binaries. "make <flavor>" handles producing disk image packages (ZIPs of disk images, via Cadius), SHK files, populating a directory with metadata that can be mounted by the Virtual ][ emulator, or (my usual) install onto an existing disk image (via Cadius) - in my case, my preferred emulator's default boot image. I usually just run:

make && make install && open $EMU_PATH

... and a few seconds later the emulator is running the app. I'm able to install into a 2MG image that's already mounted in the emulator, so don't even need to reboot for even faster iteration, if the target (e.g. a desk accessory) is hot-loaded by the app. The same image files are my default for Ample/MAME so if I want to test another emulated machine it's almost as fast.

On Wednesday, April 5, 2023 at 6:21:42 PM UTC-7, mark.l...@gmail.com wrote:
> A more specific question - I work on both Windows and Mac, but the Nox build process currently runs on Windows. Are there tools on the Mac side now to setup an automated build process? For some reason that didn't seem possible in 2015 (without custom development) though I don't recall why.

What do you consider missing from *your* automated build process? i.e. what were your pain points when working on Nox?

Potential improvements in *my* workflow would be:

* Continuous builds in the background while editing. Sometimes I open a background window and do builds in a loop.
* Parallel assembly, taking advantage of multiple cores. Not really a bottleneck, but couldn't hurt if output was clean.
* Better integration of my editor (Emacs) with build results - I'm boring and usually build in another window or shell out, rather than "living" in Emacs, so jumping to an error line is a bit tedious.
* Automatic dependency tracking, e.g. building makefiles from "include" references. Makefiles are a pain to make extremely accurate, so I usually just have wildcards for e.g. ../inc/* which works but means unnecessary incremental builds sometimes.
* Automated regression testing - difficult for a GUI app.

[sc...@alfter.diespammersdie.us]

mark.l...@gmail.com <mark.l...@gmail.com> wrote:
> A more specific question - I work on both Windows and Mac, but the Nox
> build process currently runs on Windows. Are there tools on the Mac side
> now to setup an automated build process? For some reason that didn't seem
> possible in 2015 (without custom development) though I don't recall why.

I'd expect the Mac to have the same tools that'd be used on Linux to
automate builds: make and friends. Those same tools could also be set up on
newer versions of Windows by running them within WSL. (I'm typing this
message in through a Gentoo-on-WSL window on a Win11 box.)

An (old) example of a makefile-driven cc65 build is here:

https://gitlab.com/salfter/a2bfc

GitLab tells me it's 15 years old now, so there's a chance it might not
build under current versions of cc65 without some tweaks, but it worked back
then until I got the idea to swap in a Raspberry Pi to replace the Apple II.

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

[sc...@alfter.diespammersdie.us]

Richard <legaliz...@mail.xmission.com> wrote:
> I don't think they have the runtime environment setup for Apple ][
> yet, but this project is serious and being worked on:
>
> <https://llvm-mos.org/wiki/Welcome>

A screenshot at that link shows the code it produces running on an Apple II
(or an emulator).

The weird bit is that it appears to be disguised as a BASIC program so it
can be LOADed and RUN, rather than BLOADed and CALLed.

[Richard]

[Please do not mail me a copy of your followup]

sc...@alfter.diespammersdie.us spake the secret code
<P2CXL.428695$5CY7....@fx46.iad> thusly:

>Richard <legaliz...@mail.xmission.com> wrote:
>> I don't think they have the runtime environment setup for Apple ][
>> yet, but this project is serious and being worked on:
>>
>> <https://llvm-mos.org/wiki/Welcome>
>
>A screenshot at that link shows the code it produces running on an Apple II
>(or an emulator).

Yeah, I thought they had Apple ][ support but maybe the only thing that's
missing is the SDK support for things like printf and so-on:
<https://github.com/llvm-mos/llvm-mos-sdk#supported-platforms>

[fadden]

On Thursday, April 6, 2023 at 8:29:00 AM UTC-7, David Schmidt wrote:
> Written in a portable language that was unencumbered with runtime
> constraints (not looking at you, Python/Perl/Java/anything interpreted)
> - so my suggestions are C/C++/Go

Every language has a runtime. You won't get very far in C/C++ without libc. CiderPress comes with a few MB of libraries for the runtime and MFC GUI.

Some development environments allow you to package the runtime with the application. For example, .NET applications can be prepared with "publish --self-contained" to include the necessary bits and pieces. It adds 70MB to the installation (35MB when compressed in ZIP) for a command-line program, but avoids installing the runtime as a separate step. This wouldn't matter for Windows users, since it should already be there, but might be handy for Mac/Linux/RaspberryPI/whatever.

Is your concern for the installation process, or a philosophical dislike of bytecode?

[fadden]

On Thursday, April 6, 2023 at 9:02:57 AM UTC-7, sc...@alfter.diespammersdie.us wrote:
> The weird bit is that it appears to be disguised as a BASIC program so it
> can be LOADed and RUN, rather than BLOADed and CALLed.

That's the standard approach for C64, e.g. this is common:

.addrs $0801
.dd2 $080b ;ptr to next line
.dd2 $0014
.dd1 $9e ;SYS 2061 ($080d)
.str “2061”
.dd1 $00
.dd2 $0000

L080D ldy #$1e

In this case it's a HELLO program that starts when DOS boots, which IIRC wouldn't work with a 'B' file unless you fiddled with something.

[Kent Dickey]

In article <b7a45370-b1dc-4ac5...@googlegroups.com>,

But...that's because the C64 can only really LOAD Basic programs from the
floppy drive. So of course they have to do it like this. It is not unheard
of to sneak machine code into an Applesoft BASIC program on the Apple II, but
it is unusual (since it's not necessary, generally). On an Apple II, it's
definitely annoying to have to deal with machine code hidden in a BASIC
program.

Kent

[Mark Lemmert]

On Thursday, April 6, 2023 at 10:10:08 AM UTC-5, fadden wrote:
> Out of idle curiosity, is there anything more that you'd want from a command-line tool?

I don't have a specific wishlist. Over the years I feel like I've heard of new tools being developed and even a complete Apple II development environment of some sort, but I could be misremembering. I just want to make sure I consider all the option before diving into another big project because if I'm going to make a change, now is the time. I get very stubborn about not changing things once I've got a lot of code built on top of it.

[Mark Lemmert]

Thanks for your reply!

On Thursday, April 6, 2023 at 10:44:48 AM UTC-5, Joshua Bell wrote:
> For A2D, builds are done on macOS (locally) or Linux (github actions); no-one has pursued Windows successfully yet.
>
> * cc65's ca65 cross-assembler
> * Makefiles
> * Cadius
> * nulib2 for SHK files (optional)
> ... and lots and lots of bash scripts.

Maybe I'm misunderstanding, but are you running Cadius on a Mac? I thought it was Windows only and if it runs on Mac now that would be great to know.

> What do you consider missing from *your* automated build process? i.e. what were your pain points when working on Nox?

The biggest thing is it's not cross-platform (windows only) which I'd like to change to ease collaboration.

[Mark Lemmert]

Many thanks to everyone for your replies!

[Joshua Bell]

On Thursday, April 6, 2023 at 6:29:23 PM UTC-7, Mark Lemmert wrote:
> Maybe I'm misunderstanding, but are you running Cadius on a Mac? I thought it was Windows only and if it runs on Mac now that would be great to know.

Yes, builds/runs fine on macOS and Linux. Here are the relevant instructions from my project:

https://github.com/a2stuff/a2d/blob/main/docs/Building_And_Running.md#option-1-create-a-disk-image

[Mark Lemmert]

Thanks much!

[Antoine Vignau]

Link to the macOS version of Cadius at the bottom of http://www.brutaldeluxe.fr/products/crossdevtools/cadius/

[mmphosis]

dskbsave is written in C. The op in the thread settled on a2tools

https://www.applefritter.com/comment/102380#comment-102380

I did a build of dskbsave using cosmopolitan as a test. There is no runtime
as the cosmopolitan libc is included statically. Apparently, it runs on
Windows, Mac, Linux, BSD... I've only tried it on Linux and Wine. It won't
run on dosbox or 32-bit Windows. cosmopolitan creates ~/.ape executable.
This build has the trace options and the binary would have been much smaller
if I'd used the tiny option.

https://justine.lol/cosmopolitan/

I built both Merlin32 and Cadius for PowerPC Mac a long time ago. Thank you
Brutal Deluxe Software

[Steve Nickolas]

That's another reason it would be nice to have something that isn't GUI or
Java to work on Apple ][ disk images.

I used to have a "get33", and still have "dir33" and "format33", but I
never managed to make "put33", "del33" or "ren33", or any ProDOS-8 tools.
:/

-uso.

[Michael 'AppleWin Debugger Dev']

On Saturday, April 8, 2023 at 2:26:49 AM UTC-7, Steve Nickolas wrote:
> That's another reason it would be nice to have something that isn't GUI or
> Java to work on Apple ][ disk images.

Agreed. GUIs are great and all but command-line utilities are awesome for scripting. And I despise needing yet-another-bloated runtime like Python, Java, etc.

> I used to have a "get33", and still have "dir33" and "format33", but I
> never managed to make "put33", "del33" or "ren33", or any ProDOS-8 tools.
> :/

You may be interested in my prodosfs utility which was inspired by those.
https://github.com/Michaelangel007/apple2_prodos_utils

Sub-directory manipulation is still a WIP but the basics, add, get, cat, dir, are there.

I also want to have a high performance multi-threaded "add" which was the main motivation for why there is yet-another-prodos-volume manipulation utility. =P

Cheers,
Michael

[David Schmidt]

On 4/6/23 4:17 PM, fadden wrote:
> Every language has a runtime.

[...]

> Is your concern for the installation process, or a philosophical dislike of bytecode?

If I write DiskStuff.py, you need a Python interpreter. If I write
DiskStuff.jar, you need a Java runtime.

If I write DiskStuff.exe and DiskStuff.app, you just need an OS.

[fadden]

On Saturday, April 8, 2023 at 9:07:45 AM UTC-7, David Schmidt wrote:
> On 4/6/23 4:17 PM, fadden wrote:
> > Every language has a runtime.

> If I write DiskStuff.py, you need a Python interpreter. If I write
> DiskStuff.jar, you need a Java runtime.
>
> If I write DiskStuff.exe and DiskStuff.app, you just need an OS.

There are two separate things: compilation to native form, and runtime support.

Compilation to native form can happen ahead of time or "just in time". Java/C# might use an interpreter for something that bloats up when compiled (like large static array initialization), but they generally compile everything to native code before its executed. (It might even be using LLVM, though Java wasn't particularly well suited IIRC.)

C/C++ need libcrt (compiled in), libc.so, and probably some other support libraries; run "ldd" on a Linux executable. There are very few fully "stand-alone" executables anymore. "/sbin/init" on my Ubuntu system is linked against 36 shared libraries. /lib/x86_64-linux-gnu has 24MB of binaries in it. If Java or .NET ships as part of the operating system, then I would argue that a Java or .NET app is equally unencumbered on that platform.

If a program can be distributed in a fully-encapsulated form, then the only drawback vs. a gcc-compiled binary is potentially the distribution size. With modern storage that's more of a philosophical issue than a practical one.

Windows does an amazing job with software; you can still run creaky old versions of CiderPress. Apple discards all software every few years: 68K, then PPC, then x86, then x64, then ARM. They interpret the old stuff for a few years then drop it. Linux effectively invalidates old executables when libc has a major change, and you can't count on building an executable for one distribution and running it on another. Apps compiled to bytecode are easier to distribute and to carry forward because each individual app doesn't need to be recompiled (...unless you have system-specific start code).

(FWIW, Linux *hardware* compatibility is outstanding... you can still use old SCSI cards with the default distribution. Windows breaks the world when they update their driver model.)

[David Schmidt]

On 4/8/23 12:40 PM, fadden wrote:
> On Saturday, April 8, 2023 at 9:07:45 AM UTC-7, David Schmidt wrote:
>> On 4/6/23 4:17 PM, fadden wrote:
>>> Every language has a runtime.
>> If I write DiskStuff.py, you need a Python interpreter. If I write
>> DiskStuff.jar, you need a Java runtime.
>>
>> If I write DiskStuff.exe and DiskStuff.app, you just need an OS.
>
> There are two separate things: compilation to native form, and runtime support.

Yep, well aware. But the end result for Joe or Jane user is much
simpler: do they need to install and run one thing, or do they need to
install run two things? My experience is that they're much happier when
it's just one. The onus is now on me to maintain backwards and forwards
compatibility, and not on them.

[Mark Lemmert]

On Friday, April 7, 2023 at 2:25:20 PM UTC-5, Antoine Vignau wrote:
> Link to the macOS version of Cadius at the bottom of http://www.brutaldeluxe.fr/products/crossdevtools/cadius/

Thank you Antoine!

-Mark

[Mark Lemmert]

On Saturday, April 8, 2023 at 11:40:43 AM UTC-5, fadden wrote:
>Windows does an amazing job with software; you can still run creaky old versions of CiderPress. Apple discards all software >every few years: 68K, then PPC, then x86, then x64, then ARM. They interpret the old stuff for a few years then drop it.

I love this about Windows and hate that about Apple.

[Oliver Schmidt]

Hi,

>On Saturday, April 8, 2023 at 11:40:43=E2=80=AFAM UTC-5, fadden wrote:
>>Windows does an amazing job with software; you can still run creaky old ve=
>rsions of CiderPress. Apple discards all software >every few years: 68K, th=
>en PPC, then x86, then x64, then ARM. They interpret the old stuff for a fe=
>w years then drop it.=20

>
>I love this about Windows and hate that about Apple.

Full ACK! I'm writing this on my Forte Free Agent from 1999 which runs
almost flawlessly on my recent Windows :-)

Regards,
Oliver

[Lucas Scharenbroich]

On Thursday, April 6, 2023 at 10:44:48 AM UTC-5, Joshua Bell wrote:

> For A2D, builds are done on macOS (locally) or Linux (github actions); no-one has pursued Windows successfully yet.
>
> * cc65's ca65 cross-assembler
> * Makefiles
> * Cadius
> * nulib2 for SHK files (optional)
> ... and lots and lots of bash scripts.

I think the best value of looking at the A2D sources is all of the macro support you have in place there for safely handling SELF_MODIFIED_BYTE optimizations, MAIN/AUX mem splits, tail call optimizations, etc. Having a decent safety net for implementing all of those little memory-saving techniques really seems to have a compounded effect on improving that codebase.

Maybe that's something that could be useful to adapt to a large codebase like Nox in addition to the suggestions for the build tools themselves.

-Lucas

[Michael 'AppleWin Debugger Dev']

Microsoft looks towards the past, Apple towards the future. Neither is better, just different. There are pros and cons for each philosophy. One is built upon hack-after-hack, the other abandoned although in Apple's case at least they provide notice and support deprecated features for a little bit before completely yanking the rug.

Apple is one of the few companies that have had their ecosystem (OS & Apps) migrate through 4 hardware changes as mentioned above because they are about making _their_ life easier, consumer be damned. Yeah, it is frustrating knowing the hardware is perfectly good, albeit slow, and no longer supported.

Microsoft was about making the consumer's life easier (when they aren't CONSTANTLY fucking up the UI). "Lately" they have switched to more of an Apple approach with their shenanigans of dropping support for newer CPUs (Ryzen) on Windows 7 because they are about shoving Windows 10 and 11 down consumer's throats. As bad as Windows is, a bad defacto standard is still better then no standard at all. /me Throwing light shade at Linux. :-)

Microsoft is also still struggling to treat ARM as a first class citizen. Ironically Windows NT also used to initially support MIPS and Dec Alpha. Part of the difference is due to Apple being a hardware company and MS was traditionally a software company (excluding the odd example of MS selling a 16 KB Language Card for the Apple 2 until they got serious about Mice, Keyboards, and Consoles.) MS bet big on "investing" in the Developer Ecosystem and it paid off, although Apple is having the last laugh their popularity of mobile and tablets.

I've been using Windows, MacOS, and Linux for decades. Operating Systems, like Editors, ALL suck. The trick is to find the one(s) that annoy you the least so you can get your work done. =P

Michael

[I am Rob]

...

> I've been using Windows, MacOS, and Linux for decades. Operating Systems, like Editors, ALL suck. The trick is to find the one(s) that annoy you the least so you can get your work done. =P

Boy, did you hit the nail on the head. I think Apple and MS are secretly working together to write some software that really sucks and the other guy writes that same software to be really good. How is it that neither company has the same software where they are both really good or both really bad?

One of the reasons I love programming on the IIGS, or more importantly in emulators, is to try to make software that can do the same thing, but way more efficient and not as bloated, as both company's counterpart software.

[Mark Lemmert]

On Sunday, April 9, 2023 at 1:44:38 PM UTC-5, Michael 'AppleWin Debugger Dev' wrote:

> I've been using Windows, MacOS, and Linux for decades. Operating Systems, like Editors, ALL suck. The trick is to find the >one(s) that annoy you the least so you can get your work done. =P
>
> Michael

I think this really sums up my feelings on it as well!

-Mark