Looking for W3D_Picasso96MU.library v4.2 (17 Feb 2002)

[vxm]

I'm not so sure that selling both the Amiga and a PC were a mistake

It was not just to sell two competing platforms problematic. It was to manufacture AND sell them.  

Is Amiga performance or compatibility more important?

Reducing a problem to one or two questions can sometimes be dangerous.
We should begin by defining compatibility type:
hardware or software (well, okay, here, there are only two questions)?
In general, compatibility and performance should not exclude each other, I would say they are complementary.
The problem lies rather be in their subordination.  

And yes, yesterday the 68k was condemned to disappear, mainly because of technological limitations. But is it still valid?
Today, FPGA technology seems promising because it appears to allow to overcome certain constraints.
What is interesting with the FPGA is the abstraction part. This should help to reduce dependence on this technology.

[twizzle]

this is the closest i can find for you. i am sure i have this mmcd update ..somewhere.?
i will keep looking.

http://www.ppa.pl/programy/instalacja-warp3d.html  
 
translated
Here are my versions of system files mediator (as at 19 July 2005.), Which ran the 3D support. Therefore, the files contained's see, among others, in the package MediatorUP_3.9.lha (my current version):        February 17, 2002

W3D_Picasso96M.library    4.2    17 lutego 2002    Libs:Warp3D/GFXdrivers

[QuikSanz]

@matthey,

Well stated, thank you!

[matthey]

this is the closest i can find for you. i am sure i have this mmcd update ..somewhere.?
i will keep looking.

W3D_Picasso96M.library    4.2    17 lutego 2002    Libs:Warp3D/GFXdrivers

This W3D archive listing at your link shows a W3D_Picasso96M.library with the new date but no W3D_Picasso96MU.library with a new date. This looks like more evidence that the updated library does not exist and the information on Elbox's web site is incorrect. IMO, the chances of the Elbox web site being wrong is greater than the chance that updated W3D archives were sent out missing this updated library. It may be that a bug or problem was found in the library and it was removed from the archive but the listing was never updated.

It was not just to sell two competing platforms problematic. It was to manufacture AND sell them.

Once again, there are synergies and economies of scale if properly managed. More of the same cases and power supplies with different stickers could have been used, a few of the same chips and screws could have been bought in larger quantity for both, larger manufacturers can negotiate better prices even if the products vary, etc. Did C= take advantage? Well, it looks like management is where they failed. I expect the PC manufacturing changed a lot over the years from doing a lot of in house production to contracting most of the work to Asia which is how it is done today (and with razor thin margins).

Reducing a problem to one or two questions can sometimes be dangerous.
We should begin by defining compatibility type:
hardware or software (well, okay, here, there are only two questions)?
In general, compatibility and performance should not exclude each other, I would say they are complementary.

 

Compatibility and improved performance are possible at the same time but rarely complimentary in my experience. Compatibility depends on what technology is used to improve performance. Replacing a CISC CPU (the brain of the computer) with a RISC CPU is not exactly a minor transplant and is bound to have compatibility issues even if it is also big endian. Removing the custom chips also unnecessarily decreases compatibility considering their minor cost in modern hardware.

And yes, yesterday the 68k was condemned to disappear, mainly because of technological limitations. But is it still valid?

The 68k disappeared for management and marketing reasons and not technological limitations. The 68060 overcame every 68k obstacle. It became RISC internally with a modern instruction pipeline. Instruction decoding was improved so that it was no longer a bottleneck but, rather, the naturally compact code became an asset saving caches and memory. The 68k has most of the advantages of the x86 except the code is simpler to decode, the code is more compact, the CPU has more mostly general purpose registers and it is easier to program and debug. The older x86 proved to be adequately powerful and the 68k is a more modern and logical design. The industry keeps ignoring the advantages of CISC while RISC designs like SPARC, MIPS and PPC (ARMv8 to be determined) never live up to expectations. IMO, the 68k has great potential.

[OlafS3]

Thanks for the clarification!  I'm sure I will forget and post erroneous information again, maybe I should just bookmark this comment, lol.  

Still disappointed about how that all played out.  I have very little interest in MiniMig, MiST, FPGA Arcade, and whatever all the other gazillion Amiga clones and derivatives are.  But I would've bought the heck out of Natami.  

Natami would have been very expensive in fact, you would have get a very good equipped PC for that (part prices without soldering) so I do not think that the market would have been very big. Some would have bought it of course. A standalone device would be nice in future and is one of the future ideas for the apollo project. But first they should get the accellerators out.

[matthey]

Natami would have been very expensive in fact, you would have get a very good equipped PC for that (part prices without soldering) so I do not think that the market would have been very big. Some would have bought it of course. A standalone device would be nice in future and is one of the future ideas for the apollo project. But first they should get the accellerators out.

Thomas was making the Natami with the high quality and many features he wanted. Yes, it would have been expensive in small quantity orders that were expected but cheap compared to AmigaOS 4 hardware. No pre-order numbers for production boards were gathered that I know of but I believe the interest was under estimated. The Natami MX bringup thread has 729k reads!

http://www.natami.net/knowledge.php?b=1¬e=33366

If everyone looked at the thread 100 times, there would be 7296 interested people with no advertising! Natami cost estimates were likely conservative and based on small quantities. The Natami value is highly dependent on the performance of the CPU and the FPGA CPUs at that time were not as mature or fast (a real 68060 was much more cost). The price of FPGAs has dropped significantly since then. It may be affordable to use an FPGA with SerDes now for SATA/PCIe which may allow the board to be smaller and cheaper. It may be possible for the ethernet chip to be removed and driven by the FPGA directly as planned for the Apollo sandwich accelerator. The board would probably need at least a partial redesign depending on availability and price of parts like DDR2 to DDR3. The Natami, like the original Amiga, was ahead of its time but it would be easier to offer more value today.

http://www.natami.net/gfx/NatAmi64_MX/natamipinout.png

Weren't the Natami problems cache coherency problems? I had the impression that Thomas was trying to speed up the custom chips to what the hardware is capable of. Even the gfx speed up of the FPGA Arcade or Mist over AGA is huge and more would likely be possible in a higher spec Natami.

[vxm]

Once again, there are synergies and economies of scale if properly managed.

Yes, this principle has worked so well that the Amiga has paid the price of these economies.

On another level, the first Amiga still operate today. Can we expect the same of today's components? I have serious doubts ...
 

Compatibility and improved performance are possible at the same time but rarely complimentary in my experience. Compatibility depends on what technology is used to improve performance. Replacing a CISC CPU (the brain of the computer) with a RISC CPU is not exactly a minor transplant and is bound to have compatibility issues even if it is also big endian. Removing the custom chips also unnecessarily decreases compatibility considering their minor cost in modern hardware.

I am neither for nor against the idea of using a processor again. I just think it's too early to think about it; the situation of the Amiga does not allow it.
The FPGA seems to me the best option.
If you want a hardware that is not 100% compatible, the problem would be to know where to place the cursor between compatibility and performance.
Now, if you want a hardware that is 100% compatible, this problem disappears.

The 68k disappeared for management and marketing reasons and not technological limitations.

The disadvantage was that the CISC warming faster than the RISC. Its operating frequency was clamped.

[OlafS3]

Thomas was making the Natami with the high quality and many features he wanted. Yes, it would have been expensive in small quantity orders that were expected but cheap compared to AmigaOS 4 hardware. No pre-order numbers for production boards were gathered that I know of but I believe the interest was under estimated. The Natami MX bringup thread has 729k reads!

http://www.natami.net/knowledge.php?b=1¬e=33366

If everyone looked at the thread 100 times, there would be 7296 interested people with no advertising! Natami cost estimates were likely conservative and based on small quantities. The Natami value is highly dependent on the performance of the CPU and the FPGA CPUs at that time were not as mature or fast (a real 68060 was much more cost). The price of FPGAs has dropped significantly since then. It may be affordable to use an FPGA with SerDes now for SATA/PCIe which may allow the board to be smaller and cheaper. It may be possible for the ethernet chip to be removed and driven by the FPGA directly as planned for the Apollo sandwich accelerator. The board would probably need at least a partial redesign depending on availability and price of parts like DDR2 to DDR3. The Natami, like the original Amiga, was ahead of its time but it would be easier to offer more value today.

http://www.natami.net/gfx/NatAmi64_MX/natamipinout.png

Weren't the Natami problems cache coherency problems? I had the impression that Thomas was trying to speed up the custom chips to what the hardware is capable of. Even the gfx speed up of the FPGA Arcade or Mist over AGA is huge and more would likely be possible in a higher spec Natami.

a lot of "if" in your sentence... of course in bigger quantities production and component prices are cheaper but I have seen no realistic calculation of it only the situation at that point of time. And at that point of time it would have been too expensive for many. We need a lift of the whole hardware base and not just 100 or 200 sold systems.

Regarding problems I think I read RAM timing problems but I cannot say more about it because not being involved there. In any case the problems obviously were so relevant that the whole project stalled.

[Cosmos Amiga]

The FPGA seems to me the best option.
If you want a hardware that is not 100% compatible, the problem would be to know where to place the cursor between compatibility and performance.

I guess you have zero idea of what is really the word "developping" on Classics...

For myself, it's extremly difficult : zillions problems all the time, insane bugs, forum trollers, no answer from those who can help you, very few users help, ennemis, hardware worked fine yesterday and fail the next day, false friends, psychic attacks, money problems and many many more crazy things...


Try to do something (coding, new hardware, various hacks...) on Classics, and you will see...

[guest11527]

Regarding problems I think I read RAM timing problems but I cannot say more about it because not being involved there. In any case the problems obviously were so relevant that the whole project stalled.

Not really RAM timing, but the problem was to pipeline the blitter *and* stay compatible with the original. The current FPGA implementation does not really use the full power of the FPGA for blitter emulation, it is more a step-by-step implementation. It could be made much faster by bundling the RAM accesses and fetch several words at once, similar to bursting (as far as I understand it).

The problem is that this also limits compatibility. With the original blitter, you can in principle configure your output register (channel D) such that it writes "in front of" the input registers (A,B,C), i.e. the input channels can see what the output writes, *if* you know the exact timing of the blitter, and which channel allocates which DMA time slot.

With any type of pipelining in place, this type of "trick" no longer works. The input registers would have their input already buffered since a long time before the buffered output ever appears on the bus, and hence blitter functionality would then be different.

As always "no sane programmer" would have done that, but a lot of insane programming (called "hacking") was done on the Amiga... So it was again a problem of finding the right balance between speed and compatibility. With blitter prefetching active, probably a handful of "programs" (as in demos) would not run anymore correctly, but this would again cause an outcry of those who love that stuff...  

Thus, one of the big problems here is really of finding the "sweet spot" between compatibility and speed. All Os4 and friends/foes cut compatibility at "source code level" (as in "you have to recompile"). This would be ok for an open source platform, but Amiga was none. Natami tried at "hardware register level", but maybe that's already asking a bit too much, and probably the cause for its failure.

Having a blitter is probably a "must have", but do we really need to emulate every nonsense that was done back then in the early days? *That* is the big question.

[OlafS3]

Not really RAM timing, but the problem was to pipeline the blitter *and* stay compatible with the original. The current FPGA implementation does not really use the full power of the FPGA for blitter emulation, it is more a step-by-step implementation. It could be made much faster by bundling the RAM accesses and fetch several words at once, similar to bursting (as far as I understand it).

The problem is that this also limits compatibility. With the original blitter, you can in principle configure your output register (channel D) such that it writes "in front of" the input registers (A,B,C), i.e. the input channels can see what the output writes, *if* you know the exact timing of the blitter, and which channel allocates which DMA time slot.

With any type of pipelining in place, this type of "trick" no longer works. The input registers would have their input already buffered since a long time before the buffered output ever appears on the bus, and hence blitter functionality would then be different.

As always "no sane programmer" would have done that, but a lot of insane programming (called "hacking") was done on the Amiga... So it was again a problem of finding the right balance between speed and compatibility. With blitter prefetching active, probably a handful of "programs" (as in demos) would not run anymore correctly, but this would again cause an outcry of those who love that stuff...  

Thus, one of the big problems here is really of finding the "sweet spot" between compatibility and speed. All Os4 and friends/foes cut compatibility at "source code level" (as in "you have to recompile"). This would be ok for an open source platform, but Amiga was none. Natami tried at "hardware register level", but maybe that's already asking a bit too much, and probably the cause for its failure.

Having a blitter is probably a "must have", but do we really need to emulate every nonsense that was done back then in the early days? *That* is the big question.

thanks for explanation

interesting read

my personal 2 cents... who prefers compatibility as highest priority is better off with FPGA Arcade or Mist. The new apollo cards (and Natami) should be for new software mainly so in doubt having faster and more advanced hardware implementation is more important than that every old game or demo works correctly.

[Blizz1220]

If it's gonna end up as yet another NG system nobody will want it.

I don't think this is were it's headed though.Set goal was compatibility with old chipsets (as in recreated) and addition of fastest possible CPU and RTG.

That way you only increase number of (useful or not so much) applications.

As for Natami , what was the point of better Blitter anyway ? Was there gonna be a lot of new games written for it ? Better option was to add C2p (Akiko?) or just put FBlit in kickstart.

If you look at old Capcom System 1 games like Final Fight they actually use "slowness" of 68000 at some parts of game like when there is many enemies to give "slow motion" effect.I don't think that was bad coding and demos are made for specific hardware not for future compatibility.

Compatibility should be balanced between number of sw pieces that you "loose" to gain advantage.

[guest11527]

If it's gonna end up as yet another NG system nobody will want it.

I don't think this is were it's headed though.Set goal was compatibility with old chipsets (as in recreated) and addition of fastest possible CPU and RTG.

Well, that's probably a bit harsh. "Nobody" is surely not correct (I would have wanted one), and I wouldn't have been afraid of a bit of blitter incompatibility as long as the os level routines still work fine (which is surely true if you don't try stupid things). At least it would have made the blitter "useful" again, in the sense of "the blitter is faster than the CPU".  

As for Natami , what was the point of better Blitter anyway ? Was there gonna be a lot of new games written for it ? Better option was to add C2p (Akiko?) or just put FBlit in kickstart.

It's not about games. At least not for me. It's about having a 256 color workbench that renders at acceptable speed without depending on the full patch-o-rama an RTG system is.  

And please, can be forget Aikiko? It really doesn't do anything useful. It's just a small set of passive registers that doesn't do much. If Aikiko would have included a DMA engine or could have been combined with the blitter, that would have created a couple of useful applications, but the "el-cheapo" implementation CBM went for was good for almost nothing. It's really only a single register where you push in "chunky data", serially, one by one, by the CPU, and another register where you can fetch the planar data from.

[Blizz1220]

Well not a problem if you loose even 10 or 30 % of hardcoded software titles but as long as you gain more usage out of those that benefit and you couldn't use before.

Problem I see is that DPaint or Protracker won't really need anything more than memory or faster CPU.Even faster CPU won't make anyone type/draw/create tracks faster.From what I've seen it either works with old stuff or it just doesn't , somewhere in between could be very nice and you can always fit FPGA with slower/more compatible core (I hope).

[matthey]

Not really RAM timing, but the problem was to pipeline the blitter *and* stay compatible with the original. The current FPGA implementation does not really use the full power of the FPGA for blitter emulation, it is more a step-by-step implementation. It could be made much faster by bundling the RAM accesses and fetch several words at once, similar to bursting (as far as I understand it).

The problem is that this also limits compatibility. With the original blitter, you can in principle configure your output register (channel D) such that it writes "in front of" the input registers (A,B,C), i.e. the input channels can see what the output writes, *if* you know the exact timing of the blitter, and which channel allocates which DMA time slot.

With any type of pipelining in place, this type of "trick" no longer works. The input registers would have their input already buffered since a long time before the buffered output ever appears on the bus, and hence blitter functionality would then be different.

...

Having a blitter is probably a "must have", but do we really need to emulate every nonsense that was done back then in the early days? *That* is the big question.

I don't see this is a show stopper at all. I would leave a compatible hardware blitter, perhaps with a global turbo mode bit which can be set for some speedup with less compatibility. Add an SIMD to the 68k and patch/change the AmigaOS and blit functions to use it for new software. The hardware blitter takes minimal logic so there is minimal waste. Gunnar has suggested adding an SIMD and using it to replace the blitter. From his forum posts, it sounded like he had even suggested it to ThomasH. Supposedly, they worked out an agreement for SAGA and CPU technology sharing so maybe the idea was well received.

Well, that's probably a bit harsh. "Nobody" is surely not correct (I would have wanted one), and I wouldn't have been afraid of a bit of blitter incompatibility as long as the os level routines still work fine (which is surely true if you don't try stupid things). At least it would have made the blitter "useful" again, in the sense of "the blitter is faster than the CPU".    It's not about games. At least not for me. It's about having a 256 color workbench that renders at acceptable speed without depending on the full patch-o-rama an RTG system is.  

The classic AmigaOS needs to go back into development. Better compatibility between AmigaOS 4.x and classic would make developing for a larger user base much easier. FPGA technology may allow the larger classic user base to expand quicker also. AmigaOS 4.x has an updated graphics.library supporting RTG now. Standards would also be helpful so we don't have a bunch of incompatible patched up classics. A-Eon could make it happen, and act half way interested, but the classic does not seem to be a priority.

[vxm]

I guess you have zero idea of what is really the word "developping" on Classics...

Sometimes you seem rough.

For myself, it's extremly difficult : zillions problems all the time, insane bugs, forum trollers, no answer from those who can help you, very few users help, ennemis, hardware worked fine yesterday and fail the next day, false friends, psychic attacks, money problems and many many more crazy things...

Who said you it will be easy?

Try to do something (coding, new hardware, various hacks...) on Classics, and you will see...

Already done. Try to develop a network card for an A2000 OS 1.3, with an A590 and an A2090A as only examples. You will see, it's very funny. You will learn a lot of unnecessary things.