The Sinclair QL Forum

I decided to put the new extension to the test

So added the following code snippet to Dilwyn's port of the Dracula adventure and replaced most of the "PRINT #0," with "PRINT0" and it works a treat speaking all the phrases until I got bitten and killed by Dracula! (if making a proper version I'd ...

It seems if you try and read a string parameter before then trying to read numeric value(s) the first number gets read as a string


Really? I'm surprised!

You might find section 7.5.2, table 7.7 and section 7.6 in the 2020 edition of my book useful. You can determine each parameter type from ...

After doing just GTSTRG, but with 2 numeric parameters (in this case 16,1), the name table shows first entry as a numeric on the RI stack and the 2nd parameter as type $0203 so not on RI stack

When I look at the RI stack the number 16 is actually a string (2 bytes of length & ascii characters for ...

When I debug, the parameter(s) don't appear on the name table A6,A3.l until after GTSTR or GTINT are called

So that rules out checking the parameter type BEFORE making a GTSTR/GTINT call

And once I make a GTSTR call, and there's not a string parameter, the call to GTINT doesn't work to get the ...

Hi Rich

I came across this when I was trying to get Night Nurse running on Minerva too

Sorry, I probably should have mentioned it!

IIRC JS doesn’t do anything with the 2nd range, just ignores it?

Will take a look, thanks Norm

What I was doing was calling GTSTR, check for $0101 on the name table

If there was a match then I would use the string

If it wasn’t a match I’d then call GTINT but that didn’t return the 1 or 2 integers, but debugging showed the ascii version of the 1st integer value ...

Have got the i2c_say text-to-speech extension nearly completed

I had to split the numeric parameter commands into a separate command i2c_say_cmd (sorry Dave, but I’ll revisit this later)

The only thing still to do is to replace the DS.B work buffer with using space on the maths stack!

I think a ...

It seems if you try and read a string parameter before then trying to read numeric value(s) the first number gets read as a string

So my plan to have
i2c_say("<text>")
i2c_say 16
i2c_say 16,1

Won't work

Will have to split them into 2 procedures I guess

Hi Tony,

Maybe it's because that's a function rather than a procedure

This is exactly the solution. Functions need parentheses, procedures don't and throw a "Bad Line" error if you use them.

If you change your procedure to a function, you'll need to be very very careful about keeping the ...

It’s occurred to me that the extension might be better off as a function anyway so it can return just a status rather than an SBASIC error, in most cases