Overclocked dreamcast

[qatmix]

Hi All

ive done the tutorial on the Jap site and attempted to overclock my DC.

The good news, It works.

The bad news I cant actually tell the difference. kajamin, Im a bit confused aboutthe crystal, I have two types so i might swap them. I tried sega rally, and the frame rate was much better (I think).

I tried DCNeogeo (the rom emu, not the cd emu) and it was giveing a lower framerate.

Erm, confused! Kajamin are you about?

Cheers
Q

[Kamjin]

The mod is only going to speed up the CPU, but in reality that also going to speed everything up..

I'd understand if the 3D would stay the same, but the emu's should speed up. before I pop open DC to check let's start with...

What is the xtal speed your using? and what's confusing you about the xtal?

[quzar]

What I'm thinking is that if the CPU goes out of synch with the system bus, the memory will be effectively slowed down because the CPU will miss the timed calls to the memory that are needed. Even it it would speed up raw CPU calculations a bit, it would still slow down the effective speed.

The only good analogy i can think of is how if you overclock a computer CPU without regard for the multiplier and bus speed, the system could lose performance. From what I understand in some systems the system bus is not very important and keeping the CPU and ram in sync isnt either, but afaik, in the DC it is.

[Alexvrb]

First off, the only chipset I am aware of that has a real problem with out-of-sync memory is the nForce 2 (and maybe 1). But that's a case of the memory being out of sync with the FSB, not the other way around *. How can the "CPU go out of synch with the system bus" when your processor speed is FSB x multiplier?

Besides, we don't have enough info yet. I don't know how the buses in the DC derive their clockspeed, for instance. There's got to be a way to keep things in sync, even if it requires you to overclock other components.

[quzar]

[quote author=Alexvrb link=board=hardware;num=1094318646;start=0#3 date=09/04/04 at 22:10:02]First off, the only chipset I am aware of that has a real problem with out-of-sync memory is the nForce 2 (and maybe 1). But that's a case of the memory being out of sync with the FSB, not the other way around *. How can the "CPU go out of synch with the system bus" when your processor speed is FSB x multiplier?

Besides, we don't have enough info yet. I don't know how the buses in the DC derive their clockspeed, for instance. There's got to be a way to keep things in sync, even if it requires you to overclock other components.[/quote]

There are many different things you can do to manually overclock a CPU idependantly of the FSB. Like I said this was mostly a problem back in the p2/p3 era.

[Kamjin]

Actually in the case of the sh4, it's Xtal input to PLL1 to divider to PLL2 which might be gated by a Clock pulse gen unit... to SDRAM

There actually hasn't been a "system bus" in ages, in the past the CPU/RAM/ROM clock was considered the system bus, since each component has it own bus today, and each can be clocked async.. well..

There's alot of myth out there... even people who know what they're talking about, fall into the trap sometimes

for example.. what's wrong with this paragraph? when I saw this.. I thought if he only knew
"Anything else you want to do is up to how you want to design it, and what the device's requirements may be. For example, if one wanted to build a PCI bus that actually operated to spec (33MHz CLK minimum), one would need to add an oscillator for the 33MHz clock, and do some weird FIFO buffering to talk to the DC side of things. Not very simple."

Back to the topic.. the cpu to ram can't be the issue, mainly due the fact that it's actually working, since the sh4 controls the ram.. But what Quzar said was almost the same thing I though of first.. just off to the side a bit, one of my guesses is that the interface to the PVR might actually be having problems, and it's causing the slow down.. or the DC's kernal is actually smart enough to add wait states on the ram.. gotta do more spec reading before this makes sense though..

[qatmix]

its a 40 mhz crystal. the inputs are nc/c 5v GND and output

I plced the output on the mb once i lifted pin 11 and the nccc on the chip pin which I lifted. (Ive since removed that connection)

I have another 40mhz which doesnt require the ncc if thats more what I need?

[quzar]

[quote author=Kamjin link=board=hardware;num=1094318646;start=0#5 date=09/05/04 at 00:51:56]Actually in the case of the sh4, it's Xtal input to PLL1 to divider to PLL2 which might be gated by a Clock pulse gen unit... to SDRAM

There actually hasn't been a "system bus" in ages, in the past the CPU/RAM/ROM clock was considered the system bus, since each component has it own bus today, and each can be clocked async.. well..

There's alot of myth out there... *even people who know what they're talking about, fall into the trap sometimes

for example.. what's wrong with this paragraph? when I saw this.. I thought if he only knew
"Anything else you want to do is up to how you want to design it, and what the device's requirements may be. For example, if one wanted to build a PCI bus that actually operated to spec (33MHz CLK minimum), one would need to add an oscillator for the 33MHz clock, and do some weird FIFO buffering to talk to the DC side of things. Not very simple."

Back to the topic.. the cpu to ram can't be the issue, mainly due the fact that it's actually working, since the sh4 controls the ram.. But what Quzar said was almost the same thing I though of first.. just off to the side a bit, one of my guesses is that the interface to the PVR might actually be having problems, and it's causing the slow down.. or the DC's kernal is actually smart enough to add wait states on the ram.. gotta do more spec reading before this makes sense though..


[/quote]

I was just thinking something like...ok the CPU checks the ram, and every I/O device it is attached to every... lets imagine 10 cycles. when everything is working at the clock speed that is specified, then the devices will be ready at that time. If its going slightly faster, then they wont be ready till the next 10 cycle iteration.

Just tell me if that idea is wrong, or just my original statement about system bus.

[Kamjin]

[quote author=quzar link=board=hardware;num=1094318646;start=0#7 date=09/05/04 at 02:35:56]

I was just thinking something like...ok the CPU checks the ram, and every I/O device it is attached to every... lets imagine 10 cycles. when everything is working at the clock speed that is specified, then the devices will be ready at that time. If its going slightly faster, then they wont be ready till the next 10 cycle iteration.

Just tell me if that idea is wrong, or just my original statement about system bus.
[/quote]

Neither is wrong.. just the sync problem was actually a 486-P1 era thing, and then it became a myth.. my mistake.. I forgot to mention that's what I was talking about..

actually the interface to the PVR, and ARM is what I was thinking of, with the exact same thought you were having.
There's two ways of interfacing them 1st where a device in the middle handles each device asynronously, and separatly, in this case a clock change won't make a difference, the other method is by holding off one device, until the signals align. This is where the problem might be happening.

PS: PCI devices can run from DC(0Hz)-33MHz

its a 40 mhz crystal. the inputs are nc/c 5v GND and output

I plced the output on the mb once i lifted pin 11 and the nccc on the chip pin which I lifted. (Ive since removed that connection)
I have another 40mhz which doesnt require the ncc if thats more what I need?

You've got it hooked up fine.. Now there's either some sort of alignment issue, or the DC was smart enough to play with clocks and wait states..
Or another thing, take a .1uF ceramic capacitor, and solder it to the xtal from gnd.
Also trying different xtals in the 34-40Mhz range.

[qatmix]

Thanks,

looking at the webpage, (and some of my other DC motherboards). The actual chip number is different on the DC i modded. Its still labelled as the same component on the motherboard as my older DC (with the pipes). However this is a revision 1 mobo not a revision 0 which that is.

I however very much doubt that this is the issue. Kajaming does your DC have the pipes etc?

I tried disconnecting the crystal and the DC doesnt work. so that goes to show the crystal is connected and making a through signal.

I dont have the ceramic capacitor on it however. What differnce will that make? Ive also tried another different 40 mhz crystal(this one does not have a nc *on it (What is that btw?).

Is there someway that I might need to ensure that the pin is not 'arc'ing with the wire on the mobo and overriding the circuit?

Sorry for all the questions, im sooo close and I think this will be an interesting mod for all of the dc community, so Im trying to get it sorted.

Cheers
Q