Commander X16

Ed Minchau wrote: ↑Sun Feb 05, 2023 7:41 am

Daedalus wrote: ↑Thu Jan 26, 2023 4:16 pm 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?

The X16 is going to have a bunch of user ports. Maybe someone could create a board the has a second SD card reader. It would probably need a ATtiny and its own onboard ROM with all the software the X16 needs to blit the data.

Has anyone started looking at making peripheral cards for the X16?

This should be possible with the SD2IEC. You'd just need to connect an SD2IEC on the IEC serial port and then just run a file copy program to transfer files from the SD2IEC to the internal SD card.

Or you can insert the game card into a PC, copy the files to your hard drive, then insert your other card and copy the files back.

We will also have a network interface available as an expansion card. I expect that to be a popular add-on, especially since the Gen-2 system will have this same network feature built-in. With appropriate software, we'll be able to copy files from a PC or even over the Internet.

Note that we need something different from "AUTOBOOT.X16" for the Basic program that the Launcher loads, because on powerup the system will run AUTOBOOT.X16, and having "but don't put this in the directory searched by the system on power-up because it will think it is the power-up configuration program" is too confusing an explanation to be viable.

• Note: a "program distribution" might have one or the other or both of the first two
• name.X16 is a Basic program that IS the "name" program, because "name" is a Basic program
• name.PRG is a binary program ready to be loaded according to its two byte address header, which might be the basic location with a magic basic launch into a SYS call (like my xforth.prg) or might be a call to another address which requires an explicit SYS call to launch. If it accompanies an .X16 Basic file, it is probably a data file or a binary for SYS calls by a master Basic program.
• Some *.PRG files may be for other Commodore systems and a distribution should be able to have VIC-20 or C64 versions and X16 versions side by side in the same distribution, so *.P16 would be a "for clarity, this is the X16 PRG file, not a PET or Vic-20 or C64 PRG file". This is a filetype used by ProTracker Studio, so I would defer to the audio hands whether it would better to use .B16 for X16 Binary file, where .B16 mostly means an obscure image file format.
• It may be assumed that if only one or the other is available, that's a program, and it may be assumed that if the header of a .PRG file points to the default basic location, it can be executed by RUN and otherwise it may be executed by SYS
• For any given program, those assumptions may not be valid, which is where a manifest comes in
• If you have a manifest, it will have the details, and also if it is a unique file type, it will be recognized as "the things with name.??? are all connected to this manifest, they do not have to be shown".
• I would recommend name.M16 as the Manifest file type. This is a Microsoft Money data file format, which shouldn't be a problem in an X16 program distribution.
• LAUNCHER.P16 (suitable for inclusion as being loaded as the last step in executing the AUTOEXEC.X16 file, or being copied as AUTOEXEC.X16) then searches for *.PRG, *.X16 and *.M16 files that it doesn't have in its file list when asked to scan for new files.
• KISS: Use name.M16 if it exists, otherwise use name.X16 if it exists, otherwise use name.P16 if it exists, otherwise use *.PRG

Note that if Launcher is developed so that (1) it works properly running in the emulator and (2) is available at the main X16 first release, hopefully later this year, it should be popular enough to become a de facto standard. Not requiring a manifest but having a manifest letting any distribution by launched with it no matter how the developer organized the program distribution would further support that.

Jestin wrote: ↑Mon Jan 30, 2023 8:19 pm As soon as we talk about emulation using SD images, things get much more difficult. Now we either expect users to modify existing SD images or to treat them as cartridges. Neither option sounds very appealing, if you ask me. Modifying images is a difficult task to ask casual users, and swapping cards is an inconvenience while you are actually using the X16. For example, what if I want to distribute an X16 tile editor. If I put it on it's own SD image, it's useless because I can neither create new game assets nor edit existing ones. The new ones I create will be stuck on an SD image containing nothing but an editor, and the existing ones are still on the SD images of their respective games, and not accessible on the SD image containing my editor. On actual hardware, I'd just unzip the editor to an existing SD card and that would be that. ...

To me, this says that the emulator needs an option to copy a folder or zip file from the host file system into the current SD image, and to create a new SD file system that has the folder / zip file contents as a directory of root.

Regarding the comment immediately above, note that my sketch of a launcher menu would not require state saved on the X16 nor the addition of any information to any config or "available programs" file at some specific location. Rather, it would be like Vernon D. Buerg's LIST.. Rather than "add new programs" as an option, you hit the "programs" function, and the names of things that LAUNCHER knows how to run are shown, and if you cursor/mouse over and return/click, it is run.

BruceRMcF wrote: ↑Thu Feb 09, 2023 2:45 pm ...from "AUTOBOOT.X16" for the basic program...

name.X16 is a basic program that IS the "name" program, because "name" is a basic program

...which might be the basic location with a magic basic launch into a SYS call...

...If it accompanies an .X16 basic file, it is probably a data file or a binary for SYS calls by a master Basic program.

...a .PRG file points to the default basic location...

For clarity's sake, please use the acronym "BASIC" when referring to the programming language, as "basic" is a word with a whole different meaning.

Thanks much.

I for one think that a menu / launcher is a good idea for two reasons:

- The SD card allows for FAR MORE storage compared to what was available in the 80's. Realistically people will probably use one or maybe two SD cards for everything. This is a stark difference from the 80's when you had a disk (or more) per application. It was as simple as: "insert the correct disk" then "run a load/run command". Now there is a lot of folder navigation and typing to get to the application you want before you load it. It is fairly tedious and slow compared to what people are used to today. A menu could speed this up quite a bit.

- The whole experience is unfamiliar and honestly not the easiest to research online. I feel this will turn off a lot of first time users, especially if they are younger and weren't alive in the 80's. They will dismiss the whole thing in the first 10 minutes and never come back. If you want the CX16 to be approachable for a new audience, a better startup interface option is really required.

Agreed. A menu or autolauncher is a good idea; it was even used in the 1980s in some machines. And although I grew up with the C64, even I consider the "LOAD" and "$" and "RUN", a very cryptic user interface.