MX8330 and MX9911

[Yohko]

I have a PAL N64 (NUS-CPU (P)-01) which has a MX8330 for U15 but a MX9911 for U7. I tried the Direct VLCK method (DENC-NUS) and lifted pin 1 on U7 (MX911) and connected the pad to Xtal (pin 16 on DENC-NUS is connected to FSEL). However this doesn't give any Video/Audio. Neither Composite/S-Video/RGB or HDMI (have an additional N64Digital installed). Putting pin 1 on U7 back restores all video signals. PAL and NTSC games boot and seem to run under 50 or 60Hz (according to N64Digital). Composite is in color (via RT5x). Lifting Pin 1 on U7 and bridging the jumper on the N64Digital also works. However here composite is then in black and white. I didn't try and connected stall to the pin 1 pad and have the jumper on the N64digital closed at the same time as that probably will also cause a crash? Any thoughts on this?

[jago85]

Hi,

hm, I do have some thouhgts. But it's not totally clear to me.

The MX9911 should not make a difference. It's the same as the MX8330 but has no output on pin 3. When lifting pin 1, the chip has no influence to the video clock.

Did you close JP1 on UltraPIF for the Direct VCLK method?

As far as I know, the N64Digital does not work with the clock directly from the UltraPIF. I think it's putting too much load an the line or has too high termination/damping resistance. But I cannot test it, because I don't have one.

Did you test with the N64Digital disconnected? If it doesn't work, maybe the UltraPIF clock output has an issue.

Do you have a scope to meassure the clock?

Did you try the Standard VCLK method? I cannot test this too, becaus I have no MX9911 here.

[Yohko]

I have JP1 closed. But I never tried the standard method (as I didn't want to remove any parts). Pin1 is lifted and the N64Digital JP on the flex is closed. I got basically the same issue now on an NTSC (US) N64 with the two MX8330. In both cases I ended up using the N64Digital for the clock. I don't have a scope here but I eventually can try and disconnect the N64Digital and connect the UltraPif to Pin1 and see if it works again. Its not that 50/60Hz doesn't work, just that the N64Digital has to be connected to Pin1 instead.

[Yohko]

I did some work on the NTSC-US N64 today and did some tests again. (1) N64digital disconnected (only the flex is still attached to the RCP, jp1 on flex is open), Direct VLCK method with Ultrapif (jp1 on ultrapif is closed, xtal connected to pin1 pad on board, pin 1 lifted and disconnected): no picture (composite) (2) same as above but N64digital attached: no picture (3) xtal disconnected from pin1 pad, jp1 on N64digital closed: picture for composite as well as RGB and HDMI from N64digital. PAL composite is black and white and flickers as expected. Everything else looks good.

In all three scenarios (1-3) doing boot up LD2 on ultrapif flashes and the power led cycles through the colors.

Edit: the Xtal wire was as short as possible. But the N64digital equivalent wire is much longer and there it works without any problems.

[jago85]

Everything you wrote sounds done right. Maybe there really is something wrong with the UltraPIF / the clock gen. Hard to tell without having it here and without the ability to measure something.

I did some tests today. I disconnected the XTAL signal on both installation methods. With the Direct VCLK method the N64 is stuck after boot. LD2 doesn't flash and the power LED doesn't cycle through the colors. With the Standard Method LD2 flashes and the power LED cycles but everything is slightly slower than normal. This is because the MX8330 outputs some clock even if there is no input. So I think there must be some clock on your VCLK. Maybe not the right frequency. Can you tell if the power LED color cycling is slower when the clock comes from the UltraPIF? When you then disconnect the clock completely the N64 should stop after boot. (Just to verify that there really isn't anything connected to the clock.)

I don't have any really good ideas now. Maybe you could do some continuity checks.

The wire from XTAL should have continuity to pin 9 on UltraPIF U1.

Maybe the FPGA has no connection to JP1 and thus cannot read that it is closed. If JP1 is closed there should be continuity between GND and pin 64 of U2.

I have no clue at the moment. But as long as the N64Digital isn't working with the clock from the UltraPIF you cannot use the Direct VCLK method anyway. Eighter you keep using the N64Digital's VCLK or you try the Standard Method. (The N64Digital's clock will work without the removed parts, too.)

[Yohko]

During the last few years I have now installed the UltraPIF in several systems with UltraHDMI, N64Digital, and GEM. If I don't want to use the "Standard VCLK method" (as I don't want to remove components) then only direct VLCK with JP1 closed, but no wires connected from XTAL to Pin1 will work. FSEL connected to the encoder if I wanted to fix the composite (on a compatible encoder). Others came to the same result. Standard method seems to work but then the HDMI mod looses its functionality to switch the clk. With direct mode it's the other way around (if UltraPIF is not connected to Pin 1, else back picture, e.g. real direct mode is still broken with HDMI mods). Did you look into this further and maybe tested this with a HDMI mod yourself (e.g. if direct mode can be made functional?

If only one mod will be able to control the CLK then this is probably how it's supposed to be, e.g. Standard mode if Ultrapif should control it, JP1 closed (but not wired up) if HDMI mod is controlling it.

[jago85]

I'm not sure if I understand everything correctly. Please allow me this question: You don't happen to speak German, do you? Your name sounds like you could be German. No problem if that's not the case. It would just be easier for me to understand and explain the complicated things.

only direct VLCK with JP1 closed, but no wires connected from XTAL to Pin1 will work.

Which JP1 do you mean: UltraPIF or N64Digital? If you don't connect XTAL, it is useless to close JP1 on UltraPIF. If you use the clock from the HDMI mod JP1 on the UltraPIF is a Don't Care. XTAL is left unconnected.

Standard method seems to work but then the HDMI mod looses its functionality to switch the clk.

Of course, when using the clock from the console it's impossible to use it from the HDMI mod at the same time. If you are using Direct VCLK from UltraPIF you will lose that feature, too. You always have to decide where the clock should come from. But if you have an UltraPIF, I don't see the point of using the HDMI mod to generate that clock. (Except for the fact it doesn't work any other way for some reason).

With direct mode it's the other way around (if UltraPIF is not connected to Pin 1, else back picture, e.g. real direct mode is still broken with HDMI mods).

I don't fully understand this. With direct mode, you mean the HDMI mod driving this clock? From the UltraPIF's point of view, this is not a mode at all. It is simply unused. And yes, it cannot control the clock in this case. As said, you have to make a decision.

If only one mod will be able to control the CLK then this is probably how it's supposed to be, e.g. Standard mode if UltraPIF should control it, JP1 closed (but not wired up) if HDMI mod is controlling it.

As said before, when using the clock from HDMI mod the setup of JP1 on UltraPIF doesn't play a rule. Or did you mean JP1 of the N64Digital?

Did you look into this further and maybe tested this with a HDMI mod yourself?

I have several mods based on CPLD or FPGA using that clock. N64 Advanced v2 (HDMI mod), N64 Advanced v1 (RGB mod), N64 RGB mods from F_L_a_S_H. Everything works without problems, regardless of whether the VCLK is output from the MX chip or directly from UltraPIF. I have just tried it with 3 different consoles.

I got reported the N64Digital not liking the VCLK from UltraPIF years ago. I increased the drive strength of the SI5351A (which is generating the clock) to the maximum. It then worked if I remember correctly.

I probably won't have an N64Digital or Retro GEM unless one is made available to me. (It would also be possible to swap an HDMI mod for say 2 UltraPIFs if the devs are interested in a test system with an UltraPIF.) One thing I've done differently is to connect everything via individual wires. I'm not using flex cables as I only have experimental setups here. My wiring looks rather messy and yet it works fine. So my assumption remains that the clock signal may be too strongly attenuated by a resistor in the flex cable or some other component. As long as no one can measure the signal with an oscilloscope as it arrives at the HDMI mod, I have no new ideas.

[jago85]

Can you follow how the clock line runs from the N64 board to the FPGA of the HDMI mod? Through any resistors? I can see there is at least one resistor on the flex cable where the clock goes through. But I don't know where the signal ends on the FPGA. Is there a termination on the HDMI board? Any R-C combination or something?

You could also try connecting the clock from the UltraPIF to the HDMI board with a dedicated wire. You could also try using an additional separate GND wire with the clock.