Jump to content

Open Club  ·  87 members

AtariVox
IGNORED

Quadtari


Thomas Jentzsch

Recommended Posts

Somewhat unrelated, but I suppose I find the right audience here best.

 

If it makes sense, we should enhance Stella to support it too. Assuming it does:

  • How do you code for the Quadtari work?
  • Is there any documentation or example code somewhere? 

 

And help welcome!

Link to comment
Share on other sites

On 4/9/2020 at 10:14 AM, Thomas Jentzsch said:

Somewhat unrelated, but I suppose I find the right audience here best.

 

If it makes sense, we should enhance Stella to support it too. Assuming it does:

  • How do you code for the Quadtari work?
  • Is there any documentation or example code somewhere? 

 

And help welcome!

Hi TJ!

 

Apologies for not replying sooner; I did not get any notifications so I clicked on "follow" so I should be all set now moving forward. ;) 

 

There is no official documentation *yet* for the QuadTari, but I do plan on working with Nathan Tolbert on that when it eventually gets released.

 

With that said, I did finalize the API and added code to support it for WoW and Galagon so I can certainly provide coding examples of how it works. :D  Stella support would be awesome, and I hope it's possible! :thumbsup:  I'll help out in any way I can so thanks in advance. :)  

 

First off, the QuadTari is really 2 "DuoTaris" (I just made that name up :lol: ) where 2 joysticks can each be connected to each controller port.  The QuadTari is 2 DuoTaris stacked on each other and are electronically separate.  Nathan T. is considering selling DuoTari separately, and perhaps allow someone to "stack them" by sliding 2 together for 4 player games, but we'll see.  

 

The design originally used one or two of the pins in output mode to select which joystick to activate (with the output control pins mapped to the paddle pins INPT0 and INPT1), but this had a few disadvantages:

 

  • If you had 1 joystick connected and wanted to play a non-QuadTari game, it didn't work since 2 of the directions were re-mapped (left and right).
  • You can't use the INPT0/INPT1 to auto-detect when a QT is connected (vs. a regular joystick or a Genesis 2-button controller)
  • It takes twice as much time to read directions for 4 joysticks vs. 2 (more about this below)

During some testing, it was suggested that we use VBLANK DUMPPORTS used for reading paddles to select a joysticks (which drive pin 5 and pin 9 high) instead of using the directional pins in output mode.  This is the direction we went for a few reasons:

 

  • Since joystick directions aren't remapped, you can play joystick games that are non-QuadTari compatible with Joystick 1 connected through the QuadTari, with some exceptions (one being Defender doesn't work because it seems to DUMP_PORTS which messes with which QT joystick is active).  The Harmony menu software seems to do the same thing (which makes sense since you can use the paddle or joystick with it) but for that you can control the menu with Joystick 2.  I think I had posted a while ago asking if it was possible to only DUMP_PORTS in the Harmony menu software if paddles were detected (assuming that is what is actually happening).
  • Since INPT0 and INPT1 aren't remapped or used, we ground one of them and the other one is pulled high, so you can detect whether a QuadTari is connected to port A:
    • both low, it's a regular joystick
    • both high, it's a Genesis 2-button controller
    • INPT0 low and INPT1 high, it's a QuadTari (DuoTari).  
    • You can also use the same logic to see if there is a QuadTari connected to port B, but with INPT2/INPT3, so you can determine if you have 4 controllers available.
  • For 4 joystick games with 2 DuoTari's connected, you can read values for joystick 1 and 3 by reading the high bits of SWCHA (and INPT4 for the button) when VBLANK DUMP_PORTS is low, and you can read values for joystick 2 and 4 by reading the low 4 bits of SWCHA (and INPT5 for the button) when VBLANK DUMP_PORTS is high.  

Since there is a delay needed between activating/de-activating DUMP_PORTS and reading the joystick ports, what I do is:

 

  1. At the beginning of OverScan, I read Joystick 1 (and 3 if needed) since DUMP_PORTS is 0.
  2. After reading the values, I update VBLANK and  set DUMP_PORTS to 1.  This will switch the QT to read Joystick 2 (and 4 if there is one plugged into port B)
  3. In vertical blank, I read joysticks 2 (and 4 if needed).  At the end of vertical blank, VBLANK is set to 0 (DUMP_PORTS is also set to 0)
  4. Goto step 1

This allows enough time between activating / deactivating DUMP_PORTS (which switches the controller to read on the QuadTari) and actually reading the values on SWCHA and INPT4/5.

 

We don't know the exact amount of time needed between updating DUMP_PORTS and reading consistent values; I hope to determine this through some more testing.  Certainly the amount of time we have is more than enough as the testing with Galagon and WoW didn't have any control issues, but I'm sure the time needed is much lower.

 

Here is the code I use in Wizard of Wor Arcade to detect a QuadTari (DuoTari) in port A.  A couple notes:

 

  • You can hold down SELECT to disable QT detection.  
  • I store a 1 in the high bit of flags if a QT is detected (multi-tap is the generic name I use) in port A
  • This is not detecting a DT/QT in port B, but could be easily done by checking INPT2 and INPT3 and storing another bit in flags.  

 

	; if select is held down, skip multi-tap detection
	lda SWCHB
	and #SELECT_MASK
	beq detectSaveKey
	
	; auto detect
	; 	INPT0			INPT1
	;		0				0		regular joystick connected
	;		1				x		Genesis pad (or paddles) connected
	;		0				1		multi-tap connected		
	
	; if INPT0 = 1, we have a Genesis pad connected and no multitap
	bit INPT0
	bmi detectSaveKey
	
	; if INPT0 = 0 and INPT1 = 1, we have a multitap connected
	bit INPT1
	bpl detectSaveKey
	
	lda flags
	ora #FLAG_MULTITAP
	sta flags

 

This is my generic ReadController subroutine.  x is the input; 0 = read joystick 1 (and 3) and 1 = read joystick 2 (and 4).  It can most certainly be optimized.  Note that I store the values in RIOT ram in "controller" and combine the button and joystick values (and I invert the values so 1 is active and 0 is inactive).  I do this because these values are sent to the ARM where I do all my controller checks.  Note that the controller[0] and controller[1] are normalized so the ARM code doesn't know (or care) if the controller values come from 2 joysticks connected to a QT or 2 separate ones connected to 2 ports.  I do use the controller bit in flags to enable/disable co-op options with an Atarivox, etc. if needed (ie. if you have an AtariVox and no QT, you can't play a 2-player game).

 

; =============================================================================
; input: X - controller to read (0 = A, 1 = B)
;
ReadController:
; =============================================================================
	
	ldy  #0
	
	; regular joysticks
	cpx  #1
	beq  readControllerB

readControllerA:	
	lda  SWCHA
	and  #%11110000
	bne  storeController
	
readControllerB:		

	; if multitap, we're reading controller A
	bit  flags
	bmi  readControllerA
  
	ldy  #1
	lda  SWCHA
	asl
	asl
	asl
	asl

storeController:	
	sta temp
	
	; read the button
	lda INPT4,y			; for multi-tap, we always read INPT4
	lsr					; shift to the proper bit to store
	lsr
	lsr
	lsr
	ora temp
	and #$F8			; don't really need this
	eor #$F8			; flip all bits to make it active high
	sta controller,x


endReadController:		
	rts

 

The switching of the DT/QT is done in OverScan.  Since VBLANK is 0 (and DUMP_PORTS is 0) during the entire kernel, this is more than enough time to have the QT/DT switched over to read joystick 1/3.  At the beginning of OverScan I read these values, and then enable DUMP_PORTS immediately so the DT/QT can switch ports and you get almost all of OverScan as a delay (since they aren't read until Vertical Blank).  This can probably also be optimized but it does work. :) 

 

OverScan:    
    START_OVERSCAN
    
    ; read controller 2
    ldx #0
    jsr ReadController

    ; turn on dump ports to read other joystick
    bit flags
    bpl noMultiTap
	ldx #DUMP_PORTS|DISABLE_TIA
	stx VBLANK
noMultiTap:    

Note that in Vertical Blank, I set x to 1 before calling ReadController to read controller 1.  I put ReadController such that I don't need to jsr to it in this instance:

 

	ldx #1		
; this falls directly into ReadController so no need to jsr

; =============================================================================
; input: X - controller to read (0 = A, 1 = B)
;
ReadController:
; 

Hope that makes sense!  Let me know if you have any questions and I'll be more than happy to answer them. :)  
 

Thanks TJ!

John

 

 

 

  • Like 1
  • Thanks 2
Link to comment
Share on other sites

18 minutes ago, johnnywc said:

I think I had posted a while ago asking if it was possible to only DUMP_PORTS in the Harmony menu software if paddles were detected (assuming that is what is actually happening).

I think I missed that request. Should be doable.

 

Thanks a lot for the detailed explanation. That should help implementing support into Stella. Please let us know about the timing constraints when you found out.

  • Like 1
Link to comment
Share on other sites

  • 4 months later...

Hi TJ,

 

Here is a revamped QuadTari test application (4K) that will read the controllers in each port and display them accordingly, including:

 

- Genesis 2-button controller

- Savekey

- QuadTari

 

If none are found, it assumes there is a regular joystick connected.

 

multitap_test_4.thumb.png.b21882d4472d917b96ca1dc94f216419.png


- If a Savekey is detected (in port B only), no joystick/button movements are displayed.

- If a Genesis gamepad is detected, the joystick directions and button 1 / button 2 is displayed for testing (I should at some point change this to display Button B/C)

- If a Quadtari is detected, 2 joystick tests are shown for that port for the 4 directions and 1 button

- If a regular joystick is detected, the 4 directions and 1 button are displayed

 

Joystick 1 (and 3 for Quadtari in port A) is read on port A.

Joystick 2 (and 4 for Quadtari in port B) is read on port B.

 

Joystick 1 and 2 are read when DUMP_PORTS is low (0).

Joystick 3 and 4 are read when DUMP_PORTS is high (1).

 

I'm not sure how you intend on adding support to Stella, but my guess is that you will add 5 more emulator events to each port "player"?

 

image.png.68f4f07231b34fc49f8614cc7ebe7d80.png

 

So, you would have P0 QuadTari Joystick Up, down, left, right, fire and P1 QuadTari Joystick Up, down, left, right and fire perhaps?  Then, depending on the value of DUMP_PORTS you could read the input from the correct controller and store it in SWCHA/ INPT4/INPT5?  

 

I have done some timing tests but still need to perform more.  I would say for now I would put a 20 scanline min delay between switching the DUMP_PORTS and reading accurate values from the correct input.  If the delay is shorter, I guess you could emulate that by having the code get the values from the other wrong inputs or randomly mixing the results.

 

Anyway, hope this helps!  We're planning on releasing the QT in a few months (design is final, picking out a case right now) so adding Stella support would be great.

 

Let me know if you have any questions.

 

Thanks!

John

 

multitap_test.zip

Link to comment
Share on other sites

25 minutes ago, johnnywc said:

I'm not sure how you intend on adding support to Stella, but my guess is that you will add 5 more emulator events to each port "player"?

How does a real Quadtari work?  Do you plug it into both ports, and then 4 joysticks into the device itself?  If so, that's how we would emulate it.  In general, we try to do the emulation at the level of the component.  For example, there are two Controller classes, which are inherited from by each virtual controller (Joystick, Paddles, Driving, etc).  Each of these modifies SWCHA and INPTx in various ways, depending on the controller.  If the 'controller' takes over both ports, like the Compumate, then the virtual controller/class does the same thing, and emulates exactly what real hardware would do.

 

So ideally what we (the Stella team) would need is a device to test with, or at the very least a description at the hardware/component level (with timing considerations) to properly emulate this.  Whoever is involved with this should submit an issue at https://github.com/stella-emu/stella/issues with the required info.

Link to comment
Share on other sites

11 minutes ago, stephena said:

How does a real Quadtari work?  Do you plug it into both ports, and then 4 joysticks into the device itself?  If so, that's how we would emulate it. 

The "Quad"-tari can be plugged into 2 ports, but it can also work if plugged into 1 port.  It can read 2 joysticks for each port it is connected to.  So, if you have it connected to both ports, you can read 4 joysticks; 2 on the left and 2 on the right.  If you have it only connected to the left port, you can read the 2 joysticks assigned to that port (in this case, joystick 1 and joystick 3).  Same for the right port, except you would read joystick 2 and joystick 4 connected to the QuadTari.  It was designed like this so you could have 4 controllers for 4 player games, but also optionally have 2 controllers on the left port and free up the other right port for another device like the SaveKey or AtariVox (think Wizard of Wor co-op mode with speech).  So I think the best way to emulate it would be to have each port assigned the QuadTari separately. 

11 minutes ago, stephena said:

In general, we try to do the emulation at the level of the component.  For example, there are two Controller classes, which are inherited from by each virtual controller (Joystick, Paddles, Driving, etc).  Each of these modifies SWCHA and INPTx in various ways, depending on the controller.  If the 'controller' takes over both ports, like the Compumate, then the virtual controller/class does the same thing, and emulates exactly what real hardware would do.

Makes sense.  In this case, I think it would make sense to have the QuadTari only take over 1 port and be treated as such (1 port with support for 10 inputs / 2 joysticks (4 directions and 1 button each)).  Setting the left and right port to QuadTari would allow for 2 'joysticks' on each port.  

 

When 2 joysticks are connected to the QuadTari, the movement is still read in that ports joystick/button addresses (high bits of SWCHA and INPT4 for the left port and the low bits of SWCHA and INPT5 for the right port).  What controller is actually 'read' depends on the state of the DUMPPORTS bit in VBLANK.  If it's low, then QuadTari joystick1 and joystick 2 inputs are read from the left and right ports, respectively.  If it's high, then QuadTari joystick 3 and joystick 4 are read from the left and right ports.  (this is assuming of course you have a QuadTari connected to both ports of course).  Internally, the QuadTari is using analog multiplexers to pass through the value of the controllers to the Atari and the select bits are controlled by the pin 9 from the Atari left port for Joysticks 1 and 3 and pin 9 of the right port for Joysticks 2 and 4.  (pin 9 (and pin 5) are set high or low depending on the value of DUMPPORTS in VBLANK).

 

There is a delta between when you set the value of DUMPPORTS and when the correct values can be read from the QuadTari.  If you read the values too soon after changing the value of DUMPPORTS, your results will be undefined, but most likely a mix of the values of the other controller and the controller you want to read.  I will do some tests to figure out how many cycles this is; right now I am safely reading different values from each controller using a delay of > 30 scanlines, but I'm sure this can be much less.  The value may even be in the specs for the multiplexers; I'll take a look and see if I can figure it out.  If not, I'll do some tests with shorter delays between switching DUMPPORTS to figure it out that way.

11 minutes ago, stephena said:

So ideally what we (the Stella team) would need is a device to test with, or at the very least a description at the hardware/component level (with timing considerations) to properly emulate this.  Whoever is involved with this should submit an issue at https://github.com/stella-emu/stella/issues with the required info.

We don't have any devices ready yet (we've finished the design, ordered up the boards and are working with enclosures) but expect to have prototypes available soon and I would be more than happy to send you a couple for testing. :)  I can also provide the chip level schematic and have provided a test program above that shows how the controller(s) are read.

 

I will also submit an issue into Git; I thought TJ was looking into it and perhaps had created an internal issue already.  If not I will add the required info there.

 

Thanks Stephen (and TJ)!

John

 

Link to comment
Share on other sites

We discussed this briefly in the past, but until now we didn't have all the necessary information. 

 

Regarding the ports, IMO we would have to come up with something new. I don't thing the CompuMate approach will be sufficient, because we will have not one controller but two. And they have to be switched on-the-fly. The latter is something Stella supports already, but the code is not meant for permanent switching. But this is something for the Stella team to discuss. :) (

 

Knowing the minimum cycles for DUMPPORT switches would help developers a lot. 

 

BTW: Any suggestions how to auto detect the Quadtari support (static ROM analysis)? Maybe we should define a short text pattern (e.g. "LQUAD" and "RQUAD" for left and right port) for all coming games. And then we need the patterns for the existing game(s?). Also, since we would have to decide for one controller per port, which priority would you prefer? Your example program supports normal joysticks, Genesis and Quadtari. I figure that not that many people will own a Quadtari and/or use Stella for it, so maybe a Genesis would be highest priority? Followed by...?    

Edited by Thomas Jentzsch
Link to comment
Share on other sites

Question: Does the QuadTari only support joysticks? Or would e.g. paddles, driving controllers and trackballs be supported too? Also, is it possible to mix controllers at one port? 

 

So would something like this be possible?

  • left port: joystick and paddles
  • right port: trackball and AtariVox

I figure paddles (and Genesis or Omega BoosterGrip) might be a problem due to INPT0/1 auto detection (maybe this should only work for a moment during power up?), but all others seem feasible, no?

 

if yes, a full implementation will become quite a bit more complex. 

Edited by Thomas Jentzsch
Link to comment
Share on other sites

5 hours ago, Thomas Jentzsch said:

We discussed this briefly in the past, but until now we didn't have all the necessary information. 

Yes, sorry TJ - I didn't mean to imply that you should have been working on this. :)  I was referring to whether or not there is an issue open in Git for QuadTari support and whether you had already created it so I wouldn't create a duplicate issue.  Have you created an issue in Git?  If not I can certainly do it and organize all of this info. :thumbsup:  

5 hours ago, Thomas Jentzsch said:

Regarding the ports, IMO we would have to come up with something new. I don't thing the CompuMate approach will be sufficient, because we will have not one controller but two. And they have to be switched on-the-fly. The latter is something Stella supports already, but the code is not meant for permanent switching. But this is something for the Stella team to discuss. :) (

Let me know if you need more info and whatever else to help out the Stella team! :D  One thing I want to stress is that although it's called a "QuadTari", it really is two "duo"-Tari's that run independently of each other so you don't have to have both left and right plugged in for it to work.  Plugging it into a port basically allows that port to have 2 controllers instead of one.  You can easily have (and will most likely be the most common configuration) the QuadTari connected to the left port for 2 joysticks and the SaveKey connected to the right port.

5 hours ago, Thomas Jentzsch said:

Knowing the minimum cycles for DUMPPORT switches would help developers a lot. 

I will figure this out today and get back to you with the value.  

5 hours ago, Thomas Jentzsch said:

BTW: Any suggestions how to auto detect the Quadtari support (static ROM analysis)? Maybe we should define a short text pattern (e.g. "LQUAD" and "RQUAD" for left and right port) for all coming games. And then we need the patterns for the existing game(s?).

Hmm, I think that is going to be tough to autodetect with static analysis, but I will be more than happy to share the detection code I use for Galagon and Wizard of Wor.  Zoo Keeper is in RC and uses the same detection scheme as Galagon.  Robotron is being finished now and is the first game to support the QT in both ports for 4 player action (or 2 players each using 2 controllers); the other 3 support the QT in the left port only.  As I describe above, I auto-detect on startup by checking INPT1 and INPT0.  If INPT0 = 0 and INPT1 = 1, I assume there is a QT connected to that port.  (INPT0=INPT1=1 means a Genesis controller).

5 hours ago, Thomas Jentzsch said:

Also, since we would have to decide for one controller per port, which priority would you prefer? Your example program supports normal joysticks, Genesis and Quadtari. I figure that not that many people will own a Quadtari and/or use Stella for it, so maybe a Genesis would be highest priority? Followed by...?    

Hmmm, it would probably make sense to have the QT standard for most games that support it as it is the recommended way to play so the right port is reserved for the Savekey/AtariVox.  Right now, only Robotron supports the QT and the Genesis, but the QT is the recommended way to play as it supports 2 joysticks for a player, one to move and one to fire.  The Genesis controller allows you to fire backwards with button 2.  Co-op modes in Galagon and Wizard of Wor Arcade are disabled if you have a Savekey in the right port and no QT in the left port.

 

 

Link to comment
Share on other sites

2 hours ago, Thomas Jentzsch said:

Question: Does the QuadTari only support joysticks? Or would e.g. paddles, driving controllers and trackballs be supported too? Also, is it possible to mix controllers at one port? 

The QT does support driving controllers for sure (I was able to test this).  I have never used or owned a trackball (I should really get one of those!), but from what I understand it is implemented similar to the driving controller using 2 encoders?  I see that up/down is changed when rotating a driving controller; I assume a track ball changes up/down bits in SWCHA for vertical movement and left/right bits for horizontal movement?  If so, then yes trackballs should also be supported.  

 

Paddles are not supported, nor are any controllers that use INPT0 to 3 as these pins are not wired up the same.  Actually, pin 9 isn't hooked up at all to the joysticks since from the Atari that pin is used as the select line for the QT multiplexers.  Pin 5 (INPT0/INPT2) is not hooked up from the Atari (ground).  You can still use a Genesis controller but it is detected as a regular joystick with one button.  I don't own a Booster grip, but from what I recall it adds a couple buttons using INPT0/INPT1?  If so, that would not work.  

 

With that said, there is nothing stopping someone from actually hooking up paddles/Genesis controller/Booster grip to a QuadTari port; the behavior will just be different than what the player expects, so perhaps you should allow any controller to be hooked up to the 2 QT ports and emulate their behavior?   What I mean is that I can hook up fours sets of paddles to all 4 ports of a QT, and in my test program the dials will have no effect but pressing the 8 paddle buttons will show left/right being activated for each 'joystick' display.  Probably not too useful (except for a 4 player simultaneous pinball game), but possible. ;)  

2 hours ago, Thomas Jentzsch said:

So would something like this be possible?

  • left port: joystick and paddles

Yes.  In this scenario, you can read all 5 inputs of the joystick (4 directions and the button) and the 2 buttons of the paddles.

2 hours ago, Thomas Jentzsch said:
  • right port: trackball and AtariVox

Yes, this should be possible too.  All of the AtariVox interaction would need to be done when DUMPORTS was either low or high (depending on what port it's connected to) and you would have to switch to input mode for the proper bits of SWCHA to read the trackball with the opposite value of DUMPORTS, but yes this should be technically possible. :)  You gave me a good idea too; I should be able to make a game that supports 3 players and the AtariVox/Savekey :D  using this configuration.  I'm not 100% sure if the AtariVox savekey uses INPT0/INPT1 pin 5/pin 9 for anything but I'm pretty sure it just uses the SWCHA bits to read/write which would mean it should work.

2 hours ago, Thomas Jentzsch said:

I figure paddles (and Genesis or Omega BoosterGrip) might be a problem due to INPT0/1 auto detection (maybe this should only work for a moment during power up?), but all others seem feasible, no?

In short, any value that requires INPT0/INPT1 are not supported when connected to the QT since these are used as the select line for the QT multiplexers (as is INPT2/INPT3 for the right port).

2 hours ago, Thomas Jentzsch said:

if yes, a full implementation will become quite a bit more complex. 

Yes, it sounds like it.  I am not familiar with the framework of Stella, but perhaps it would be more simple if you looked at a QuadTari as 1 controller with 10 inputs?  Depending on the value of DUMPPORTS would determine which of the 5 inputs are being mapped to SWCHA/INPT4/5, and depending on which controller is connected to each QT port will determine which bits in SWCHA or if INPT4/5 are set/reset.  Apologies in advance if this suggestion doesn't make sense with the current framework. :ponder: 

 

It does certainly sound like a pretty complex addition; thanks so much for taking a look into this!  Of course I will do whatever I can to assist and will make sure I send the Stella team some QTs as soon as they're available. :thumbsup: 

 

Thanks!

John

 

 

Link to comment
Share on other sites

1 hour ago, johnnywc said:

Yes, sorry TJ - I didn't mean to imply that you should have been working on this. :)  I was referring to whether or not there is an issue open in Git for QuadTari support and whether you had already created it so I wouldn't create a duplicate issue.  Have you created an issue in Git?  If not I can certainly do it and organize all of this info. :thumbsup:

No reason to be sorry, I didn't think you implied something like that. And I have created an issue today. :) 

 

1 hour ago, johnnywc said:

Hmm, I think that is going to be tough to autodetect with static analysis, but I will be more than happy to share the detection code I use for Galagon and Wizard of Wor.  Zoo Keeper is in RC and uses the same detection scheme as Galagon.  Robotron is being finished now and is the first game to support the QT in both ports for 4 player action (or 2 players each using 2 controllers); the other 3 support the QT in the left port only.  As I describe above, I auto-detect on startup by checking INPT1 and INPT0.  If INPT0 = 0 and INPT1 = 1, I assume there is a QT connected to that port.  (INPT0=INPT1=1 means a Genesis controller).

Hmmm, it would probably make sense to have the QT standard for most games that support it as it is the recommended way to play so the right port is reserved for the Savekey/AtariVox.  Right now, only Robotron supports the QT and the Genesis, but the QT is the recommended way to play as it supports 2 joysticks for a player, one to move and one to fire.  The Genesis controller allows you to fire backwards with button 2.  Co-op modes in Galagon and Wizard of Wor Arcade are disabled if you have a Savekey in the right port and no QT in the left port.

Stella has no run-time detection, so we can only rely on static analysis. Maybe there is a certain code pattern which is used by QuadTari games, e.g. the controller detection or switching? Else I would suggest using signature strings. 

Link to comment
Share on other sites

30 minutes ago, johnnywc said:

The QT does support driving controllers for sure (I was able to test this).  I have never used or owned a trackball (I should really get one of those!),

An Atari or Amiga mouse would do too. I think they are cheaper and usually need less maintenance.

 

30 minutes ago, johnnywc said:

...but from what I understand it is implemented similar to the driving controller using 2 encoders?  I see that up/down is changed when rotating a driving controller; I assume a track ball changes up/down bits in SWCHA for vertical movement and left/right bits for horizontal movement?  If so, then yes trackballs should also be supported.  

OK, that's the point where it starts getting complicated. :)  Each "DuoTari" can support N^2 controller combinations (more or less). Which adds another level of controller setup on top of the basic controller setup. I wonder if we should go that far or if we (at least for now) only add fixed combinations which are used by an existing game. Then  Joystick/Joystick would be the only combination so far, correct? 

 

30 minutes ago, johnnywc said:

Paddles are not supported, nor are any controllers that use INPT0 to 3 as these pins are not wired up the same.  Actually, pin 9 isn't hooked up at all to the joysticks since from the Atari that pin is used as the select line for the QT multiplexers.  Pin 5 (INPT0/INPT2) is not hooked up from the Atari (ground).  You can still use a Genesis controller but it is detected as a regular joystick with one button.  I don't own a Booster grip, but from what I recall it adds a couple buttons using INPT0/INPT1?  If so, that would not work.  

OK, I think we can eliminate this for now.

 

30 minutes ago, johnnywc said:

With that said, there is nothing stopping someone from actually hooking up paddles/Genesis controller/Booster grip to a QuadTari port; the behavior will just be different than what the player expects, so perhaps you should allow any controller to be hooked up to the 2 QT ports and emulate their behavior?   What I mean is that I can hook up fours sets of paddles to all 4 ports of a QT, and in my test program the dials will have no effect but pressing the 8 paddle buttons will show left/right being activated for each 'joystick' display.  Probably not too useful (except for a 4 player simultaneous pinball game), but possible. ;)  

 

30 minutes ago, johnnywc said:

Yes.  In this scenario, you can read all 5 inputs of the joystick (4 directions and the button) and the 2 buttons of the paddles.

 

30 minutes ago, johnnywc said:

Yes, this should be possible too.  All of the AtariVox interaction would need to be done when DUMPORTS was either low or high (depending on what port it's connected to) and you would have to switch to input mode for the proper bits of SWCHA to read the trackball with the opposite value of DUMPORTS, but yes this should be technically possible. :) 

Definitely something for later (if ever). :D

 

30 minutes ago, johnnywc said:

You gave me a good idea too; I should be able to make a game that supports 3 players and the AtariVox/Savekey :D  using this configuration. 

That's why I am asking. :) Because that seems like the most useful use case so far.

30 minutes ago, johnnywc said:

I'm not 100% sure if the AtariVox savekey uses INPT0/INPT1 pin 5/pin 9 for anything but I'm pretty sure it just uses the SWCHA bits to read/write which would mean it should work.

SWCHA only.

 

30 minutes ago, johnnywc said:

Yes, it sounds like it.  I am not familiar with the framework of Stella, but perhaps it would be more simple if you looked at a QuadTari as 1 controller with 10 inputs? 

I think handling them for each port separately fits better to our code.

30 minutes ago, johnnywc said:

It does certainly sound like a pretty complex addition; thanks so much for taking a look into this!  Of course I will do whatever I can to assist and will make sure I send the Stella team some QTs as soon as they're available. :thumbsup: 

Thanks! Looking forward to it.

It will only become complex (also for the GUI) if we allow controller arbitrary combinations. Else it seems straightforward.

 

BTW: Have you tested with R77? I doubt it will work, at least the way the kernel is currently designed.

Link to comment
Share on other sites

1 hour ago, Thomas Jentzsch said:

No reason to be sorry, I didn't think you implied something like that. And I have created an issue today. :) 

Oh good, and thanks for creating the issue! :thumbsup:  

1 hour ago, Thomas Jentzsch said:

Stella has no run-time detection, so we can only rely on static analysis. Maybe there is a certain code pattern which is used by QuadTari games, e.g. the controller detection or switching? Else I would suggest using signature strings. 

I can take a look at the code patterns and see if anything is consistent.   Usually this will change based on the game's requirements (ie. the detection for Robotron also checks for Gamepads but WoW/Galagon don't, etc.).  Also the Robotron code has code to read all 4 controllers while Galagon/WoW only read from 2 on the left port.  The switching code may be something we can look at.  I would say anything that is setting DUMPORTS to high in Overscan might be a good indicator (see the example code), although there is no requirement for other develops to do that.  I read 2 joysticks in VBLANK and the other 2 in Overscan to split the time required to read the controllers and give enough time between switching DUMPORTS, although my suspicion is that my tests will indicate that the delay between setting DUMPPORTS and getting an accurate reading from the QT is going to be be much shorter than 30+ scanlines.

46 minutes ago, Thomas Jentzsch said:

An Atari or Amiga mouse would do too. I think they are cheaper and usually need less maintenance.

Cool, I'll look to pick one up. :thumbsup:  

46 minutes ago, Thomas Jentzsch said:

OK, that's the point where it starts getting complicated. :)  Each "DuoTari" can support N^2 controller combinations (more or less). Which adds another level of controller setup on top of the basic controller setup. I wonder if we should go that far or if we (at least for now) only add fixed combinations which are used by an existing game. Then  Joystick/Joystick would be the only combination so far, correct? 

Yes, Joystick/Joystick would work fine for the existing games and Robotron/Zoo Keeper being released this year.  However, I think Nathan T (the guy who is actually producing the QT) is thinking of making a 4 player racing game using driving controllers at some point (I would like to do the same, maybe a Destruction Derby type game or Super Sprint :cool: ) so perhaps we can add that in later?  The games themselves would also support joystick too.  I am also intrigued by the Joystick/Savekey combo in the right port for 3 player games with SaveKey/Avox but for now I don't have any immediate plans for that (although I would consider it in the future like a Guantlet type game).

46 minutes ago, Thomas Jentzsch said:

OK, I think we can eliminate this for now.

Yes, I agree.

46 minutes ago, Thomas Jentzsch said:

Definitely something for later (if ever). :D

Agreed.  Joystick/Savekey combo would probably be the only useful combination at this point.

46 minutes ago, Thomas Jentzsch said:

That's why I am asking. :) Because that seems like the most useful use case so far.

Agreed.  3 player with Savekey would be very helpful. :thumbsup:  

46 minutes ago, Thomas Jentzsch said:

SWCHA only.

Excellent!  I'll have to see about updating my test app to support this!

46 minutes ago, Thomas Jentzsch said:

I think handling them for each port separately fits better to our code.

Okay, I meant the 10 inputs for the left port, and 10 inputs for the right port -I'm not sure that was clear.  The reason I say this is that it looks like you added P0 Booster Grip controls to the menu that can be mapped.  You can think of two controllers connected to a QT as 1 joystick with 5 inputs and 5 additional inputs, and how your read them is dependent on the values of DUMPPORTS.   Now that I think about it, I think the reason you add the booster grip stuff is because that can be added on top of a regular joystick?  Is it a pass through adapter that adds 2 more buttons that are read at INPT0/INPT1?  If so, it seems that the QT is doing the same, except it's adding 5 more inputs.  Of course they are read from the same locations as the other 5 inputs so maybe that's the issue.  Anyway, I'm not trying to design it, just trying to imagine how someone would configure a QT once it's selected.  I would think at some point you would need mappings for the other 10 inputs if someone has the game configured for 2 QT's.  (ie. what key is mapped to the action).  

 

46 minutes ago, Thomas Jentzsch said:

Thanks! Looking forward to it.

It will only become complex (also for the GUI) if we allow controller arbitrary combinations. Else it seems straightforward.

Sounds good.  Straihgtforward is better than complicated. ;)  :thumbsup:  

46 minutes ago, Thomas Jentzsch said:

BTW: Have you tested with R77? I doubt it will work, at least the way the kernel is currently designed.

I have not, although I can give it a shot.  I will need to modify my test code so it doesn't detect a QT since if it's not found it won't execute the switching logic and only one controller will be configured for each port.  If the R77 is setting pin 9 high when DUMPORTS is set (which I think it would have to if real paddles work on the R77), maybe it will work.  What do you mean by the "the way the kernel is designed"?  Do you mean in the QT test app?  Just curious which part that you are concerned about that may cause it not to work?

 

It should also be noted that since there is no remapping of pins in the QT, if you select QT for a non-QT game that uses a joystick, it *should* work without issue.  Of course only one of the joysticks will work (the first one in the QT) as long as DUMPPORTS isn't being changed in the game.  (DUMPORTS will always be 0, therefore the select line pin 9 is always low, so joystick 1 is always active on that QT port).  I have seen some games where it doesn't work (Defender is one, not sure why they would be using DUMPPORTS in that game).

 

Also, I mentioned above, for the Harmony menu you need to use joystick 2 connect to the QT as it seems that DUMPORTS is set high when reading the controllers (most likely to add paddle support)?  A small request (if possible); if that is the case, could the Harmony menu code be modified so it only DUMPPORTS if a paddle is detected?  In this way, the Joystick 1 can be used to navigate the Harmony menu instead of Joystick 2.  Not a big deal if it's a huge change, but something I figured I'd mention. ;)  
 

Thanks TJ (and Stephen)!

John

 

Link to comment
Share on other sites

23 minutes ago, johnnywc said:

Yes, Joystick/Joystick would work fine for the existing games and Robotron/Zoo Keeper being released this year.  However, I think Nathan T (the guy who is actually producing the QT) is thinking of making a 4 player racing game using driving controllers at some point (I would like to do the same, maybe a Destruction Derby type game or Super Sprint :cool: ) so perhaps we can add that in later?  The games themselves would also support joystick too.  I am also intrigued by the Joystick/Savekey combo in the right port for 3 player games with SaveKey/Avox but for now I don't have any immediate plans for that (although I would consider it in the future like a Guantlet type game).

For a limited number of combinations, we can add new controllers quite easily. But eventually we will have to refactor.

Quote

Now that I think about it, I think the reason you add the booster grip stuff is because that can be added on top of a regular joystick?

Actually only because it uses INPT0, just like the Sega Genesis (but with opposite values). 

Quote

What do you mean by the "the way the kernel is designed"?  Do you mean in the QT test app?  Just curious which part that you are concerned about that may cause it not to work?

I meant the R77 kernel. The original Linux kernel was modified by Hyperkin. Paddles are using something like a separate device. Which makes them react to different axis in Stella. 

 

I also vaguely remember that there is some kind of controller detection going on in R77. Hot swapping controller types does (or did) not work.

 

Quote

It should also be noted that since there is no remapping of pins in the QT, if you select QT for a non-QT game that uses a joystick, it *should* work without issue.  Of course only one of the joysticks will work (the first one in the QT) as long as DUMPPORTS isn't being changed in the game.  (DUMPORTS will always be 0, therefore the select line pin 9 is always low, so joystick 1 is always active on that QT port).  I have seen some games where it doesn't work (Defender is one, not sure why they would be using DUMPPORTS in that game).

Good to know for testing. Thanks.

 

Quote

Also, I mentioned above, for the Harmony menu you need to use joystick 2 connect to the QT as it seems that DUMPORTS is set high when reading the controllers (most likely to add paddle support)?  A small request (if possible); if that is the case, could the Harmony menu code be modified so it only DUMPPORTS if a paddle is detected?  In this way, the Joystick 1 can be used to navigate the Harmony menu instead of Joystick 2.  Not a big deal if it's a huge change, but something I figured I'd mention. ;) 

I am sure this can be changed quite easily. But AFAIK even the 2nd joystick support in Harmony which I added by hacking an existing BIOS (needed that for testing my Trackball hacks) is not even officially released yet. Or am I wrong here?

 

Quote

Thanks TJ (and Stephen)!

John

You're very welcome.

Edited by Thomas Jentzsch
Link to comment
Share on other sites

1 hour ago, Thomas Jentzsch said:

For a limited number of combinations, we can add new controllers quite easily. But eventually we will have to refactor.

Sounds good!  Joystick/Joystick would be the most common for sure.

1 hour ago, Thomas Jentzsch said:

Actually only because it uses INPT0, just like the Sega Genesis (but with opposite values). 

Gotcha.

1 hour ago, Thomas Jentzsch said:

I meant the R77 kernel. The original Linux kernel was modified by Hyperkin. Paddles are using something like a separate device. Which makes them react to different axis in Stella. 

 

I also vaguely remember that there is some kind of controller detection going on in R77. Hot swapping controller types does (or did) not work.

Oh okay, then perhaps it won't work.  I'll give it a shot!

 

1 hour ago, Thomas Jentzsch said:

Good to know for testing. Thanks.

:thumbsup:  

1 hour ago, Thomas Jentzsch said:

I am sure this can be changed quite easily. But AFAIK even the 2nd joystick support in Harmony which I added by hacking an existing BIOS (needed that for testing my Trackball hacks) is not even officially released yet. Or am I wrong here?

No you're right. I don't mean a 2nd joystick connected to the right port.  By "Joystick 2" I'm referring to the second joystick connected to the QT connected in the left port, which would be read just like a regular joystick connected directly to the left port (vs the first joystick connected to the QT in the left port).  Since DUMPPORTS is high in the Harmony software, the QT connected to the left port will only read values from the 2nd joystick connected to the QT.  Again, not a big deal but logically I think people would prefer to be able to navigate the Harmony menu using Joystick 1 connected to a QT.  Hope that makes sense! :D 

1 hour ago, Thomas Jentzsch said:

You're very welcome.

:thumbsup:  

Link to comment
Share on other sites

3 minutes ago, johnnywc said:

No you're right. I don't mean a 2nd joystick connected to the right port.  By "Joystick 2" I'm referring to the second joystick connected to the QT connected in the left port, which would be read just like a regular joystick connected directly to the left port (vs the first joystick connected to the QT in the left port).  Since DUMPPORTS is high in the Harmony software, the QT connected to the left port will only read values from the 2nd joystick connected to the QT.  Again, not a big deal but logically I think people would prefer to be able to navigate the Harmony menu using Joystick 1 connected to a QT.  Hope that makes sense! :D 

Got you. But I will only change the software if @batari promises to release it officially when it is done. :) 

Edited by Thomas Jentzsch
Link to comment
Share on other sites

On 8/28/2020 at 1:37 PM, Thomas Jentzsch said:

Got you. But I will only change the software if @batari promises to release it officially when it is done. :) 

I will bribe Fred and see what I can do. ;)  Thanks!

5 hours ago, Thomas Jentzsch said:

One more question: In your test ROM, you are displaying a SaveKey, even if there is no SaveKey attached. Is this a bug or am I missing something?

hmmm, I just tried it and it only displays Savekey in Stella if I explicitly set the right joystick to Savekey, plus it looks like Stella auto-detects Savekey?  If I set the right port to something else (i.e. Joystick), it will correctly display the controller connected.  I tested it on real hardware and it will only display Savekey if one is connected, so I think this is related to Stella's auto-detect (I may be wrong and it could be a bug in my test program ? ).

 

 

Link to comment
Share on other sites

Ah, I realize it now. Stella sees the SaveKey code and assumes a SaveKey is present.

 

I had thought your code does some extra magic. :) 

 

BTW: I will commit an update in a few minutes (in feature/QuadTari branch), which adds basic QuadTari support to Stella.

Edited by Thomas Jentzsch
  • Like 1
Link to comment
Share on other sites

10 hours ago, Thomas Jentzsch said:

Ah, I realize it now. Stella sees the SaveKey code and assumes a SaveKey is present.

 

I had thought your code does some extra magic. :) 

:) 

10 hours ago, Thomas Jentzsch said:

BTW: I will commit an update in a few minutes (in feature/QuadTari branch), which adds basic QuadTari support to Stella.

Great!  I don't have a dev system set up to build Stella (at least I don't think so, I may have a while ago) but I'll download the changes soon!  Good timing too, as we're in the middle of testing the prototypes and finalizing enclosures, etc. :thumbsup: 

 

Thanks!

John

Link to comment
Share on other sites

QuadTari using joysticks is now fully implemented in Stella (merge is pending). What is missing is the switch timing and if we have to exclude support for R77.

 

To support more controllers (e.g. Driving, SaveKey), we would need some test ROMs. SaveKey might be an easy task if you change the existing multitap ROM. 

  • Like 1
Link to comment
Share on other sites

9 hours ago, Thomas Jentzsch said:

QuadTari using joysticks is now fully implemented in Stella (merge is pending). What is missing is the switch timing and if we have to exclude support for R77.

Thanks TJ!  When I get some free time, I will do some testing to figure out what the minimum number of cycles is between switching and getting an accurate reading from the controller.  I'm not sure how to test this on R77; do you mean connecting an actual QuadTari to the R77?

9 hours ago, Thomas Jentzsch said:

To support more controllers (e.g. Driving, SaveKey), we would need some test ROMs. SaveKey might be an easy task if you change the existing multitap ROM. 

Okay, I can do that also.  I was thinking that for the SaveKey it should have to run in Joystick port 2 (which is the first joystick connected to the QT connected to the right port).   The reason is that the Savekey detection and reading/writing all needs to be done when the the QT is active on that controller (i.e when DUMPORTS is low).  On startup when a savekey is detected, DUMPORTS will be low so it will be checking the first joystick on the right QT which is "Joystick 2".  Joystick 4 is the extra joystick connected to the right port and will be read when DUMPORTS is high.  I guess we could support QT Savekey/Joystick AND QT Joystick/Savekey, but it's probably easier to just have it support one or the other.

 

If you're building on Windows, any chance you can send me via PM the stella.exe so I can test it over here?  If not it will take me a while to get a build system going, plus I think my trial period for MS Dev Studio has expired (I don't use it often ? ).  Thanks!

 

PS I was thinking about the "signature" bytes that could be used for auto-detecting.  I forgot that for each game that supports it (WoW Arcade, Galagon and ZK coming up), I do display the word "QUADTARI" if one is detected on startup using my text engine.  The byte values of this string "QUADTARI" is: 0x1B 0x1F 0x0B 0x0E 0x1E 0x0B 0x1C 0x13 (A = 11 decimal/0x0B, etc in case I counted wrong). :)  This would be helpful to set the left port to QT joystick at least for the already released games, and we can come up with something more elaborate for the upcoming games.  I can send you the ROMs for Galagon and WoW if you want to give it a test.  

 

 

 

 

Link to comment
Share on other sites

14 minutes ago, johnnywc said:

Thanks TJ!  When I get some free time, I will do some testing to figure out what the minimum number of cycles is between switching and getting an accurate reading from the controller. 

Thanks.

 

14 minutes ago, johnnywc said:

I'm not sure how to test this on R77; do you mean connecting an actual QuadTari to the R77?

Yes, that would have been the idea. Directly and via OTG cable and 2600-daptor. I suppose only the latter might work.

 

14 minutes ago, johnnywc said:

Okay, I can do that also.  I was thinking that for the SaveKey it should have to run in Joystick port 2 (which is the first joystick connected to the QT connected to the right port).   The reason is that the Savekey detection and reading/writing all needs to be done when the the QT is active on that controller (i.e when DUMPORTS is low).  On startup when a savekey is detected, DUMPORTS will be low so it will be checking the first joystick on the right QT which is "Joystick 2".  Joystick 4 is the extra joystick connected to the right port and will be read when DUMPORTS is high.  I guess we could support QT Savekey/Joystick AND QT Joystick/Savekey, but it's probably easier to just have it support one or the other.

No problem, the current code supports both combinations.

 

14 minutes ago, johnnywc said:

If you're building on Windows, any chance you can send me via PM the stella.exe so I can test it over here?  If not it will take me a while to get a build system going, plus I think my trial period for MS Dev Studio has expired (I don't use it often ? ).  Thanks!

Will do. It is still WIP, but joysticks already fully work.

 

14 minutes ago, johnnywc said:

PS I was thinking about the "signature" bytes that could be used for auto-detecting.  I forgot that for each game that supports it (WoW Arcade, Galagon and ZK coming up), I do display the word "QUADTARI" if one is detected on startup using my text engine.  The byte values of this string "QUADTARI" is: 0x1B 0x1F 0x0B 0x0E 0x1E 0x0B 0x1C 0x13 (A = 11 decimal/0x0B, etc in case I counted wrong). :)  This would be helpful to set the left port to QT joystick at least for the already released games, and we can come up with something more elaborate for the upcoming games.  I can send you the ROMs for Galagon and WoW if you want to give it a test.  

That signature can be added, no problem. It will be used for left and right port. To allow single ports, I have prepared "QUADL" and "QUADR" for now.

 

Any test ROMs will help.

  • Like 1
Link to comment
Share on other sites

I hooked up the QT to the Retron77:

 

- when hooked up to the front Retron left port, pushing the first QT joystick button 'left' brings up the Power On menu in Stella.  Once in the menu, pressing the joystick button opens up the selected dropdown and pressing left closes the dialog window.  The 2nd QT joystick does nothing (as expected).  My guess is that perhaps the Retron77 is detecting the QT as a paddle since INPT1 is high on startup, so only left works which is mapped to the first paddle button. 

- when hooked up to the 2600dapter through OTG cable, neither joystick works at all.  This may be a 2600dapter issue where it's detecting them to be paddles perhaps.  

 

Question: is there a way to use the OTG USB controllers to navigate the menu?  Also, can you hook up a real AtariVox to the OTG and have it work on the Retron77 with voice?  I can do it on my PC but was wondering if it would work for the R77 also.  I have the USB serial adapter needed to connect the AtariVox to a USB port.

 

I may reach out to the 2600dapter developer and see if possibly we can get QuadTari support added to it.  :)  

 

 

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...