[Coco] Re: PIA keyboard input?

[Rodney V Hamilton]

In article <55D9AEF6-292E-11D8-BC0E-003065E07450 at skwirl.ca>, 
james at skwirl.ca says...
>
>On 7-Dec-03, at 10:02 PM, Robert Gault wrote:
>
>> That's easy to do if you use the correct algorithm. What is equivalent 
>> to rolling a bit? A power of 2 change is the same thing. So, if you 
>> want a zero bit, the loop would be (in Basic)
>>  for i =1 to 8
>>   poke pia, 255-2^(i-1)
>>  next i
>> The above is going to give you 255-1=254=%11111110, 
>> 255-2=253=%11111101, 255-4=251=%11111011, 255-8=247=%11110111, etc.
>
>Which is what I had tried.  However, it seems the store instruction 
>isn't triggering the PIA in MESS.  The ROL does, so I'm guessing it's 
>something related to emulation or timing or something of the like... 
>from what I've heard, it's probably not the emulation... here's the 
>code that reads the row:
>
>        clra
>        std     -21,u   ;movhi: R:d -> -21,u
** this must be a copy of "i"
>        ldd     #1      ;movhi: #1 -> R:d
>        ldx     -21,u   ;movhi: -21,u -> R:x
>                        ;ashlhi: d by x
>        leax    -1,x    ;decr shift count
>        bmi .+6
>        aslb
>        rola
>        bra .-6 ;loop
>        comb            ;comqi: R:b
** this is ~(1<<i)
>        stb     -254    ;movqi: R:b -> -254
** THIS must be the write to 0xFF02
>        ldb     -18,u   ;zero_extendqihi: -18,u -> R:d
>        clra
>        leax    d,u     ;addhi: R:x = R:u + R:d
>        ldb     -256    ;movqi: -256 -> R:b
** and THIS must be the read from 0xFF00
>
>It's taken directly from gcc's output, but should be pretty much the 
>following in C:
>
>       *((unsigned char *)0xFF02) = ~(1<<i);
>       columns[i] = *((unsigned char *)0xFF00);
>
>where i is my loop variable, columns is the array of columns.  However, 
>if I do the following:
>
>       asm( "rol 0xFF02" );
>       columns[i] = *((unsigned char *)0xFF00);
>
>and a ROL instruction is generated, it works... kinda stumped.  I 
>haven't had a chance to test it with a real CoCo, though, only MESS.
>
>I've found gcc does seem to generate a lot of code... my little app to 
>scan the keyboard and print out the matrix of rows and columns takes up 
>about 2-3k.  If I rewrote it in assembly, I could probably halve or 
>even quarter that... but in gcc's defence, it does a lot to make sure 
>it keeps variables in check with registers... if I rewrote the 
>function, I'd probably skip a lot of that.
>
>James

James, does your gcc support the "volatile" keyword?
You should declare all I/O port accesses as volatile
to keep the C compiler's optimizer pass from erasing
all but the first read or last write from the code block.
Or you could step optimization down until the code works.. <wink>

If you're not already doing this, try putting the C code
fragment under consideration into a "stub file" and compile
it to assembly code only.  You can examine the generated code
and modify the C code snippet until gcc gives you something
in asm code that looks like what you intended.

Also, you should declare the I/O addresses themselves as unsigned
(or unsigned volatile) - negative addresses make my brain itch...

Rodney Hamilton