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

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.

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.

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

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.

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

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

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

"mark.l...@gmail.com" <mark.lemmert@gmail.com> spake the secret code
<6e990edc-0ecc-41e6-b595-8a9d3ac1d0b5n@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>

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.

mark.l...@gmail.com <mark.lemmert@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?

Richard <legalize+jeeves@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.

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

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

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

>Richard <legalize+jeeves@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>
--
"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>

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?

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.

In article <b7a45370-b1dc-4ac5-8a24-f1e29c951641n@googlegroups.com>,
fadden <thefadden@gmail.com> wrote:
>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.

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

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.

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.

Many thanks to everyone for your replies!

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

On Thursday, April 6, 2023 at 8:50:06 PM UTC-5, Joshua Bell wrote:
> 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

Thanks much!

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

David Schmidt wrote:
> 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
>

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

On Thu, 6 Apr 2023, Michael 'AppleWin Debugger Dev' wrote:

> 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
>

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.

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

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.