nesdev.org

Posted: **Tue Oct 06, 2015 1:15 pm**

I worked off this datasheet writing the superfamicom wiki page: http://www.datasheetcatalog.com/datashe ... T-70.shtml
It's the "generic" equivalent of the Nintendo part, unfortunately lacking the 38 D0 command but it becomes apparent that these work with "page buffers". Basically you copy the "vendor info" block into the currently selected (cmd 0x72) page buffer, then write to the page buffer using cmd 0x74. However I haven't found a way to write the page buffer back to the vendor info block.

Posted: **Wed Oct 07, 2015 7:45 am**

Some random information I came across while googling:

- the official Nintendo Game Boy Dev/Prototype Carts also had Sharp flash memory(Datasheet, Useless but nice to look at decap)

Source: http://atariage.com/forums/topic/170272 ... boy-proto/

- Here is the source code for some homebrew GB Flashcart writer that supports them, just search for "LH28F800SU" and "LH28F032": http://www.reinerziegler.de/download/Readpnew.c and http://www.reinerziegler.de/download/re ... 27.tar.bz2
For example some interesting parts:

Code: Select all

/* Sequential load to page buffer */
    ADDRESS_LOW(0x00);
    ADDRESS_HIGH(0x40);
    WRITE_NFLASH(0xe0);
    ADDRESS_LOW(0x00);
    ADDRESS_HIGH(0x40);
    WRITE_NFLASH(0xff);
    ADDRESS_LOW(0x00);
    ADDRESS_HIGH(0x40);
    WRITE_NFLASH(0x00);

Code: Select all

/* Write page buffer to flash */
      ADDRESS_LOW(0x00);
      ADDRESS_HIGH(0x40);
      WRITE_NFLASH(0x0c);
      ADDRESS_LOW(0x00);
      ADDRESS_HIGH(0x40);
      WRITE_NFLASH(0xff);

Code: Select all

/* write data in Nintendo flash cart */
void WRITE_NFLASH(val)
{
  WRITE((BYTE) val);
  LOAD(DATA_REG);
  WRITE(0x00);
  OUTPORT(CTRL, SET_DATA);
  WRITE(0x01);
  WRITE(0x00);
  OUTPORT(CTRL, NOP);
}

There is also a Gameboy Dev cart in the code with Intel DA28F320 chips (datasheet) that uses 0xe8 to write to the buffer and 0xd0 to write the buffer to the flash.

- In the LH28F800SU datasheet it states "Refer to the LH28F800SU User’s Manual", so there seems to be a second document that actually explains how things work.

Posted: **Thu Oct 08, 2015 8:25 am**

Good findings. The source code's byte_count value (FF,00) for 256 byte writes does somewhat confirm that Sharp's byte_count is meant to be "number of bytes minus 1".

And here are the two photos compared, FLASH chips in Gameboy dev cart vs Satellaview FLASH cart,

even without legible text on the second photo, the chip layout's are looking identical, so it' should be about 99% sure that the satellaview carts have used whatever Sharp chips (for knowing the exact part number, one would need a screwdriver & one of those carts).

Posted: **Thu Oct 08, 2015 8:45 am**

I have a couple memory packs lying around, maybe I can take some pics later.

Posted: **Thu Oct 08, 2015 10:00 am**

That would be great.

More random google finds:
- after sending the 128bytes to the MX29F1610 you are supposed to wait 100us according to this application note http://www.prom-electric.ru/data/upload ... 10-app.pdf
- on page 31 of this MX29GL128 datasheet there is an example on how macronix handles writes to the page buffer, maybe they used similar commands for the Nintendo Power cart's flash? http://www.zlgmcu.com/mxic/pdf/NOR_Flas ... _DS_EN.pdf

Posted: **Thu Oct 08, 2015 12:21 pm**

Well, whaddayaknow.
This thing responds to a lot more commands that given in the datasheet so there seems to be undocumented stuff, maybe information about that is given in the "User's Manual" which seems to be unavailable.
Then again, -Z1 is a strange speed rating... judging from the LH28F004SUT-Z1 datasheet it just seems to mean 100ns though.

Posted: **Thu Oct 08, 2015 1:33 pm**

Nice, the LH28F004SUT-Z1 datasheet even has some flow charts that are missing from the LH28F800's datasheet.

Posted: **Thu Oct 08, 2015 2:12 pm**

sanni wrote:after sending the 128bytes to the MX29F1610 you are supposed to wait 100us according to this application note...

Yes, that's mentioned in the regular MX29F1610 datasheet, too. It's starting writing if you don't send further bytes for min 30us .. max 100us (the tolerance is probably due to not having precision oscillators in the chip).
However, the nintendo-specific chips are starting writing when writing the last byte twice, so you don't need the 30-100us delay (as a side effect, nintendo's macronix chips are a bit faster (and less timing-critical) than normal macronix chips).

sanni wrote:on page 31 of this MX29GL128 datasheet there is an example on how macronix handles writes to the page buffer

I thought the normal macronix chips were internally having a 128-byte page buffer for the normal page/byte write command, too. But this datasheet does actually seem to come up with extra page buffer commands. The datasheet is much newer, and it's using normal macronix-style addresses (ie. the 555 stuff) instead of the sharp-style addresses used in nintendo power carts, so no idea if any of the extra commands in that newer datasheet are working on older nintendo power carts...
Interestingly, the MX29GL128 datasheet is mentioning a 128-word extra sector for "security", so the concept of adding a hidden sector doesn't seem to be restricted solely to customized nintendo chips.

ikari_01 wrote:I have a couple memory packs lying around, maybe I can take some pics later.
Well, whaddayaknow.

Cool, thanks for the photo! The BSMC-AF-01 PCB's text layer is a little different as on the d4s photo. And the FLASH is a Sharp LH28F800SUT-ZI or LH28F800SUT-Z1. The suffix looks more like -ZI to me (though the "1" in the datecode might be just using a different font). But -Z1 would also make sense in relation to the LH28F004SUT-Z1 datasheet (which is for a smaller 4Mbit chip, not the 8Mbit chip in nintendo power carts, and not containing info about the hidden sector).

ikari_01 wrote:This thing responds to a lot more commands that given in the datasheet so there seems to be undocumented stuff, maybe information about that is given in the "User's Manual" which seems to be unavailable.

There are even a lot more commands? I knew only about the 38,D0 one, and the 08,07 one that you've mentioned on the wiki page (btw. does that command write the whole 256 bytes to some flash address, or could 07 be the byte-count, so it would only write 7 or 7+1 bytes?)

Before you try to overwrite the hidden sector, could you dump it? Using the same procedure as in the satellaview bios, but reading the whole 256 bytes instead of the just the handful of bytes used by the bios - would be interesting if there's more data stored in there (and if it's a Type 1 or Type 3 or Type 4 chip).

Posted: **Fri Oct 09, 2015 1:34 pm**

Here's the mapping details for my latest batch of NP carts:

Code: Select all

Fire Emblem Seisen no Keifu (No Menu):
C0FF00      5D 11 61 31 A5 97 00 12 
C0FF08      FF 11 FF 19 FF 18 FF 19 
C0FF10..7E  FF-filled
C0FF7F      00
C0FF80..FF  FF-filled  
E0FF00..8F  FF-filled
E0FF90      FF FF 55 00 FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFA0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFB0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFC0..FF  FF-filled

Heisei Shin Onigashima Zenpen (with menu)
C0FF00      03 11 AA 92 AA 97 00 11 
C0FF08      54 07 61 12 A5 30 10 37 
C0FF10..FF  FF-filled
E0FF00..8F  FF-filled
E0FF90      FF FF 55 00 FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFA0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFB0..FF  FF-filled
   
Heisei Shin Onigashima Kouhen (with menu)
C0FF00      03 11 AA 54 AA 97 00 11 
C0FF08      54 13 61 16 A5 01 10 41 
C0FF10..FF  FF-filled
E0FF00..7F  FF-filled
E0FF80      AA 00 41 00 FF FF FF FF FF FF AA 00 40 00 AA 00 
E0FF90      FF FF 55 00 FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFA0      FF FF 55 00 FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFB0..FF  FF-filled
  
Derby Stallion 98 (with menu):
C0FF00      03 11 AA 83 AA 97 00 11 
C0FF08      16 14 29 16 4A 11 10 24 
C0FF10..FF  FF-filled
E0FF00..8F  FF-filled
E0FF90      FF FF 55 00 FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFA0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFB0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFC0..FF  FF-filled

Derby Stallion 98 + Caravan Shooting Collection (with menu):
C0FF00      03 11 AA 82 AA 97 00 11 
C0FF08      16 11 29 11 4A 49 10 19 
C0FF10      43 FF AA FF AA FF 70 FF 
C0FF18..FF  FF-filled
E0FF00..8F  FF-filled
E0FF90      FF FF 55 00 FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFA0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFB0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFC0..FF  FF-filled

Bokujou Monogatari (Rev 1.1) + Pro Mahjong Kiwame 3 (with menu):
C0FF00      03 11 AA 35 AA 97 00 10 
C0FF08      0D 16 29 10 4A 43 10 45 
C0FF10      05 FF 29 FF 4A FF 54 FF 
C0FF18..FF  FF-filled
E0FF00..7F  FF-filled
E0FF80      AA 00 44 00 FF FF FF FF FF FF AA 00 43 00 AA 00 
E0FF90      FF FF 55 00 FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFA0      FF FF 55 00 FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFB0      FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFC0      55 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFD0..FF  FF-filled

Mini Yonku Let's & Go WGP2 + Dokapon 3-2-1 (Rev 1.1) (with menu):
C0FF00      03 11 AA B8 AA 98 00 01 
C0FF08      4D 20 61 10 A5 44 10 22 
C0FF10      09 FF 29 FF 4A FF 54 FF 
C0FF18..FF  FF-filled
E0FF00..8F  FF-filled
E0FF90      FF FF 55 00 FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFA0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFB0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFC0..FF  FF-filled  

Picross NP Vol. 1 (Rev 1.1) + Wrecking Crew 98 (with menu):
C0FF00      03 11 AA 25 AA 97 00 12
C0FF08      44 24 61 08 A5 35 10 38 
C0FF10      4D FF 61 FF A5 FF 31 FF 
C0FF18..FF  FF-filled
E0FF00..8F  FF-filled
E0FF90      FF FF 55 00 FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFA0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFB0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFC0..FF  FF-filled  

Super Jinsei Game 3 (Rev 1.1) + Dokapon 3-2-1 (Rev 1.1) (with menu):
C0FF00      03 11 AA 31 AA 97 00 11 
C0FF08      0D 14 29 08 4A 29 10 34 
C0FF10      09 FF 29 FF 4A FF 54 FF 
C0FF18..7E  FF-filled
C0FF7F      00    
C0FF80..FF  FF-filled 
E0FF00..8F  FF-filled 
E0FF90      FF FF 55 00 FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFA0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFB0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFC0..FF  FF-filled

Torneko no Daibouken + Super Family Tennis (with menu):
C0FF00      03 11 AA 82 AA 97 00 11 
C0FF08      09 18 29 11 4A 24 10 10 
C0FF10      07 FF AA FF AA FF 44 FF 
C0FF18..FF  FF-filled 
E0FF00..8F  FF-filled
E0FF90      FF FF 55 00 FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFA0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFB0      FF FF FF FF FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFC0..FF  FF-filled

Dokapon 3-2-1 (Rev 1.1) + Dokapon Gaiden + Kessen Dokapon 4 (with menu)
C0FF00      03 11 AA 23 AA 97 00 09 
C0FF08      09 26 29 08 4A 20 10 53 
C0FF10      07 FF AA FF AA FF 44 FF 
C0FF18      05 FF 29 FF 4A FF 64 FF 
C0FF20..FF  FF-filled        
E0FF00..7F  FF-filled
E0FF80      AA 00 43 00 FF FF FF FF FF FF AA 00 42 00 AA 00 
E0FF90      FF FF 55 00 FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFA0      FF FF 55 00 FF FF 55 00 FF FF FF FF FF FF FF FF 
E0FFB0      FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFC0      55 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
E0FFD0..FF  FF-filled

Posted: **Tue Oct 20, 2015 3:33 pm**

So I finally ran thru all the 4-byte sequences looking for changes in the hidden mapping area of the flash chip. After a week of searching sequences, I found that the chip only responds to the sequence of 0x38, 0xD0, 0x71 when it comes to the hidden area. I ran all 2, 3, 4 byte sequences then also added the 0x38, 0xD0 and 0x38, 0xD0, 0x71 before the 2-byte and 3-byte sequences. I quit looking after that and there's no way that I'm running another 4-byte (or greater) search. Either my search code is wrong or there's something else that needs to be done to change the mapping.

I decided to search the port commands. I ran all the commands to 0x2400 and found something interesting:
CMD:20: 2A 0 2A 2A FE 61 A5 0
CMD:21: 2A 8 2A 2A FE 61 A5 0
..
CMD:40: 2A 8 2A 2A FE 61 A5 0
CMD:41: 2A 8 2A 2A FE 61 A5 0
CMD:42: 2A 8 2A 2A FE 61 A5 0
CMD:43: 2A 8 2A 2A FE 61 A5 0
CMD:44: 2A 8 2A 2A FE 61 A5 0
CMD:45: 2A 8 2A 2A FE 61 A5 0
CMD:46: 2A 8 2A 2A FE 61 A5 0
CMD:47: 2A 8 2A 2A FE 61 A5 0
CMD:48: 2A 8 2A 2A FE 61 A5 0
CMD:49: 2A 8 2A 2A FE 61 A5 0
CMD:4A: 2A 8 2A 2A FE 61 A5 0
CMD:4B: 2A 8 2A 2A FE 61 A5 0
CMD:4C: 2A 8 2A 2A FE 61 A5 0
CMD:4D: 2A 8 2A 2A FE 61 A5 0
CMD:4E: 2A 8 2A 2A FE 61 A5 0
CMD:4F: 2A 8 2A 2A FE 61 A5 0

These commands show that bit 3 for Port 0x2401 is toggled. This appears to be something new. CMD 0x20 turns off bit 3, CMD 0x21 turns on bit 3. You can even use CMD 0x21 with CMD 0x02 and the resulting Port 2401 output will be 0x0C. The 0x40-4F commands are the same number of entries as the 0x80-0x8F game selection commands.

The other command that returns weird data is CMD 0xFF. I get varied results after sending that command - generally something along the lines of:
CMD:FF: 2A E0 2A 2A 8F 8F 9F 9F
or
CMD:FF: 2A F0 2A 2A 8F 8F 8F 9F
or
CMD:FF: 2A F0 2A 2A 8F 8F 9F 9F

I'll have to do more testing.

Posted: **Thu Oct 22, 2015 4:11 pm**

Hi Everyone,

I know this is a little off topic but still Nintendo Power cart related. I'm trying to re-flash my GB NP cart but there is very little info on the protocols. I've thoroughly read through all that has been posted regarding the MX flash IC's and it is very good work you have all done on reversing and discovering the non-standard flash features.

The GB cart also holds ROM information outside of the standard flash ROM space. I've probed the WR and CE lines while requesting a read of this data and there is no activity so I don't believe the data is stored in the Flash IC at all.

Perhaps it is in the SRAM, or even inside the custom controller IC. More effort will need to be put into this to get to the bottom of it.

My biggest issue is the flash protocol used in the MX chips. I cannot get any response from the chip when trying with all the standard flash protocols, Macronix, Sharp, Intel, even the SNES flash IC instruction set seems to be ignored.

I know the data bus is direct from the edge connector to the Flash IC, I know that my instructions are passing through to the IC and the magic sequence is working as I get bus activity on the chip when issuing my commands. It seems it is the commands that are not correct.

Has anyone had experience with this particular flash IC? or could possibly point me in the direction of a datasheet?

Thanks!

Edit-

I've spent the last couple of hours disassembling Mootan's program to try find the protocol. Not having GiveIO.sys, or a compatible system to install it, or the supported cart interface has slowed me down a little. I have not returned empty handed though, here is what I have found:

There are 7 functions written to communicate with the NP cart. I'll list them as discovered in the binary.

1:
[0120] <- 0F
[0125] <- Address Hi
[0126] <- Address Lo
[0127] <- Databyte
[013F] <- A5

2:
[0120] <- 09
[0121] <- AA
[0122] <- 55
[013F] <- A5

3:
[0120] <- 08
[013F] <- A5

4:
[0120] <- 0A
[0125] <- 62
[0126] <- 04
[0127] <- 00
[013F] <- A5
[0120] <- 01
[013F] <- A5
[0120] <- 02
[013F] <- A5

5:
[0120] <- 10
[013F] <- A5
[0121] <- 01
Following Data bytes are passed through to flash using Function #1
5555 <- AA
2AAA <- 55
5555 <- Databyte (passed to the function as variable)

6:
[0120] <- (0xC0 & Databyte) passed to function as variable
[013F] <- A5

7:
Following Data bytes are passed through Function #1
4555 <- AA
42AA <- 55
4555 <- Databyte (passed to the function as a variable)

From the work Nitro has done, and some logic and trial and error on my Joey, Function 1 is a raw write access function to the Flash IC. Before you can issue Function 1, you need to execute function 2 & 4.

Function 3 returns the cart back to a read only mode.

Function 4 differs slightly to what Nitro has documented as does 1.

Function 5 seems like a generic flash preamble

Function 6 swaps out ROM blocks within the flash. This is how the custom IC changes games.

Function 7, similar to 5 except is write to the high bank of the GB cart, maybe used for writing to sectors other than bank 0??

Still more work to do, like find out why I can't get a response from my Flash IC... At first I though maybe the CE line must remain active the whole command sequence but Mootan doesn't seem to adhere to that logic...

And where is the ROM data stored if not the Flash??!?!?

Hopefully hear back from Nitro soon.

Posted: **Sun Oct 25, 2015 1:18 am**

One mystery solved.

I coded a bootstrap program on the gameboy, hot-swapped carts to the NP then tried the usual 5555/2AAA flash instruction set. Success!

Now out with the logic analyser to compare pulse timing with the gameboy vs my Joey. Maybe 480ns WR pulses are too quick for the MX flash IC.

Once I get my cart interface debugged, I can find where they hide the magic info.

Posted: **Sun Oct 25, 2015 10:35 am**

Not sure if it helps but on the SNES NP cart I do the WR pulses like so:

// Arduino running at 16Mhz -> one nop = 62.5ns
// Wait till output is stable
__asm__("nop\n\t""nop\n\t""nop\n\t""nop\n\t""nop\n\t""nop\n\t");

// Pull WE low
digitalWrite(wrPin, LOW);

// Leave WE low for ~375ns
__asm__("nop\n\t""nop\n\t""nop\n\t""nop\n\t""nop\n\t""nop\n\t");

// Pull WE high
digitalWrite(wrPin, HIGH);

// Leave WE high for ~375ns
__asm__("nop\n\t""nop\n\t""nop\n\t""nop\n\t""nop\n\t""nop\n\t");

Ofc since the Arduino is kinda slow, it will end up to be more than 375ns.

And writing I do like this

// Write hirom
for (int currBank = startBank; currBank < startBank + numBanks; currBank++) {

// Print Status
Serial.print(".");

// Fill SDBuffer with 1 page at a time then write it repeat until all bytes are written
for (unsigned long currByte = 0; currByte < 0x10000; currByte += 128) {
myFile.read(SDBuffer, 128);
// Write command sequence
writeBank(startBank, 0x5555 * 2, 0xaa);
writeBank(startBank, 0x2AAA * 2, 0x55);
writeBank(startBank, 0x5555 * 2, 0xa0);

for (byte c = 0; c < 128; c++) {

// Write one byte of data
writeBank(currBank, currByte + c, SDBuffer[c]);

if (c == 127) {
// Write the last byte twice or else it won't write at all
writeBank(currBank, currByte + c, SDBuffer[c]);
}
}
// Wait until write is finished
busyCheck(startBank);
}
}
}

Posted: **Sun Oct 25, 2015 11:40 am**

skaman wrote:This appears to be something new. CMD 0x20 turns off bit 3, CMD 0x21 turns on bit 3. You can even use CMD 0x21 with CMD 0x02 and the resulting Port 2401 output will be 0x0C. The 0x40-4F commands are the same number of entries as the 0x80-0x8F game selection commands.
The other command that returns weird data is CMD 0xFF. I get varied results after sending that command - generally something along the lines of:
CMD:FF: 2A E0 2A 2A 8F 8F 9F 9F
or
CMD:FF: 2A F0 2A 2A 8F 8F 8F 9F
or
CMD:FF: 2A F0 2A 2A 8F 8F 9F 9F

Good findings! I didn't have tried CMD 20h/21h. But tested them today, setting/clearing bit3 happens here, too. And the effect... it looks as if FLASH reads are disabled when bit3=1 (on a SNES, I am getting open-bus values when reading the ROM area, ie. retrieving the MSB of the ROM address as open bus data value).

CMD 40h-4Fh are just aren't doing anything special? Ah, or is their "special" effect that they don't reset the chip to return 7Dh bytes when reading port 2400h-2407h (unlike most other CMDs which do have that "reset to 7Dh" effect)?

CMD FFh doesn't seem to work for me. It doesn't change the port 2400h-2407h values, and also doesn't issue a RESET. Maybe it works only in relation to other values being sent prior to CMD FFh? And you are sure that you've used CMD FFh, aren't you? Asking because CMD 00h would have roughly the same effect as what've described (setting the 8 registers to "2A E0 2A 2A FF FF FF FF" in my cart).
The 'variable' bytes that you are receiving (E0 or F0, and 8F and 9F) are looking like some unstable/uninitialized stuff. Are there any cases where you are always getting the SAME values? Like always getting the same values after power-up? Or getting different values only when using different cartridges?

Posted: **Sun Oct 25, 2015 11:53 am**

BennVenn wrote:[0120] <- 0F
[0125] <- Address Hi
[0126] <- Address Lo
[0127] <- Databyte
[013F] <- A5

That's about same as in the "appendix" on the http://blog.gg8.se/wordpress/2013/02/25 ... and-tears/ page (apart from the extra "[0120]=02" on that page). The thing that is really confusing me is how one could address an 8Mbit(?) chip with two address bytes - unless the address is meant to be an 14bit offset within the gameboy's current 16K-byte bank?

Some other stuff that would be interesting about the gameboy FLASH chip would be if it's requiring that "write-last-byte-twice" thing, too. And just for curiosity, which manufacturer/device IDs it's having. And of course, if it's returning hidden data when sending those "38h, D0h, 71h..." values, too.

nesdev.org

How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?

Re: How to program a NINTENDO POWER Cartridge ?