I've successfully modified drivers.s in order to read flash manf/device ID's from PRG flash and CHR flash on NROM flash cart.
Some things should probably be moved around to a more appropriate location as my understanding is only mapper specific code belongs in the driver. I'm proposing a new file flash.s which would provide code in the prg-rom that doesn't get copied to RAM with the driver. With that setup the only code in the drivers would be prg flash sensing which is the only code that NEEDS to run from RAM.
I've pretty well settled on my hardware design for flashable discrete mapper boards. I discussed it over
here which turned out to be pretty accurate. I've confirmed that there is indeed not enough address setup time before PRG R/W goes low. Driving /CE with ~M2 works great for my NROM board, I'll try BNROM next, but all signs point to success with this method.
PRG flash ROM
/OE -> PRG /CE
/CE -> ~M2
/WE -> PRG R/W
Here is code where I read the manf & device ID from a NROM, which has been tested and working on hardware. Reading CHR flash ID's works too, but isn't as interesting...
Code:
;WR $5555, 0xAA unlock cycle #1
lda #$AA
sta $5555
;WR $2AAA, 0x55 unlock cycle #2
lda #$55
sta $2AAA
;WR $5555, 0x90 software ID entry command
lda #$90
sta $5555
;RD $0000, Manf ID to get /OE low, read from $8000
ldx $8000 ;Manf ID = 0xBF for SST
ldy $8001 ;Device ID = 0xB5,B6,B7 for SST39SF010A, 020A, 040 respectively
;WR $xxxx, 0xF0 software ID exit command.
lda #$F0 ;exitID flash won't work as ROM again until this command is given.
sta $5000 ;write to flash anywhere ($0000-$7FFF)
I'm sticking with my idea (or at least would like to support) to use NOR gates on a UNROM board which gives a free inverter. Only difference there is that PRG A14 gets inverted in that case. Which moves $5555->$1555, and $2AAA->6AAA. So $1555 conflicts with RAM mirrored down to $0555. That's pretty much smack dab in the middle of RAM. Shouldn't be too much of an issue so long as the driver isn't there, I'm guessing it is though... Chances are as long as I clean up after myself and temporarily store the value (code) in $0555 and then restore it I'll be safe. If those few (~8) instructions happen to land in the same exact spot you'd stomp over yourself though. What's the best way to avoid that with the driver code?
As an aside, any idea what happens when you write to $2002 PPUSTATUS? Guessing/hoping nothing, or at most resets the latch just like a read does. It'd be a bummer if it didn't decode the difference between R/W and caused a bus conflict when writting to $2002 and it's mirrors.