Author: Johan Klockars (ctfs.celsiustech.se)
Date: 01-21-2002 14:33
> > unnecessarily uses stuff like that
>
> Talking about the CPU card are we?
No, we were talking about the 68882.
I have not said one word about your processor card and memory, for example.
> > ARAnyM, for example.
>
> Another emulating thingy? We *could* start
Yes, emulating an '040 Atari (with FPU and
MMU (the latter not yet fully working)).
Deals with the Falcon graphics modes, but is really supposed to be used with fVDI and a device driver running mostly in native code.
> off our backs now? Just because you donīt
> like the idea of an better TOS machine,
I have absolutely nothing against a better TOS machine.
> > Sure, I have PC2100 memory in my current
> > PC, but it makes very little difference
> > compared to PC133 for most things.
>
>-Tror jag, det! COULD it be because the
> intel never exceeds
> say, 30-35% MHZ/MIPS ratio, so it doesnīt
> even reach 133?!
Exactly the kind of myths I was talking about earlier...
If you look around you'll find numbers of 3000-5000 (Dhrystone VAX) MIPS for the latest Intel/AMD processors.
Of course, Dhrystone is not a good benchmark, but it is what is used for MIPS numbers, normally.
IIRC, I wrote something rather long about this in reply to an article that originated around Christmas.
> Myths?? Come on! Most things I have seen
> & heared so far has been nothing but
> trueths. If not all.
I know you think that. That's why I felt I needed to jump into a few threads here.
> I wasnīt talking about the ī882, but about
> a tricky little IC that suits perfectly
> for interfacing the ī882 to the ī040.
> You might not believe it, but itīs turning
> out great. We still donīt know of any
> better way to do this, but
What I've been trying to do is to convince you that you are better off without the 68882.
> You know that. WE know that too. But TOS
> doesnīt know.
No, TOS has no idea whether there is an FPU in the system or not, and does not care.
> To those very few APPs that actually uses
> the FPU,
They are indeed very few, and they are likely to use very few of the FPU instructions (lots of times that is) that are missing in the '040.
Does this not suggest to you that adding an '882 is a waste of time/money?
> > Try running some real software rather
> > than a stupid benchmark
>
> Yes, please! -Any suggestions for some
> good test softs?
There are quite few for the Atari machines, since very few of them have even remotely decent FPU performance, unfortunately.
How about a raytracing program?
> Ah, The AB40, yes... A 32 bit CPU, in a 16
> bit machine.
Well, I'd rather see it as a 32 bit CPU with a 16 bit IO bus. Very little except IO really passes the 16 bit bus.
> I have read something about that. Said it
> has this external UDS/LDS MUX, that brings
It obviously needs to connect to the Falcon
bus.
> the 040īs performance down to half of its
> actual clock speed. Amazing. I just had to
> check this up, and yes, it turned out to
> be true.
It is not, really.
Obviously things slow down to a crawl when you access the Falcon bus. The processor can run along during write accesses, though.
IIRC, it has time to run nearly 20 simple instructions between two 16 bit writes to the Falcon bus, and of course nearly twice that when doing 32 bit writes.
It is actually possible to do an 8 bit chunky to planar conversion while moving from fast RAM to the Falcon's memory at the same speed as a simple copy.
Since the '040 can not reorder instructions, it will have to wait on reads from the Falcon bus, though, unfortunately.
> They called it a "bus resizer", if I
> remember it right.
The '040 needs that to access 8/16 bit locations, yes.
> BTW, talking about the AB040;
> Is it a LC or a RC 040? what clock speed
> does it run in?
I think you could get it with both types. The CPU is socketed, anyway. Normally it runs at 32 MHz.
> Does it speed up the so called "bus" as
'so called'?
> well, or just the CPU?
There is no bus-speeder included with the AB040, though some people have used the normal ones.
> Though, I donīt mean the Pclock frequency,
> the Bclock is the true one.
> (as you are very well aware of, I guess?)
I can never recall which clock is called what, but I am indeed well aware that the '040 is not 'clock-doubled'.
> I also would like to ask about the
> software compatibility, with both AB40 and
> R2?
> Does it run very many softs at all? Apex?
There are of course some incompatibilities with the '040, but it's not too bad. I've been able to run just about everything I've wanted, including a few old games. Some of the problems can be avoided by turning off one or both caches, but that is of course a very bad idea for the performance.
I'd believe the Apex stuff would work with the '040, since the author of that package did most of the '040 compatibility stuff (the AB040 Toolkit).
The RageII is mainly intended to run VDI programs, and it runs the vast majority of those. There are still some bugs and missing features, and new problems crop up from time to time, but I usually manage to deal with them.
Direct screen access with the RageII is possible, but not a good idea (especially with an '040, since it can get into an infinite bus error loop). The frame buffer is byte swapped, which causes trouble for some programs.
> If you would like to try Centbench on it,
> Iīll mail it. Just ask.
I could do that, but I'm away for a few days (work), and I could probably locate that program myself.
[The below is regarding the Dragonball]
> > "And would fail to run even the Falcon
> > OS, as well as anything else compiled
> > for an '030."
>
> Geez, You should know very well that
> *that* is wrong.
Uh, no it is not.
> For your information, I have been running
> Cubase Audio on my Mega 4 with Viking card
> and SM194 19", in 1280x960.
> CAF is "compiled for an '030" I think?
If it ran on a 68000 processor, it obviously can't be.
> Moto says that the SZ will run under
> virtually *any* OS.
I have not seen where they say that, but they can't mean what you think they do.
There are lots of new addressing modes in the '030 that no 68000 could deal with. Then there is the MMU and caches, with their respective instructions, an extra stack pointer, etc.
> Why this negative attitude?
Negative attitude? Where?
I do know my hardware, however.
> > I did not take anything on that site
> > seriously.
...
> But we think you obviously did? Why else
> did you start spreading lies about the
> things you found there?? ;o)
You won't find any lies in what I've written in this thread. I might possibly have been mistaken somewhere (please, feel free to point that out, if so), and have possibly used stronger words than necessary.
I've explained the reason for my articles here before:
Not everyone knows enough to be able to figure out what's wishful thinking or plain ignorance. If I can dispell some of that, and have some time to spare (;-), why not?
(Believe it or not, I actually enjoy these kinds of things. ;-)
I will try to restrain myself from from talking about the 'hacking' of driver dll:s...
|
