>>I've looked at the NAND command protocol, there's no way for the memory chip to tell the host to slow down except when actually erasing or programming a block.
>Not true - the r/b (Ready/Busy) line does just this.
No, the original comment is correct, there is no byte level flow control. Timing diagrams in the data sheet show that R/B# only goes low when the chip is reading from the memory array to it's internal cache, or during programing or erase. Individual reads/writes on the bus have no effect on the R/B#, you _do_ need to know how fast you can access the device.
(I moved this thread here from the "cartridge PCB" topic, cause it's more appropriate here.)
Hmm. It doesn't matter what existing NAND chips DO with R/B#, it matters what the juicebox boot firmware looks for.
(which is proprietary and can't be posted, but presumably people have single-stepped it?) With
a lot of luck, it could check R/B# before every read/write... (But if you're seeing 250-500ns writes,
it seems unlikely that all such writes got funneled through a common status-checking "write nand" function. Sigh.)
Assuming it doesn't, how much full-speed buffering would a hypothetical NAND emulator require? A full
"block" worth plus a couple commands, with busy only checked when the chip is told to write/get a block?
That would make the emulator rather difficult...
