Commander X16

Update:
It seems like a launcher is the way to go, with a simple manifest file format to populate the entries:

The launcher will maintain its own menus, but it will also auto-scan the SD card for AUTOBOOT.X16 and MENU.X16 files.

So here's my current thought:
The launcher would boot up (manually or via AUTOBOOT) and read its config file to display existing, known programs. On that menu, you would have options like:
F1: SCAN FOR NEW PROGRAMS F2: ADD A PROGRAM F3: ADD A CATEGORY F4: DELETE AN ITEM

If the user presses F1, the launcher will scan through the SD card, looking for new manifest files. the manifest can be in the form of a PETSCII text file or a BASIC program.

MENU.X16 is a plain text file and looks like:
NAME:CHECKERS
BY:JOHN SMITH
CATEGORY:GAMES
RUN:CHECKERS.PRG
README [[
THIS IS A SIMPLE CHECKERS GAME. PLAYERS TAKE TURNS AND USE THE
KEYBOARD OR MOUSE TO SELECT AND MOVE A PIECE.
]]

AUTOBOOT.X16 would be similar, but use REM statements. AUTOBOOT does not need a RUN: line, because
the launcher will run the AUTOBOOT.X16 file, which will in turn run the actual program.

10 REM NAME:CHECKERS
20 REM BY:JOHN SMITH
30 REM CATEGORY:GAMES
40 REM README [[
50 REM THIS IS A SIMPLE CHECKERS GAME. PLAYERS TAKE TURNS AND USE THE
60 REM KEYBOARD OR MOUSE TO SELECT AND MOVE A PIECE.
70 REM ]]
100 LOAD "CHECKERS.PRG"

For other BASIC programs, you could add the same data as REM statements, and the launcher could just pick them up and add them. For machine language programs with BASIC launchers, you could do the same as above, just moving your start point a little higher in memory to allow for the metadata.

So really, the only thing we'd be asking programmers to do is to consistently add this information to the top of their programs. It not only makes it easier on everyone to have a consistent header, but it makes it easy to automatically parse and add this to menu programs.

Original post:
So the discussion on the Snake topic made me start thinking about a one-click installer for the Commander.

It would need to unpack and install files for both the physical machine (via SD card) and the emulator.

Basically, this would start out as a Zip file, with a custom extension (like P16) that would allow us to open the file in the installer.

The installer would look for a configuration file in the Zip and would do a few things.

• Copy the files from the package to a directory on the SD card or the emulator's SD image.
• Add an entry to a boot menu, pointing to the program
• Optionally sync files between the emulator and the SD card

Part of this package would be a menu program that lets users launch programs on their Commander. It would include an uninstall feature, which would remove the files associated with an app (via a manifest file located in the app's program directory), and it would be able to pick up newly installed programs and add them to the menu.

Right now, this is a loose collection of ideas, and I don't have a specific implementation in mind yet. Quite frankly, the Commander side could simply be BASIC code, and I'm picturing something simple and cross-platform for the PC side... maybe even something bundled with the emulator. Maybe even a program that runs in the emulator.

What are your thoughts?

My personal thoughts is that this is out of place on Commander. My view of retro system is that I am in control if things. And simplicity is important. Most programs should be able to run without installation. (Remember The 8 Bit Guy's comparison of old and new computers: installing a program means putting a floppy in the box - that's all, program installed.)
If a program needs to setup drivers or add some line in a config file - I would like to do it myself. And being a program on a retro system, it should be simple enough.

I'm not discouraging people making such installer if they want to. I'm just sharing my thoughts and preferences.

I also think this feels out of place (but again, everyone should make what they want). One of the things that has been lost since the 8bit era is the statelessness of a computer. A reboot was the same thing as a modern "factory reset", and you never had to worry about what state you were starting from (drivers/dependencies installed). I suppose a better way to rethink your problem is to ask what advantages state could have, and whether is it worth managing on the Commander X16.

Maybe it's because I'm still waking up this morning, but I'm not sure I understand what the intended context is for this installer.

If it lives on the X16, then I don't understand what it's purpose is supposed to be. Reading from the SD card is generally "fast enough" for the 512KB of internal memory that the X16 is expected to ship with. So front-loading into RAM isn't a problem, and the kernal already exposes a set of functions to help with rapidly moving data between the SD card and RAM (or VRAM). A cartridge isn't a problem, either -- the data is already on the cartridge, how much faster do you need to access it than the literal speed of RAM? An installer in the kernal seems like it would just perform a search of the SD card and then provide a menu of asking which PRG to LOAD and then RUN. Maybe that's an improvement over CBM DOS commands or the original LOAD"*"/RUN experience, but I wonder if that isn't drifting away from Dave's vision for the machine and would want to ask for his feedback before writing a bunch of assembly to put that into the ROM.

If the installer lives on the emulator, then I think there are already other methods already in place that can help manage multiple finished projects, with promising avenues being explored to help users manage loose files. The existing emulator support for SD card images is 95% of the work here, really the most I would expect to need on top of this would be a better implementation (or really, any implementation where x16emu is concerned) to swap around SD card images at run-time, without having to quit the emulator and relaunch it with a new -sdcard parameter. As for loose files, there's an active pull request for x16emu to emulate the CBM DOS environment more directly, allowing the X16 to work on the host's filesystem through the kernal API instead of relying on an SD card image. (And I swear, I haven't forgotten about those changes and still intend to find time to go through them -- though I'd almost certainly still want mist64's feedback before accepting them into x16emu.)

What I think may be missing from a fully robust feature set is the ability to create new SD card images from scratch. It would be nice if the kernal had some function or BASIC command to format an SD card, so that the X16 can do this directly (or can do it through the emulator once the emulator creates or opens an empty file). But it could also be nice if the emulator, itself, could generate formatted SD card images on the host filesystem. That, and/or maybe a tool or some emulator code to help folks author and manage the data on SD card images -- that's a todo item on Box16, but I have no idea when I'd be able to get around to it.

I also agree that the machine should be stateless and simple. Every time you turn it on, it looks the same.

However, there is a gorilla in the room. The SD card is essentially a hard drive that will fit many many games, while you COULD have a single game on each SD card, it's position on the back of the machine is inconvenient and you would have a huge number of SD cards when only one or two would suffice. Hence, there are sub directories on the card. As such, we've already "mission creeped" the original hardware into a position where "Now we need installers." and eventually... "Now we need a program registry."

It seems to me that the core issue is the machine "boots to BASIC" instead of of "booting to DOS" like computers started to do as soon as they had storage devices out of the box. I think there's some kind of rudimentary DOS in the BASIC, but I have no idea how to actually use it. Ok. I'll look at the github repo for "BASIC." There's a command called "DOS" (Actually, I already tried that, and it responded with some random looking stuff before going back to "READY.") Apparently, the second field (The text one.) is a command. Ok. DOS "list"... nope. DOS "dir" ... nope. I have no idea how this is supposed to work. My gut instinct was to try all the "Directory" commands I could think of at the READY prompt, like LIST or DIR... nope. What about HELP? Nope. Yeah, I have absolutely no idea how this is supposed to work.

My strategy for getting games on the SD card has been to use bash on my main computer to just put the files into a directory, then use a bash script to run the emulator with the -prg switch set to run that program.

So, if I had a hardware Commander X16 and I bought a box game ... say... at a retro compute show and it came with an SD card what arcane ritual would I have to perform to load it onto my own SD card that I have all my games on?

Let me clarify after reading StephenHorn's post (Which was posted while I was writing mine.)

I've never used the -sdcard switch to map a physical SD card to the emulator (At least I assume that what that does.) Instead I just cd to the directory I want (I run Linux Mint on all my computers.) and run the emulator from there, essentially making that directory the "SD card" as far as the emulated Commander is concerned. That has worked just fine. I don't concern myself with the "speed" of the SD interface as it's so much faster that an 8 MHz 6502 and has to load so little data that it's irrelevant.

Edited to add: Essentially unrelated... but I don't think it's necessary (Assuming it's even actually possible.) to give the X16 the ability to format SD cards out of ROM. Simply saying "SD cards formatted for FAT32 are required" would suffice, and if you really wanted to be fancy you could ship a "FAT32 formatter" utility on the SD card it ships with.

That doesn't solve the management issue, though. You would need 2 SD card slots for the X16 to transfer a game you bought on SD card to a "main SD card" you store all your games on. And it appears the system is already locked down to the point where you can't do that.

Daedalus wrote: ↑Thu Jan 26, 2023 4:16 pm As such, we've already "mission creeped" the original hardware into a position where "Now we need installers." and eventually... "Now we need a program registry."

I don't agree that subdirectories imply the need for an installer, provided the user can use the DOS commands to navigate their SD card's filesystem.

The DOS commands seem to have been a real sticking point for you, because the DOS commands are not well-documented and they presently require the emulator be pointed at an SD card (the emulators have extremely limited capability to directly work with the local filesystem). Here's some quick tips I was able to pull from the DOS testing script in the x16-rom repo:

• dos"$" | This is "dir".
• dos"cd:foo" | This is "cd" into the directory "foo".
• dos"cd:.." | This is "cd" out of the current directory and into its parent.

LOAD, SAVE, OPEN, etc., work from the current directory.

I didn't immediately see a command to print the current working directory, but maybe that exists somewhere. To one of my own previous points, though, it looks like CMDR-DOS may already have the ability to format SD cards. I'll add "experiment with that" to my lengthy to-do list...

Daedalus wrote: ↑Thu Jan 26, 2023 4:16 pmSo, if I had a hardware Commander X16 and I bought a box game ... say... at a retro compute show and it came with an SD card what arcane ritual would I have to perform to load it onto my own SD card that I have all my games on?

I apologize if this seems snarky, but I think you're overcomplicating a very simple Windows file copy:
https://www.amazon.com/Anker-Portable-R ... B006T9B6R2

I guess I did skip the "why."

The thing I'm seeing is comments in the files section and elsewhere about "how do I run this game?" I feel like this presents a bit of a stumbling block for people that aren't used to actually having to operate their computers from the command line, and I think a standardized menu and install framework would make it easier for people who have never typed a DOS command and have always let the OS manage their software installs.

Right now, the process of installing a game to an SD image for the Commander is...
1. Mount the SD card image. On Windows, that either requires third party tools or creating a new VHD with Disk Management.
2. Copy the files in to the SD card image.
3. Unmount the image
4. Start the emulator from the command line, to supply the -sdcard argument (or create a script or shortcut to do the same)

The upcoming changes to the emulator will help, but a "one click run" for the emulator solves the "how do I play this?" question, since the package file would be associated with the emulator, which would unpack and run the program bundled in the package.

StephenHorn:

It did not occur to me to look in the rom repo to find DOS test cases. And there they are! Hey! They sort of work even if you're not using an actual CD card... but I can't change the directory. I even made a directory in UPPER CASE like I was 18 and still in 1978 just to see if it didn't work because all my directories there are in lower case. Sadly, no joy. Ah well.

LOL! You included a link to a USB SD card reader! That's hilarious! Thanks! Now if the one I have dies, I'll know where to get another.

I was going to say "Ok, Boomer!" but you might not have gotten it, and I'm probably older than you anyway. Also, if anyone can be accused of being snarky here it was me with the use of "arcane ritual."

So I'll explain my snarky comment: Since there is only one SD card slot on the X16, and there is nowhere inside the X16 to fit an entire directory of stuff in one go, how would I copy a game I got on an SD card to a directory on another WITHOUT using a modern computer to execute the file copy? This leads to the original post and it's "installer", which can't install anything on the X16 without physically removing the SD card and sticking it into a modern computer. Once the SD card is IN the modern computer, in theory, the installer can install new games onto it and update games that are already there. which leads to the mission creep.

Hence the "gorilla in the room" from my first response, that there is only one SD card reader and it's on the back of the machine. Ergo, if the expected use case is to use a modern computer (Which is legit, as everyone who is going to get an X16 has one.) to copy the game to the user's "Game SD card" or just use the SD cards you got the games on directly as if they were floppy disks that could hold an entire game. You can't even add a shell because ... what would you do with it? There is no practical way to copy a game from one place to another with it until the game is ON the SD card that you want to move it to without playing the "Insert source disk..." "insert destination disk..." game over and over and over. And THAT got old decades ago.

The upcoming changes to the emulator will help, but a "one click run" for the emulator solves the "how do I play this?" question, since the package file would be associated with the emulator, which would unpack and run the program bundled in the package.

That idea is causing some thoughts to percolate in my head. Hopefully soon the emulator will have more robust support for loose files on the local filesystem. Maybe once that goes in, we can leverage that code and add in the ability for the emulator to treat a zip file as the local filesystem.

But right now, the best interim solution might be to ask software developers to submit downloads here on the forums in the form of an SD card image, or an SD card image in a zip file. That way, folks who want to run software from here don't need to worry about loose file support or building their own SD card images, and can just run the emulator with an appropriate -sdcard parameter.