Maximum sectors per track and extended track range (ETR)?

[OldWoman37]

Hello all.
I had a question regarding the maximum supported sectors per track. Although the documentation states FF can support up to 256 sectors per track, I don't know if this is actually possible given the amount of time needed to read/write the actual sectors. Each sector is made up of a number of bits and when you look at the transfer bit rates, there must be an upper limit to the number of sectors (bits) you can have in a single rotation.
I'm trying to add "more addressable space" to an existing system by allowing tracks to go up to 254, and increasing the number of sectors per track. Through emulation however I'm finding I'm maxing out the floppy controller (emulation takes this into account), and once a track is formatted for more sectors, the address marker bits can't be found with a read as I wrote too much data initially. So I'm thinking there has to be an upper limit to the number of sectors (bits) per track. Will changing the RPM (slower) allow me to store more information? I don't know how FF is coded, but I would assume each track is loaded into RAM so that the information can be immediately available; so there has to be some limit to how much can be stored per track.
In terms of tracks, my controller (PC8477B) supports extended track ranges (ETR) which should allow up to 4096 tracks. It stores the extra 4 bits into the HEAD field in the sector headers. Given the limitations I see with the maximum sectors per track, having more tracks would allow me to store more information. Does FF support ETR, and if not, would it be possible to do so in the future?
Thanks.

[keirf]

It is possible to have this many sectors, but the time per rotation will correspondingly decrease. So for example, 256 x 512-byte sectors would rotate at perhaps 15 rpm. This makes the random access latency of the disk worse, as you on average need to play out half a track to find a sector and here that would be about 2 seconds, compared with 100ms at 300rpm!

I don't support ETR but probably could if I can see an example or spec.

[OldWoman37]

Okay. I assumed you just cached a whole track in RAM and then sent it out as needed, but it sounds like there is more to it.
You can find info about ETR in the controller datasheet:
https://retrocmp.de/ctrl/testfdc/pc8477b.pdf
I don't think you would have to do much to accommodate for it other than decode the HEAD information in the header. It looks like most of the work is done by the controller itself.
I guess the only other consideration is having to deal with much larger image files as a consequence of this.
I also had one more quick question: doesn't the "sector" number in the encoded header start at 1? If so, if you have 256 sectors, what is sector 256 encoded as? a zero? or would this be controller dependant?
Thanks.

[keirf]

Sector numbers are actually arbitrary integers 0-255. It is convention to number sectors logically in consecutive order, and to start from either 0 or 1.

[OldWoman37]

Hello.
I was just curious if you had a chance to look at adding ETR support?
I managed to make the firmware changes I needed to my system and I tested it in emulation and everything seems to work well.
Thanks.