TROGDOR

I have a suggestion on the resubmission controversy. I think if resubmissions are allowed, there should be no point deductions. Let the game stand on its own merits. But, a game can only win in its category the first year that it's submitted. In subsequent years, it may get the highest vote, but it will no longer qualify as the winner of its category. Or we could just ammend the rules to disallow resubmission all together. Personally, I'm not the resubmitting type. I think the Oscars analogy applies well here. I've got enough game ideas that there will always be something new to submit in future years.

Andrew Braybrook was one of the most talented programmers in classic gaming history. He also wrote Paradroid and Uridium. I spent well over 100 hours on each of those three games. Gribbly's Day Out is among my top 10 all time favorites for the C64. I think the farthest I ever got is either level 4 or 5. This was a very tough game. I got pretty good at avoiding the maniacal black crab creature, but doing this while avoiding collisions with the landscape is nearly impossible. This would be a good game to hack just to see all 16 levels. I'm pretty sure there's a trainer version of this game out there.

Birthdays, weddings, aniversaries, work, and Runescape are all conspiring against my efforts to complete this game. But there is forward progress, as I'm determined to have this done in time for the 2006 Minicomp. This post combines the last 4 updates to the code, with several new features. New Features: V0.12: - Added preliminary score display. V0.13: - Completed programable 7 digit score display with 1 digit reinforcements display. v0.14: - Expanded the ship rotation graphics to use 16 positions instead of 8. Thanks to Nathan Strum for providing the ship animation cells. - Moved ship graphics into its own file to simplify automated changes. v0.15: - Updated player shots to shoot in all 16 directions. - Implemented 16-bit physics for player shots. - Added offset to player shot initialization so the shot appears to come from the center of the ship. - Fixed bug in ball size. The ball size bits in CTRPLF were being overwritten when playfield mirroring was disabled during score display. Todo: - Add more sounds. - Implement player shot to shield collision detection. Known Issues: - I finally understand the purpose of vertical delay. I'll add this to the kernel so full vertical resolution can be restored. The game currently uses half vertical resolution. - The ricochet physics is still off. Development Notes: I spent several hours writing a perl program that translates 5 animation cells into 16 Atari bitmaps, split into odd and even scanline tables. This was some hairy code. I'll post it when I get more time. I'm really happy with how the score display came out. In its original implementation, I was using a 25-byte RAM buffer, and requiring 1500 cycles per frame to preload. After several rounds of optimization, I got it down to 12 bytes of RAM, and it loads real-time in the kernel. I'll post some code examples later. This dynamic score display is a deviation from the original game. The original game only displayed the score when the player was killed or the Star Castle was destroyed. If I'm going to have code to display the score, there's no reason not to display it during the game, other than the small hit to screen realestate.

I'll have a 4K game ready by August. I'm not sure which one I'll submit, but Stellar Fortress is the farthest along. Are we allowed to make more than one submission for the same category? I didn't see any mention of this in the rules. The "one game, one vote" in the FAQ seemed to only apply to the same game across multiple systems. If yes, I'd like to submit Stellar Fortress and The Battle of Midway, if I can get both of them completed in time.

Thanks Tom. I found a ton of information here: http://www.atarihq.com/danb/files/TIA_HW_Notes.txt The section "Playing with the HMOVE registers" describes this problem in detail. Here's an excerpt from it: The extra HBlank time shifts everything except the Playfield right by 8 pixels, because the position counters will now resume counting 8 CLK later than they would have without the HMOVE. This is also the source of the HMOVE 'comb' effect; the extended HBlank hides the normal playfield output for the first 8 pixels of the line.

Can someone point me to a post or document that describes how HMOVE affects background display? I've been experimenting with moving sprites around in the kernel, and I'm seeing those nasty black lines on the left side of the screen that were so common in Atari games. I'm getting the feeling that these lines are unavoidable if HMOVE is called during on-screen scanlines, but I want to get the details so I can figure out how this will affect my game. TIA (Thanks in advance, not Television Interface Adaptor)

Hi John, Thanks for working on PCAE. I've been using pcaewin since I started doing Atari development in 2004. It's still my favorite emu. The debugger has helped me solve many nasty problems in my code. I've been using it with XP for a couple months now, and it works fine for me.

Cybergoth: I admit that I do like weird controls. It makes the game more interesting than the standard joystick. But for this game, I'll be sticking with the standard joystick for 2 reasons. First is, I don't own an Atari driving controler. The second is, I doubt many other people own an Atari driving controller. If this game were to expand into an 8K cart, it would be a possible optional switch, but I know it won't happen in a 4K cart, as I will assure you I will eat all the ROM by the time I'm done. My favorite target for design is the standard 2600 with a 4K cart. Regarding weird controls, I own 2 USB driving wheels, 2 virtual fighting pads, one of which has infrared motion sensors, a vibrating mouse that vibrates based on sound from the soundcard, and one of those wacky P5 virtual gloves. I hear Wings of Fury mentioned a lot with this game, but I've only played that game once, and it was because it was mentioned so much. While Wings of Fury looks great, it's not the basis for this game. The conceptual basis comes from a game called Two Tigers. This was one of my favorite games in the 80s. The other basis for this game is Intellivision Triple Action Bi-Planes. I loved the stalling-out feature in that game. Thomas: This will only be a one player game. I use GRP0 for the player, and GRP1 for the enemy plane. I'd have to frame switch to add a second player, and it would also eat a lot of scarce RAM (player positions, mutliplexed sound, 2 BCD score displays, etc.) Two simultaneous players would be great, but it's not practical with the physical limitations of the 2600. That would be more appropriate for a Supercharger game, or a C64 game. vdub_bobby: Thanks. This game will definitely be completed before the end of this year, and will likely end up in a physical cartridge. It's my favorite project. If I can get it done soon enough, it will also be submitted to the 2006 mini comp.

Nice work there Nathan. Thanks for your help. I'll be busy the next couple days with non-Atari activities, but I'll get this coded up as soon as I can. My pixel maps for this kernel are a pain. I have to split the graphic tables into odd and even rows. I'll probably write up a small perl program to do that for me. It's tedious work for 16 sprites, and I'll likely be doing a similar odd/even algorithm for Battle of Midway.

There was a nice version of War Games for the Commodore 64. The premise of the game was that you weren't actually fighting a nuclear war. You were playing against the W.O.P.R to prevent defcon 1 before the timer ran out. A fun game, and graphically advanced for the C64.

Hey Nathan, Thanks! That's a nice graphic. I'll try coding them up and see how they look. I could go to 8 x 10, but I wouldn't want to go any larger. My original intent was to use 8 height, and only about 6 pixels width to keep the proportions consistent. What tool do you use to make your gif animations?

I'll probably have to stick with 16. That's how many are used in asteroids, and most games for the Atari, and it works well. The limiting factor isn't the math, or even memory. Using trig tables, it's trivial to add more rotation positions. The limiting factor is the graphics. The spaceship has to fit in an 8 by 8 pixel display, and it's tough to rotate the image and still have something that looks like a spaceship (as opposed to, say, a squashed bug.) This problem is compounded by the fact that pixels in the 2600 are rectangular rather than square. I'm really happy with the graphics for the current 8 positions of the ship in the game, and spent a good hour or so fine tuning them. But then I spent another hour trying to make the 22 degree diagonals, and they all look like crap. If anyone would like to submit their own rendition of a 22 degree diagonal ship that matches the style of the current ship, if I use it, you'll get honorable mention in the game manual.

Thanks Manuel. Community feedback is a great motivator for me to continue work on these projects.

Thomas, I'm still kinda noobish with the forum interface, so I'm not sure what you mean here. I used the code tags. Is there a way to make the code section collapsable/expandable? vdbu_bobby, thanks for the suggestions. I tend to avoid illegal opcodes unless I really need the cycles. Currently the kernel does everything I need it to, so I don't plan to cram anything more in unless there's a way I can shave off a ton of cycles (a ton being 5 or more.) Nathan, nice suggestion. I may take you up on that. Keep in mind that I'm not trying to do an exact port of the game, for copyright reasons. This literally is "an artistic reinterpretation." I already have some plans to deviate from the original game. Specifically, a slight retooling of the kernel will allow me to add enemy attack ships in the upper and lower empty space of the screen. These ships will show up occasionally on harder levels, similar to the random ships in asteroids. I may also make a "classic" option in the game, which will match the original game as closely as possible, and then all the other options will have my own added features like the enemy ships, variations in the number of interceptor missles, different shield ring configurations, etc. Also, on harder levels, the rings will slowly regenerate, differing from the full regeneration if a ring is totally destroyed.

Thanks Tom.

Atari Gurus, I'm in the middle of writing a very hairy 2-line kernel, and I've come across an instance where I need to force a zero-page STA to take 4 cycles. I can do this by making the store absolute instead of zero-page, but is there a clean way to do this in DASM without having to specify the opcode bytes? I've got: STA Temp4 The ugly way to force this is: .byte #$8D .byte #Temp4 .byte #$00 Correct? Thanks,

If I was going to do an artistic re-interpretation of Elevator Action, I certainly wouldn't call it Elevator Action. How about Elevator Adventure? Or Spy Against Spy? Or my personal favorite: SpyWhere! Then I'd publish it under one of my many subsidiaries; Slony, Pandasonic, Eclectronic Arts, etc. Oh, and for the record, IANAL.

Looks very nice! Paradroid was probably my favorite game on the C64, out of thousands played. At first I thought you were trying to implement this on the standard 2600 , until I saw the supercharger load screen. It might still be possible without the supercharger, if you made the game like the Amiga version. That version only scrolled vertically. But the supercharger is probably the way to go, given the complexity of the game.

Not necessarily so. The latest version has 5 rings, and there's still plenty of playfield left. I will probably add a 6th ring, for the higher levels. It will make the game harder, but that's the idea. As for the side screen technique, I'm aware of it. At higher levels, the AI just might become aware of it, too. Seriously, my plan is to increase the difficultly each level, so you're always challenged. This won't be like pacman, where you can get one million plus points and play indefinitely. Eventually, the game will beat you. It's just a question of how far you can get. For example, if you make it to level 10, touching the shield will be fatal. You won't find that in the original. Heh. I'll bet my big beefy arm you're wrong on that one. The main objective of 2600 ports is to create a fun game. My game won't look exactly like the original, but it will have the same feel, and I will make sure it's fun to play. FYI, all future posts on this game will be in my blog, here.

The largest obsticale to writing an RTS for the 2600 is RAM. An RTS implies lots of variables, something the 2600 can't handle with its 128 bytes of RAM. However, a great RTS game could be written with the Supercharger. I'm leaning that way for future projects, and possibly for the Supercharger contest. I've only done minimal research on publishing a cart, but AA looks like the way to go.

Hi vdub_bobby, I'm really glad to hear you liked Master of Arcturus. I was wondering if anyone ever played that game after the mini competition was over. I still play it occasionally. The higher difficultly levels are challenging for me, even though I know exactly what the AI is thinking. I need to update the documentation for that game. My original intent was for the player to figure out on their own what the various difficultly levels affect. But, I think that could frustrate some people into not playing the game. As an alternative, I'll add a full description of the difficultly levels to the user manual, along with a spoiler warning to explain my original intent. Level 64 is supposed to be next to impossible to beat. I can only beat it about 1 in 10 games. My main goal in writting that game was to capture the feel of a 3X simulation game (explore, expand, exterminate.) Due to the limited resources of the 2600, the game only has 8 worlds, but this actually has a useful side-effect. The games only take about a half an hour to play. Master of Orion takes about 40 hours to complete a campaign, which eventually forced me to stop playing it. But with Master of Arcturus, I can pick it up any time and enjoy a quick campaign, and still get the satisfaction of conquering the galaxy. MoA will be made into a cartridge, if the demand is there. I do need to clear out a few minor bugs before I commit the code to ROM. Hopefully I can talk my brother into providing some artwork for the game. He's a great artist with GIMP. I'll post a request for pre-orders when the game is ready to go, to determine how many copies to make.

Source control is a good idea. I really have to get off my butt and install RCS for dos. In the meantime, I've just been keeping a simple text log file for version info, and making a copy in a directory for the source, which isn't a problem when you're dealing with 10k text files. For my system, I'm using an older Athlon (1800+) which does fine. For my monitor I'm using a 20 inch NEC LCD, and that thing is great for development. I can run at 1600 resolution and still read the text without going blind. I'll never go back to CRT. For text editing, I'm a devout follower of VI, the One True editor.

Another thing to beware of is that certain memory locations can be affected by reads. In a 4K cart, this isn't apt to be a problem (the only thing affected by a read is the timer-interrupt flag on the RIOT which is cleared by reading INTIM). In a 16K or 32K cart, skipping "INC nn,X" or "ISB nn,x" will trigger a bank switch if 'nn' is $1F, $3F, $5F, $7F, $9F, $BF, $DF, or $FF, but such an instruction isn't too likely to occur. In a 32K cart, skipping "SBC nn,X" will also trigger a bankswitch. None of those bankswitch hotspots is in practice likely to be a problem. On the other hand, RAM based carts open up a much bigger danger zone. On a Superchip cart, skipping any instruction whose opcode is $00-$7F and whose operand is $10, $30, $50, $70, $90, $B0, $D0, or $F0 will trash a byte of Superchip RAM. On a Supercharger, skipping any two-byte instruction whose operand is one of the above will be, to put it mildly, "interesting". 986508[/snapback] Thanks for the heads-up supercat. I want to maintain Supercharger compatibility for all my programs, so it looks like I'll have to ditch my favorite hack.

Here's my all-time favorite hack for the 6502. The "skip 2 bytes" pseudo-instruction, which piggybacks off the BIT instruction. It saves a byte when performing "either/or" branching. Consider the following example. You want to store a value in either Loc1 or Loc2, depending on whether it's negative. Normally, your code would look like: LDA MyNumber;2 BPL B1;2 STA Loc1;2 BMI Done;2 (This is effectively a BRA to Done.) B1 STA Loc2;2 Done It uses 10 bytes. Now consider this alternative: LDA MyNumber;2 BPL B1;2 STA Loc1;2 .BYTE $2C;1 (Skips the next 2 bytes, effectively doing a BRA to Done.) B1 STA Loc2;2 Done It only uses 9 bytes, and does the same thing. When the processor hits the ".BYTE $2C", it reads this as an Absolute BIT command, which is a 3 byte command. So, it uses the two bytes of the STA Loc2 command as the argument to the BIT command, performs a meaningless BIT test, and then continues to run, without ever executing the STA Loc2 command. The only thing to be careful with this is that the N, V, and Z flags will be corrupted. But the accumulator is not affected. So you've just saved a byte. Also be wary that one extra cycle is used. BIT Absolute is 4 cycles, and a BMI branch is 3 cycles (or 4 if it crosses a page boundary.)

Oops. Surely you're not suggesting I should check my scanline count before posting a demo??? V0.02 New in this release: - Cleaned up the Vblank, display, and overscan timers so exactly 262 scanlines are used. - Added a low pulsing sound in unison with the shield visual pulse. This will either add an ominious feeling to the game, or be really annoying. To do: - The original game required 2 shots per shield section to destroy it. Since this is impractical given the color constraints of the 2600, I'll probably just add more single shot shield rings. I'm thinking 6 rings should work. SF02.BIN