johnnywc
-
Content Count
2,579 -
Joined
-
Last visited
-
Days Won
6
Posts posted by johnnywc
-
-
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!
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.
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
) 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).
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.
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.
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
-
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 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.
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
-
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.
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!
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.
-
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
-
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
-
On 8/20/2020 at 4:54 PM, Albert Penello said:This is amazing! Great work to the team.
Is it possible for those of us on emulators (using Xbox or Playstation controllers) to enable to dual sticks?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!
15 hours ago, Kiwi said:Very cool! Both player look almost alike, maybe paint the 2nd player's head red would make it easier to difference between player 1 and 2.
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.
-
4
-
-
10 hours ago, Andrew Davie said:What's the call on the 'bug' in those games? Produce all future carts with the fix included, or leave the bug as-is in those?
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 " ⏩
-
3
-
-
On 8/11/2020 at 2:44 PM, root42 said:The menu feels a bit janky, i.e. is reacts too quickly to joystick movements? Not sure about that, but it felt more relaxed in Mappy. The latter being much more slowly paced overall. 18+ grown ups, so were not popular here.
@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!
-
2
-
-
5 minutes ago, Nathan Strum said:(On the plus side, now I know something else to look out for when repairing my 2600. And John's.
)
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!
-
1
-
-
On 8/12/2020 at 6:20 PM, insertclevernamehere said:Note to the great John Champeau. Much in the same way making Scramble made it easier to make Super Cobra Arcade, I'm hoping that making Robotron will make it easier to make Food Fight. Hint hint.
Note taken... FF is a great game and the Robotron engine would certainly lend itself nicely to that type of game!
-
5
-
-
On 8/11/2020 at 2:44 PM, root42 said:I have only played this game for two days, and never played the arcade version, so my experience is limited. But maybe I can already give a bit of feedback. First of all: I think the game is great. Technological marvel, the gameplay is also solid. It seems very fast paced. The easy mode seems a tad bit simpler than standard, with one more life, but not much easier. It is really fast paced and this shows as I lost even the first level in the first couple of tries. Right now my skill is at beating round 5 on easy and round 3 on standard.
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.
On 8/11/2020 at 2:44 PM, root42 said:The menu feels a bit janky, i.e. is reacts too quickly to joystick movements? Not sure about that, but it felt more relaxed in Mappy. The latter being much more slowly paced overall. But I guess the arcade version of Zookeeper is similar to this. A whole game definitely takes much less time for me. But maybe that will change in the future when I get better.
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.
On 8/11/2020 at 2:44 PM, root42 said:One minor gripe: Can we use AAA as the default letters for the highscore? PL1 is subjectively so far away from useful letters for the highscore table... I already disliked that in Galagon.
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.
On 8/11/2020 at 2:44 PM, root42 said:The whole gameplay is interesting, much like a reverse breakout. Never seen it before, but alas, we didn't have arcades in Germany when I was a kid. Arcade games were strictly for 18+ grown ups, so were not popular here.
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
-
2
-
-
On 5/18/2020 at 10:14 PM, spspspsp said:Does the high-score table in ZooKeeper function like that in Robotron? Specifically, for scores over 1M, will the "rank" number disappear? I am not to 1M yet, but with a bit more practice should be able to get there. Again, this may be trickier in the full version, but given how the points awarded for jumps doubles each time you jump over an additional animal, this shouldn't be too hard.
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 #.
On 5/18/2020 at 10:14 PM, spspspsp said:Also, I think I noticed a bug: I was on level 1 and there was a net on the outside of the cage, but then an elephant escaped at exactly the spot where the net was located and the net disappeared. Usually, items aren't supposed to disappear like that, right? This was the last item and the level hadn't ended yet.
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
-
On 8/5/2020 at 10:09 PM, Danjovic said:It is a good idea to choose a case and then design the pcb around it.
If you need some help with the pcb please tell me.
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
-
2
-
-
12 hours ago, ChildOfCv said:TTL spec says anything 2V or above is high. And for the joystick inputs, the multiplexer doesn't identify the voltage as high or low. It's merely a relay that simulates connects plugging in one joystick or the other. That's what makes this a nice design, if it is made to work.
Okay great, thx for the info, that makes sense about the mux.
QuoteBut still, the 6532 of the 2600 has internal pull-ups on each line in input mode. So it should be reading near 5V on the joystick inputs at least. Then the 2600 adds a 10K pull-up resistor for the button. The 7800 should also have that pull-up on the joystick lines since it also uses the 6532.
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
-
37 minutes ago, Nathan Strum said:Managed to get a million-point jump on the latest release candidate.
(This is a composite of about 5 frames to show everything that was flickering).
Wow!
Great job Nathan! I have not achieved the coveted 1,000,000 point jump... yet!
-
On 7/18/2020 at 8:46 PM, Prizrak said:Will there be another binary released or is it close enough to completion that we wait for a cart release?
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!
-
1
-
-
17 minutes ago, sramirez2008 said:Yep. @johnnywc Bring on Robotron!
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
-
9
-
Hello all,
Looking for a working NTSC Atari 7800 system for testing. I live in CT so something close would be preferable.
Thanks!
John
-
1 hour ago, ChildOfCv said:Then there may be some damage to the system. Maybe you could locate the transistors and test the voltages at the base, with the output bits high vs low. Q5 and Q6 are the two that pull the voltage up. Q8 is the "master" which is switched on or off depending on TIA or MARIA mode. The base is the middle pin. Then with the flat side on the west, the output pin would be on the south.
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. 😕
-
4 hours ago, RevEng said:Yeah, it's my site. The reason Norton is complaining is because it hosts binaries that were built using open source tools, and AV vendors aren't technically savvy enough to tell the difference between "hello world" and a virus.
No worries, I was able to bring it up on my phone.
35 minutes ago, ChildOfCv said:Yeah it should be useful to see the voltages with port B in either state, and see if it makes a difference. If not, then it's possible that the transistors were affected too.
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!
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Quadtari
in Topics
Posted
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!