The self-flashing process should be almost identical to the self-flashing implemented for mapper 30/UNROM512; both boards use the SS39SF040 flash ROM for PRG storage. (Identical other than that GTROM uses 32KiB-at-a-time banking, and so issuing the flash command sequence doesn't require bankswitching)

PPU $3000-$3EFF shouldn't be a mirror of $2000-$2EFF if I remember what Memblers said correctly... IIRC it's basically "the bottom 8KiB and top 8KiB of PPU address space can each choose one of two separate banks of RAM, with no sharing"

I meant that FCEUX makes $3000-3FFF a forced mirror, so I can't implement it. (It seems his nintendulator implementation ran into the same problem?)

There's vague information on how to flash at the UNROM 512 wiki, but it's kind of underspecified as to how the flash chips respond to things (e.g. what causes the sequence to reset, etc.). I guess I can probably dig up a datasheet with that flash ROM part name though (thanks for that).

I was just hoping that Memblers had already written guidelines for it.

Yes, that sounds like the correct beep sequence. The test ROM writes an LFSR sequence into all of the CHR-RAM banks, resets the seed and reads them back for comparison. If it passes, it lights the green LED and sits in an infinite: JMP infinite loop. If it fails, it lights the red LED and sits in a loop repeatedly writing to the sound registers with my beep macro (makes a high-pitched screech on NES, may be inaudible or nearly so on emulators though..). During all this, it's sending text strings out the controller port at 19.2kbaud, not that that's useful in emulation (would be cool to do a high-level emulation of that sometime though, by adding a fake UART register for easier emulation).

I've attached the full version of the test program if you want to have a go at the FlashROM, it does things in this order:check flash chip IDerase flash (full chip erase)blank checkCHR-RAM checkwrite $8000-$8800 of every PRG bank (shortcut instead of writing the full 32kB)verify $8000-$8800 of every PRG bank

Works the same as the RAM test program did, it was just a cut-down version of this.

The Flash programming commands are best documented in the SST39SF040 datasheet, and like lidnariq mentioned it is similar to mapper 30. With GTROM the command unlock addresses are mapped to $D555 ($5555 on the chip) and $AAAA ($2AAA).

And yeah that memory at $3000-$3EFF is it's own region but is tied to the nametable bank select. No one is using that yet, not even my test ROM. I believe INL said one of his boards has a similar kind of feature too (not sure if or how it's banked in that case though).

If it helps, here are my flash routines (these have to copied into RAM and executed there for obvious reasons). The byte_program routine is probably kind of overkill, it follows what the datasheet says pretty closely though the NES is probably too slow for it to matter.

Okay, didn't seem too tough to do the self-flashing once I got my hands on the datasheet.FCEUX r3290

I didn't implement the software ID thing. Is it important?

Seems to run my dump of The Incident mostly fine. Though one or two curious things are happening, not sure if due to the mapper implementation. Saving seems to also turn off the game music for some reason, and going to erase data does erase but switches to the level editor mode for some reason (don't want to try and see if it does the same on my cart, because I've got a save halfway through the game).

The last sound written to the first square channel here is clearly not high frequency, and it's using the length counter, i.e. it's a regular "beep". This doesn't seem to be the failure noise you described?

Hmm, I've noticed that your test ROM does not write the mapper register before doing the Software ID test. According to the datasheet, reading the Software ID requires A1-18 to be low. How does it manage to pass that test on hardware? Does this rely on the mapper powering on in bank 0?

As near as I can tell, when in Software ID mode, reads from addresses other than 0 and 1 are undefined and don't pass through to the underlying flash.

On many other EEPROMs, Software ID mode seems to just ignore all the high address lines altogether, effectively replacing the entire ROM with a two-byte (or occasionally larger) mask ROM. I wouldn't be surprised if that's the case here, even though the datasheet disagrees with that comment about "5. With AMS-A1 = 0;"

Also, it's kinda funny that since this is a self erasing test, I have to delete the .sav every time I run it. Probably was more annoying for Memblers who had to reflash it every time? (Is that what the modded Game Genie was for?)

That's great, thanks a ton for getting that to work. It is passing the test. I've uploaded a Win32 build of it here, if anyone wants to try it out already:http://membler-industries.com/nes/fceux-r3293.zipPretty cool to see it in FCEUX, I've used that emulator so long that it's kinda like a modern-day NESticle.

That prg0.nes is what I use for testing before shipping, after running it on many hundreds of boards it is slightly surreal to see it (or hear, rather) run on an emulator. Though the beeps are little more satisfying when accompanied by the text output in the terminal, heheh.

Yeah it is kinda funny that the test self-destructs, I should probably hide that file now so when people use the on-cart version of the bootloader they don't forget what it is and ruin their day. I'll have to make a less dangerous test ROM if anyone else wants to support it in their emulators. Yep, that gets loaded from my Game Genie. It's pretty crazy how fast the full-chip erase happens, it gets annoying using the sector-based one after being used the full-erase, when you watch it go "loading, loading, pause, loading, loading, pause, ..."

I completely missed that footnote in the datasheet about the upper addresses needing to be zero when using the ID mode. The reason it never affected me was because I only load that program through the Game Genie, my loader puts it in the first bank, runs as soon as it's loaded and naturally the GG loader had set the bank reg before running it. The mapper when running by itself in an NES does certainly seem to have random startup state (especially easy to notice random LED state if the cart is blank).

I managed to get my dump of The Incident working in FCEUX, but I had to patch it slightly. It seems like the time it takes for writes to settle on the real flash is significant enough to make a difference here. I think the problem is that because timing has shifted there's an NMI happening at an very inopportune moment that causes a crash. All I did was add a BIT $2002 to clear the vblank flag at the offending moment, kind of a dodgy fix, but enough to verify that changing the timing makes the problem disappear.

I've let Kevin know, in case he decides this is something to be fixed. (Or if he has some other insight, still could be the emulator's fault in some way I don't forsee.)

Do you know what the chip does when in Software ID mode and you don't have all 0s? Does it just mirror those 2 bytes everywhere? (Maybe it doesn't matter... lidnariq suggested it's "undefined".)

I gave it a quick test, and it's not repeated. I'd agree with undefined, as there's some unknown results in there. I did a full chip erase, went into ID mode, then dumped the first 256 bytes ($8000-$80FF) and it looks like this:

The next 448 bytes are all FF except for two- at $00100 there's a $68, and at $001FF there's a $C8. The second 512 bytes are a repeat of the first 512, and this 512 byte pattern appears to repeat for most but not all of the memory.

Note that this flash is NOT empty.

I guess I should write a "real" memory explorer so that I can actually see where the pattern changes...

memblers: np, the post content was still in my browser history

Last edited by lidnariq on Thu Sep 01, 2016 9:18 pm, edited 3 times in total.

Who is online

Users browsing this forum: No registered users and 2 guests

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