Ser Olmy wrote: ↑Fri Feb 09, 2024 5:51 pm
wouldn't expect a beginner with no programming experience to start by redefining the system fonts,
Nope, but as-needed regional ROMs could be made, and the community is approachable enough to make that happen. As character sets are changed, they are copied from System ROM over to VERA VRAM.
Ser Olmy wrote: ↑Fri Feb 09, 2024 5:51 pm
and the YM2151 is used for ... well, nothing. Honest question: How much CPU time does the playback routine require?
Nothing? Ok, I've updated the video description of the audio demo linked earlier to annotate which sample is using which audio capability. Out of the 14 samples, only four of them do not make use of the FM (YM2151). One of them ONLY makes use of the FM. So I'm not following what you mean here? Regarding CPU time, when using VGA output on Melodius it shows a kind of "CPU utilization" on the far right (same as Calliope before it). The video capture maybe didn't have enough frame rate to fully keep up with it. In some cases, some streaming from the SD (memory card file system) to the audio hardware is involved. MooingLemur also created another example of a "TSR" (customized interrupt routine) that you could invoke an audio playback in the background, while continuing to use the X16 CMDR-DOS as normal. In other words, the system isn't fully stressed only doing audio playback - there is plenty of CPU time remaining for "AI"/NPC logic or exchange of game-state over external communication (network gameplay) and certainly local gamepad polling. That was another point of the Melodius audio demonstration: there is enough CPU time left over to visually depict what all the audio channels are doing in real time. But maybe I've misunderstood the question re: CPU time?
Ser Olmy wrote: ↑Fri Feb 09, 2024 5:51 pmI know very little about the Agon Light, especially its audio capabilities, and visiting the various web sites associated with the project didn't help much.
I got one, I had to try over a dozen PS2 keyboards before finding one that actually worked with it. And it doesn't boot to BASIC - it can be setup to BOOT to BASIC, but it's a number of steps to figure out how to get to that point (and then it's a lackluster BASIC). I haven't used that AL in over a year and it's not something I recommend gifting (like to nephews), especially for the PS2 keyboard issue. Maybe I should give it another fair chance someday, but really the X16 has been far more fun to use from Day 1.
Ser Olmy wrote: ↑Fri Feb 09, 2024 5:51 pmBASLOAD is good. Ditching the ancient BASIC interpreter entirely would have been even better.
Do you mean something else, that would also fit within an 8KB ROM slot? Something like APL, since we could apply APL symbols to the font? Maybe giving that one more chance, something like APL might finally catch on? Not likely. Or do you mean something like Python? Not all of that capability is going to fit in ROM, and so then you levy SD-card content requirements. No thanks - I'll take the "bare minimum" solution to maintain that "boots into programmable mode" feel, and nearly "instant on" (2-3 seconds at most). There were some growing pains between R31 and R46 releases of the System ROM -- breaking backwards compatibility in some cases, and that kind of "moving target" a lot of developers don't want to deal with. But through that churn, a number of good BASIC keywords were added, and refinements to the BASIC/KERNAL interaction.
prog8 has been a very interesting novel approach to software development for the X16. But on-system high level language support remains a challenge, specifically going past the "64K" RAM barrier (of both code space or data space). Solving that, on system, gets into "basically I need to build a complete operating system" level of effort. That is, deciding policy on how to handle across-BANK allocations. Building that on spare-time as hobbyist will take a while (a couple Pascal projects are working towards that). That was the appeal of QDOS (that became MS-DOS): it allowed up to 10 segments of 64K to be more seamlessly used by end users (i.e. appearing as "contiguous" 640K RAM). So then it's no surprise that C and Unix were essentially co-developed: one needs a greater expression to do structured dynamic memory allocation, but a kind of "operating environment" is needed that decides where/how to note down the allocations.
Ser Olmy wrote: ↑Fri Feb 09, 2024 5:51 pmToday, computers are almost literally a dime a dozen, and people aren't impressed in the slightest by seeing lifelike graphics in computer games.
Yep, much is taken for granted in computing these days: flow some electrons down metal conduits, apply some Boolean logic to the path of that flow to build up to fancy math expressions, which in turn build up into a rendered depiction to something we equate "in the real world" (starting with monospaced fonts, then to the amazing real time rendered images we get today). To me, the X16 is like a skateboard or BMX bike: A device that can do a few tricks and fun to use in your spare time, but not something you'd use on the main highways.
Note on the X16 SD card, I put in BASIC examples of BIGFONT, VELOCITY, INTEREST as examples of "computationally interesting" tasks (along with other such examples by other folks). To show it's not a system for just bouncing sprites around. It's not "so capable" that you end up just streaming YT. It's odd to advertise something on merits of "what it can't do" - but that really is part of the charm of something like the X16.