Jump to content

johnnywc

+AtariAge Subscriber
  • Content Count

    2,579
  • Joined

  • Last visited

  • Days Won

    6

Posts posted by johnnywc


  1. On 9/20/2020 at 1:04 AM, adamchevy said:

    How are things coming along with Gorf? 

     

    14 minutes ago, adamchevy said:

    Guess nothing, that’s ok I know your very busy with other excellent projects. I just love me some Gorf! Almost as much as I like Boing! See what I did their!

    TLDR:  read succinct response above. :D 

     

    Hi there! 

     

    Darn - I meant to reply to this last week but I totally spaced!  🥴

     

    Unfortunately there hasn't been any progress on Gorf Arcade since February.  We have added in all the speech phrases (thanks @Nathan Strum!) and the game is somewhat playable, but we probably won't have a demo available until the end of the year when we hope to debut it on @ZeroPage Homebrew's Twitch stream. :D 

     

    The good news is that we have finished Avalanche and Zoo Keeper (both expected to be released in the Atari Age store in October) and we have made great improvements to Robotron (now named RobotWar:2600) and are have almost completed development.  We're in that annoying phase where we are looking for more ROM to add in bells and whistles.  We originally had to remove the scoring animation story sequence to fit in all of the new options like co-op, two players, additional sound fx and animations, etc. but I am happy to report I was able to squeeze it all back in. :thumbsup:  Right now I'm focusing on fixing intermittent screen rolls on wave 30 and 40 advanced (when there are 100+ enemies on the screen).  We plan on releasing Robo-X in early 2021 (David Exton aka @liveinabin is making great progress with the artwork!).

     

    Well, I guess this ended up being an update for Gorf Arcade and Robotron. ;) 

     

    Thanks,

    John

     

     

     

    • Like 12

  2. 6 hours ago, spspspsp said:

    I come back to this demo every now and then. It's great fun. I prefer it over the copy I have for my A800.

     

    Robotron.thumb.jpg.9ba6a9e950e780b7295213442264b6cc.jpg

    Wow - that's a great score!  :thumbsup: 

     

    6 hours ago, spspspsp said:

    Have you had a chance to examine why sometimes the missiles appear black/invisible sometimes? I was able to reproduce that again a few times in this game.

    Yes, I believe it only happens on the '9' levels, right?  (9, 19, 29, etc)  It's because the border is invisible on that level (like the arcade) and the player shots are the same color as the border.  The color change to the border color is happening a little too late on the left side and a little too early (from the color of the grunts/electrodes) so the missile can't be seen.  I have fixed this in the most recent version and it will be included in the next demo (that I will upload soon).

    6 hours ago, spspspsp said:

    This particular play through took about one hour, then I just let my lives go. I really should spend more time on the other levels, but I like that i can just kinda zone out on novice.

    Advanced should definitely be a bit more challenging. ;)  Topping off on level 9 reduces the difficulty too as there are 71 more unique levels in the game for Novice (40 waves on novice, then 41-60 are repeats of 21-40 but on standard, and waves 61-80 are repeats of 21-40 but on advanced).

    6 hours ago, spspspsp said:

    I don't know how the arcade does it, but is it also not possible to know how many lives you have above 8 lives there too? 

     

    R:2600 can only display up to 8 reserves; I'm not exactly sure how many are displayed in the arcade but it's probably about the same.  My rule of thumb:  If you have more than 8 lives in reserve, you should probably play a harder skill level.  :P  ;) 

     

    Thanks for the feedback!

     

    John

     


  3. On 8/28/2020 at 11:30 PM, Fungi said:

    Would it be so bad to rename it, oh I don't know, Robotron: 2600?

     

    Unfortunately, we need to steer clear of the word "Robotron" so that will not be part of the name. 😕   2600 is currently on the table as the 'year' though... ;) 

    On 9/3/2020 at 2:16 AM, adamchevy said:

    I’m pretty damn excited for this game to come out! Co-op Robotron is the stuff my dreams are made of.

    Thanks!  My son and I have been played probably 10 hours of Co-Op and I can tell you it's fun, challenging and pretty stressful, especially on the later levels! :o   PS Great avatar! ;)  


  4. On 9/7/2020 at 5:05 PM, Jase said:

    You've summed the sparx rules up quite comprehensively John!

    Oh good, I'm glad I understand it somewhat. ;)  

    On 9/7/2020 at 5:05 PM, Jase said:

    The only other thing I would add is that when they change to super sparx, they chase you up your stix as you are drawing. Once you have completed the line the super sparx continue on their path. Suffice to say that a spark is designated to move either clockwise or anticlockwise around the perimeter and cannot change its direction.

    I've never gotten far enough to see the SUPER sparx!  It sounds like they act like a fuse except they'll come after you even if you're not moving while drawing stix (which I think is what triggers the fuse).

    On 9/7/2020 at 5:05 PM, Jase said:

    You probably knew that already!

    Yes, I figured each sparx is designated as clockwise or counterclockwise and that will determine which direction the sparx will follow along the outside border or if there are multiple options (ie. a clockwise sparx heading left will turn up if it can vs. turning down).

    On 9/7/2020 at 5:05 PM, Jase said:

    One of the first things I do on a new wave is make up the trap as you described at the top of the screen to trap the new sparx. Somehow, occasionally one or two do actually escape eventually. No idea how, and it can take a while (sometimes I can spend ages completing a wave the way I play, trying to maximise my score).

    Yes, I've seen that strategy taken on that YT video. :thumbsup:  Once I get a playable POC, I'll see if the limited horizontal resolution (40 PF pixels) takes away too much from the Qix experience; if so we'll probably abandon the project.  I'm hoping a Qix-like game will be good enough for players so we can continue on! 🤞

    On 9/7/2020 at 5:05 PM, Jase said:

    More than happy to answer any other questions!

     

    Thanks!  At some point once I have something playable I will post a demo here and any feedback will be appreciated! 

     

     

    • Like 2

  5. Back to Qix; any experts out there that can tell me what the 'rules' are for what paths the sparks follow?  

    • I know two start the level at the top and one moves clockwise and the other clockwise around the border
    • If an area is filled in the middle by your marker, the sparks will follow the new outside border of the un-filled area
    • If a spark is caught on a border that becomes an inside border after an area is filled, it seems to follow the previous outside border trying to get to the new outside border (if that makes sense)
    • If planned carefully, you can 'trap' a spark by having it get stuck following an inside path that has no way to get to an outside path based on their movement.  An example of this can be seen in this YT video.
    • If you place the 'trap' on the top middle, when the spark timer (the red timer) runs out and new sparks are spawned, they are also stuck in the trap

    Any help or clarification would be appreciated! :D  

     

    Thanks,

    John (a casual Qix player ;) )

     


  6. On 9/3/2020 at 4:54 PM, sramirez2008 said:

    Oh I can't wait to see on the 2600. But I'd like to see Lunar Lander ahead of this one. 

    That reminds me; I forgot that was shown on James' ZeroPage Homebrew show and since it's completely playable, I should at least list it as a WIP. :) 

     

    EA is one of my favorite arcade games from back in the day so if the BUS issues can be resolved, that will quickly move to the top of my priority list. :D 

    • Like 3

  7. 1 minute ago, RevEng said:

    Yes indeed, they are the same bits. I think we were just trying to push or pull things for troubleshooting, but I'm hearing that you're using the paddle lines, so definitely you need to not enable two-button mode. It also may be a small issue on the 7800 for two button games, if QT is supposed to act like a pass-through for one player games.

    Okay great thx for the confirmation!  Yes, the QT acts as a pass-through for one player games that aren't QT compatible (meaning, they don't explicitly enable/disable DUMPORTS to switch the multiplexer).  If DUMPPORTS is kept low, the QT will run in 'low' mode which means joystick 1 will always be enabled.  The 4 directions and the button are mapped; pin 5 and pin 9 are not mapped from the joysticks since those are used as the select line from the Atari. :) 

    1 minute ago, RevEng said:

    Good stuff on the QT detection. I've made a couple 7800 games, and ported another from the A8, but the majority of my hobby time is spent developing 7800basic (bB for the 7800) and the a7800 emulator.

    I may have to take a look at 7800basic as I've always wanted to try my hand at 7800 development (and 5200 development also, but that's another story).  Maybe we can work together to add QT support to 7800basic once the QT is actually released (soon hopefully). :D 


  8. 17 minutes ago, RevEng said:

    You're welcome. Yep, it actually defaults to single-button mode. It's controlled by a couple RIOT PORTB bits.

    Great - thanks for the head up!  I can't visit that site unfortunately (Norton gives me the RED SCREEN OF DEATH), but are these the same bits that I used above to disable the pull ups when I was troubleshooting the 7800 button issue?

    17 minutes ago, RevEng said:

    And yes, I don't see why single-button games wouldn't work with QT. If that QT startup state held very long? The 7800 has a bios that runs for at least a second or two, prior to control being handed over to the game.

    The QT startup state is just it's normal state; INPT0 will always be low (hooked up to ground) and INPT1 will always be high (hooked up to a 10K pull up resistor/vcc) as long as you don't enable DUMPPORTS, at least I think that's true. :D If so, you should be able to check those bits at any time after the 7800 bios is done.  Are you a 7800 developer by any chance?  I can always reach out to Bob aka PacManPlus to see if he would be interested in testing and perhaps even making a 4 player game for the 7800. 


  9. 12 hours ago, Danjovic said:

    @johnnywc, you're not missing anything, lol! The switching times for the mux ICs are really low.

    Adding a few CPU cycles may compensate, though, for the capacitance of the controller wires that altogether with the pullup resistors form an RC network asmuch as a paddle.

    It is possible to make some measurements of the capacitance of the wires of a typical controler and do some math to estimate ẗhe time, for instance:

     

    Consider 1nf of total capacitance (which is pretty high) and a threshold voltage of 2.0 volts for Atari to identify a voltage as high, being powered by 5Volts and using 10K pullup resistors you get around 5us

    http://mustcalculate.com/electronics/capacitorchargeanddischarge.php?vfrom=0.1&vto=2&vs=5&c=0.000000001&r=10000

     

    The opposite way, discharging from 5 volts down to 0.3 volts should render about 32us.

    http://mustcalculate.com/electronics/capacitorchargeanddischarge.php?vfrom=5&vto=0.3&vs=0.1&c=0.000000001&r=10000

     

    Again this is a rough estimative with a pretty high value for stray capacitance (1nf).

     

    Nevertheless I dare to say that a single horizontal line should be safe for all cases.

     

    Thanks for the confirmation!  I'm going to test with a 3 cycle delay (read SWCHA immediately after updating VBLANK) and see what kind of results I get.  We are going to keep a 1 scanline delay in Stella and recommend that for developers on real hardware.   Galagon, WoW and Zoo Keeper are already released or about to be released and have a minimum 20 scanline delay so those will be all set. :)  

     

    PS Silly question, but what does 'us' stand for in your estimates above e.g. '5us', '32us'? :dunce:  


  10. 17 hours ago, RevEng said:

     

    Paddles can be read, and the entire process is the exact same as on the 2600. But yes, this is provided you've set the console to single-button mode. So single-button mode should work fine, as far as your device.

    Thanks!  I didn't realize there was a 'single button mode' for the 7800... I assume that's done by setting a specific bit/register?  

    17 hours ago, RevEng said:

    In two-button mode, you indeed are using both paddle lines to read the buttons. The controllers themselves are even more complicated than that, because they have extra circuitry to ensure both buttons respond on the regular joystick button line if the console is in single-button mode. (or if the controller is plugged into a 2600)

     

     

    Thanks for the explanation!  So it sounds like someone could develop a 7800 game that is compatible with the QuadTari and support 4 joysticks if they set the console to single button mode, and then follow the QT SDK to detect a QT (INPT0 is low and INPT1 is high on startup) and switch/read the 4 joysticks using VBLANK/DUMPORTS (charge or discharge the paddles) and read SWCHA/INPT4/INPT5.  :thumbsup: 

    • Like 1

  11. 3 minutes ago, Karl G said:

    If I'm understanding correctly from browsing this topic, it looks like the quadtari will only work for 2600 games when using it on a 7800?

    Hi Karl,

     

    No, that is not correct; apologies if that was suggested.  The QuadTari hardware works on the Atari 2600 AND the 7800 (and most likely the Atari 8-bit computers also; more details to come). :)  

     

    It currently is supported only by 2600 games (Galagon, Wizard of Wor, and the upcoming Zoo Keeper, Robotron and Gorf Arcade) but support can be added to any 2600 game.  I'm not a 7800 developer but if the reading of the joystick ports and charging the paddles through the VBLANK is similar to the 2600, I would anticipate that QuadTari support could be added to a 7800 game also.  This may not be true as I don't know if 7800 supports paddles for 7800 games and the QT mechanism relies on the paddle charging mechanism to select which joystick to read from.   Now that I think about it; since the 7800 has a 2-button controller, it's most likely using pin 5 and pin 9 (the 2600 'paddle' pins) to read the extra button so perhaps the QT would not work on a 7800 game.  Either way, the QT does work on a 7800 running a 2600 and on a 2600 running a 2600 game. :D  

     

    Hope that makes sense!

     

    John

     

    • Thanks 1

  12. Hello all,

     

    I've been working with the Stella team as they are adding in QuadTari support. :thumbsup:  

     

    One thing that they're asking for is the minimum amount of time needed between switching the muxs and safely reading the ports.  My original implementation tries to maximize the time between enabling/disabling the select line (via DUMPORTS) and reading the values from SWCHA (joystick direction) and INPT4/INPT5 (the buttons).  To do this, I read the ports at the beginning of VBLANK assuming DUMPORTS is high;  DUMPORTS is then disabled at the end of VBLANK (when the screen is drawn), and then I read the ports at the start of OverScan (with DUMPORTS low), and then immediately set DUMPORTS high again for the next port read in VBLANK.  This has a huge delay of at least 200 scanlines between setting DUMPORTS low in VBLANK and reading the values in Overscan, and a delay of at least 20 scanlines between setting DUMPORTS high in overscan and reading the values in VBLANK.

     

    So, to answer the Stella's team question about the minimum amount of time, I referred to the 4053 multiplexer datasheet.  I may be misinterpreting the values, but it states a "On time - Max" of 720ns and an "Off time - Max" of 450ns.  I believe this refers to the time to switch the multiplexer from "off" to "on" and vice versa, respectively. 

     

    I did some math and it takes approximately 837ns to execute 1 cycle on the 2600.  (1 / (262 scanlines/frame * 76 cycles/scanline * 60 frames/second)) = 8.37 e-7 = 837ns.  (hopefully that's right)

     

    If so, it would seem that you could "safely" read from the ports 1 cycle after enabling or disabling DUMPPORTS (selecting on or off for the multiplexer), since it takes 837ns to execute one cycle on the Atari but the max "on time" and "off time" is < 837ns. :ponder: 

     

    So, I did a test and modified my code so that it reads the ports when DUMPORTS is low (to read the first joystick on each port), enables DUMPORTS, and then immediately reads the ports again (which would read the second joystick on each port), and it works without any issue. :thumbsup:  This is with a delay of 21 cycles between setting DUMPORTS and reading SWCHA, which is certainly much less than 21 scanlines. :)  I am going to test with reading SWCHA immediately after setting DUMPPORTS which should in theory still work since that takes 3 cycles or about 2500ns, well above the maximum on/off times in the spec sheet.

     

    Anyway, I thought I'd share my results and see if there is something I may be missing.  To be safe, I think we're going to keep the delay between setting DUMPPORTS and reading the ports to 20 cycles in the Stella implementation, unless we can definitively come up with a smaller reliable max delay.

     

     

     

     


  13. 16 minutes ago, Kaboomer said:

    Did I miss "Elevator Action" on your signature line for POC?  ;) 

    Good catch!  I kind of stopped working on that until the BUS issues are resolved, but I guess there's no harm in listing it as a POC. ;)  

    • Like 1

  14. 21 minutes ago, stephena said:

    The ROM has to have 'QuadTari' set as its controller, otherwise it will default to normal joystick mode (single controller per port).  Or can Stella now autodetect the ROM as using QuadTari?  If so, then ignore this part.

    Okay, I was testing with the community build on the R77 and I don't think QT support has been added into that, or at least I don't have that version.  I think TJ wanted to check to see if the first joystick of the QT would work since when connected to a real Atari it will act as a regular joystick when used with a non-QT game (like Combat, etc).  

    21 minutes ago, stephena said:

    Likely not without extra work.  The AVox-USB adaptor is used to create a virtual serial port, which Stella then 'talks' to.  However, I'm not sure if the drivers for USB virtual COM ports has been compiled into the Linux image that the R77 uses, but I would guess that they aren't.  If they were, then I see no reason why it wouldn't work in R77 too.  Remember that behind the scenes, the R77 is simply Linux running an ARM version of Stella, and the OTG/USB route bypasses the builtin ports completely.  So as long as we can get Stella to have a COM port, there's no reason why the AVox couldn't work.

    I'll give this a test and see what happens.  If the R77 can detect the USB-serial adapter, we should be good to go.  What would be the effort to add in the USB COM drivers to the R77 build?  I'm sure there are others that would like to have AtariVox voice for the games that support it. :) 

    18 minutes ago, stephena said:

    Honestly (and I've said this before), if one could remove the built-in controller ports and put two 2600-daptors there instead, it would make things much more compatible.  That's essentially what we're doing with the OTG cable anyway.

    That would be great!  Maybe a Retron77 v2? ;)  Hopefully there's some aspiring young hardware hackers that can make this happen - I would certainly pay for this!  My dream is to be able to play a true game of Wizard of Wor Arcade on the R77 with a QuadTari/2 joysticks in the left port and an AtariVox with voice in the right port. :D 

     

    Thanks for the info Stephen, it's much appreciated!

    John

     


  15. 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.  :)  

     

     


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

     

     

     

     


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


  18. 22 minutes ago, BIGHMW said:

    Checking in September 1st, how's the game going so far??? 

    Hi there!

     

    Unfortunately there has been no progress on Qix since the POC was announced (we still have not committed to completing it, but we most likely will sometime in 2021 ;) ).  The last few months have been spent finishing Zoo Keeper (being released in the AA store very soon) and Robotron which we hope to release by the end of the year.

     

    2021 will be busy as well with Gorf Arcade, Champ Sports Baseball, Qix possibly, and most likely a "secret game" announcement in May as we've done the last two years if we feel inspired again. :D 

     

     

    • Like 2

  19. 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 😕 ).

     

     

×
×
  • Create New...