Boot routine/ bank selection?

[Oziphantom]

okay so the SNES splits it and make both neg active.. odd

Visual6502 sadly doesn't show the RESET sequence, but pagetable has simulated it https://www.pagetable.com/?p=410
so it seems it

Code: Select all

READ 00FF
READ 00FF
READ 0100
READ 01FF
READ 01FE
READ FFFC
READ FFFD
READ (FFFC)

on an NMOS 6502.

Looking at your trace
I seems it skips straight to read 100
then does read 1ff, 1fe then pulls the vector.

[nocash]

Yes, if it's similar to 6502 then it's probably reading from stack instead of writing (6502 seems to decrease the stackpointer by 3 without writing).

/RD must be getting low when reading the reset vector, if it isn't: You have used the wrong pin, or it's shortcut to VCC. Or, if the logic analyzer is synced to the SNES cpu clock, then you might sample the /RD signal at the wrong time, and thus won't see the periods when it gets low.

Does address 3FFCh still occur? That should be FFFCh. And don't forget that LoROM doesn't use A15, so it would be at offset 7FFCh in the memory chip.

[VIP Quality Post]

As you had issues with the address pins, I would double check the data pins as well. You can open the ROM in a hex editor and see what values it should read at those locations and make sure your logs match.

I crossreferenced the ROM when I initially had this problem because that is what I thought was the issue. It doesn't match, so I am on the same page as you. I think the issue is in my ROM wiring on the board.

/RD must be getting low when reading the reset vector, if it isn't: You have used the wrong pin, or it's shortcut to VCC. Or, if the logic analyzer is synced to the SNES cpu clock, then you might sample the /RD signal at the wrong time, and thus won't see the periods when it gets low.

Does address 3FFCh still occur? That should be FFFCh. And don't forget that LoROM doesn't use A15, so it would be at offset 7FFCh in the memory chip.

I thought of that last night before bed. I was only using state analyzer because I was thinking the SNES was slow compared to my LA. I have the HP 1652B which has a speed of 250MHz, but since it only triggers on clock edges, I could still be missing the signal. I'll set it up in timing machine mode tonight and see if I can see the RD signal at all. I will double check the pin I have it connected to, but I looked them all over yesterday when I first had the issue.

$3FFFC doesn't happen any more (or I should say never happened), that was just a problem with my analyzer connections. I am using mode 21 on these boards so I still have A15 used.

I was thinking to try and tie the 27C322 /CS and /E to gnd and just use the mux OE to gate the ROM onto the data bus and see if that works. Right now I have both 74257s and the 27322 /OE on the same signal (1Y3 from 74139). I am thinking that reading from the ROM is the main issue, not that it's reading the wrong data.

[VIP Quality Post]

OK, so there is something funny going on. I programmed another EPROM with FF in address $00FFFC and $00FFFD, just to see if I could look it up.
I am not seeing that value at all.

In addition, the timing analysis shows that RD is being pulled low fairly regularly, in step with the clock cycle. I'm not sure why state analysis (SNES CLK) didn't show this. It could be I had something set up wrong, but it's pretty straightforward to take measurements and I am getting reasonable data (reset vector). I am not sure what is up with the irregular clock cycles. Maybe it is because I am not giving the SNES or my LA time to warm up. In any case, all the signals move on step with the clock, so it shouldn't' be an issue AFAIK.

Sorry I can't just post a .txt dump, my instrument only has printing capability. I sketched up some PCB for reading the print signal and found a library for converting to .txt or .pdf but I've been a dummy and haven't finished that before moving onto this project.

[Oziphantom]

so when it reads from RAM it gets $55 and when it reads from ROM it gets $00 thus we conclude your ROM is not getting enabled. However if the ROM was not being enabled I would expect it to act as "open bus" and hence it would hold the $55 for at least one more clock if not more ( see the Super Mario World warp credits exploit for open bus behaviour ), which makes me think something on your board is directly draining them to 0.

[VIP Quality Post]

What do you mean by "them"? Are you referencing the data bus? I am thinking if there is something shorting the bus to ground that it wouldn't be able to read the $55 from RAM anyway.

I agree that the ROM is not being enabled. I am going to try and jumper some PCB traces around to see if I can get that to make it output.

[lidnariq]

Sorry I can't just post a .txt dump, my instrument only has printing capability.

That generation of HP logic analyzers run X11 and HP/UX; you should be able to X-forward the display to another computer.

I'm not sure why state analysis (SNES CLK) didn't show this.

"SYSCK", or whatever you want to call it, isn't a useful phase relative to /RD. You'll notice in Poot36's trace from this post uses the 21.5MHz master clock instead for state analysis, and also that φ2 rises before /RD falls, and falls at the same time /RD rises.

[VIP Quality Post]

That generation of HP logic analyzers run X11 and HP/UX; you should be able to X-forward the display to another computer.

I don't think the 1652 has it. The 1660/1700 series do, but the 1652 is an earlier age.

"SYSCK", or whatever you want to call it, isn't a useful phase relative to /RD. You'll notice in Poot36's trace from this post uses the 21.5MHz master clock instead for state analysis, and also that φ2 rises before /RD falls, and falls at the same time /RD rises.

Strange. I didn't think to check that. A lot of sites reference the pin I'm on as CPU_CLOCK which is why I thought it was a good idea. I'm not sure how I'm going to probe the native clock signal since I didn't make a cart that fills all the slots, so I'd have to jig a wire under the SNES mainboard or something.

I shorted /G and /E on the ROM, leaving just the 74257 muxes as the only thing preventing the data bus from being always full of ROM data. I have the /OE for the two muxes set as /cart for now, but I'm still not reading the ROM. This is really stumping me.

[lidnariq]

Why not try powering the cart out of the SNES entirely? Provide +5, ground, tie /RD and /ROMSEL low, and measure voltages on the data bus.

(edit: Oh, I see, the 1652 only has HPIB, not ethernet)

[Oziphantom]

What do you mean by "them"? Are you referencing the data bus? I am thinking if there is something shorting the bus to ground that it wouldn't be able to read the $55 from RAM anyway.

I agree that the ROM is not being enabled. I am going to try and jumper some PCB traces around to see if I can get that to make it output.

yes the Data bus lines. Can't you hook the analyzer up to OE and check it?

[VIP Quality Post]

yes the Data bus lines. Can't you hook the analyzer up to OE and check it?

Yup, I already had it hooked up to /OE. I previously had it (322 OE) connected to /RD but you can see from the trace it is being pulled low and nothing is going on the bus. I have it grounded now and I am still not seeing anything on the bus using /CART to enable the muxes.

[VIP Quality Post]

Why not try powering the cart out of the SNES entirely? Provide +5, ground, tie /RD and /ROMSEL low, and measure voltages on the data bus.

(edit: Oh, I see, the 1652 only has HPIB, not ethernet)

Kind of a weird idea, but also makes a lot of sense. I set up my power supply and am not seeing anything (D0-D8 are all 0V)
I have /G and /E grounded. I see Vcc and Vss correctly. Q0-Q16 on ROM are 0V. The '257 have Vcc and Vss, and nothing is getting strangely hot that I can tell. I am seeing nothing on any of the bus. I programmed the EEPROM with full FF and verified that with the programmer, plus there is no need to program (state after wiping is FFFF) in the case there was some sort of error. I am drawing 7mA so the chips are doing... something?

I'm not sure why but this is really embarassing to have a trivial problem like this. There is something extremely obvious that I am missing here, it has to be, I'm not sure what else could be the issue.

[lidnariq]

Do you have a schematic? Photos of the PCB before/after assembly?

[Oziphantom]

this sounds like a point where one asks "you have checked and made sure the Data pins are soldered"

[VIP Quality Post]

Do you have a schematic? Photos of the PCB before/after assembly?

I'll post mine when I get home from work today.
I never looked at the SRAM behavior up close. I am thinking to remove the SRAM from the circuit and see what sort of behavior happens then.

this sounds like a point where one asks "you have checked and made sure the Data pins are soldered"