Assembler Programming Problem

[t0nyt]

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 on the stack

In isolation both of my GTSTR and GTINT routines work fine, but not one after the other

[t0nyt]

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 numeric parameter(s), but it does work if GTSTR isn't called first

[t0nyt]

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 "16")

|'m assuming that's why I can't get the first parameter then with GTINT, because it's already been processed?

EDIT: I also tried calling GTINT first, but that doesn’t work either (breaks reading the text)

Many thanks
Tony

[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

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 1(a6,a3.l) - bits 0--3 determine the type of each parameter. You should be able to fetch them one by one if necessary.

I've never written a procedure which can take different parameter types on different calls, so I might be wrong. Worth an experiment maybe?

HTH

Cheers,
Norm.

Hi Norm,

I was looking at page 79, because I'm working out how to use bv_chrix for my buffer, and you put 2 into D1 when calling it, but shouldn't this be D0 please?

EDIT: I'm confused. searches on here say D1, but the QL Technical Guide's I have say D0

Many thanks
Tony

[NormanDunbar]

Hi Tony,

From Wolfgangs current docs for SMSQ and QDOS:

Space may be allocated on the stack by calling the vectored routine QA.RESRI: the number of bytes required is given in D1.L; D0 to D3 are smashed by the call. Since both the stack within the S*Basic area and the S*Basic area itself may move during a call, the stack pointer should be saved in BV_RIP(A6) before the call, and restored from BV_RIP(A6) after the call has been completed. The routine ensures that the restored value will be correct.

QA.RESRI is the same as BV_CHRIX. So D1.L is where the space you require is put prior to calling the vector to do the allocation.

HTH.

Cheers,
Norm.

[t0nyt]

Thanks Norm, D1 it is then!

Many thanks
Tony

[tofro]

In a BASIC Extensionion you should also be able to safely use the BASIC buffer.

[NormanDunbar]

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

I've had a very quick and dirty play with this -- I still don't have an office set up yet so this was "laptop on knee" which does my back no good at all!

So, I wrote a test procedure:

Code: Select all

test
    trap #15
    moveq #0,d0
    rts

The trap #15 jumps into QMON2 provided that QMON2 has already been exected AND TL 14 has been executed. So, a full test looks like this:

Code: Select all

qmon
tl 14
g

test <whatever>: REMark Jumps into QMON 2.

d 0(a6,a3) 1 to display the name table. I record the first four bytes displayed, then "G"

The results:

Code: Select all

Offset x(A6,A3.L)    0  1 2--3     4--7
---------------------------------------
test                00 00 FFFF FF1016A8
test 1234           02 02 FFFF 001016A8
test 12.7           02 02 FFFF 001016A8
test "Hello"        02 01 FFFF 001016AC
test x%             02 03 02C7 001016B0
test fp             02 02 02C6 001016A8
test a$             02 01 02C8 001016BC
test x% + x%        02 03 FFFF 001016D0
test fp * 4         02 02 FFFF 001016D0
test a$ & a$        02 01 FFFF 001016D4
test a$(1)          02 01 FFFF 001016D4
test ram1_          00 02 02C9 001016C0
test_ram1_test_asm  00 02 02CA 001016C8

Adding hash and separators afterwards:

Offset x(A6,A3.L)    0  1 2--3     4--7
---------------------------------------
test #x%            02 83 02C7 001016B0
test x%!            02 43 02C7 001016B0
test x%,            02 13 02C7 001016B0
test x% TO          02 D3 02C7 001016B0

Etc etc etc.

The byte at 1(a6,a3.l) is the one to look at.

Bit 7 = 1, there is a hash in front of the parameter.
Bit 7 = 0, there is no hash.

Bits 6-4 = 0 = No separator after this parameter.
Bits 6-4 = 1 = There's a comma separator after this parameter.
Bits 6-4 = 2 = There's a semicolon separator after this parameter.
Bits 6-4 = 3 = There's a backslash separator after this parameter.
Bits 6-4 = 4 = There's a exclamation mark separator after this parameter.
Bits 6-4 = 5 = There's a "TO" separator after this parameter.


Bits 3-0 = 0 = Null or machine code function call for this parameter.
Bits 3-0 = 1 = String parameter.
Bits 3-0 = 2 = Floating point parameter.
Bits 3-0 = 0 = word integer parameter.

So you can access the lower 4 bits of the byte at 1(a6,a3.l) and test if it is of the required type.

Be aware that you might need to adjust A3 and/or A5 to ensure that you only collect the required parameter(s) of the required type. You can, for example, be passed a string, two words and a float, followed by another string. You would have to adjust A5 to A3 + 8, grab the start, adjust A5 back again then add 16, add 8 to A3 and grab the two word integers, then mess about with A3 and A5 to pull in the float and again, to pull in the final string.

Confusing? You bet, and you would need to be careful about what registers are corrupted by the calls to the parameter fetch routines.


But, I believe this is all moot now as y9u might have trashed your Minerva 2.


Cheers,
Norm.

[t0nyt]

Many thanks for looking into this Norm, much appreciated

Yes, it may well be moot now

Strangely the built-in I2c nvram/rtc works fine still, so I don't understand why the external take-off doesn’t work

Understanding the nuances of electronics is beyond me I’m afraid

[t0nyt]

Looking at Alvaro’s schematic & my spare PCB the SCL/SDA lines seem to come straight off the NVRAM/RTC IC

So I assume it must be this IC that’s failed in some way, despite the fact its own I2c is still working (can set boot parameters and read/write the RTC still)

Later next week maybe I’ll try changing the IC, if I can de-solder it ok