ZackAttack

Added schematics for logic level translation and bus-stuffing circuits to the first post. The logic level translation is pretty straight forward. D1 will clamp the voltage to 3.3V when the signal is high and the output will be pulled low by the buffer through the resistor when the input signal is low. A R1 value of 1K should be big enough to limit current to a safe level and small enough to meet timing requirements. The Bus-Stuffing will also perform the level translation. The pull-up resistor R2 will always assert a high signal on the bus. The 6507 and peripherals should have no problem pulling it low. The FPGA will pull the data bits low by activating U2. From the FPGA perspective writing a value to the data bus will look the same regardless of whether or not bus-stuffing is taking place. I found a couple 74LS125's in my parts bin to test with. If those don't work for [email protected] I may try a slightly different design that uses a 74 series part with open collector outputs.

Technically, I guess you'd no longer need to race the beam. For the best results you'd still need to carefully time the TIA updates. It'll just be a whole lot easier and quicker to set it up. A buffer won't be required, but the ARM microcontroller will have have plenty of on board RAM for programs that want to create one. The graphics will still be limited enough to look like a VCS game, but with this design you should be able to achieve better results than what could be done with assembly and even DCP+. Program size will only be limited by the size of the SD card.

An example would be the STA instruction. Normally you would need a minimum of 5 cycles to LDA # and STA ZP in order to update a TIA register. Since the 6502 drives the databus high with transistors that act as pullup resistors it is safe to drive the data bus low during a cycle which the CPU is driving the bus. So as long as A has $ff loaded into it we can trim the TIA update down to 3 cycles by driving the appropriate bus lines low when the 6502 is writing the value. Hence it's called bus stuffing since you're stuffing in a new value. That's pretty much it. Each command will map to a 6502 instruction along with some additional data. The 3 cycle write TIA register command will require the Command ID, TIA Register Address, and Desired Value. This command would then feed the STA opcode followed by the Address and then bus stuff the value. Exactly what I was thinking. The snooped value would then be stored in the retrieved data buffer until cleared by the MCU. If the buffer isn't cleared it will eventually wrap around and overwrite the oldest values first.

I have decided to build a prototype for a new cartridge that will support bus-stuffing and run everything on an ARM microcontroller. The goal for this project is to facilitate the creation of a new generation of Atari 2600 games in a timely manner. Here is a high level diagram of the overall design. The basic concept is to offload the work off timing TIA register reads/writes and bus-stuffing to the FPGA thus freeing the MCU to run the game code. There will be two command buffers that will each have enough room for at least a single scanline of commands. The FPGA will automatically toggle between the buffers and raise an interrupt on the MCU each time the buffers are swapped. The MCU will then need to fill the other buffer during it's handling of the IRQ. When the MCU is not handling the buffer fill requests it is free to run whatever game logic it wants. The following commands are what I've thought to support so far: 2cycle NOP, 3 Cycle Register Write, 4 Cycle Register Write, 5 Cycle Register Double Write (RMW Instruction), JMP to $1000, 3 cycle Register Read, 4 cycle Register Read. Frameworks could be built on top of the command structure similar to batari Basic in order to provide some higher level abstractions for those who are just getting started with C++. I would appreciate any feedback on this design, good or bad. If the prototype is successful I plan to modify stella so it can support running/debugging C++ games from within Visual Studio 2013. All design documents and source will be made publicly available.

I was thinking of the Fast Fetch mode. Could have swore the documentation stated 3 cycle register updates. Must be confusing it with my own project. Sorry about that.

My understanding is that the harmony already does some bus-stuffing in it's DPC+ implementation. Changing the TIA COLUBK register every color clock is not possible from the cart because no control signals are available and the 6507 is too slow. The fastest the background color could be changed without modifying the system is only every 9 color cycles. It's actually good that this limitation exists because it forces all VCS games to have that VCS look and feel. @Treep there are also 96 pixel kernels that you could use. I think they are just 2 48pixel kernels interlaced together.

Well that's disappointing. I think Jaholmes is correct about manipulating the TIA directly. 2 TIA updates every 5 CPU cycles wouldn't be enough to produce that screenshot. You'd need almost twice that. Of course if you're accessing the TIA directly you could just set COLUBK every color clock and have a 160x192 bitmap with full 7bit color. I'm more interested in building a cartridge prototype that is compatible with any VCS system by simply inserting the cart as you would any other cart.

I tested LSR COLUBK this morning and it produces a 3 pixel wide line. I need to review the TIA schematic further to ensure it's safe to force the COLUBK read to $ff so the 2 writes that follows can be overridden with any color.

Could you link to the topic you pulled that quote and image from?

I think phi2 is what actually triggers the latching, but you're right. Overriding the address bus won't have any effect since it's latched. I've thought about the RMW instructions too. That might be useful for setting color registers. You could use it to draw a 3 pixel wide object inside of the playfield. If timed across a pixel boundary it could even be 1 or 2 pixels wide. it's probably best to just focus on the databus. Getting 25+ register writes per scanline is going to be cool enough.

I know there has been some experiments done with overriding the 6507 data bus in order to update a TIA register every 3 CPU cycles (9 color clocks). I'm getting ready to do some experimenting of my own and was thinking that maybe the address bus could be overridden too in order to update multiple TIA registers during the CPU cycle where the write signal is active. Does anybody that's familiar with the hardware aspects of the TIA think that could work?

If you eat a cloud fruit on a cleared screen your health does not restore right away. You have to go to another screen and collect a new fruit before the health meter goes back to full. Is that what is supposed to happen? It would be nice if you can't accidentally eat a fruit when you already have full health. What's a good strategy for the Invictas? Those guys are also laying the smack down on me.

If I had the source code I could double my score too The difficulty definitely ramps up as you progress, but in a good way that makes you keep playing. I finally got good at killing the wasps and then they started flying faster. Looks like you still had a fruit left when the 7th Invica got you. That must have been frustrating!

Got 5380. Score changes back to yellow if you pick up another fruit after it turned green. I always load up before returning to Zazzle field so I have a change against the boss fights.

Isn't that the only way? Don't forget that the TIA runs 3 times the clock rate of the 6507. That 8 pixel window to perform the write is only 2.66 CPU cycles. Storing a value to ZeroPage takes 3 CPU cycles. The reason the 48pixel is possible is because it starts ahead of the beam and just barely stays ahead of it. GRP0/1 can be set to the first graphic prior to the time sensitive section. The A, X, and Y registers can all be preloaded as well. That way during the time sensitive section all that needs to be done are writes. Btw, I recently posted a demo that is similar to what you're asking about here: http://atariage.com/forums/topic/237574-demo-3-sprites-without-flicker/ Reviewing how that works might give you some further insight.

The short answer is that GRP0 and GRP1 are written to 3 times per scanline each. Each write needs to occur in the time between the respective sprite being rendered. So GRP1 is written to while GRP0 is being drawn on the screen and vice versa. You should be able to search around the forum for lots of topics related to 48/96pixel kernels. Just keep in mind that these sort of techniques require timed code. In other words, you have to worry about how long each instruction takes to execute in addition to what it's doing. If you feel this is something you're ready for I would suggest starting with just a Player0 duplicate wide sprite and trying to get different graphics to be displayed on each copy. Also, make sure you lookup how to make use of the debugging facilities in stella.

All those refinements really improved the overall feel of the game. The difficulty curve seemed spot on to me. It isn't repetitive and it isn't impossible. I'm still trying to figure out the best strategy for the boss battles. The third one really put a hurting on me. I can't wait to see what you and your family come up with next.

If you're comfortable with c++ you could grab the Stella source code and modify it to write out a log of what vales are stored to which audio register and also record how many cycles passed since the last register write.

The trapwrite command in Stella should make this easy to do. Use it on all the audio registers. I.e. trapwrite AUDF0

Thanks. I uploaded a new version that lets you modify the bees paths by pressing up or down.

I had an idea to simulate more than 2 sprites by duplicating P1 and updating GRP1 and COLUP1 twice per scanline so each copy of P1 can be a different sprite. By padding the graphic data with zeros the vertical positions of each copy can be changed independent of the other. By moving them in a circle and placing them out of phase with each other, it allows one object to rotate clockwise and the other to rotate counterclockwise. Sorry the source is so messy. Latest Build: bees0.2.bin bees0.2.asm Use up and down to modify the paths of the bees

Sorry, the second doesn't was a typo. I meant to say "native DPC+ requires more effort to take full advantage of it." My point is that there will never be a huge developer base for DPC+ because of the extra complexity it adds. I understand that the ARM just emulates DPC+ but afaik the harmony/melody boards are the only boards that implement DPC+ and they both use ARM to do it. So to me DPC+ => ARM, but that's just my opinion.