It is currently Wed Dec 13, 2017 3:53 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 197 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 14  Next
Author Message
PostPosted: Sun Aug 09, 2015 9:44 am 
Offline
User avatar

Joined: Sat Jul 20, 2013 2:21 pm
Posts: 43
Turns out MX1500 pin 29 is VCC :oops:


Top
 Profile  
 
PostPosted: Sun Aug 09, 2015 1:47 pm 
Online

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 537
Ah, then everything makes more sense (and pin 38 would be another "mode select" input with either R11 or R12 installed, similar to pin 97).

Could you check R7 and R8, too? Both would make more sense if they would go to VCC instead of GND.

PS. and double check if FLASH_WE3 is really shared as SRAM_WE? It's possible, but looks quite odd. But having three separate FLASH_WE signals is odd anyways, no idea what they have intended there.

PPS. why is the schematic called "Nintendo SF-Memory Cartridge"?
"Nintendo Power Cartridge" would appear more obvious to me : -)


Top
 Profile  
 
PostPosted: Mon Aug 10, 2015 2:15 am 
Offline
User avatar

Joined: Sat Jul 20, 2013 2:21 pm
Posts: 43
WE is shared between the 3rd Flash and the SRAM, just double checked again to be sure.


Last edited by sanni on Sun Sep 27, 2015 6:36 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Aug 10, 2015 4:38 am 
Online

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 537
Okay, you are right. Thanks for checking!
One small detail: the signal on MX1500 pin 34 should be marked GND.


Top
 Profile  
 
PostPosted: Mon Sep 14, 2015 4:04 am 
Offline
User avatar

Joined: Sat Jul 20, 2013 2:21 pm
Posts: 43
So I desoldered the two MX29F1601 flashroms out of my NP cart and wrote a programmer based on Arduino for them. It works but takes 4 hours because I am supposed to write 128 bytes at once but I only write one byte at a time. Because otherwise I get alot of unwritten bytes. So no special write commands, no protected sectors, just a changed protocol that I don't fully understand, which is why it takes 4hrs to write them.

Now I did the following tests:
- flashed a retail Illusion of Gaia to one of the MX29F1601 and put the flashrom into a standard hirom pcb to confirm that you can indeed flash the MX29F1601 -> it worked flawlessly
- flashed a retail Illusion of Gaia to one of the MX29F1601 and put the flashrom back into the Nintendo Power cartridge -> didn't boot
- downloaded Wizardry 1-2-3(from some emu site), split it into two and flashed it to both MX29F1601 -> didn't work
- flashed back the Derby Stallion 98 with menu that was on there before -> worked

My conclusion, that could be wrong, is that when the rom you flash has a menu you can flash the MX29F1601's and it will work. If you flash something that doesn't have a menu it won't boot. Most likely there is something in the MX1500 chip that needs to be setup if there is no menu.

I did not have any luck flashing the MX29F1601 while they are still soldered into the NP cart even though I connected the missing WE/OE pins to the Arduino flasher. The data lines are connected straight through to the cart connector as you can see in the schematic I posted earlier but the address lines are not and not everything you send to the cart edge connector will come out of the other end of the MX1500 chip. At first it did but then the MX1500 chip somehow locked up idk. I have no clue what I am doing tbh.


Last edited by sanni on Wed Sep 16, 2015 2:36 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Sep 15, 2015 8:10 am 
Online

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 537
Interesting and good to know that write commands are working, at least with 1-byte writes.
Aside from being slow, issuing 128 separate writes per sector will also reduce the chip's lifetime by factor 128.

Did you test your code with both MX29F1610 and MX29F1601 chips? Ie. are you sure that the "can write only 1 byte" problem occurs only for the Nintendo Power chips, or could be a general problem with your code?

For the "delay(7)": Erasing/writing flash memory does take some time, so you would need some similar delay also for normal 128-byte writes. Usually, the chip should output some "busy/ready" info, so you would wait for that info instead of using a hardcoded "delay(n)". Going by the MX29F1610 datasheet, data.bit7 should indicate ready. Or are you doing that kind of wait somewhere outside of the write function?

Datasheet also says that gaps between multiple byte writes may not exceed 30us. That might also cause lost writes in case the arduino is too slow, or in case it gets interrupted by IRQs.

NB. what is delay(7), seven microseconds, or seven milliseconds?


Top
 Profile  
 
PostPosted: Tue Sep 15, 2015 9:23 am 
Offline
User avatar

Joined: Sat Jul 20, 2013 2:21 pm
Posts: 43
I started with the 29F032 flashrom and wrote an Arduino Mega based programmer for that, then continued to the 29F1610 and 29L3211 and finally tried to apply what I learned to the NP's 29F1601.
I'm a beginner when it comes to programming, hence working with Arduino.
Yes the delay is also needed with the 29F1610, but since I can write 128bytes per delay it's not that bad. The delay is in milliseconds (1/1000s), so it's quite long if you have to delay after every written byte.

Reading the status register while the flashrom is programming itself would be much much better, I tried that but couldn't get it to work so I kept the delay.

The next step would be to be able to program the flashrom inside the NP cart without the very tedious process of desoldering the flashroms.


Last edited by sanni on Sun Sep 27, 2015 6:35 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Wed Sep 16, 2015 1:37 pm 
Online

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 537
I got an own nintendo power cart, too (thanks to skaman). And started some hardware tests today. Some first findings:

The thing initially didn't want to boot, but worked after a few attempts with inserting/removing the cartridge, maybe the contacts in my console were just a bit dirty. I am a bit surprised that it is working in my PAL console (with the PAL-CIC disabled in the console). I would have expected needing to disable the NTSC-CIC in the cartridge since it's passing some "ERROR" signal to the MX15001 chip... but apparently that signal doesn't protect the NTSC cart agaist being used in (modded) PAL consoles. Well, just fine.

Next surprise is that the boot menu music is quite moderate. After having listened the Satellaview and DSi bootmenu music themes, I was having the impression that Nintendo planned to create an army of labile teenagers running amok and to randomly shoot other people just because they are scared and distracted about the world that they are living in. But, for the Nintendo Power menu, the music is quite okay (just gets a bit boring when listening to it for about 30 minutes). Hmmm, maybe I was wrong and Nintendo never really intended to provoke amok and they are just tend to have a real/unreal bad taste in music. Anyways.

The Reset button is handled other as I would have expected: Within the menu, it does just restart the menu. But after selecting a game, it does restart the selected game. Only way to return to the menu seems to be switching power off/on? Can somebody confirm that? (just in case it happens only on my modded PAL console).

Reading the I/O area returns value 7Dh for addresses 00h:2400h..2407h (no matter if menu or game is being selected). Addresses 00h:2408h and up are open bus. And there are no mirrors in other banks (tested banks 01h, 10h, 20h, 80h, and they are all open bus).

Next, I've also had a look at the menu of the nintendo power gameboy version. One difference is that it's having some simple selftest mode, which is making a bit easier to get an idea what kind of commands are being used/supported. The used port [0120h] command numbers are 09h, 04h, 05h, 08h for whatever purpose, and 8xh and/or Cxh for game(x) selection. All commands seem to be terminated by [013Fh]=A5h. Command 09h should be prefixed by a dummy read from [0120h], and seems to require two fixed parameters: [0121h]=AAh, [0122h]=55h. The other commands don't use any parameters at all. The "decode data" selftest displays a 24bit value read from [0122h..0124h], and does then verify if [0122h..0124h] is A8h,00h,00h. The "menu sequence" selftest checks if [013Fh] is A5h.
The homebrew source code snippets for programming nintendo power gameboy carts are using command 09h and 04h, too. Plus commands 01h, 02h, 0Ah (also without parameters), plus command 0Fh (with 8bit data and some incomplete looking 16bit address). I am still wondering who has reverse-engineered those extra commands and how. Either somebody did have access to an official programming station - or somebody just randomly tried sending commands & parameters to see if any of them would pulse pins on the FLASH chip. Considering that most commands don't require any secret parameter values, that method should be actually working - without even needing any other equipment than a LED or volt-meter.

Going by the part number, the SNES chip seems to be a bit older than the gameboy chip. And it doesn't seem to require any equivalent to the gameboy's trailing [013Fh]=A5h write. So, the SNES chip might be even less complicated than the gameboy chip. At the moment, I am optimistic that it'll be cracked in next 24 hours...


Top
 Profile  
 
PostPosted: Wed Sep 16, 2015 1:57 pm 
Offline
User avatar

Joined: Sat Jul 20, 2013 2:21 pm
Posts: 43
"Within the menu, it does just restart the menu. But after selecting a game, it does restart the selected game. Only way to return to the menu seems to be switching power off/on?"

It does exactly the same on my Super Famicom. Also when in the menu you can hold X and it shows you where the game is stored and how much space it occupies by flashing the F and B symbols.

As for the GB NP cart it seems like the commands where found by doing some educated guesswork and using a lot of probes:
Image
"Combination of numbers will become the astronomical number, but look at the behavior we will squeeze to guess the command format."(Translated by google from this source http://mootan.hg.to/fmgbx/)


Top
 Profile  
 
PostPosted: Wed Sep 16, 2015 3:17 pm 
Online

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 537
Yeah, I've seen that photo. It's a bit hard to make sense of it. The stupid theory would be that the software for the blue cartreader did have nintendo power support included, and that the guy reverse engineered the software with a logic analyzer instead of disassembling the cart reader software directly. But that would be just stupid.

Other theory would be that the cartreader was just used for doing the tests on a PC instead of on a real gameboy. The connection is weird though. The nintendo power cart-edge seems to be on the left (=without direct connection to the cartreader on the right). Maybe there's an adaptor from left-to-right underneath of the cartridge, and with additional wires on the left for forwarding the cart-edge signals to the logic analyzer (not that one would need to analyze the cart edge signals that one is sending to the cart, since one should know what one is sending anyways; but it might be helpful to log the sent-commands alongsides with the cart-internal signals). Inside of the cartridge, most wires seem to go to the SRAM chip (makes sense since it has the biggest solder pads).


Top
 Profile  
 
PostPosted: Wed Sep 16, 2015 3:49 pm 
Offline
User avatar

Joined: Sat Jul 20, 2013 2:21 pm
Posts: 43
As far as I understand it, the NP cart plugs into some cheat device like a Blaze xploder or Action Replay
Image
and through that it plugs into the blue Bung flash linker.
The cheat device is probably just used so he has better access to the NP cart since that way it's not hidden away inside the blue Bung flasher's cart slot.
Then he send commands from his pc through the Bung flasher to the cart edge and read the results if any on the sram chip inside the NP cart.


Top
 Profile  
 
PostPosted: Wed Sep 16, 2015 6:17 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 760
My guess is that they hooked it up to that device just as a PC interface to send arbitrary commands to the cart, then they have the probes set up to log the output result of the commands. Chances are, the SNES cart has an unlock sequence similar to the GB one, and you could try to bruteforce it by sending a single byte sequence to each address, and cycle through every address/data combination, then try a two-byte sequence, then three, and basically monitor the ROM /WE line. If you manage to get the /WE line to go low, then you've found the unlock sequence. However, as the poorly translated page says, the number of possibilities quickly becomes incredibly large. You could start with some commonly-used values to start though, such as 0x55, 0xA0, 0xAA, etc. as data values.


Top
 Profile  
 
PostPosted: Thu Sep 17, 2015 3:00 am 
Online

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 537
Oh, yes, the yellow Blaze thing looks like the gray case on the other photo.

Writing commands to the FLASH chip seems to be no issue, writing the chip ID commands works without problems, it does even seem to work without needing to send any of the special nintendo power commands (like those being sent in the menu). I've tried this:
Code:
 mov  a,0aah // mov  [far 018000h + 1555h*2],a
 mov  a,055h // mov  [far 008000h + 2AAAh*2],a
 mov  a,090h // mov  [far 018000h + 1555h*2],a
 mov  a,[far 008000h]  ;returns C2h, maker (Macronix)
 mov  a,[far 008001h]  ;returns zero (unused, aka MSB of maker)
 mov  a,[far 008002h]  ;returns F3h, device (MX29F1601MC)
 mov  a,[far 008003h]  ;returns zero (unused, aka MSB of device)
 mov  a,[far 008004h]  ;returns C2h (probably "sector protect" flag, not maker)
 mov  a,[far 008005h]  ;returns zero
 mov  a,[far 008006h]  ;returns zero
 mov  a,[far 008007h]  ;returns zero

Unlike as in the gameboy source snippets, the writes are done directly to cartridge memory space (rather than writing HH and LL and DD bytes to the MX15000x registers; though the SNES might support that indirect write method, too).
The MX29F16xx chips are having 16bit databus, hence the "word addresses" in the datasheet are meant to be multiplied by 2 for "byte addressing" (ie. word address 5555h would be AAAAh in byte addressing, with the SNES LOROM mapping, that'd be 01:AAAA, ie. the above "mov [far 018000h + 1555h*2]" opcode).

For programming the FLASH memory, the main issue would be probably finding a way to unlock the /WP pin (ideally by software, although doing it by soldering would be "easier").
The other issue would be getting access to the whole FLASH memory (writing to the LOROM space of a cartridge with MENU does probably allow to access only the mapped 512Kbytes) (a possible workaround might be overwriting the MENU's cart header by a "bigger" cart header, reset the cart, and hope that the MX150001 chip will see the new header and map the whole memory, so one could then write a bigger file, or rewrite the menu with multiple smaller files).

I've also tried issuing the commands from the menu software:
Code:
 mov a,09h // mov  [002400h],a   ;\NP_CMD_09h
 mov a,[002400h]   ;dummy        ;
 mov a,28h // mov  [002401h],a   ;
 mov a,84h // mov  [002401h],a   ;/
 mov a,06h // mov  [002400h],a   ;\NP_CMD_06h
 mov a,39h // mov  [002400h],a   ;/

Don't know what CMD_09h is good for, maybe it's just needed as prefix for unlocking other CMD's (looks a bit like so in the gameboy menu).
CMD_06h seems to toggle port 2400h..2407h to return either eight 7Dh bytes, or bytes 2Ah,00h,2Ah,2Ah,03h,AAh,AAh,00h (it can be sent multiple times to toggle between the two responses). Whatever that's intended for.

Ah, and here's a summary of the different IDs (from datasheet's and from actual cartridge):
Code:
Manufacturer ID:
  C2h = Macronix
Device ID:
  FAh = MX29F1610A  ;\with sector_protect, suspend/resume, without sleep/abort
  FBh = MX29F1610B  ;/
  F7h = MX29F1611   ;-with sector_protect, suspend/resume, sleep/abort
  6Bh = MX29F1615   ;-without sector_protect, suspend/resume, sleep/abort
  F3h = MX29F1601MC ;<-- undocumented, used in SNES nintendo power carts


Top
 Profile  
 
PostPosted: Thu Sep 17, 2015 4:41 am 
Online

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 537
Tried the gameboy unlock stuff (commands 0Ah,04h,01h,02h). The SNES doesn't seem to require commands 0A,04,01h. The /WP pin is getting HIGH when just sending SECRET command 02h (preceeded by the OFFICIAL normal SNES bootmenu commands). Ie. this sequence:
Code:
 mov a,09h // mov  [002400h],a   ;\
 mov a,[002400h]                 ; NP_CMD_09h
 mov a,28h // mov  [002401h],a   ;
 mov a,84h // mov  [002401h],a   ;/
 mov a,06h // mov  [002400h],a   ;\NP_CMD_06h (send this only if above read has returned 7Dh) (not if it's already returning 2Ah)
 mov a,39h // mov  [002400h],a   ;/
 mov a,02h // mov  [002400h],a   ;-NP_CMD_02h  causes 2A,04,2A,2A instead of 2A,00,2A,2A --- and does set /WP=HIGH

Whoa, one must write 02h to 002400h. That's just... incredible ;- )

Testing some other random commands did also have some effects (mostly changing some of the 2A,00,2A,2A,03,AA,AA,00 response values):
Code:
;mov a,04h // mov  [002400h],a   ;-NP_CMD_04h  causes FE,61,A5,00 instead of 03,AA,AA,00
;mov a,0ah // mov  [002400h],a   ;-NP_CMD_0Ah  no effect
;mov a,01h // mov  [002400h],a   ;-NP_CMD_01h  causes always 8x7D
;mov a,02h // mov  [002400h],a   ;-NP_CMD_02h  causes 2A,04,2A,2A instead of 2A,00,2A,2A --- and does set /WP=HIGH
;mov a,00h // mov  [002400h],a   ;-NP_CMD_00h  hangs?
;mov a,03h // mov  [002400h],a   ;-NP_CMD_03h  causes 2A,E0,2A,2A,FF,FF,FF,FF and /WP=LOW


Top
 Profile  
 
PostPosted: Thu Sep 17, 2015 8:55 am 
Online

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 537
Tried sending the FLASH write command. Doing it as described in datasheet (or as in sanni's 29F1610 source) doesn't work out for the 29F1601 chip. It's causing odd effects: Outputting weird status values on databus, even after trying to issue the "Read/Reset" command, so one is receiving those odd status values even on following "Read ID" commands.

So, I checked sanni's 29F1601 source code again... and, yes, writing the data byte twice is doing the trick: The chip is then outputting correct status values, and returns to normal state when issuing "Read/Reset".
Trying to write a different value didn't work as expected, the result got ANDed with the old value (I was thinking that the chip would automatically erase/rewrite the written page, which should works as so on modern FLASH chips, but the 29F1601 can apparently only change bits from 1 to 0).

Next, tried to write multiple bytes: Writing each byte twice didn't work, it caused only the first byte to be written. So write-twice is apparently terminating the write command. Writing all bytes (except last byte) once, and then writing the last byte twice seems to work okay. Then wait for status.bit7 to become set (in case of the arduino code, don't forget to switch to read-direction for status reads (read address can be probably anywhere, as long it's on the same FLASH chip; I used reading the address of first-written byte, or the last written-address should be fine, too), and remove all that delay(20) and delay(7) stuff).

---

Todo would be trying to find out how to access the whole FLASH memory. Or, well, maybe it's already fully accessible (I haven't yet tested if the the chip is booting up with/without memory being restricted to the 512Kbyte menu area).

And one thing that would be great is logging the traffic on the databus after switching from the menu to a game. That's something that can't be done on a SNES console (at least not without external extra hardware). But your arduino cart-readers should be quite optimal for doing that tests, somehow like so:
Code:
- output the game-select command (as done by the menu)
- set data direction to input
- manually issue LOW and HIGH pulses to the "21MHz" pin
  (ie. wrire some output to that pin, then switch it LOW and HIGH by software, with some "nop" delays)
- after each clock pulse, read the databus, and output its value to PC (via COM port or SD card or whatever you have)

That would be great for seeing if/what values the chip is reading from FLASH memory.
Logging the state of the cart-edge /RESET pin alongsides with the databus values would be neat, too.
The "21MHz" is probably internally divided, so you'd probably see each value on several clock pulses.
The chip is probably doing that on initial power up, too (so you may need to issue LOW/HIGH pulses to "21MHz" pin after power-up, too).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 197 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7 ... 14  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 14 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group