It is currently Sun Nov 19, 2017 11:05 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 197 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14  Next
Author Message
PostPosted: Fri Jan 29, 2016 2:28 am 
Offline

Joined: Fri Oct 24, 2014 1:56 am
Posts: 75
Success! Programmed my blank SF cart with US versions of Super Mario World and Super Mario All Stars (including English game names in the menu). The cart fully works with the new mapping.

Thanks to everyone that contributed to the project!


Top
 Profile  
 
PostPosted: Thu Feb 04, 2016 4:04 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 534
Did you figure out why C0h didn't work (or got it working with C0h?). I've tested only writing/erasing the E0h chip yet (and didn't expect any differences for the C0h chip). The FLASH chips should be same (and wired up the same), and the MX15001 probably can't prevent hidden writes (that would require it to be able to separate between normal & hidden flash writes). So I think that problem could be only due to different initialization of the flash chips.

If it's working with D0h but not with C0h... that sounds a bit as if the sector protect flag for the normal flash sector at C0h-C1h might also prevent accessing the hidden sector in that area... did you try clearing the sector protect flag? It's set by default/by nintendo, so you may need to clear it - and best keep it cleared forever since it's only disturbing normal writes (and maybe also hidden writes).

Problems with clearing the sector protect flag normally shouldn't happen - did you get that working, sanni? And released the /WP pin before doing so?


Top
 Profile  
 
PostPosted: Fri Feb 05, 2016 3:49 am 
Offline
User avatar

Joined: Sat Jul 20, 2013 2:21 pm
Posts: 43
I can't erase nor write the sector protection flag on the first flash chip. I'm using CMD 0x02 to unlock /WP, both /WP's of two flashchips are connected together and using CMD 0x02 does have an effect on the second flashchip as without it I can't erase the sector protection, but with I can.

Also I do have a Nintendo Power cart that doesn't have any protected sectors by default and one with two protected sectors(two as seen in hirom). Both behave the same, I can't set/erase the sector protection nor delete/write the hidden area of the first chip. Using bank 0xD0 also doesn't work for me.

Here is my current Arduino Cart Reader Shield code for the NP cart, it can write the 2MB flashroms in one minute each thanks to using direct port manipulation instead of the Arduino functions I used before. PORTE3 (Arduino Pin 5) is used for generating the clock signal and needs to be connected to the CLK input of the NP cart.
Besides the non working sector protection/reading and writing the hidden area on the first flashrom it works quite reliable.

Edit: I can erase/set the sector protection by using bank 0xC1 instead of 0xC0. Guess I'll try all banks to see if any work for the hidden mapping area.


Last edited by sanni on Sun Feb 14, 2016 5:29 am, edited 3 times in total.

Top
 Profile  
 
PostPosted: Fri Feb 05, 2016 4:26 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
skaman wrote:
Success! Programmed my blank SF cart with US versions of Super Mario World and Super Mario All Stars (including English game names in the menu). The cart fully works with the new mapping.

Thanks to everyone that contributed to the project!


Congratulations! Now please be sure to buy up all the cheap $20 NP games, reprogram them with Wizardry 1-2-3, and make yourself $360 per reprogramming.

And also thank you. Now I have a definitive reason not to purchase any NP games ever. Verification of their contents is completely meaningless and impossible now. Saves me a lot of money ;)

I'll probably use this knowledge to make a nicer serial UART dev cart for myself as well :D
(Will need that for investigating the behavior of expansion port devices like the Satellaview.)


Top
 Profile  
 
PostPosted: Fri Feb 05, 2016 11:53 am 
Offline

Joined: Fri Oct 24, 2014 1:56 am
Posts: 75
I haven't investigated the 0xC0/0xD0 further. I need to test on some of my other NP carts. I've been exclusively working on the blank cart so maybe that's the difference. 0xD0 works perfectly on the blank cart. EDIT: Tested on one of my other carts - Derby 98 and the mapping using 0xD0 works on it as well.

@byuu, you can get carts for less than $20. ;) Unfortunately, no one (outside of those in this thread) is dumping the complete menu AND mapping for the NP carts. Non-menu carts like Wizardry only need the mapping data which is basically 16 bytes in the hidden area. Creating multi-game carts would probably leave signs in the menu data that they're not original. Someone would need to accurately reproduce the menu entries including the SJIS, bitmap, and Nintendo/Lawson date and time stamp. I'm not really interested in faking the carts but at $360 a pop, anyone interested in a Derby 98 Wizardry cart? :P


Top
 Profile  
 
PostPosted: Sat Feb 06, 2016 6:07 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 534
sanni wrote:
Here is my current Arduino Cart Reader Shield code for the NP cart, it can write the 2MB flashroms in one minute

Looks as if you forgot to call the "busyCheck" in eraseMapping, unlockSectorProtection, and setSectorProtection - so that functions won't work (no matter what bank value you are using).
The various write/erase/lock/unlock commands (including hidden erase/write) are automatically switching to status mode (so you don't need the AA-55-70 in the busyCheck function).

The MX29F16xx datasheets specify 0.9ms per 128-byte page write (=avarage 7us per byte), so writing 2MB should take about 14 seconds, plus some more time for the chip erase (the datasheet says 1.3s per 128Kbyte sector, that would be 20.8s for the whole chip - but the chip erase command is hopefully faster, maybe taking only 1.3s for the whole chip).
And mind that you can program both chips simultaneously (issue write/erase to both chips, and - then - do busyCheck on both chips. So 14 seconds per 2Mbyte means that 4Mbyte will also take only 14 seconds (not 28 seconds).


Top
 Profile  
 
PostPosted: Sat Feb 13, 2016 12:50 pm 
Offline
User avatar

Joined: Sat Jul 20, 2013 2:21 pm
Posts: 43
I got it working now too, thanks to you and ofc skaman. :beer: :D

Followed your advise and updated the code in the link above. It now takes only 85s to flash a 4MB file instead of 125s like before thanks to flashing both roms in parallel.
With the busycheck commented out it takes 33s but ofc you only get write errors this way, but it means that all the sd reading code and sending the bytes out over the Arduino takes 33s while the additional 52s are spend in the busyloop waiting for the flashrom to send the "finished" command.


Last edited by sanni on Wed Mar 23, 2016 3:47 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Mar 21, 2016 11:03 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 534
Just released no$sns v1.6, and alongsides updated the Nintendo Power flashcart documention: http://problemkaputt.de/fullsnes.htm#sn ... rflashcard
The nintendo power chapters are still a bit messy, containing some unsorted scratch notes, but anyways, they should somehow contain everything that's known about those cartridges (unless I forgot to mention something in there).


Top
 Profile  
 
PostPosted: Thu Mar 24, 2016 9:57 pm 
Offline

Joined: Wed Mar 23, 2016 5:56 am
Posts: 1
nocash wrote:
Just released no$sns v1.6, and alongsides updated the Nintendo Power flashcart documention: http://problemkaputt.de/fullsnes.htm#sn ... rflashcard
The nintendo power chapters are still a bit messy, containing some unsorted scratch notes, but anyways, they should somehow contain everything that's known about those cartridges (unless I forgot to mention something in there).


Hey nocash, I believe your documentation on the title bitmap is slightly wrong, while each section is indeed 30h bytes, I believe the first two tiles are created in line by line pairs (line 1 tile a, tile b, line 2 tile a, tile b) until the first two tiles are complete, it then moves on to the third tile but uses 1 bit of padding between 2nd and 4th tile code, for example, writing FF 00 would result in the output looking like F0 with potential garbage caused by the first F being in the padding area, if we instead write as 0F F0 (inserting 1 bit padding at the start that shifts over the hex by 1 bit), then we have space to do all 12 lines of the tile within 0 padding before returning to the standard side by side tiles for tiles 4,5,7,8,10,11,13,14,16,17,19,20,22,23

I have demonstrated this here : http://i.imgur.com/DBKu5wo.jpg
using this hex:
Code:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 0FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF0 - char 1,2,3
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 0FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF0 - char 4,5,6
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 0FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF0 - char 7,8,9
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 0FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF0 - char 10,11,12
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 0FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF0 - char 13,14,15
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 0FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF0 - char 16,17,18
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 0FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF0 - char 19,20,21
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 0FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF0 - char 22,23,24


Top
 Profile  
 
PostPosted: Fri Mar 25, 2016 6:49 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 534
Yes it's two tiles line by line (hence the "y*2" in the formula; "y" is the line number). I think the formula is okay (for deciphering the bitmaps, which is probably opposite of what you are doing; assuming that you want to create those bitmaps). There is no "1 bit" padding/shifting (mind that hex-digits are 4bit wide).


Top
 Profile  
 
PostPosted: Sun Apr 24, 2016 2:18 am 
Offline
User avatar

Joined: Sat Jul 20, 2013 2:21 pm
Posts: 43
I made a short video: https://www.youtube.com/watch?v=YGsC28IBr2A&t=8m5s :D


Top
 Profile  
 
PostPosted: Sun Aug 28, 2016 5:48 am 
Offline

Joined: Sat May 11, 2013 3:03 am
Posts: 9
Hello!
I have bought one of Sanni's version 2 cart readers and I'm loving it:)
I want to thank all of you for the work you have put in to the project and especially figuring out the nintendo power cartridges, which are the reason I bought the shield.

What are the current goals people are working towards? I wanted to start figuring out the menu system myself by comparing different dumps but it looks like it's been done. I also don't think I ever would have figured out the bitmaps, and I'll admit it's still over my head even having read how it works..


Top
 Profile  
 
PostPosted: Sat Sep 24, 2016 1:42 am 
Offline

Joined: Sat Sep 24, 2016 1:36 am
Posts: 1
Is anyone interested in a dump of 16 random NP SFC carts? Hoping to contribute to some sort of menu tool being created for easy customisation of NP carts.
I've just archived them in a .rar with the flash, map and rom dumps with a text file containing the game names and order.


Top
 Profile  
 
PostPosted: Sat Sep 24, 2016 12:45 pm 
Offline

Joined: Fri Oct 24, 2014 1:56 am
Posts: 75
Here's a compilation of some stuff I wrote for someone awhile back.

There isn't an automated way to make a multi-game ROM yet. I know one person was planning to write a program to create multi-game ROMs but I haven't heard of any progress for a couple months. To do it manually, you'll need to gather the games that you want and then create the menu entries starting at 0x62000. You'll need to know the ROM and RAM sizes and place those into the game entry. As you add each game, then the offset to the ROM and RAM needs to be calculated. Once the sizes and offsets are in the game entry, then you need to create the game title for the menu. Final step would be to create the mapping file which would also include the offsets for each game and the LoROM/HiROM setting.

I'd start out with a list of games and write down their characteristics:
Game 1: LoROM 512KB ROM, 8KB RAM
Game 2: HiROM 512KB ROM
Game 3: LoROM 512KB ROM, 2KB RAM
and so on.

Then write the corresponding bytes into each menu entry. Game 1 would be at 0x62000, Game 2 would be at 0x64000, Game 3 would be at 0x66000, and each subsequent game +0x2000. Keep in mind that the Menu uses ROM Block 0 when calculating the ROM offset.

===============================
If you look at a multi-game cart dump, then the first 0x80000 bytes are the "MENU PROGRAM". Within the Menu Program, there are entries used by the menu. The Menu entry is at address 0x60000. The Game 1 entry is at address 0x62000. The Game 2 entry is at address 0x64000. If there were more games, then they would be at +0x2000 bytes (0x66000, 0x68000, and so on).

Each game entry basically has 0x1D8 bytes of unique data within the 0x2000 bytes. At the end of the block, there is the "MULTICASSETTE 32" text.

The full documentation is in nocash's FullSNES here: http://problemkaputt.de/fullsnes.htm#sn ... rdirectory
Code:
Directory Entry Format

  0000h 1    Directory index (00h..07h for Entry 0..7) (or FFh=Unused Entry)
  0001h 1    First 512K-FLASH block (00h..07h for block 0..7)
  0002h 1    First 2K-SRAM block    (00h..0Fh for block 0..15)
  0003h 2    Number of 512K-FLASH blocks (mul 4) (=0004h..001Ch for 1..7 blks)
  0005h 2    Number of 2K-SRAM blocks (mul 16)   (=0000h..0100h for 0..16 blks)
  0007h 12   Gamecode (eg. "SHVC-MENU-  ", "SHVC-AGPJ-  ", or "SHVC-CS  -  ")
  0013h 44   Title in Shift-JIS format (padded with 00h's) (not used by Menu)
  003Fh 384  Title Bitmap (192x12 pixels, in 30h*8 bytes, ie. 180h bytes)
  01BFh 10   Date "MM/DD/YYYY" (or "YYYY/MM/DD" on "NINnnnnn" carts)
  01C9h 8    Time "HH:MM:SS"
  01D1h 8    Law  "LAWnnnnn" or "NINnnnnn" (eg. "LAW01712", or "NIN11001")
  01D9h 7703 Unused (1E17h bytes, FFh-filled)
  1FF0h 16   For File0: "MULTICASSETTE 32" / For Files 1-7: Unused (FFh-filled)


You'll need to understand bytes 0x0-0x6. Byte 0 is the Game Entry#. Byte 1 is the ROM block offset. Byte 2 is the SRAM block offset. Bytes 3-4 are the number of ROM blocks used by the game. Bytes 5-6 are the number of RAM blocks used by the game. The game code at 0x7 can be anything but I'd suggest using the Nintendo assigned game code. The Shift-JIS text at 0x13 can be anything or padded out. The title bitmap at 0x3F is the text that is shown in the Menu. You'll have to convert your game title text to the format that the menu uses. The time/date/location stamp at 0x1BF can be left the same as you already have.

For example, a multi-game cart with 2 games (Shin Megami Tensei 1 & Shin Megami Tensei 2):

0x62000: 01 01 00 0C 00 40 00: Entry 1, ROM Block 1, RAM Block 0, ROM Blocks 0xC, RAM Blocks 0x40
0x64000: 02 04 04 10 00 40 00: Entry 2, ROM Block 4, RAM Block 4, ROM Blocks 0x10, RAM Blocks 0x40

If you look at Game 2, the game starts at ROM Block 4 because Game 1 uses 3 (0xC/4) ROM Blocks. Same goes for the RAM, Game 2 start at RAM Block 4 because Game 1 uses 4 (0x40/16) RAM Blocks.

Good Luck!


Top
 Profile  
 
PostPosted: Fri Oct 28, 2016 2:50 am 
Offline
User avatar

Joined: Mon Sep 05, 2011 5:56 pm
Posts: 287
Is this cartridge can only programming 10 times?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 197 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 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