tepples wrote:
I'd be willing to explore extending the A53 mapper with new register $2A exposing a flash memory control port. Then enabling or disabling /WE would look like this:
Code:
lda #$2A
sta $5555
lda #FLASH_WRITE_ENABLE
sta $AAAA
; program some data
lda #$2A
sta $5555
lda #FLASH_WRITE_PROTECT
sta $AAAA
These registers would still respond to $5000-$5FFF and $8000-$FFFF like any other A53 mapper feature, but use of $5555 or $AAAA thematically matches the rest of the flash unlock sequence and would be easy to catch with the debugger.
Not sure if I want to mark it as user ($2A) or supervisor ($AA) though. It depends on whether we want to built in a self-flash mechanism analogous to that of so-called UNROM 512.
So thinking about this more closely as I'm trying to implement it, there's a number of ambiguities with things getting complex quickly.
So for the $5555 register, is that the only specific address where bits 6-1 of the select register stick? Or can you write 0x2A to any address $5000-5FFF and it has same effect as writes to $5555?
Similarly, does the write to the 'flash enable register' have to occur at $AAAA, or can it be anywhere in $8000-FFFF? I'm assuming it must be $AAAA specifically.
If I understand your code correctly, some modifications would be needed:
Code:
lda #$2A
sta $5555 ;must be this specific address to write to FLASH portion (bits 6-1) of $5000-5FFF REG_SEL register.
;bits 7 & 0 of the write above still get written to $5000 REG_SEL register
lda #FLASH_WRITE_ENABLE (define this as 0x55 ?)
sta $AAAA
; now writes to flash are enabled
; writes to $8000-FFFF go to flash AND the mapper register (don't care CNROM mode)
; but writes to $AAAA go to the flash enable register AND flash, must deconflict this
lda #$00
sta $5555 ;deselect flash enable register, and put the mapper in CNROM mode so 32KB PRG-ROM bank is fixed.
; now writes to $8000-FFFF will go to flash, and mapper register.
; but mapper register only changes the CHR-RAM bank which we don't care about.
; program some data to flash, keep in mind this code can't execute from PRG-ROM
lda #$2A
sta $5555
lda #FLASH_WRITE_PROTECT (define this as any value besides 0x55?)
sta $AAAA
I do think there's value in simplification where possible so long as protection is adequate as there's been several mentions of interest from compo entries to utilize flash saves. But to be honest the complications here are quite significant and even I have a hard time wrapping my head around all this. It gets even further complicated by not really knowing what part number will be used for the game. 128-512KB, 1-2MB, and 4MB+ all have different address/command pairs, different expedited flash algorithms, and the board design may change in the future. 128-512KB flash doesn't even require flash write protection. The creator of a compo entry can't know any of those details in development. And even if they do, we may use a 512KB flash for that individual compo release, and a 8MB flash on a future multi-volume mass compilation. It's unlikely devs will be interested in updating their entry to support the new board config year(s) after the fact.
So I guess what I'm trying to say is for right now, the specifics of what we implement for this flash shouldn't really matter for the future. I'm suggesting we don't even publish the solution we use here in the wiki. It's only real purpose is to allow me to manufacture this volume's cartridge.
In the end if we want to provide flash save option to future compo entries, I think it's best to abstract away the actual flash save algorithm completely. There are a few ways we could do this, which is probably a discussion for a different thread. But one idea would be to define mapper 28 CHR-RAM as battery backable. In practice though, the action53 menu rom could have helper functions present at $6000-7FFF which transfer CHR-RAM data to/from flash instead of actually placing a battery on board. Or maybe we just avoid all the hassle and drop a 32KByte battery backed SRAM on the board and give each entry 128-1024Bytes of save RAM. IDK what's best, but the complexities of entries writing directly to flash may never be reasonably within reach..