ZackAttack

Your code says otherwise. ArenaLoop: ; - 11 - time of longest path here cpy FrancisFeet bne DontDrawMissile lda #2 sta ENAM1 lda #4 sta COLUP1 Only the FrancisFeet variable controls if M1 is enabled. An easy fix would be to have a variable named ShowM1 and set it when you want the missile to change states. ArenaLoop: ; - 11 - time of longest path here cpy FrancisFeet bne DontDrawMissile lda ShowM1 sta ENAM1 lda #4 sta COLUP1

If you move the missile past the edge of the screen it just wraps around to the other side. You need to keep ENAM1 cleared once it has traveled to the side of the screen.

You should look at the Collect blog entry for missiles. The source code is attached at the bottom. In collect.asm there is a subroutine named PosObject, just use that to position your missiles horizontally. Don't forget that this routine only sets the HMxx registers. You still have to strobe HMMOVE and probably want to clear the move registers after you've called PosObject for all the objects you want to position. ;set missile0 x position to 74 lda #74 ; x position ldx #2 ; missile0 jsr PosObject ;set missile1 x position to 95 lda #95 ; x position ldx #3 ; missile1 jsr PosObject ;Strobe HMOVE sta WSYNC sta HMOVE ;Wait a scanline and strobe HMCLR ;You must not strobe HMCLR until at least 23 cycles after HMOVE or positions will be wrong sta WSYNC sta HMCLR ;PosObject routine from collect.asm ;=============================================================================== ; PosObject ;---------- ; subroutine for setting the X position of any TIA object ; when called, set the following registers: ; A - holds the X position of the object ; X - holds which object to position ; 0 = player0 ; 1 = player1 ; 2 = missile0 ; 3 = missile1 ; 4 = ball ; the routine will set the coarse X position of the object, as well as the ; fine-tune register that will be used when HMOVE is used. ; ; Note: The X position differs based on the object, for player0 and player1 ; 0 is the leftmost pixel while for missile0, missile1 and ball 1 is ; the leftmost pixel: ; players - X range is 0-159 ; missiles - X range is 1-160 ; ball - X range is 1-160 ; Note: Setting players to double or quad size will affect the position of ; the players. ;=============================================================================== PosObject: sec sta WSYNC DivideLoop sbc #15 ; 2 2 - each time thru this loop takes 5 cycles, which is bcs DivideLoop ; 2 4 - the same amount of time it takes to draw 15 pixels eor #7 ; 2 6 - The EOR & ASL statements convert the remainder asl ; 2 8 - of position/15 to the value needed to fine tune asl ; 2 10 - the X position asl ; 2 12 asl ; 2 14 sta.wx HMP0,X ; 5 19 - store fine tuning of X sta RESP0,X ; 4 23 - set coarse X position of object rts ; 6 29

It's not technically a "task for you" assignment, but I just completed the first 5 parts of the series. Pretty sure your blog just saved me hours of cursing at Linux and gnu

Check out RESMP0, RESM0, and HMM0 in the stella programming guide. Essentially you can either position missiles centered on their corresponding player or position them as you would a player by strobing RESM0 and then using HMM0 to fine tune it. Pairing P0&M1 and P1&M0 would work for producing to multicolor sprites as long as you can tolerate them having opposite color schemes. Otherwise you have to update COLUP0 and COLUP1 at just the right time. That means there must be enough horizontal space between sprites and you also have to have some precisely timed code. Best case for pulling this off would be if the sprites were each restricted to the left or right third of the screen. EDIT: Just realized you meant multicolored in the traditional sense where the color is changed each scanline. In that case you can have each player be a multicolor sprite and the missile will just take on whatever color the player is that scanline. In other words the missile will be multicolor as well.

I agree, it'd be nice to fix but doesn't really hurt the game play.

Thanks for posting another demo. This game is really coming together nicely. I encountered an issue with the collision detection. If you jump into the corner of a wall just right, you can end up stuck in the wall until you jump out of it. Perhaps it is related to the fact that the player is drawn using flicker to enable a two color sprite. Could you draw the legs and feet on every frame to eliminate some of the flicker and possibly improve collision detection with the level?

My concern would be that once you are able to update the TIA every pixel, it will lose everything that makes programming the VCS special. Instead of having to manipulate the limited resources at just the right time, you'll have a 160x192 128 color bitmap. Programming that would be no different than any other system with a frame buffer. Of course, there's also the obvious drawback that the console must be modified. At that point why not just have an HDMI port on the cartridge? I don't see any reason not to make it though. If someone doesn't want to use it, they don't have to. This is just a hobby after all.

It might be good to use the test program I proposed earlier so we'll know which failures are timing issues and which are resistance/electrical issues. I'd be happy to help implement that if needed.

I was able to test this on a 7800, Jr., and light sixer today. 7800 and light sixer worked fine, but the Jr. did not. I tried repeating Crispy's experiment on the Jr. but D0 is always low. I'm guessing this is different than what the others reported. In this case the CPU seems to have got into a halted state. Instead of jail bars garbage is rendered similar to what you'd see if you pull out the cartridge while it's running. Important note about that Jr. is that the harmony menu doesn't display right and A12 always goes low for a portion of every clock cycle. In general this specific console seems to have lots of problems with the harmony. Normal games all work just fine though. I also tested on a CRT and a LCD TV. The LCD TV looks like this.

I see two possible causes to this problem. Either the timing is off or the electrical aspects make it impossible to force some of the data lines low. Ideally you'd have access to the problematic system and a logic analyzer to figure this out. However, since that is likely not feasible I'm proposing the creation of a test program that can be used to determine which one is causing the problem. This program would initialize all the ZP RAM to $FF, hold the data bus low for a second, and then display what's in ZP RAM as PF pixels. Since the data bus is being stuffed with $00 for over a million clock cycles it removes timing from the equation. This will work because $00 is the BRK statement. That means the system will continually push PC+2 and the status register until a non break command is given. That should make it hit every RAM address in the stack page. What ends up in the RAM will indicate if the cart is electricaly capable of forcing the bus low. A solid background color would indicate a timing issue. The appearance of any PF pixels would indicate the cart/system combination is not electrically capable of driving the entire data bus low. Psuedo code: Reset: Set $00 to $7f to 0 Set $80 to $ff to $ff Set status register to $ff (or as close to that as possible) Drive data bus to $00 Sleep for 1 second (data bus must be left $00 during this time. I.E. disable IRQ handlers that would cause otherwise) Resume normal ROM emulation mode. BRK vector should point to here. Break: do vsync set TIA regs back to 0 set COLUBK and COLUPF to something that will have contrast on NTSC and PAL. do vblank LDX #0 TXS LDY #192 drawline: PLA STA PF1 DEY BNE drawline do overscan JMP Break

That's a cool idea. Seems worthy of its own topic don't you think? Maybe include some screen shots as you add new functionality.

As Spiceware pointed out, we can move the player over to handle extended arms and legs. Just don't move anything more than 7 pixels (single wide pixels) each scanline. The 7 pixel movement limit applies to missiles from both sides due to the way I'm reflected the players. So make sure on both the left and right side there is never more than 7 pixels apart from the previous edge on the scanline above.

Updated screenshots now that the converter tool is using a better palette:

I was thinking we just need to define a 256 byte array which maps each NTSC color value to the closest PAL color value. In pal mode just lookup the pal color anytime a write to one of the color register occurs. That way the game code doesn't even need to be nstc/pal aware

I'm not sure how we would implement vertical spikes. The Playfield pixels are too wide to make them pointy. Maybe the RESP trick would work. I remember someone making a circus game that has balloons repeated across the full width of the screen. So do the same thing, but draw spikes instead of balloons. Then the only problem is drawing the body hitting the spikes. Unlockable characters sounds like a good plan. Should definitely add that. We'll need to eventually sync up the palettes we're using so the conversions are more accurate. There should probably be a NSTC to PAL conversion table too. Right now I've just been assuming everything is NSTC since that's all we have here. I think with enough spacing between the two columns of players we can get a full selection box around them instead of lines above and below. Need to start a backlog so I keep track of everything left to do. Yes. I've been creating new kernels and tools to attempt to keep up with all of MayDay's mockups in an actual Atari game. The screenshots I've been posting are actually running in a modified version of Stella that supports my new bus-stuffing API. Hopefully someone will volunteer to help out with the actual game logic. If not I'll get to it eventually. Since everything is being written in C it shouldn't take that long to complete.

PF Converter is functional.

You should continue to make them 160x192 and enlarging them to post. There's no need to convert anything you've already done. I was just recommending you resize any new mockups to 1280x960 (width*8, height*5) instead of the size you've been resizing them to. Either way I'm going to build a converter tool which will convert them to something the code can consume.

Are you clicking the "More Reply Options" button? You have to go there first and then there will be an additional section below the text editor to Attach Files. There you can browse to your png file and attach it. It's one of those things that's only obvious once you know it's there.

The VCS uses pixels that are wider than they are tall. Can you start sizing your mock-ups as 1280x960? In other words a single width pixel should be drawn as an 8x5 rectangle and a quad or PF pixel should be a 32x5 rectangle. This will make the aspect ratio match what the real system and TV display.

Don't worry about freeing up cycles. This game will be written entirely in C and is going to run on the ARM processor. I'll post a video once I get the parallax done. I'm pretty sure you'll agree with using scrolling once you see it in action.

Yes, I've had some problems too. @MayDay, you should try to attach/embed images directly to your post instead of linking to a 3rd party image hosting site. Once you upload the picture there's a link to add it to the post. Btw, what are those 3 yellow bars supposed to be?

Those look great. I can't wait to get them converted and into the engine. The kernel supports PF scrolling. It can even scroll different sections at different rates to create a parallax effect. The overall width in PF pixels can be as much as 128. Keep in mind that the left 2 PF pixels are always hidden by the HMOVE bars. Leave the left most PF pixel off in all your mockups so the image converter can identify which is background and which is PF. There isn't really any constraint or ROM space. So feel free to make as many arenas as you'd like. I'll build a converter that is run as a prebuild step. That way all that has to be done is to drop the image files into the "assets/arena/" folder and click run.

Added support for player movement to smooth out graphics. Just adjusting the top of the head makes a nice improvement. Also, after thinking about how to implement the color changes I don't think it will be a problem to use the player movement to extend the sprite horizontally for kicking and punching.

Thanks for the tip. Making it wider would complicate the palette switch timing further. It's probably best to avoid that. Using a 1 pixel shift to smooth out the edges should work nicely. I'll add support for moving players. The original mockup was pretty close to fitting the constraints. Most of the graphical glitches are from me messing up the data as coded it up. There are a lot of constraints to deal with. Here are the main ones. The player and missile must not overlap. Missiles must be sized 0, 1, 2, 4, or 8 pixels wide. Players must be double wide. (This could probably be changed if needed, but I doubt it would gain much) Missiles can only be moved 7 pixels in either direction between each row. (The revised mockup obeys this rule because the 10 pixel move is split across 2 rows) The easiest way for you to verify the graphics would be to input the data directly into the source code and see what it looks like in Stella. Let me make a few more changes and then I'll push it all to GitHub. You'll need to have Visual Studio 2013 or newer installed so you can build and run the code. Everything is written in C. I can take care all of the kernel code if someone else can implement the game logic and design all the graphics. This should be able to run on a harmony cart once the BUS driver becomes available. If not it will need to utilize the new cartridge I designed.