Excitement about NatAmi

[Karlos]

Maybe they thought you were mental.

Was that really called for?

[Karlos]

Why shouldn't I? What's so sudden about it? Please enlighten me.

You're a MOS developer and as such don't have the right to an opinion about a different amiga offshoot :lol:

[Karlos]

Tee Hee, Duck Tape...

A couple of years ago, I noticed a car in the parking area outside my flats where the windscreen was held in with the stuff. If only "There I, fixed it!" was up back then :lol:

[Karlos]

Why does this remind me of BoXeR?

Back in the day when it was first announced I had such high hopes for the BoXer

[Karlos]

Those were the glory years for Vapourware.

Who remembers the A-Box and it's famed Caipirinha custom chip?
Who remembers the phase5 BlizzardG4 ? I was so up for that :lol:
When that never materialised, there was the met@box AmiJoe G3. OK, a step down from G4, but still, got all hot and sweaty again for nothing
Elbox SharkPPC?
Elbox Dragon?

(at least there were prototypes of the last few)

It gets depressing after a while.

[Karlos]

I don't want to piddle on anybody's cornflakes but a 133MHz 68060 CPU that has neither MMU or FPU doesn't excite me that much given that the E41J mask 68060's can easily achieve 100MHz (I've seen quotes of 120, even) and has both. Also, by the sounds of it, it's this 133MHz 68060FC part is as rare as rocking horse poo.

[Karlos]

A does a 100Mhz 060 real = 100Mhz PPC (Assuming they mean G3 here)

Not really, though it's hard to give an exact comparison given the different architecture of the two parts. A 68060 running typical 68K object code will get through around 1.3 instructions per cycle. A PPC750 (G3) will get through around 2.3 for typical PPC object code. The PPC on average has a slightly lower code density, but on the other hand, has some instructions that can do more work than you can do in a single instruction on 68K (floating point multiply-add would be an example that might see use in codec code).

Code properly tuned for each can achieve significantly better in those circumstances where you can leverage parallel execution across multiple functional units, properly fold out branches and make the best use of pipelining.

And will a 100mhz 060 be able to decode divx/xvid/dvd ?

Sure, just not necessarily in real-time for any watchable resolution.

[Karlos]

Unless he meant "slightly" was a joke.

In reality, most object code I've compiled for ppc and 68K shows between a 30-70% size increase in the PPC version. It varies a great deal. In some extreme cases, I've seen object code that's more than twice the size.

As for the example above, the increased complexity of the PPC example is not entirely down to the PPC architecture but also considerations of the OS itself.

[Karlos]

030 compatibility is no bad thing, especially if you are interested in backwards compatibility.

[Karlos]

The natami is a hardware emulation of the amiga architecture? Does this mean it is not a "real" amiga?

Emulation doesn't really describe it. Once you set up the logic, it's just hardware that is compatible.

[Karlos]

I linked what blitting was, it's just copying memory, occassionaly with a mask.  Hence your limiting factor is :shock: :horror: how fast you can move memory.

So potentially, Natami can move memory something like 438 times faster an an A500.

There's more to amiga blitting than just moving data, even with a mask. The amiga's blitter could combine up to 3 sources using a user-specific boolean function and write the result to a separate destination. IIRC, the any combination source(s) and destination could be the same. As such, it's fair to say there's rather more sophistication in there than your typical graphics card blitter, which tend to be optimized memory copy units only.

Even a direct port would only bump it up to 1MB of PPC code. Infact, how much ram are on the classic Amiga's with PPC accelerator? 64MB?

Mine has 256MB. By now, most BlizzardPPC/CyberstormPPC users have fitted as much RAM as they can on their boards.

[Karlos]

As will the Natami blitter.  Hence the limiting factor is: how fast you can move memory.

I'm not disagreeing, I was just expanding upon the point. Many people think of a blitter as a simple memory mover, since that's pretty much all modern blitters are, and they tend to have been superseded by 3D hardware where it's often just faster to redraw everything than it is to worry about blitting things (not to mention that compositing window managers actually require this to function properly).

Kudos to you.  What was the minimum required when OS4 for Classic was released?
Heck, the fact that the new product, 128MB ZoRAM, is being supported now shows me that many barely had 64MB...which is my point about OS4+Wii.  But, again, OT, just defending myself from the ignorant people(s).

Well, less than 256MB, that's for sure. In fact, 4.1 ran fine on my A1 in 128MB. However, the moment you start a remotely modern browser, that will quickly vanish.

[Karlos]

^The point, however, is that the minimum requirements to run the OS, should not be viewed as the minimum requirements to do something useful with it.

[Karlos]

Gentlemen, a spot of calm if you please.

Until I have a working NatAmi in my grubby paws, as far as I am concerned it's all speculative. On that point, a modern implementation of the hardware, if it lives up to the promise of being able to utilise the full DDR2 memory bandwidth would seem to qualify as much, much faster than the original. However, that's as much as can be said. Putting numbers on it at the moment, no matter how educated a guess, remains a  guess.

[Karlos]

Karlos be careful, how dare you say its just a guess, its just moving memory.   Did you fail maths in school etc etc

If there's one thing I've learned when doing low level work with real hardware, there's the theoretical speed of which the hardware is capable and the actual speed that is attained in the real world with applications that test it. The interface between software and hardware is often a murky place.

User
|
Application
|
OS Graphics API
|
Driver
|
Hardware

Remember, to use the blitter in an OS friendly manner, you have to wait for it, own it, set it up to do your operation, disown it etc. etc. All of those steps take time, which is more or less independent of how fast the blitter itself can do the operation you've asked.

Will you see a 100x speed up in a real world application? It all depends. If the setup cost is small, maybe you'll experience more than that. OTOH, if there are many small blits going on frequently, then the setup latency may dominate and you'll observe a lot less.