Assembler Programming Problem

[t0nyt]

I was wondering if anyone can give me any advise on the following m/c problem, because I'm obviously missing something, please?

I've created an SBASIC extension called i2c_say
I want to be able to call it in 3 ways
i2c_say("<some text>")
i2c_say(<integer>)
i2c_say(<integer>,<integer>)

When it's called I check if the first parameter is a string, this seems to work, and if it's not a string it then checks for the first parameter being a number again this seems to work (or at least it's accepted)

But when I try the last version, i2c_say(<integer>,<integer>), when I press enter I just get "bad line" at the command line

I didn't think that sbasic would be checking the number of parameters, but I guess I'm wrong please?

Any thoughts please?

Many thanks
Tony

[t0nyt]

It seems it does like i2c_say 1,1 (i.e. no brackets)

Is it really as simple as that please?

Thanks
Tony

[Dave]

It can be that simple. I used a BASIC once that required a space between every element.

You don't use the parentheses when calling a procedure or function. Only when creating it. I imagine that carries across.

[t0nyt]

It can be that simple. I used a BASIC once that required a space between every element.

You don't use the parentheses when calling a procedure or function. Only when creating it. I imagine that carries across.

Thanks Dave

It's a strange one though because the Minerva I2c_io() uses brackets fine and that has a variable 2 to 4 parameters

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

Many thanks
Tony

[t0nyt]

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

[NormanDunbar]

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 maths stack tidy. Procedures let you run riot and tidy up for you, functions mean you have control!

If you are reading my Assembly Language book, ignore anything that says what the value of A1 is in entry. That applies to the BBQL only. (I might have updated it to correct for SMSQ, I know I've done the experiments and documented it on the forum, somewhere!)

Cheers,
Norm.

[t0nyt]

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 maths stack tidy. Procedures let you run riot and tidy up for you, functions mean you have control!

If you are reading my Assembly Language book, ignore anything that says what the value of A1 is in entry. That applies to the BBQL only. (I might have updated it to correct for SMSQ, I know I've done the experiments and documented it on the forum, somewhere!)

Cheers,
Norm.

Thanks Norm

I'll leave it as a Procedure for now then and see if that presents any issues in normal use once I've got it all running

I have about 12 functions in the extension but these don't take parameters so was able to copy the code for the return of a value from your book

Many thanks
Tony

[Martin_Head]

If memory serves. Functions in QDOS need parentheses, but in SMSQ/E does not.

[t0nyt]

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