johnnywc

Thanks for saying this. I can assure everyone that Champ Games is not making ARM based games to belittle or take away anything from the games that don't use the ARM and it saddens me to hear that there are developers as talented as Andrew that feel that it's not worth pursuing their own projects for fear of their work being compared or judged. Andrew, you certainly have all my respect and it is pioneers like you, TJ, Dennis Debro, etc. that inspired me to get into 2600 games in the first place, and IMO Boulder Dash is an absolute masterpiece. I have been developing games for the 2600 for 13 years, starting with a 4K conversion of Lunar Lander, moving up to 16K for Lady Bug and Conquest of Mars. I then burnt myself out by working on 4 games simultaneously (Avalanche, Wizard of Wor, Rip Off and Moon Cresta) and stopped developing for 8 years. When I rejoined the scene back in 2015 and was introduced to DPC+ by Darrell, that inspired me to get back into game development because for me it was *fun* again! Making a game like Scramble was very satisfying and challenging, and for me the ARM just set the bar higher as to what my expectations were and opened up a whole new door to an opportunity to be creative. As much as the ARM may assist development (mostly because I can write game logic in C at the cost of using more ROM typically), the true challenge is still the 6502 kernels and bridging the two vastly different architectures to make a game that is fun and within the confines of the TIA (2 sprites, 2 missiles, the ball, and the low res playfield). I also program with the ARM because, frankly, I'm getting old and the development is much more quicker. I personally don't have the time or patience to work on a game for years and I take my hat off to those who can stick to a project that long (my limit is about 6 months ;)). Anyway, those are some of my thoughts, and back to what Karl G said; I think there is plenty of room for both types of games to exist. Right now I think I'm the only one making ARM games as Darrell is on hiatus and most of the games coming out this year look amazing (my personal favorite is Aardvark). Personally, I wish people would stop using the word 'cheat' to describe what we do as it does carry a negative connotation. I am very transparent with everyone who asks "what's the magic" behind my games so I think we should leave it up to the players to decide whether or not they want to enjoy them for what they are. Thanks, John

Great thx, I'll give it a shot. Okay, that makes more sense. I can run this test too. Will do! Thanks for the help, it's much appreciated! John

I modified my test software so the Color/BW switch enables/disables switching. When disabled, the left difficulty selects which joystick to test (joystick 1 or 2) by making the select line a constant 0 or 1. The interference does reduce when I disable switching and is the same regardless of which joystick is active. By reduced interference; with switching enabled, you see a constant sparkling white horizontal line at the bottom of the screen, about 3 inches long that gets more intense when you activate any switches on either joystick. When switching disabled, this line disappears. However, there are occasional 'dot's of interference, almost like static, that appear all over the screen, again only when you're moving the joysticks. This 'static' doesn't seem to improve whether switching is enabled or not. I'm not sure what you mean here, but I did wire the OE line directly to VCC and then GND to remove the select line connection to the Atari. With this the visual output seemed the same as using a constant select line as in step 1 (no switching). I alternated VCC and GND so it would activate one or the other joysticks to see if there was a difference. This seems to be N/A since both joysticks/octal buffers seem to be exhibiting the same behavior. I did modify Nathan's original design so I do have 2 select signals (the intent was to use them to select 1 - 4 joysticks) so I can test with two select lines. I think what you're saying is to connect one select line each to one of the octal buffers? Then in software I would first disable one buffer with a write to SWCHA and then enable the other buffer with another write to SWCHA? (I would then disable/enable the other in reverse order when selecting the second joystick). During VBLANK - read joystick 1 values - disable select line for joystick 1 - enable select line for joystick 2 During OVERSCAN - read joystick 2 values - disable select line for joystick 2 - enable select line for joystick 1 Of course it looks like the OE is triggered low so by enable I would write a 0 and by disable I would write a 1. Does that sound right? Hmmm can you elaborate what you mean by diode isolation for us newbies? I know diodes are used to ensure current flows only in one direction, but I'm not exactly sure what type to use and what pins I should be using them on. The joystick inputs? The select lines? Thanks so much for the help! John

I think I have some capacitors that came with my start up kit lol, I'll see what types they are and give this a try. By 'between VCC and ground', do you mean wire VCC to one end of the capacitor and ground to the other? Do you mean actually unplug the joystick from the multi-tap port? If so, I did try this and that didn't seem to improve. I actually put together a test app, but it's doing the same during the game. During VBLANK it reads the ports and stores the values in joystick 1 variable. Once completed, it then toggles the select bit so the other joystick becomes active (joystick 2). The screen is then drawn. During overscan, it then reads joystick 2 and stores the values in joystick 2 variable. Once completed, it then toggles the select bit again so the other joystick becomes active (joystick 1). Hmm I don't think I have a 555 timer so I'll have to look into getting one of those to perform this test. See below; I did run some additional tests suggested by Stephen. Thanks!

Thanks so much - this is very helpful! A picture is worth a thousand words. Thanks for the explanations! Yeah, I was pretty sure *not* hooking up VCC was a bad thing, thanks for the confirmation! As for the switch to multi-purpose the 2nd select line; I agree it may not make sense in the end, but I appreciate the time to explain some of the pros and cons (and the design). One thing I noticed in my tests today is the interference that Nathan saw with his original design. It's a white line on the bottom of the screen that will show up only when you're pressing the joysticks in any direction while hooked up to the multiplexer. I'm not sure what's causing it or even how to trouble shoot it. I don't have a oscilloscope or anything to take measurements, but I do have a potentiometer though. My next step while I wait for the other parts to come in (to test a 4 joystick version) will be to build the first circuit that was suggested that just used ground to select the joysticks. Thanks! John

Update: I finally had a few hours and put the circuit together with 2 of the octal buffers with the resister packs on the inputs, 1 inverter using 1 select line and it worked like a charm! I'm not seeing any interferencebut I'll need to test some more. It does work with Genesis controllers without any issue (the 2nd button isn't even wired up so that makes sense). One odd thing I noticed is that in my first tests everything worked, but after reviewing the circuit I realized I hadn't hooked up VCC to one of the octal buffers yet it seemed to work either with/without it. I did have VCC hooked up to the DIR pin for A->B and the output enable line hooked up so maybe VCC got fed to the chip through one of those? I ordered the decoders and will try to get 4 controllers/1 button working later this week. In the meantime I'm going to get the 2nd button on the Genesis controller working. Assuming all that works, I'll look into the switch option for 2 joystick/2 button mode and 4 joystick/1 button mode. I don't think I'm following your design completely, but once I get closer to that point I'll ask some more questions. I do understand the first part where you suggest wiring the switch to the 2nd line of the decoder (makes sense; in 2 joystick mode the 2nd line is always low, in 4 joystick mode it would be the value of the select line). I get a little lost with "the switch would have 2 poles and 2 throws".... I'm not sure what that means lol. Do you mean the switch is doing double-duty; one for the select line and one for the button 2 buffers? Thanks again for all the help! John

Like Stephen says, we are using the ARM processor in the Harmony cart to do a lot of the data preparation for the 2600 kernels that draw the sprites and for game logic. However, the 8 multi-color sprites on a line with no flicker has nothing to do with the ARM; this trick was done in Atari's Galaxian released back in 1983. With the fast fetch mode of the CDFJ driver we do have more cycles to update more TIA sprites; we use this extra time to draw the stars and an extra missile to reduce flicker on the other objects. The biggest advantage to me with ARM programming is the time that it saves me since I have developed a pretty robust sprite engine that I tweak for each game based on the requirements (playfield, multiple missiles, multi-color vs. single sprites, ). The extra ROM and RAM allows us to add in all the eye candy and extra features that we wouldn't be able to squeeze in 8 or 16K. I mentioned in another post that I believe a very good Galaga game could be made without the ARM using the technology from the 80's, but of course with the ARM the game can be much more polished and have more features, etc. However, I don't think a decent Mappy, Scramble or Zoo Keeper could be done without the help of the ARM, mostly because of the scrolling which would take up most of the processing time. Hope that helps! John

Hello there! It looks like the attachments are temporarily unavailable during the forum upgrade, but the links should be fixed soon! If they aren't corrected in the next couple days, I will re-upload the ROMs. Thanks! John

Agreed! I purchased this on cart when it was released, it's a lot of fun! I was hoping a whole line of 'Blip' games would follow... maybe someday!

Hello! Good questions! First off, I believe a pretty good Galaga port could be done with 16K and perhaps Atari's SuperChip which adds 128 bytes of memory (this was used in such games as Dig Dug, Crystal Castles, and Secret Quest). The Galaga kernel is basically an enhanced version of the Galaxian kernel that uses a combination of RESPx and NUSIZx (change object position and # of copies) to draw the enemies in formation, all with one sprite and no flicker, multi-color too. It should also be noted that the enemies in formation take 6 bytes of RAM to store (1 bit for each enemy). The extra RAM in the SARA chip would be used for storing the info on your ship, enemies in flight, reposition information for re-using sprites, missiles, etc. (you may even be able to get away without the SARA chip since Galaxian didn't use it either but it would be tough). With that said, of course having the ARM allows for a much more enhanced game to be developed. The original intention of the ARM (I believe) was to emulate the DPC chip found in Activision's Pitfall 2. Galaga uses the CDFJ driver which is an extension of the CDF, DPC+ and DPC drivers (in that order). One of the key features of these drivers is the ability to update a sprite in 5 cycles (the original DPC could do it in 7, and methods prior to that would be around 13 give or take a cycle). What this means is that more TIA registers can be updated per scanline, so Galaga updates both player sprites (multi-color if needed), the ball and both missiles. Those extra cycles also make it possible to overlay the text on the screen (if you notice, Galaga uses 208 scanlines for game play, with the score and status overlaying the playable area). The extra cycles also also me to repositioning sprites more often using 1 scanline, so sprite re-use is higher, therefore there is less flicker. Besides the kernel improvements, the ARM can also execute C code during Vertical blank (the time before the screen is drawn) and Overscan (the time *after* the screen is drawn). This is why I was able to port Galaga over in such a short time; I had the C code from my PC port of Galaga that I did back in 1997 (CHAMP Galagon) which I was able to reference, and in some cases just copy over (like the pattern data) with just a few changes (the PC games were written in VGA assuming a 256x200 playing area and the Atari play area is 144x208). Of course, the PC version of Galaga used much more ROM (400K) so squeezing all the game logic into 28K was no small task, plus I had the huge benefit of Nathan doing all the graphics and Ross doing all the sounds too! So, what does the ARM C code actually do? It can't talk directly to the Atari (that all needs to be done in 6507 assembler). Well, for me, in VBLANK (the time before the screen is drawn), it basically sets up all of the datastreams to be read by the kernels to display the graphics. It should be noted that there is not a lot of time to do this work; just clearing out the buffers that store the data to be drawn takes up most of VBLANK. In Overscan, I execute the C code that does all the movement and collision detection, plus play sounds (which is just TIA sounds). Anyway, I'm getting a little off base here, but to answer your question: For the game to run as is, it is using as much as the ARM as it possibly can as almost all the cycles in VBLANK are being used. However, if the ARM was less powerful, I would most likely be able to keep the same features but would need to be more creative in using the ARM's resources. But, as I said above, I do believe a very good Galaga game could be written without the ARM, with the big losses being the eye-candy, probably the star field, and a bit more flicker. Also the overlaid score/status area would be pretty difficult so you would have a shorter play area. I'm not familiar with the SuperFX or SA-1 Chips, but in my opinion a good Galaga game could be made with a less powerful chip. If we were going back to something that would have been feasible in the 80's, if you had 32K ROM with extra RAM (SARA chip maybe, like Fatal Run), or perhaps a game with the DPC co-processor. Hope that helps!

Nathan and I are debating about this; 4 joysticks with 2 buttons each using 2 ports or 4 joysticks/ 1 button 1 port. I have plans on making 4 player games that will need the AtariVox/Saveky functionality (specifically sports games) so I'm leaning towards 4 joysticks/1 button on 1 port. In a post above I had asked about the possibility of adding a switch that would toggle between 2 joystick/2 button and 4 joystick/1 button mode so the multi-tap could in theory support either (2 joystick/2 button would only use 1 select line, freeing up the other 6 pins for UDLR and 2 buttons while 4 joystick/1 button mode would use 2 select lines and the other 5 would be UDLR and 1 button). Of course that's all 'pie in the sky' thinking so I'm sure we'll land somewhere in the middle. I know it was discussed above, but concerning this new design, are there suggestions on how we could multi-purpose a pin from the Atari to be either an input (for button 2) or an output (select line) using a physical switch? Nathan's 4 joystick design is basically 2 separate 2 joystick designs, each connected to 1 port, but for some reason they were connected. Perhaps he is using 1 select line for both like Stephen recommends above.

Champ Games started a hockey game (CHAMPionship Hockey) back in 2003 but haven't worked on it since, but we are planning on finishing it using CDF at some point soon, hopefully next year! Here are some screen shots we posted on our Facebook page a while back. If it catches on and people are interested, we would consider making other Champ Sports titles such as Baseball, Football, Basketball, Soccer, Bowling, etc.

Makes sense. So if I hook up VCC, is that what makes it a 'pull up' resistor, meaning it's pulling it up to high? Would connecting ground make it a pull down resistor? Got it now... I forgot Nathan had posted a pic before. That really clears things up! Awesome! I'm going to try to put this together this weekend and will post my findings here. Thanks! John

Yes, the version (b) suggested by Stephen above with the octal buffer. Glad I asked, I would have incorrectly guessed common was ground. Man I'm really rusty with this stuff! Hmmm, so you're saying that I connect the joystick inputs directly to the octal buffer? When you say a pull-up resistor on a buffer line, is that on the input or the output? :S Great, thx. Silly question, but how do I get a high signal to DIR? Do I connect VCC directly? (or GND if I wanted to get low)? Those sound like dangerous ideas, is there another way to get high/low to that pin? Great thx! Awesome thx! I figured there was a specific chip that would be able to solve that issue instead of building it with logic gates. Thanks for the info! John

Thanks! That would be cool! (and the 5200 too!) My first bit of game programming was way back in 81 on an 800 using BASIC, maybe one day Champ Games will return to where it all started. I think Atari did pretty well with 7800 Galaga for the time but with that said I never did play it much because it felt 'off'. Of course it didn't help that I first discovered it in the mid-90's right around the time I was starting my PC clone of Galaga (Galagon) so my expectations were a bit high. Hmmm, I could spread out the double fire but I would need to also spread out the ships which IMO would look strange. Also, with the shorter screen vs the arcade I find that you can hit most of the enemies before they even get into formation so it would make the game way too easy. I don't think I've ever played Tekken (maybe on the Playstation?) I've never really been into fighting games so a 2600 port is probably best left in the hands of someone with fond memories of the game, as that is one of my requirements for porting games to the 2600.

Hi Stephen, Thanks for the clarification, I wouldn't have thought about the pin orientation until after I had started building the circuit lol. Great, I bought some of those too. Just so I don't blow anything up: - Sanity question: I get VCC (pin 7) and GND (pin 8 ) off of the Atari hookup, correct? - connect the joystick inputs to the resistor pack (up/down/left/right/button/ Genesis button) - connect the outputs of the resistor pack to an octal buffer. Looks like there is a DIR pin that controls the direction of the data (A->B or B->A). I assume this should be the same for both (meaning the direction should be the same for both). What do I connect to this pin? - Repeat for both joysticks - Connect the outputs of the 2 octal buffers in parallel to the output that is connecting to the Atari. right/up/down/button map to the standard pins, left maps to INPT1. Do I need anything (resistors, diodes, etc) between the octal buffers and the Atari pins? - select line is pin 3 from the Atari (left). How do I go about having it activate one octal buffer and not the other? Is it as simple as connecting the select line directly to one of the 245 OE pin (output enable) and passing the select line through an inverter before connecting it to the other one? - BONUS: If I wanted to extend the design to allow up to 4 joysticks connected using 2 select lines (let's say pin 2 and 3, right and left), I assume I would need some logic gates for the two select lines to output enable one of the octal buffers? Maybe use a 7408 AND gate in combination with a 7404 inverter to output enable one of the buffers on 00, 01, 10, or 11? Apologies for all the basic questions, I can promise I'm a fast learner though! Thanks, John

Hello there! Yes, that is correct. We actually finished co-op mode and it is graciously being tested by a few people including James (& Tayna) over at Zero Page Homebrew and Glenn (aka GRay Defender) & his family. Both have reported that co-op is a lot of fun and will be a welcomed edition to the final version! We are also working on tweaking the CHALLENGE mode. In this special mode, you are only competing against CHALLENGE stages, earning and losing reserve ships based on your performance during each stage. The mode is fun & challenging in it's own right, but also a good way to practice the challenge stages for the real battle. Have fun!

Great, thx for the info, it's very helpful! So Stephen recommended a 4K7 resistor pack (or 5K1), so I think this one suits the need: https://www.mouser.com/ProductDetail/Bourns/4609M-101-472LF?qs=%2Fha2pyFadugOMSB5yBRKclNlQDagKDSXTScC2ZhFKwTAAF%2FHbRdHBQ%3D%3D It has 8 resistors which will be enough for 1 controller, so I'll need 2 for the circuit (1 for each since there are 5 maybe 6 inputs if we include the 2nd button). Thanks again!

Great thanks for the confirmation! Any suggestions on a SIL resistor pack/network (not sure if those are the same) that I could use for the pull up resistors? I see SIP resistor packs (which they also call single-in-line which is confusing) so I'm not sure if they're the same.

LOL I'm glad I asked! I'll look around for DIP version of the buffer. Thanks! I assume something like this would be okay? It says it's 'through hole' DIP-20 (I'm guessing '20' is the number of pins). PS I appreciate the help, especially with the basic stuff! I'm researching at the same time too so hopefully my questions will be a little more advanced soon!

Hi Stephen, Thanks for all the info and suggestions! Nathan (aka gauauu) is going to try the diode solution. I figured I'd give the circuit a shot myself since he's making this multi-tap for my game (Wizard of Wor Arcade), so I've gone and ordered a bread board, resistors etc. to try to get back into hardware (it's been about 30 years since my EE lab class at UCONN lol). Anyway, if you don't mind, I'm looking on mouser.com and did a search on the 74HC244 for the octal line buffer (I was going to try solution (b) since Nathan's original design used a couple 2x1 MUX). I picked the first one in the list, does this seem to be appropriate for what we need? Also, you mention a 4K7 or 5K1 SIL resistor pack. I did a search on that but couldn't find anything; do you have any more specific information that may help me find what we need? EDIT: okay, I was able to find out what SIL means (single-in-line and it's basically a bunch of resistors all using a common terminal. Very slick! Sounds like the best solution would be to maybe get 2 of these, one for each set of joystick inputs (5 inputs each)? Thanks in advance! John

Hmmm, I'm pretty sure this is how it is in the arcade (it will show 150 in white if the flagship is destroyed in formation). If that's not correct, I'd be glad to fix it! Again, I'm pretty sure this is how the arcade is, but I may have misheard it while I was researching. There's certainly some ROM savings if I can run the same chunk of code for multiple situations, but to make small changes like this would cost about 4 - 8 bytes for the conditional check so no big deal. If you can provide specifics, I can put them on the to-do list to make sure they're included in the final release. Thanks for the feedback! John

Thanks for the feedback! I have to be honest here, I'm not even sure what re-flowing solder even means; does it mean desoldering the connections and re-soldering them with new solder? Lol I wasn't kidding when I said I'm a software guy. I'm sure I can do plenty of damage with a hot soldering gun too! I'll try the the tape/anchor solution first - that sounds much more up my alley Thanks again! John

Hi Darryl, We have been working on tweaking this as a few people have pointed out this 'trick' - I will look at making a few more adjustments to get it a bit closer to the arcade. Good catch; this is an easy one to fix. Thanks so much for the kind words! John

Hello there! That is correct. I don't believe any of the ARM-based games (Scramble, Mappy, Super Cobra Arcade, Draconian, etc.) work with the UNO cart because it doesn't emulate the ARM (which is on the Harmony cart), but I believe I read somewhere that the developers are trying to upgrade the firmware on the UNO cart so that some day it might be able to run these games (I may be wrong here).