Devin
-
Content Count
487 -
Joined
-
Last visited
Posts posted by Devin
-
-
The docs say to set HMxx registers no earlier than 24 cycles after HMOVE: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!
-
Hey Devin,I had the chance to test on hardware this weekend and, well, you can see there are some bugs that the emulator doesn't show. This is probably due to writing to some of the HMxx registers too early in the scanline, the results of which are one of the few traits of the 2600 that emulators don't replicate. I had to learn this the hard way too.
I've also attached a very short video clip that shows the sprites going berzerk:
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.
-
To clarify, the 6502 uses certain bits of the opcode to decide what memory operand (if any) to fetch; the 6502 can make that decision before it has determined what to do with the value it receives. There are some opcodes which will result in a memory fetch being performed, but which will then not actually do anything with the value fetched. These opcodes are collectively referred to as "NOP" even though they do perform an operation (the memory fetch) which in some cases may be meaningful in and of itself.So, is there any advantage to using
NOP $FFF8
rather than
LDA $1FF8
other than preserving the value of the accumulator?
-
The NOP here uses an undocumented addressing mode. If you prefer, you can use CMP or BIT instead, but these will affect the status flags. The bankswitch howto used LDA, but this will also affect the accumulator. The important part is that the bankswitching address is accessed somehow. I prefer the NOP method as this allows the code to continue executing in the new bank as if nothing had happened.From the DASM manual, the valid syntax is DC[.BWL], where .B is a byte (8-bit), .W is a word (16 bit), and .L is a long (32 bit). If no extension is given then the default is a byte. BYTE, WORD and LONG can also be used.
Chris
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. -
Looks great so far. Here is a template for 8K (F8) bankswitching. It assumes that the main code is in bank 2, and bank 1 is called as a subroutine: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!
- 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.
-
Just fired this up in Stella, looks great!
..Al
Thanks! Now comes the "fun" part - bank-switching! (insert scream sound here)
-
I can't seem to hit him even then. He blocks no matter when I punch.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.
-
I'd really like to have this on cart too when it's done. Think you'll be able to add a ref? It would be funny if it was Pitfall Harry.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.
- 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.
-
Be sure to add King Hippo! No Punch Out! is complete without the King!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.
-
Do you want to try to make posts for the ropes using the playfield?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.
-
man, can this game get any friggin better?
if this goes on a limited cart, i'm calling the lowest number possible!!
This needs to be on its own cart.
-
That part's a given. Play a note early or late, and it plays early or late on the audio track (the other voices would all play in correct time regardless). Miss a note and it doesn't play. Move the joystick the wrong way, or when there's no note even close, and a wrong note will play.But how to come up with joystick movement patterns that make musical sense?
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.
-
The essential feature of Guitar Hero is that the moves make sense in the context of the rhythm and melody that's being played; it "feels" like you're actually playing the tune. I don't know how well that would work with a joystick.Further, you should note that graphics could take no more than 30 cycles/scan line if I use the BTP2 or EBTBTP2 driver. That's not a lot, but as Stella's Stocking demonstrates, it's still enough to do some cool things.
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.
-
You know, along these same lines, I was pondering a DDR for the VCS...
Is Paul Slocum still out there???
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).
-
here's an updated version of the game, I had to remove the reset feature and one row of playfield to make room for the ultimate gameplay element : the enemy now doesn't just grow towards the player, it moves towards the player !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.
-
Excellent! The addition of the eggs drastically improved the gameplay - on what is already an excellent game! I wouldn't touch the music or sound effects from this point on. Its just too good in its present form.
Why did you have to remove the highscore? Why not go 4k? This game deserves to be on its own cartridge.
-
The "Discs of Tron" is a classic - and doesn't look that hard on the 2600.
-
The border is a tad small - and it can be annoying to accidentally bump into it and die. The game is still extremely fun.
Would it be possible to have a wider border - and perhaps one that is not deadly to the touch? Maybe there can be two difficulty levels.
-
You could also use a table approach:
LDA SWCHA BIT JOY_UP BEQ JoystickUp BIT JOY_DOWN BEQ JoystickDown BIT JOY_LEFT BEQ JoystickLeft BIT JOY_RIGHT BEQ JoystickRight ;=== No input JMP JoystickEnd JoystickUp ... JMP JoystickEnd JoystickDown ... JMP JoystickEnd JoystickLeft ... JMP JoystickEnd JoystickRight ... JMP JoystickEnd ;---------------------------------------- ;Table. Has to be memory for BIT command ;---------------------------------------- JOY_UP .byte #%00010000 ;Up bit JOY_DOWN .byte #%00100000 ;Down bit JOY_LEFT .byte #%01000000 ;Left bit JOY_RIGHT .byte #%10000000 ;Right bit JoystickEnd
-
About ideas, The missile was used for middle line, ok, can be removed, but kernal had now 4 cicles left...I have others ideas, "Super" means new things, for exemple the "Blind Mode"!
When ball cross the middle, it vanish, and you need figure where the ball is, you can see more or less if take attention in middle line, this is the reason of that bright, what you think?
Ah.I got it.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
K.O. Cruiser - my first homebrew
in Homebrew Discussion
Posted
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).