(No self-flashing implemented yet, and CHR at $3000-3FFF seems to be a hard mirror of $2000-2FFF, so I don't really plan to implement that.)
I have some questions:
1. What does GTROM CHR-RAM test.nes do?
I get a grey screen with a pattern of beeps in the following rhythm: B . . . B . . . B . B . B . . . B . . . B . B . B
Is that correct?
2. Is the self-flashing process documented somewhere?
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"
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 ID
erase flash (full chip erase)
write $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.
Code: Select all
; wait >25ms
edit: forgot this part for reading the chip ID
Code: Select all
sta $8000 ; reset command
lda #$AA ; unlock command
lda #$90 ; auto-select command
lda $8000 ; mfg. id
lda $8001 ; device id
sta $8000 ; reset
lda #$BF ; maker: Microchip/SST
lda #$B7 ; device: SST39SF040
edit: I removed the prg0.nes attachment since it's self-destructive to bootloaders. If you need it for emu testing or board testing with game genie, send me a PM.
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).
Anyhow, your test ROM (once I set the mapper number to 111, and "battery backed" to enable the flash features) sounds like it's running. Whole lotta beeping, then eventually stops.
The last written value was 0x40, which according to your PDF is a red light. Dunno what test it failed, though.
There's 57 beeps, and it doesn't end in a busy loop. This is where it ends:
Code: Select all
A:40 X:10 Y:1A S:FF P:nvubdIzC $0508:8D 00 50 STA $5000 = #$40
A:40 X:10 Y:1A S:FF P:nvubdIzC $050B:A9 9C LDA #$9C
A:9C X:10 Y:1A S:FF P:NvubdIzC $050D:8D 00 40 STA $4000 = #$9C
A:9C X:10 Y:1A S:FF P:NvubdIzC $0510:A9 12 LDA #$12
A:12 X:10 Y:1A S:FF P:nvubdIzC $0512:8D 03 40 STA $4003 = #$12
A:12 X:10 Y:1A S:FF P:nvubdIzC $0515:4C 15 05 JMP $0515
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?
Edit: oh wait, I didn't realize 0 turns an LED on. 0x40 means "red LED off" doesn't it, so it's actually a success, eh?
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?)
Pretty 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'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.)
rainwarrior wrote: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:
Code: Select all
BF B7 01 FF 01 FF FF FE FF FF 25 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0F 06 01 FF (the rest is all FF)
edit: For giggles I tried changing the PRG bank before entering ID mode, it still works and returns the same thing.
I made a simple SNES PCB that takes a SST39SF040 and wrote a few simple tests...rainwarrior wrote:(Maybe it doesn't matter... lidnariq suggested it's "undefined".)
First 64 bytes of the ID memory on this random one I have are:
Code: Select all
BF B7 01 FF 01 FF FF FE FF FF 25 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0E 0C 04 FF FF FF
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
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