ZackAttack

I really like the new colors and enemies. This version is a huge improvement over the last. The jump could use some work though, it should allow you to move horizontally and the vertical speed should slow at the top of the jump and then speed up again on the way down. In other words, better physics would be cool. I'd still like to see the dragon breathing fire.

Got the ring, ball, and running/standing sonic player sprites into the engine. There is still room left for the jumping sprite and the taking damage sprite. I'll add those as soon as I get time. Uncollected rings will be rendered as background since they are stationary. The foreground ring will be for when sonic takes damage. I'll flicker between sonic and one or more rings. I know it's not all that impressive to look at, but the important thing here is that rendering the player uses exactly 22 cycles per scanline during the entire 192 line frame. It had to be small and constant in order to allow the background kernels to work around it. http://youtu.be/AXZcyeuKt6o

Awesome thanks. I'll start posting some videos once I make a little more progress. I just about have the player rendering done. Then I can finish up the scrolling implementation.

@Tokumaru Would you mind if I use your artwork in my program?

I'd suggest coloring the enemies based on class instead of using random colors. Each class of enemy should have a different attack pattern, power, damage, and color. It would be cool if the dragon was green and breathing fire. Since there are no playfield objects in the horizontal region where the dragon resides, you could set the playfield color to orange/red/yellow and use the ball to draw the flame. This technique could be used for other enemies too on some screens. It might be interesting to have to bring the princess back to the castle. She could follow you to the edge of the screen and then wait there while you clear the enemy on the next screen. As soon as the enemy is dead, she would come running up to you and follow you to the edge of the screen again. If the falling rocks hit her it could decrease your health or end the game.

This is really nice. I will definitely use this routine when I need to position multiple objects and the extra scanline/cycles can be tolerated. The 8way scrolling engine I'm constructing only needs to position P0 in this manner. I guess once I run out of CPU cycles or ROM bytes I'll know which approach is right for that project.

I was able to increase the range to 0-160. 160 is equivalent to 0, but it could be useful for smoothly moving the player off the right side of the screen. The ides behind this algorithm is that it uses the division by 15 to create the delay required to position the RESP0 strobe. The remainder is used for fine movement of course. Since the division itself produces the delay, there is no need to track the quotient. Bit 7 in PlayerX is used to decide if the player is on the left or right side of the screen. This gives enough time to calculate and set HMP0 on the same scan line. I wrote this cause I couldn't find any existing code to do this. If there is a better way to do it, I'd like to know. I couldn't figure out how to edit my original post so I'll attach the files here. positionMacro.asm positionMacro.bin

I've created a macro to position player0 and was hoping I could get someone to test it on real hardware for me. It only uses 72 CPU cycles and supports a horizontal position from 0 through 157. Left/Right on joystick moves sprite back and forth. Hold fire to step the movement 1 pixel per joystick movement. I'm including the bin and the asm file. Any feedback is appreciated. Thanks. positionMacro.bin positionMacro.asm

I've been working on putting together a 4k demo with an 8 way scrolling engine that will support a level editor and single pixel scrolling in all directions. I'd like to include sonic and tails in this demo, but I'm not very artistic. Would someone more artistic mind putting together a sprite for me? Ideally it will be of tails flying with sonic going along for the ride. It will need to meet the following constraints. 1. Single color bitmap must be 8 pixels wide and less than 65 pixels high. 2. Maximum of 2 bitmaps for animation purposes. 3. One color per horizontal line. 4. Each bitmap can have more than one color scheme. So if changing some of the colors of each line can improve animation, it could improve the animation without adding additional bitmaps.

If there's going to be a gap in the middle of the scanline, couldn't the COLUPF just be set to match the COLUBK halfway through the scanline to avoid the merging of PF and player graphics? Then you'd only have to update the COLUPF register twice per scanline instead of all the PF registers. (Assuming SpiceWare's assumption is right)

It looks like variable v holds which room you are currently in and can be 0-8. It also looks like you always begin in room 0. So I would recommend generating a number between 1-8. This will prevent the random number from ever being the starting room. if joy0fire then g = (rand&7) + 1 : goto start Now g will contain a room 1-8 to hide the item in. Instead of having an if for each room you can simply compare g with v. If they are equal, you must be in the room with the item. Then we can use data arrays to lookup the x and y positions for each room. Notice that v is used to index into the _item_x_location data array. For example if v is 3, _item_x_location[v] will evaluate to 120 since 120 is the 3rd item in the _item_x_location[v] array. if g = v then missile0x=_item_x_location[v] : missile0y=_item_y_location[v] else missile0x=0 : missile0y = 0 data _item_x_location 30, 30, 120, 80, 50, 50, 50, 50, 50 end data _item_y_location 50, 50, 20, 50, 50, 50, 50, 50, 50 end Hope that helps.

This code looks very redundant. There should be a much easier way to do it than having so many similar if/else statements. I'm not sure how v is being used in the rest of your program. If you post the .bas source file I could assist you further.

You could use this to generate a random number between 0 and 8. (Add 1 if you need 1-9 instead) a = (rand&1) + (rand&7) There are other ways you could do it too. Though I'm guessing the speed for this isn't critical since it's at the start of the game.

Congrats on your first game! I'd like to suggest you change the cowpie behavior so it doesn't follow the cow's horizontal movements. Occasionally the cow moves while a cowpie is flying and it looks weird when the cowpie follows the cow.

If you're looking to understand the internal workings of the CPU I'd start with this video https://www.youtube.com/watch?v=fWqBmmPQP40 and then play with the 6502 simulator at http://visual6502.org/JSSim/expert.html You can also download the source for the visual 6502 simulator if you want to go all the way down to the gate level of the chip.

The 6502 data sheet shows the Input Low Threshold Voltage (VILT) as Vss+0.8. In other words once the /RES pin has 0.8 Volts or more the CPU could come out of reset. The first thing it does is pull the reset vector from the ROM. I'm not sure if any clock cycles occur before the actual read of the vector, but in general a good design will be completely initialized before the POR delay expires. The schematic shows a 4.7uF 10K ohm RC network attached to the /RES pin. So if I did the math correctly it has a POR delay of about 8.195ms. Keep in mind that the original systems had inductors on the power and ground pins going out to the cartridge. So there will likely be a good chuck of the POR delay used up while the voltage going to the cart ramps up. Also, there could be other factors that affect how much time there is before the ROM is accessed depending on the system revision. That's why when developing hardware/firmware it is best to test on as many platforms as possible before release. In theory the design should prevent these unintended interactions, but in practice that's more the exception than the rule. Disclaimer: I make no guarantee about the accuracy of this post

1) Correct. Based on the schematic of the VCS, A12 is used as the chip select input for the TIA and RIOT. This effectively maps those components into all memory locations below $F000. 2) No. There isn't any internal hardware mapped to that memory range. 3) The 6502 bus timing diagram has this information. After the address is stable the Memory Read Access Time (Tacc) is how long you have to put valid data on the bus. Tacc depends on the CPU speed. It is 575ns and 300ns for 1MHz and 2MHz CPUs respectively. Since the 6507 in the VCS is clocked between 1 and 2 MHz I'd use 300ns as the limit. If that's not enough you could interpolate the timing data to get exact amounts for NTSC and PAL versions. 4) Most likely a random state that either completely crashes the program or halts the CPU. There's a good chance the system will have to be powered off to recover. 5) Based on what I've seen on http://visual6502.org/ A12 will remain high as long as the CPU continues to access sequential memory locations. So yes, A12 will remain high across multiple instructions being executed.

What if each kernel could be up to 512 pixels wide and each kernel was designed to overlap with other kernels by 160 pixels on each side? I'll attempt to demonstrate with some ascii art. Each character represents 40 pixels. The groups of 4 O's at the top indicate where 2 kernels overlap by one screen. The top shows 3 different kernels stitched together (the loop is placed twice). The bottom shows each kernel separated. If each kernel is only made as high as at needs to be instead of a screen height, they could be stacked vertically as much as we want. The only restriction would be making sure they overlap horizontally by a screen width. This technique could allow for a level engine that supports 8-way single pixel scrolling and a user friendly level editor. OOOO OOOO OOOO __ __ / \ ___ / \ | | ___/ \__ | | _____\__/_____/ \_____\__/_____ ____ | | | | __ __ / \ / \ | | | | _____\__/_____ _____\__/_____ ___ ____ ____ ___/ \__ | | ____/ \____ | |

You also need to be aware of how limited the hardware on these retro consoles are. Batari Basic (bB) only provides 26 bytes of memory to be used in your program and the background graphics are limited to a 32x12 bitmap of a single color foreground. If you're just looking to produce a cool looking game in a short amount of time then you should stick with the high-level frameworks that you've been using. If you're interested in learning more about writing high performance code and figuring out clever ways to make retro consoles do things they were never intended to do, then you should start with bB and plan on eventually learning assembly.

This is pretty good for your first game. The third fish disappears sometimes, I think that might be a bug? I recommend you review the bB documentation on variable aliasing and sub routines. As your projects get larger you will need to make them more modular to help manage the increased complexity. It will also save you considerable amounts of work once you master writing more generic code that can be reused. Using an alias for variables will make your code a lot easier to read and debug.

Wouldn't this create serious limitations to the level design though? Maybe I don't fully understand your intention here. To me this would be the same as having 160 pixel wide tiles to design the level with. I think it would also require a lot of space for the different combinations. For example if you had 5 screens, they could be combined in 15 different ways or n(n+1) / 2. I'm sure you would only implement the combinations that are used in actual levels, but it could still grow very large.

Also you entered NUSIZO instead of NUSIZ0. (The last character should be the number zero instead of the letter O)

The problem you're having is that you've tangled the different if statements together. This is causing the right player to have dependencies on the left player's state. Change: if missile0x>155 then let missile0y=200:goto skip if missile1x<3 then let missile1y=200:goto skip missile0x = missile0x+2:goto draw_loop missile1x = missile1x-2:goto draw_loop skip if joy0fire then missile0y=player0y-4:missile0x=player0x+4:goto playsound if joy1fire && a = 1 then missile1y=player1y-4:missile1x=player1x+3:goto playsound To: rem if else structure for missle0 processing if missile0x < 154 then missile0x = missile0x+2 : goto skip0 missile0y=200 if joy0fire then missile0y=player0y-4:missile0x=player0x+4:goto playsound skip0 rem if else structure for missle1 processing if missile1x > 2 then missile1x = missile1x-2 : goto skip1 missile1y=200 if joy1fire && a = 1 then missile1y=player1y-4:missile1x=player1x+3:goto playsound skip1 Make sure you understand this if/else pattern before you proceed. There are other places where you have the same issue. This is why the fish will not change both x and y position at the same time.

You should alias the variables to make your code easier to read. Instead of this: rem p is player 1 health and q is player 2 health whichever hits 10 first loses Do this: dim _Player1Health = p dim _Player2Health = q dim _Is2PlayerMode = a Now the alias can be used in the code instead of the single letter variable name. Note that the bB manual recommends a __ (2 underscores) prefix for labels and _ (single underscore) prefix for variable alias. It would be a good idea to follow this convention. See the "Using dim to Create More Descriptive Names" subtopic of http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#variables I wasn't able to compile the source code you provided. Probably due to extra formatting included in your post. Maybe you can attach the .bas file instead of pasting the contents into your post. Finally, there is a sub-forum for bB that would be a better place to post questions regarding bB programs.

The FPGA would be what's providing the normal 6502 code. The only time there will be a collision on the bus is when the FPGA intentionally overrides the data being written to the TIA registers during the bus-stuffing operation. Each line will consist of 24 "STY TIA_Address" instructions (24 * 3 = 72 cycles) and 4 cycles of noop. The noops would be used to offset when the writes happen to try to keep the colors in sync with the pixels during horizontal scrolling.