Why Is TerribleFire 160 Times Slower Than Vampire? | page 1 2 3 4
|
---|
|
---|
| | ![](gfx/user2.gif) Gunnar von Boehn (Apollo Team Member) Posts 6214 20 Jan 2020 20:20
| ![](gfx/tf520_sysinfo.jpg) I saw this benchmark result with a very interesting discussion about the performance of the TERRIBLE FIRE 520. The performance of this accelerator is relative low. In fact its only providing a 160th fraction of the performance of a Vampire..... Lets not put this hardware down. But understanding WHY this is the case is a good exercise to understand how an 68K CPU works and what is important. Actually its relative easy to understand where the problem lies. So lets start talking about it. Can you explain the cause?
| |
| | ![](gfx/user1181.gif) A1200 Coder
Posts 74 20 Jan 2020 20:49
| Well, it's even slower than a 14 MHz 68020 running from 32-bit chip ram, so it must be all 16-bit memory? The chip ram speed is at least slow, so it's 16-bit chip ram as well. And no dcache/iburst? If these are disabled my 68030 board gets slower.
| |
| | ![](gfx/user9.gif) Igor Majstorovic (Apollo Team Member) Posts 407 20 Jan 2020 21:06
| I could try but I think that this is one of earlier prototypes not final version. As from picture shown we see that there is memory allocated in FastRam so slowdown is not there. As we know system gets power with CPU using FastRam since communication is much faster there than communication with Amiga bus. So problem here is that bus cycle to the Amiga side is not exact. To run on higher speed for example 14MHz with accessing to slow 7MHz bus you have to mimic it. This could be done in several ways: 1. By using state machine who will follow rising and falling edges of original clock. a) by using 10X higher clock and counters who will count original clock edges b) making edges from double sync of original clock and comparing their states 2. By making routine who will depend only on DTACK signal.In reality 2nd choice is possible when you don't have high speed CPU used for accelerator. 1st option and its variations is more realistic if you go over 50MHz. All of this stands for synchronous bus access. On the other hand there is also asynchronous bus access who is related to VMA,VPA and E signals where slowness could happen.
| |
| | ![](gfx/user1126.gif) Retrobrain Johnny
Posts 12 21 Jan 2020 02:05
| Edit: nevermind was thinking of TF530..
| |
| | ![](gfx/user827.gif) Nixus Minimax
Posts 416 21 Jan 2020 07:58
| Is that clock value correct? 34.4 MHz would be a very bad choice for connecting to a 14 MHz chipset bus. I also wonder whether fastmem access is somehow blocked by chipmem accesses which would turn the fastmem into slowmem. These stats are very bad for an 020 accelerator. Something must be very wrong.
| |
| | ![](gfx/user1253.gif) Andy Hearn
Posts 374 21 Jan 2020 09:49
| my understanding is that the TF520 is a first step along the way, a kind of "lets see if it works" board. it doesn't have any fast ram bar what you can supply on the 68k bus, which invariably is going to be 16bit ram requiring 2 cycles to access on a 7Mhz bus. As if i recall and understand correctly, the TF presents a 32bit ram interface in preparation for having it's own local ram. the title of the thread is a bit miss-leading, as it seems to imply that ALL terrible fires are this slow. the TF330 i have is "only" something like 15 times slower, and the 060 based cards that are being worked on at the moment are as fast as an 060 card should be that i've seen. also the aims of the two projects are different. TerribleFire is one man trying to develop some new cheap basic accelerators and make them fully open sourced, for anyone to be able to build them to put them into their own machines, or onto the amiga market that is gasping for MIPS. i'm not going to point out the differences in the goals compared to the apollo team, as i'm sure we are all well aware. a simple google would show the steps made going from the 520, to the 530, the 532, 534, 536. each one being a learning process with more ram, an IDE interface, a faster CPU clock. there was going to be a 540 with 32meg of its own ram, but that was veto'd in favour of developing an 060 card for the CD32, as it's a much simpler dev system (no need for a connector once you have a cpu slot riser). that development work then turned into a development of an 060 card for the 1200. each of which i'm sure will be released as and when the guys are happy that it's stable and good to go. even has a software modifiable cpu clock.
| |
| | ![](gfx/user2.gif) Gunnar von Boehn (Apollo Team Member) Posts 6214 21 Jan 2020 10:29
| Andy Hearn wrote:
| my understanding is that the TF520 ... doesn't have any fast ram bar what you can supply on the 68k bus, which invariably is going to be 16bit ram requiring 2 cycles to access on a 7Mhz bus.
|
The memory bus on AMIGA takes 4 cycles at 7 Mhz per WORD. 4 cycles per word is also the normal speed of the 68000.
Some examples: LENGTH CYCLES MOVEQ #1,D0 2 4 MOVE.L D1,D2 2 4 MOVE.L #$12345678,D4 6 12
From its CPU features, the MC68020 CPU at 35 MHz should in theory be over 10 times faster than an 68000 at 7 MHz. According to Sysinfo from the Factor > 10 only a factor 1.2 remains. So we see that nearly 90% of the speed of the 68020 CPU seems to got lost because of the lack of own memory. This is clearly interesting information. It shows how important memory speed is. The Sysinfo test code does also execute a number of rather slow instructions like MUL and DIV and SHIFTS in these instruction the 68020 should gain a lot more speed. I think to recall that a simple 68010@7Mhz CPU got already like 10% more speed than an 68000@ 7Mhz - simply because it executes MUL/DIV a little faster. This makes us wonder if the 68020@35Mhz should not be a lot faster here? Why does the 68020 not gain more? Could it be that the bus-interface of the TF520 not reaches 100% of the speed of the 68000? Maybe the 68020 in same areas performs even slower than the original 68000 CPU? I think seeing again some Sysinfo results for an 68010 CPU would be interesting for comparison. Maybe some other test like BUSTEST would also provide information to better understand the problem and the bottleneck.
| |
| | ![](gfx/user2.gif) Gunnar von Boehn (Apollo Team Member) Posts 6214 21 Jan 2020 12:28
| Andy Hearn wrote:
| and the 060 based cards that are being worked on at the moment are as fast as an 060 card should be that i've seen. |
Obviously the owner of the TF-520 who posted this Sysinfo score did also believe his card to be as fast as any other 68020 card as he is clearly very disappointed that this is not the case. Did I understand you correctly that the Terrible Fire is a range different card iterations? Learning by doing so to say? Learning by doing is OK to me. If from previous mistakes is learned. Of course this leaves owners of the 1st generations in the rain.. The slow memory bus is on the TF520 clearly a big limitation. Did you double check that this problem is good on the new cards now? What is his real motivation doing these cards? Is the goal to develop a real good and stable card? Or is it just playing around? Andy Hearn wrote:
| even has a software modifiable cpu clock.
|
From quick looking on all Terrible Fire cards - I have the impression that CAPS and Voltage stability is rather poorly done on all of them. From 10 feet distance I would assume all cards have a stability problem risk because of this. Instead such "overclock" feature maybe more important would have been to fix the Caps?
| |
| | ![](gfx/user1253.gif) Andy Hearn
Posts 374 21 Jan 2020 12:57
| 4 cycles? ouch!
| |
| | ![](gfx/user877.gif) Wawa T
Posts 695 21 Jan 2020 22:41
| Learning by doing so to say? |
i think so, judging by the posts i once read on eab, by original developer. it should also be open source, i guess, if anyone cares to correct possible mistakes.id say, it isnt worth to hammer about there shortcomings. while it might be worth to contribute solutions to these shortcomings that are free to share.
| |
| | ![](gfx/user1856.gif) Mark Mc Fadden
Posts 36 21 Jan 2020 23:55
| Long time lurker( 3-4 years ) first time poster I dont like this attitude, this is disingenuous to Stephens work and progress, this is one of his earlier projects( which he open sourced!!!! ) and is obsolete along with a few other projects( TF534, TF328 ) - EXTERNAL LINK He has ongoing active projects( open source also apart from the 060 work ) on TF530, TF330, TF3609 which includes TF1260 for A1200 ), TF536, and has a youtube channel detailing his work, changes, progress, performance etc. - EXTERNAL LINK Don't turn this into a Vampire does this look as this other effort, the Amiga is already a very small community and doesn't need this nonsense whether disrespecting Stephen, Jens or those involved in the Warp 1260, its not welcome, post benchmarks sure but there is no need to knock others trying their best, no more than yourselves.
| |
| | ![](gfx/user1116.gif) Mr Niding
Posts 459 22 Jan 2020 05:34
| @Mark Mc Fadden I was thinking the same thing when I saw this thread.
| |
| | ![](gfx/user1127.gif) Eric Gus
Posts 477 22 Jan 2020 05:49
| @Mark Mc Fadden I didnt read it that way.. I actually found it interesting to see how other boards worked internally (which is actually interesting) .. But I suppose one could see it that way .. I didn't ..
| |
| | ![](gfx/user1116.gif) Mr Niding
Posts 459 22 Jan 2020 06:03
| eric gus wrote:
| @Mark Mc Fadden I didnt read it that way.. I actually found it interesting to see how other boards worked internally (which is actually interesting) .. But I suppose one could see it that way .. I didn't ..
|
I understand Gunnars intrest in how hardware internals works, but judging from expirience, discussions like this creates tensions, even if the examination comes from a friendly and curious perspective (which I think Gunnar have). I remember Stephen a good while ago withdrew his work for a period due to external pressure and critism towards his work. Im a big supporter of the Apollo project (and AROS), but I think Mark speaks for a share of people in the community, that will see this as less than friendly poke at TF. Even if its not intended to be that way. I remember flype on IRC last year "we are only human", speaking of the effect of constant critism of the Apollo project. Im sure Sephen feels the same way.
| |
| | ![](gfx/user2.gif) Gunnar von Boehn (Apollo Team Member) Posts 6214 22 Jan 2020 06:43
| Mark Mc Fadden wrote:
| I dont like this attitude, this is disingenuous to Stephens work and progress,
|
Hello Mark, We discussed technical facts. - Discussing problems allows you to understand them. - When you have the understanding then you can give advices. - If advices are followed this can lead to an improvement. The idea of an open source 68k accelerator is good. This idea is not new, already in the 80th AMIGA and ATARI Magazins did publish "open-source" the plans to several simple accelerators similar to the TF520 / TF530. If any discussion can leads to improvements on the Terrible Fire then this is good for all users of it. I think there are 3 areas which could be reviewed. a) Bus access. b) E-Clock c) Caps a = can improve performance b = can improve compatibility c = can improve stability of the card and is important for the live time of the chips I have to admit, that I'm very annoyed about the missing caps on the Terrible Fire cards. Adding enough caps is crucial for stability and reliability of the card - and its also crucial for the live time of the CPU. When I look at the Terrible Fire cards, then my first though is "NOT ENOUGH CAPS". Is the reason for this laziness or lack of "knowledge"? If its lack of knowledge then such discussions - can help to provide the knowledge.
| |
| | ![](gfx/user2.gif) Gunnar von Boehn (Apollo Team Member) Posts 6214 22 Jan 2020 07:12
| Mark, Lets make clear here: we are not doing unqualified bashing or ranting here. We talk about technical problems and we can offer advice. I think you know that our advice is highly qualified. Everyone in the AMIGA scene does know that our Memorycontroller and our Buscontroller are second to none and outclass all other Amiga cards. Its obvious that we perfectly understand the topics and we can give expert advice. And we are willing to help. Regarding the CAPs topic I'm disappointed. Mainly because I raised this topic in good faith not long ago, and was told that there would be XX caps on the 060-card, but I could only count halve of them.
| |
| | ![](gfx/user1675.gif) Kyle Blake (Needs Verification) Posts 108/ 1 22 Jan 2020 07:36
| I'm not really surprised this thread caused controversy. The Terriblefire guy is very popular with people, he's nice and he does his hardware development in a social way, as an amateur and hobbyist not as professional or business. He likes to give his designs away for free to everybody on forums like people did in electronics clubs in the 70s. So obviously to create a thread called "why is terriblefire 160 times slower", without making it clear you mean his very old First experiment, upsets people. As longtime natami and then vampire lurker I know that you don't mean to cause this controversy and you say stuff from genuine desire to help. But to people who don't know who you are Gunnar, it reminds too much of dickhead comments from people like Jens Schoenfeld.
| |
| | ![](gfx/user2.gif) Gunnar von Boehn (Apollo Team Member) Posts 6214 22 Jan 2020 07:45
| Kyle Blake wrote:
| As longtime natami and then vampire lurker I know that you don't mean to cause this controversy and you say stuff from genuine desire to help.
|
Danke!
Kyle Blake wrote:
| The Terriblefire guy is very popular with people, he's nice and he does his hardware development in a social way, as an amateur and hobbyist not as professional or business
|
This is good. And doing this as amateur is also nice. I like this. At the same time I would love if we can help here and would love to see that our advice is accepted. I think his idea of more "minimalistic" and affordable cards is great. I believe adding enough CAPs for stability is crucial. And I can offer to review the Bus-Access and to give advice - so that performance can be improved.
| |
| | ![](gfx/user1835.gif) Matthew J Fletcher
Posts 8 22 Jan 2020 07:45
| Hi Gunnar, Those of use that are engineers understand valid technical criticism, however please understand that many people are not engineers and dont understand a technical criticism is not personal and also that you are (like it or not) a celebrity in the Amiga/retro community. You might need to be careful in what you say does not get misunderstood. Clearly the first TF520 was a learning project (like V2.0 V500 apollo and V2.00 cores), both are done in spare time by talented people without being paid. TF528, TF530, TF534 and Vampire core 2.09, 2.10, 2.11, etc are all improved and better. Back to the technical question, i guess the only way to understand TF520 performance is to connect a logic analyser to its 68k and memory busses. There are many possible problems with the memory fetching, wait states, clocking, etc.
| |
| | ![](gfx/user827.gif) Nixus Minimax
Posts 416 22 Jan 2020 08:03
| Gunnar von Boehn wrote:
| Adding enough caps is crucial for stability and reliability of the card - and its also crucial for the live time of the CPU. |
Let's not forget that somebody also had to learn this the hard way with the progression from the Vampire 1 to the Vampire V2.2.
| |
|