ZackAttack

You're missing an option for Visual Studio.

You don't really need to understand much to modify the graphics in the asm. Really you just need to know how to assemble it to a .bin so you can test it. Have you tried the following? 1. Open the .asm I attached in my previous post in a text editor of your choice. 2. search for MPH 3. change the 1's and 0's to produce the desired MPH graphic and save the asm file. 4. Assemble with dasm. There's a bunch of ways to do this. This simplest is to call dasm from the command line with the path of the asm file. On windows I use a small batch file which assembles it and then runs it. SET progpath=%~dp1 SET fileName=%~n1 dasm.exe "%progpath%%fileName%.asm" -f3 "-o%progpath%%fileName%.bin" "-l%progpath%%fileName%.lst" "-s%progpath%%fileName%.sym" -v5 "%progpath%%fileName%.bin" but you can get away with just running dasm.exe "C:\path\file.asm" -f3 "-oC:\path\file.bin" ​

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.

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.

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 OUTATIME (by Keebz) - Dragster hack.asm

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.

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

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.

Shouldn't it disappear with a trail of fire once you hit 88mph?

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.

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.

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.

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.

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.

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