Welcome, Guest. Please login or register.

Author Topic: Need explanation of the CPU and FPU technology on turbo boards  (Read 13234 times)

Description:

0 Members and 2 Guests are viewing this topic.

Offline shoggoth

  • Full Member
  • ***
  • Join Date: Dec 2004
  • Posts: 223
    • Show all replies
Quote

rkauer wrote:
Just a memo: you could NOT use a faster FPU than your CPU. If you bought a faster FPU, simply put a cristal the same clock of CPU.


Quote

kidkoala wrote:
I think it's like this: if you have a cpu@30mhz and a fpu@50mhz, then the fpu would have to wait for the cpu all the time, because it's so much faster.
it's better if they have about the same Mhz to cooperate better, meaning there's no point in having a really fast fpu if the cpu is lagging behind.


Dudes, no offence, but you have it all wrong. The FPU is faster at floating point calculations (naturally), but it still uses a lot of cycles to perform it's calculations. The CPU waits for the FPU, not the other way around. Speed up the FPU, and the CPU spends less time waiting.

This has been tested and verified on other architectures.

-- Peter
 

Offline shoggoth

  • Full Member
  • ***
  • Join Date: Dec 2004
  • Posts: 223
    • Show all replies
Re: Need explanation of the CPU and FPU technology on turbo boards
« Reply #1 on: November 27, 2006, 01:17:59 PM »
Quote

kidkoala wrote:
it's great with you're explanation to, but after hearing every meaning possible on just the matter you speak of, i'm having problems trusting anyone hehe, any kind of proof, documentation etc.? (i don't suppose you have this, it's just a question). :)


Don't wish to offend you in any way, but... It's not like you have a well defined technical reason not to believe me (prove me wrong here, and please do so with real arguments on a technical level). There's a big difference between sayong "no" because you know better, and saying "no" just because you can. In case of the former you shouldn't have a problem presenting your arguments.

Overclocking the FPU is a well known DIY hack, at least on other 68k platforms. Consider the following. The program counter resides in the CPU - not in the FPU. This means that the FPU isn't "pushing" program execution forward - the CPU is. When the CPU reaches a point where it needs data from the FPU and the FPU hasn't finished processing the current FPU instruction
, the CPU will wait. If the FPU is finished, the CPU will continue with the next instruction.

If you really need proof, consult the official docs from Motorola. Or find some tables with cycle times for FPU and CPU instructions. Do the maths.

Note that CPUs with built-in FPUs works a bit differently from the 020/030+68881/2 combo, but it's really not applicable here.

-- Peter
 

Offline shoggoth

  • Full Member
  • ***
  • Join Date: Dec 2004
  • Posts: 223
    • Show all replies
Re: Need explanation of the CPU and FPU technology on turbo boards
« Reply #2 on: November 27, 2006, 01:28:26 PM »
Ah, sorry kidkoala. I didn't realize it was you who started the thread.

1. It's asynchronous. It doesn't have to be the exact same speed. Generally it's better to have a faster FPU clock to improve the throughput.

2. Yes you can. You'll also need to get a dedicated oscillator for it, of you want it to run at some higher speeds. There is no connection between the CPU and FPU speed, hence the word "asynchronous".

3. (first part - dunno). Second part - overclock using a dedicated oscillator connected to the clock input of the FPU. The 68881/2 overclocks very well, and can often run at 2x-2.5x of the original speed.

4. Floating point stuff, naturally. Usually no games from that era uses it, and it won't speed up your workbench. Raytracers often came with FPU versions, and modern stuff can often be compiled to take advantage of FPUs.

Hack for the Atari Falcon which can probably be adapted for the Amiga:
http://atari.nvg.org/fpu/

-- Peter
 

Offline shoggoth

  • Full Member
  • ***
  • Join Date: Dec 2004
  • Posts: 223
    • Show all replies
Re: Need explanation of the CPU and FPU technology on turbo boards
« Reply #3 on: November 27, 2006, 07:03:30 PM »
Quote

but where do you get osc. of up to 100mhz?? when i bought the 33mhz one, the biggest one was at 50mhz or something..


100Mhz oscillators are rare, but they exist. I wouldn't go that high to start with. Try common ones first, say 50 and 66Mhz.

Quote

second, won't the fpu have a very shortened lifetime when overclocking it to 2-2.5x? i guess the cooling will help but anyway..


Probably, but keep it within sane temperatures and it won't be a big deal.

Quote

EDIT: just found 64mhz oscillators on amigakit, they can just be fitted? i have to activly cool the fpu itself with a standard cooler also then?


Yes. And yes. Try with a heatsink and some thermal glue first, it could be enough. Use something FPU-intensitive when testing, such as a raytracer compiled with FPU support.

Quote

what programs do i use to becnhmark this thing after being overclocked?


Dunno.

Quote

and also, how do i overclock the cpu on a sx32@030/40?
can i just replace the one i have with a 50mhz one? or should i just overclock the one i have? (i've read that you can often overclock, say a 33mhz to a higher level than a 50Mhz?


Dunno. I've used a 33MHz 030 for years at 50MHz w.o. problems. Needs a heatsink and a fan though.

-- Peter
 

Offline shoggoth

  • Full Member
  • ***
  • Join Date: Dec 2004
  • Posts: 223
    • Show all replies
Re: Need explanation of the CPU and FPU technology on turbo boards
« Reply #4 on: November 28, 2006, 12:49:47 PM »
Quote

Piru wrote:
In my experience FPU doesn't overclock very well, it'll easily begin to generate errors (this was with 33MHz chip at 50MHz).


You either got A: A bad FPU, B: an unstable clock, C: EMI trouble or D: all three.
Motorola chips from that era overclocks extremely well, especcially the 68882. Dunno about the 68881 though, but that's not an option anyway.

I've used a 33Mhz 68882 at 50Mhz for many years without cooling. No problems whatsoever - but I wouldn't be surprised if a bad clock could give the symptoms you describe.

-- Peter
 

Offline shoggoth

  • Full Member
  • ***
  • Join Date: Dec 2004
  • Posts: 223
    • Show all replies
Re: Need explanation of the CPU and FPU technology on turbo boards
« Reply #5 on: December 01, 2006, 09:55:12 AM »
Quote

DamageX wrote:
The trouble with an A500/600/1200/CD32 is that there is interleaved memory access between the CPU and chipset (unlike a PC or a Genesis) so I guess if they are running at different speeds the clock signals still have to "line up" at certain times.


Same thing on the Falcon. The solution there is to use some extra logic which switches between 32 & 16Mhz, causing it to run in 32Mhz when not accessing the bus (typically speeding up  stuff which resides in the cache and slow instructions). As soon as it access the bus, the clock is switched back to 16Mhz. Afaik both clocks must be in phase, or it won't work.

I think the same approach is used to overclock A500:s, and possible A1200:s. I may be wrong though.

Another approach on the falcon is to speed up the entire bus+cpu to 25Mhz, simply by replacing an oscillator on the mainboard. Don't know if that can be done on the Amiga without screwing up the refresh frequencies etc. for the screen? If possible, it should give a lot better performance compared to just double-clocking the CPU as I described earlier.. Well, I guess it's fairly obvious that I'm not too familiar with all aspects of Amiga hardware.. yet..

-- Peter
 

Offline shoggoth

  • Full Member
  • ***
  • Join Date: Dec 2004
  • Posts: 223
    • Show all replies
Re: Need explanation of the CPU and FPU technology on turbo boards
« Reply #6 on: December 01, 2006, 11:50:40 AM »
Quote

Piru wrote:
Overclocking the motherboard clock is out of the question as it will skew all chipset timing.


If all clocks in the system are derived from the same master clock, and you replace that master clock with something higher, I can see no reason why it shouldn't work - provided that one keeps it within a sane range.

However, since it would most probably screw up screen synchronization, baudrates, sample rates and other I/O, yeah, it's probably not a good idea... forget what I said.

-- Peter