It is currently Sat Sep 23, 2017 6:20 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 50 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Sun May 29, 2016 5:27 pm 
Offline
User avatar

Joined: Fri Apr 08, 2016 5:58 pm
Posts: 93
Location: California, USA
Ah, perfect. Thank you.


Top
 Profile  
 
PostPosted: Tue Aug 30, 2016 11:13 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5643
Location: Canada
I have made a preliminary implementation for FCEUX: https://sourceforge.net/p/fceultra/code/3287/

(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?


Top
 Profile  
 
PostPosted: Tue Aug 30, 2016 11:49 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6178
Location: Seattle
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"


Top
 Profile  
 
PostPosted: Wed Aug 31, 2016 12:10 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5643
Location: Canada
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.


Top
 Profile  
 
PostPosted: Wed Aug 31, 2016 12:32 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3466
Location: Indianapolis
Wow, that's great, thanks. :)

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)
blank check
CHR-RAM check
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:
byte_program:
        stx temp_x

        ldx #$AA
        stx $D555
        ldx #$55
        stx $AAAA
        ldx #$A0
        stx $D555
        sta (addr_lo),y

@toggling:
        ldx #2
@tryagain:
        lda (addr_lo),y
        and #%01000000
        sta temp_lo
        lda (addr_lo),y
        and #%01000000
        cmp temp_lo
        bne @toggling
        dex
        bne @tryagain

        pla
        cmp (addr_lo),y
        beq :+
@dead:
        beep ;error
        jmp @dead
:


        ldx temp_x
        rts

;---------


chip_erase:
        lda #$AA
        sta $D555
        ldx #$55
        stx $AAAA
        ldy #$80
        sty $D555
        sta $D555
        stx $AAAA
        lda #$10
        sta $D555

@toggling:
        lda $8000
        and #%01000000
        sta temp_lo
        lda $8000
        and #%01000000
        cmp temp_lo
        bne @toggling
        rts

;---------

sector_erase:
        lda #$AA
        sta $D555
        ldx #$55
        stx $AAAA
        lda #$80
        sta $D555
        lda #$AA
        sta $D555
        stx $AAAA
        lda #$30
        sta (ptr),y

        ; wait >25ms
        ldx #4
:
        lda $2002
        bpl :-
        dex
        bne :-
        rts



edit: forgot this part for reading the chip ID
Code:
autoselect_mode:
        lda #$F0
        sta $8000       ; reset command

        lda #$AA        ; unlock command
        sta $D555
        lda #$55
        sta $AAAA

        lda #$90        ; auto-select command
        sta $D555

        lda $8000       ; mfg. id
        sta temp1
        lda $8001       ; device id
        sta temp2

        lda #$F0
        sta $8000       ; reset

        lda #$BF        ; maker: Microchip/SST
        cmp temp1
        jne detect_fail
        lda #$B7        ; device: SST39SF040
        cmp temp2
        jne detect_fail



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.


Top
 Profile  
 
PostPosted: Wed Aug 31, 2016 2:19 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5643
Location: Canada
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).


Top
 Profile  
 
PostPosted: Wed Aug 31, 2016 2:53 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5643
Location: Canada
Hmm, I implemented the software ID thing.

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. :P

There's 57 beeps, and it doesn't end in a busy loop. This is where it ends:
Code:
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?


Top
 Profile  
 
PostPosted: Wed Aug 31, 2016 4:24 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5643
Location: Canada
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?


Top
 Profile  
 
PostPosted: Wed Aug 31, 2016 11:04 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6178
Location: Seattle
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;"


Top
 Profile  
 
PostPosted: Wed Aug 31, 2016 12:56 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5643
Location: Canada
Ah, that makes sense. I'll implement it as 2 bytes mirrored everywhere then.

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?)


Top
 Profile  
 
PostPosted: Wed Aug 31, 2016 7:30 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3466
Location: Indianapolis
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.zip
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).


Top
 Profile  
 
PostPosted: Wed Aug 31, 2016 8:04 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5643
Location: Canada
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".)


Top
 Profile  
 
PostPosted: Thu Sep 01, 2016 12:02 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5643
Location: Canada
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.)


Top
 Profile  
 
PostPosted: Thu Sep 01, 2016 12:40 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3466
Location: Indianapolis
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:
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.


Top
 Profile  
 
PostPosted: Thu Sep 01, 2016 12:43 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6178
Location: Seattle
rainwarrior wrote:
(Maybe it doesn't matter... lidnariq suggested it's "undefined".)
I made a simple SNES PCB that takes a SST39SF040 and wrote a few simple tests...
First 64 bytes of the ID memory on this random one I have are:
Code:
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 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.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 50 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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