What are the advantages of the present/future Amiga?

[amigaksi]

by cicero790 on 2008/8/29 7:30:44

>Nobody is debating if a Mac is a Mac because of the Intel chips. Why should Amiga be any different?

Because Amiga IS better than a Mac, and a new "Mac" is NOT a Mac because of Intel chips.  If hardware can be completely different and name remain the same, then the Commodore PC (especially an upgraded one) can be relabeled as an Amiga as well, right?  They are just using the name to draw loyal fans and for marketing purposes.  I would state that if the hardware is backward compatible, then you can use the same name.

>Amiga is a powerful brand name not some small orphan OS that never had a platform of its own. I was forced to leave Amiga in the 90’s because the stopped development of hardware. I loved my A1200.
>Millions upon millions of people were like me, force to leave a platform we liked for PC or Mac.

Well, if Motorola kept advancing their processors and keeping them backward compatible, you could have had a more powerful Amiga more easily today.

[amigaksi]

>by Piru on 2008/8/30 22:29:15

>@amigaksi
>Quote:

>    a new "Mac" is NOT a Mac because of Intel chips


>Why not?

>I have both PPC and Intel Macs. There is no difference between them, except that the Intel Mac is much faster.

And how did you draw such a conclusion that they are both Macs.  The Mac was originally a 680x0 and although overburdened (unlike amiga) had some support hardware like for audio/keyboard/mouse etc. so unless you have a system that is a subset of that hardware configuration you can bet there exists a program that will work on original Mac not on your so-called Mac.

[amigaksi]

>by warpdesign on 2008/8/31 13:02:15

>Quote:

>    Because Amiga IS better than a Mac, and a new "Mac" is NOT a Mac because of Intel chips. If hardware can be completely different and name remain the same, then the Commodore PC (especially an upgraded one) can be relabeled as an Amiga as well, right? They are just using the name to draw loyal fans and for marketing purposes. I would state that if the hardware is backward compatible, then you can use the same name.


>That's stupid. Seems like you are against evolution to me...

Saying it's "stupid" is not an argument but your biased opinion.  If you had read the entire post before replying-- I did mention something about evolution of processors where Motorola one's did not go as far as Intel ones.

>And you cannot accept your old Amiga solution sucks and isn't the way to go anymore. This was good 20 years ago though... As good as the Ford produced 20 years ago was probably good. But the Ford produced today isn't backward compatible with the old one... And Amiga of today... Wait! there's no Amiga of today. The Amiga hasn't evolved since 20 years. But maybe it's still better than anything... Or maybe it's not...

I don't even think you understood what I wrote.  PCs are backward compatible for about 30 years; I can still run 8088 code on a Pentium IV.  Get your analogies correct.  I already know there are still unique uses for an Amiga even today, but that's not the argument-- the point was there's no meaning to the name if you can assign it to hardware that's completely different.  

You cannot accept that you are a hypocrite claiming Amiga sucks on an Amiga forum.  If you really know it sucks, then state the proof.  Any small baby child can be taught to say "this sucks", "this is stupid", etc. etc.  

>>    Well, if Motorola kept advancing their processors and keeping them backward compatible, you could have had a more powerful Amiga more easily today.

>Maybe they didn't because it was hard and useless ? maybe the 68k wasn't perfect and there was a better way to design processors ?

You can always design hardware for backward compatibility; just look at Intel.  They would have had better optimization if they dropped all the 8-bit instructions in their 8088 instruction set but they did not.

[amigaksi]

by alexh on 2008/8/31 13:49:03

>>    you can bet there exists a program that will work on original Mac not on your so-called Mac.


>I bet there are very few programs worth running that fall into this category.

It does not matter the number; in fact, there can even be none-- just theoretically exist (someone may write one) and that would show it's not backward compatible.

>If you find one of these programs and find you cannot live without it, there are numerous easy to use hardware level emulators at your disposal.

Well, unless the audio/kb/etc. of the new machine is a superset of the old machine, it would be hard to do any sort of emulation accurately.  Actually, you can state there is some Mac out there that does this since there are so many flavors  and new flavors coming, it's hard to keep up.

[amigaksi]

That should be "has a subset" not "is a subset".

by amigaksi on 2008/8/31 13:45:16

>by Piru on 2008/8/30 22:29:15

>@amigaksi
>Quote:

> a new "Mac" is NOT a Mac because of Intel chips


>Why not?

>I have both PPC and Intel Macs. There is no difference between them, except that the Intel Mac is much faster.

And how did you draw such a conclusion that they are both Macs. The Mac was originally a 680x0 and although overburdened (unlike amiga) had some support hardware like for audio/keyboard/mouse etc. so unless you have a system that is a subset of that hardware configuration you can bet there exists a program that will work on original Mac not on your so-called Mac.

[amigaksi]

by Beast96GT on 2008/8/31 14:38:39
...
>I would like to think that the new Amiga would have an architecture that would not be held back by backward compatibility, as the PC seems to be. Why couldn't backward compatibility be provided in software emulation?

I would state that it kills the userbase once you just develop a new machine that's not backward compatible and you have a new learning curve for development as well.  It could be backward compatible in software if the hardware supports it (that's why I was stating things like subset/superset).  For example, you can't show real-time sprites all over a screen on a machine that does not have sprites.

>There would need to be incentives for developing software for it. Maybe a killer app that really fills the "niche"?

PCs have always coexisted with Amiga/Ataris-- one having a different focus than the other.  All of a sudden people want to use the PC for everything once Amiga/Atari went bankrupt, but they did not redevelop the PC that fits the hardware requirements of Amiga/Ataris.  

There's nothing wrong with people asserting their opinions, but when people start declaring "it sucks", "it's stupid" we need evidence.

[amigaksi]

>by alexh on 2008/8/31 13:40:42

>It doesn't matter what hardware it uses. To be honest if you're even THINKING what the underlying hardware is then the OS + applications have not done their job correctly.
...
>You could argue that the spirit and soul of the Amiga was not in the OS level but in the bang the metal programming that grew up around the earlier computer systems. But I doubt very much you are a programmer or know anything about this area. You are just a user. (As am I)

Yeah, so stick to being a user then and stop telling people about what is the right way to program or better programming because your statements reflect your inexperience.  For some tasks you need to know the hardware behind the software.  If someone wrote a medical system to control medical instrumentation or some power plant relying to timing issues, he can't just get a new system that's not backward compatible (on the hardware level).  The Amiga systems retained their hardware register level compatibility, so it's more optimal to use it and NOTHING wrong with it.  Read the PREFACE to Hardware Reference Manual for Amiga and it tells you the same.

[amigaksi]

>The software is everything. Today the hardware is nothing.(Although I admit that without the hardware in the first place there would have been no software).

Wrong.  If software was everything, people would still be using Commodore 64 since when new machines came out, they had very little software and C64 had tons of it.  And you can apply the same principle to any later time a new machine was introduced.  Nobody should have bought the new "Macs" or faster PCs since older PCs already had more software.  Perhaps, if you are running stuff like a Word Processor or some Browser, you don't care about the hardware behind the application, but many tasks require one to know what the target machine (hardware) they are writing their applications for.

[amigaksi]

>by alexh on 2008/8/31 15:09:22

>>Quote:
amigaksi wrote:
PCs are backward compatible for about 30 years; I can still run 8088 code on a Pentium IV.

>No you cannot.

It's my code that I wrote when I was in college and it still runs; here's a sample:

;BX=FLOOR(SQRT(AX))
Sqrt Proc Near
Xor BX,BX
SqrtAX: Sub AX,BX
Inc BX
Sub AX,BX
Jns SqrtAX
Dec BX
RET

The keyboard access to port 60h, timer access to 40..42h, etc. all are still the same.  

>The caches and internal pipeline structure means that a lot of code does not run as it was supposed to. I dont think you were a PC user during the transition to 32-bit x86 architecture and once again to the Pentium architecture. Either that or you've forgotten.

Even the 8088 had various speeds so if you tried to time things with instructions, you probably had problems or with self-modifying code; however, the instructions set was purposely kept backward compatible like it was with 680x0 series (on Macs/Amigas/Atari STs).  That's different from making a new processor and then doing some software emulation where you probably can't even map the timer or other hardware the software accesses.

>>Quote:
amigaksi wrote:
It does not matter the number; in fact, there can even be none-- just theoretically exist (someone may write one) and that would show it's not backward compatible.

>Of course it matters. Creating a system that performs terribly for all applications just to support one or two rogue applications that are very rarely (if never) used (and have working equivalents) is just stupid.

If the application was the only thing one required to get a task done, the numbers don't matter.  It's a rogue application is your opinion especially if the hardware was being kept standard for a bunch of models.  It's always more optimal to go directly to hardware registers if the hardware is standardized and you also know exactly what is happening in your code and how many cycles it will take.

>Like everything in life its a matter of numbers.

That's even more absurd.  It's okay to claim "Not everything is a matter of numbers" as an absolute claim since you only need one item to prove it like "love" or where quality is better than quantity.

>>Quote:
amigaksi wrote:
Well, unless the audio/kb/etc. of the new machine is a superset of the old machine, it would be hard to do any sort of emulation accurately.

>Hard yes, but people have been working on them for decades. They are very good. Certainly good enough for a regular user. Because the MAC used libraries to abstract everything and there was far less "bang the metal" programming a highly accurate and compatible MAC emulator is far easier than say an Amiga emulator.

That's true since Mac has less custom hardware supporting it, it's easier to emulate whereas Amiga is impossible to emulate for certain things on a PC. I would like to know what target machine (spec) you are comparing to since I have seen Macs emulated on Atari ST, Amiga, and various PCs and newer so-called "Macs".  That way we can better tell whether they can be called "Macs".

>>Quote:
amigaksi wrote:
For example, you can't show real-time sprites all over a screen on a machine that does not have sprites.

>Not true. It all depends on how much CPU power per VBL you have, what RAM bandwidth you have, what VBL synchronisation you have.

Do you really think that setting 30 X,Y registers of sprites even on a 7.16Mhz OCS Amiga 1000 can be beat by a standard CPU/Graphics Card doing erasing/repainting of software sprites?  Think again.  It only takes a few microseconds on an Amiga 1000.

>You think high level Amiga games use only hardware sprites? Of course not when the accelerated CPU's could pump 10x of them around in 1/10th the time.

Never said sprites had to be used for games.  What's high level game for you might not be for others.  And doing 10x in 1/10th of the time, first answer the part of doing 1X in the same time or less.

[amigaksi]

>Don't see me doing that ever... gimme some links. Answer: You cannot.

"To be honest if you're even THINKING what the underlying hardware is then the OS + applications have not done their job correctly." from the very thing you replied to.

>They have Amiga's controlling medical systems and power stations? I didn't think so. AmigaOS is not an RTOS btw.

Don't misquote me; take your time in replying.  I never said there was an Amiga controlling them.

>Admittedly it was usually the fault of the programmer who had set-bits in reserved fields or used invalid address ranges to get a few extra cycles of speed but 100% register compatibility... nope!

The defined bits are 100% backward compatible.  Undefined bits have problems even on the PC parallel port where bit 5 at 37Ah was used for I/O mode on IBM PCs.  But you see the point that some applications are not even possible without going directly to hardware registers; even my floppy simulator does not work if I go through Windows API.

[amigaksi]

by mdwh2 on 2008/9/1 21:10:36


>>>Do you really think that setting 30 X,Y registers of sprites even on a 7.16Mhz OCS Amiga 1000 can be beat by a standard CPU/Graphics Card doing erasing/repainting of software sprites?

>>Surely it can? The bandwidth of DDR2 + 16x PCIe + 2.4GHz Core2Duo means the CPU can erase and repaint a 320x240x8 screen many thousands of times per VBL?

>Indeed, his claim is ludicrous.

When you don't understand the point, you should first try to understand it before replying.  Alex is right in trying to repaint the screen because the ORIGINAL point is showing a screen full of sprites on a system that does not have sprites.

>Moreover, there's no reason it has to be done in software anyway - on modern hardware, this sort of thing can easily be done in hardware (the sprites are stored in graphics memory, and rendered directly by the graphics hardware).

Moreover, you missed another point-- that you have to use a standard graphics card/CPU not something that works on maybe your system and you are NO LONGER using a system that does NOT support sprites.  It won't work on modern hardware that I have-- my ATI card does not support sprites in hardware so you have to repaint the screen or some other algorithm.

>Therefore you don't even have the bottleneck of PCIe, and graphics memory is even faster than DDR2. From http://en.wikipedia.org/wiki/GeForce_200_Series , the memory bandwidth on modern graphics cards is ~100GB/s, with 240 processors giving a peak fillrate of about 20 billion pixels per second (which would fill that 320x240 screen about 260,000 times a second). What was that about being able to set a measly 30 registers?

It's NOT 100GB/second from CPU accessible memory to graphics card; stop picking up things randomly from the web and trying to argue against a point you don't understand.  You don't even understand how amiga sprites work; they can be rendered even on a 640*400 screen at their 320*200 resolution so the worst case is repainting 640*400.  It's the Amiga that only has to set 30 registers not the PC; PC has to repaint the area.  

This is your understanding of the argument:

I say: system without hardware sprites would have a hard time showing a screen full of sprites in real-time (on a standard CPU/Graphics card).
You say: that's ludicrous, just use the hardware sprites in the graphics card and use the latest and greatest graphics card.

Duh!  Perhaps, I should put in Video Toaster in my machine and use that to my advantage as well and some other souped up attachment that only works on my Amiga.

[amigaksi]

>by alexh on 2008/9/1 6:23:10

Quote:


>>amigaksi wrote:
    It's always more optimal to go directly to hardware registers if the hardware is standardized


>But it's even more optimal to go directly to the library level if the hardware is not standardized. Especially today.

You know what people did when there was only a few things nonstandard is that they give a list of sound cards or graphics card, so they could be used optimally.

>I can appreciate there are some very strange situations where that would be good. But I doubt you can count cycles on todays processors with all their caching, out of order execution and branch prediction? Or would I be surprised?

You can estimate the upper bound (worst case analysis), but if it's a library call, you can't really tell what exactly is happening behind the call-- some sort of emulation or exact hardware support.

>>amigaksi wrote:
    Amiga is impossible to emulate for certain things on a PC.

>Yes? Excluding I/O.. what would that be?

Yeah, I posted some things in some places; but going by standards, sprite example would be one of them.  On my ATI graphics card, I get less than 100MB/second which would make a full screen of sprites impossible.  Then again there's the reading of joysticks, timers, sound sampling rate accuracy, etc.  

>>amigaksi wrote:
    I would like to know what target machine (spec) you are comparing to since I have seen Macs emulated on Atari ST, Amiga, and various PCs and newer so-called "Macs". That way we can better tell whether they can be called "Macs".

>I was thinking modern x86 based systems.

My brother got rid of original mac/documentation so can't really try out to see whether it's specs are subset of modern x86 systems.

>Surely it can? The bandwidth of DDR2 + 16x PCIe + 2.4GHz Core2Duo means the CPU can erase and repaint a 320x240x8 screen many thousands of times per VBL?

Try it out.  I could not get it done on modern systems.

[amigaksi]

>by A6000 on 2008/8/31 11:52:47

>@DavidF215
>Good post, wrong website - this one's filled with amiga haters.

Some are poor souls mislead by misinformation or their own misunderstandings.

[amigaksi]

>by persia on 2008/9/2 19:09:15

>Yeah, low-res analogue non-HD video, that'll confuse the heck out of most people today, maybe you could add a punched card reader too...

Believe it or not for compatibility reasons, I would still go with NTSC non-HD video and MPG4 has its own unknown loss in the spatial domain associated with editing.  I have seen deltas ranging from -128..127 on primaries after decompressing/recompressing and comparing with the original data.

[amigaksi]

>by mdwh2 on 2008/9/2 19:00:43

>>amigaksi wrote:
    Alex is right in trying to repaint the screen because the ORIGINAL point is showing a screen full of sprites on a system that does not have sprites.

>Right, I understand this -

You don't because later in your post you state the samething-- let the hardware do it.  You can't let the hardware do it, if the argument is how to render sprites on a system that does not support hardware sprites.

>and even if you have to repaint every pixel by CPU, this is easily possible on modern hardware.

That's not the argument either.  This is a straw man argument.  When you emulate accurately some aspect of the system, you have to meet or exceed the requirements; here I PURPOSELY used the words REAL-TIME sprites meaning you have to meet the real-time constraints of the original item you are trying to emulate.  So back to the point, if the Amiga 1000 OCS can render 30 sprites in around 40 microseconds, you have to do the same in the new system in 40 microseconds or less.  IT HAS NOTHING TO DO WITH REFRESH RATE.  Imagine a scenario where besides the 40 microseconds, all the other time is being used to send pulses through the I/O ports or the Amiga is in HALTed state and some other machine is controlling some medical heart/lung machine.

>>    Moreover, you missed another point-- that you have to use a standard graphics card/CPU not something that works on maybe your system and you are NO LONGER using a system that does NOT support sprites.

>What do you mean "works maybe your system"? 3D graphics cards that do texture mapping in hardware have been around for over a decade!

I know cards are around, but we're talking about standards.  AGP is the standard since most people nowadays have AGP or better cards.  I'll answer this further below.

>How old is your ATI card exactly?

Does not matter really since it has to work in most PC systems which would require doing it in software not relying on some sort of "sprite" hardware being present.

>Software written for graphics cards will work on any make of graphics cards (although there may be some differences, this is in areas that is way beyond what any Amiga chipset ever did) - unlike banging the hardware, which won't work on anything, possibly not even a newer version of that chipset from the same company (consider all the OCS vs ECS vs AGA incompatibilities).

That's wrong.  OCS banging works just fine for ECS/AGA as far as I have tried it and thus good for this argument.  On the contrary, you can't be sure the graphics cards will support certain hardware features that you may be relying on.  And some software/OS/drivers may shut down certain hardware features without you knowing it.  And there are more bugs in these software/OS/drivers than in OCS/ECS/AGA compatibility.  So maybe it will work using a device driver and maybe it won't.  Hardware banging is allowed for by Commodore themselves in the Hardware reference manual as I already explained.

>If you're rendering from hardware, the CPU doesn't need to do a thing.

We're not sure if hardware is present, so we need to take the worst case and do some algorithm like (after pasting sprites in appropriate areas):

Mov ECX,640*400/4
CLD
Mov EDI,VidMem
Mov ESI,BitMapPtr
Rep Movsd

>You don't need "sprites", because any bog standard (or even several years old) PC will do it in hardware. You don't need latest and greatest - that was just an example of what modern hardware is like today - a 10 year old Voodoo would do it.

It's not a standard and some AGP cards do not support hardware sprites.  Regardless, the argument is to emulate sprites in systems that DO NOT support it in hardware.

>But even if we restrict ourselves to a CPU solution, I don't see why this is not possible. The obvious example would be a software 3D renderer, which has to redraw the entire screen many times a second. That was being done a decade ago with Quake - now computers are doing things like real time raytracing!

See now why this is called a straw man's argument.

>>    Duh! Perhaps, I should put in Video Toaster in my machine and use that to my advantage as well and some other souped up attachment that only works on my Amiga.

>Okay, fine - and what will it be able to do better, compared with modern hardware?

Another straw man argument.  Never said I'm trying to beat out modern hardware; since you kept picking some 100GB graphics card, I started picking up some hardware which is nonstandard for Amigas.  I purposely picked OCS Amiga as an example not even AGA to stick with bare standard where you know exactly what is happening in a REAL-TIME set up.