TROGDOR

Hi Guillermo, Please provide more info about your project. Is it for the 2600, or a different system? Screen shots and a bin link would also help you get a better response. I can't help with the art request. My artistic skills are limited to 8 bits. Good luck with your project.

To draw the sword, I have to be able to move in both directions. It looks like there isn't a way to have right motion without the bars. Bummer.

Calling all Atari Gurus, I've been fighting with my kernel for the past 2 hours. Right now we're not on speaking terms. I'm working on the Kenjutsu kernel, trying to remove the unsightly HMOVE bars from the left side of the screen. I've done extensive forum research. My conclusion is that placing the HMOVE at cycle 74 should prevent the bars. I've sync'ed up my kernel so that all paths are 76 cycles, and removed the WSYNC. I then carefully timed the entry to the kernel so that it starts at cycle 74, with the first command being an HMOVE. The synchronization must be correct, because my player graphic and the sword are displaying correctly. Very Bad Things would happen otherwise. I've also used the nifty debugger info in Stella to verify the HMOVE is happening on cycle 74 for each scanline. But, the resulting game still shows the bars. I've run out of ideas. Can anyone offer advice on what I'm missing here? Below is the code for my kernel, and I've attatched a zip with the full .asm and .bin. TIA TheKernel STA WSYNC LDX #192 ;2 LDY Sword0Dir ;3 LDA SwordHeightTable,Y;4 STA Temp1 ;3 Temp1 holds the sword height. LDA SwordWidthTable,Y ;4 STA NUSIZ0 ;3 LDA SwordHmoveLookup,Y;4 STA Sword0HmoveLo ;3 LDA #0 ;2 STA HMCLR ;3 31 cycles JSR Wait12 JSR Wait12 JSR Wait12 ;36 cycles NOP NOP JMP KernelLoop ;3 Ends on cycle 74 align 256 SkipSwordDraw LDA Temp1 ;3 (+1 from previous branch.) LDA #0 ;2 STA HMM0 ;3 BEQ ContinueKernel0;3 Block = 12 SkipDraw LDA #0 ;2 (+1) BEQ ContinueKernel1;3 Block = 6 KernelLoop STA HMOVE ;3 This runs at cycle 74. STA GRP0 ;3 LDA Temp2 ;3 STA ENAM0 ;3 Block = 9 ; Check for the sword. SEC ;2 TXA ;2 A now holds scanline. SBC Sword0Y ;3 ADC Temp1 ;3 Sword Height. BCC SkipSwordDraw ;2 or 3 Block = 12 TAY ;2 LDA (Sword0HmoveLo),Y ;5 STA HMM0 ;3 LDA #$FF ;2 ContinueKernel0 STA Temp2 ;3 Block = 15 SEC ;2 TXA ;2 A now holds scanline. SBC Player0Y ;3 ADC #8 ;2 Player height. BCC SkipDraw ;2 or 3 Block = 11 TAY ;2 LDA PlayerGfx,Y ;4 Block = 6 ContinueKernel1 NOP ;2 NOP ;2 NOP ;2 NOP ;2 NOP ;2 NOP ;2 LDY Temp1 ;3 Block = 15 DEX ;2 BNE KernelLoop ;2 or 3 Block = 5 Kenjutsu_Debug.zip

Features: kenjutsu02.asm 07/09/06 - Sword swings in full circle. - Added positioning offset to keep base of sword centered. - Cleaned up sword graphics to have uniform width and length. kenjutsu03.asm 07/09/06 - Added player graphic. - Adjusted sword offset to swing relative to the player. kenjutsu04.asm 07/10/06 - Added joystick support. Joystick controls movement of the player, and rotation of the sword. To move the warrior, push the joystick in the desired direction. To swing the sword, hold down the action button and the press the joystick to the left or the right. - Added movement boundary checks. Known Issues: - The sword disappears when on the far left side of the screen. I think this is related to the HMOVE bars, but I thought that only affected the background... To Do: - Add the second player and sword. - Update the kernel to support displaying both players and swords simultaneously. Development Notes: ADD has set in, and I find myself working on Kenjutsu again, in between baby feedings. Initially this was meant to be a very basic sword fighting game. But I like where this is headed, so I will likely expand this into a warrior RPG, either in a dungeon or a gladiator pit. I also plan to have 2 versions of this game. One will be a 1k game (too late for the minicomp, but there's always 2007), and either a 4k or 8k version with a wide variety of opponents with different fighting styles. My original interest in the Kenjutsu theme was based on a class I've been taking for the past 2 years on Japanese swordsmanship. Here's a video of my Sensei demonstrating a kata with a student. Kinda hard to translate that into a 2600 game.

Thanks guys.

What kind of geek dad would I be if I didn't mention the birth of my child in an Atari blog? Corinne Marilyn Collins was born on July 1st at 7:26 AM at Chandler Regional Hospital in Arizona. She weighed 8 lbs, 2 oz, with a lot of fuzzy brown hair. Mom, dad, and baby are doing fine. Corinne has an older brother Kyle, who was born in 2004. His birth pre-dates this blog, but I have to give credit where credit is due. Here is a picture of Kyle, completing work on the 2600 game Master of Arcturus for the 2004 minicomp.

Hi Bob, Go Fish! is a great game! I hadn't played it before. Very impressive, especially the effects on the title screen. Is there an online manual for the game? I'm trying to figure out if I can eat those eels. Shark! Shark! ranks in my top 10 of favorite classic console games. How's this for a screenshot? I met this friendly shark on a Bahamas scuba trip in 2003. I listened to the splash in Go Fish! with the music turned off, and unfortunately it still has a noticable flange. So I'll keep my current splash, but thanks for the offer. I'm using a creshendo / decreshendo from 0 to 7 and back down, with a frequency of 1. This seems to minimize the flange effect.

In this context, the ZZZs correspond to snoring, so the scientific question here is, "can a person snore when they're in an unnatural unconscious state?" I did some web searches on snoring and comas: According to encyclopedia.com, "Snoring is rough, vibratory sounds made in breathing during sleep or coma." wikipedia.com's entry on snoring states: "Snoring is the act of breathing through the open mouth in such a way as to cause a vibration of the uvula and soft palate, thus giving rise to a sound which may vary from a soft noise to a loud unpleasant sound. This most commonly occurs during sleep, or immediately after death." If a dead person can snore (presumably from externally induced pressure on the diaphragm), then it's safe to assume that a person who is knocked unconscious could also potentially snore. So the ZZZ's are not unreasonable. QED

Features: tbom14.asm - Added Akagi aircraft carrier. The left difficulty switch determines which ship is displayed. A=Yamato B=Akagi. Press reset to see the selected ship. - Fixed bomb loop error. When the bomb is droped, an offset is added to the X position. On the right side of the screen, this can result in a value larger than 160. I was checking for X=160 to wrap. Now I'm checking for X>=160. - Multiplexed machinegun fire in with explosion sounds. - Added shorter and higher pitched explosion for plane impact. - Added moveable object collision detection. - Added player plane crash routine when the player collides with the enemy plane or AA fire. - Added splash sound when bomb lands in the ocean. tbom15.asm - Added title music. - Started using the random number engine. The ship's AA fire now fires from a random location on the ship. Known Issues: - There's an HMOVE bar in the upper left side of the screen. It's coming from the horizontal positioning code. I need to move this up higher in the vblank. - The title music mode is preliminary. If you drop a bomb in the middle of the music, it will stop the music. When the game is finished, you won't be able to control the plane during attract mode, which is when the music plays. Todo: Add the aircraft carrier Akagi. Add sprite collisions (missle to plane, plane to plane, bomb to plane) Add shot down plane effects. - Add score display - Add replicated sprites for enemy plane squadrons. Development Notes: The title music is an adaptation of the title music from the movie Patton. General Patton was not involved in the battle of Midway. I just like the music. I spent an unusually long time working on the splash sound. I'm still not happy with it. The Atari white noise generator has a flange that doesn't sound right for a splash sound effect. If anyone as a suggestion for a better sound, I'm all ears.

After another 12 hours of development, here's version 0.13: Features: tbom11.asm 6/15/06 - Added machine gun sound, multiplexed in with engine and bomb sounds. - Fixed bullet code to prevent Gorf-style bullet retrieval. tbom12.asm 6/16/06 - Added gun overheat. If the machine gun is fired continuously without allowing time to cool, the gun will overheat. If the gun overheats, it will be inoperable for 4 seconds while it cools down. - Bomb can now be dropped to the left or the right. - The vertical momentum of the plane is now translated to the bomb. i.e., if the plane is flying downward, the initial falling speed of the bomb will be faster. This only works in the downward direction. Upward still needs to be implemented. - The bomb cannot be released at sharp upward and downward angles. tbom13.asm 6/17/06 - Rewrote the kernel for the bottom of the screen. It uses mirrored background to simplify the kernel, although it requires strict kernel timing. The kernel can now display the bomb in the ship area. - Moved the ship into RAM so holes can be blown in it. - Added a large mess of code to detect bomb-to-ship collisions and map the bomb coordinates to the correct bit in the ship RAM. - You can now bomb holes in the ship! - Added bomb explosion sound FX. Known Issues: - The bomb loops strangely when dropped near the left side of the screen. (Some kind of boundary condition error I'm sure.) - There's an HMOVE bar in the upper left side of the screen. It's coming from the horizontal positioning code. I need to move this up higher in the vblank. Todo: - Add the aircraft carrier Akagi. - Add sprite collisions (missle to plane, plane to plane, bomb to plane) - Add shot down plane effects. This is going to be cool. Development Notes: The bomb-to-ship collision code was unexpectedly convoluted, and required a good 3 hours of debug. But it appears to be working correctly. If you download the source, check it out.

Hi ~llama. Thanks for the interest in the project. This game will see the light of day eventually. In fact, another major update will be coming in a few minutes. I'd like to submit something for the 2006 minicomp, but time is getting tight.

Hi all, I haven't posted in a while, but I've been doing some work behind the scenes. I got bogged down in the Stellar Fortress code, working on more kernel tweaks and hacking at the AI. Normally I enjoy AI coding, but implementing AI on an 8 bit system with a few bytes of RAM left is painful. So I decided to take a break from that game and revisit The Battle of Midway. The first thing to point out is that after using it for 2 years, I've finally bid a fond farewell to PCAEWin. I installed Stella 2.2 when it was released, and was very impressed with the integrated debugger, so that's become my emu of choice. I particularly like the red highlighting for register and memory deltas. It also provides more crisp screenshots, so no more fuzzy screenshots in my blog. The second thing to point out is that I've finally stopped being a miser with my precious source code. This release contains a zip of the full source and the binary. And on with the update description: Features: tbom09.asm 6/12/06 - Complete rewrite of the kernel. Now uses 2LK, to remove the on-screen sprite shifting. tbom10.asm 6/12/06 More improvements to the kernel: - Ball and both missles now have full resolution. - Both player sprites have full resolution. Used sprite buffering to provide full resolution with 2LK. - Removed artifacts from player sprites in the ship area of the screen. - It's now 262 scanlines proper. Known Issues: - Bomb only falls to the right. - The bomb loops strangely when dropped near the left side of the screen. (Some kind of boundary condition error I'm sure.) - There's an inexplicable HMOVE bar in the upper left side of the screen. Development Notes: Necessity is the mother of invention. I made an interesting discovery between versions 9 and 10. In version 9, I reworked the kernel to 2LK. My intention was to use VDEL to shift both sprites, both missles, and the bomb to provide full vertical resolution. My first disappointment was finding that there are no VDEL registers for the missles! Then, after lurking through some posts on VDEL, I discovered that the sacred stealla.pdf's description of VDEL behavior is inaccurate, and I couldn't get it to provide the full resolution for the sprites either. Blah. So at the end of version 9, I had a half-resolution version of the game. The on-screen sprite shifing was solved, so I was happy about that, but I really didn't like seeing the half resolution motion of all the movable objects. It was too jerky. In version 10, I set out to resolve this. First, I squeezed the 2LK to allow update of the bomb and both missles on every scanline. Not too hard. At that point I decided I was stuck with the jerky half-resolution motion of the planes. But, because of the way I implemented the 2LK, I was now seeing artifacts at the top of my plane sprites. The sprites are 8 lines tall, but the 2LK was overflowing to a 9th scanline, either before or after the sprite, and that was being drawn to the screen. To fix this, I buffered the plane graphics data with a line of zeros on at the start and end of each sprite animation. Now, here's the amazing part. As soon as I did this, the planes suddenly went to full vertical resolution!! It was totally unexpected. My 2LK processes 2 scanlines of GRP0 in the first line, and 2 scanlines of GRP1 in the second line. Adding the extra zeros into the graphics data provided a perfectly meshed offset, so that the planes moved smothly from one scanline to the next. I'm still relatively new at kernel coding, but I've never seen this technique mentioned in any kernel discussions, so I'm wondering if this is new? Or did I just reinvent the wheel? In either case, I'm very happy with the result. I suspect there's a more efficient way to achieve full vertical resoltion in the player sprites using the VDEL buffers, but I'd have to see a 2LK code example to understand it. For comparison, here's a binary of the older version 9 of TBOM. You'll see the jerkiness I was complaining about.

If you liked Tron, you must get the game Tron 2.0 for the PC. It's only $9.97 on Amazon. Very fun. The plot, graphics, and gameplay fit nicely with the feel of the original movie.

Nice effort on the scans. I'd recommend a slightly higher resolution, though. The smaller text is difficult to read. 1989 seems like a strange year to start a magazine for Atari enthusiasts. But still an effective business model. Charge for a year subscription, produce 3 issues, then fold... If you get any grief about copyright, be sure to remind the copyright holders they still owe you six bucks.

My coding and my gaming habits are similar. Usually in one to two hour bursts.

I was sitting down to do some more development on Stellar Fortress tonight and decided is was time that I check the current ROM and RAM usage. Not good. ROM only had one page left (256 bytes), and RAM only had 16 bytes left, and that's including the space reserved for the stack. So I was forced to postpone development and instead start code optimization. A quick check of the code showed that 50% of the ROM is currently used for logic, and the other half is data tables. Fortunately I made flagrant use of the "align 256" macro. Some of these reserved pages were only using a quarter of the 256 bytes. Without too much work, I was able to shift the data and subroutines around, resulting in the removal of several align 256's. I now have 5 pages free, about 1300 bytes, so the ROM is 70% consumed. RAM optimization is going to be harder. I don't use many subroutines, so I'm only reserving 8 bytes for the stack. It also occurred to me that my 2 byte graphics pointers can be refreshed every frame, so I can move them to temp storage. This has freed up about 16 bytes of RAM, so it's still going to be tight. But at least I've got enough breathing room that I can go back to normal game development.

Thanks for the feedback guys. Nathan - I decided to make the game as true to physics as possible, so the ship will not slow down during normal flight, given that space is a vaccum. However, I will dampen the velocity energy when the ship hits the shield, by around 10 percent. That dampening hasn't been implemented yet. There are a few known bugs in the game. I try to keep those listed under known issues. Don't worry about reporting bugs yet. I'll be more focused on removing bugs when the code goes alpha, which probably won't happen for another 20 revisions. There are several problems with the ricochet physics. As you mentioned, the ship can pass throught the shield at high speeds. I'll probably reduce the top speed to fix this. The ship also sometimes bounces at unexpected angles when it hits the corner of the shield. I'll overhaul that code when the full vertical resolution is implemented.

There is an old adage that says "It's not a video game until you can shoot something." Well, now you can shoot something. New Features: v0.16: - Added thrust soundfx. - Added shot to shield collision detection. Sections of the shield can now be destroyed by the player's Ion Pulse Cannon. v0.17: - Added Ion Pulse Cannon soundfx. - Implemented BCD score addition routine. - Added scoring for destroying shield blocks. - Implemented supression of leading zeros in score. - Added startup shield generation graphics and sound FX. Todo: - AI for the enemy DASMs and Plasma Cannon. - 16-bit physics for the DASMs. Development Notes: I spent about an hour on the player's cannon sound. I'm happy with the result. It doesn't sound like a pea-shooter. It's got a deep resonating sound, as you would expect from an Ion Pulse Cannon. Rather than just make the shield suddenly appear, I added a graphical effect that dynamically generates the shield. You can shoot at the shield while it's generating, but you won't be able to aim fast enough to hit the central cannon with a cheap shot. Believe me, I've tried. I worked out a detailed backgound story to the game. Now I just need to get it down on paper. There is another old adage that says "Atari homebrew developers stay up way the hell too late." Time to get some .

Devilbunnies! I snort the nose, Lucifer! Banana, banana!

The Devil Does Drugs.

Consumers need to stop being so selfish. Did they ever consider the needs of the corporation? Corporations are people too, y' know. My co-worker has a PSP, and it's pretty easy to see why UMD failed. He bought a 2 gig (Sony-proprietary) memory stick for his PSP, and he can play his own encoded movies directly from the stick. Sony crippled movie playback from the stick by only allowing 320x240 resolution, vs the full 480 x 272 resolution. But even in the reduced resolution, movies still look fine played from the stick, and the reduced resolution actually helps keep file size under control. My co-worker has never bought a UMD for his PSP. Once the UMD is completely dead, it would be nice if Sony could remove this crippling "feature", but it wouldn't surprise me if it's implemented in hardware to prevent hacked firmware circumvention.

From the Wikipedia entry on M.U.L.E.: "In 1996 Computer Gaming World named M.U.L.E. as #3 on its Best Games of All Time list on the PC." For comparison, Doom was ranked #5 on that list. I don't want to hijack your thread, so I'll refrain from any more M.U.L.E. comments. I was just surprized that you haven't played this classic. vdub_bobby, the only port of Paradroid that I'm aware of is its port to the Amiga, called Paradroid90 (as in 1990). It is an excellent port with nicely updated graphics.

Manuel, you've never played MULE??? You're missing out, my friend. Paradroid was one of the greatest games ever written for the C64. MULE was the greatest game ever written for the C64. (IMHO)

It just occurred to me that if I wanted to get through this game, I won't need a trainer. I can use the save-state feature in the emulator, and save the game every time I make reasonable progress. When I get some free time (arg) I'll do this, and post some screenies.

The only TV I watch anymore is the Colbert Report. It's an excellent source of morally grounded conservative journalism. Most of my video game playing consists of play-testing my 2600 development homebrews. That and playing the disease that is Runescape. I have Starwars Battlefront I and II still in the shrink wrap and waiting to be played, but I want to upgrade my Nvidia TI4200 video card first. (I can't believe a fourth generation video card is now ancient technology...) I've got about a five to one ratio on video games vs. TV.