Troed's H4 build

[troed]

Do you remove the osc from MB and put it on your board and add a 64Mhz as well?

Yes - they're routed through the GAL to make sure the other clocks get the right values. The 32MHZ osc on the board goes directly to the Shifter (well, through a resistor, but) so needs to be removed.

edit: 5 PCBs now ordered from Eurocircuits. Never used them before.

edit2: Maybe it's not obvious why I have both 64 and 32 since one can be gotten from the other. It's easy - on my own board these are 64.000 and 32.0084988 - since I want exact ST compatibility.

/Troed

[troed]

doubleST_board.JPG

It's a thing of beauty. It's not working though - I've gotten the HDMI Shifter to go to green led a few times (meaning: TOS has run some instructions) but that's it. Been scratching my head a bit this evening as to how to figure out what's the problem.

I have seen something weird though. The GAL is in full control of the clocks, but somehow probes being connected or not to it might cause GLUE to become inverted (clock hi/lo) compared to CPU. That's sort of impossible, IMHO, but it is what the LA shows.

I have used PLCC versions of the MMU and GLUE on the H4, whereas on the old doubleST I had the SMD versions. I might decide to swap those in here as well just to make sure that's not a problem source. (edit: They're not during this testing though, currently I run everything at stock speeds - just through the mod board)

/Troed

[troed]

Still confused. It looks like DTACK is noisy (also incoming), and even though there's 33Ohm on all clocks I get different behaviour with the probes attached so obviously some capacitance should be added.

(This is all running at stock speeds, just using the GAL to generate the clocks, and routing DTACK passthrough)

weeee.JPG

[exxos]

(This is all running at stock speeds, just using the GAL to generate the clocks, and routing DTACK passthrough)

What clocks are you generating exactly with the GAL ?

[troed]

What clocks are you generating exactly with the GAL ?

Shifter, MMU, CPU, GLUE and MFP

In stock mode, the 32.08 MHz clock is passed directly from the input pin to the clk pin of the GAL (non-registered) and that's then used to create 16MHz, 8MHz, 8MHz and 4MHz.

I think these are all fine, what looks strange is DTACK. That's just the bodge wired removed and wired up to the board so not sure why it would be noisy. Could be an LA artifact but since the behaviour does mimic DTACK issues ...

I'm using the jumpers on the board to output all the clocks, and those have 33OHm resistors between the jumper and the IC, except for Shifter where I have a 33Ohm on the board.

The last GAL I ran on the old doubleST was a 20V8 so it might be possible there are subtle differences to the 22V10 which I don't know I'm stumbling upon.

[exxos]

What clocks are you generating exactly with the GAL ?

Shifter, MMU, CPU, GLUE and MFP

In stock mode, the 32.08 MHz clock is passed directly from the input pin to the clk pin of the GAL (non-registered) and that's then used to create 16MHz, 8MHz, 8MHz and 4MHz.

You can't do that.. With MMU and GLUE generating its own clocks, it will be all out of sync. Its bad enough fighting the wakeup states (clocks all have random skews) but your going to be doubling that problem if not using the original clocks.

[troed]

You can't do that.. With MMU and GLUE generating its own clocks, it will be all out of sync. Its bad enough fighting the wakeup states (clocks all have random skews) but your going to be doubling that problem if not using the original clocks.

No no, this is how it must be done (and how my working doubleST did it). GLUE only generates 2MHz, that can be disregarded. The GAL syncs the clocks just fine.

Reason for doing it like this is that when going from stock speeds to doubled speeds for _some_ but not all chips the original clock creation cannot be used.

All I'm doing now is recreating what I had running on an STF on the H4 instead. I'm sure that can be done. Once it is up and running I'll look into if I can replicate non-booting wakestates.

[exxos]

The MMU outputs 8MHz from the 32MHz input, which then becomes 16Mhz which should feed the CPU. You then downclock the 4MHz (now 8Mhz) for the MFP and run the GLUE from the 4MHz MMU clock which then becomes 8MHz for the GLUE.

If you start with 32MHz and downclock with a GAL to 8Mhz, it shouldn't (and cant) always be in sync with the 8MHz from the MMU because the FF's are not reset in the MMU.. This means the MMU can be out of sync with the CPU.. its depends on wakeup states.. if you are seeing it in sync, then your machine must just happen to have a wakeup mode which just happens to match the GAL clock. Normally leave the machine off 10mins and power back up and things *should* go out of sync.. but depends on what wakeup state the MMU favours on powering up.

[troed]

If you start with 32MHz and downclock with a GAL to 8Mhz, it shouldn't (and cant) always be in sync with the 8MHz from the MMU because the FF's are not reset in the MMU.. This means the MMU can be out of sync with the CPU..

There's no 8MHz from the MMU to not be in sync with since it's not being used. All ICs are clocked from the GAL, and that's how they can be made to be in sync regardless of boosted mode or not.

[exxos]

There's no 8MHz from the MMU to not be in sync with since it's not being used. All ICs are clocked from the GAL, and that's how they can be made to be in sync regardless of boosted mode or not.

I'm really talking about internal functions in the MMU itself... If anything internally is clocked from its own 8MHz then if you provide a external 8MHz clock, it can malfunction as they may never be in sync. Of course as the exact internals are somewhat unknown, this could be either way. But I think it is better not to make the assumption that the MMU only uses the 16Mhz clock input for internal operations.