Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: TheMagicM on November 19, 2004, 02:03:40 AM
-
No updates for quite some time. Would you buy one? If so, how much would you be willing to pay?
Me..yea I would. I'd pay up to $400-$450..why? dunno..cause nobody has one and because it has USB, memory, sound etc..
-
I would buy around that price point myself. I would rather have one than a A1XE or PeGII. Would be fun to try and get toaster/flyer running on it.
-
I sincerely hope not.
Whats the sketch, Oli?
-
Unfortunately, Coldfire isnt 100% compatible with the 68Ks. It misses some key stuff that the AmigaOSs have been using for quite a while.
samuar
-
Samuar wrote:
Unfortunately, Coldfire isnt 100% compatible with the 68Ks. It misses some key stuff that the AmigaOSs have been using for quite a while.
The coldfire project they were referring to had a little ROM that emulated the missing instructions. It's not that hard to add them in since I believe that the missing instructions cause an exception which the emulator can trap to execute the equivalent instructions.
-
I really hope it is not dead....
I wouldnt mind have a powered Amiga 4000. :-D Though $400 is kinda pricy, I would be willing to pay for it. :-D :-)
-
But in terms of speed, just imagine what the SDram would do to your A4000 comnpared to the PPC Cyberstorm with EDO or Simm modules :-D
-
Well Oli is still around, he is posting on the Vulcan website about that one that got sold on Ebay.
-
Coldfire V4 & V5 have an ability to fully emulate 68k opcodes... But only AT THE FIRST SIGHT. No provisions made to emulate 64-bit mul, 64-bit div and division with remainder instructions (coldfire just won't trap on them and will make rubbish), so virtually every piece of real amiga code will fail on coldfire.
The overall JIT emualtion as well as other methods of workaround for this bug will make coldfire totally uneffective when compared even with 060.
So the coldfire accelerators "suck and must die" =)
-
lordv wrote:
Coldfire V5 has an ability to fully emulate 68k opcodes... But only AT THE FIRST SIGHT. No provisions made to emulate 32-bit muls and mulu instructions (coldfire just won't trap on them and will make rubbish), so virtually every piece of real amiga code will fail on coldfire.
The overall JIT emualtion as well as other methods of workaround for this bug will make coldfire totally uneffective when compared even with 060.
So the coldfire accelerators "suck and must die" =)
It would probably work out better to build the emulator around an XScale, and then run a 68k JIT on that.
-
lordv wrote:
Coldfire V4 & V5 have an ability to fully emulate 68k opcodes... But only AT THE FIRST SIGHT. No provisions made to emulate 64-bit mul, 64-bit div and division with remainder instructions (coldfire just won't trap on them and will make rubbish), so virtually every piece of real amiga code will fail on coldfire.
The overall JIT emualtion as well as other methods of workaround for this bug will make coldfire totally uneffective when compared even with 060.
So the coldfire accelerators "suck and must die" =)
As far as I understand, there is also a software-bit to the ColdFusion accelerators. There will be somekind of emulation made in software (on a ROM on the board) that will take care of this.
This would probably just take care of the normal 68000-instructions, though, I don't know if FPU-instructions will be supported aswell.
-
how much faster is the coldfire then a 060? What is the actual processor used? (ie. 68060, 68030 etc etc..do they have a # for it? or is it called "coldfire" )
Is it faster then a PPC g3/g4?
-Alex
-
The Coldfire CPUs are classified as V3, V4, etc.
They are pretty fast, comparable to the 060 IIRC, but most of them don't have MMU or FPU. The major advantage is that they are availible in speeds up to 200+ MHz, and that they can use "modern" SDRAM.
They are semi-compatible with the 68k-series, and there are tools both for making 68k-software run on them. They are also cheaper than the 68ks, as they are produced in much larger quantities.
-
Still I would want one, because it would mean that I could stick even longer to my classic systems. I also like the PPC upgrades, but somehow I do not favor the A1 or PegasosII .... even though they are much faster and modern and can work with OS4 ...
-
>As far as I understand, there is also a software-bit to the
>ColdFusion accelerators. There will be somekind of emulation
>made in software (on a ROM on the board) that will take care
>of this.
The "emulation" would be very very similar in concept to 68040.library or 68060.library. In fact, it's the exact same concept, but will probably need to trap and emulate more instructions than those libraries did. If they put it on the board and not in a file on disk, I sure hope they use a nice FLASH that can easily be rewritten with bugfixes and performance improvements.
-
billt wrote:
>As far as I understand, there is also a software-bit to the
>ColdFusion accelerators. There will be somekind of emulation
>made in software (on a ROM on the board) that will take care
>of this.
The "emulation" would be very very similar in concept to 68040.library or 68060.library. In fact, it's the exact same concept, but will probably need to trap and emulate more instructions than those libraries did. If they put it on the board and not in a file on disk, I sure hope they use a nice FLASH that can easily be rewritten with bugfixes and performance improvements.
If the Coldfire doesn't trap 32-bit muls and mulu instructions then there is no way it could ever run Amiga software without something like a JIT... in which case using a modern RISC would be a better idea.
-
A Coldfire board for the Amiga is very possible. Since the 4e core Coldfire chips are more compatible with the 68K series it's more feasable than ever.
However, there are some things that present a problem with the ColdFusion project.
1. Someone with no engineering background isn't likely to be successful their first time out.
2. You either have to emulate the 68K CPU entirely in software to use the existing ROMs or you have to rewrite at least a portion of the ROMs.
Full emulation of the 68K CPU isn't any better on a Coldfire than on a Pentium so why not just run an emulator on a PC?
Rewriting part of the ROM would let most instructions execute natively and instructions not supported by the Coldfire could be emulated by illegal instruction traps. There are some instructions that CAN'T be emulated (see old threads if you want to know why).
This is NOT like the 68060.library!!!! Yes, the 68060 library uses instruction traps... in that way they are the same. But the current Amiga ROMs would fail within the first few instructions and you'd never get to load a 56xxx library.
The exec needs rewritten so that it is totally Coldfire safe and it needs to have the illegal instruction handler integrated into the exec. Since the exec also uses timers, that should also be made coldfire safe. After that the instruction traps would take care of MOST incompatibilities. Some hardware drivers might need a rewrite as well.
The best way I know how to do this and use the existing ROMs would be to have the accellerator start in it's own FLASH memory, copy the old Kickstart ROM to RAM (executes faster there anyway), patch it, remap the RAM to overlay the old ROMs (disable writes to the RAM while it's at it) and then reset to start the ROM image. Like kickstart on an Amiga 1000 but with an additional step.
As time goes on more patches could be added or the entire ROM could be replaced.
The Coldfire CPUs handle non-floating point math the same as the 68K with minor exceptions which can be worked around with patches. Replace the incompatible multiply & divide instructions with illegal ones that can be trapped and original behavior emulated.
The floating point math is WAY different and a new floating point library would need to be written.
And most importantly... if it won't run on a 68060... it probably won't run on a Coldfire.
-
Well, I hope Oliver can make this work. Such a card would be the only way I'd ever invest in Amiga hardware again... :-(
-
Hi,
No updates for quite some time
Yep, im lazy, I did buy a new snazzy website which I intend to do sometime.. but I havent.
Im putting the finishes to a new prototype design.. why? well the current design should work (well I think it should) but it doesnt, so the new card is stripped down to the basics and has a socketed Coldfire, this should help me get the thing working.
I also have an A2K design finished which I will get printed but its a very basic design.
As for updating the website, yes I should do that, I really should do that......
-
> If the Coldfire doesn't trap 32-bit muls and mulu instructions
Does it fail, or are you "if-ing" about hypothetical stuff? Id think that in trapping an instruction it doesn't have implemented, it wouldn't say anything about afew certain functions like muls or mulu being non-implemented but not allowed to trap...
Does it not just say "I don't implement that instruction, I don't care what it is, just trap it." ???
-
[/quote]Does it fail, or are you "if-ing" about hypothetical stuff? Id think that in trapping an instruction it doesn't have implemented, it wouldn't say anything about afew certain functions like muls or mulu being non-implemented but not allowed to trap...
Everybody doubting please go to the freescale.com (former motorola) and find 68k software emulation library for coldfire, where it is written, that coldfire JUST WON'T TRAP on 32x32->64 mul, 64/32->32 div and 32/32->32:32 div instructions! Because they differ only slightly from 32x32->32 and 32/32->32, which coldfire supports. And coldfire just won't see any difference and execute them as 32x32->32 or 32/32->32. Unlike the 060, which will trap anyway.
This is a serious bug preventing virtually any 020+ program from correct executing. There are several workarounds, like a total JIT-emu of 68k code or hell MMU stuff like examining every codepage it's going to execute and see if there are such muls, but overall it will make coldfire even slower than 060.
FPU is also a pain, which probably won't work correctly anyway.
-
If the Coldfire doesn't trap 32-bit muls and mulu instructions then there is no way it could ever run Amiga software without something like a JIT... in which case using a modern RISC would be a better idea.
Yes, you're right. A g4-only accel card will be enough for everybody (whoops! :). fast g4 (1ghz) could fully emulate 68k at the rough speed of 040 or 060 when no JITting. With JIT it will become the fastest 68k ever seen :) And you still have conventional amiga, not the pc-like monster (pegosos or amigaone, whose the only difference from pc is the powerpc processor). Optionally you can have on such an accel modern single-chip videocard (I don't understand why I could ever wish geforce4 on my amiga!).
-
About the lack of FPU, the Apollo 68060/75 Mhz also lacked an FPU but besides programs that needed it, the card was lightning fast, not ?
-
lordv wrote:
Yes, you're right. A g4-only accel card will be enough for everybody (whoops! :). fast g4 (1ghz) could fully emulate 68k at the rough speed of 040 or 060 when no JITting. With JIT it will become the fastest 68k ever seen :) And you still have conventional amiga, not the pc-like monster (pegosos or amigaone, whose the only difference from pc is the powerpc processor). Optionally you can have on such an accel modern single-chip videocard (I don't understand why I could ever wish geforce4 on my amiga!).
Actually, I have to point out that running interpritevly, the 680x0 emulation in OS4 is quite capable of reaching the same level performance on my 603e as the real 68040 on the same card. Naturally the actual performance depends on the task at hand - some oerations are considerably slower, others faster.
-
by bloodline on 2004/11/19 10:30:41
Well Oli is still around, he is posting on the Vulcan website about that one that got sold on Ebay.
probably i haven't understood well but . . . what "about that one that got sold on Ebay"
Ciao
-
probably i haven't understood well but . . . what "about that one that got sold on Ebay"
Ebay link to Vulcan (http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&rd=1&item=5530699633)
-
I didn't realize that they had changes somewhat the results of certain instructions. That can make it more difficult than just being able to trap everything. But I doubt it's impossible. Come on, we've got the Amiga background, a tradition of doing the unnecessary, the bizarre, and the nigh-impossible.
No, it may not be easy, but if we all wanted to take the easy route we'd all be Windows users right now, wouldn't we?
-
I didn't realize that they had changes somewhat the results of certain instructions. That can make it more difficult than just being able to trap everything. But I doubt it's impossible. Come on, we've got the Amiga background, a tradition of doing the unnecessary, the bizarre, and the nigh-impossible.
For what is it worth to do impossible things with coldfire? It can't fully emulate 68k by trapping everything, so the only way is JITting. Then, JITting is more effective on ppc-g4/g5/soon. Exhaustively enough? =)
-
Actually, JIT mechanism for 68K on coldfire need not be more complex than HP's Dynamo mechanism. That is effectively a hotspot JIT emulating the actual same CPU it is running on and gets faster performance due to various runtime optimisations that arent possible to make at compile time.
Like Dynamo, a JIT 680x0 on coldifre implementation has the benefit that most of the instructions would need no translation - you only need to worry about branch offsets that change as a result of expanding some code "inline", like your unimplemented 680x0 instructions.
-
Actually, JIT mechanism for 68K on coldfire need not be more complex than HP's Dynamo mechanism. That is effectively a hotspot JIT emulating the actual same CPU it is running on and gets faster performance due to various runtime optimisations that arent possible to make at compile time.
Like Dynamo, a JIT 680x0 on coldifre implementation has the benefit that most of the instructions would need no translation - you only need to worry about branch offsets that change as a result of expanding some code "inline", like your unimplemented 680x0 instructions.
Don't know anything 'bout dynamo (maybe some urls?), but with coldfire it's not that easy.
Just imagine - you have all regs filled with data and you must JIT-emulate add.w d1,d2. No stack push/pops are allowed by definition, flags must be also set correctly. The same but to a greater extent goes to mulu.l d1,d2:d3 or smth similar.
That's why I'm saying about g4/g5 JIT emulator as an accelerator for amiga. Unfortunately I have no needed knowledge to do such thing by myself.
-
Dynamo is a dynamic recompilation engine for HP PA8000, running on he HP PA8000.
It blows away the arguments against register allocation and so on. It is a hotspot JIT (ie mostly interpretation which in this case translates into just executing the code as is) that simply optimises away loops, conditional branches etc. at runtime.
See here (http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html)
The concept is equally applicable to any CPU. If you imagine the coldfire as a 68K, it will simply operate by running the code as is until it encounters a trap triggered by an unimplemented instruction. This will invoke the recompilation stage for that part, which can expand inline into a sequence of instructions to achieve the same end and then saved out into the JIT cache. You will just have to push any registers you clobber at the start of the expansion and pop them at the end (not neccessarily to the system stack, but a reserved area that is part of the JIT engine). You make sure the last thing you pop are the cc/sr (and modify them as required). It really isn't any different to the dynamo case - they are optimising away expensive loops etc, the coldfire system would be optimising away the unimplemented instructions. 99% of the time, you'd just be executing coldfire compatible 68K code, the remainder would be actually doing the transcription where needed.
-
But karlos... the coldfire isn't going to trap the 32bit mul, it's just going to return the wrong result.
Also, if one were to go the JIT route... then I would prefer an XScale rather than a G4, as the ARM uses less power and generates less heat and is much cheaper!
-
But Matt, the beauty of the dynamo approach is that you can trap any instruction you want. You dont need to rely on hardware exceptions - all code blocks are analysed before 'interpetation' (which means execution in this case) ;-)
Simply put, dynamo is the only emulation strategy that acutally outperforms the the cpu it is emulating *on that cpu*! :-D
It runs PA8000 code on a PA8000 up to 25% faster than the PA8000 does by itself. Read the article to see why ;-)
-
Yeah I know about dynamo :-)
I see what you mean, the JIT can catch the erroneous instructions rather than the CPU... but personally... if we are going the JIT route... I wanna use an XScale :-p
-
Fair enough, but *if* Oli's coldfire hardware takes off, you have to admit it would be a killer way to emulate the 680x0 on it :-D
-
@Karlos
Dynamo is a dynamic recompilation engine for HP PA8000, running on he HP PA8000.
It blows away the arguments against register allocation and so on. It is a hotspot JIT (ie mostly interpretation which in this case translates into just executing the code as is) that simply optimises away loops, conditional branches etc. at runtime.
Ok, now it's clear. It works as any other JITter - first runs code interpretive, then taking some fragments, generating for them new code fragments in an isolated buffer and running them from there instead of interpreting original code. In such a manner it could perform on coldfire as well (for a system-wide code fragments). BUT! - when doing so, it would be more effective to use G4/G5 - because they're significantly faster, having more registers (JIT is easier), at last have ability to run warpup/powerup applications natively.
-
@bloodline
But karlos... the coldfire isn't going to trap the 32bit mul, it's just going to return the wrong result.
Even the standard 040/060-like OXYpatcher method isn't applicable for coldfire, because OXYpatcher replaces every unsupported command with jsr -xxx.w, which takes 2 words and fits perfectly into any unsupported command. But when we have unsupported add.w d1,d2... Nothing except trapping possible. The unrecognized mulu.l commands do even worse - preventing coldfire from direct (trapped) execution of 68k code.
Also, if one were to go the JIT route... then I would prefer an XScale rather than a G4, as the ARM uses less power and generates less heat and is much cheaper!
Does it have altivec-like features? How faster is it over existing G4/G5 processors? How do you manage to support 'legacy' powerup/warpup applications with it?
-
@lordv
Agreed but it isn't quite like any old JIT in that it has a much smaller transcription overhead than other JIT since the majority of any code is simply pased through the translation stage unchanged - in fact, in many cases blocks that contain no unimplemented instructions do not need to be copied at all, simply referenced.
However that is not the issue here. The topic is about the existing coldfire project and the problems it faces - I'm just trying to suggest solutions to those problems.
A G4/G5 card would be great, but then there is absolutely no reason not to use MOS/OS4 on those systems instead since that will be even faster than a pure 680x0 emulation of OS3.x (by virtue of having the native OS / driver resources).
-
From skimming the Coldfire docs and reading the information about CF68KLib (the 68K emulation library for Coldfire that traps the exceptions for the missing instructions), I see no reason to believe that the 32 x 32 -> 64 multiply wouldn't generate an exception. It's not like they replaced it with a 32 x 32 -> 32 multiply since that already existed on the 68k and I don't see any evidence (though perhaps I'm looking in the wrong place) to suggest that they remapped the 32 x 32 -> 64 multiplies onto the 32 x 32 -> 32 multiplies (especially since it would do little but screw up attempts to run 680x0 software on the chip while adding to the complexity of the instruction decoding logic). The CF68KLib documentation doesn't suggest that the 32 x 32 -> 64 multiplies are a problem (though there are other problems, like MULU and MULS not setting the overflow bit).
-
http://www.microapl.co.uk/Porting/ColdFire/FAQCF68KLib.html
"A lot of code can be run without any changes, since CF68KLib includes handlers to emulate all missing 680x0, CPU32 and CPU32+ instructions. However, there are a few special cases where an instruction behaves slightly differently under ColdFire and which the emulation library cannot automatically correct. The most important of these are:
MULU and MULS instructions executed on ColdFire do not set the overflow flag. Because these are legal ColdFire instructions, with the same opcodes as the 680x0 equivalents, no exception is generated and the CF68KLib handler will therefore not be called. If the original code depends on multiply setting the overflow flag, it will need to be patched or modified to run correctly.
Certain variants of the divide instructions DIVS.L and DIVU.L behave differently under ColdFire.
MOVE.B ,-(A7) and MOVE.B (A7)+, change the stack pointer by one byte on ColdFire instead of 2 bytes as on the 680x0.
An instruction such as MOVE.L (A7)+,(A0,D0.W) is not legal in ColdFire because word-length displacements are not supported. Although the ColdFire processor will take an exception for this instruction, it does so only after incrementing the stack pointer, and so the exception stack frame overwrites the data to be restored. As a result, it is impossible for CF68KLib to reproduce the correct behavior. "
-
MULU and MULS instructions executed on ColdFire do not set the overflow flag. Because these are legal ColdFire instructions, with the same opcodes as the 680x0 equivalents, no exception is generated and the CF68KLib handler will therefore not be called. If the original code depends on multiply setting the overflow flag, it will need to be patched or modified to run correctly.
Certain variants of the divide instructions DIVS.L and DIVU.L behave differently under ColdFire.
Not quite right. See here for details.
http://www.microapl.co.uk/Porting/ColdFire/Download/CF68KLib.pdf
"The most significant difference between ColdFire and 680x0 is that some of the
multiply/divide instructions introduced with the 68020 do not behave the same
and do not cause an exception. The following instructions are affected:
MULS.L ,Dh:Dl (Signed multiply: 32x32 -> 64)
MULU.L ,Dh:Dl (Unsigned multiply: 32x32 -> 64)
DIVS.L ,Dr:Dq (Signed divide: 64/32 -> 32r:32q)
DIVSL.L ,Dr:Dq (Signed divide: 32/32 -> 32r:32q)
DIVU.L ,Dr:Dq (Unsigned divide: 64/32 -> 32r:32q)
DIVUL.L ,Dr:Dq (Unsigned divide: 32/32 -> 32r:32q)"
Then go to freescale.com and see CFPRM.pdf (coldfire programmers reference manual). There are NO 64bit mul/divs.
So "they behave differently" means "they just generate rubbish"!
-
@Karlos
Agreed but it isn't quite like any old JIT in that it has a much smaller transcription overhead than other JIT since the majority of any code is simply pased through the translation stage unchanged - in fact, in many cases blocks that contain no unimplemented instructions do not need to be copied at all, simply referenced.
But you can't modify the original codem because it can rely on itself in an unpredictable manner! (I think it's obvious! :). So anyway mainloop is emulation and JITting of frequently-used parts.
A G4/G5 card would be great, but then there is absolutely no reason not to use MOS/OS4 on those systems instead since that will be even faster than a pure 680x0 emulation of OS3.x (by virtue of having the native OS / driver resources).
There IS reason not to use mos/os4. os3.1 is freely available to you as amiga user, while mos and os4 were made especially for some ppc workstations (wrongly called as new 'amigas'). Neither firm will release them for g4 amiga accelerator, because it will lead to decreasing of their sales.
-
:crazy:
This discusstion has turned waaay too technical for me.
-
@lordv
To be honest I think we are talking about crossed purposes.
All I am saying is that for a coldfire based solution, the dynamo style JIT would be the best way to go for highest performance 680x0 emulation.
I didn't say it was perfect, but it is a lot better than the average JIT in terms of efficiency. Again, the whole point I am suggesting it is because the topic is about the coldfire and not PPC/XScale.
Obviously if someone released a CPU card powered by an x86/PPC/XScale etc. you would have to employ a conventional JIT approach. If, on the other hand, you are using a coldfire, you can use a dynamo style JIT (which is not fully applicable to a CPU with a totally different instruction set) which is proven more effective for the specific case of emulating like on like.
@Whabang
Dont worry, most of it is academic argument - unless someone does release a G4/G5 card for the classic :-D
-
Karlos wrote:
@Whabang
Dont worry, most of it is academic argument - unless someone does release a G4/G5 card for the classic :-D
Or an XScale card :-D
Imagine a Trapdoor connector with an FPGA to convert the ZII (A1200 trapdoor) bus signals (and generate an interupt) to one of the hi-speed serial interfaces (Hirose DF12C(3.0)60DS0.5V80 or NSSP?) for a gumstix computer...
(http://www.linuxdevices.com/files/misc/gumstix-thm.jpg)Gumstix Board (http://www.gumstix.com/index.html)
That would be a cool A1200 Acelerator...
-
bloodline wrote:
Or an XScale card :-D
Or an XScale card.
What about an Athlon64 card running a JIT emulation? For tower systems only of course. You get the benefit of decent off the shelf controllers for memory, AGP, IDE etc then :-)
-
Karlos wrote:
bloodline wrote:
Or an XScale card :-D
Or an XScale card.
What about an Athlon64 card running a JIT emulation? For tower systems only of course. You get the benefit of decent off the shelf controllers for memory, AGP, IDE etc then :-)
I've thought about that actually... since Free HyperTransport core are available for FPGAs...
The Athlon64 has 16 General purpose registers, which makes it ideal for 68k emulation... it's general purpose regs are 64bit, so JIT book keeping could be kept in the upper 32bits of the registers (sort of treat the 16 64bit regs as 32 32bit regs)... the CPU is REALLY fast and very cheap... it's 64bit (always a good thing :-D), it got strong Vector support (MMX, SSE, 3DNow!), SMP is possible... oh and AROS support is there ;-).
But, the CPU is big, it's hot, it draws a huge amount of power.. it needs one hell of a heatsink... while I agree that it would be perfectly acceptable for someone with a Tower system... these people would probably be better off buying an A1/Peg or a modern PC and Running WinUAE...
The XScale on the other hand could go into a stock A1200 (or even other Amiga Models) and run with no heat, power or space issues. It should be able to far outperform the 060 , and be far more affordable...
Hell if we're using an FPGA one could even put a few nice features in there too... a Chunky buffer (+ Blitter) with a DMA to Lisa... which would allow the CPU to write chunky pixels and would convert the pixels to Planar during the screen refresh :-)
-
One reason I suggested the althon 64 was largely because it apparently dissipates a lot less heat than previous generations.
-
Karlos wrote:
One reason I suggested the althon 64 was largely because it apparently dissipates a lot less heat than previous generations.
That's true... 32Watts normal, 65Watts underload, 95 Watts max (IIRC)... but my BlizzPPC melted... and I'm sure that didn't pump out 35Watts of heat... I think that the small "British" RISC ARM CPU is better suited to the task :-D
Hell... I want an Athlon64 Accel for my A1200 now :lol:
-
How the hell did you melt your blizzppc?
I have the 040 version and it doesnt get that hot!
-
What´s the maximum speed of a coldfire anyway?
I have seen 266MHz, know any faster?
-
I think some of the v4 cores are over 400MHz already?
@Matt
Anyhow, your basic Athlon64 card would naturally have an ATX power connector and appropriate cooling :-)
-
bloodline wrote:
Karlos wrote:
One reason I suggested the althon 64 was largely because it apparently dissipates a lot less heat than previous generations.
That's true... 32Watts normal, 65Watts underload, 95 Watts max (IIRC)... but my BlizzPPC melted... and I'm sure that didn't pump out 35Watts of heat... I think that the small "British" RISC ARM CPU is better suited to the task :-D
Hell... I want an Athlon64 Accel for my A1200 now :lol:
Just put a nanoITX in a empty A1200-shell:-P
-
Karlos wrote:
How the hell did you melt your blizzppc?
I have the 040 version and it doesnt get that hot!
IIRC I have the same board as you... 25Mhz Full 040 + 240Mhz PPC... I kept it in the desktop case, with the trapdood lid off... then the fan melted... then wires melted and other things melted... I found an old 486 and used the cooler from that to cool the 040... but it was a pain in the bottie as I was moving around a lot at the tim... also taking the A1200 to gigs and stuff so I swaped my Bliz1230-IV in for increased reliability. I've not put the PPC back in since :-/
-
@bloodline
Yeah same card (I have the SCSI also, but nothing is using it atm).
That sounds far more like the result of an electrical short out in the fan to me. The current surge would be enough to melt the wires after that - they are only thin, after all.
My system now just has the heatsink on the 040 and that physically touches the case side plate (no space for a fan). There is a slimline VGA cooler added to the PPC heatsink now and although it fits in the case, I left the side off for the moment until I can drill some holes where the fan is (it is illuminated too so it might not look totally poo if done right).
-
This discusstion has turned waaay too technical for me.
LOL!! same here.. I was just wondering if they had a card ready for general release etc..
-
400Mhz, well then a Coldfire would be faster than what my pc does in UAE(6 times faster than a 060-50Mhz( or PPC-JIT on 1Ghz MOS/OS4)).
-
Dan wrote:
400Mhz, well then a Coldfire would be faster than what my pc does in UAE(6 times faster than a 060-50Mhz( or PPC-JIT on 1Ghz MOS/OS4)).
You forget about the IPC... it's not that great on the Coldfire... certainly not as good as the 060 (or the PPC or the Xscale or the Althon64 etc...)
-
bloodline wrote:
Dan wrote:
400Mhz, well then a Coldfire would be faster than what my pc does in UAE(6 times faster than a 060-50Mhz( or PPC-JIT on 1Ghz MOS/OS4)).
You forget about the IPC... it's not that great on the Coldfire... certainly not as good as the 060 (or the PPC or the Xscale or the Althon64 etc...)
I don´t know anything about that. first term java and c-programming only here.:-P
IPC=interprocess communcation?
-
Dan wrote:
bloodline wrote:
Dan wrote:
400Mhz, well then a Coldfire would be faster than what my pc does in UAE(6 times faster than a 060-50Mhz( or PPC-JIT on 1Ghz MOS/OS4)).
You forget about the IPC... it's not that great on the Coldfire... certainly not as good as the 060 (or the PPC or the Xscale or the Althon64 etc...)
I don´t know anything about that. first term java and c-programming only here.:-P
IPC=interprocess communcation?
Instructions per Cycle :-)