ZackAttack

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.

treep78, your best bet would be to use a cheap FPGA and MCU instead of several ICs. The MCU could send data to the FPGA serially so you could get away with using a MCU with only a few pins. The FPGA will have to cost a few bucks, but will pay for itself via the savings on IC count and PCB size. I think this could make your $5 target feasible once the PCB cost is split across multiple units. If you would like to team up on this project I could take care of the FPGA side of things and you could focus on the OS and API for the MCU. Here's what I'm thinking we could make: Background would consist of two scrollable screen buffers. Pixel data would be stored in a 12x30 byte buffer with 40x192 pixels visible on the screen. Scrolling has a resolution of 1 pixel (horizontal pixels are actually 4 screen pixels) Color data would be stored in a 16x30 byte buffer where each byte represents the color of 6x1 pixels (24x1 screen pixels) The buffers combined would require 840bytes of MCU RAM. The FPGA would buffer a line of data at a time and signal an interrupt on the MCU when it is ready for the next line to be sent over. Now the FPGA will handle bus-stuffing the playfield registers at the appropriate time to allow for the 40pixel/7color per line background graphics. This will also leave enough time for around 6-8 additional TIA writes per line. It will be left up to the game program how to utilize those writes. During vblank there will be additional TIA writes available and some time to read controller inputs. The FPGA would also take care of the horizontal scrolling which will be way more effective than shifting bits around in the MCU, not to mention the precise TIA write timing required for the colors to scroll in sync with the pixels. Since the FPGA will signal interrupts when it needs data, the MCU will be able to maximize the time it can spend on game logic processing. The different types of interrupts can be translated in the OS to their respective API callbacks. In other words, you could specify a game code function to be called every time vblank starts! I love the idea of having a C++ SDK for the 2600. It could really improve an already great game library and even open the door for distributing games as digital downloads for a small fee. Though I think at least some of the proceeds should go to this site.

Since the cart cannot force an active write signal I believe you must use a 6507 opcode that performs a write in order to buss-stuff a value into the TIA. Using a read-modify-write instruction would get it down to a 2.5 cycle average, but the writes occur in adjacent cycles (R R R W W) so you would end up getting every other pixel drawn 4 times the size of the one next to it. Including the illegal opcodes the best bet still appears to be a STA, STX, or STY with zeropage addressing.

Since the cart cannot force an active write signal I believe you must use a 6507 opcode that performs a write in order to buss-stuff a value into the TIA. Using a read-modify-write instruction would get it down to a 2.5 cycle average, but the writes occur in adjacent cycles (R R R W W) so you would end up getting every other pixel drawn 4 times the size of the one next to it. Including the illegal opcodes the best bet still appears to be a STA, STX, or STY with zeropage addressing.