Jump to content
IGNORED

Freeway hack question


vb_master

Recommended Posts

Hard to say without looking at it. I would imagine your best bet is to Disassemble it and start scanning code for the playfield registers. I doubt HOM will help you here. Only occasionally do I see playfield elements represented in HOM. :sad:

 

You seek Nukey, he can help you. :)

Link to comment
Share on other sites

Dammit! I got hit by a car. :-(

 

..

 

I think a neat idea for a hack of Freeway that might make it fun even as a one-player game would be to make it so that any time you are hit by a car the game ends. This way you get to see how many times you can cross the road flawlessly without getting hit. Maybe there could be two modes - one with a timer (so you gotta hurry too), or without a timer just to see how hard you can go. The last truck level can be amazingly hard! :-)

 

Back on this hack though... if you could hack in a mailbox, was the original idea for this to be a mail carrier type game? GO POSTAL! YAH BABY YAH!

 

k, um... bye.

Link to comment
Share on other sites

If you are reading PCAE's freeze window to better understand the code...you have gonna have a hard time. Your best bet is to use Distella to create a disassembly, and begin looking there.

 

Think of how the 2600 creates it's screens. Pixel data is put into 3 bytes and then those registers are sent to that scanline. So you'll need to look for the routine that does this. Distella automatically tags register locations with abbreviated names so you can better locate when the A, X, or Y register is being saved to them...and then backtrack where that data originated from (which will also be labelled). Unfortunately, it's entirely up to the programmer if the game screen data is fully mapped out in the game (which is unlikely on ANY 2600 game...much less a sparse one like freeway). The game data itself might consist of only 9 bytes...

-Border (3 bytes)

-Street (3 bytes)

-Dotted line (3 bytes)

...and the game's display kernal decides which of those sets are sent to the playfield registers. It may even be simpler than that...say by having the kernal decide when to send a given single value to all 3 registers depeding on what scanline is currently being updated...

You need to keep in mind that the 65xx is a very dumb animal...and it needs everything spelled out to it in very small steps.

 

To add in a mailbox or other detailed graphic image, you are better off looking in the code for the area of the kernal that is creating the border...and then fetch new data from a table that you've added for a mailbox graphic - and then passing that value to one of the player images during that scanline. Unfortunately, you'll also have to count machine cycles used for every instruction that you include to make sure that the display timing is still good.

 

Have you begun reading the tutorials in the 2600 programming forum? That is pretty much a first step to learning how this is done.

Link to comment
Share on other sites

Here's a simple solution - maybe...

 

If you don't mind losing the score board, you could hack all of the number sprites to look like a mailbox - they'd all have to be the same of course. Then there would be a mailbox there. LOL!

 

So, what kind of hack is this? Was I right when I asked if it was a game about a postal worker?

Link to comment
Share on other sites

So, what kind of hack is this?  Was I right when I asked if it was a game about a postal worker?
Well, its kinda strange really, my father said "Dont get run over by a car!" EACH and EVERY time I went to get the mail, and he said the Nintendo should make a game about it, I thought it would be a good joke if I showed him Freeway hacked with the chicken sprite replaced with a person sprite, and it worked!

 

Now another question... Can I make the guy crossing the street dirrerent colors for clothing?

Link to comment
Share on other sites

You can certainly change the color of the whole guy, I'm not sure about giving him more than one color. You'll have to go code surfing and find the color registers, then change the values.

 

That is a very neat story and inspiration for your hack. I hope you get a chance to complete it. :)

Link to comment
Share on other sites

As I try to modify the color for the players, Dasm spits out error messages on every line. anyways, I hacked the 0 so it looks like a mail box, now I have to get it aligned properly. Is there any mods I can do? Thanks!

 

A couple of questions:

Does it say that all the commands aren't recognised? That usually indicates that you don't have the text processor 6502 above your origin tag (just above where it says "ORG=F000". Distella doesn't add that in the file when you create one.

 

Also, you need to make sure that all comments in the file have a semicolon first. This tripped me up a couple times when I forgot some. Something like adc $F0 this is where the score is added will generate an error, but adc $F0 ;this is where the score is added will not.

Link to comment
Share on other sites

Oh, and naturally ALL commands/bitmaps that you ADD to the program will have to be SUBTRACTED from some free bytes in the program...and for good measure, you should keep everything exactly where it is until you can track down indirect addresses. So what are indirect addresses? Consider the following:

 

LF500: .byte $00,$10,$20,$30,$40

LF505: lda LF500,x

      sta $EE

      lda #$F8

      sta $EF

Do you see what is happening there? The first line has some values in memory that are loaded and saved to a ram location by the next two lines. The bottom two lines save a value of $F8 to a ram location just above the first...EE and EF. This code example COULD be creating a rom address pointer. So later in the program, an instruction like lda ($EE),y could be getting the data from that address that the code snippet created! Let's assume that x held a value of zero when the first instructions executed. That would leave $EE holding $00 and $EF holding $F8. If y held a value of $03 in the above instruction, the accumulator would be loaded from address $F803 in memory ($F800 + $03). So what do you think is going to happen if you add an instruction below $F800 and subtract a byte at the end of the rom? Those address pointers in the data table are no longer correct (they would all be off by 1 in this case).

Distella will label things that it can "see", but it's up to you to find data tables that hold address pointers.

Link to comment
Share on other sites

START is just a label (like all of those LF's). It's defined right at the end of the rom...low byte and high byte. That is how Distella is able to find it and label it as "start". The point is that until these pointers can be found, don't attempt to remove the number of bytes in any area and move them to another and expect that it's going to work. Use NOP instructions to fill in gaps that you leave by removing instructions...and locate bytes that are not used at all to add instructions of your own.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...