splendidnut

I was going to make some long rant about how the burgers in ChaoticGrill should be included... but then I saw the previous year disqualification and realized that I did the burgers way back end of 2015/ beginning of 2016.

I've definitely seen that blue line issue come up several times on this forum with people blaming everything from the Harmony Cart, the power supply, composite mods... etc. I've personally noticed this blue line with my Vader while it's non-existent on my old light-six switch sears model. The Vader has very saturated color, while the 6 switch is somewhat washed out. Both Atari's are using just the original unmodded RF signal output. So, I believe the vertical blue line is partially caused by the overly saturated color on the Rev. 14 and up boards. The other factor being a display enable signal in the TIA causing a slight surge in the video signal. The surge is unnoticed unless the saturation level is high. With that said... I believe my TIAs are normal, so I can't contribute any more to this topic For reference, I've played around with NTSC video generation and have had a similar timing/display issue crop up in my own circuit.

Thanks! Remaining enemy issue will be looked at, a few other people have noticed that as well (in the development thread). I fixed the score issue (was using INC instead of LDA,ADC,STA for BCD arithmetic), so that will be in the next build.

Hmmm... quite a necro-bump. But since I was already looking at the schematics, I figured I'd answer it. That chart is a little confusing. TIA is selected whenever both address bits A7 and A12 are low, so address < $1000, and low byte $00-$7F... TIA doesn't use address bit A6, so the TIA is at $00-$3F and mirrored at $40-$7F. RIOT is selected whenever address bit A7 is high and A12 is low, so address < $1000, and low byte $80-$FF. RAM is selected when address bit A9 is low, so when the high byte is $00 or $01. $0000-$007F - TIA $0080-$00FF - RIOT - RAM $0100-$017F - TIA $0180-$018F - RIOT - RAM $0200-$027F - TIA $0280-$02FF - RIOT - IO $0300-$037F - TIA $0380-$03FF - RIOT - IO Then this layout is mirrored 3 more times: $0400-$07FF $0800-$0BFF $0C00-$0FFF Hopefully this clarifies what's going on.

Thanks. I'll be improving the flicker management (finishing the flicker management code I have in progress) at some point in the future... I'm holding off for now, to focus on game play issues.

Thanks to help received from Kurt Woloch (as seen in here), I believe all the enemy movement issues have been eliminated.

Thanks to Kurt Woloch (as seen in previous posts), I believe all the enemy movement issues have been eliminated. Enjoy. chaoticGrill-2019-01-20.bin

Ahhh, that explains it So it looks like I should be able to use my pseudo code to handle cases 4, 5, and 6 well, but I should probably check for cases 1, 2, and 3 and handle them separately since they each only have one outcome based on the incoming direction.

This can be reduced if you concentrate on just the axes, combining to form left/right and up/down code branches. The out of bounds is already taken care of when the enemy recovers from being dropped; it's a completely separate code branch. For the general decision logic, my thinking is as follows (slightly more minimized pseudo-code than yours) At intersection: Current Direction LR? CUD Current Direction UP? CLR CUD: Compare with player Y If Up, switch to up if possible, exit If Down, switch to down if possible, exit Check current direction, if can't move, use opposite direction, exit Use same direction CLR: Compare with player X If Left, switch to left if possible, exit If Right, switch to right if possible, exit Check current direction, if can't move, use opposite direction. Use same direction Current direction is stored in the same form as the level layout data, each of the four directions uses a bit: ;-- Directions (uses different bits for each direction to allow multiple directions) DIR_RIGHT = 8 DIR_LEFT = 4 DIR_UP = 2 DIR_DOWN = 1 Check current direction would be a simple AND and branch statement. This follows along in similar ways to how the code flows now... my code just hasn't evolved to this point yet.

Mentioning flicker management probably was not the best thing to do since the RAM usage only really applies to flicker management code not used in the public builds. You don't think I've made it this far without keeping track of RAM usage? RAM usage is as follows (not necessarily in this order): 38 bytes for player, 4 enemies, bonus item, pepper spray 6 bytes for sound/music routines 36 bytes for tracking burgers in motion (stationary burgers only exist as Display Data in DPC+ RAM) 5 bytes for miscellaneous game variables 16 bytes reserved for future flicker management code (most are currently used when the code recompiled with the flag enabled) 9 bytes for game variables that exist between levels (score, lives, etc...) 18 bytes for temporary variable storage and call stack (call stack can take upto 10) There are a couple of places where a byte or two could be saved to expand the temporary variable space, but I'm trying to hold off on that for now. Ultimately, I only have around 8 temporary variables to use. In the case of the enemy movement code, I believe they are mostly used up... although, I know I did free a couple after converting the level structure.

There definitely is some charm in the original game. After working on this project, I definitely have a better understanding of why it is the way it is... there's a lot going on game-logic wise.

Burger pieces fall one story when knocked down... they fall one additional story for each enemy riding them. So if I'm understanding your description correctly, it sounds like they are functioning correctly. I definitely need to look at the player code because I know that it lost some functionality after reworking the level data structure code. Thanks!

I completely didn't realize that the bonus items weren't timer driven. I basically threw them in there the easiest way I could, with a timer that makes them appear after a certain time (~16 seconds) and then disappear if not grabbed quick enough (after ~16 seconds). And I definitely didn't think about the hex vs decimal issue. Thanks for pointing that out. Also, thank you for providing your ideas on how to implement the enemy logic... it's definitely given me additional things to think about. I'll probably opt for a more code based solution as opposed to a table driven solution since RAM usage is tight (saving space for flicker management usage) and the directional data would probably need some translation code, thus eliminating any speed advantage. I haven't quite got the chance to implement any of this yet since working on the level data structure/loader code over the Christmas holiday. I needed a break and ended up working on the missing game features instead. I appreciate the feedback and bug reports. Please keep them coming

Huh, some bit of code from my work-in-progress build must have snuck into the released build. Thanks for letting me know.

Annoying? Maybe... While it may be slightly annoying to hear the about the same issue over and over, it serves as a reminder to me that it's something that still needs to be fixed. There are definitely a few fun bugs currently in the enemy AI. It was really fun watching the Zeropage Homebrew crew yell "cheaters" at the screen when the enemies decided to use non-existing ladders. Basically, I never finished reworking the enemy AI code after working on the level data structure/loader code over the Christmas holiday. I needed a break from it, so instead I worked on the missing game features. At some point in the future (not quite sure when), it will get fixed.

Just a heads up... I fixed a few things: Items should appear in the appropriate places for each level. Also fixed some graphical issues with them (i.e. coffee cup missing top line, etc...) Added extra life bonus for every 10,000 points. After completing level 6, the levels should loop back around without ending up at the title screen. See first post for updated version.

Fixed a few things: Items should appear in the appropriate places for each level. Also fixed some graphical issues with them (i.e. coffee cup missing top line, etc...) Added extra life bonus for every 10,000 points. After completing level 6, the levels should loop back around without ending up at the title screen. Enjoy. chaoticGrill-2019-01-08.bin

I thought I may have broken that when reworking the level structure. Thank you for confirming my suspicions.

Very nice start to this. I really like the level intro scene with the falling man grabbing onto the parachute.

I think the categories are relatively fine as they are...because at the end of the day, shouldn't the focus be on the games themselves? Not the technology behind the games? I ask, more or less, because I think ChaoticGrill would be an odd man out... uses DPC+ driver, but no ARM code (game logic is all in 6502 assembly). Would it be fair to stick it in with the other games that use ARM-based game logic? It would almost fit best with the Bb-based DPC+ games. Along those lines, shouldn't Bb games themselves be separated into DPC+ vs non-DPC+? And it goes on and on and on.... You have to draw the line somewhere so that you don't draw too many lines

If you combine these two observations of yours, then it sounds like it's an issue with the RetroTINK circuitry. Although this could be a power or capacitor issue with the Atari Jr. Maybe the signal is just on the edge of not being strong enough for the RetroTINK to process when passed into SVideo input.

Stop holding the button down While pepper is spraying, the button is ignored until the spray is done (spray currently lasts for 0.5 seconds). Once the spray is done, it can be immediately retriggered if the button is still pressed. As a fix, I can lengthen the spray time a bit and add a lock-out until button is released. A flaky button would still potentially cause issues regardless of any software fix.

Thanks! And thank you for the work you put into the latest versions of Stella.

I was trying to figure out what whether you were just complaining, or attempting to ask a question... but then you said: So it sounds like it's a bit of both. A bit of history on this project (which you may or may not have read): http://atariage.com/forums/blog/614-splendidnuts-blog/ I originally started this project without DPC/DPC+ and found that I wasn't going to be able to do much better graphically than the original M-Network Burgertime. Potentially add a little more color. I then switched to DPC (Pitfall 2): I needed a little more than that... at least both sprites multi-color and time to switch kernels and/or move data around during the display. Switching to DPC+ gave me the following: - fluid burger dropping - fully detailed burgers (PF and color update in 10 cycles using fast fetch) - multicolor single-line sprites (for both) Yes, this project could be done without DPC+ (since I use no ARM code... I've only written 6502 assembly with DASM macros), but the burgers (a key element of the game) would sacrifice the most graphically. The project would look more or less like the screenshot in "BurgerTime Remake: The Start" only without the multicolored chef. It would still need 256 bytes of extra ram (a la... M-Network's E7 mapper ) I grappled a lot with whether or not to use DPC+, but at the end of the day, I'm really glad I chose to use it. My compromise has been to write only in 6502 assembly.

ChaoticGrill is an attempt to bring a new version of the arcade classic BurgerTime to the Atari 2600. With a grill in the midst of chaos, you control Pete the chef to build burgers for eagerly awaiting customers. Sounds like an easy job, right? Well it would be if it weren't for some other pesky ingredients trying to interfere with your burger assembly line. It's chaos on the grill. But you can manage, right? To play, navigate your chef around the kitchen and knock down pieces to build your burgers while avoiding the hot dogs, pickles and eggs. You can use the FIRE button to spray pepper on the enemies. Knock down all the pieces to complete a level and move on to the next one. Controls: JOYSTICK - Move player around FIRE BUTTON - Spray pepper (also start game) SELECT - Switch levels RESET - Reset to title screen RIGHT DIFFICULTY - Turn on/off music Credits: splendidnut - programming, sound NostAlgae37 - graphics -------------- This is currently a work-in-progress, but pretty much feature complete at this point, so I figured I would post it here also. Information on development can be found here: http://atariage.com/forums/topic/246769-chaoticgrill-burgertime-remake-in-progress/ Latest version (as of August 18th, 2019): chaoticGrill-2019-08-18--NTSC.bin chaoticGrill-2019-08-18--PAL60.bin Older version (as of July 5th, 2019): chaoticGrill-2019-07-05--NTSC.bin chaoticGrill-2019-07-05--PAL60.bin And even older versions: chaoticGrill-2018-12-31.bin chaoticGrill-2019-01-08.bin chaoticGrill-2019-01-20.bin chaoticGrill-2019-02-17.bin