[Coco] Re: Technical: PIA Help

Robert Gault robert.gault at worldnet.att.net
Tue Dec 6 17:59:08 EST 2005


That's a hard question to answer in the context of the game. First, we 
are in "data direction" mode for the snippet below. Second, the joystick 
switches could still be read with no keyboard columns active.

I don't know what will happen under #1 and the only way to find out 
would be to write a small ml program to test the condition.

Brad Grier wrote:
> I took a quick look at the source but got hung up on the $ff03 usage. 
> Okay...assuming that's a bug. I don't understand the following:
> 
> lda #$ff
> sta $ff02         normal, all output
> lda $ff00
> coma
> anda #%011111111  ignore joystick comparator
> bne $cf2f         go if key press
> 
> What does lda $ff00 return if a key is down? Since we previously stored 
> $ff at $ff02, we aren't asking for a specific keyboard column to be 
> examined. Does it return any key regardless of column?
> 
> Anyway, I'm trying to figure this out between work and other things. 
> Maybe tonight I'll get out the CoCo and see what's what.
> 
> Thanks,
> 
> Brad
> 
> 
> 
> Robert Gault wrote:
> 
>> You will never determine what is going on without looking at the code 
>> in question. Part of what you report comes from
>>
>> $cf01 extends to about $cffe
>> pshs d,x,y,u
>> leas -5,s
>> clr $ff02
>> lda $ff03
>> anda #%11111011   data direction register
>> sta $ff03
>> lda #$ff
>> sta $ff02         normal, all output
>> lda $ff00
>> coma
>> anda #%011111111  ignore joystick comparator
>> bne $cf2f         go if key press
>> set some data and at $cfde deactivate data direction
>>
>> $cf2f
>> leau $da23,pcr
>> ldx #$601
>> clr 2,s
>> clr 4,s
>> lda #%10000000
>> sta $ff02         only MSB is output
>> lda $ff00
>> bita #%01000000   check for shift keys
>> bne $cf48
>> inc 4,s
>> $cf48 lda #1
>> sta $ff02
>> 10 nops to wait
>> lda $ff00
>> coma
>> anda #%01111111
>> ldb 2,s
>> cmpb #7
>> beq $cf6b
>> cmpb #4
>> beq $cf6b
>> cmpb #3
>> bne $cf6d
>> $cf6b anda #%00111111
>> $cf6b sta ,s
>> eora ,x
>> anda ,s
>> beq $cfb0
>> ldb #1
>> $cf77 lsra
>> bcs $cf7d
>> aslb
>> bra $cf77
>> $cf7d andb ,s
>> stb ,s
>> lda #15
>> ldb 2,s
>> mul
>> leau d,u
>> lda ,s
>> lbsr $cc7c
>> ldb #3
>> mul
>> leau d,u
>> lda 4,s
>> lda a,u
>> etc.
>>
>>
>>
>> There does not seem to be any advantage to activate data direction and 
>> this is normally only done for $FF02 after a cold start. I think that 
>> the entire business is an error and more likely is that bit3 was 
>> intended. That would change the MSB of the MUX line which might make 
>> some sense.
>>
>> Brad Grier wrote:
>>
>>> I added a few println calls to Mocha at the memory locations in 
>>> question. This is what happens at those addresses during a Tetris 
>>> interrupt.
>>>
>>> I'm guessing some of the peek return values aren't right but I'm 
>>> displaying what Mocha thinks the result should be.
>>>
>>> The big question: What's going on with the peek and pokes at $ff03?
>>>
>>> fire interrupt
>>> poke ff02: ff
>>> peek ff00= ff
>>> poke ff02: 0
>>> peek ff03= b5
>>> poke ff03: b1 (ff02 data direction bit=0)
>>> poke ff02: ff
>>> peek ff00= ff
>>> poke ff02: ff
>>> peek ff03= 31
>>> poke ff03: 35 (ff02 data direction bit=1)
>>> poke ff02: ff
>>> peek ff02= resets field sync IRQ flag
>>> fire interrupt
>>> etc, etc, etc, etc
>>>
>>> Maybe I need to hook up my coco and figure out how to use EDTASM again.
>>>
>>> Brad
>>>
> 
>>
> 
> 



More information about the Coco mailing list