SNES rev 1 black screen at startup

[Poot36]

The game is still All-Stars. The SNES has the the resistor from the reset line that comes out of PPU2 that holdes the CPU, RAM and sound module in reset disconnected (I think it is R72 or R74). I can trigger off the sysck line and I think I can trigger off a data pattern but I will need to read my LA manual to figure out how to do it. I will loose the CPURD and CPUWR signals by doing this though (trigger off SYSCK). The LA is a HP 1661C if you are wondering. I will try to convert the tif files to jpeg in the future. Sorry about that. It also looks like the SNES is trying to enable the display but ends up turning it off as well as trying to initialize the sound module.

[lidnariq]

I will loose the CPURD and CPUWR signals by doing this though (trigger off SYSCK).

Oh? Eh, not worth it, then – basically the useful thing to know is the value of the various busses on a rising edge of any of CPURD, CPUWR, PARD, PAWR.

I will try to convert the tif files to jpeg in the future. Sorry about that.

Wait, wait, NOT jpeg. Almost anything but jpeg. JPEG does great for photographic pictures with soft gentle brightness ramps in it, but badly for 6-grey images like these.

Also, it's not like saving 200kB is really worth that much. Don't feel bad about it.

---

Anyway, if I compare what the LA trace is doing to what the game "ought" to be doing (according to NO$SNS's debugger), I actually see some useful things:
At $00866D, SMAS has the following code:

Code: Select all

sta $2181
sty $2183
lda #$8000
sta $4300
lda $02
sta $4302
ldy $04
sty $4304
lda $00
sta $4305
ldy #1
sty $420B

In the debugger, when this routine is first called, the first five bytes of memory are $00 $04 $00 $FC $07—it should be trying to transfer $0400 bytes from address $07FC00, and instead it's getting open-bus values.

Oh, right. You said you disabled the RAM. Well, it definitely shows that.

[tepples]

In this trace, SYSCK itself looks interesting. It's not 50/50 duty; slow cycles seem to have it high longer while CPURD is low longer. This confirms my suspicion about 3/5 ratios. There are also what appear to be a few very short pulses on SYSCK; what do those signify?

I will try to convert the tif files to jpeg in the future.

PNG would be far better.

[lidnariq]

Here's a plot of just the control signals: http://eamp.org/li/controlsignals8.png (2kB, Warning: 16400 × 64 pixels) Each input sample was converted into two horizontal pixels (to allow the vertical transitions to not obscure the end value)

The short pulses might be glitches? The entire thing appears to be using the 21.5MHz SNES master clock for the sample clock.

[Poot36]

Ok, I have converted the pictures to .png. I have found out that triggering on SYSCK is a bad idea because you do end up loosing the CPURD, CPUWR, PARD, and PAWR lines and sometimes the LA will stop capturing if it does not see a clock for a predetermined time. I have captured a trace by leaving the SNES running but just re-triggering the LA. The RAM chip is still being reset, all I have done is prevented the PPU2 chip from holding it (and the CPU and Sound Module) in reset by disconnecting R74 in the schematic. This is the /RESOUT1 line. The CPU still pulls this reset line high.

[lidnariq]

Unfortunately, this trace just shows garbage again :/

Code: Select all

 time     db    addr    /rd   /wr pa  /pard /pawr /ram   +refresh
   7795    FE<-[000D]     0     1 03    1    1      1      0
   7801    3C<-[000E]     0     1 03    1    1      1      0
   7809    7C<-[001F]     0     1 04    1    1      1      0
   7816    00<-[3E1A]     0     1 06    1    1      1      0
   7823    FC<-[01FF]     0     1 04    1    1      1      0
   7827    18<-[0011]     0     1 04    1    1      1      0
   7837    00->[7EE8]     1     0 CA    1    1      1      0
   7844    13->[7EE7]     1     0 C9    1    1      1      0
   7851    39<-[77FF]     0     1 C4    1    1      1      0
   7863    00<-[3933]     0     1 0D    1    1      1      0
   7867    00<-[3935]     0     1 0D    1    1      1      0
   7875    0C<-[C3FF]     0     1 00    1    1      1      0
   7881    4B<-[0001]     0     1 00    1    1      1      0
   7885    0A<-[0001]     0     1 00    1    1      1      0
   7893    D7<-[8A42]     0     1 02    1    1      1      0
   7903    D7->[8A4B]     1     0 42    1    1      1      0
   7909    C1<-[8A4B]     0     1 40    1    1      1      0
   7915    08<-[0003]     0     1 01    1    1      1      0
   7921    47<-[0004]     0     1 01    1    1      1      0
   7927    06<-[0005]     0     1 01    1    1      1      0

Those aren't sensible addresses to be reading from or writing to.

[Poot36]

Hmm, I wonder if the SNES has crashed after attempting to execute some corrupted code. Would a bad RAM chip cause this or is it most likely the CPU? If I disconnect the RAM chip (eg keep it in reset or use the chip select line to disable it) what should I expect the CPU to do? Is there a off the shelf RAM chip that I could try replacing it with?

[lidnariq]

Really hard to tell, either could be breaking things. For all I know, SMAS could just start executing random crud if any peripheral isn't working.

(e.g. There's the known bug in the revision 1 CPU's DMA controller (revision is indicated on top of the CPU package, 5A22-nn); if SMAS is writing specific wrong garbages to the DMA controller, because it expected valid values in RAM ... well, we don't actually know what that crash looks like, in an electrical sense.)

Anyway, what's keeping you from making a test cart? Lack of PROMs? Lack of programmer? You're quite clearly already very good with a soldering iron...

[Poot36]

I got a 2Mb 120ns eeprom that I think will work and have programmed it on a 1988 Data I/O using the site 48 plugin. It has two 720Kb floppy drives and has boot software from you will never believe this 2006 running on it! It uses a serial port for communication and takes 5 minutes or so to start up off the floppy drive (old slow 10Mhz Motorola based processer I think). I am still trying to find a cart to modify and I don't look forward to removing the existing rom chip without damaging it. I think you are right that I am just making things more complicated then they need to be with a standard cart. What cart should I be looking for to run the test programs that have been mentioned in previous posts? I think it has to be a LoROM cart.

[lidnariq]

Is this an UVEPROM or EEPROM? A lot of the earlier SNES carts are DIP; the later ones tend to be SMT. For reference, you can look at the pages on snescentral.com.

Alternatively, if you have the ability to get a PCB made (such as a PCB mill), I have a very simple design that would accept a 128 to 512 KiB EEPROM like the SST39SF0x0 series. It's basically identical to the 1A0N and 1JON official PCBs.

[cdq1985]

Hi. I'm new here. I own a used game store and have several SNES consoles with the same problem. In my many repair attempts I did notice one strange occurrence. A "Jeopardy" game cartridge I used for testing would actually load (briefly) on these consoles. Only for a few seconds, but the title screen would be visible. No other cartridge I used would do this. Not sure if this means anything. Just thought I would throw it out there.

[Poot36]

Ok, I have finally got a cart to make into a test cart (Donkey Kong Country) that had a damaged ROM chip. I have attached a socket and have preformed the 2 pin swap but only connected the CS line due to my chip only having 2mb (256Kb) of space on it. I have used the snesROMUtil to byte swap the .sfc file and programmed it to the chip however it is not working. The flash chip is a AS29F2008-12 made by ASD and I can not find a datasheet for it and my programmer does not have it listed so I selected Winbond W29C020 in my programmer instead. The cart is labled SHVC-1J1M-11 and has a MAD-1 chip on it. Am I doing this wrong or do I need a 27c801 for this utility to work? Is there a more compatible flash chip that I can select in my programmer? The original ROM chip does have a small crack like blister showing on the package, is it possible that it damaged other chips on the board when it died? Should I bypass the MAD-1 chip?

[lidnariq]

but only connected the CS line

I hope that that means that both the PROM's /OE and /CE pins are connected now?

and programmed it to the chip however it is not working.

Ok, what are you testing with? The smaller the better, because it reduces the number of possibilities for things to screw up.

Also, I hope you have a known-good SNES to distinguish between "cart" and "console" ?

The flash chip is a AS29F2008-12 made by ASD and I can not find a datasheet for it and my programmer does not have it listed so I selected Winbond W29C020 in my programmer instead.

If you remove power to the 'PROM, restore power, and the programmer verifies, you can assume it worked.

(Donkey Kong Country) [...] The cart is labled SHVC-1J1M-11 and has a MAD-1 chip on it.

Ok, I'm looking at 1J1M for reference.

Am I doing this wrong or do I need a 27c801 for this utility to work?

No, but you'll need to pad and then truncate off duplicates: see this bug report for SNES ROM Utility.

Alternatively, why do you (think you) need to endian-swap the bits?

Is there a more compatible flash chip that I can select in my programmer?

No idea, unfortunately. I can't even find out who "ASD" was.

The original ROM chip does have a small crack like blister showing on the package, is it possible that it damaged other chips on the board when it died? Should I bypass the MAD-1 chip?

Can't hurt. If you do do that, make sure you disable the RAM on the cart: the MAD-1 is basically a 74'139 (responsible for decoding RAM, or multiple ROMs) plus a battery backup protection circuit.

[Poot36]

I think I figured out a few things. First I meant OE not CS (was reading off the SNES schematic). Second I think the "J" letter printed on the cart label means that it is a HiROM cart and all of the ROMs that I am using are LoROM. Third the byte swap is so that I only have to change the positions of 2 pins of the EEPROM instead of 5 pins due to the nonstandard pin placement of the cart vs EEPROM. After reading the extra note of the utility my roms are only 2mb so from what I gather I need to expand it to 8mb and then run it through the utility but could I then shrink it back to 2mb and have it still work is the big question? Forth is there a way to convert the LoROM file to a HiROM one or will I have to modify the cart further? Fifth I do have a working SNES and can confirm that the cart's CIC (lockout) chip is still functioning. I have programed this chip before (but only as a 1mb chip by holding the last address line permanently low and selecting the W29C010 from the programers list) for a 486 motherboard and it worked but would sometimes give me errors I think due to the board been flaky or it somehow rewriteing the chip (it was designed for a UV EPROM). I think the second problem is the root cause of this not working. Oh well at least I am learning and no magic smoke has come out yet.

[lidnariq]

is there a way to convert the LoROM file to a HiROM one or will I have to modify the cart further?

Yes, but you lose half the capacity.
HiROM can store LoROM by taking each successive 32KiB of the input file and putting it twice, sequentially, in the output file. (i.e. ABCDEFGH becomes AABBCCDDEEFFGGHH).


It's probably easier if you find one of the various tiny SNES tests, like the pile of 32 KiB homebrew that have been made over the years... not that I can find an obvious listing of these.

If nothing else, I took tepples's spadtest-0.01 and reassembled it to be eensy (just 8KiB). Duplicate it to fill your 'PROM.
The patch containing the source differences to make it 8KiB instead of 256KiB is included in the zip.