johnnywc

Although I'm no a huge soccer fan (I did watch the New England Revolution play back in the early 80's) and don't like playing it, I do like video game soccer. RS Soccer was a real disappointment (I enjoyed M-Network Soccer and Pele's Championship Soccer much more) so a good soccer game is definitely a possibility!

I agree and I am leaning towards this. What we're striving for is to allow players to pick teams that match their strengths (hitting, fielding, running, small-ball etc.) but also have teams that are 'stacked' so players can essentially choose their skill level by purposefully choosing a 'weaker' team (and I use the term loosely since all the players will be 'all stars') for a greater challenge or pitting a home run hitting team vs. a singles/small ball team, etc. Plus, coming up with rosters/lineups will be much easier based on real players. Using BCD (binary coded decimal), you can store 2 numbers in one byte so that's why that would be the most efficient way. Unfortunately BCD only allows for numbers, but we can always make #'s up for players that didn't have jersey numbers as all the other attributes will be the same. We may have overlaps with #'s too (different players from different eras that had the same # on the same team) so we'll need to be creative. I should start a spreadsheet so we can start adding in potential teams, players, attributes, etc. I think we should avoid having the same player on different teams; we can make the choice based on what balances a team more, or whatever team the player spent the most time with or had the most impact. It would be interesting to have Babe Ruth on the Red Sox as a pitcher and on the Yankees as a right fielder though. Thanks for the suggestions! We're looking forward to getting back to CS Baseball development soon!

Thanks! If the reception for CS Baseball is good, I would love to continue with hockey and basketball (and even football too!).

Good points! We'll just be using jersey numbers (no names) most likely to save space but we'll see what makes sense when we get to that part of the design. I do love the old Accolade games, especially Hardball and 4th & Inches!

Quite the opposite actually... I've managed to get this to run in just 128 bytes of RIOT RAM! Seriously though, yes it does use the ARM and 32K (CDFJ bankswitching).

Hi Philip! Wow - this seems really cool! I agree; one of the things that attracted to me to the ARM development was being able to use C for the game logic. Not only does it speed up development, but it makes it so the game development is more fun than frustrating (to me). As far as Galaga is concerned, certainly writing the logic in C helped a lot, but the main reason we were able to get a playable game done so quickly was because I had done a port of Galaga for the PC back in 1997 (in C, nonetheless) so I was able to use a good portion of the game logic, patterns, etc. to get things working quickly. Add to the fact that I have a pretty good SDK that handles all of the monotonous boring stuff like UI, high score tables, etc. and a playable prototype can be done fairly quickly. For other games, like Zoo Keeper, the development has been slower (I started it in October of 2018) but writing logic in C has been extremely helpful. Good luck and I will be interested to see how this goes!

Correct... I personally liked the Expos more than the Blue Jays because the Blue Jays are direct rivals to the Red Sox both being the AL East. It's sad the Expos moved before they had a chance to win a World Series. 1994 they were killing it before the strike hit, and that basically ended baseball in Montreal. On the plus side, the Red Sox acquired Pedro Martinez from the Expos which helped us break "the curse" in 2004!

We hope to include at least one Canadian team! I visited Toronto last year and was able to catch a Blue Jays game, it was a lot of fun! We were able to get great seats right behind the first base dugout real cheap... I could never do that at Fenway! 😮

We plan on keeping the game 32K so probably no need for an upgraded Harmony. Although I do see the advantage of a larger ROM size (more teams, more options, etc.) I think that really gets away from what kind of game we're trying to make (arcade baseball game with some strategic elements). Also, Champ Games has 10 or so other projects (including other Champ Sports titles) that we like to work on and larger ROM size will most definitely mean more complicated game taking longer to finish (if ever ). I've always had a soft spot for the Tigers (loved the old Tiger Stadium) so Detroit will most likely be one of the final teams.

Thank you! Good points! I know choosing the final teams will be a challenge that's why I hope to have room for a team editor so someone can override one of the teams and make it their own. I was thinking the same thing about Chicago since we are using city names. Due to a non-MLB license we will not be using any team names, logos, player names, etc. Yes, I was thinking about my last post and I do plan on having contact, power and possibly "bunt" skills for hitters. Although I'd like to use names, the space needed would be too much, plus they would have to be made up anyway. I was considering jersey numbers so that would at least help identify most of the players; they old timers we could assign numbers and between the team and skills people could determine who that player is supposed to be. Jersey #'s also only take up 1 byte but assuming we go with 10 characters max for a name (which isn't much), 16 teams, 16 players per team means 256 bytes for the jersey #'s vs. 2,560 bytes for names (and we're talking 32K for the entire game ). When I played Homerun in 1978, I would squint and pretend the red team were the Red Sox, the blue team were the Yankees, and Cartlon Fisk was facing Goose Gossage. For this game we hope to make it a bit more believable (less squinting needed) but probably won't be able to reach the level that Earl Weaver Baseball and the later baseball games did (which had a lot more space). Also, if we plan on allowing teams to be saved to the Atarivox, there is only so much room on the Atarivox that is shared by all games of all developers. I would like to keep the total space needed for Champ Sports Baseball under 256 bytes for the Atarivox to save room for other developers (and other Champ games too!). Anyway, I just wanted to let everyone know that although I'd love to have all these bells and whistles, we do want to strike a balance between playability and simulation given the limited resources. I definitely want to use all time greats if possible for the same reasons you mention. I need to think it through, but yes I'm thinking a max skills per team, max skill per player, and then having perhaps a couple players you can mark as "all stars" that get a boost in skills and then a "super star" that can have a maxed out skill. We'll come up with something that is a good balance I'm sure. Lol I remember that guy! Yes, we will have bunting, hit and runs, steals, double steals, pitch-outs, squeeze plays, etc. The trick is making the game accessible to the casual baseball player (keeping it more arcade-like) without having the simulation/strategy make it a niche game. Most people I'm sure just want to press a button to pitch, hit, have the players run around the bases, and be able to throw the ball around and not worry about bringing in a lefty to face a lefty with 2 outs in the 7th and having the 1st baseman guard the line and the outfield in with the 3rd baseman charging while the 2nd baseman is bluffing to cover and the catcher calls for a pitchout. (personally I love that stuff so I hope to be able to add in strategy somehow, even as an option). Definitely a possibility; I was at least thinking of having injuries as an option that could occur with bean balls, sliding, running into the wall, diving for a ball, etc. It would be configurable but for sure a bell/whistle. Hmmm, we'll see! We hope to do this; we need to come up with a way to even display the wall (not implemented yet) with dimensions and then we'll go from there. We at least want to have customized fence distance and wall height, and wall color. We also hope to have an artificial turf option so there would be dirt only around the bases and of course the ball would bounce higher, grounders faster, etc. If we have injuries they would be more prevalent with artificial turf. Yes, definitely! I'm sure for the cavernous parks and a good ricochet off the wall, players should be able to make it around for an inside the park homerun. We are trying to strike up a balance with the field dimensions so there will be a max distance for the fences so we'll see what parks will be able to be represented accurately. Although my tendency would be to go full simulation in this game, we truly think that a pick up and play game with strategic elements would be much more enjoyable to the community in the long run, so striking up that balance is going to be challenging! We started this game as a loose port of the arcade game "Championship Baseball" Thank you - I will definitely need some assistance with all that data! We're still pretty far away from that point (we want to have a playable baseball game with generic players working first), but once we have a better idea about space for skills, players, teams, parks, etc. we can start on this part. Awesome, thanks for all the suggestions! I personally can't wait to play it with my son either!

This is one of my favorite homebrews of all time, such fun!

Champ Sports Hockey was supposed to be the first "Champ Sports" release, but Nathan and I were inspired to do baseball based on the proof-of-concept I did with the field and we're both pretty big baseball fans too. Assuming the response for CS Baseball is positive and the community supports it, Champ Sports Hockey will most likely be the next Champ Sports game released.

Done! Thanks! That's what started this all; a proof-of-concept to see how it would look with alternating PF colors of brown and white to get the baselines/bases/etc. We originally also had alternating dark/light green for the grass which looks pretty cool, but we didn't have enough cycles to keep it in. 😕 PRB certainly looked really good and plays okay, we're shooting for more of a arcade/simulation combo. The players are quick placeholders done by Nathan so I'm sure they'll look even better in the final release! Like Nathan said, the "teams" will be city names (US) based on cities from MLB teams. I play on having 2 "leagues" or conferences, each with 8 teams (this number may change). I have made a list of possible cities; the only 2 that are sure bets are Boston and Seattle (since those are mine & Nathan's "teams"). Oh, and New York for @sramirez who is a big Yankees fan and will be doing some of the initial 2-player testing with his son (thanks Steve!). For the other teams I will most likely choose them myself or have some sort of poll. We do want to add a team editor that will allow you to update at least 1 of the teams (maybe 2) and save it to the Atarivox. To add to what Nathan said, we're debating about rosters, skills, features to add to the game so we have a good balance of arcade action and simulation. Here are my thoughts (none of this has been implemented yet so suggestions are welcome): Each team will have a set roster, most likely 15 or so players (25 is a normal roster but that is overkill since we are not going for a full blown simulation). This should be enough for a starting lineup, multiple pitchers, and a few pinch hitters/runners. Each player will have pre-defined skills for running, hitting, fielding, and throwing (like a number between 1 and 10). They will also have primary and secondary positions. Instead of names (which are copyright), I was thinking each player could also have a jersey # so you would know who it is (ie. "Now batting for the Yankees, #3 the right fielder"). Players are also identified by what arm they throw with and if they are left or right handed batters (or switch hitters). Each team will have a pre-defined starting lineup (order players bat) that can be altered before a game. Changes to starting line ups for custom teams could be saved to AVox, meaning your custom team can simply be an edited version of the NY team. I'm thinking each team could be an "all time" greats collection of players. I'm not sure how this would work as some teams would be stacked (NY, I'm looking at you!) but overall I think this would be the best way to go. I would probably hold a poll of some kind to get people's votes on which players should be included on each roster, or I may get most of the info from resources like Earl Weaver Baseball, the Hall of Fame, research, etc. I personally love baseball history so this would be the most fun part of making this game for me! We would like to add in pinch hitting, pinch running and pitching changes to utilize the rest of the roster. The team editor (in theory, I'm not sure if we'll be able to do it) would allow you to change jersey #'s and skills for each player, with a way to make sure that you don't 'max out' each skill (either have a max total skill per player or per team, or a "super star" bonus you can add to a few of your players to boost certain skills). Teams will have their own pre-defined uniform colors and ball park (ball parks will have a specific turf type (real or artificial) and outfield dimensions). Not sure if I'm going to include wind factor yet. The editor (if we make it) would allow you to change uniform colors and associate the team with a different ball park. Whew! Certainly a pretty big wish list and I'm sure not all of it will make it in, but that's what we're thinking. Again, our goal is to create an enjoyable baseball game that is accessible to many people (read: pick up and play) but have enough customizable options and features to suit baseball simulation junkies (like myself) without having it be too complicated. Right now we're focusing on making the game fully playable as a baseball game and will start adding some of these features in with an eye on available space, etc.

Hi TJ! Apologies for not replying sooner; I did not get any notifications so I clicked on "follow" so I should be all set now moving forward. There is no official documentation *yet* for the QuadTari, but I do plan on working with Nathan Tolbert on that when it eventually gets released. With that said, I did finalize the API and added code to support it for WoW and Galagon so I can certainly provide coding examples of how it works. Stella support would be awesome, and I hope it's possible! I'll help out in any way I can so thanks in advance. First off, the QuadTari is really 2 "DuoTaris" (I just made that name up ) where 2 joysticks can each be connected to each controller port. The QuadTari is 2 DuoTaris stacked on each other and are electronically separate. Nathan T. is considering selling DuoTari separately, and perhaps allow someone to "stack them" by sliding 2 together for 4 player games, but we'll see. The design originally used one or two of the pins in output mode to select which joystick to activate (with the output control pins mapped to the paddle pins INPT0 and INPT1), but this had a few disadvantages: If you had 1 joystick connected and wanted to play a non-QuadTari game, it didn't work since 2 of the directions were re-mapped (left and right). You can't use the INPT0/INPT1 to auto-detect when a QT is connected (vs. a regular joystick or a Genesis 2-button controller) It takes twice as much time to read directions for 4 joysticks vs. 2 (more about this below) During some testing, it was suggested that we use VBLANK DUMPPORTS used for reading paddles to select a joysticks (which drive pin 5 and pin 9 high) instead of using the directional pins in output mode. This is the direction we went for a few reasons: Since joystick directions aren't remapped, you can play joystick games that are non-QuadTari compatible with Joystick 1 connected through the QuadTari, with some exceptions (one being Defender doesn't work because it seems to DUMP_PORTS which messes with which QT joystick is active). The Harmony menu software seems to do the same thing (which makes sense since you can use the paddle or joystick with it) but for that you can control the menu with Joystick 2. I think I had posted a while ago asking if it was possible to only DUMP_PORTS in the Harmony menu software if paddles were detected (assuming that is what is actually happening). Since INPT0 and INPT1 aren't remapped or used, we ground one of them and the other one is pulled high, so you can detect whether a QuadTari is connected to port A: both low, it's a regular joystick both high, it's a Genesis 2-button controller INPT0 low and INPT1 high, it's a QuadTari (DuoTari). You can also use the same logic to see if there is a QuadTari connected to port B, but with INPT2/INPT3, so you can determine if you have 4 controllers available. For 4 joystick games with 2 DuoTari's connected, you can read values for joystick 1 and 3 by reading the high bits of SWCHA (and INPT4 for the button) when VBLANK DUMP_PORTS is low, and you can read values for joystick 2 and 4 by reading the low 4 bits of SWCHA (and INPT5 for the button) when VBLANK DUMP_PORTS is high. Since there is a delay needed between activating/de-activating DUMP_PORTS and reading the joystick ports, what I do is: At the beginning of OverScan, I read Joystick 1 (and 3 if needed) since DUMP_PORTS is 0. After reading the values, I update VBLANK and set DUMP_PORTS to 1. This will switch the QT to read Joystick 2 (and 4 if there is one plugged into port B) In vertical blank, I read joysticks 2 (and 4 if needed). At the end of vertical blank, VBLANK is set to 0 (DUMP_PORTS is also set to 0) Goto step 1 This allows enough time between activating / deactivating DUMP_PORTS (which switches the controller to read on the QuadTari) and actually reading the values on SWCHA and INPT4/5. We don't know the exact amount of time needed between updating DUMP_PORTS and reading consistent values; I hope to determine this through some more testing. Certainly the amount of time we have is more than enough as the testing with Galagon and WoW didn't have any control issues, but I'm sure the time needed is much lower. Here is the code I use in Wizard of Wor Arcade to detect a QuadTari (DuoTari) in port A. A couple notes: You can hold down SELECT to disable QT detection. I store a 1 in the high bit of flags if a QT is detected (multi-tap is the generic name I use) in port A This is not detecting a DT/QT in port B, but could be easily done by checking INPT2 and INPT3 and storing another bit in flags. ; if select is held down, skip multi-tap detection lda SWCHB and #SELECT_MASK beq detectSaveKey ; auto detect ; INPT0 INPT1 ; 0 0 regular joystick connected ; 1 x Genesis pad (or paddles) connected ; 0 1 multi-tap connected ; if INPT0 = 1, we have a Genesis pad connected and no multitap bit INPT0 bmi detectSaveKey ; if INPT0 = 0 and INPT1 = 1, we have a multitap connected bit INPT1 bpl detectSaveKey lda flags ora #FLAG_MULTITAP sta flags This is my generic ReadController subroutine. x is the input; 0 = read joystick 1 (and 3) and 1 = read joystick 2 (and 4). It can most certainly be optimized. Note that I store the values in RIOT ram in "controller" and combine the button and joystick values (and I invert the values so 1 is active and 0 is inactive). I do this because these values are sent to the ARM where I do all my controller checks. Note that the controller[0] and controller[1] are normalized so the ARM code doesn't know (or care) if the controller values come from 2 joysticks connected to a QT or 2 separate ones connected to 2 ports. I do use the controller bit in flags to enable/disable co-op options with an Atarivox, etc. if needed (ie. if you have an AtariVox and no QT, you can't play a 2-player game). ; ============================================================================= ; input: X - controller to read (0 = A, 1 = B) ; ReadController: ; ============================================================================= ldy #0 ; regular joysticks cpx #1 beq readControllerB readControllerA: lda SWCHA and #%11110000 bne storeController readControllerB: ; if multitap, we're reading controller A bit flags bmi readControllerA ldy #1 lda SWCHA asl asl asl asl storeController: sta temp ; read the button lda INPT4,y ; for multi-tap, we always read INPT4 lsr ; shift to the proper bit to store lsr lsr lsr ora temp and #$F8 ; don't really need this eor #$F8 ; flip all bits to make it active high sta controller,x endReadController: rts The switching of the DT/QT is done in OverScan. Since VBLANK is 0 (and DUMP_PORTS is 0) during the entire kernel, this is more than enough time to have the QT/DT switched over to read joystick 1/3. At the beginning of OverScan I read these values, and then enable DUMP_PORTS immediately so the DT/QT can switch ports and you get almost all of OverScan as a delay (since they aren't read until Vertical Blank). This can probably also be optimized but it does work. OverScan: START_OVERSCAN ; read controller 2 ldx #0 jsr ReadController ; turn on dump ports to read other joystick bit flags bpl noMultiTap ldx #DUMP_PORTS|DISABLE_TIA stx VBLANK noMultiTap: Note that in Vertical Blank, I set x to 1 before calling ReadController to read controller 1. I put ReadController such that I don't need to jsr to it in this instance: ldx #1 ; this falls directly into ReadController so no need to jsr ; ============================================================================= ; input: X - controller to read (0 = A, 1 = B) ; ReadController: ; Hope that makes sense! Let me know if you have any questions and I'll be more than happy to answer them. Thanks TJ! John

Good point, except with 64 or 128 I'd end up working on CS Baseball for a couple years and a) probably go insane and b) not finish any other games. I like to keep the games at 32K so it forces me to pick and choose the important things to include but also be creative in freeing up space for the bells and whistles. Oops I forgot one of the most important selling points! 😮 No wonder I'm not in marketing!

We'll see! I'm pretty sure it's going to be really tight trying to squeeze in all the features I want but hopefully there is some room for some cool bells & whistles!

I plan on posting a video soon, and/or having it shown on James' ZeroPage Homebrew Twitch stream. I haven't worked on this in a month or so and it's in an unplayable state (I was in the middle of adding in foul ball detection), so I'll need to get back into it to resolve these issues before posting. Maybe! I love the old ball parks too... my obsession back in the mid to late 80's was Earl Weaver Baseball for the PC that had all the old teams/stadiums/etc. so I hope to include some of that in this game, space permitting. If we can include a ball park editor, that would be ideal so people will be able to edit and make their own! Thanks! This is new ground for us (an original game) so a big part is trying to come up with a design without having feature creep hold us back, but as you can see by my wish list above that's been a futile effort so far!

Hmmm, that sounds strange... never saw that one before! 😕 Sounds like an undocumented feature/Easter egg/bad magic situation... you win! Seriously though, I'll take a look at the code and see if something like that could occur. I'll give Al a heads up, I'm sure he'll be thrilled!

Nathan (Strum) and I are still working out the outfield dimensions; we're debating whether to expand the outfield so there is more opportunities for doubles and triples, but not so much that it fields like you're in a sea of green tracking down fly balls. We do plan on having different dimensions and wall heights/colors to simulate different stadiums, and maybe even a "stadium editor". Being a Red Sox fan, I'm sure we'll find a way to include Fenway and the Green Monster. Thanks! We do have all of the screen transitions done, pitches and hits are "simulated", meaning you press the button and a random pitch is thrown and when it reaches the plate a random hit is done. Fielders are automatically moved towards the ball (you can override with the joystick to 'take control') or cover a base, runners will advance around and score runs. Fielding mostly works (catching, throwing) and you can tag runners out or tag a base for force plays. I'm currently working on foul ball detection (right now every hit is considered "in play" which makes it pretty easy to score ). Nathan has signed on for the animations; what we have now are very quick placeholders of the player sprites that he threw together while I worked on the game logic. The 16 built-in teams (# may change based on ROM) will have pre-defined cities/names, team colors, rosters and stadium) but we plan on allowing you to edit 1 or possibly 2 teams and save them to the Atarivox. Of course, all of this is "wish list" and will be determined by available ROM (and my sanity ).

Hello all, With the baseball season on hold, Champ Games has been inspired to start on our first original sports game ... Champ Sports Baseball for the Atari 2600! Our plans for Champ Sports Baseball include: Multiple built-in teams (16 is the current # we're hoping to include), including unique team colors, lineups, etc. Team editor for name/uniform colors, etc. Different field types (artificial turf vs. grass) Multiple game modes Exhibition mode: play with any two teams Tournament mode: choose a team and compete in a tournament-style march to the championship! Practice mode: hone your skills with batting, fielding and pitching practice Multiple play modes: 1 player vs. computer 2 players vs. and team modes Multiple screen views: Pitcher/catcher Infield view Multiple outfield views (left, left center, center, right center and right field) Other: Double and triple plays Infield fly rule Bunts, sacrifice flies Steals, hit and runs, pickoff plays, pitch outs Left/right handed pitchers and batters, plus switch hitters Player skills (throwing, fielding, hitting, running) Throwing and fielding errors Game stats Development is in the early stages (field views, ball physics, fielding, scoreboard, throwing to bases, etc. are almost done) and we hope to have a playable demo sometime this summer. Here are some screen shots from the current build. As always, suggestions are always welcome. Pitcher/catcher view with full scoreboard: Infield view. The solid red player - the catcher - shows player that has the ball: Left-center view. The ball and shadow can be seen around 2nd base. The yellow cross hairs show where the ball will land to aid in fielding (can be disabled for advanced players):

I think Cafeman was saying that Lady Bug is soooo good he just assumed I must have used the ARM/unicorn/Kray computer/etc. Thanks for the kind words! Galaga(on) takes full advantage of the ARM and is a lot of fun to play, but Lady Bug will always be my favorite and game that I'm most proud of. I'm glad I was able to fulfill my dream of making a game (and sentimental favorite) for the 2600 that could have existed 'back in the day' (along with Conquest(Caverns) of Mars, Lunar Lander, Avalanche and eventually Rip Off!), and I'm equally excited and motivated to use the new tools and technologies to make games that wouldn't have been possible back in the day. To me it's the best of both worlds!

I haven't been following this thread since it was moved from it's original "Galaga 2600" thread... wow it certainly has taken on a life of it's own! I did want to clarify that Lady Bug does NOT use the ARM or any extra RAM (128 bytes total), although it does use 16K of ROM. It could have been released exactly as it is "back in the day", I suspect around 1983 or 84 (pre-crash ). EDIT: Oops, I was only on page 10 when I saw this quote and felt compelled to reply; I did realize it had been dormant for a couple months. Disregard!

Bus stuffing is great but currently there are issues with it on some Atari machines (but the CDFJ team is working on it) so you may want to start with CDFJ. I have often thought about Super Pac-man on the 2600 and how I would approach it; I think what you started with was really good! Feel free to send me a PM and I would be glad to help you get started on CDFJ development and share some of my ideas.

You're welcome! I was also following your development of Super Pac-man which looked very promising too (except for the flicker issue ).

Hello there! I understand your desire about having a no-box option. @Albert at Atari Age makes all decisions based on whether to offer a no-box option, and that is usually determined by how many boxed copies are sold so he has an opportunity to recoup some of the investment needed to print a boxed version at a reasonable price. Hopefully if WoW sells well enough he'll be able to offer a no-box version sooner than later! 🤞