ProPlay - New 4 button gamepad for TI

[sometimes99er]

Edited August 28, 2013 by sometimes99er

[RXB]

You can write a program in XB for this controller.

 

10 CALL JOYST(1,X,Y)
20 CALL JOYST(2,B2,B3)
30 CALL KEY(1,B1,S)
40 CALL KEY(2,B4,S)

 

in that 4 lines of code you get access to all the buttons on the controller.

X,Y return -4,4 for up,down,let,right

B1 returns 18 for button 1

B2 returns 4 for button 2

B3 returns 4 for button 3

B4 returns 18 for button 4

 

X,Y,B1 are normal joystick 1 functions so pad works with any single player game that supports a joystick

B2,B3,B4 are calls from joystick 2

 

Well RXB would make that a little faster and more compact.

10 CALL JOYST(1,X,Y,2,B2,B3)
30 CALL KEY(1,B1,S,2,B4,S)

 

As RXB stays in the orginal code and does not have to go scan a second time it is quite faster.

[jchase1970]

Paypal, jchase1970@hotmail.com but be sure to email me, or even text me at 812-459-9970. I'll be ready to send them out by Friday.

 

In the mean time, little demo program and a crappy little video.

 

7 CALL CLEAR
8 CALL CHAR(42,"183C3C9999FF9981")
9 CALL SPRITE(#1,42,2,20*8,16*
10 CALL CHAR(44,"00003C42813C4218",45,"104824A4A4244810",46,"0812242525241208")
100 CALL JOYST(1,JX,JY)
110 CALL JOYST(2,B3,B2)
120 CALL KEY(1,B1,S)
130 CALL KEY(2,PAUSE,S)
140 IF PAUSE=18 THEN 1000
150 IF(JX=0)*(JY=0)THEN 160 ELSE 500
160 IF B1=18 THEN 600
170 IF B2=4 THEN 700
180 IF B3=4 THEN 800
190 IF(S1=1)+(S2=1)+(S3=1)THEN 400
200 GOTO 100
400 IF S1=1 THEN CALL POSITION(#2,Y,X)ELSE 420
410 IF Y<10 THEN CALL DELSPRITE(#2) :: S1=0
420 IF S2=1 THEN CALL POSITION(#3,Y,X)ELSE 440
430 IF X<10 THEN CALL DELSPRITE(#3) :: S2=0
440 IF S3=1 THEN CALL POSITION(#4,Y,X)ELSE 100
450 IF X>246 THEN CALL DELSPRITE(#4) :: S3=0
460 GOTO 100
500 CALL MOTION(#1,-JY,JX)::GOTO 160
600 CALL POSITION(#1,Y,X)::CALL SPRITE(#2,44,2,Y-8,X,-8,0)::S1=1::GOTO 190
700 CALL POSITION(#1,Y,X)::CALL SPRITE(#3,46,2,Y,X-8,0,-::S2=1::GOTO 180
800 CALL POSITION(#1,Y,X)::CALL SPRITE(#4,45,2,Y,X+8,0,::S3=1::GOTO 190
1000 FOR DELAY=1 TO 10
1001 NEXT DELAY
1005 CALL KEY(2,PAUSE,S)
1006 IF S=0 THEN 1005
1010 IF PAUSE=18 THEN 1020 ELSE 1005
1020 FOR DELAY=1 TO 10
1030 NEXT DELAY
1040 GOTO 100

 

Using 3 buttons to shoot in different directions

http://youtu.be/xL45QzqjVaY

 

John

Edited November 13, 2011 by jchase1970

[RXB]

You can make better video if you use http://www.hyperionics.com/

 

And I use http://www.freewin7software.com/

 

You can make pretty good videos with these and they are free.

[jchase1970]

 

Well RXB would make that a little faster and more compact.

10 CALL JOYST(1,X,Y,2,B2,B3)
30 CALL KEY(1,B1,S,2,B4,S)

 

As RXB stays in the orginal code and does not have to go scan a second time it is quite faster.

 

Wow, I like the compact way that works

 

Just for kicks I timed it to see how much slower the extra polling was,

10 I=0
20 I=I+1
30 CALL JOYST(1,X,Y)
40 CALL KEY(1,B1,S)
50 IF I=100 THEN END
60 GOTO 20

 

SAME CODE WITH EXTRA POLLING

INSERTED

[code

35 CALL JOYST(2,B3,B2)

45 CALL KEY(2,B4,S)

[/code]

 

And the results

Single poll 100 times in xb 6.4 seconds

Double poll 100 times in xb 11.2 seconds

 

It seems each call to KEY or JOYST adds about 2.5 seconds per 100, one is not faster or slower then the other, so if you dont need the pause key you can speed it up by 25%

[jchase1970]

You can make better video if you use http://www.hyperionics.com/

 

And I use http://www.freewin7software.com/

 

You can make pretty good videos with these and they are free.

 

This was filmed on the TV using my real TI and ProPlay game pad. I use CamStudio for my screen capture video. Although I have been looking for a video converter, Thx.

Edited November 13, 2011 by jchase1970

[RXB]

Ok ran a test:

10 I=I+1
20 CALL JOYST(1,X,Y)::CALL JOYST(1,A,B)
30 CALL KEY(1,B1,S)::CALL KEY(2,B2,S)
40 IF i=1000 THEN END
50 GOTO 10

Result after 1 minute I=552

 

Next test RXB:

10 I=I+1
20 CALL JOYST(1,X,Y,2,A,B)
30 CALL KEY(1,B1,S,2,B2,S)
40 IF I=1000 THEN END
50 GOTO 10

Result after 1 minute i=597

 

This surprised me as I thought the difference would be greater.

 

Making line 20 into a single CALL JOYST and CALL KEY was 545 XB and 593 for RXB.

 

So :: actually slows the program down more then more line numbers does.

[jchase1970]

Ok ran a test:

10 I=I+1
20 CALL JOYST(1,X,Y)::CALL JOYST(1,A,B)
30 CALL KEY(1,B1,S)::CALL KEY(2,B2,S)
40 IF i=1000 THEN END
50 GOTO 10

Result after 1 minute I=552

 

Next test RXB:

10 I=I+1
20 CALL JOYST(1,X,Y,2,A,B)
30 CALL KEY(1,B1,S,2,B2,S)
40 IF I=1000 THEN END
50 GOTO 10

Result after 1 minute i=597

 

This surprised me as I thought the difference would be greater.

 

Making line 20 into a single CALL JOYST and CALL KEY was 545 XB and 593 for RXB.

 

So :: actually slows the program down more then more line numbers does.

 

I'm not so surprised, as even if rxb makes it into 1 statement there are still 2 calls to the joystick. so it's not that you are really doing any less work on the machine side of the code. You can only poll one joystick x,y axis at a time and same with the buttons, you can only poll one controller button at a time.

 

I find it so interesting how TI managed to compact the joysticks into one port by adding diodes and using the same wires to return values for 2 different joysticks. It is a impressive way to do it, all other console just use 2 joystick ports but TI did the same thing with 50% less ports. Just the fact that someone thought that out back then impresses me, "We need 2 joystick ports , wait what if we can use one port and make it do double the work? Do we need a 15 pin connecter then? No we will use the same 9 pin connector and make the 7 wires work double time too."

 

I wonder why double command lines with the :: are slower then single line. I would think the basic interpreter would sort it out exactly the same as single command lines?

[RXB]

Well looking over the GPL code (RXB and XB are the same here)

[0303] 0082		  SSEPZ  EQU  >82			   ::
<0043> CB37 82			  BYTE SSEPZ			 *  ::
<0015> A000 0F,75		   XML  CONT			  XML CONT used by subprogram
<0016> A002 43,FB		   BR   LITS05			Build FAC entry and GETSTR
<0017> A004 40,9C		   BR   EXEC			  Execute a program
<0018> A006 48,D3		   BR   LINE
<0019> A008 48,6E		   BR   DATAST
<0020> A00A 48,8A		   BR   ASC
<0021> A00C 40,A9		   BR   EXEC1
<0022> A00E 41,2B		   BR   EXEC6D			Save information on a break
<0023> A010 48,0A		   BR   DELINK			Delink symbol table entry
<0024> A012 48,E5		   BR   CONV1
<0025> A014 49,C9		   BR   SQUISH			Called in error routine in PS
<0026> A016 45,71		   BR   VALCD
<0027> A018 42,8D		   BR   INTRND
<0028> A01A 40,1A		   BR   $
<0029> A01C 4A,E7	GA01C  BR   LNKRTN			Routine to go back to XB prog
<0072>			   ***********************************************************
<0073>			   *		START EXECUTION OF A PROGRAM OR STATEMENT
<0074>			   * DATA:
<0075>			   *	  RAM(START) points into line number table at the
<0076>			   *	  first line to execute
<0077>			   *	  @PGMFLG contains >FF if executing a program or zero
<0078>			   *	  if imperative statement
<0079>			   ***********************************************************
<0080> A09C 8E,44	EXEC   CZ   @PRGFLG		   If program
<0081> A09E 60,AE		   BS   GA0AE
<0082> A0A0 BD,2E,A3		DST  V@START,@EXTRAM   Line to start execution at
   A0A3 72
<0083> A0A4 95,2E		   DINCT @EXTRAM		  Pointer to text pointer
<0084> A0A6 06,A2,8D		CALL INTRND			Initialize random number
<0085> A0A9 BE,7F,03 EXEC1  ST   X2,@XPT		   Initialize screen display
<0086> A0AC 40,B2		   BR   GA0B2
<0087> A0AE BF,2C,08 GA0AE  DST  CRNBUF,@PGMPTR	Executing out of crunch buffe
   A0B1 20
<0088> A0B2 BF,26,A0 GA0B2  DST  EXEC20,@RTNG	  Address of return from ALC
   A0B5 BC
<0089> A0B6 BF,28,A1		DST  NUDTB,@NUDTAB	 NUD table address for ALC
   A0B9 47
<0090> A0BA 0F,76		   XML  EXECG			 Execute XB
<0091> A0BC 8A,23	EXEC20 CASE @ERRCOD+1		 Check type of return

99/4 GPL-ASSEMBLER (Pass 3) correct								   PAGE 0011
EQUATES EXEC-359
<0092> A0BE 40,DF		   BR   EXECND			0 - NORMAL END
<0093> A0C0 41,1A		   BR   EXECBK			1 - BREAKPOINT
<0094> A0C2 40,ED		   BR   EXECTR			2 - TRACE
<0095> A0C4 48,AB		   BR   ERORZ			 3 - ERROR
<0096> A0C6 40,D4		   BR   WARNGZ			4 - WARNING
<0097> A0C8 41,DA		   BR   ONERR			 5 - ON ERROR
<0098> A0CA 47,17		   BR   UDF			   6 - FUNCTION
<0099> A0CC 42,18		   BR   ONBRK			 7 - ON BREAK
<0100> A0CE 44,38		   BR   CONCAT			8 - CONCATENATE STRINGS "&"
<0101> A0D0 41,AA		   BR   ONWARN			9 - ON WARNING
<0102> A0D2 42,2F		   BR   GPLCAL			A - CALL STATEMENT
<0103> A0D4 C6,73,B0 WARNGZ CH   >B0,@SUBSTK
<0104> A0D7 6D,34		   BS   ERRSO
<0105>			   * Stack overflow
<0106>			   *					ALLOW ROOM ON STACK FOR WARNING CALLS
<0030> A01E 49,89	GA01E  BR   SPCOL			 Clear breakpoint in line # ro
<0031> A020 46,FC		   BR   UBSUB			 Spare
<0032> A022 40,22		   BR   $
<0033> A024 40,24		   BR   $		 ***	 Please let me know it you add
<0034>			   *					 ***	 branches here since it will a
<0035>			   *					 ***	 the address of link list. Sum

 

So the ROMs in RXB and XB use a NUD table to find the :: or a line number and branches to the correct routine.

 

This is the reason the :: is a little slower then Line numbers. Less parsing of the line is needed for Line numbers.

(Line numbers are alway first, while :: could be anywhere.)

Edited November 14, 2011 by RXB

[ti99iuc]

Hi Jchase !

i worte you a lot of emails for the joypad... but i had no answer... have you some news about shipping costs ?

have you got and read my email ?

 

Let me know

 

Thankyou.

 

Ciro

[sometimes99er]

I wonder why double command lines with the :: are slower then single line. I would think the basic interpreter would sort it out exactly the same as single command lines?

 

This is the reason the :: is a little slower then Line numbers. Less parsing of the line is needed for Line numbers.

(Line numbers are alway first, while :: could be anywhere.)

 

So :: should be slower than line numbers ?

 

That statement surprised me just a little bit. I think TI wrote that "multiple-statement lines" was for speed and efficiency, but then speed could then be relative to programming and not execution or something.

 

Also I think Rich said that line numbers are looked up (to find where the next statement is), whereas :: is not (as in just continuing on the line). FOR-NEXT etc. might mess that up etc., but I thought I understood the message.

 

My smaller (and different) test programs however show that :: is faster than line numbers. Here's one of the smaller ones ...

 

10 I=I+1

20 I<2000 THEN 10

30 I=1/0

 

10 I=I+1::I<2000 THEN 10

30 I=1/0

[RXB]

Well KEY and JOYST are both mostly assembly programs and the XB PARSE routine is also a XML PARSE BYTE >B6 as a example is the >B6=( so I was comparing speed of using line numbers vs :: and using KEY and JOYST.

 

What I showed was when the :: was added the value of variable I=I+1 was lower and indicates that it executed less times in one minute then the line numbers did.

 

I can not explain what you did. If you make a single line 16 CALL CLEAR commands separated by :: and another program that is 16 lines with a single CALL CLEAR per line they take the same amount of time.

Edited December 18, 2011 by RXB

[sometimes99er]

Well, I would have guessed, that it was not the fault of "::", but the double amount of CALLs, that made it slower (variable count was lower).

 

So you're doing "only" 16 iterations of "::" versus "lines", and I guess that apparently doesn't really show any difference. I'm doing about 2000 iterations, and it's done in about 20 seconds, and then in favour of "::".

 

Anyways, it's not important. No big deal.

[ti99iuc]

Hi Jchase !

i worte you a lot of emails for the joypad... but i had no answer... have you some news about shipping costs ?

have you got and read my email ?

 

Let me know

 

Thankyou.

 

Ciro

[marc.hull]

Hi Jchase !

i worte you a lot of emails for the joypad... but i had no answer... have you some news about shipping costs ?

have you got and read my email ?

 

Let me know

 

Thankyou.

 

Ciro

 

 

 

Ditto..... Me too please...

[jchase1970]

I got the first batch out and ran into some serious personal problems. I have some more almost done. But, I'm in the middle of moving. Please be a little patient with me and I'll contact you.

 

Sorry, John.

[marc.hull]

I got the first batch out and ran into some serious personal problems. I have some more almost done. But, I'm in the middle of moving. Please be a little patient with me and I'll contact you.

 

Sorry, John.

 

OK.... No problem. Sorry for your personal troubles, hopefully it plays out well. And don't apologize..... you are doing us a solid ....

[ti99iuc]

I Tried the two JoyPad i got from John Chase but i must press the direction pad very hard to be able to move a sprite on the screen... this problem make the joypads unsable.

it's normal or is not normal ?

i am the only one that have this problem ?

 

i must push very strong to have the correct movements of the sprite...

not for the buttons... they have a working goos as is normal...

i mailed a lot of time to John but i haven't got an answer...

 

someone could help me ?

 

Thank You...

Edited May 6, 2012 by ti99userclub

[ti99iuc]

have someone tried the JChase's Joypad ?

[kl99]

if you have an atari joystick adapter for your ti-99, you can get a very handy gamepad:
http://www.ebay.com/itm/Atari-2600-Original-Atari-Joypad-Controller-Joypad-gebraucht-/390700500665?pt=DE_PC_Videospiele_Controller&hash=item5af79086b9

I bought one on the last retro faire in Vienna, it works just fine with the WICO Joystick adapter.

Reaction time of this Atari gamepad is really good! Could only see advantages over my other joysticks so far!

TI Scramble was never so fine to play with!