Hi. Not sure how useful this post will be. Unfortunately, I'm not too familiar with the RoboCop game. However, it looks like a pretty neat project you have going on here, and I was interested in checking it out.
0x199F4-0x19A13 (0x20) - Palette for scene.
Original:
0F 32 26 16 0F 22 12 02 0F 0F 0F 0F 0F 0F 0F 0F
0F 22 12 02 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0FTest (to see how things are affected when attribute byte tests are also performed later):
0F 32 26 16 0F 22 12 02 0F 3A 2A 1A 0F 3B 2B 1B
0F 22 12 02 0F 27 17 07 0F 23 16 04 0F 37 2A 050x19E16-0x19F0F (0xFA) - Free space(?): "FF" bytes
0x19F10-0x1A00F (0x100) - Free space(?): "00" bytes
$B64D-$B66D = 0x1965D-0x1967D (0x21)
B64D:A2 00 LDX #$00 ; Beginning of sprites.
B64F:BD 54 BC LDA $BC54,X ; $BC54 = 0x19C64.
B652:9D 00 02 STA $0200,X ; Byte 0 = Y position.
B655:BD 55 BC LDA $BC55,X ; $BC55 = 0x19C65.
B658:9D 01 02 STA $0201,X ; Byte 1 = Tile ID.
B65B:A9 00 LDA #$00 ; Same attribute for all.
B65D:9D 02 02 STA $0202,X ; Byte 2 = Attribute.
B660:BD 57 BC LDA $BC57,X ; $BC57 = 0x19C67.
B663:9D 03 02 STA $0203,X ; Byte 3 = X position.B666:E8 INX ; Increment X 4
B667:E8 INX ; times to account
B668:E8 INX ; for next sprite.
B669:E8 INX ; Check if 15 sprites/
B66A:E0 3C CPX #$3C ; 60 bytes reached.
B66C:90 E1 BCC $B64F ; If not yet, go back.Disclaimer: Text dump is likely not 100% accurate nor included as part of a balanced breakfast.
Disregarding all of the above nonsense, to answer your question of why they made the code the way they did by using the same attribute byte for those animations of RoboCop... who knows? On one hand, you could argue that they were doing it to save space somehow, but really, what space did they save? By logging the data and code used, you can see that they had groups of 4 bytes for that sprite data starting at 0x19C64, but they weren't logged because the code doesn't load those data bytes. So, the bytes still exist and occupy space, but are essentially wasted instead, and they only saved
one byte by not using a "BD" LDA instruction/opcode there. Plus, it appears as though there is still free space at the end of that specific ROM bank that they
could have used if they needed to. So, what was the point? There was no point! There's no point to anything in life!
Was it to reduce/save time for the game to perform the code? How much time would it really save overall?
Nonetheless, assuming that the free space at the end of the bank is indeed unused (it wasn't logged by the Code/Data Logger), then you could potentially just insert a jump at the appropriate point in the code, and then jump back after your custom code of how it should have been all along!
As a test, I replaced "A9 00 9D 02 02" with "
20 C0 BF EA EA" at
0x1966B-0x1966F (0x5), and "00 00 00 00 00 00 00" with "
BD 56 BC 9D 02 02 60" at
0x19FD0-0x19FD6 (0x7).
B65B:20 C0 BF JSR $BFC0
B65E:EA NOP
B65F:EA NOPBFC0:BD 56 BC LDA $BC56,X
BFC3:9D 02 02 STA $0202,X
BFC6:60 RTSThe result was the following:
Since it appears that you're creating a custom scene, you would need to play around with the data bytes to fit your specific needs. In addition, it appears that there's additional code to load additional data for other parts of the scene - maybe? So, there might possibly be additional code that you'll also need to manipulate. However, again, there seems to be free space for you to work with, so hopefully, you'll be able to work it out.
With the above code to load individual attribute bytes, you'll have to modify the "00" of each sprite on your own to what you want/need it to be.
As for the additional time for the code to perform the jump and the return back, not only once but multiple times for all of RoboCop's sprites in that part of the scene, efficiency could be improved if you were able to shift everything forward at that point by one byte so that you could just fit in the "LDA $BC56,X" line where the original code already is; however, unless you have a disassembly to work with to make this a much easier and quicker process, it might not be worth your time and effort to manually shift everything through the hex editor, and have to account for manually adjusting branch lengths like the one at $B66C, as well as any JSR and JMP jump sources and destinations. Unless inefficient code causes you a headache, I would avoid the headache caused by all of the extra work for what really amounts to little reward or appreciation.
Sorry again if this post is inaccurate or incomplete (and as a result, unhelpful), and/or difficult to read through because it was verbose, like my code: "consuming much time".
Perhaps it can still be some sort of starting point towards a solution. We can only hope so, anyway.
In any case, I believe that, ultimately, you can do it in the end! Do it for RoboCop!
Best of luck with your project!
Topic: NES RoboCop with Arcade sprites (Read 42350 times)