TROGDOR

Very nice. Gotta love instructables. I get pretty girl-friend from instructables. I like the Stones, and the G&R cover, but I'm partial to Skrew's cover. One of the most severely mangled remakes ever.

Thanks for the explanation supercat. That makes sense. I'll stop worrying about the extra black line in The Battle of Midway. This appears to be a display bug in Stella. If I set it to start at the 34th scanline, it shows 2 full black scanlines at the top of the screen, which is expected. The first blue line for the sky is complete across the entire scanline, and looks fine. But, if I set Stella to start at the 36th scanline, it doesn't start with a smooth blue line like I'd expect. Instead it has 8 pixels of black (similar to an HMOVE comb), followed by blue sky. I double checked this in Z26, and the black line wasn't there.

Hi all, I'm doing work on The Battle of Midway again. One of the things I'm trying to fix is an unexpected HMOVE bar in the upper left corner of the screen. I attempted to debug this by setting a break at the beginning of my kernel, immediately after the timed VBLANK wait completes. I was surprised to find that it returned on scanline 36. There should be 3 scanlines for vertical sync, then 37 lines of vertical blank. So a WSYNC right after VBLANK ends should start the screen on scanline 40, correct? If my VBLANK is ending at scanline 36, I can only guess that my TIM64 setting isn't long enough. I'm using 44, which I grabbed from an Atari programming tutorial 4 years ago. It's set after the initial 3 WSYNCs for vertical sync. My other question is what display property values should be used in Stella for a standard NTSC cart? The default values seem strange. YStart is 34. Shouldn't that be 40 for NTSC? And the Height is 210. Shouldn't that be 192 for NTSC? An explanation of these values would be greatly appreciated. TIA, TROGDOR

Great work Cropsy! I tried it out on The Battle of Midway. There's one problem with the formatting, though. For longer titles, the text is anchored to the south. Can you change it to be vertically centered? It's a problem for both the side and top text. If you look at the images below, you'll see what I'm talking about, especially for the top text. Another minor issue, if you use double quotes in the text entries, it needs to be backslashed when the form text is populated. It still creates the image correctly, but the quoted text is missing from the form entry. Otherwise, a very impressive tool. P.S. Tinman, in your Expendablity game, the first line should say "He's dead, Jim!"

atb17f1 is no longer a registered user. Nice work guys. You likely saved some poor noob collector several hundred dollars. Even if the seller was legit, he needs to learn to get his act together before selling on eBay.

Wow. Tough crowd here. I hadn't even announced that I was working on Firefly, and somebody already hates it!

I think you're confusing that with the greatest death of an industry. jk On topic, I'd have to go with Circus Atari for best death, graphically. For nostalgia, my favorite death is still Berzerk. For homebrews, I'm going to go with the death scene from Hunt the Wumpus, but I'm kinda biased on that one.

Lol. I was going to say exactly the same thing batari! In fact, I think I will. For my homebrews (If I ever finish one ) I don't think I'll bother with a label contest, 'cause I'd just pick your entry anyway... There are other artists here who do decent submissions for label contests, but Nathan's work is just too damn good.

Blog is not dead which can eternal lie. My blog has been dormant for over 6 months, but I'm finally doing more Atari development. Incoming! Use the fire button to fire the cannon. cchaos05.zip Features: cchaos03 - Added on-screen positioning of both ship sprites. - HMOVE every line to prevent comb-effect. - Reduced size of island by removing 6th row of castle. cchaos04 - Added demo cannon ball in ball graphics that moves down middle of screen. - Implemented pseudo 3D cannonball effect by making the ball larger as it flies higher. - Split main kernel into left-side and right side, based on ShipX. Only right side is implemented. cchaos05 - Cleaned up ship display to properly align both sprites. (Or so I thought. See issues below.) - Added sound engine, splash sound, and cannon fire sound. - Added Joystick button support. - Added preliminary AI to move the pirate ship. To Do: - Add cannon rotation angles. - Add cannonball trajectory angles. - Add whistle when cannonball is falling (similar to bomb sound in The Battle of Midway.) - Design a 3D physics engine to properly calculate the x,y, and z coordinates of the cannon ball. Known Issues: - The cannon ball starts well below the cannon. I need to update the coastal rendering kernel to support the cannon ball. Also, 2 scanlines of ocean are used to position the ship. This needs to also support the cannonball. It may require 2 different kernels; one when the ship is on the left side of the screen, and one when the ship is on the right. - I've run into a major issue with the emulators. The display is different between Z26V2.13 and Stella 2.3.5. The game runs as expected in Stella. In Z26, the second player sprite, used to draw the cannons and sails on the pirate ship, doesn't align correctly with the bottom of the ship. Normally I would try to clean this up before posting, but I figured it would be more useful to the Atari community to demonstrate a clear emulation discrepancy between these two emulator versions. I'd also be interested to know which one is "right", as in which one matches the actual hardware. Development Notes: Another thing I'm wondering about is how to properly read the scanline count in Stella. It starts on scanline "0", and when I press the back-tick to pause the game, it says it's on scanline 261. Does this mean there are 262 scanlines? When I run with -n in Z26 (the only reason I use Z26, other than to cross check against another emu,) Z26 says there are only 261 scanlines.

Supercat, thanks for the suggestion, but I'm going to try to make this work without the HMOVEs. If I were to HMOVE the display, it would require pointers for all 24 characters on every frame, which would eat 52 bytes of RAM. That doesn't leave enough to support the game that I'm intending to use this with. Plus, I'd like to be able to play this in an emulator. Have you mentioned this issue to any of the emu developers? SpiceWare, thanks for testing it. I'm at a loss for why this would roll. Running in Z26 with -n, it consistently says 262 scanlines. I'll double check the source. I threw this together pretty quickly, and I may have done something brain-damaged in the Vblankwait. Is there a way in Stella or Z26 to flag potential rolling problems?

Ack. Has it really been 2 months since I've posted? I got a chance to do some coding the last couple days, and I've come up with something that I've always wanted to implement: a 24 character display for the Atari 2600. Behold, the wannabe Atari 2600 home computer! tesoro_bas.zip Features: - Displays 24 characters per line, and a max of around 18 lines per screen. - Character set can contain 52 unique characters. More, if byte sharing is used. - Only uses 26 bytes of RAM. - Only uses 512 bytes of ROM for the character set. - Works on a standard Atari, with a standard 4k cart. Development Notes: The idea for this display came from the classic 12 character text display. My display breaks each of the 12 sprite copies in to two nibbles, allowing for 24 characters total. The character set uses 5 bytes per character, and there are effectively 2 copies of every character, one defined in the left nibble, and one defined in the right nibble. This requires extra processing time, since the left and right nibbles have to be assembled into a single byte for each scanline. This is achieved with: LDA (Buffer0),Y ORA (Buffer1),Y STA GRP0 This requires a whopping 13 cycles, which would make it impossible to squeeze 6 of these into a single 76 cycle scanline. To work around this, I only use this technique for the first 4 sprites. For the last 2, I preload the display data into a separate RAM buffer, so they can be displayed quicker. The total RAM requirements are 16 bytes for 8 2-byte addresses, which point to 8 nibble characters, which are displayed in 4 sprites, and then 10 bytes to hold the raw display data for the remaining 4 nibble characters, which are displayed in the remainting 2 sprites. The original 12 character display code used a pseudo interlacing technique which is nice on the eyes, but unfortunately requires extra cycles. Instead, I ditched the interlacing model, and just horizontally shift the sprites on alternating frames. So, sprites 0, 2, 4, 6, 8, and 10 are displayed on even frames, and the other 6 are displayed on odd frames. This saves me the trouble of implementing HMOVES. It also saves RAM. The 12 character display code required 24 bytes of RAM, because all 12 characters are displayed each frame. My only concern about this implementation is whether the flicker will make it too painful to look at. I've tested the binary in Stella 2.2 and Z26, and both displays look great, as long as the emulator is running at 60 Hz. I haven't tested it on real hardware with a TV. Anyone who can test this out, please let me know how it looks. If you've ever used a Vic-20, you'll recognize the text in the screenshot. I've only spent about 3 hours total on this code, so there's still plenty of optimization that could be done. One thing that would save ROM space is an end-of-line character. Currently, all 24 characters have to be defined for each line, which wastes a lot of ROM. If the flicker is acceptable on a real Atari, this code will eventually become Stellar Adventure 2600, an interplanetary space trading game that will use a lot of text, and yes, it will be yet another Atari project for me to work on. The binary is 8k only because I used my 8k source template when I started this project. It's really using less than 1k ROM. Using the 6k RAM of the Supercharger, this display code could be enhanced to create something very similar to a Vic-20 programming environment.

The last console I bought was an Intellivision. I do all my gaming on the PC, including my retro gaming (don't want to wear out the original equipment. ) Most of my favorite modern-era games were never available on a console (Starcraft, Warcrafts I through III, Diablo I and II, Populous the Beginning, Ultima 9, Civ, Steel Soldiers, several MMORPGs, etc.) PC games seem to have more of a soul than the console games. However, I do hope the Wii does well. Broadcom has some chips in there.

This wiki article offers an insightful description of the crash: http://en.wikipedia.org/wiki/Video_Game_Crash_of_1983 In a nutshell, the number one factor that started the whole collapse was greed. Atari didn't provide sufficient compensation to their engineering talent to retain them. So their talent left to create third party companies. Activision's lawsuit victory opened the flood gates for third party development, which caused crippling market saturation and quality issues, and collapsed margins to the point that the business was no longer profitable. If the manufacturer's had treated their engineers like rock stars, giving them publicity and paying them well, the collapse probably would've never happened, and everyone would have made more money. I found 2 interesting facts in there that would go nicely under the Did You Know section (if they aren't already there.) - US Games was owned by Quaker Oats. - The typical game of 1982 cost $34.95, which is $73 adjusted for 2006 inflation. As for Atari's own collapse, I would attribute that to having to compensate retailers millions of dollars for the vast number of high priced games that didn't sell in '83 and '84, E.T. being the most blatant offender. For E.T., they had to pay millions just to license the name, then millions more to market it, then millions to manufacture and distribute 15 million 8k carts, which were state-of-the-art at the time, and then millions more to buy back the glut of unsold product. The overall crash would have been worse if Atari had ducked its obligations to the retailers and just let all those millions of unwanted E.T. games be cleared out for 5 bucks each. Instead, they destroyed the unsold product.

I also encounted the two loop dead end while playtesting. I'll add a check for it in the next revision. The luck factor will be reduced when I add the rope and guided arrow features.

Are you up to the challenge of level 4? cc2_cd_zip.zip Features: htw18.asm 09/27/06 - Added level display and selection on the title screen. - Implemented 4 difficulty levels. The level defines the ratio of rooms to tunnels: Level 1: 40 rooms, 24 tunnels Level 2: 32 rooms, 32 tunnels Level 3: 24 rooms, 40 tunnels Level 4: 20 rooms, 44 tunnels To Do: - Expand Wumpus clues so they appear in all rooms that are within 1 or 2 rooms of the Wumpus. - Add cut scenes for Wumpus death, Pit death, arrow shooting, and victory. - Add title screen and music. (started) - Add in-game sound effects. - Add difficulty levels and level selection. Known Issues: - I've verified a bug when moving at the top of the screen. This is possibly the bug that Supercat was talking about. If you get close to the top of the screen, you will explore the room on the screen above, without moving into it. This can cause unexpected death, if the room above is a pit or Wumpus. The fix isn't simple. I'll probably have to revamp the room transition code to resolve this. - Firing the arrow at the Wumpus is still quirky. - There is still one scanline of unwanted black lines at the top of the screen that I haven't cleared out yet, but the rest of the lines are gone. - Most of the scanline bounce has been cleaned up. There are still a couple frames in the death scene that are not 262 scanlines. - There are artifacts in the teeth of the death scene that need to be cleaned up. Development Notes: Level 4 is tough. My best score out of about 20 games was 4780, which amounted to 3 Wumpus kills. All the previous versions were the equivalent of level 2, with about 32 rooms and 32 tunnel tiles. Over the next few revisions I will be adding more difficulty features. There will be at least 16 difficulty levels in the final game.

I let my blog fall off the main page. Bad TROGDOR. No peasants for you. This update is the product of taking two steps backward, and three steps forward. The ROM image is now 8K, making it my first 8K bankswitching ROM! This required a lot of code reorganization, which is one of the least fun things to do when writing a game. The biggest problem was hunting down all the subroutines and data references that pointed to the wrong bank and caused the game to lock up. I've cleaned all those out and did thorough testing, so you shouldn't see any crashes. This is also a step backward since I've gone from 90% use of a 4K ROM to 50% use of an 8K ROM. The Hunt the Wumpus progress bar has moved back accordingly. This update doesn't have any graphics changes, so no screenshot this time. The source code is included, if anyone wants to check out my bankswitching strategy. pescoman_x1.zip Features: htw16.asm 09/17/06 - The code has been dramatically altered to work in an 8k ROM footprint. It uses standard Atari F8 bankswitching. To simplify the code and save RAM, there is only one path for switching to bank2, and one path for switching back to bank1. Bank1 holds most of the Vblank processing, and all the Overscan. Bank2 holds some Vblank processing, and all the kernels. Functionally, the game is the same as version 0.15. htw17.asm 09/24/06 - Modified the song playing routine to support multiple song pointers. - Added Victory song and Death durge. To Do: - Expand Wumpus clues so they appear in all rooms that are within 1 or 2 rooms of the Wumpus. - Add death music and victory music. - Add cut scenes for Wumpus death, Pit death, arrow shooting, and victory. - Add title screen and music. (started) - Add in-game sound effects. - Add difficulty levels and level selection. - Add bank switching code to allow 8K ROM. Known Issues: - I've verified a bug when moving at the top of the screen. This is possibly the bug that Supercat was talking about. If you get close to the top of the screen, you will explore the room on the screen above, without moving into it. This can cause unexpected death, if the room above is a pit or Wumpus. The fix isn't simple. I'll probably have to revamp the room transition code to resolve this. - Firing the arrow at the Wumpus is still quirky. - There is still one scanline of unwanted black lines at the top of the screen that I haven't cleared out yet, but the rest of the lines are gone. - Most of the scanline bounce has been cleaned up. There are still a couple frames in the death scene that are not 262 scanlines. - There are artifacts in the teeth of the death scene that need to be cleaned up. Development Notes: I plan to work on level implementation and selection next.

If the company does go belly up (again), that would be an ideal time to publish JoustPong in its original glory. jk

At 1:30 in the morning, after an hour of recoding Hunt the Wumpus to work with bankswitching, I pronounce it: $0A28

This is a very interesting discussion. I've been using the below algorithm for random numbers in all my games, including Hunt the Wumpus. It was the best algorithm I found after about an hour of web research. Although it has worked reliably, it's wasteful in all respects (4 RAM bytes, extra ROM bytes, and many extra cycles.) I'll play around with the 2 byte implementation mentioned above and see if I can integrate it into my games. Thanks for the info guys. ;Random number generator. Creates random bits, and loads them into A. ;The number of bits desired is passed in through the X register. RandomBits LDA Rand4 ASL ASL ASL EOR Rand4 ;new bit is now in bit 6 of A ASL ASL ;new bit is now in carry ROL Rand1 ;shift new bit into bit 0 of register; bit 7 goes into carry ROL Rand2 ;shift old bit 7 into bit 8, etc. ROL Rand3 ROL Rand4 DEX BNE RandomBits LDA Rand1 RTS

Hey guys. It's been a few days since I've worked on this, and I'm ready to jump back in. The next release will most likely be 8K, which will take some code rework. I've never done a multi-bank cartridge, but after doing some research, it looks like it won't be too difficult. (At least, no more difficult than every thing else related to 2600 programming. ) My plan is to place all the kernels in one bank and everything else in the other bank. The final game will have at least 6 unique kernels. The current game has 4. vdub_bobby, you may be right about the footstep volume. I'll wait until there are more sounds in the game before I focus on volume balancing. As for the speed of the footsteps, that's a compromise. I'm using a mask to activate the footstep. Adding a bit to the mask makes it twice as slow, which seemed too slow. The footstep rate is actually very close to Haunted House. If you go back and play that game, you'll see what I'm talking about. I figured that since your player is smaller than the player in Haunted House, faster footsteps made since from a physics perspective. The ideal footstep would be between the slower and the current version, but I didn't think it warranted a lookup table vs. just using a simple mask. supercat, any screen bounce in the game is entirely my own laziness, and will be cleaned up. There should still be tons of time left in the vblank. I'll try to hunt down the bounce and eradicate it. Don't worry about the winning noise. It's only a placeholder. The actual winning scene will have it's own bit map, possibly an animation, and definitely its own music. That's one of the reasons I decided to move to 8K. 4K wouldn't do it justice. The pit scene will also have it's own animation. (Think little pitfall guy flailing as he falls into a pit full of slime.) I'll post the source next time so you can see more of what's going on. For the footstep sound, I'm turning on white noise for 1 full frame, then off for 7 frames, producing ~8 steps per second. If I use a creshendo / decreshendo, I don't think it will sound like a footstep. It should be a staccato sound. I'll hunt for a Haunted House disassembly and see what they did, for comparision. As for the shot logic, you can't hit walls. If you shoot down, it will go to the room below it, regardless of where you are in the room when you shoot. The only exception to that is if you accidentally run into the target room while trying to shoot. That will be fixed when I clean up the shooting user interface. 2600 programers might notice a bit of perfectionism that I put into the arrow shot scene. The arrow moves from off of the right side of the screen, to off of the left side of the screen, without any sprite wrapping. This required black playfield masking on both sides of the screen, timed with the movement of the arrow. (I'm assuming there's no way to turn off wrapping for an Atari sprite.)

A shot in the dark. Features: htw14.asm 08/24/06 - Added arrow shot cut scene. htw15.asm 08/28/06 - Added footsteps - Added arrow shot sound FX. To Do: - Expand Wumpus clues so they appear in all rooms that are within 1 or 2 rooms of the Wumpus. - Add death music and victory music. - Add cut scenes for Wumpus death, Pit death, arrow shooting, and victory. - Add title screen and music. (started) - Add in-game sound effects. - Add difficulty levels and level selection. - Add bank switching code to allow 8K ROM. Known Issues: - Firing the arrow at the Wumpus is still quirky. - There is still one scanline of unwanted black lines at the top of the screen that I haven't cleared out yet, but the rest of the lines are gone. - Most of the scanline bounce has been cleaned up. There are still a couple frames in the death scene that are not 262 scanlines. - There are artifacts in the teeth of the death scene that need to be cleaned up. Development Notes: This is growing into an 8K game, so I can add a lot more detail into the cut scenes, music, sound FX, etc. 4K is getting too crowded. I'm not sure about the footsteps. I'll leave them in there and see if they grow on me. Your player is supposed to be an expert beastie exterminator, and all this thumping around seems out of character for a ranger. I may make the footsteps more subtle. I want to focus on cleaning up the teeth in the death scene so I can have a nice screenshot for the game. It's time to make a formal AtariAge In Development submission.

Hey all, I'm glad you're able to enjoy the game in spite of the placeholders. vdub_bobby and supercat, how does the lighter playfield look on your displays? I did some more development tonight, and I'll have another update this weekend. There is no doubt that this game is going to have to grow into 8K. I've only got about 750 bytes left, and there are plenty more things I still want to add. To accommodate this, I've started doing research on bank switching (mostly from old vdub_bobby posts.) As for high scores, here's my best test game:

Score! Features: htw12.asm 08/20/06 - Added score display. - Added scoring for cave exploration. - Lightened the cavern color based on user feedback. htw13.asm 08/21/06 - Added ability to shoot at Wumpus, and victory / death detection. - Added previous game score display on title screen. - Added buffering to fire button to detect state changes. To Do: - Expand Wumpus clues so they appear in all rooms that are within 1 or 2 rooms of the Wumpus. - Add the ability to shoot your arrow at the Wumpus, so you can actually win the game. - Add death music and victory music. - Add cut scenes for Wumpus death, Pit death, arrow shooting, and victory. - Add title screen and music. (started) - Add in-game sound effects. - Add difficulty levels and level selection. Known Issues: - Firing the arrow at the Wumpus is quirky. See notes below. - There is still one scanline of unwanted black lines at the top of the screen that I haven't cleared out yet, but the rest of the lines are gone. - Most of the scanline bounce has been cleaned up. There are still a couple frames in the death scene that are not 262 scanlines. - There are artifacts in the teeth of the death scene that need to be cleaned up. Development Notes: The following sections have been added to the instuctions. Scoring: Exploring a tunnel: 5 gold Exploring a cavern: 10 gold Slaying the Wumpus: 1,000 gold Winning the Game: When you think you know where the Wumpus is, you can shoot your magic arrow at him. Be careful. You only have one magic arrow, and if you miss, the Wumpus will pounce on you. You can fire the arrow by pressing in a direction with the joystick and then pressing the fire button. (This order is important. If you press the button first, and then push the direction, the shot won't be detected, and you will likely end up running into the room you were targeting. This will be fixed in a later version.) The arrow will travel one room in the direction pressed. If the Wumpus is not in the target room, you will be killed, and the game is over. If the Wumpus is in that room, you win, and you are awarded 1,000 gold. You will then enter a new, unexplored maze, to hunt another Wumpus. I had to add the arrow firing cludge because the victory cut scene hasn't been implemented yet. Without the cut scene, holding the button was causing the code to load a new maze and then fire a second arrow shot immediately, which resulted in instant death.

Regrettably, I won't be submitting anything this year. Hunt the Wumpus is on track to be my next completed project, likely in Q4 2006. Next will be Stellar Fortress in 2007, followed by The Battle of Midway. All three of these games are targeted to be 4K ROMs. Hopefully I'll be able to submit all three next year, and start publishing them into carts.

Hi Eric. I'm glad you're enjoying the game. You're stealing my thunder. All the sound effects that you've mentioned are already in development. I had planned to make a footstep sound, using Haunted House as a model. However, it will be low volume, to keep it from being distracting. I also have considered a collision sound, again similar to Haunted House, but I'm not sure on that, since most of the game is spent colliding into the walls as you slide through the maze. There will be redundant sound clues for each marker. The Wumpus will have a breathing sound, using the dragons in AD&D for the Intellivision as the model. For the pit, I'll use one of two sounds. Either wind (thinking the wind sound from DragonStomper, but lower volume), or a high pitched random dripping sound, if I can pull that off. The bat will use flapping wings, also from AD&D. There will be no visual clues for the bat, just the sound FX. The clue sounds will play constantly, as long as you're in a room that contains the corresponding clue. I'm also considering random spooky ambient sounds that aren't associated with any clue. Hmmmm. Since you're in a cave, echo effects would be nice... The warning messages won't be implemented. I'm starting to run low on ROM, and the text messages wouldn't add enough to warrant the ROM they'd use. I'm also working on a scoring system, something that hasn't been used in previous Wumpus incarnations. My development time is limited right now, but hopefully I'll have another version update this weekend.