Kernal & BASIC sound API for the ROM - ideas?

[rje]

On 12/9/2022 at 11:44 AM, TomXP411 said:

As to expanding the language - the problem is that the token table is in ROM. So you can't modify it at runtime without pushing that out to RAM and decreasing the amount of memory available for programs. I can think of a few ways around that, however, and maybe I'll suggest something. The simplest way would be to create an "escape" token, which basically tells the interpreter "the next byte is a custom token" and hand that off to user code for parsing.

That sounds right to me.  "Hey, this is a user command, jump to the user vector stored here..."

[neutrino]

@TomXP411 Interesting analyze.

Maybe numeric literals can be turned into internal variables on-the-fly so as to keep the user interface intact but get a speed increase?

The variable lookup table perhaps could make use of hash and tree techniques to gain speed?

As for expansion I think something like a jump table hook at the token level would be useful such that the interpreter can be made to call a specific function first or when it can't find any matching token depending on configuration bits. Or simply copy a token table jump table to RAM and then use that. Such that other add-ons can simply modify said table. Enabling extensions to Basic to take precedence over builtin tokens.

Also considering poorly implemented commands, maybe there is a gain to implement a CBM Basic compatible Basic with new code?

[TomXP411]

On 12/9/2022 at 12:39 PM, neutrino said:

@TomXP411 Interesting analyze.



Maybe numeric literals can be turned into internal variables on-the-fly so as to keep the user interface intact but get a speed increase?



The variable lookup table perhaps could make use of hash and tree techniques to gain speed?



As for expansion I think something like a jump table hook at the token level would be useful such that the interpreter can be made to call a specific function first or when it can't find any matching token depending on configuration bits. Or simply copy a token table jump table to RAM and then use that. Such that other add-ons can simply modify said table. Enabling extensions to Basic to take precedence over builtin tokens.



Also considering poorly implemented commands, maybe there is a gain to implement a CBM Basic compatible Basic with new code?

Feel free to search existing threads on those topics. We've actually discussed them in the past. The simple fact is - nobody here has the time and/or specific experience to do the work. I certainly can't do it, as I'm already working full time plus, and most of the other people here with the kind of experience needed are also already working full time and working on other parts of the project. 

[Edmond D]

On 12/7/2022 at 10:07 AM, Jestin said:

I really like the idea of being able to hand children a manual have let them play around with sound.  For that purpose, I'm obviously in favor of the BASIC commands.

I'm also in favour of basic like commands - consider myself as a child when it comes to making music.

In the Vic-20 example it at least has some UI, so that I can see what I'm doing (playing with) - choosing 1 of 4 voices modifying what pitch to put int that voice.  I believe the manual explains what voice is, but to a "lay child" a voice is what one speaks with. Remember that the Vic 20 had to introduce computers,  programming and BASIC to the mass consumer market, all under the guise of the "friendly computer." 

I can't get any musical idea of the current example from the X16 listing. It looks like it loads some magic bytes into magic registers. It's almost machine code - placing values in memory locations. Perhaps the text in the document leading to this example might explain it better than the code does. I hope it's just one of many examples that are explained in the documentation.

 

In the third example the proposed BASIC commands seem to make sense to me, as the naming of them is descriptive. Having commands means that they can be looked up in a manual for what each parameter means. Hopefully it eventually gets supported in the 1.1 ROMs after the X16 releases. That would be something for the children, like myself.



 

[neutrino]

On 12/13/2022 at 1:57 AM, Edmond D said:

under the guise of the "friendly computer."

Yes.. the magic poke & peek. Completely intuitive ?

 

[Jestin]

On 12/12/2022 at 6:57 PM, Edmond D said:

Perhaps the text in the document leading to this example might explain it better than the code does. I hope it's just one of many examples that are explained in the documentation.

My example from above is from my crowd sourced user guide, and is not official an any capacity.  If I knew that there _was_ going to be an official user guide, I'd kill my project right now to avoid the confusion.  But sadly, I think that's one of the things that's fallen to the wayside as the project has evolved.

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

I understand that not everyone is comfortable with LaTex (I know I'm not), but I'm willing to take unformatted pull requests and add the formatting on my own.  With most aspects, I believe we are ready to start writing chapters.  With sound, I feel the user guide has highlighted a usability issue with BASIC.  Sound is just too complicated to do anything at a beginner level.  The proposed BASIC commands would fix that.

[ZeroByte]

On 12/12/2022 at 6:57 PM, Edmond D said:

I can't get any musical idea of the current example from the X16 listing. It looks like it loads some magic bytes into magic registers. It's almost machine code - placing values in memory locations. Perhaps the text in the document leading to this example might explain it better than the code does. I hope it's just one of many examples that are explained in the documentation.



 

In the third example the proposed BASIC commands seem to make sense to me, as the naming of them is descriptive. Having commands means that they can be looked up in a manual for what each parameter means. Hopefully it eventually gets supported in the 1.1 ROMs after the X16 releases. That would be something for the children, like myself.

The "inscrutable code" example is a combination of two examples from the x16-docs chapter on audio programming. The x16-docs repo is primarily reference document, but I did threw a little bit of tutorial language into the end of the "sound programming" chapter. Even so - the DATA statements are presented as a set of magic numbers that aren't explained. Well, it would be more accurate to say that the individual values themselves are not explained. What they are (collectively) IS explained. Those are the 26 bytes of "patch configuration data" that I referred to earlier in this thread. Think of those as the "marimba" button on the music keyboard. FMINST would load those bytes into the YM from a bank in ROM. (replacing the entire section of code with the DATA statements and the loop that pokes them into the YM). FMPAT would load a set of patch bytes from some place in RAM that you specify instead of using the instruments provided in ROM.

The rest of the program, essentially lines 100+ are the actual note playing, and would be explained completely in the accompanying text.

I chose to use "magic values" for instrument configs in the documentation because FM instrument design theory is its own rabbit hole. It's better to just assume a configured instrument and start explaining how to play notes after that.

[ZeroByte]

On 12/12/2022 at 6:57 PM, Edmond D said:

I can't get any musical idea of the current example from the X16 listing. It looks like it loads some magic bytes into magic registers. It's almost machine code - placing values in memory locations. Perhaps the text in the document leading to this example might explain it better than the code does. I hope it's just one of many examples that are explained in the documentation.



 

In the third example the proposed BASIC commands seem to make sense to me, as the naming of them is descriptive. Having commands means that they can be looked up in a manual for what each parameter means. Hopefully it eventually gets supported in the 1.1 ROMs after the X16 releases. That would be something for the children, like myself.

The "inscrutable code" example is a combination of two examples from the x16-docs chapter on audio programming. The x16-docs repo is primarily reference document, but I did threw a little bit of tutorial language into the end of the "sound programming" chapter. Even so - the DATA statements are presented as a set of magic numbers that aren't explained. Well, it would be more accurate to say that the individual values themselves are not explained. What they are (collectively) IS explained. Those are the 26 bytes of "patch configuration data" that I referred to earlier in this thread. Think of those as the "marimba" button on the music keyboard. FMINST would load those bytes into the YM from a bank in ROM. (replacing the entire section of code with the DATA statements and the loop that pokes them into the YM). FMPAT would load a set of patch bytes from some place in RAM that you specify instead of using the instruments provided in ROM.

The rest of the program, essentially lines 100+ are the actual note playing, and would be explained completely in the accompanying text.

I chose to use "magic values" for instrument configs in the documentation because FM instrument design theory is its own rabbit hole. It's better to just assume a configured instrument and start explaining how to play notes after that.

[ZeroByte]

On 12/12/2022 at 6:57 PM, Edmond D said:

I can't get any musical idea of the current example from the X16 listing. It looks like it loads some magic bytes into magic registers. It's almost machine code - placing values in memory locations. Perhaps the text in the document leading to this example might explain it better than the code does. I hope it's just one of many examples that are explained in the documentation.



 

In the third example the proposed BASIC commands seem to make sense to me, as the naming of them is descriptive. Having commands means that they can be looked up in a manual for what each parameter means. Hopefully it eventually gets supported in the 1.1 ROMs after the X16 releases. That would be something for the children, like myself.

The "inscrutable code" example is a combination of two examples from the x16-docs chapter on audio programming. The x16-docs repo is primarily reference document, but I did threw a little bit of tutorial language into the end of the "sound programming" chapter. Even so - the DATA statements are presented as a set of magic numbers that aren't explained. Well, it would be more accurate to say that the individual values themselves are not explained. What they are (collectively) IS explained. Those are the 26 bytes of "patch configuration data" that I referred to earlier in this thread. Think of those as the "marimba" button on the music keyboard. FMINST would load those bytes into the YM from a bank in ROM. (replacing the entire section of code with the DATA statements and the loop that pokes them into the YM). FMPAT would load a set of patch bytes from some place in RAM that you specify instead of using the instruments provided in ROM.

The rest of the program, essentially lines 100+ are the actual note playing, and would be explained completely in the accompanying text.

I chose to use "magic values" for instrument configs in the documentation because FM instrument design theory is its own rabbit hole. It's better to just assume a configured instrument and start explaining how to play notes after that.

[ZeroByte]

sorry for the repeat post - the UI was acting like nothing was happening, yet it was posting and not updating my screen. Also, I can't seem to find the "delete post" option - can one of the mods please delete the duplicates and this post as well?