Devin

He would definitely have dance combo! Strong Sad might be the only fighter than just knocks himself out - "Oh, I can't win anyway....".

Here's what I have created so far: Line 1 contains characters that I created for my original Commodore 64 version. The second guy, in green trunks, is the champ. Line 2 contains characters I created for a possible "Holiday" related sequel. They are Santa Claus, Frosty, St. Patrick's Day (I might put a shirt on him), Independence Day, Halloween (maybe), Jack O'Lantern (Halloween), and Easter (which is the goofiest picture ever). Line 3 contains miscellaneous characters. The first two might go into a "Time" related sequel. I could also incorporate the Soviet from the top row. The ninja could get associated with feudal Japan. The next two are clowns: Pennywise from IT (from the book) and a generic clown (not evil). Finally, I have a lumberjack and a thief. The last line contains characters from Homestar Runner. I doubt I would be able to create this, though I'm sure the creator would find it funny. I then have masked fighter and a stereotypical representative of spanish television. Finally, I have Michael Moore. I would love to hear everyone's feedback on the designs.

Apparently, the human ear is too sharp to be fooled in that way. Even if the two tones are changed every 1/60 of a second? Curses!

I was thinking of creating a two tables - about 60 bytes each (5 octaves). Each table would essentially be redundant except for cases where I have to transpose two notes to create a missing one. This might be too simple a solution since playing two frequencies at 50% of the time each, might not create the desired result. Anyway, the Play statement in QBasic is quite advanced in the sense that octaves can be moved absolutely or relatively. The solution I was looking at would implement both - allowing songs to be created that can be changed during game play. The initial octave could be increased or decreased depending on game play. Naturally, to even attempt to get the full note range, I will have to stick to the "pure tones". This is just a thought now. Once I fix the ball bug in my homebrew, I'm going to attempt to tackle sound.

Hello everyone, I am curious if any knows of an excellent Atari 2600 sound to music note tables. I found two guides by Glenn Saunders and Eckhard Stolberg - and they should be helpful by themselves. My ultimate goal is to be able to create an array in a programs that just contains encoded notes: quarter-C, full-F#, etc.... The Atari would then look up the pitch and distortion codes in an table and recreate the sounds. For non-supported notes, I might try to iterate between two close notes to create a blended one. Overall the plan is to be able to convert MIDI to Atari. I'll already created a program that converts MIDI to the QBasic Play Statement codes - which are pure notes. A conversion from QBasic Play to Atari 2600 should be incredibly straight-forward (knock on wood).

Each object has a 4-bit motion-compare value (loaded via HMxx or HMCLR) and a pulser on-off latch (not directly accessible). The system also has a 4-bit motion counter, a "counter force enable" latch, and a "HMOVE triggered" latch. The motion circuitry operates using the TIA's system clock (which I'll qclock) which runs at a rate of one cycle every four pixels (i.e. once every 1.33 CPU cycles, or 57 times per line). Hitting HMOVE turns on all objects' "move enable" latches, as well as the system's "counter force enable" and "HMOVE triggered" latches. Those latches get turned off as described below. -1- Every object's "move enable" latch will get cleared any time it matches the system motion counter xor'ed with 8. -2- The "counter force enable" latch gets cleared after one qclock. -3- The system motion counter will count once per qclock unless it's at zero and the "counter force enable" latch is not set. -4- The "HMOVE triggered" latch is continuously cleared during the visible part of the screen. When set, it delays the visible part of the screen by 8 pixels. -5- Each object will receive a count pulse once per pixel during the visible part of the screen, and will receive one count per qclock when its "move enable" latch is set. Each object will be displayed when its count reaches 160; players and missiles may also be displayed when their counts hit 16, 32, or 64, based on NUSIZx. If an object's "move enable" latch is set when a new value is written into HMxx, a variety of things can happen based on the values of the system motion counter and the new HMxx. If HMxx is $80, the object will end up receiving 16 motion pulses. If (HMxx xor $80) is greater than the motion counter value, the move will simply use the new value. If (HMxx xor $80) is non-zero but less than the motion counter value, the motion-enable latch will remain set until either another HMOVE is performed or HMxx is written with $80. Thanks. It might take me a while to digest all of that. In a nutshell, as long as I do my HMxxx calls after 24 cycles, I should be okay? I'm only updating my graphics registers during horizontal blank (with the exception of HMxxx).

I think I found the suspect code in the section of the kernal that draws the computer's head. It is under 24 cycles. Would the bug cause all the balls to to stick together on the screen? The ball graphics are aligned relative to each other correctly. Odd. But, that what makes programming the 2600 so fun! DrawHead LDY ScrnHeadIndex ;---------- ;Ball ;---------- LDA TableHeadBallColor,Y ;Ball color STA Temp2 ;BallColor LDA TableHeadBallCntrl,Y;mmmmssss m=move constant, s=size # STA HMBL AND #$0F ;get index into control table TAX LDA TableBallCntrl,X ;Get CTRLPF and ENABL codes STA Temp3 ;---------- ;Player 1 ;---------- ... I'll flip the code - do Player 1 first. I'm aligning the ball using the same subroutine that I am using for the players and missiles. I modified another sub I found on these forums. In the code below, I capitalized the statements where I made changes. I would appreciate if someone far more knowledgeable than I can give it a thumbs-up. The sub is as follows: PositionSprite sta HMCLR PositionSpriteNoClr sec sta WSYNC STA HMOVE ;+3 --------------------- ADDED BY DEVIN PositionSpriteLoop sbc #15 bcs PositionSpriteLoop;+4/5 7/12.../57 eor #7 ;+2 9/14.../59 asl asl asl asl ;+8 17/22.../66 ;In the following code, I reversed the HMP0,x and RESP0,x ;commands and added a NOP to align the code to the original 5 cycles. NOP ;+2 19/24.../66 STA RESP0,X ;+4 23/28/33/38/43/48/53/58/63/68/73 STA.wx HMP0,X ;+5 sta WSYNC ;+3 0 begin line 2 sta HMOVE ;+3 rts ;+6 9 It works great, even with the modification (probably poorly done). Here's the code that calls the sub to align the ball. This takes place before the end of VBlank. ;--------------------------- ;Align Ball ;--------------------------- InitBall ;Contains position of head LDA CompuPosX CLC ADC #6 ;Atari's 1 pixel bug LDX #4 ;4 = ball JSR PositionSprite LDA #$00 ;BLACK BACKGROUND STA COLUBK STA HMCLR ;Important Which is also breaking the 24-cycle rule. Argh. Thanks everyone for their help!

Thanks Zach. I'm aligning the initial position of the ball during the VBlank period. Does it need to be done during the kernal? I call HMOVE right after the STA WSYNC call. I'm not sure when in the scanline I am setting the HMBL register. The head and body code set HMBL. The head also sets the size of the ball.

So, is there any advantage to using NOP $FFF8 rather than LDA $1FF8 other than preserving the value of the accumulator?

The template worked like a charm! I now have 8k of ROM. Now the biggest challenge - what to do with all this space?! Thanks again.

Thank you! This looks like an incredibly easy template to use. I have a few quick questions. The NOP $FFF9 statement is a tad odd. Is this a valid 6502 command or an assembler hack. I would imagine that a no-op wouldn't have an argument. Does DC.B = .byte and DC.W = .word. I would imagine so, but I'm not 100% sure. Thanks again for the code and a "thank you" to everyone for their help!

Thanks! Now comes the "fun" part - bank-switching! (insert scream sound here)

I've attached a new version where the computer will be delayed 2 seconds after each punch - rather than 1 second as before. You can either block or dodge left or right before you counter-punch. To get more than one hit, step forward after each punch. If you get him on the ropes, you can deliver your deadly combo without advancing. I'll probably have to do some work in this area to perfect the gameplay. I also updated the "in range" flags for both the left and right punch - the math was a little off in the last version. KO_Cruiser_WIP_2008_03_13.bin

Hee hee. That would actually be funny. I might make a sequel where you can box against Atari classic characters. Pitfall Harry would be the champ! I definitely want to put this on a cartridge.

Seemo, out of curiosity, have you started to think about what the cartridge artwork will look like? I'll add it to my list of cartridges to buy.

Update! I just finished the first playable WIP version of the game. The game is far from finished, but the basic format and behavior is complete. The computer character's script is very simple at the moment. He doesn't have any special moves or behavior. For each loop - which contains a bob, flip gloves, etc... there is a 25% chance he will throw a punch. Each punch is extremely slow and is blockable. You can then hit the computer up to 3 times. This number is specified in the script. I can add more - even make it possible to hit the computer when he's just standing there. You can't currently hit the computer until he throws a punch. Otherwise, he will block. Please note, that I still need to program the following: Knock-down logic. Currently, if your health or the computer's goes to zero - nothing happens. Basically, all the characters are still in God Mode with Unlimited Ammo. Sound. It will be more obvious when the computer blocks a punch with the appropriate sound effect. Round logic. The timer will stop at 3 minutes in the final version. Right now it just keeps going and wraps around. I'm only using one byte for the time. Any guesses when it go to zero again? Bank-switching. The final version will definitely require it. I plan to put all the kernal in Bank 1 and game logic in Bank 0. I plan to have 5 or 6 different opponents in the final version. The color of your character will also change when you are in range - and being hit. Your player will have a "my punch was blocked" image. KO_Cruiser___WIP___2008_03_11.bin

Bah! I created my initial set of characters before 'ole King Hippo was on the shelves. Besides, I have much cooler characters!

Wow. It looks great so far. I particularly like the cute animations you put into the main character. I look forward to seeing more.

The computer player's head and torso can cover the ropes - and both use the ball. That would make some pretty funky looking posts! I'm sure I can playing some timing games, but the code is already pretty tight on available time.

This needs to be on its own cart.

Okay. I understand now. IMHO, it probably would be easier to create a version of Dance-Dance Revolution rather than Guitar Hero. At least in the case of DDR, the directions on the joystick can be whatever values you want - or even randomly generated. In the case of DDR, the joystick directions can be linked to animations for some sort of cute cartoon character.

Perhaps the arrows could be integrated directly with the music buffer. When an arrow is reached, the system will no longer advance the to the next note until the correct joystick direction is pressed. This way, the song will rhythmically line up with the joystick input. If the user is slow with an input, the time between notes will be longer. Just a thought.

I've been giving some considerable thought to a DDR-style game using an enhanced version of the BTP2 music driver (used in Stella's Stocking). The biggest issue would be control--I just don't know how much fun the game would be with joystick. Cosmic Ark uses a very similar interface to what could be use for DDR. Perhaps you can draw a cartoon character using Player 0 and Player 1 and use the ball to draw left, right arrows - depending on the next move (player 0 and 1 could be up and down).

AHHHH! GET AWAY FROM ME YOU LITTLE BASTARDS! The aggressive nature of the "Omicrons" does force you to move around the field to survive. Great new version!

Here is a quick update on how the project is progressing. I've attached screenshot from a recent build. Sorry, I can't attach a binary at the moment. I am currently doing brain-surgery on the application to prepare it for the eventual jump to 8k. The ring was set green for testing, but I am becoming convinced that this might be the final appearance. Let me know what you think. Cheers.