ZackAttack

You should consider that some may not need a full blown tutorial and will simply use the blog as a reference. So the lack of response may not be an accurate indicator of how many developers have benefited by your efforts. I'd also guess that there is limited interest due to the extra effort required to develop for both systems simultaneously. The DPC+ bB kernel has a much bigger impact of graphics quality and very little complexity, whereas native DPC+ requires more effort to take full advantage of it. Personally I doubt I would ever develop a DPC+ game because it seems silly to me to have to write any assembly when there's a ARM CPU available to do all the work, but I'll still review your blog and learn from it. So thanks for all you effort!

Yes, the return address should have been F0A8 instead of F0A6. The 2 bytes after the BRK instruction are data and should not be executed. Try incrementing FE twice before RTI

Hit the spacebar first on the new line and now you have white space. also check out this post for more info http://atariage.com/forums/topic/236987-i-keep-getting-the-same-error-message/

Started on it late last year. I was looking for a game idea and when I saw the sprites and design ideas/demos from tokumaru and roland p, I decided to try picking up where they left off. Soon I'm going to start work on the hardware prototype so testing the new banking scheme on real hardware can be done.

I think what's confusing you is that stella is trying to disassemble the 2 data bytes after the BRK instruction. That's probably not relevant to your issue. It should always be executing the instruction that follow that macro and once it does, the disassembly will fix itself. I think the real problem is the RBS macro. BSR_ORIGIN_BANK will most likely be set to the bank you're already in instead of the bank you just came from. You should try this instead. (NOT TESTED) Basically just keep track of the origin back in a variable. If you call through multiple banks you may need to refactor it to use the stack or allocate an array instead of a single variable. Hope that helps! -Zack MAC BSR // takes routine address as argument ldx #BANK_{1} brk .word {1} ENDM MAC BANK_HOTSPOT ORG BANK_ORIGIN + $FD3 RORG $FFD3 Hotspot LDA #CURRENT_BANK ;Save the current bank in ram so we know what it was later STA originBank ;<-- declare a variable for this dec $FE ldy #1 lda ($FE),y pha dey lda ($FE),y pha dec $FB sta hotspot,x rts ReturnSpot sta hotspot,x rti BYTE_COUNT Hotspot, "Hotspot" ENDM MAC RBS ldx originBank ;can't use the macro here because this will vary at runtime depending on which bank called into this one jmp ReturnSpot ENDM

Well in that case, the moth should have a rocket pack

Feels like all the little changes made for a large improvement in gameplay. Would it be possible to have a mode where the moth travels straight in whichever direction you're holding the joystick when the button is pressed? Maybe the difficulty switch could choose.

Had to google that. Didn't know that game existed. lol

Finally had some time to start work on the vertical loop tile. Moving both sides in a curve and drawing each ring separately was quite a challenge. I had to hide the flag to enable/disable the second copy of M1 in the color data for P1 and the move data for HMM1. There is still a ton of work to do, but it appears to be possible at least. Here's what it looks like so far. If you pay careful attention you'll see that the graphics for each ring is different. They can be animated to spin in different directions and be easily removed once collected. Debug colors to show how it works:

Stella is what I've been using. I meant one that would allow the breakpoints to be set inside the code editor window. That way I could set a breakpoint inside a macro and only break in that specific macro regardless of how many times the label is reused or which bank it happens to be in.

I'd like to set breakpoints directly in the asm files much like you can do with any modern IDE that supports source level debugging. Is there anything like that for the 2600? Has anyone ever attempted it?

That can already be achieved in the stella debugger once the symbol files are properly loaded. Just hit ` to enter the debugger and all 128 bytes of RAM are displayed in a table. I'm not sure if the variables a-z always get put in the same location. That may change depending on the banking type. The test program I looked at started with a at #D6. @RT maybe you could refine this info and start a "Debugging with stella" section in your documentation.

Thanks for posting this. Can't wait to watch them. When are you going to post an update on Moto-x?

Animation looks great, nice job. I don't notice the overlap anymore either, the meteor breaking up seems to solve it.

Welcome to Atari programming and congrats on building your first VCS game! Personally I would only do flashes when damage is taken. I think that would make them more meaningful. Perhaps the meteors could have a destruction animation instead. The projectiles move so fast that they overlap a lot before the collision is detected. Have you tried giving the meteor priority over the projectile to see how that looks?

It's impressive how well this tells a story. One more suggestion I'd like to make about the animation. The parts with high jumps are awkward because the speed is very linear. I know you're very space limited and this may not be feasible, but maybe you could fit a small lookup table or approximation algorithm so the speed decreases with the height and then increases as the object falls back down.

I think you may be referring to source level debugging where the breakpoint is set directly in the basic source file. That's not available, but you can use the built in debugging tools in stella to set breakpoints and inspect variables. However, stella's debugger is based on 6507 ASM not basic. As with any debugger, there needs to be some type of symbol file to map the labels and variables to their hardware locations. Since bB is directly translated to assembly it can be done. You just need to place the files in the same folder as the bin and give them the appropriate file extensions. I was playing around with this the other day and posted my findings here Note: the stella debugger can be accessed by simply pressing ` (the key below escape) while the game is running.

There aren't any bB debugging features in stella. However, the asm debugging tools are fairly applicable since the bB source is mapped to assembly. Did you try the the modification to 2600bas.bat to see if you could get the symbols to load properly?

Nice demo. I'm curious if you had any applications of this technique in mind as you were constructing it.

Nice job on the animation after you kill the boss.

Finally conquered the platform tile. It now scrolls off the top and left sides properly. Now it can be used as a template for the more difficult tiles like the loop. The level data format was changed to allow horizontal placement at any location and allow for a single parameter. Fortunately this won't take any more RPM space than the previous format. The video is a little choppy because my gpu can't seem to handle stella and bandicam recording simultaneously. http://youtu.be/8ICIDswdJnY

Did you remember to start the line with some whitespace? You'll get a better response if you post basic questions in the basic forum. Attaching the bas file to the post would be helpful too.

The stella debugger offers a lot of cool features to track down the hard to find bugs. You can set breakpoints for execution, writes, and reads at specific locations. You can inspect the current values of variables. It allows you to trace through each instruction as it's executed and will highlight the registers and memory locations that changed in red. When the proper lst and sym files are provided, stella will use friendly names instead of hex values to represent labels in the disassembly and memory sections. I modified my 2600bas.bat to create the files correctly for visual bB and was able to break on labels from the bas source file as well as see the variable names in the disassembly and memory label section. In the screen shot below you can easily see that the Velocity variable has a value of 1 and execution is at the .ChangeDirection label. If anyone is interested in making a similar change to their 2600bas.bat file you can change the dasm line to this: dasm "%~f1.asm" -I"%bB%"/includes -f3 -l"%~p1\bin\%~n1%~x1.lst" -s"%~p1\bin\%~n1%~x1.sym" -o"%~f1.bin" | bbfilter For regular bB (non-visual) I think all you would need to do is fix the lst and sym file extensions on that same line.

I'm trying to gauge how much the stella debugging facilities are used by bB. If it's worth it, I will try to add out of the box support for resolving label addresses inside of the stella debugger for bB and VbB projects. This would make setting breakpoints and reading the disassembly easier.