Jump to content
  • entries
  • comments
  • views

Atari coding burnout starting to fade




I know people are anxious for me to get back to work on Frantic, but I'm not quite ready to jump back into a major project yet.


I have started to dabble though, so I think the burnout is nearly over. I've also been researching ADPCM to compress the digital samples even more than packing did, though it's currently making my head spin. I've had an idea though and will be experimenting with that soon.


So why, some might ask, did I experience a bout of burnout? Well namely, besides programming for a living, I've also been working on a number of 2600 projects - often concurrently:

  • Space Rocks - wrapped up in November, but is not yet available due to manual printing issues, box color issues (if you look closely you'll see that the box is grey, it should be black), and a shortage of Melody boards.
  • Chun-Li* - the continually delayed project with which we've worked out a number of DPC+ issues with over the past few years. If you've been paying attention, you know what this one is ;) It's 99.9% done, so it will finally be released sometime this year.
  • Project Retro* - I was a supporting programmer on this exciting project that failed to pan out. I believe Nathan plans to write up a blog entry about this at some point, so I shall say no more.
  • Cat Food* - another exciting project that failed to pan out. Unlike Project Retro, I'm going to say more about this one :)

* code names by Nathan




Cat Food


At the end of the year I was approached by a company that's well known for their April Fools jokes that end up becoming real products, such as the iCade and Taun Taun Sleeping Bag.


They wished to release a 2600 game and had these requirements:

  1. star Timmy
  2. bananas should be thrown

Not much to go on, so we gathered together a small group and debated a number of game ideas. I kept returning to one suggestion in particular, so I started work on a game inspired by it:


blogentry-3056-0-93444500-1371168658_thumb.png blogentry-3056-0-11855500-1371168459_thumb.png


Instead of bombs we thought we'd set it up so that an April Fools prankster hide all the Think Geek products awaiting shipment. Timmy needs to round them all up so as not to disappoint any of the Geeks. We planned to use actual Think Geek items, but what's currently in place are colored cubes with a letter code for testing my new routine which does on-the-fly color conversion. The TV Type option is used to select NTSC, PAL or SECAM. The red/green/blue below it are used to reinforce that you've selected the right value:


Think Geek's order numbers are in HEX so I planned to show the score using that. Some didn't care for this idea so I added an option to let the player select DECIMAL. I also whipped up that crude Think Geek logo, which Nathan would have expertly redone before the game shipped.


Jumpman has upward-only and downward-only ropes which are differentiated by their color and zig-zag pattern. Neither of those options is viable on the 2600, so I came up with the idea of using the missile/ball size setting to draw narrow ropes for going up and wide slides for going down:


We needed to go beyond Jumpman's world for the banana requirement, so I started working on an idea of conveyor belts and switches. The converor belts would create one-way platforms that could be controlled by throwing bananas at switches scattered around the level. This isn't functional yet as I was working out issues, which cropped up with using NUSIZx for the triplicate conveyor belt wheels, when the project ended.


So what happened? At the start of January we stopped getting input from Think Geek. I continued working on it due to the deadline, but we were getting more and more anxious as time went on. Finally in February we found out that there'd been a management shakeup at Think Geek and the project was now in limbo.


The project won't go to waste though as I plan to convert it into something else. I'm planning to work with batari and use this game to develop a bus-stuffing bankswitch format for the Harmony/Melody.


In the mean time, here's the current ROM and Source with the Think Geek logo removed:








You can use Stella to try out the different TV-Types. Hit <CONTROL>-F to step between the different formats. Use modes PAL60 and SECAM60 instead of PAL and SECAM.


blogentry-3056-0-30060300-1371230367_thumb.png blogentry-3056-0-54814400-1371230372_thumb.png


blogentry-3056-0-30474300-1371230483_thumb.png blogentry-3056-0-53541900-1371230378_thumb.png


SECAM. Note the loss of luminance shading on Timmy and the R G B blocks.
blogentry-3056-0-19344100-1371230384_thumb.png blogentry-3056-0-27048100-1371230390_thumb.png


A real SECAM system most likely won't look exactly like it does in Stella, though I think it'll still work out OK.

  • Like 4


Recommended Comments

I'm not entirely willing to give up on Project Retro yet. Not until I get a firm "no". Of course, without a firm "yes" there's no point in continuing with it either. ;)

  • Like 1
Link to comment

I hope the "bus-stuffing bankswitch format" has residual benefits for batari BASIC. I could see making an Ultima type game if batari could be motivated to explore large bank switching formats (and incorporate support into bB)


UPDATE: I LOVE the Adventure-esque sound effect in cat food :)

Link to comment

No money changed hands. I'm free to do what I want with my code.




It might show up in bB, though it'll be quite some time before we know. I plan to wrap up Frantic first, then there's just a little bit more left to do on Chun-Li. After that I'll start to work on the new format.


The sound effect as written is for my advanced driver, which I haven't ported to bB.

.byte 0, D3, D3+1, D3+2, D3+3 ; collect item

.byte 0, $6f, $6f, $6f, $6f ; collect item
sfxCOLLECT = *-sfxCV-1




There hasn't been much response to the simple driver, so I don't know if I'll take the time to port the advanced version or not. It's simple to convert the above for the simple driver though:


.byte 0, 0,0,0, 1,1,1, 2,2,2, 3,3,3 ; collect item
.byte 0, $6f,$6f,$6f, $6f,$6f,$6f, $6f,$6f,$6f, $6f,$6f,$6f ; collect item
sfxCOLLECT = *-sfxCV-1


In that you can see the benefit of the advanced driver, especially when you factor in that your sfxF/sfxDF and sfxCV tables are limited to just 256 bytes each. sfxDF = Duration & Frequency table.

Link to comment

Awesome Darrell - glad to see Cat Food not going to waste. ;)


Also, very cool sound driver!


I may hit you up with questions as you work on the digital samples for Frantic, as I have also resumed work on Frenzy.


Link to comment

I can't speak for the other bB enthusiasts but I've been satisfied with my ability to generate sound effects. Although it is tremendously gracious of you to even consider porting libraries to bB.


I've been trying to figure out a good way to implement 4 way scrolling and the ability to load in playfield data as needed. batari made an example that I modified to run on newer bB builds here:



Sadly, manipulating level data is non-sensical. I don't really understand his code.


I guess what I'm saying is, if you ever get to thinking about bB again I'd appreciate any help you could offer simplifying 4 way scrolling (and loading in playfield data) :)

Link to comment

Thanks PacManPlus! Sure thing, though I'm doing the prep work on the ARM so I'm not sure how well it'll translate to the 6502.



Atari playfield scrolling is complicated due to the way the TIA draws the playfield. If you look at the bits in the byte as 76543210, some parts are displayed as 76543210 while other parts display as 01234567. The other complex part is you're shifting individual bits around, and if you don't have a grasp of binary (testing the state of individual bits, shifting bits from one byte to another, etc) it'll be hard to follow. This might help you follow what's going on.


I think the best approach for playfield scrolling in bB would be to utilize DPC+ and have functions written in ARM code with special bB commands that would call it for you. Setting that up would take a lot more work than I care to tackle as I'd need to have a really good understanding of how bB is doing everything, and I don't.

  • Like 2
Link to comment

OK, I finally found some time to test your program on my SECAM VCS. I can't attach pictures here, but it seems that red is a bit tricky to get on SECAM. In the title screen the exclamation point after "Timmy" and the word "RED" turn out to be a light gray, whereas the word "START" is red when it's not selected. In all levels the platforms where red is mixed with something else it also ends up as gray, while the 'R' blocks and the ladders / chutes really are red. All other colours seem to be as intended, as far as I can tell. I hope this helps.

Link to comment

Thanks! That is odd about the red - I was expecting the striped areas to end up a different color but figured anything that was solid red over multiple scanlines would come out OK.

Link to comment

Any relation to South Park Timmy? I mean the one in the wheelchair?



How about writing a few mini-kernels to avoid the color bleed on to the rope? I never liked that in Jungle Hunt, so one day I fixed it. Turns out it was a real simple fix as the ball wasn't being used. I don't know why they didn't do that in the first place. I realize you are using the ball and playfield here, but a small kernel to do a midline color change shouldn't be too bad.






Edit: I just followed the link and found out who Timmy was.

Link to comment

Timmy's a monkey, hence the banana requirement.


There's a bunch of mini-kernels due to sprite repositioning, which can occur on any scan line.


The ropes and slides look a bit different on a real Atari vs Stella as I round-robin the ball and both missiles. Stella's screen grab only shows 2 frames worth of the blending caused by the round-robining.

Link to comment

Added a fixed version of Timmy! for the Harmony Encore.



dd skip=3 count=29 if=timmy_20130613.bin of=t29k.bin bs=1024

cat DPC+20121020.arm t29k.bin > timmy_20130613_encore.bin 
Link to comment

In Timmy! if you switch the left difficulty to A you'll see 4 debugging sprites appear at the top.


The left 3 show the platforms & ladders detected around around Timmy.  What's overlapping Timmy is white, what's around Timmy is red.


The 4th shows the detected ropes/slides. What overlaps with Timmy is blue, the bottom white line shows what was detected - 1 pixel = rope,  4 pixels = slide.


The detection occurs in function UpdateTimmyPF_RS().  The results are used to determine if Timmy is on a ladder and cane move up, standing on a platform or falling, climbing a rope, going down a slide, etc.

Link to comment
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...