nesdev.com
http://forums.nesdev.com/

Possible optimization for UNROM code
http://forums.nesdev.com/viewtopic.php?f=2&t=15705
Page 1 of 1

Author:  DRW [ Sat Mar 25, 2017 5:34 pm ]
Post subject:  Possible optimization for UNROM code

In https://wiki.nesdev.com/w/index.php/Programming_UNROM there is the following code:

Code:
bankswitch_y:
  sty current_bank      ; save the current bank in RAM so the NMI handler can restore it
bankswitch_nosave:
  lda banktable, y      ; read a byte from the banktable
  sta banktable, y      ; and write it back, switching banks
  rts


In line 4, wouldn't TYA do the same (since the values in banktable equal their offset value), but be shorter?

Author:  lidnariq [ Sat Mar 25, 2017 5:47 pm ]
Post subject:  Re: Possible optimization for UNROM code

For mappers that are not UNROM, where there are bits in the mapper register that are not contiguous (for example, GNROM), there may be value in keeping a densely-packed version in memory, and using the look-up table to expand the bits at run-time, allowing for a smaller total look-up table.

This is irrelevant for UNROM, though.

Author:  tepples [ Sat Mar 25, 2017 6:50 pm ]
Post subject:  Re: Possible optimization for UNROM code

True, tya can be faster. But reading the bank table before writing lets you use a non-identity mapping. For example, you can watermark your ROM by shuffling banks within the ROM, not unlike source code shuffling.

In my most ambitious UNROM production (240p Test Suite), I've tended to switch banks by overwriting the operand of an immediate load instruction (LDA, LDX, or LDY), like this:
Code:
lda #<.BANK(some_label)
sta *-1


Or when the bank number is in a table (the BNROM version of Action 53 does this a lot):
Code:
  lda sb53_files,y
  sta ciSrc
  lda sb53_files+1,y
  sta ciSrc+1
  lda sb53_files+2,y
  sta sb53_files+2,y  ; switch bank

Author:  tokumaru [ Sat Mar 25, 2017 6:51 pm ]
Post subject:  Re: Possible optimization for UNROM code

Look at AxROM for example, where there's a gap between the PRG bank bits and the mirroring bit. You can get rid of that gap and use a 16-byte look-up table instead of using a 32-byte table if you do it like in the example code you posted.

Author:  Bregalad [ Sun Mar 26, 2017 1:28 am ]
Post subject:  Re: Possible optimization for UNROM code

DRW wrote:
In https://wiki.nesdev.com/w/index.php/Programming_UNROM there is the following code:

Code:
bankswitch_y:
  sty current_bank      ; save the current bank in RAM so the NMI handler can restore it
bankswitch_nosave:
  lda banktable, y      ; read a byte from the banktable
  sta banktable, y      ; and write it back, switching banks
  rts


In line 4, wouldn't TYA do the same (since the values in banktable equal their offset value), but be shorter?

Code examples on the wiki are consistently shitty and I wouldn't bother using it. You should really code your own bankswitch routine based on a case-by-case scenario.

Quote:
Look at AxROM for example, where there's a gap between the PRG bank bits and the mirroring bit. You can get rid of that gap and use a 16-byte look-up table instead of using a 32-byte table if you do it like in the example code you posted.

Which is probably why bus-conflicts elimination is often implemented on AxROM boards - with a 74HC02 chip on ANROM board and with a special mask ROM on some AOROM boards.

Author:  DRW [ Sun Mar 26, 2017 3:20 am ]
Post subject:  Re: Possible optimization for UNROM code

lidnariq wrote:
For mappers that are not UNROM

Yeah, but that page is specifically for programming UNROM, that's why I mentioned it.

Bregalad wrote:
Code examples on the wiki are consistently shitty and I wouldn't bother using it. You should really code your own bankswitch routine based on a case-by-case scenario.

Yeah, I mentioned it as a possible code improvement for the wiki.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/