First of all I disassembled the 1.f3 firmware and located the routines that handle bitsetting. They are easy to find since they all need to access address $5086. That's the address where the booktype for +R9 is stored.
Then I copy the Bytes that represent this code and paste them in a free area of the 3.04 firmware. So I have some copied routines for bitsetting, but of course that's not all.
The next thing is to check the 3.04 firmware for some subroutines that are called in the bitsetting code. These routines start at different locations, depending on the firmware version and need to be adjusted in the copied code. Some of the other addresses need to be changed too since memory locations may also differ from time to time. (Although this sounds easy, it's a very time consuming task)
Now I have a working bitsetting code, but the firmware won't do bitsetting yet, so I have to change the original routines so they call the new routines. (Just add an unconditional jump at the beginning)
I can see that modifying some data structures (with media codes for example) can be relatively safe, but I'm not so sure about modifying the code.
Maybe you can imagine that it's a bit more complicated to implement bitsetting than to "just" change some media codes or increase writing speeds where support tools exist. Most of my work is done with Ultraedit - a text and hex editor. And I wrote a small tool to adjust some subroutine calls for 3520 firmware, since the target address needs some calculation and Byte moving...