| Attachment | Size |
|---|---|
 A2FILECMD-6502-BOOT.dsk | 140 KB |
| A2FILECMD-6502-EXTRA.dsk | 140 KB |
| A2FILECMD-65C02-XL.2mg | 32 MB |
Hi everyone,
I’ve been working on A2FileCmd, a keyboard-driven, two-panel file manager for the Apple II. The idea is to bring everyday file management, disk utilities and file viewers together in one program, with additional tools loaded as plugins.
Think of the two-panel workflow of Norton Commander, with the ambition of gradually bringing together some of the capabilities of Copy II Plus, Locksmith and ProSel.
What it can do today
- Copy, move, rename and delete files and directory trees. - Tag files for batch operations, sort directory listings and change ProDOS attributes. - Browse ProDOS and DOS 3.3 disk images as folders and extract their files. - Read physical DOS 3.3 disks. - Create disk images from floppies, write images back to disk and format ProDOS volumes. - View text, hexadecimal data, Applesoft listings and AppleWorks word-processing documents. - Edit text, compare files and search for names or content. - Extract ShrinkIt and Binary II archives. - Display HGR and DHGR pictures, and play Mockingboard music.
The plugin menu also includes tools for CRC-32 checksums, file identification, conversions, batch renaming and volume management.
A recent addition is VOLINFO, a read-only ProDOS allocation checker. It displays free space, fragmentation and a block map, and detects shared blocks, lost blocks and referenced blocks incorrectly marked as free.
Two CPU versions, three disk options
There are separate 6502 and 65C02 builds. Each has:
- BOOT: a bootable 140 KB floppy with the main program and essential tools. - EXTRA: a companion floppy containing additional plugins for that CPU. - XL: a bootable 32 MB .2mg containing the complete collection on one disk.
Single-drive floppy exchanges explicitly identify the disk and drive to use. The program requires 128 KB and an 80-column display; the original, non-enhanced IIe is supported by the 6502 build.
Next in development are deleted-file recovery, disk comparison, empty-image creation, damaged-media recovery, directory synchronization and a directory-tree viewer.
Source, build instructions and documentation: https://github.com/habib256/a2filecmd
I’d particularly welcome feedback from people using real hardware: original IIe machines, enhanced IIe and // c systems, Disk II drives and different storage interfaces. Which disk utility would you most like to have available without leaving your file manager?
The six tools mentioned above as “next in development” — UNDELETE, DISKCMP, MKIMAGE, RESCUE, SYNC and TREE — are now included. Please use the canonical GitHub Release for the complete, versioned 6502 and 65C02 BOOT, EXTRA and XL images, checksums and PDF manual: https://github.com/habib256/a2filecmd/releases I’m particularly looking for tests on real hardware and storage interfaces.
Thanks, FlyingZebra! A 40-column file manager for the II+ sounds interesting — I’d love to see what you’re working on.
A2FileCmd currently requires 128 KB and 80 columns, so your project would serve machines mine doesn’t support. Fitting a useful file-management interface into 40 columns is a challenge in its own right!
Are you going for a two-panel layout too, or a different approach? Always happy to compare notes.
Is there a chance for a version running on a II+ with Videx 80 column?
**The ProDOS edition** (the two-panel manager with the overlays) needs an Apple IIe or newer with **128 KB**. The launcher checks the machine before anything else and hands control back to ProDOS otherwise. That's not a licensing choice: the program writes the 80-column text screen directly at `$400–$7FF` with the even columns in the **auxiliary bank**, and it uses auxiliary memory throughout — panel tables, `/RAM`, double hi-res pictures, the block claims FIXIT keeps on large volumes. A II+ has no auxiliary bank at all, so no 80-column card can make that edition run there.
**The Videx Videoterm** is also a very different target from the IIe's 80-column card: its character RAM lives on the card and is reached through a `$CC00` window with bank switching, driven by its own slot-3 firmware, rather than being part of main/aux RAM. Every screen write in the program would have to go through a new driver.
**What does run on a II+ today is A2FC Mini** (DOS 3.3, 48 KB, 40 columns) — a separate, all-assembly program shipped as `A2FC-MINI-DOS33-*.dsk` in the releases. Its screen code is isolated in one file, so a Videx mode is *conceivable* in principle, but it would mean a new screen driver plus a re-laid-out 80-column panel design , and my test host has no Videx card. So it isn't on the roadmap. If you have the hardware and want to experiment, the Mini's sources are the place to start, and I'm happy to answer questions.
Why is the 65C02 build necessary at all?
Hi Arnaud,
thanks for your reply and detailed explanations.
Regards
Eberhard
There is a 65C02 in enhanced Apple IIe & Apple //c.
Enhanced have the mousechar.
So it is not the CPU that is needed, but rather the character generator. I recommend you to name your executables by character generator they use. It is not uncommon to see a 6502 installed in enhanced apple 2e's and vice versa (The ROM of enhanced is not relying on 65C02, and works fine with 6502). On the other hand a 65C02 may be present in accelarators, etc., on non-enhanced and plus-es, and your users may run 65C02 thinking the software needs 65C02 instead of the enhanced charset. I recommend you to add some computer recognition to know what computer the program runs on, and to adapt itself, instead of having so many executables.
You're right that the naming is misleading:
the 65C02 edition needs both a real 65C02 (it's compiled with 65C02 opcodes) and the enhanced ROM (MouseText, mouse). Its launcher only checked the ROM, so a 6502 in an enhanced IIe slipped through — that's being fixed with a real CPU test.
Note that since 0.8 all floppies are 6502 code and run everywhere; only the XL image still comes in two flavours, and a single XL that picks its edition at boot is on the list.
And what exactly is gained by using the 65C02 additional instructions?
Mainly more compact code and some cycle savings from cc65’s 65C02 code generation. I haven’t measured the overall speed benefit, so I can’t quantify it. The 6502 build provides the same file and disk tools; the enhanced edition also offers MouseText and optional mouse support.
There is most likely no speed benefit, but what about the size of the generated code? How much smaller is it?
The code-size savings are just enough to make room for mouse support.
How many bytes is that?
Measured on 0.9.5, same source, same compiler (cc65 2.18), only --cpu changed:
- Resident part (always in memory), C code: 24,933 bytes as 6502, 24,503 as 65C02. 430 bytes saved, 1.7 %.
- Whole C program with its 24 built-in overlays: 75,637 -> 74,394. 1,243 bytes saved, 1.6 %.
- cc65 git master gives the same picture: 448 and 1,283 bytes.
What the enhanced edition adds:
- Mouse: 492 bytes of C plus a 286-byte assembly driver = 778 bytes, all of it resident. So Thanks to the savings from 65C02. I need free space for mouse support ...
I would rather talk about what the program does. 0.9.5 came out on October 4, and it opens a lot more old files.
https://github.com/habib256/a2filecmd/releases/tag/v0.9.5
New formats with a viewer:
- VisiCalc worksheets, recalculated as VisiCalc shows them
- The Graphics Magician pictures (Penguin Software)
- Take 1 movies (Baudville) and Fantavision movies (Broderbund),
each with its own clean-room player
- The Newsroom photos, banners and clip-art disks (Springboard)
- Movie Maker backgrounds and shape sheets
- Epistole, Papyrus and HomeWord documents, with Epistole's calculations, headers and footers
- Bank Street Writer documents
- Saved text screens, 40 and 80 columns
- HRCG fonts (DOS Tool Kit .SET, Beagle Bros .FONT)
- Terrapin Logo procedures and pictures
- KoalaPad / Micro-Illustrator pictures
Also new:
- S in any picture viewer starts a slideshow round the folder; Fantavision movies follow one another the same way
- PT3 music plays with GROUiK / French Touch's player
- No question about /RAM any more when it is online and empty
- The XL disk's DEMO folder holds a file for every viewer
All of it runs on a plain 6502 as well as on a 65C02.
Sounds extremely handy! I can't wait to give it a try.
Thank you for your hard work. :-)
All your thanks should go to AI (most likely Claude) and engineers behind it ;)
@transwarp2, I understand your apprehension regarding the growing role of AI in development, but the "magic button" myth needs a reality check. Attributing all the credit to the AI overlooks the actual mechanics of the modern engineering loop.
AI is not an autonomous creator; it is a cognitive amplifier.
Syntax vs. Architecture: Just like we don't thank GCC or Clang for compiling a C++ binary, (Thanks CC65 !), AI translates human architectural intent into syntax. Formulating the strict constraints—like designing a cycle-accurate engine, managing memory, or setting up differential testing—demands a global vision that a language model simply does not possess for now.
The Instrument vs. The Scientist: Giving all the credit to the AI is akin to attributing the success of a complex thermodynamics experiment solely to the precision of the thermometer, completely erasing the physicist who designed the protocol, how to use the thermometer and writed the equations.
Furthermore, all my software is 100% free and open-source. The code and the structure used to generate it are available for anyone to study. Nothing is hidden. For me, AI is simply a tool that accelerates learning and allows me to finally bring to life the software I have always dreamed of building, without having to dedicate 2 or 3 years of my life to write it entirely by hand.
The syntax generation is automated, but the heavy lifting in engineering, design, and validation remains deeply human. The tool is incredibly powerful, but the intellectual effort and the vision belong firmly to the architect wielding it.
In the aviation we call this "lack of situational awareness". Shameless -- even your reponses here are AI generated. This was obvious and I needed just a few questions to expose that. Your merit in this and other jobs "of yours" is near 0. All is the AI, the mathematicians and programmers that created it and the readily published data that was used in its "learning" database. What you learned, and "your" code's merit to the people's total knowledge is zero--zero additional knowledge, the AI just did an assembly of already known blocks, blocks, created by other PEOPLE. You hardly learned anything, without access to AI you are still where you were -- a dreamer. Unfortunately the existense of AI will only amplify the plagiarism, and will put forward people who have no honesty and dignity to admit "Hey, it was not me, it was John, George, Nick , or even AI -- it was not me".
The true situation may be rather worse, as evidence see this recent paper: A Case of New-onset AI-associated Psychosis
Also, on the same subject from the Unintentional Hilarity Department, did you know that Sam Bankman-Fried mentee Leopold Aschenbrenner named his cratered AI "hedge fund" "Situational Awareness"?
@arnaudverhille
It is still 'drafty', I did not test or implement all of it but if you want to have a look:
Thanks for sharing, FlyingZebra! I tried your file manager and RetroAppleJS, and really enjoyed both. It’s great to see a 40-column file manager for the Apple II+, and being able to try it directly in your emulator is very convenient. Really nice work on both projects! :-)