Command line a2tools for ProDOS?

[Michael 'AppleWin Debugger Dev']

Context: I have a src2dsk *nix shell script that:

* check if extension is .s -- if not, replace it
* assembles foo.s
* removes the extension, uppercases foo -> FOO
* check if a FOO.DSK exists, if not copy a bootable blank DSK to FOO.DSK
* use a2tools to put the binary FOO(.bin) onto FOO.DSK

For the last part I'm using Terry Kyriacopoulos's excellent A2Tools. A single C source files compiles to a2in, a2ls, a2out, a2rm -- command line utilities for adding, listing, extracting, removing files respectively onto a DOS3.3 formatted DSK image.

Problem:
Are therey any *nix command line tools that handlesProDOS volumes? (C please, no Java) Yes, I'm aware of Apple Commander, CiderPress, etc. and those all work but I'm looking for native command line utility that will fit into the exist toolchain.

Potential Solution:
I already have some A2 Disk Tools command line utilities -- make a blank DSK, copy .BIN onto DSK starting at T0S0, etc. so it would be relatively easy to write -- but thought I would first check if there is an existing option before I spend time writing + debugging.

Is there any interest in extending a2tools to accept a -prodos flag to handle ProDOS volumes?

The other reason I mention going this route is that I need to extend a2tools to support yet-another-apple2-file-system I'm working on so a modular utility where you can "plug in" in a file system DOS, ProDOS, etc. would be perfect long term.

TIA.

[John Brooks]

I use Cadius from Brutal Deluxe. It is a simple cmd-line tool written in C and can do pretty much any file manipulation job needed on ProDOS disk images.

-JB
@JBrooksBSI

[Jorge]

I've never used a2tools, but it would be great if I could compile a .c or assemble a .s on a web page and the page then "played" the binary to the Apple II as sound: you just type in the Aapple II "LOAD" or the command to read from the cassette I/O port from woz's system monitor (whatever that command was, I forgot ! addressl.address2R was it ? )

Because most Apple IIs have the cassette port... then just bsave or whatever.

--
Jorge.

[Hugh Hood]

On 7/12/2017 10:51 AM, Michael 'AppleWin Debugger Dev' wrote:

>
> Problem:
> Are therey any *nix command line tools that handlesProDOS volumes? (C please, no Java) Yes, I'm aware of Apple Commander, CiderPress, etc. and those all work but I'm looking for native command line utility that will fit into the exist toolchain.
>

As John mentioned, Cadius does a nice job.

If you're comfortable with Perl, Chris Madsen has a nice little set of
utilities:

<http://search.cpan.org/~cjm/AppleII-LibA2-0.201/>

Check out the 'AppleII::ProDos' Module to access files on Apple II
ProDOS disk images.

Madsen, FWIW, is the guy who wrote the very nifty 'VBinDiff' utility,
described as:

"Visual Binary Diff (VBinDiff) displays files in hex & ASCII and can
highlight the differences between 2 files."

He mentions its Apple II heritage:

"VBinDiff was inspired by the Compare Files function of the ProSel
utilities by Glen Bredon, for the Apple II."


I have used it to investigate patched versions of files and disk images
to see exactly what was changed. Ewen's 'ChewBagger' does this on the
IIGS, BTW.




Hugh Hood

[Oliver Schmidt]

Hi,

>> Context: I have a src2dsk *nix shell script [...]

> I use Cadius from Brutal Deluxe. It is a simple cmd-line tool written in
> C and can do pretty much any file manipulation job needed on ProDOS disk images.

I think for the context given by the OP it's pretty unfortunate that
Cadius' ADD FILE command requires a '_FileInformation.txt' to set the
ProDOS file type and auxtype to something different but zero. It would be
pretty desirable to allow for cmdline options as alternative.

Just m two cents,
Oliver

PS: Yes, I know that one can create a '_FileInformation.txt' on the fly.

[olivier...@cooperteam.com]

You can also patch the code of Cadius to do so.

I guess there are only 10 lines to modify in the source code to authorize the usage of extra parameters (TYPE + AUXTYPE) on the command line for ADDFILE. If I find 10 minutes next week, I'll update it with this new option.

Olivier

ps : usage of _FileInformation.txt is interesting because you do not overload file name with information we don't care. It is alos a way to store complex data such as FolderInfo. You also encode a full folder withing a single file. Now, for the ADDFILE, I understand that 99% of the audience don't care about FolderInfo and want only TYPE / AUXTYPE.

[Oliver Schmidt]

Hi,

> You can also patch the code of Cadius to do so.

I don't think that it helps much to answer "all" feature suggestions with
"it's open source - just change it" ;-)

> ps : usage of _FileInformation.txt is interesting because you do not
> overload file name with information we don't care. It is alos a way to
> store complex data such as FolderInfo. You also encode a full folder
> withing a single file.

Surely - and therefore I didn't even implicitly suggest to move away from
the "side car file" appraoch.

> Now, for the ADDFILE, I understand that 99% of the audience don't care
> about FolderInfo and want only TYPE / AUXTYPE.

Yep, therefore I explicitly referred to the context given by the OP of this
thread.

But apart form that Cadius is advertised as part of a cross dev tool chain.
So it's not 99% of some audience (ob-)using the tool but 99% of the
intended audience ;-)

And as a final remark I personally would consider it great if the cross dev
tools generating Apple II binaries and the (command line) tools being able
to add/insert/inject them (in)to disk images would share some standard to
express at least the most important meta data - namely the file type and
the auxtype.

To me the Ciderpress approach to encode those meta data in the "foreign"
file name seems a reasonable idea at first sight. However I fear that most
cross dev tools aren't easily adapted to fiddle with the file name provided
by the user as output file. And it would become virtually impossible to
automate the further processing of those files (i.e. with 'make') if the
actual name isn't known beforehand :-(

So one ends up with the need for some proprietary header to be added to the
file. As there was no standard I opted for the old DOS 3.3 B file 4 byte
address/length header. It can be written by the cc65 linker and can be
consumed by AppleCommander and a2tools.

Obviously the DOS 3.3 B file header is less than optimal (as it i.e.
doesn't contain the file type). I just wanted to point out the benefit of
such a "agreement" between binary file producer and disk image handling
tool.

Regards,
Oliver

[olivier...@cooperteam.com]

Le jeudi 13 juillet 2017 17:55:52 UTC+2, Oliver Schmidt a écrit :
> Hi,
>
> > You can also patch the code of Cadius to do so.
>
> I don't think that it helps much to answer "all" feature suggestions with
> "it's open source - just change it" ;-)

I guess it is a valid answer if the effort is limited. Here we speak of 10 lines of code to modify. I agree that if 50% of the open source has to be re-written, the 'do it yourself' shows its limit.

> To me the Ciderpress approach to encode those meta data in the "foreign"
> file name seems a reasonable idea at first sight.

It is one possible option. My concern is about the mirroring of the Prodos drive and the PC drive. When I export all my Prodos drive content into a folder of my PC, I want the file to keep their extension without getting extra information in the file name. I have GIF files on y Prodos drive, I want to access them directly on my PC, without having to rename them. Same for Text files, MOD files, midi files... Even if the extension has never been used in the GS/OS and Prodos as a way to type the data, it is now a standard everywhere else. So, my .s or my .txt file on the PC can also be a .s or a .txt file on the Prodos Volume.


Regards,
Olivier

[Steve Nickolas]

I guess a possible option would be to have default mappings for certain
types by extension (such as .sys -> #FF0000, or .bin -> #060800, or .bas
-> #FC0801)...

-uso.

[Antoine Vignau]

Steve is right, this is the method used by Apple in its Apple Exchange thing between MS-DOS and their file systems

[olivier...@cooperteam.com]

Le vendredi 14 juillet 2017 13:22:26 UTC+2, Steve Nickolas a écrit :

> I guess a possible option would be to have default mappings for certain
> types by extension (such as .sys -> #FF0000, or .bin -> #060800, or .bas
> -> #FC0801)...
>
> -uso.

Could you provide a list here ?

[Antoine Vignau]

It is probably on the File Type Notes by Apple

[Michael 'AppleWin Debugger Dev']

On Wednesday, July 12, 2017 at 1:50:45 PM UTC-7, John Brooks wrote:
> On Wednesday, July 12, 2017 at 8:51:02 AM UTC-7, Michael 'AppleWin Debugger Dev' wrote:
> I use Cadius from Brutal Deluxe. It is a simple cmd-line tool written in C and can do pretty much any file manipulation job needed on ProDOS disk images.

John,

Thanks for the mention about "Cool Another Disk Image Utility Software", aka Cadius. I took a quick look at it and it seems OK.
https://www.brutaldeluxe.fr/products/crossdevtools/cadius/index.html

One caveat is that it is currently for Windows only. It includes a pre-compiled .exe (yay!) but, as the webpage says, needs to be ported over to compile with Linux / OSX. (boo)

I've started the process of cleaning up the source so it compiles under OSX -- just need to fix the 2 errors of c_file type and mkdir() argument count.

[olivier...@cooperteam.com]

Cadius has already been ported to Linux and Mac OS.

Ask Dagen for the binary (he is using it). I need to update the web site with this release.

Olivier