Mapper 16 discovery -- maybe new information?

While implementing mapper 16 I was using Disch's mapper documents as a guide. I find these documents infinitely useful and enjoy his humor when it comes to some of the more ridiculous mappers. I was reading through mapper 16 and it struck me that I'd seen those patterns for accessing the EEPROM elsewhere in my life. This might be new information or it might have been discovered/discussed/closed already and Disch just never updated his mapper docs -- or I failed to download an update? Anyway...I think it's worth noting and perhaps even updating Disch's mapper 16 document.

The EEPROM protocol is Inter-Integrated Circuit (I2C). I've written quite a damn few I2C drivers for various things. The most common being I2C SEEPROMs. I2C SEEPROMs have a very recognizeable 9-beat bit pattern with the first nibble of the first byte after a START condition being 1010, followed by a 3-bit device address, followed by a 0 [write] or 1 [read] command bit. The ninth bit is the ACK bit, where the device receiving the data drives the bus to acknowledge receipt.

I've implemented the I2C protocol for the SEEPROM in mapper 16 using the following method. It works well with Dragon Ball Z Gaiden and I'm going to try it with others shortly.

Writes to the 800D register and reads from anywhere in 6000-7FFF cause the two-wire I2C bus to transition in the various patterns required to drive the I2C protocol.



I2C requires a START condition before any activities. A START is a negative edge on SDA while SCK is high. This is generated [again, observations from Dragon Ball Z Gaiden -- I'll update this post if I find different sequences elsewhere] by the following writes to 800D:



Clearly, SDA goes low while SCK is high.

Transfers consist of 8 data beats and an ACK beat. The 8 data beats are exactly as Disch describes. To send a '1' bit to the SEEPROM the following writes to 800D are done:



Data is set high before the postive edge of SCK which is when the data is clocked into the SEEPROM.

Similarly to write a '0' bit:



A 0-bit is clocked into the SEEPROM on the positive edge of SCK.

The ninth beat or the ACK beat is different depending on whether the master [the 2A03] is writing a byte to the SEEPROM or reading a byte from the SEEPROM. If it's writing, it performs a read to make sure the SEEPROM drives SDA low to acknowledge the byte transfer. If it's reading, the 2A03 either drives the bit low to indicate it'll be reading more, or drives it high to indicate it's done reading.

Transfers are completed with a STOP, which is a positive edge on SDA while SCK is high.



Clearly, SDA goes high while SCK is high.

Reads from the SEEPROM are done by generating a SCK positive edge then reading from 6000-7FFF. It is typical for the SDA/SCK lines to be pulled high in I2C so SDA is sent to 1. Typically SDA would be looked at directly for the SEEPROM to drive it to 0 or leave it at 1 but in this case the read-out bit goes to D4.



The I2C SEEPROM protocol is clearly described in many datasheets for SEEPROMs. One example I used while writing my mapper 16 EEPROM implementation is this one.

Hope this information helps someone. It certainly made implementing the thing feel a heck of a lot less hacky to me. I'm not ready to push it yet but mapper 16 support will be in the next NESICIDE release.

Could D7 be "drive SDA" vs "don't drive SDA" ? Relatedly, could the SDA line actually be full push-pull, and not just a pull-down?
I guess that's not consistent with the ACK bits, though.

Yeah, D7 being a data direction register (DDR) agrees with what is written in the wiki's article about the mapper.

Heh nice. I knew it'd probably already been worked over. Oh well.

I'm still looking for Disch's latest docs, I guess...mine says:

Perhaps someone stealth edited the Disch-quote section of the page.

<_< >_> Hi!

That page is driving me crazy with the exchanged use of EPROM and EEPROM.

When I wrote the first version of that page, I guess my opinion on whether EPROM necessarily meant UV EPROM might have not matched some other people's. Is EEPROM a subset of EPROM, with UV EPROM being the other subset, or does EPROM always refer to UV and there's some other term containing both EPROM and EEPROM?

The first E of EEPROM is "electrically"? Doesn't that answer it?

http://en.wikipedia.org/wiki/EEPROM

EPROM technically is the generic term, but it was used so long for UV EPROM (or OTP EPROM) that it still insinutates that.

Anyway, I edited the article to not tickle that neurosis

To further the neurosis I believe such I2C or SPI EEPROMS are also referred to as SEEPROM.

PROM = Programmable ROM -- Basically is a matrix of fuses, one fuse per bit. Programmable one time only.
EPROM = Erasable Programmable ROM -- Using a window on the back of the chip, you can feed UV light in order to erase the bits, so you can reprogram the rom.
EEPROM = Electronically Erasable Programmable ROM -- Now you can erase the bits by just interfacing with the chip, instead of needing UV light.

Electronics are weird, just look at kb, kB, kib, kiB, ...

And then there's the classic Kb, too.

Kibibyte is more fun than Kilobyte! Suck it, engineering prefixes!

As EEPROM is an evolution of EPROM, one can consider Flash one of many modernized implementations of EEPROM.