Thoughts on a menu/launcher with auto config (revised)

[Daedalus]

Ah! An update to the original post.

Now, I'm really not trying to be the "contrarian bad guy" here, but I feel like that's what I'm coming off as, and that's really not where I want to be. So, view me as a "Devil's Advocate" of sorts.

I can see where the start menu would be a cool way to find programs that are already on the SD card. You click "ADD A PROGRAM" then are presented with a list of programs that are both on the SD card with a manifest and not in the start menu's list... and add them. Easy peazy.

But how did the program get onto the SD card in the first place? Bear in mind that this needs to work for all 3 use cases: Programs you downloaded to use on the emulator, programs you downloaded as "downloadable content" and intend to use on actual hardware, and programs you bought on an SD card that you want to add to the SD card you already have.

The fourth use case, where you bought an SD card with a program on it and just want to run it right now is handled by reaching around to the back of the machine, yanking out the SD card, and inserting the one they just got. Basically using the SD card as a "game cartridge."

For use cases 1 through 3, the user needs to know how to put the program onto the SD card, or know how to download it and put it in a directory the emulator can get to. And the easiest way to do that is a link to a website with a manual or a link to this forum with a pinned page.

[Jestin]

But how did the program get onto the SD card in the first place? Bear in mind that this needs to work for all 3 use cases: Programs you downloaded to use on the emulator, programs you downloaded as "downloadable content" and intend to use on actual hardware, and programs you bought on an SD card that you want to add to the SD card you already have.

The fourth use case, where you bought an SD card with a program on it and just want to run it right now is handled by reaching around to the back of the machine, yanking out the SD card, and inserting the one they just got. Basically using the SD card as a "game cartridge."

I think the main issue here is with using the emulator. Managing a physical SD card is no big deal for even a casual user of modern computers. You put the card in, you add/remove/move files, you take the card out. Every OS has made this easy. The problem arises when you need to manage an SD card image. That is not straight forward on any OS, which is why I feel this discussion is even taking place.

If we limit our use cases to physical hardware, everything becomes much simpler. DOS commands can get you to directories where games are stored, or a launcher could be build that is easily configurable by modifying files on an SD card (probably on a modern OS, but possibly with something on the X16). Downloadable content can just be zip files, perhaps containing any launcher metadata files that would be needed. You download, you unzip, move the card to the X16, and maybe you browse to a directory if a launcher isn't used.

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.

The more I think about this, the less I care about the emulation experience. Ideally, hardware will be the preferred platform once it's available, and the emulator will be seen more as a development tool. I'm not sure it will turn out that way, but that's what I hope will happen. In any case, I'd hate for the user experience on the emulator to be prioritized over the user experience on the hardware. I'd suggest making a good experience (and perhaps a launcher) on the hardware, and then giving a best effort on the emulator. Not the other way around.

[TomXP411]

The more I think about this, the less I care about the emulation experience. Ideally, hardware will be the preferred platform once it's available, and the emulator will be seen more as a development tool. I'm not sure it will turn out that way, but that's what I hope will happen. In any case, I'd hate for the user experience on the emulator to be prioritized over the user experience on the hardware. I'd suggest making a good experience (and perhaps a launcher) on the hardware, and then giving a best effort on the emulator. Not the other way around.

I've thought a lot about emulation vs hardware, too, and there are good reasons to treat the emulator as a first-tier product. Primarily, it's the entry point into the ecosystem, and if the emulator is allowed to die on the vine, this will affect people's perception of the system and will result in fewer people buying hardware.

Aside from that, some people simply can't afford to buy hardware or live in places where getting the hardware will be difficult or impossible. So emulation may be the only choice for some people.

Also, the emulator is the best tool for software development, because it's quick and easy to deploy software to the emulation environment for testing and feedback. I can compile and run a program on the emulator with one click, where it takes several steps to move a file to the physical machine and run it. In my day job, I use a virtual machine every day, and I rarely touch the hardware my software is deployed on. If I do, it's only for issues I can't resolve on my VM. So the emulator is critical for software development.

So we need to always consider the emulator when writing software. In some ways, it's the most important part of the ecosystem, and if we ignore that, we'll miss out on people who haven't yet or can't obtain the hardware.

[Cyber]

Managing a physical SD card is no big deal for even a casual user of modern computers. You put the card in, you add/remove/move files, you take the card out. Every OS has made this easy.

I just now had a thought. Modern users don't usually use SD cards as a removable media nowdays.So most modern users won't be a able to put the SD card into their modern computer, unless they have an external SD card reader (which is not a usual buy nowdays also). It is funny, but I realized that just now.

[TomXP411]

Managing a physical SD card is no big deal for even a casual user of modern computers. You put the card in, you add/remove/move files, you take the card out. Every OS has made this easy.

I just now had a thought. Modern users don't usually use SD cards as a removable media nowdays.So most modern users won't be a able to put the SD card into their modern computer, unless they have an external SD card reader (which is not a usual buy nowdays also). It is funny, but I realized that just now.

Good point. Many laptops have SD card readers, but not all of them. I think my work laptop has one, as do my NUCs. My personal laptop does not.

Regardless, people will need SD card readers if they want to install software to their new Commander X16, and since you can get them for less than $20, there's no excuse to not have one, these days.

[Jestin]

Also, the emulator is the best tool for software development, because it's quick and easy to deploy software to the emulation environment for testing and feedback. I can compile and run a program on the emulator with one click, where it takes several steps to move a file to the physical machine and run it.

This is what I'm considering the real use case for an emulator. I see it more as a software development tool rather than a target platform. I'm not saying it isn't useful, but it's hard for me to agree that it has the same priority as the hardware it's emulating. There will always be some emulator-only users, but what was the point of a retro machine built with modern off-the-shelf parts if not to actually use the hardware?

As far as functionality is concerned, the emulator needs to be one-to-one with hardware for it to continue to be useful as a development tool. In this way, I feel it's a little more first-tier, but not so much when it comes to end users. What the main issue is, however, is still that SD image problem. To make loading software easier for emulator users, SD image management needs to be made easier for users. Hardware SD management is something I'd consider solved (despite Cyber's correct observation on card readers), but to my knowledge there is no simple answer for SD images for casual users.

Have we been overlooking the emulator's native filesystem support? I know there are some changes coming for r42, but I haven't paid much attention to what they are. Does anyone know if it is possible to ignore SD images altogether on the emulator in favor or running from a native directory? Are images still necessary/useful during emulation? Could a launcher/installer simply be configured with regular file management?

[StephenHorn]

This is what I'm considering the real use case for an emulator. I see it more as a software development tool rather than a target platform. I'm not saying it isn't useful, but it's hard for me to agree that it has the same priority as the hardware it's emulating. There will always be some emulator-only users, but what was the point of a retro machine built with modern off-the-shelf parts if not to actually use the hardware?

The emulator, however, sort of has multiple roles, whether it was intended or not:

1. Software development and debugging.
2. Advertising the platform and its software.

In particular, the web build placed a much greater emphasis on the latter point, along with the previous forums' embedded support for running software through it. I suppose I'd be a little curious to know more about how that worked, because the emulator does not natively support opening up zip files and treating them as directories. My not-well-educated guess is that the web-based emulator was unzipping projects into a temporary, sandboxed directory on the web server, or else had some way of unzipping projects into a local sandbox on the web client.

It would be nice to restore the web emulator. I'm still working on finding/devoting time to catch up with PRs to x16emu. It's on my "to-do" list, but please, please don't anyone let that stop you from looking into that on your own if you're interested in it. The joy of open-source is that we can always do more together than we can individually. And I can (and do) accept pull requests for x16emu, even if I do struggle to find the time on larger submissions.

Have we been overlooking the emulator's native filesystem support? I know there are some changes coming for r42, but I haven't paid much attention to what they are. Does anyone know if it is possible to ignore SD images altogether on the emulator in favor or running from a native directory? Are images still necessary/useful during emulation? Could a launcher/installer simply be configured with regular file management?

As a matter of fact, MooingLemur has submitted a pull request to x16emu to greatly improve support for using the native filesystem when the emulator does not consider an SD card to be attached to the system. I've finally started working my way through it, but I don't quite have an ETA on when I'd accept it. It's a big set of diffs. I'll probably have some notes. Though in the meanwhile, Lemur has also created a branch of x16emu with all the pending PRs integrated.

[AndyMt]

How about allowing the emulator opening a specific file extension like "*.X16" which would just be renamed SD-card images. Developers could supply this file extension in the download section if they want.
This would allow users to just double click a download and it would be ready to go. I quite liked the "Try Now" feature of the old forum, as you quickly could run any of the offerings by the click of a button.

[TomXP411]

How about allowing the emulator opening a specific file extension like "*.X16" which would just be renamed SD-card images. Developers could supply this file extension in the download section if they want.
This would allow users to just double click a download and it would be ready to go. I quite liked the "Try Now" feature of the old forum, as you quickly could run any of the offerings by the click of a button.

That's already been discussed upthread; the short version is that SD card images are not just a waste of space, requiring a minimum of 32MB, but they don't do any good for people using actual hardware. Whatever solution we choose has to work for both the emulator and the real machine. Besides, the need for SD images is going to go away, once MooingLemur's changes to the emulator go through.

We'll still need to use SD card images to test low level file I/O routines, but apps that use the KERNAL for I/O will be able to talk directly to the host file system.

[Ed Minchau]

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?