ZackAttack

Sprites sort of working. It's moving and resizing the missiles in order to avoid using flicker. Still need to handle positioning the sprites horizontally. Right now the X position is hardcoded in the kernel.

MayDay you need to be more careful about how many PF colors you put on a single scanline/row. Venetian blinds will let you get away with two, but any more than that will start to look bad. I've attempted to recreate this mockup in code. I made the columns wider because I'm lazy and it's easier to draw them procedurally if they are a multiple of 8 pixels wide. The kernel takes a bitmap though so they could have been thinner like in your drawing. Now for the tricky sprite problem...

Interesting, I didn't know that 7800s do that. That A12 behavior isn't limited to the 7800 though. I have a 2600 Jr. that does the same thing. Of course the 6502 datasheet agrees with this behavior since the address bus is only guaranteed to be valid at specific portions of each cycle. Sure would be nice if some of the control bus had made its way to the cartridge... Have you changed your mind about supporting quad-stuffing yet? Regarding PAL vs NSTC, can't you just time how long it takes to execute some arbitrary routine and load the appropriate driver accordingly?

Is that information in the forum somewhere? Can it be?

Nice job! At first I was confused about how to score points because collecting the white pellets have the same animation as taking damage from the black ball and homing missile. Once I unmuted my speakers the sound effects cleared that up. Still it might play better if you omit the animation for collecting pellets. If you time it just right you can get the pellet to pass through your ball without collecting it. You may want to consider increasing the pellet size by a factor of two so it cant slip through the gaps in the corners of the ball. You probably have a bunch of ideas on how to enhance this already, but just in case you don't here are some ideas. Every five pellets collected earns you a single ball-to-ball missile. The b2b missile should shoot up or down depending on the joystick direction pressed. It should spawn in a random location on the left half of the screen so you have to get brave enough to move to the left to pick it up. After 20 seconds it should flash for a few seconds and then disappear. Hitting the black ball with a missile should change it's color a shade lighter each time. Destroying completes the level and the next level has a bigger ball to dodge than the previous. Of course more points are awarded for hitting and destroying the opponent ball.

How is this an official 2600? I tried every 2600 game I had and not a single one fit in the cartridge slot.

Don't forget to read the Stella programming guide a few times.

With 3-way venetian blinds and the 13 color PF it's possible to create a 38x64 colored background.

Don't forget Stella source code is available. You can customize it in order to help automate the process. Reversing software requires a deep understanding of the system at all levels. You will get a lot faster with some practice.

While playing around with the API today I figured out a nice way to get a 13 colored playfield. I think with some refinement I can squeeze in 15Khz sampled audio and multiple single height colored players.

Level translation and bus-stuffing sections are almost complete. It's starting to look like a cart PCB.

I think it would be less confusing to everyone if you keep implementation details of Harmony/Melody/BUS in its own thread and link to it from everywhere else.

The cart has access to the address and data bus. Simply instruct the 6507 to read from the RIOT and watch what value the RIOT puts on the bus. I posted a video of this in action in an earlier post: http://atariage.com/forums/topic/238357-designing-a-cartridge-that-supports-100-cc-game-development/?p=3241026 Towards the end of the video you can see the 8 green LEDs reflected the value of SWCHA ($0280)

I'm not sure that you cannot damage the hardware. Due to the way the 6507 is implemented it can sink far more current than it can source. When the 6507 outputs a logic 1 and the cart pulls it low the current is kept to a safe limit because of the relatively high resistance inside the 6507. I've personally grounded the entire data bus on my 2600 jr. and confirmed with a logic analyzer that it continues to operate just fine. (infinite loop of BRK instructions) Things are a little different when the 6507 outputs a logic 0 and the cart tries to pull it high. There is almost no resistance to ground and the cart hardware is likely a newer technology that has low resistance to +5V. The result can be close to short circuiting the +5V supply to ground. Multiply this by the 8 bit data bus and you have the potential to fry something. I can't speak for the Harmony's BUS driver implementation. It may or may not be possible to get the hardware in a state that will cause it to damage something. The design that I'm working on will use 7400 series ICs and pull up resistors to ensure that no matter what stupid mistakes you make programming the FPGA/MCU, it will be impossible to drive the bus high with anything other than a pull-up resistor. It adds a little bit to the total cost for each board, but I feel it's an acceptable trade off. There is a buffer of commands. Each command translates to a 6507 instruction + bus stuffing data. The buffer acts as a frame buffer. You write an entire frame worth of commands to the buffer and then instruct the system to use that buffer. There are at least two buffers to use. So the MCU can fill one buffer while the other one is used to render the screen by the FPGA. The MCU can take as much time to fill the next buffer. The FPGA will continue to render the active buffer until it is swapped for the other at the end of a frame. Really since the FPGA and MCU are both programmable there can be many variations on this implementation. The Harmony cartridge implementation is called BUS. There are some other topics that discuss the details of that implementation. Basically the ARM MCU acts as a ROM emulator. The 6507 executes whatever code you assembled with the caveat that when in BUS mode a STY instruction will trigger the BUS driver. The BUS driver will then stuff in a different value depending on which TIA register is currently being addressed.

You could mold the cart into a cool design instead of just making it a rectangular prism. That would help hide printer imperfections and also make the game that muck cooler.

The address is made up of 13 bits (signals) and data is made up of 8. Generally we refer to the group of signals as a bus. In the case of the VCS there is the 13bit address bus and 8bit data bus that are brought out to the cart connector. There is also a control bus with a few additional signals, but the control bus is not accessible from the game cartridge port. From the perspective of the 6507 the address bus is an output only and the data bus is bidirectional. Each cycle the data bus will be assigned a direction depending on which cycle of which instruction. Well behaved hardware will only drive the signal on the data bus when it has been told to do so by the processor. In the case of a typical 4K ROM this is whenever the address is in the range $1000-$ffff aka A12 is a logic 1. Keep in mind the convention is to start at A0 so A12 is actually the 13th/highest bit. Bus stuffing works by driving a signal on the bus at the same time as the processor which overrides the data the processor is outputting with a new value. This allows TIA registers to be updated faster because you no longer have to load the value and store the value. Instead the 6507 is instructed to store repeatedly and each time it tries to write the value it's writing is overridden by the bus stuffing circuitry. Here is an example of what it would look like to update the GRP0 and COLUP0 registers without and with bus stuffing. There is also a second way to do bus stuffing that involves overriding both the address and data bus at the same time. This can allow even faster register updates than the first way but is more timing sensitive and difficult to implement. As you can see the number of cycles it takes to update two TIA registers is 10, 6, and 5 for normal, data stuffing, and both stuffing respectively. Looking at it differently a 76 cycle scanline has enough time for 15, 25, or 30 TIA register updates depending on which mode you use. Cycle: 0 1 2 3 4 5 6 7 8 9 Normal: Instruction: |---LDA #xx--||-------STA zp------||---LDA #xx--||-------STA zp------| Address: Out Out Out Out Out Out Out Out Out Out $f000 $f001 $f002 $f003 $001b $f004 $f005 $f006 $f007 $0006 Read/Write: Read Read Read Read Write Read Read Read Read Write Data: In In In In Out In In In In Out $a9 $11 $85 $1b $11 $a9 $22 $85 $06 $22 Bus stuffing data bus: Instruction: |-------STA zp------||-------STA zp------| Address: Out Out Out Out Out Out $f000 $f001 $001b $f002 $f003 $0006 Read/Write: Read Read Write Read Read Write Data: In In Stuff In In Stuff $85 $1b $11 $85 $06 $22 Bus stuffing address and data bus: Instruction: |--------------ROL zp-------------| Address: Out Out Out Stuff Stuff $f000 $f001 $00ff $001b $0006 Read/Write: Read Read Read Write Write Data: In In In Stuff Stuff $26 $ff $ff $11 $22 Programming the VCS can be viewed as simply updating TIA registers at specific times. If we have an abstraction that allows you to specify a list of registers to update and the hardware can consume that list you can take the 6507 out of the equation. Any microcontroller inside the game cart can be programmed in C/C++ to generate the list of registers to update in a memory buffer. What's really nice about doing it this way is that the hardware takes care of timing the actual TIA updates. None of the code needs to be timed anymore. If you take more than 1/60th of a second to update the buffer it can simply redraw the same buffer twice. No more screen rolling because you ran out of time.

Sounds promising. My biggest complaint with assembly is how difficult it is to fail at compile time. Well that and the massive amounts of macros needed to make decent code. The Atari is very resource constrained. You may need to include either the ability to link with assembled binaries or inline assembly for the most timing critical parts. Typically this would be the display kernel(s).

Welcome to the forum. All the Atari games are small. You could probably use any game, but collect is probably the best choice because it is one of the most commented source files you're going to find. I'm curious to see what new features your language will bring. Could you give an overview of what it supports and what it gains over assembler?

I probably wouldn't put much effort into protecting against guessing/cracking. Between Stella and the internet it's going to be easy to defeat an Atari password system no matter what. The thing you do need to protect against is a player accidentally entering a password wrong which happens to take them to a different level than intended. Since you're storing a single byte you could just expand it to two bytes and make the second byte the result of XOR'ing the first byte with a magic number. More symbols will give you shorter passwords, but also can be more difficult to input. Personally I think 8 symbols is just right for the Atari because it maps perfectly to the 8 joystick positions. If you use arrows as the symbols it makes it possible to enter the entire password without looking at the screen. Simply move the joystick in the direction of the arrow and press the button. As far as implementation goes, I'd probably store everything as 256 byte arrays and index into them with the room number (starting at room 0 of course). A second option would be to store all the data in a structure and align it to a power of 2. Either way the module that loads the room shouldn't care if it was called because you beat the previous room or because a password was entered.

I assumed symmetric implied mirrored for this specific application because a repeating symmetric PF would be impossible to align with only the center 96 pixels. I also assumed the BUS driver supported the read modify write form of bus stuffing which gets you two adjacent write cycles at the end of the 5 cycle instruction. Without that you run out of time. The video you posted looks better than I expected. The tile sized movement actually looks pretty good. Definitely some good RPG potential here.

Perhaps it could be done with a repeating PF instead of mirrored. Also, I'd recommend changing the way the players are staggered. Instead of this: 01 01 01 01 01 01 Do this: 0 0 0 1 1 1 0 0 0 1 1 1 That spreads the writes over 8 more pixels and puts a gap in the middle since the first instance of 1 can be set ahead of time. With the repeating PF you can have PF0-PF2 pre filled for the left side and some wiggle room when updating the right side.

I thought 30fps turned out ok as long as you enable phosphor in stella. While it may not be a completely accurate potrayal of what real hardware looks like I think it'd be good enough for this. Regarding the previous comment about the hero moving in tile sized steps. What if you have navigable regions that use PF for the tiles instead of GRP0/1. Then GRP0/1 is available to draw the character at any position inside the navigable regions. Simply split the hero's graphic accross multiple tiles as needed. Maybe with venetian blinds for the hero sprite you could also place one or more enemies in the navigable area as well. So you essential have coarse grained background where the hero and enemies roam and fine grained graphics everywhere else.

How much space are you over by? I'd at least try to make it all fit into 32k before you start culling features. I bet if you post the source and ask for help, someone on here might be able to advise you on how to optimize for ROM space. You should start off thinking big. Look for an algorithm that can be changed to unlock a large chunk of space instead of trying to save a few bytes here or there. List out each component and its subcomponents and estimate how big each one is. The biggest ones are the most likely to have an opportunity for meaningful space savings. If you have spare CPU cycles you should keep an eye out for algorithms that can be swapped for slower/smaller ones.

Running a 4k game is just the first software milestone. It's a the first of many steps in bringing up the new hardware. If everything goes as planned with the DRAM it should support up to 4MB games. The FPGA only has 4000 4-bit LUTs. It's more like a civic engine in a shopping cart. Also, keep in mind that even a 4k game can take advantage of the FPGA. It could easily have a full PF buffer with hardware support for 4way scrolling.

What reference did you use for the dimensions of the edge connector?