Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #4809 > unrolled thread

IIGS joystick programming?

Back to article view | Back to comp.sys.apple2.programmer

Contents

  IIGS joystick programming? paul.s.macmillan@gmail.com - 2018-10-08 06:57 -0700
    Re: IIGS joystick programming? D Finnigan <dog_cow@macgui.com> - 2018-10-08 16:30 +0000
      Re: IIGS joystick programming? Michael J. Mahon <mjmahon@aol.com> - 2018-10-08 15:25 -0500
        Re: IIGS joystick programming? John Brooks <jbrooks@blueshiftinc.com> - 2018-10-08 19:10 -0700
          Re: IIGS joystick programming? paul.s.macmillan@gmail.com - 2018-10-08 19:17 -0700
            Re: IIGS joystick programming? John Brooks <jbrooks@blueshiftinc.com> - 2018-10-10 07:42 -0700
              Re: IIGS joystick programming? D Finnigan <dog_cow@macgui.com> - 2018-10-10 16:35 +0000
                Re: IIGS joystick programming? paul.s.macmillan@gmail.com - 2018-10-10 10:45 -0700
              Re: IIGS joystick programming? Michael J. Mahon <mjmahon@aol.com> - 2018-10-10 16:26 -0500

#4809 — IIGS joystick programming?

I scanned all my IIGS textbooks and none of them mention the joystick. Is there a new way to read the joystick on the IIGS or is the old PREAD firmware call still the only way to go?  

Also -- not sure how to call (8-bit) firmware routines from a 16-bit (ORCA/C) program... is there anything in print on how to do this? Ideally I could use some inline assembly from ORCA/C to call PREAD.

Ultimately what I'd like to do is work on 2 player games using the joystick and the mouse.

Thanks.

[toc] | [next] | [standalone]

#4810

paul.s.macmillan wrote:
> I scanned all my IIGS textbooks and none of them mention the joystick. Is
> there a new way to read the joystick on the IIGS or is the old PREAD
> firmware call still the only way to go?  

See here: https://macgui.com/usenet/?group=2&id=22257


011- A while ago someone posted about how to read the joystick on  
     a GS in native mode. They said that it was possible to read  
     both paddles at once and therefore get much more accurate  
     readings?  
Only the high bit of these locations is valid. When the high bit of either
location becomes 0 then the corresponding analog input has timed out.  

You will actually get more accurate results by reading them one after the
other with the accumulator set to 8 bits wide and the index registers used
to hold the counts (16 bits wide). This allows for a much faster loop,
giving better resolution. Assuming that this routine is called from full
native mode, the following code will do the trick:  
   

strobe equ $C070 ; analog input timing reset 
pdl0 equ $C064   ; analog input 0 
pdl1 equ $C065   ; analog input 1 

start php        ; save processor status register 
phb              ; and data bank register 
sep #%100000     ; make accumulator 8 bits wide 
lda #0           ; make data bank = 0 
pha 
plb 
ldx #0           ; initialize the counters 
txy 
lda strobe       ; strobe the timing reset 
loop1 inx        ; increment pdl0 count 
lda pdl0         ; is high bit = 0? 
bmi loop1        ; no, keep checking 
lda strobe       ; yes, strobe the timing reset again 
loop2 iny        ; increment pdl1 counter 
lda pdl1         ; is high bit = 0? 
bmi loop2        ; no, keep checking 
plb              ; yes, restore data bank 
plp              ; and processor status register 
rts              ; return to caller (could be RTL) 

Notice that the actual counting loops are only 9 cycles long. This gives the
best possible resolution. You will need your counters to be 16 bits wide as
the results will easily overflow the capacity of an 8 bit counter.  
Using memory locations as counters will only serve to slow the counting loop
down. If X and Y contain valid data before entry, you will need to save them
off to the stack and pull them back in after interpreting the joystick
results. I have used this exact method to read the analog inputs on my
Science Toolkit box which connects to the joystick port.  

The results have been extremely accurate (much more than would be needed for
a game which reads the joystick). --tgeer@pro-gumbo.cts.com (System
Administrator)  

[toc] | [prev] | [next] | [standalone]

#4812

D Finnigan <dog_cow@macgui.com> wrote:
> paul.s.macmillan wrote:
>> I scanned all my IIGS textbooks and none of them mention the joystick. Is
>> there a new way to read the joystick on the IIGS or is the old PREAD
>> firmware call still the only way to go?  
> 
> See here: https://macgui.com/usenet/?group=2&id=22257
> 
> 
> 011- A while ago someone posted about how to read the joystick on  
>      a GS in native mode. They said that it was possible to read  
>      both paddles at once and therefore get much more accurate  
>      readings?  
> Only the high bit of these locations is valid. When the high bit of either
> location becomes 0 then the corresponding analog input has timed out.  
> 
> You will actually get more accurate results by reading them one after the
> other with the accumulator set to 8 bits wide and the index registers used
> to hold the counts (16 bits wide). This allows for a much faster loop,
> giving better resolution. Assuming that this routine is called from full
> native mode, the following code will do the trick:  
>    
> 
> strobe equ $C070 ; analog input timing reset 
> pdl0 equ $C064   ; analog input 0 
> pdl1 equ $C065   ; analog input 1 
> 
> start php        ; save processor status register 
> phb              ; and data bank register 
> sep #%100000     ; make accumulator 8 bits wide 
> lda #0           ; make data bank = 0 
> pha 
> plb 
> ldx #0           ; initialize the counters 
> txy 
> lda strobe       ; strobe the timing reset 
> loop1 inx        ; increment pdl0 count 
> lda pdl0         ; is high bit = 0? 
> bmi loop1        ; no, keep checking 
> lda strobe       ; yes, strobe the timing reset again 
> loop2 iny        ; increment pdl1 counter 
> lda pdl1         ; is high bit = 0? 
> bmi loop2        ; no, keep checking 
> plb              ; yes, restore data bank 
> plp              ; and processor status register 
> rts              ; return to caller (could be RTL) 
> 
> Notice that the actual counting loops are only 9 cycles long. This gives the
> best possible resolution. You will need your counters to be 16 bits wide as
> the results will easily overflow the capacity of an 8 bit counter.  
> Using memory locations as counters will only serve to slow the counting loop
> down. If X and Y contain valid data before entry, you will need to save them
> off to the stack and pull them back in after interpreting the joystick
> results. I have used this exact method to read the analog inputs on my
> Science Toolkit box which connects to the joystick port.  
> 
> The results have been extremely accurate (much more than would be needed for
> a game which reads the joystick). --tgeer@pro-gumbo.cts.com (System
> Administrator)  
> 
> 

Of course, the worst case time is determined only by the joystick timers,
and faster code only increases the resolution. 

For game purposes, an 8-bit result is fine, so the best way to read both
axes is to trigger the timers *once* and read both axes in parallel. This
achieves the best possible speed by getting both 8-bit values with a single
timer trigger. 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#4814

On Monday, October 8, 2018 at 1:25:41 PM UTC-7, mjm...@aol.com wrote:
> D Finnigan <dog_cow@macgui.com> wrote:
> > paul.s.macmillan wrote:
> >> I scanned all my IIGS textbooks and none of them mention the joystick. Is
> >> there a new way to read the joystick on the IIGS or is the old PREAD
> >> firmware call still the only way to go?  
> > 
> > See here: https://macgui.com/usenet/?group=2&id=22257
> > 
> > 
> > 011- A while ago someone posted about how to read the joystick on  
> >      a GS in native mode. They said that it was possible to read  
> >      both paddles at once and therefore get much more accurate  
> >      readings?  
> > Only the high bit of these locations is valid. When the high bit of either
> > location becomes 0 then the corresponding analog input has timed out.  
> > 
> > You will actually get more accurate results by reading them one after the
> > other with the accumulator set to 8 bits wide and the index registers used
> > to hold the counts (16 bits wide). This allows for a much faster loop,
> > giving better resolution. Assuming that this routine is called from full
> > native mode, the following code will do the trick:  
> >    
> > 
> > strobe equ $C070 ; analog input timing reset 
> > pdl0 equ $C064   ; analog input 0 
> > pdl1 equ $C065   ; analog input 1 
> > 
> > start php        ; save processor status register 
> > phb              ; and data bank register 
> > sep #%100000     ; make accumulator 8 bits wide 
> > lda #0           ; make data bank = 0 
> > pha 
> > plb 
> > ldx #0           ; initialize the counters 
> > txy 
> > lda strobe       ; strobe the timing reset 
> > loop1 inx        ; increment pdl0 count 
> > lda pdl0         ; is high bit = 0? 
> > bmi loop1        ; no, keep checking 
> > lda strobe       ; yes, strobe the timing reset again 
> > loop2 iny        ; increment pdl1 counter 
> > lda pdl1         ; is high bit = 0? 
> > bmi loop2        ; no, keep checking 
> > plb              ; yes, restore data bank 
> > plp              ; and processor status register 
> > rts              ; return to caller (could be RTL) 
> > 
> > Notice that the actual counting loops are only 9 cycles long. This gives the
> > best possible resolution. You will need your counters to be 16 bits wide as
> > the results will easily overflow the capacity of an 8 bit counter.  
> > Using memory locations as counters will only serve to slow the counting loop
> > down. If X and Y contain valid data before entry, you will need to save them
> > off to the stack and pull them back in after interpreting the joystick
> > results. I have used this exact method to read the analog inputs on my
> > Science Toolkit box which connects to the joystick port.  
> > 
> > The results have been extremely accurate (much more than would be needed for
> > a game which reads the joystick). --tgeer@pro-gumbo.cts.com (System
> > Administrator)  
> > 
> > 
> 
> Of course, the worst case time is determined only by the joystick timers,
> and faster code only increases the resolution. 
> 
> For game purposes, an 8-bit result is fine, so the best way to read both
> axes is to trigger the timers *once* and read both axes in parallel. This
> achieves the best possible speed by getting both 8-bit values with a single
> timer trigger. 
> 
> -- 
> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

Yes, the best optimization for reading Apple II joysticks is to trigger the strobe only once and read both timers in 2.76ms instead of triggering twice and taking 5.52ms.

See Sather for a a 6502 single-strobe 2.76ms read routine.

The drawback of a single-strobe read is that you get half-resolution due to the loop taking 22 cycles instead of 11.

Half resolution was fine for my Apple II & GS games, but if you want full-resolution on the IIGS, you can read both joysticks every 11 cycles @ 1MHz using unrolled:
 LDA $64 ;4 cycles: 16-bit read of $C064 & $C065
 AND #$8080 ;3 cycles
 PHA ;4 cycles

Then go to fast speed and sum the 255x words via unrolled dpage ADC.

This reads both joysticks at full 0-255 precision in about 3.2ms, but does not early-out.

It's possible to read the joysticks via fast (2.8MHz) CPU speed, but then you'd have to worry about CPU accelerators messing up the timing.

-JB
@JBrooksBSI

[toc] | [prev] | [next] | [standalone]

#4815

So does the code posted so far work on an accelerated IIGS? (I have a ZipChip at 8 MHz).... or do I just need to scale my reading based on a speed-dependent factor. 

The range of 0-255 would be fine in my setting.

Thanks.

[toc] | [prev] | [next] | [standalone]

#4818

On Monday, October 8, 2018 at 7:17:49 PM UTC-7, paul.s.m...@gmail.com wrote:
> So does the code posted so far work on an accelerated IIGS? (I have a ZipChip at 8 MHz).... or do I just need to scale my reading based on a speed-dependent factor. 
> 
> The range of 0-255 would be fine in my setting.
> 
> Thanks.

You should slow to 1 MHz during paddle reads:

 LDA $C036
 PHA
 STZ $C036

... read paddle(s) ...

 pla
 sta $C036

-JB
@JBrooksBSI

[toc] | [prev] | [next] | [standalone]

#4819

John Brooks wrote:
> On Monday, October 8, 2018 at 7:17:49 PM UTC-7, paul.s.m...@gmail.com
> wrote:
>> So does the code posted so far work on an accelerated IIGS? (I have a
>> ZipChip at 8 MHz).... or do I just need to scale my reading based on a
>> speed-dependent factor.
>> 
>> The range of 0-255 would be fine in my setting.
>> 
>> Thanks.
> 
> You should slow to 1 MHz during paddle reads:
> 

These two posts from David Empson may also prove useful:

https://macgui.com/usenet/?group=2&id=7287#msg
https://macgui.com/usenet/?group=2&id=7289#msg

He refers to the CPS FOLLOW option on the Zip chip.

-- 
]DF$
The New Apple II User's Guide:
https://macgui.com/newa2guide/

[toc] | [prev] | [next] | [standalone]

#4820

Thanks for the help everybody!  Hopefully someday I'll have a killer two-player game (mouse, joystick) to post!!

-Paul

[toc] | [prev] | [next] | [standalone]

#4821

John Brooks <jbrooks@blueshiftinc.com> wrote:
> On Monday, October 8, 2018 at 7:17:49 PM UTC-7, paul.s.m...@gmail.com wrote:
>> So does the code posted so far work on an accelerated IIGS? (I have a
>> ZipChip at 8 MHz).... or do I just need to scale my reading based on a
>> speed-dependent factor. 
>> 
>> The range of 0-255 would be fine in my setting.
>> 
>> Thanks.
> 
> You should slow to 1 MHz during paddle reads:
> 
>  LDA $C036
>  PHA
>  STZ $C036
> 
> ... read paddle(s) ...
> 
>  pla
>  sta $C036
> 
> -JB
> @JBrooksBSI
> 

The Zip Chip has logic (option?) to slow down for several milliseconds when
the paddle trigger is accessed. 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web