Jump to content

konForce

Members
  • Posts

    26
  • Joined

  • Last visited

Contact Methods

  • Website URL
    http://

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. In short it's an unfinished version (that I abandoned in favor of a GUI version) that lets you edit large helmets & their logos.
  2. I haven't had a chance to work on it since the holidays, so there is no update. However, if I can find the original non-GUI version one I'll post it.
  3. I understand how to make user defined plays, all the way down to the routes, etc. There is still some unknown information, but it's nothing that couldn't be figured out. The kicker is that embedded in the route information is the CPU logic. The CPU is not smart, it just does what the logic tells it to per route. In other words, if you create a play you also have to tell the CPU how to use the play. What happens in the play sequence is at the end, a "take control" byte command is issued. If you are a human then you can now control the player and the play sequence is halted. However, if you are a CPU, the play sequence continues according to the logic that immediately follows it. (The last beta of my editor did not even attempt to load CPU data and thus, when saving the playbook, all CPU logic is overwritten with garbage.) The logic for a QB might look like: 1) Drop back for pass. 2) If random number is A then pass to a player 3) If random number is B then move to a location (scramble) 4) While scrambling, if random number is C then pass to a player 5) Run with ball. I never had time to completely look into this, but to me it looked like the best way to create a usable playbook editor would be to actually create a program that lets you draw plays up, and then press a "compile" button that creates the NES byte code needed for TSB. In other words the program would not be able to extract information from the TSB ROM, it would only be able to export a playbook to it. The method my playbook "editor" uses would have only worked if things were a bit more structured in the TSB ROM.
  4. This is impossible (extremely impractical) to do natively, because of space limitations. While the limitations may appear odd, there is reasoning behind it. 63 is 6 bits. In order to get 64, you'd have to have 7 bits (which would give you 127 max). This would increase the space needed to store all the data. The NES only has a fixed amount of SRAM space, so Tecmo had to plan accordingly. The upcoming tecmo GFX editor will be available for MacOSX, but I know everything else (at emuware) is only for Windows.
  5. The update here should fix the problem: http://www.tecmobowl.org/forum/viewtopic.php?t=4417
  6. For background information, see: http://www.tecmobowl.org/forum/viewtopic.php?t=4307 TSB Playbook Editor Beta 3 is available. http://www.emuware.com/files/?tsbPBE-beta03.zip Updates since the second release: * BUGFIX: blitz byte (hopefully) saved correctly * Added more information to various command codes * Sequence data is reordered upon saving (*Nukes CPU AI*) * Added "Safe Save" option The purpose of this release is to correct a problem that was brought to my attention regarding the blitz byte not being saved properly. It should be resolved now, but you'll have to see for yourself if it works. Other than that, there is no additional useful functionality. The editor does load the squences more accurately than Beta 2, but this doesn't translate into any practical applications. If you want to use the editor to swap plays around, use the Safe Save option. It only saves the play slot information. Doing a Full Save will damage the ROM in that all offensive CPU AI will be corrupted. The discovery that TSB stores CPU play logic within the sequences threw a monkey wrench into the route I was taking. To make a useful play editor, a completely high level editor would be necessary - ie, one that would essentially "compile" the playbooks into the NES format. This editor does not do that, and will likely only remain a debugging tool. tsbPBE-beta03.zip
  7. I believe the problem is that when you copy a play slot, the source play's blitz byte ends up being the same as the destination play's blitz byte. So if you copy a play to the other 3 slots, they will all share the same blitz byte (the final copied play is correct, the original(s) are not). Most likely due to a copy by reference when I was expecting it to copy by value. Update: http://www.tecmobowl.org/forum/viewtopic.php?t=4417
  8. Regarding play book editor, there very well could be problems with the blitz byte. Regarding the helmet editor, there is no release yet, and probably won't be for a few weeks, as I can only work on it a little bit on weekends.
  9. You can change which one of the 128 CHR sprite pages (64 tiles each) is used per helmet logo, although unless you feel like butchering some other graphics in the game, it doesn't make any sense in going outside the original four or five pages allocated. Regarding the tiles that are used, those can be added, removed, and rearranged at will. If you look at the 'konForce' helmet, you'll see the alignment has been changed from what the original (Steelers) helmet used. The editor does not attempt to use any of the empty space at the end of the PRG bank (there's enough to be somewhat useful), so you are still limited to the same sum size (for all the teams put together). The release of it is delayed somewhat, as I'm converting it to use a 3rd party GUI lib to make it more extensible down the road.
  10. It's a high level editor, so no knowledge of how TSB stores the GFX is necessary. Although, it's helpful to understand the space limitations and how to make the best use of column aligned tiles (save PRG/code space) VS pixel aligned tiles (save CHR/tile space) The first release will allow you to edit the large helmets. The 1960 ROM, team selection screen. A modern Washington Redskins logo edited by hand. Notice the wasted (unused) tile space and unnecessary pixel aligned tiles (right two). Original Washington Redskins logo. A helmet edited by yours truly. Notice that there is only one underline graphic. As you can tell by the grid lines the left and right most underline piece on the helmet have been adjusted one pixel to the right/left. End result is saving three graphical tiles, but using four more bytes of code space. (Each new pixel adjust costs two bytes.) The helmet above back on the main screen. Stripes are in style... (Ie, selecting a different background for the helmets.) Debugging console. What happens is after you move tiles around and such, the editor sorts the list for optimal size and then re-writes the code. A few helmets (colts and chargers, I think) actually are stored more effeciently with my sorting method than whatever the original programmers used. This is just by chance though; it is possible to construct a weird assortment of tiles where the editor does not produce the smallest amounts of bytes, but you'd have to really try hard to do that.
  11. My availability will be next to none starting next week, so I doubt I'd be able to do much regarding new projects. I have to finish up a helmet editor that I set aside while looking at playbooks. From there, I'll probably be too busy to be of much assistance, although I'm sure I'll continue on a working playbook editor and could try to answer a few questions now and then.
  12. No. On offense the RS=start, RP=acceleration, MS=max is somewhat of a simplification but it's pretty accurate, at least when RS I have not ever looked at the defensive code, so I'm only guessing that they use command bytes to increase speed. It could just be done at a global level, but that hasn't been the Tecmo style. On offense the "E boosters" add speed to the player's normal setting. This is used on flea flickers so that the QBs get back in time, etc. Tecmo always sets the boost back to normal before handing the control back on regular plays. (However, when your QB throws an interception, he gets a boost that doesn't go away.)
  13. On defense, yes. Defensive players are not capped at MS like offensive players. Instead, they are given a boost (maybe via the E0/E1/E2/E3 boost command bytes, if defense works like offense) so that they can catch up to the offensive players. The boost is so great that the MS ends up not meaning much at all. Instead, the RP becomes the critical factor. The more RP a defender has, the faster he will reach his boosted MS. A defender of 44RS 100RP 0 MS will be better than a defender of 44RS 6RP 100MS. The short of it is, for a defender, the RP is the critical factor for top speed, because it allows him to reach it more quickly.
  14. I left out some important info above regarding the general method, I'll edit the post...
  15. I didn't look at that (it probably is the pointers to the location I found), but I'll give you another method... Use FCE Ultra's debugger / memory viewer. During a play, the address of the players are stored in memory. Bring up the memory viewer and scroll to the line 03ax. The eighth and ninth columns (0x3a8 and 0x3a9) contain the address for team 1, player one. Skip a row to go to the next player (0x3c8 and 0x3c9). You have to read the addresses from right to left. So if you see this: 03ax: 00 00 EA 87 00 7E 82 00 63 BF 00 C0 00 13 45 01 03bx: 13 22 4A 40 09 2C 47 00 00 00 00 20 00 1F 05 60 03cx: 06 00 3A AD 00 7E 82 01 65 BF 00 80 00 40 43 02 03dx: 1A 2A D1 61 09 00 81 00 00 00 00 1C 00 FF 04 A0 03ex: 00 00 D1 8D 00 7E 82 02 6D BF 00 78 00 11 53 04 03fx: 19 2C E0 5A 09 D5 81 00 00 00 00 20 00 DF 05 00 040x: 80 01 EA 87 01 66 81 03 7B BF 00 B8 00 D9 43 03 041x: 13 26 92 23 09 51 57 AA FF 7B 00 10 05 D7 B0 90 042x: 00 01 E3 9E 00 55 82 04 7D BF 00 68 00 70 53 05 The boldface bytes are the command sequence addresses. The top line is team 1, player 1 (0xBF63), the third line is team 1, player 2 (xBF65) and so forth. These addresses change as the player moves from task to task. The next step is to scroll the memory viewer to the address of the player you are interested it. Note that the ROM banks load in and out constantly, so you'll need to pause the ROM while doing this. An easy way is to set a write breakpoint on 0x3A9 (or the appropriate spot for the player) via the debugger. Any time the player's command changes, the emulator will pause and you can check it out. Once it pauses, check the values at 0x3A9 and 0x3A8. You'll need to set a Read breakpoint based on those bytes. In this case, we'd set a read breakpoint on 0xBF63. Now, we'll have to run it again until that breakpoint is triggered. The difficult thing here is that you need to recognize if it's a valid trigger. Due to the NES's limited memory, the same addresses are used a lot depending on the current bank that is loaded. For our purposes here, you know you have hit it right if it's doing a LDA-Y command. So, scroll to that location now via the memory viewer (0xBF63) and notice the byte sequence. Now, do a search with a hex editor on the ROM itself to find where it is actually located in the ROM. It should only find one instance. If you find multiple, just increase the number of bytes you are searching for. I did this for the INT code and found that the INT return man always runs the commands from 0xbfc5 in the ROM. (Interesting note: this is actually the exact spot in RAM--minus the 0x10 byte header--that the NES uses; this rarely happens...) These are the commands that it runs: e1 00 (set MS back to default) e2 03 (set something to default + 3) e3 ef (set something to something) e4 (user control) df & fe ? not sure how these even come into play I didn't test with e2 and e3 but considering e0 and e1 tweak running speeds, I bet e2 and e3 do something with attributes as well. If you want super sonic speed, try changing it to e1 ff. After a while the intercepting guy can run across the entire field in a second or two. So, if you are looking to make punt returners a bit faster, increase the number after e1 until you like it. Note that e0 increases RS (acceleration), so you could add that in before the e4 command and just move everything over two bytes since there is plenty of room afterwords. I would be interested in seeing exactly what the e2 and e3's do. (Note: the attribute adjustment table that I posted about makes it nice to test interceptions. Just set all 16 PC INT bytes to 0 and the QB's will throw picks everytime.)
×
×
  • Create New...