Adventures with I2C & Minerva Mk2

Anything QL Software or Programming Related.
User avatar
t0nyt
QL Wafer Drive
Posts: 1195
Joined: Wed Nov 22, 2023 6:46 pm
Location: UK

Re: Adventures with I2C & Minerva Mk2

Post by t0nyt »

Have decided to start on the first SuperBASIC assembler extension, have chosen the Speech synthesis module as it gives the best feedback on whether it's working as planned

I was wondering if anyone has any comments/suggestions/etc. on my proposed new keywords, or anything else, please?

Have chosen i2c_say as the root of the commands

Code: Select all

When extension loads?
Check &40 responds on i2c bus

i2c_say_init 		Just sends $AA
Also call at load?

i2c_say("text")
Options below can specified in string e.g. "[v9][s2]Hello"

i2c_say_stop		Stop current speech
i2c_say_pause		Pause current speech
i2c_say_resume		Resume paused speech

r=i2c_say_status() 	Check chip status
returns $41 - frame received ok
	$4E - chip busy
	$4F - chip idle

i2c_say_reset		[d] & set defaults below

i2c_say_volume(0 to 9)  [v4]
i2c_say_speed(0 to 10)  [s5]
i2c_say_tone(0 to 10)   [t5]
i2c_say_delay(ms) 	[p0]     
i2c_say_lang(0,1,2)	[g2]
I2c_say_how(0,1,2)	[h2]
i2c_say_mode(0 to 6)	[e0]
Many thanks
Tony


User avatar
t0nyt
QL Wafer Drive
Posts: 1195
Joined: Wed Nov 22, 2023 6:46 pm
Location: UK

Re: Adventures with I2C & Minerva Mk2

Post by t0nyt »

I was wondering, as they can all be incorporated into the "text" at any point anyway, whether to just scrap all the option keywords (like volume, tone, etc.) and just have an i2c_say_help command that lists all the options (and valid values)?


User avatar
Dave
SandySuperQDave
Posts: 2869
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Adventures with I2C & Minerva Mk2

Post by Dave »

As i2c_ and say_ appear in *every* command it seems either one or the other is redundant. Is the i2c aspect important to the functionality? I'd personally drop the i2c_ part for clarity, if only because there are no other BASIC keywords with numbers in them, and I can't think of any off the top of my head that have two underscores in them. It just seems overworked.


User avatar
t0nyt
QL Wafer Drive
Posts: 1195
Joined: Wed Nov 22, 2023 6:46 pm
Location: UK

Re: Adventures with I2C & Minerva Mk2

Post by t0nyt »

Dave wrote: Fri Sep 12, 2025 6:18 pm As i2c_ and say_ appear in *every* command it seems either one or the other is redundant. Is the i2c aspect important to the functionality? I'd personally drop the i2c_ part for clarity, if only because there are no other BASIC keywords with numbers in them, and I can't think of any off the top of my head that have two underscores in them. It just seems overworked.
There's I2C_IO, so I thought "I2C_" was a good way to prefix all my own extensions to make it clear they are i2c only and ensure no clash with anything else that might exist?

The "say" was because this is the Text-to-Speech extension e.g. i2c_say("Hello World")

I could go with I2C_SAYINIT I guess for the others to keep the amount of underscores down to 1

I'm really not sure as I hadn't even considered multiple underscores would be seen as an issue

Thanks
Tony


User avatar
Dave
SandySuperQDave
Posts: 2869
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Adventures with I2C & Minerva Mk2

Post by Dave »

I think it's more to do with the fixed capitalization of BASIC keywords. Seeing things turned into I2C_Say_Resume or etc..... It does seem like Sinclair put a lot of effort (even if accidentally) into their keyword design. The command says only what it needs to. Capitalization was used carefully to communicate not just the keyword but the abbreviation of it, eg: DEFine PROCedure expanded from DEF PROC.

With how BASIC keywords are parsed, alas, there isn't a universal handler for the I2C command, where SAY could be the first argument. You're adding I2C_Say with arguments. Original SuperBASIC keywords sometimes has _i or _o extensions as part of the keywords (mostly in TT toolkits) but natively sometimes made the IN or OUT selection an argument, not the keyword itself.

I know it's petty. I don't have a cop badge. No "respect my authoritAAAH!" I simply think if you're creating a keyword and others might use it, a certain degree of thoughtfulness should go into the command structure. The simple fact you asked out thoughts tells us it is on your mind.

A bunch of keywords handled separately doesn't feel as nice as having a shorter, more global command with the variations being hung off the keyword in the first argument. It keeps KEYWORD listings crisp. It makes for a more unified and structured approach to creating new functionality. It also keeps the BASIC keywords linked list shorter so BASIC runs more quickly. I'm a little OCD about these things, I guess. :D It's coming from a good place, I promise!

I supposed that if you asked for opinions about your keywords you'd be open to all feedback. Even the useless, lame, petty or OCD feedback :D


CRaKeD - The Campaign for Rational Keyword Design!
Founding and only member ever, me :P


Post Reply