johnnywc

I'm a huge fan of the 8-bit version of Wizard of Wor; my brothers and I played it on the 800 for many hours and it was the main reason why I decided to update the 2600 version. I would welcome an updated 8-bit version too!

TLDR: read succinct response above. 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. 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. 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

I did not know that! I will bring this up at the next RobotX staff meeting and see what the board thinks... I personally like it!

No worries, "Robot Ron" is too close to Robotron so we're going with RobotWar (year pending).

Have you been peeking? 👀 As it turns out, the current WIP name is RobotWar:2600, but we may end up switching :2600 for a year like :2184 (we want to stay away from 2084 and any -tron sounding names).

Wow - that's a great score! 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). 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). 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. Thanks for the feedback! John

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... 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! PS Great avatar!

Oh good, I'm glad I understand it somewhat. 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). 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). Yes, I've seen that strategy taken on that YT video. 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! 🤞 Thanks! At some point once I have something playable I will post a demo here and any feedback will be appreciated!

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! Thanks, John (a casual Qix player )

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.

Thx, I recall now! I guess 'ms' was already taken by milliseconds.

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

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

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'?

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

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. Hope that makes sense! John

Hello all, I've been working with the Stella team as they are adding in QuadTari support. 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. 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. 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.

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.

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). 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. 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. Thanks for the info Stephen, it's much appreciated! John

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.

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

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

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.

I will bribe Fred and see what I can do. Thanks! 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 😕 ).

Here's my top 10, I'm not sure if they're all early 80's though Pole Position Tempest Commando Galaga Spy Hunter Elevator Action Scramble Star Wars Vanguard Rip Off!