Commander X16

On 12/13/2022 at 5:08 AM, Jestin said:

Sound is just too complicated to do anything at a beginner level.  The proposed BASIC commands would fix that.

Might be worthwhile to add a small section on how to make music that sounds like anything that makes sense. Without getting too theoretical.

 

On 12/13/2022 at 5:24 PM, neutrino said:

Might be worthwhile to add a small section on how to make music that sounds like anything that makes sense. Without getting too theoretical.

That's the gist of the problem.  Right now in order to do that it would require explaining too much, and would leave the reader unable to fiddle with things on their own.  Having a few handy BASIC commands and some pre-defined patches would enable the reader to try a couple examples from the chapter and then immediately jump in to making their own music.

@Jestin Some VIC-20 manuals had a short music explanation. Perhaps 1-2 pages. Music consist of notes, octaves and pauses. Here's an example notation. Look here code with data statements.. try ?

 

 

 

It was only 1 page, which is more or less my point.  It's not the DATA statements I'm worried about, but the mysterious setup and complicated read loop that the X16 will need in order to achieve an equivalent example.  For example, here's the setup needed for the VIC20:



It's 2 variables and a single POKE.  Not bad at all.  Here's the equivalent for the X16's YM2151 chip:

Quote

5 YA=$9F40 : YD=$9F41 : V=0
10 REM: MARIMBA PATCH FOR YM VOICE 0 (SET V=0..7 FOR OTHER VOICES)
20 DATA $DC,$00,$1B,$67,$61,$31,$21,$17,$1F,$0A,$DF,$5F,$DE
30 DATA $DE,$0E,$10,$09,$07,$00,$05,$07,$04,$FF,$A0,$16,$17
40 READ D
50 POKE YA,$20+V : POKE YD,D
60 FOR A=$38 TO $F8 STEP 8
70 READ D : POKE YA,A+V : POKE YD,D
80 NEXT A

It's a full on READ loop using values on lines 20 and 30 that are far from easily explained.  A manual that explains those values to advanced users is fine, but the low end of my target demographic is 6-8 year olds.  Any explanation of lines 20 and 30 simply isn't going to be acceptable (although you're welcome to post your best effort).

The READ loop in the VIC20 manual is also fairly simple:



It reads the note, checks the end condition, reads the duration, plays the note, and waits the duration.  It's very simple to document.  Here's the X16's version:

Quote

90 READ P



100 IF P < 0 THEN 300



110 READ D



120 POKE YA,$29



130 POKE YD,P



140 POKE YA,$08



150 POKE YD,$00+1



160 POKE YD,$78+1



170 FOR N=1 TO D : NEXT N



180 POKE YD,$00+1



190 FOR N=1 TO 20 : NEXT N



200 GOTO 90

There's too many magic numbers in there to understand what is being set.  When you put this all together, you get one of those type-in programs that nobody understands, but just type because you trust it will work:



For a beginner-targeted user manual, annotations need to be considered.  I'll argue that properly documenting the above code would require more bubbles than would fit on the page.  The code, itself, wouldn't fit on a single page the way the VIC20 example does.

Meanwhile, having a single statement that loads the instrument and a single statement to play a note would turn the above code into more or less the exact same thing as the VIC20 example.  No unexplainable magic numbers would have to be typed.

On 12/12/2022 at 8:08 PM, Jestin said:

No matter, though.  I believe I have an adequate template (but more will still be added as needed), so now people just need to write the examples and explanations in a friendly way.  With a project like this, there's no reason to "hope" for anything; you can simply _do_ it.  The user guide repository is here: https://github.com/jestin/x16-user-guide



 

Thanks for the response and the link to the repository. I think the best I can do in this section is attempt to use it to learn about X16 sound programming, as I've mentioned I've got low to no musical talent/background at all. I'll look at other sections where my programming and instructional experience would be of use. LaTeX presents a learning curve, but I'm sure I can climb that hill as it's technical and the web is fully of help for it. I've avoided doing any VERA programming (sound or graphics) because the investment cost is beyond what I'm willing to pay at the moment. 

I agree that good basic commands perhaps could make sound manageable/explainable to the lower end of your target (the 6-8 year olds.) Not being an early education expert (primary teacher) I can only believe it would be a stretch. Sound and graphics are tangible results that  motivate youth to explore/play with programming; calculating π to the 100th place not so much. I wonder if the topic is something that might be beyond what can be explained/taught. As you've suggested 

On 12/12/2022 at 8:08 PM, Jestin said:

Sound is just too complicated to do anything at a beginner level.  The proposed BASIC commands would fix that.

which I fully support. Perhaps a caveat at the start of the sound section with a "you must be this tall to ride" type warning with some references to programming concepts one must know before beginning might be in order. 

On 12/15/2022 at 11:16 PM, Edmond D said:

LaTeX presents a learning curve,

Solution?

https://en.wikipedia.org/wiki/LyX

On 12/15/2022 at 11:13 PM, neutrino said:

Solution?



https://en.wikipedia.org/wiki/LyX

Thanks - I'll have to look into it as I climb the LaTeX curve.

 

One thing I'd like to point out is that the FMINST command represents a gateway to "intermediate mode" sound programming for the YM as well. If there is a set of FM instruments built into the ROM and an API to activate them on voices, you can use just this one BASIC command and then use your own routines for playing back music / notes - no need to use the "FMNOTE" command per-se. Also, there will be the corresponding asm routines under the hood, and I plan to expose those and other routine functions (such as chip init) in an API on the sound bank. Assembly, C, Prog8, etc - all of these programming platforms will be able to make use of this as well.

To me, the underlying premise that I want to drive home is that if you take the task of setting up instruments off of the table, then what remains of the YM is absurdly simple for playing back music. There are literally only 2 registers that you need to understand. (3 if you count the "key fraction" register for fine-tuning / pitch bending)

So what's the plan here? Jestin and I are working together to produce a proposed PR for the ROM in the hopes that this functionality may be deemed useful enough for inclusion. By this, I mean that we're going to code it up as a set of ROM routines, patches, and BASIC commands to access the code. Our plan is to focus primarily on the YM2151 as the target chip and forego the PSG for now, and maybe extend functionality for the PSG in the future if the sound bank is adopted.

I'd like to suggest adding some PCM audio samples as well: a snare drum sample, for instance, maybe a high hat and kick as well.

@Ed Minchau

Is there any suitable binary storage facilities in BASIC for this? I guess "DATA 1,2,3,4" statements won't do ?

Maybe something like:

BLOAD "BIG DRUM", B0, P49152

BPLAY B0, P49152

But BLOAD will likely become messy quickly as it put the burden to keep track of all memory allocations on the user. So perhaps some separate named allocation scheme would be useful?

NLOAD "BIG DRUM" "BDRUM" (allocates first suitable memory location and names it BDRUM)

NPLAY "BDRUM" (user don't have to keep track of where stuff is allocated)

NDEL "BDRUM" (removes the memory object)

If the same space as Basic program variables is used. All samples will be lost whenever the program is changed?

Could perhaps also be used for graphics?

NLOAD "PARROT.BIN" "PARROT"

NSHOW "PARROT"

NDEL "PARROT"