ZackAttack
-
Content Count
785 -
Joined
-
Last visited
Posts posted by ZackAttack
-
-
Modifying the bin directly is fine for graphic and very basic hacks. For more complex hacks you should disassemble once and then make changes in the ask file and build a new bin using dasm.
That way you can add comments and rename labels as you discover what the code does. It also makes it possible to insert new code and data like I did for MPH.
-
MPH Graphics... Here you go!
Also, I saw you bumped it up to 4K!
If you could help me understand how to point that to a title screen at launch I'd could make a awesome title screen.
There a lot I think could be done with this. The game play needs some tweaking because hitting 88mph basically just means "go into 4th gear and wait"
But its really a great wip!
Hopefully I can work on it some this weekend as well.
Dropping a title screen in should be straight forward. If you want you can just provide a separate asm file for that and I'll stitch them together. What if you have to hit 88pmh before the car travels too far to the right. MPH looks good, but you didn't attach the source file too.
-
Yeah, the blacked out part just needs some mph graphics. I figured I'd leave that up to keebz to do.
I wonder if it would take much to add a 5th gear and adjust the max speed in each gear to match the actual delorean: http://www.roadandtrack.com/car-culture/classic-cars/reviews/a27099/1982-delorean-dmc-12-road-test/
-
Graphic pointers are derived from ram_b3 and ram_b5. Values outside the range 00-99 produce other parts of the display such as blown and early. Fortunately there was enough room for two more tiles in that ROM page. So I was able to hardcode b5 to $fe and put some place holder graphic data there for you to turn into MPH. (Search the ASM file for MPH to find the spot to edit)
It still needs some tweaking to fix the speed. Right now the speed variable counts in binary but displays in BCD, so it jumps all over the place. The speed climbs too fast too, causing you to hit 88MPH way too soon.
OUTATIME (by Keebz) - Dragster hack.bin
-
1
-
-
6502 assembly isn't as bad as it first looks. Give this a read and it should be enough to get you started. http://www.atariage.com/2600/programming/2600_101/03first.html
When you get stuck just post the asm file and explain what you're trying to do, what you've done, and what you can't get to work.
Btw, a lot of the variables are outlined here but you have to add $80 to them to get the actual address because he's listed them as offsets from $0080.
Don't forget you can change RAM values directly in stella. So an easy way to verify a variable is to change it's value and see if it effects the game as expected. Just don't forget that the game may overwrite your changed value.
-
how did you know that f357 did that when changed to b3?
First I used ~ to open the stella debugger at different times during play. Watching the RAM values change as I did allowed me to spot $b3 as the variable for 1st player time in seconds and $c0 as the speed of the 1st player. Then I used "trapread $b3" to find the places where the time in seconds is read from. The assumption here is that the code which displays the time must first read its value from RAM. Sure enough it breaks around $f357. Looking at the disassembly in the debugger it's easy to spot the $b3 used to indicate where it's reading from. Then it's just a matter of changing that to the speed variable instead.
I think the next step would be to find the code that loads the subsecond portion of the timer and then hardcode it to point to graphics data for "mph". To make things easier, you probably would want to disassemble the rom to an asm file so you can make changes in assembly instead of patching bytes in the bin file. I'd also bump it up to a 4k game so you don't have to worry about squeezing in new graphic data. There are several tools you can use to generate the asm file. Just search for 6502 disassembler and find one you like. Then you'll need dasm to assemble it back into a bin. Make sure you have disassemble and reassemble working before you make any changes.
-
Patch $f357 to be $c0 instead of $b3 to make the timer display the speed in place of seconds
-
1
-
-
A cheat device would actually be a fairly simple project. A small FPGA with some built-in ROM to hold the menu program would be all you need. You should build it. There's plenty of people on the forum who could help you.
-
1
-
-
Shouldn't it disappear with a trail of fire once you hit 88mph?
-
2
-
-
How about an update?
There's still a lot to finalize before this could go mainstream, but at least at this point it's been shown to work on every system that we've tried. Unfortunately I'm not sure how to retrofit this to the original BUS driver or if it will even be possible. In order to make it work for the problematic systems the opcode used has to be calculated on the fly and only some of the bits are stuffed. This is dependent on the value being stuffed so it can't be calculated until we know what value is going to be stuffed in.
I've been working with MayDay to build a fighting game based on this technology. Hopefully we'll be posting a playable demo in the next month or two. We did post a test rom of the background last month which uses bus stuffing to draw the background.
Despite everything being written in C it is not any easier to write games with this new driver. Now instead of just racing the beam the ARM MCU is racing the 6507 while the 6507 is racing the beam.
-
4
-
-
I made it to level 2 as well and then quickly died. I'd prefer if the enemies were constrained to the screen instead of allowing them to warp off one side to the other. And maybe they could fall to the ground a little slower, at least in the earlier waves. It seems like the delay to start a new game is variable, you may have a bug that causes the delay to be longer some of the time.
You need to enlist your spouse as a graphics artist or game designer so you can keep making games without losing your marriage.
-
Depends. Does it have a flux capacitor in the back? We may need to time travel in order to verify it.
That's the only way this thread is going to die. Someone needs to go back in time and force Activision not to publish times.
-
1
-
-
Your project is coming along nicely.
Just a side note about having lots of files vs one large file. Besides the obvious benefit of better organizing your project it can also help with compile times. This isn't an issue for an Atari game, because they're so small. For larger commercial projects the compile time can be significant. Having many source files and a proper make file which only builds what's necessary can make a big difference.
Regarding organizing the banks. You'll want to keep kernels and corresponding data in the same bank for performance reasons. I.E. don't switch banks while racing the beam. My understanding is that you're going to have a few different render modes for this game. I'd put each one in its own bank and fill the remainder of each with corresponding graphics data. Everything else should go into a different bank to start. Then you can move stuff around as space gets tight.
-
Maybe you can get some help with optimizing in the bB forum so you don't have to cut those rooms.
-
Pictures are useless as proof of a video game score these days.
For older systems I would think videos are just as useless. It's way too easy to hide some cheat hardware in the cart, controller, or console. It would be easy to make a modified dragster cart which has the finish line moved up just enough to make 5.51 possible. Come to think of it, why didn't Todd just do that?
-
Having the world record time with a second player seems very suspicious, but I suppose it would be a legitimate scenario.
-
Also you could have send in a photo of the wanted time while the game was still running and the dragster is close to the finish line. On the resulting picture the dragster would be a very few pixel left of the finish position (2 pixel for 5.57), but that is really hard to identify on a blurred, CRT photo.
All you need is:
- good enough skills to be at least close to the wanted time
- a friend taking the photos
- patience (or a VCR with decent freeze frame)
Wouldn't the time from the second player give this away though?
-
Yeah, that's pretty much what I had in mind.
-
I'd also like to suggest that you clean up your code some. The easier it is to read, the easier it is to debug. Suffix labels with : when you declare them. Keep indentation and white space consistent. Use SUBROUTINE and local labels like .1, .2, ... for procedural branch targets. Use empty lines to separate different pieces of the program. This might seem like a waste of effort, but you spend so much more time reading code than writing it that it pays huge dividends to put in some effort for readability.
Here's an example:
PositionObjects: SUBROUTINE sta HMCLR ldx #3 .1 lda PlayerX,x jsr PositionObject dex bpl .1 sta WSYNC sta HMOVE PollForVBlankEnd: SUBROUTINE sta WSYNC lda INTIM bne PollForVBlankEnd sta VBLANK
-
That would be my guess. It's such a common mistake and often doesn't cause any noticeable failures. It'd be interesting to see what would happen if you add a pull-up resistor to D7 and run it on real hardware.
-
Sprite height shouldn't matter. Since multiple copies are involved you'll be forced to use single wide sprites. The table will need to be specific to which spacing you start with. 3 close and 3 medium would be different tables.
-
One problem is that you're initializing the SP to a random value. (Forgot # to make ldx immediate)
ldx $ff ; stack pointer txs ; assign stack $ff <- SP is no whatever random value $ff was initialized to. If it's < $80 the game will probably crash -
I'm curious how automatic scrolling would work here. Would the idea be to put the player in a sort of bounding box, and if the player tries to move beyond the box, start moving the maze rather than the player? (That is, the player could move around the center of the screen, but if you wander too far to one edge, eventually you stop moving and the maze starts moving. I'm thinking about how the Mario games handle their horizontal scrolling this way.)
That's exactly what I was thinking. Of course you should be able to cross the bounding box when you get to the edge of the maze and can no longer scroll. That or allow it to scroll the edge of the maze far enough that it is in the bounding box.
One idea for game play could be to have some moveable walls. A dynamic maze/puzzle game. One way passages might be useful too.
-
We were actually just discussing this in the assembly forum. I proposed an algorithm which could be used in bB too. Maybe that helps you?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Weird problems with COLUPF/COLUBK inside Main Loop
in Atari 2600 Programming
Posted
If you use a repeating playfield you can set PF0 and PF1 at the end of the previous line during the time PF2 is drawn. That way you can save hblank for other updates such as cokupf and colubk.