Jump to content

current editors


cxrom

Recommended Posts

what kind of things are still unsupported (or poorly supported) in the available editors? im lookin' to get away from assembly for awhile and freshen up on some high level programming.

so far, i started with a large helmet/graphic/palette editor combo which looks promising. the logo is not positioned correctly on some helmets though. also schedules can be edited with 2 grids of 8x2 combo boxes. matchups, weeks, and games per week all are configurable. i aim to have the editor be fully dynamic, with everything being loaded from the rom.

Link to comment
Share on other sites

I'd like to have an editor to easily change the startup screen too. Just enough to add text, write what the rom is and who made it, and change the year and such. I tried when I made my all time greats rom (which plays much like drummer's 2007 rom btw) and couldn't get anywhere with it.

Link to comment
Share on other sites

The most unsupported features are the various graphics and playbook design.

Personally, I would love an easier way of editing the graphics throughout the game from the field, helmets, to just the graphics in the opening.

I built a program that could extract the playbooks and I know Bad_Al and Konforce did some work on the playbook design but there is still so much more that could be done if you could find a way. Right now I'm still doing entire playbook designs by hand.

Link to comment
Share on other sites

Personally, I would love an easier way of editing the graphics throughout the game from the field, helmets, to just the graphics in the opening.

field is definately doable. i was tinkering with that for the whether hack and it seems to be raw data in kind of a linear layout. this could probably be bundled with a title screen editor. helmets (large and small) and are both already on the list.

now what do you mean by opening? like change just the graphics, but keep the cut scene, or just create a whole new cut scene?

I built a program that could extract the playbooks and I know Bad_Al and Konforce did some work on the playbook design but there is still so much more that could be done if you could find a way. Right now I'm still doing entire playbook designs by hand.

do you have any notes i could use as reference. im still not to sure how plays are designed.

Link to comment
Share on other sites

The field design is in a TSA (Tile Squaroid) format with numbers that order the blocks (some blocks are used more than once).

By opening I meant the Team NFL logo, NFLPA, SUPER BOWL, and possibly the player graphics (SF O-line, Montana, Sanders, and LT).

Yeah, I have notes on the play design and could answer almost any question you may have. It isn't really difficult to understand once you know where and what to look for. The big problem for me and probably to get the design to work in a program is that it is like Pointers 'R Us where one added byte could change many dozens of pointers which aren't right next to each other.

Link to comment
Share on other sites

It isn't really difficult to understand once you know where and what to look for. The big problem for me and probably to get the design to work in a program is that it is like Pointers 'R Us where one added byte could change many dozens of pointers which aren't right next to each other.

so lemme get this straight:

-you have an array of 8 bytes, 1 for offense and 1 for defense.

-depeding on plays picked by both teams, you get 2 indexes into "plays" pointer table

-the "play" struct has pointers to "behaviors" for each player (on O and D respectively).

so:

1. by changing a "behavior," you'd need to change all pointers in every "play" struct that reference that behavior. you'd also need to update pointers to all the "behaviors" that follow the edited one.

2. by changing a "play" you'd need to change the address (and update all "plays" that follow) in the pointer table that the 8 byte grid indexes to.

is this close to how it works?

Link to comment
Share on other sites

That is close however the behaviors even have pointers. So you will have to update every following play struct and following pointers in the behavior.

Here is an example with something easy:

Play: R AND S SWEEP L

Slot: Run 1

Formation: 0C

Play #: 14, 14, 52, 52, 14, 14, 51, 51

Defense: 63, 62, 62, 61, 60, 60, 61, 61

The formation has a set of 22 bytes (11 pointers) for the offensive alignment. The offense has 3 structs for this play (14, 51, 52) with each having 22 bytes (11 pointers) for each player. The defense has 4 structs against this play (60, 61, 62, 63) with each having 22 bytes (11 pointers) for each player.

The offensive formation pointers are in x4010, the offensive structs are in x4410, and the defensive structs are in x6010. Offense pointers go to section x8010 and Defense pointers go to section xA010.

Offense #14 has pointers of A6CD, A6D8, BE3C, B781, A714, A720, A67E, A683, A689, A726, BE36.

WR1's behavior (B781) is F7 10 FF 54 BE. This means Boost HP by 10 then his behavior continues at BE54. At BE54 is FC FF E0 37 FE FC. This means Set to Grapple players FFE0 (this is set bitwise and is equal to every defensive player), go block the RCB, and then go back 4 bytes (to the Set to Grapple command thus looping him forever to block the RCB).

---

The behavior pointers are listed under goto pointers (xFF), jump forward or backward bytes (xFE), Random goto pointers (x20 to x2F), A pointer for change of possession during a pass (part of x91 to x94), CPU goto pointers (xC7), and Random CPU goto pointers (xC8).

Link to comment
Share on other sites

WR1's behavior (B781) is F7 10 FF 54 BE. This means Boost HP by 10 then his behavior continues at BE54. At BE54 is FC FF E0 37 FE FC. This means Set to Grapple players FFE0 (this is set bitwise and is equal to every defensive player), go block the RCB, and then go back 4 bytes (to the Set to Grapple command thus looping him forever to block the RCB).

i think i got it, so wr1s script could be re-written as:

F7 10 FC FF E0 37 FE FC

with the jump (FF 54BE) taken out (assuming addresses are updated...)? whats the significance of setting grapple(all) if blockRCB() is issued afterwards?

also im i correct that commands

D0 = positionPlayerRelative(signed Y, unsigned X)

D1 = positionPlayerAbsolute(unsigned Y, unsigned X)

for the QBs formation data (R AND S SWEEP L: D0 F0 12 EE D0 0C 40)?

also i've seen alot of $EAs, $ECs, and some $EEs, what do these do?

after looking at some of this i can already see the pointer madness. :twisted:

Link to comment
Share on other sites

Here is the guide I made for my reference (TSB II and III have a few more commands not listed). It doesn't show anything extra though about the commands.

Location = Y, X

Pointer = Lo, Hi

0x01 = m2m HB (Time)

0x02 = m2m FB (Time)

0x03 = m2m WR1 (Time)

0x04 = m2m WR2 (Time)

0x05 = m2m TE (Time)

0x11 = m2m HB (Time)

0x12 = m2m FB (Time)

0x13 = m2m WR1 (Time)

0x14 = m2m WR2 (Time)

0x15 = m2m TE (Time)

0x20 to 0x2F = Random Number (Pointer) ***Note x20 is likely to x2F isn't likely

0x30 = Block RE

0x31 = Block NT

0x32 = Block LE

0x33 = Block ROLB

0x34 = Block RILB

0x35 = Block LILB

0x36 = Block LOLB

0x37 = Block RCB

0x38 = Block LCB

0x39 = Block FS

0x3A = Block SS

0x40 = Chop Block RE

0x41 = Chop Block NT

0x42 = Chop Block LE

0x43 = Chop Block ROLB

0x44 = Chop Block RILB

0x45 = Chop Block LILB

0x46 = Chop Block LOLB

0x47 = Chop Block RCB

0x48 = Chop Block LCB

0x49 = Chop Block FS

0x4A = Chop Block SS

0x50 = Handoff QB

0x51 = Handoff HB

0x52 = Handoff FB

0x53 = Handoff WR1

0x54 = Handoff WR2

0x55 = Handoff TE

0x56 = Handoff OC

0x57 = Handoff LG

0x58 = Handoff RG

0x59 = Handoff LT

0x5A = Handoff RT

0x60 = Fake Handoff QB

0x61 = Fake Handoff HB

0x62 = Fake Handoff FB

0x63 = Fake Handoff WR1

0x64 = Fake Handoff WR2

0x65 = Fake Handoff TE

0x66 = Fake Handoff OC

0x67 = Fake Handoff LG

0x68 = Fake Handoff RG

0x69 = Fake Handoff LT

0x6A = Fake Handoff RT

0x70 = Pitch QB

0x71 = Pitch HB

0x72 = Pitch FB

0x73 = Pitch WR1

0x74 = Pitch WR2

0x75 = Pitch TE

0x76 = Pitch OC

0x77 = Pitch LG

0x78 = Pitch RG

0x79 = Pitch LT

0x7A = Pitch RT

0x80 = Motion Following QB

0x81 = Motion Following HB

0x82 = Motion Following FB

0x83 = Motion Following WR1

0x84 = Motion Following WR2

0x85 = Motion Following TE

0x86 = Motion Following OC

0x87 = Motion Following LG

0x88 = Motion Following RG

0x89 = Motion Following LT

0x8A = Motion Following RT

0x91 = Pass (#1, #2) (Pointer) ***Note Receivers are first nibble player (0 = QB to 5 = TE) and second nibble is chance of being thrown to (0 = not likely to F = likely)

0x92 = Pass (#1, #2, #3) (Pointer) ***Note Receivers are first nibble player (0 = QB to 5 = TE) and second nibble is chance of being thrown to (0 = not likely to F = likely)

0x93 = Pass (#1, #2, #3, #4) (Pointer) ***Note Receivers are first nibble player (0 = QB to 5 = TE) and second nibble is chance of being thrown to (0 = not likely to F = likely)

0x94 = Pass (#1, #2, #3, #4, #5) (Pointer) ***Note Receivers are first nibble player (0 = QB to 5 = TE) and second nibble is chance of being thrown to (0 = not likely to F = likely)

0xA0 = Route #1

0xA1 = Route #2

0xA2 = Route #3

0xA3 = Route #4

0xA4 = Route #5

0xB0 = Set Position From Kickoff (Location)

0xB1 = Set Position From Kickoff (Location)

0xB2 = Set Position From Kickoff (Location)

0xB4 = Move-Absolute (Location)

0xB5 = Move-Absolute (Location)

0xC0 = Dropback (Location)

0xC1 = Computer Pass Timing (Start Time, End Time, Take Sack Chance)

0xC4 = Celebrate (Unknown)

0xC5 = Cry (Unknown)

0xC7 = Computer Jump To (Pointer)

0xC8 = Computer Random Jump To (Pointer) (Random) ***Note Random x00 is likely to x0F isn't likely

0xCC = Pass Block

0xCD = Move-Relative (Location)

0xCE = Move-Absolute (Location)

0xCF = Move-Absolute (Location)

0xD0 = Set Position From Hike (Location)

0xD1 = Set Position From Middle (Location)

0xD2 = Hike under Center

0xD3 = Hike from Shotgun

0xD4 = Take Snap under Center

0xD5 = Take Snap from Shotgun

0xD6 = Take Snap for Field Goal/Extra Point

0xD7 = Move-Relative (Location)

0xD8 = Move-Absolute (Location)

0xD9 = Move-Absolute (Location)

0xDA = Pass Rush

0xDB = Vertical Mirror Ball Carrier

0xDD = Adjusting Pass Rush

0xDF = Computer Takes Control

0xE0 = Boost RS (Boost)

0xE1 = Boost MS (Boost)

0xE2 = Boost RP (Boost)

0xE3 = Boost MS (Boost)

0xE4 = Player Takes Control

0xE5 = Kickoff

0xE6 = Punt

0xE7 = Field Goal

0xE8 = Extra Point

0xEA = 3-Point Stance

0xEB = Shift (Time)

0xEC = 2-Point Stance

0xED = Motion (Time)

0xEE = QB Stance

0xEF = Change Player Icon to Returner

0xF0 = Face Direction (Direction)

0xF3 = Pause (Time)

0xF4 = Pause (Time)

0xF5 = Pause (Time) ***Note Time is 2 bytes

0xF7 = Boost HP (Boost)

0xFA = Recover Ball

0xFC = Set To Grapple (Players) ***Note players are selected in bits

0xFD = Set To Pass Block (Players) ***Note players are selected in bits

0xFE = Go Backward or Go Forward (# of Bytes) ***Note # of Bytes are from Signed numbers

0xFF = Jump To (Pointer)

Link to comment
Share on other sites

F7 10 FC FF E0 37 FE FC

with the jump (FF 54BE) taken out (assuming addresses are updated...)? whats the significance of setting grapple(all) if blockRCB() is issued afterwards?

The first time it sets grapple to all makes sure the player isn't able to run through a defender during his path to the RCB. The block RCB makes him chase down the RCB. Without the grapple he would get to the RCB and then just stand on top of him doing nothing. However the behavior would work the same just jumping back to the Block RCB each time.

also im i correct that commands

D0 = positionPlayerRelative(signed Y, unsigned X)

D1 = positionPlayerAbsolute(unsigned Y, unsigned X)

That is close but it really isn't signed and unsigned since F0 is the center of Y in the D0 command and 78 is the center of Y in the D1 command. And the D0 command is adjusted by where the ball is placed. I'll also note the difference of each x08 for X is a yard.

for the QBs formation data (R AND S SWEEP L: D0 F0 12 EE D0 0C 40)?

A little too far. The QB formation data is only D0 F0 12 EE

also i've seen alot of $EAs, $ECs, and some $EEs, what do these do?

The guide I just posted will have that.

Link to comment
Share on other sites

so i started thinking about how to manage all the pointers and realized its probably more of a pain then its worth. i think i'm gonna make the tool assemble a base *.asm file over the selected rom. that way all pointers are updated any time changes are made. i did this for some data in the 32rom and it worked nicely.

so along those lines i started building a dissassembly for banks 1 and 2 (0x04010 - 0x0C00F) and replacing addresses with labels. probably gonna use #defines for commands. so you get:


.dw off_qb_PosUnderCenter, off_hb_PosSingleback, off_fb_PosWingTE
.dw off_wr1_PosSplitEnd, off_wr2_PosFlanker, off_te_PosRightSide
.dw off_c_PosCenterSnap, off_lg_Pos, off_rg_Pos, off_lt_Pos, off_rt_Pos

...
...
...

off_qb_PosUnderCenter: .db setPositionFromHike, $F0, $12, stanceQB

if the tool doesn't end up editing the base file, you'd still be able to do it by hand and leave the pointers to the assembler. i thinks its safe to assume that those that can edit plays will be able to make sense of it.

Link to comment
Share on other sites

Hmm, that sounds interesting and would handle the pointers. After looking at this I know I could do something like this using CA65 but have one problem.

From my example:

.define BlockRCB $37
.define BoostHP $F7
.define SetGrapple $FC
.define JumpTo $FF

.segment "TEST"

.WORD WR1_Boost_RCB

WR1_Boost_RCB: .BYTE BoostHP, $10, JumpTo, Block_RCB
Block_RCB: .BYTE SetGrapple, %11111111, %11100000, BlockRCB, $FE, $FC

The above works but I don't know how to get the FE FC command to automatically calculate the go back to Block_RCB. Any ideas?

Link to comment
Share on other sites

i've never used ca65 but lookin at the user guide, somethin like this might work (* is the current PC variable).

label:	.db SetGrapple, $FF, $E0, BlockRCB, $FE, label - *

by the way, does ca65 support rom patching?

i've reconstucted the offensive formations/behaviors (0x04010 ~ 0x04300 and 0x08100 ~0x08300). eventually all this should be put together towards a full disassembly. i know i've got quite a bit of prg 8, 11, 12, 15 commented and some other data banks have been recontructed. still a ways to go though.

edit: you might need to cast (label - *) to a byte, not sure

Link to comment
Share on other sites

Thanks, I just tested and this is what worked correctly:

.define BlockRCB $37
.define BoostHP $F7
.define SetGrapple $FC
.define LoopTo $FE
.define JumpTo $FF

.segment "TEST"

.WORD WR1_Boost_RCB

WR1_Boost_RCB: .BYTE BoostHP, $10, JumpTo, Block_RCB
Block_RCB: .BYTE SetGrapple, %11111111, %11100000, BlockRCB, LoopTo, Block_RCB + 1 - *

I'm not sure if it is able to patch onto a rom as I've never tried. My thinking was I would just make the segments come out correct and then paste into the rom.

I broke down all the rom into data and code but there are no labels or comments on anything so I'm sure you are further along than what I've done in the past.

Link to comment
Share on other sites


.org $A567
.db $F3, $14, $D8, $F0, $C0 ; [$A567] pause(14), moveAbsolute(F0, C0),
.db $D8, $F8, $E0, $D8, $04, $F0 ; moveAbsolute(F8, E0), moveAbsolute(04, F0),
.db $C8, $89, $A5, $09 ; cpuRandJumpTo(A589, 09),
.db $C8, $8D, $A5, $05 ; cpuRandJumpTo(A58D, 05),
.db $C8, $91, $A5, $02 ; cpuRandJumpTo(A591, 02),
.db $C7, $95, $A5 ; cpuJumpTo(A595),
.db $E4, $FF, $38, $B8 ; playerTakeCtrl(), jumpTo(B838)

the "cpu" commands are only exectued when the team is COM or COA?

i've also noticed there's some repeat commands like moveAbsoute ($D8 and $D9). are they the same command or similar commands?

Link to comment
Share on other sites

The CPU commands of xC7 and xC8 are only executed by a COM team and not a MAN or COA. The majority of these computer jumps go to random boosts of speed or strength or slight adjustments for the computer throwing the ball.

There are some similar commands that have very subtle differences so just let me know which ones you run into but I'll go through the list later and note them. But for xD8 and xD9 (similar to xD0 and xD1):

xD8 is based upon where the ball is snapped (top hash, middle, or bottom hash) where the ball is at xF0. xD9 is based upon the field where the middle is x78. Other than this difference the commands work exactly the same.

Link to comment
Share on other sites

Here are those same commands:

0x01 to 0x05 and 0x11 to 0x15 (no visible difference so likely is the same command).

0xB0, 0xB1, and 0xB2. Each one is a longer distance away from the kickoff. Obvious purpose is because 1 yard = x08 so at most you would have 30 yards of lineup for the return team without more.

xB4 and xB5. Same as logic as previously stated. Needed more distance to move to.

xCD, xCE, xCF and xD7, xD8, xD9. The commands work in the same way (xCD/xD7, xCE/xD8, and xCF/xD9) but after a Set Block (xFD) command xCD/xCE/xCF will break from the run path to block a player found along the way. xD7/xD8/xD9 won't go to block until the player has reached the end of the path.

xE1 and xE3. Slight but unclear difference however xE1 is only used on the kickoff return.

xF3, xF4, and xF5. xF3 and xF4 are the same but xF4 makes the player face towards the ball and xF3 faces the current direction. xF5 is (Start Time, End Time) and will pause until Start time then randomly leave anytime up to the End Time.

Link to comment
Share on other sites

so how do commands $2x(ptr) work as opposed to $C8(ptr, rand).

i came across a


.db $2B, $48, $BE

and im not sure what to make of it other then that

$BE48 == off_behav_blockLILB.

The $2x(ptr) works exactly the same as $C8(ptr, rand) other than $2x works for MAN, COA, and COM and $C8 works just for the COM. x = rand.

Here is an easy example of the $2x set.

B79C = 2B 48 BE, FC FF E0, FF 2E B8

BE48 = FC FF E0, 35, FE FC

B82E = F3 00, FE FE

B79C goes to a random 2B (B is our random value). If B is chosen (BE48) then the player sets to grapple everyone then blocks the LILB forever. If B isn't chosen (continues on to eventually B82E) then the player pauses forever.

Link to comment
Share on other sites

as i map out more of the behaviors, im running into the problem of ambiguity of label names...


off_wr1_BlockFS_0: .db $D9, $36, $48 ; [$A8FB] moveAbsolute(36, 48),
.db $FF, off_behav_blockFS ; jumpTo(BE60)


off_wr1_BlockFS_1: .db $D9, $36, $28 ; [$AD59] moveAbsolute(36, 28),
.db $FF, off_behav_blockFS ; jumpTo(BE60)

...both essentially do the same thing. personally i dont care if there's label_0 to label_n, but do you have any suggestions for better naming conventions?

with what's mapped out now, i've had some fun with formations and some behaviors it looks very promising.

Link to comment
Share on other sites

...both essentially do the same thing. personally i dont care if there's label_0 to label_n, but do you have any suggestions for better naming conventions?

I don't have any worthwhile suggestions on that. I would be doing the 0 to nth too. Maybe someone else has an idea for the labels.

Link to comment
Share on other sites

  • 4 weeks later...

now to get back to this

0x01 = m2m HB (Time)

0x02 = m2m FB (Time)

0x03 = m2m WR1 (Time)

0x04 = m2m WR2 (Time)

0x05 = m2m TE (Time)

0x01-0x05: probably same

0x11 = m2m HB (Time)

0x12 = m2m FB (Time)

0x13 = m2m WR1 (Time)

0x14 = m2m WR2 (Time)

0x15 = m2m TE (Time)

0x11-0x15: probably same

0x80 = Motion Following QB

0x81 = Motion Following HB

0x82 = Motion Following FB

0x83 = Motion Following WR1

0x84 = Motion Following WR2

0x85 = Motion Following TE

0x86 = Motion Following OC

0x87 = Motion Following LG

0x88 = Motion Following RG

0x89 = Motion Following LT

0x8A = Motion Following RT

what does "m2m" and "Motion Following ..." mean?

Link to comment
Share on other sites

now to get back to this

what does "m2m" and "Motion Following ..." mean?

m2m = Man To Man coverage

Motion Following is after the defender has lined up with this command then will move vertically on the screen until lined up directly across from the player marked. Thus is most helpful for the facing the offensive motion plays. The defender will line up on the screen and move with the player in motion stopping across where they do.

Link to comment
Share on other sites

  • 1 year later...
Play: R AND S SWEEP L

Slot: Run 1

Formation: 0C

Play #: 14, 14, 52, 52, 14, 14, 51, 51

Defense: 63, 62, 62, 61, 60, 60, 61, 61

The formation has a set of 22 bytes (11 pointers) for the offensive alignment. The offense has 3 structs for this play (14, 51, 52) with each having 22 bytes (11 pointers) for each player. The defense has 4 structs against this play (60, 61, 62, 63) with each having 22 bytes (11 pointers) for each player.

The offensive formation pointers are in x4010, the offensive structs are in x4410, and the defensive structs are in x6010. Offense pointers go to section x8010 and Defense pointers go to section xA010.

Offense #14 has pointers of A6CD, A6D8, BE3C, B781, A714, A720, A67E, A683, A689, A726, BE36.

How are the pointers for the offense structs determined? Starting at x4410, do they go in order as they are placed in the ROM? Ex: If the first run play, in the first run slot, has one struct, are there 11 pointers and then the second run play begins? If there are two structs, are there 22 pointers and then the next play begins? This doesn't seem to be the case in my experimentation.

Are the structs themselves positioned in a certain order?

***Edit: I think I figured it out. The pointers for each player, in each struct, are identified on the tabs in TSB Playmaker.

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.

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.

×
×
  • Create New...