Assembler Programming Problem

[Pr0f]

If the on board RTC is working - then the I2C from the GAL is working - so it's not your MK2 that's gone duff.

[t0nyt]

If the on board RTC is working - then the I2C from the GAL is working - so it's not your MK2 that's gone duff.

I’ve replaced all the cables and devices & vcc/gnd are good but only the NVRAM/RTC respond/found

The external pins for data/clock run directly off 2 pins of the PCF8583 RTC so in my mind this IC could be damaged?

[Pr0f]

That chip is just a another 'target' for the I2C bus to find - so the fact you can read from that chip suggests the issue lies with either the pins for the I2C output, the resistors R1 and R2 - the 2K2 resistors, or the small PCB track that exists between the connection on the NVRAM/Clock chip and the pins for external devices.

I suspect what may have happened is that connecting to these pins on and off may have caused mechanical damage on the PCB.

[t0nyt]

Will check continuity between IC legs and the pins to start with then

Odd thing is, if it’s mechanical failure, is that yesterday was the first time I’d unplugged/re-plugged cables directly to the pins since I first fitted it as I use an external connector

I guess the other possibility is a failure of my soldering!

[Pr0f]

It might be worth 're sweating' the joints in that case - it could just be a dry joing on that 5 pin header.

[t0nyt]

It might be worth 're sweating' the joints in that case - it could just be a dry joing on that 5 pin header.

Looks like a duff solder joint on the CLK pin, now to find the time to re-solder it

Many thanks
Tony

[t0nyt]

Managed to look at it before our visitors arrive and working again now. Thanks Pr0f

Many thanks
Tony

[Pr0f]

Managed to look at it before our visitors arrive and working again now. Thanks Pr0f

Many thanks
Tony

You're more than welcome - it's all helping our community along - and the I2C area with Minerva deserves to come out from under the covers again!

You are really making strides in that area!

[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

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 = 3 = word integer parameter. (EDITED I had zero here accidentally!)

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.

I can’t claim I 100% understood the tables but I’ve managed to use the info to make a pre-check 3 instruction bit of code that allows me to scrap i2c_say_cmd and do everything thru i2c_say, further testing will show if it stands up or is too simplistic

EDIT: and I did it after a visit to the pub…

Many thanks
Tony