johnnywc

Sounds good! Joystick/Joystick would be the most common for sure. Gotcha. Oh okay, then perhaps it won't work. I'll give it a shot! 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!

Oh good, and thanks for creating the issue! 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. Cool, I'll look to pick one up. 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 ) 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). Yes, I agree. Agreed. Joystick/Savekey combo would probably be the only useful combination at this point. Agreed. 3 player with Savekey would be very helpful. Excellent! I'll have to see about updating my test app to support this! 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). Sounds good. Straihgtforward is better than complicated. 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

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. 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. 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 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. 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). 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. 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. Thanks! John

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. Let me know if you need more info and whatever else to help out the Stella team! 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. I will figure this out today and get back to you with the value. 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.

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. 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. 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

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. - 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"? 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

Thanks! Yes, I believe someone at the beginning of this thread did exactly that. Just map your controller (I assume you're using the 2 thumbsticks) to joystick 1 and joystick 2 in Stella and you should be good to go! Thanks! Good point on the colors... we have changed them in the latest build so one player is purple and the other is orange, and it seems to work pretty well. The helmets match the color of the skill level so those will be green, blue or red. We'll be posting an updated demo soon that will have co-op mode enabled so players can give their feedback.

I'll check with Al, but since it's not a critical 'bug' (and I use the term loosely as it's really just a smaller delay than my original intention when holding down the joystick when navigating the menus), I don't think there will be a rush to build new carts with an updated binary. Plus, both of those games have < 8 bytes free and adding in this fix takes 8 bytes so it's not as simple as fixing the 'bug' without potentially breaking something else. 😕 From this point on we'll consider it a feature: "Both Galagon & WoW 'feature' blazingly-fast menu turbo-navigationTM " ⏩

@root42 You were right, there is a bug in the menu navigation code. I had made a change to allow the letters when selecting high scores to scroll faster, but that uses the same timer as the menu navigation so it made that faster too. 😕 I fixed it for the final release of ZK; unfortunately the 'bug' is in Galagon and WoW Arcade, but this is the first of it ever being mentioned so it's probably not a big deal, but I'm glad it's fixed now! Thanks again!

Soon to be THREE consoles (2 2600's and a 7800). Dislikes: Lightning 😕

This is amazing Chris and Nathan - it plays and sounds as great as it looks! Day 1 purchase for me!

Note taken... FF is a great game and the Robotron engine would certainly lend itself nicely to that type of game!

Yes, the game is very fast paced! FYI we have made numerous changes since the last demo (about 50), including balancing the difficulty between the skill levels. Hmm, I'm not sure what you mean here. I'll fire up Mappy and Zoo Keeper and compare the menu navigation and see if they are similar. Certainly as you get better a game can take a while, especially if you use the continues. I will typically play a game plus 3 continues and it takes about 20 - 30 minutes. Hmm, I'll think about this. I like to keep certain things consistent between all the Champ Games (including default initials). With that said, if you have an AtariVox/Savekey to save your scores, it also saves your last initials (for both Player 1 and Player 2) so you only have to change "PL1" once. I agree, the gameplay is very unique and one of the reasons why it quickly became one of my favorites to play on MAME (I never saw or played Zoo Keeper "back in the day") and ultimately why I decided to make a 2600 version. Thanks for the feedback, it's very much appreciated! John

Hello there! As we near the release of ZK, I've been going through the old development thread and I completely forgot to answer your question - sorry about that! Yes, the ZK high score table will display scores up to 99,999,999 by removing the rank #. Hmmm, that's strange. I'm pretty sure on level 1 the net is the 2nd to the last item that appears (one more root beer appears before the end of the level). I haven't seen this happen over here but will keep an eye out for it. Thanks! John

Thanks for the offer! Nathan T. aka @gauauu is handling the PCB and enclosure design; I'm sure he would welcome the assistance.

Good news! I received both 7800's from @McCallister today and they both work flawlessly with the QT, so I think we can consider that one solved (especially since I distinctly recall it working on my 7800 too). Turns out my 2nd controller port on my 7800 isn't working now either, so there's a bunch of things wrong with it. Anyone have any recommendations for a service that can repair a 7800? So as long as we don't need pullups on the joystick inputs (and it sounds like we don't), we're good to go! Nathan T. @gauauu is itchin' to get the design finalized and put into a case for a hopeful holiday release! Thanks again everyone for the help! John

Okay great, thx for the info, that makes sense about the mux. Okay, so since the mux is really just a relay, there really isn't a need for a pull up resistor on the joystick inputs before the mux, right? It sounds like the pullups in the Atari will take care of it then. I'm still a bit confused why the measurement at the joystick inputs fluctuates between 5.2V to 3.6, but perhaps that doesn't matter since it's above 2.0V? Thanks again! John

AtariAge member @McCallister has graciously offered to send me a couple 7800's to test with and they should arrive tomorrow; fingers crossed they just work and it's my 7800 that has the problem. 🤞 If none of them work, I'll assume my 7800 is fine and then we'll need to explore options to hopefully resolve the issue by updating the design. 😕 In the meantime, above I mention the voltage I'm measuring at the joystick inputs when they're open and it's between 5.2V and 3.6V. Is this okay? I added a pull up resistor bank (10K) and the voltage stays between 5.1 and 5.5 volts. Do you recommend that we add pull-up resistors to the joystick inputs? I'm worried that when it dips to 3.6 volts it may register as a low to the mux, but then again that may be well within the tolerance. Any suggestions are welcome! Thanks, John

Wow! Great job Nathan! I have not achieved the coveted 1,000,000 point jump... yet!

Hello there! Sorry for the late reply.... We are on Release Candidate 7 and the final version will be available on cart in the AA store soon!

We're working on it now Steve! I just finished adding in co-op mode that will allow you and a friend to battle together! We're still testing it, but here is how it works for now: the players are working together to achieve one high score and they share the pool of reserve lives. two mutants (different colors) start the wave in the middle of the screen each player independently controls a mutant with their controller. Note: for now, only single joystick control is supported for each player, but the final version will allow BOTH players to each use two joysticks (one to move, one to fire) using the QuadTari to balance the game play, both players have a pool of 4 shots total that they can fire at any one time (meaning if one person is shooting, they can shoot 4 missiles; if both players are shooting, they each will fire as long as there are < 4 shots on the screen) half of the enemies pursue player 1, the other half pursue player 2. If one player is removed from the wave after being killed, all enemies will pursue the remaining player. If one player is killed during a wave: On Novice, the player stays on the screen in a zombie state (cannot move or fire). If the other player touches them, they are revived (invincible for 2 seconds). If the second player is killed before they can revive the first player that was killed, a life is lost and the wave resets with the remaining enemies. On Standard, the player is removed from the game. They will return at the start of the next wave or if the other player is killed during the wave and there are reserves left. On Advanced, the team loses a life and the wave resets with the remaining enemies (like normal) We hope to post a demo of co-op mode soon for people to test out and give feedback. Thanks, John

Hello all, Looking for a working NTSC Atari 7800 system for testing. I live in CT so something close would be preferable. Thanks! John

Thanks, I'll give it a shot, but I must be honest that 90% of what you said doesn't make sense to me. 😛 I'm sure once I open it up and find some schematics online it will be a little more clear. In the meantime, I'm going to try to acquire another 7800 to test to see if this is a problem with the QT or my 7800. Thanks again! John

Update: I modified my test program to set bits 2 and 4 of SWCHB to '0' (as it seems that they default to 1) and the voltage measurements for pin 6 on the Atari are the same with no buttons/1 button/2 buttons pressed as the bits being set high. 😕

No worries, I was able to bring it up on my phone. Okay, I did some measurements of pin 6 on the Atari and they are the same with my old multi-tap app that doesn't set the bits of SWCHB and the new app that sets bits 2 and 4 high for SWCHB: No buttons pressed: ~5.40 V one button pressed: ~5.00 V both buttons pressed: ~4.63 V I think I may be setting the bits wrong; should they be set to '0' and not '1'? The reason I ask is that I'm displaying the value of SWCHB in both applications and for both they all display 00111111 (the two 0's are for the difficulty switches that are in the B position), so it seems that bits 2 and 4 default to 1 even if you don't do a write to SWCHB. I did measurements for pin 6 at the Atari on the working 2600 and they are the expected values of 5.52V (no buttons pressed), 2.46V (1 button pressed) and 0.15V (both buttons pressed). I'll modify the program to write 0's into bit 2 and 4 and see if that makes a difference. Thanks! John PS Regarding the other question about the "floating" voltage I'm getting measuring the inputs at the joystick that I mentioned above. It looks like it fluctuates slowly between 5.2V and 3.6V when the switch is open. Is this okay? Do you recommend a pull-up resistor on the joystick inputs? I added a 1M (I'm sure smaller values would suffice too) pull-up resistor network (we had these in the previous designs) and the voltage now fluctuates between 5.5V and 5.1, but I'm not sure if it's needed. Thanks!