What are the advantages of the present/future Amiga?

[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.

[amigaksi]

I missed this post from you.

>by alexh on 2008/9/1 4:40:52

>But we were talking about from the USER perspective! (OS + applications). The discussion concerned "Was a MAC was really a MAC if it had an INTEL processor?"

Okay, user does not have to know specifics but in general so at least the user can buy the machine.  

>>    amigaksi wrote:
    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.

>And you see the point that at the user level no-one cares! And if the OS designers and application programmers have done their jobs properly they do not even notice.

Okay, as above.

>>    amigaksi wrote:
    The defined bits are 100% backward compatible.

>True, but the softies never listened.. they never do. Why use extra cycles to mask off those reserved bits when you can just overwrite them and it doesn't do anything

Okay, but that does not change the fact that they can be used as backward compatible.  Personally, the only bugs I saw in running my OCS games on ECS/AGA were fastmem/chipmem allocation, calling older version OS routines and other stuff unrelated to the spec of OCS.  And going to the hardware will always be more efficient than going through an API especially in a real-time system where you need to estimate a worst case scenario.  And even if there were a few bugs in the chips, one can test the application easily on the OCS/ECS/AGA (and use it as per spec) whereas it would be harder to estimate the worst case for hundreds of graphics cards w/drivers and various versions of OSes especially since there's always some sort of list of bugs and due to some system-specific effects.  
  Of course, as far as Amiga sprites go they still won't function in software on modern graphics cards even with the overhead of Amiga API taken into account and even at 320*240 resolution.  Just tried it on NVIDIA GEFORCE 6100, but be my guest to try it on your system.

[amigaksi]

>by mdwh2 on 2008/9/4 17:14:49

>>Quote:
>>    amigaksi wrote:
    Of course, as far as Amiga sprites go they still won't function in software on modern graphics cards even with the overhead of Amiga API taken into account and even at 320*240 resolution. Just tried it on NVIDIA GEFORCE 6100, but be my guest to try it on your system.

>Do you have a program (and preferably the source code too) for us to test? I'd be curious to see what you are trying to do, and maybe someone can see why it isn't working so well.

Why don't you just do some random search and get a URL like: http://en.wikipedia.org/wiki/Amiga_4000 and "PROVE" that there are no sprites on the Amiga 4000 (or similar system) to argue about.  Instead the Amiga 4000 has 48-bit color, 256 Hardware audio channels, ...

I tested it with a software sprite engine contained within the Gita CDROM produced by our company (see our website) which has been thoroughly optimized and allows you to select Windows API method of rendering imagery or by writing directly to the video card hardware and also lets you select various VESA modes where supported.  

[amigaksi]

>by shoggoth on 2008/9/6 6:25:20

>Amiga isn't impossible to emulate accurately. Emulation is always a trade between performance and accuracy. I've seen claims like this numerous times for different platforms, but technically I haven't seen anything that explicitly prevents accurate Amiga emulation. The possibility of emulating Amiga hardware doesn't make the Amiga less attractive, quite the contrary imo.

Do you agree that technically it's more accurate to measure something with a ruler marked with cm rather than inches?  If so, then you will also agree that having a timing mechanism to accuracy of 1/3.579545Mhz (Amiga) is more accurate than one at 1/1.19318Mhz (PC).  Opinions are only good if you don't have the facts.

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

>Sure you can. Just look at other platforms from the same era, or even earlier. On a modern machine it's not an issue at all.

Whether in the earlier era or now, hardware sprites are always better than software ones.  I saw the terrible/flickering games on earlier systems w/software sprites.  Anyway, the keyword you missed there is real-time...

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

>Yeah. But you can achieve that even on a sprite-less mid/low-spec 68k machine.

>Sprite hardware is cool, and on a 7Mhz 68k machine it really makes wonders. It's not some holy grail of performance in todays computing, however.

You can use about 30 Amiga hardware sprites to cover up almost the entire screen using about 40 microseconds of CPU time.  There's no way you can stamp sprites on a background image (320*240 or 640*400) and send the data to the video card in 40 microseconds or less.  You'll be counting in milliseconds.

>>    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 can achieve the same in software even on a mid-spec 68k machine. Either you have no clue, or I completely misjudged the core argumentation here.

Well the argument became dual core as the thread went-- drifted from original focus.  You can compute the stats yourself.

[amigaksi]

>by Hammer on 2008/9/6 9:54:24

>>Do you agree that technically it's more accurate to measure something with a ruler marked with cm rather than inches? If so, then you will also agree that having a timing mechanism to accuracy of 1/3.579545Mhz (Amiga) is more accurate than one at 1/1.19318Mhz (PC). Opinions are only good if you don't have the facts.

>Do you agree that technically it's more accurate to measure something with a ruler marked with cm rather than inches? If so, then you will also agree that having a timing mechanism to accuracy of 1/14.3818 MHz (PC) is more accurate than one at 1/3.579545Mhz (Amiga)?

>There are several timers in the X86 PC..

But there are a couple of issues you missed: (1) Sure, Amiga is hardware and one can build hardware that is equal to or better than it.  However, I picked a standard OCS bare-bone Amiga 1000 when compared to a standard PC whose timers are at 1.19318Mhz as late as the latest one I bought a couple of years ago. I can't take some application that uses some new "14Mhz" timer and walk into someone's home/office and run it assuming it's useable to it's full accuracy.  In fact, I don't even I see any API reference for it in the XP SDK.  (2) The timing accuracy is not just for the timer IRQ, the Amiga timing also applies to the audio sampling rate, copper-based register modifications, reading certain registers, etc.

>The minimum resolution with this APIC-based timer is in the magnitude of microseconds. With the bus speed of
100 MHz for 2001 era X86 PCs, the minimum resolution should be 0,1 microseconds (1/100 MHz). But due to the calculation time needed for switching to the interrupt service routine (e.g. saving context info) the achievable accuracy is about 1 microsecond. This is a 1,000 to 10,000 times higher precision than the pre-APIC PC timer.

Ahm, the old PIC is accurate to 838 nanoseconds not microseconds.

>There's High Precision Event Timer (HPET) in Windows...

It has to be in hardware first to be in Windows.  Not supported in XP which most people that I know have still.  Let's stick to standards here as I can also plug in some easy-to-build timing card into an Amiga and start timing things at 1/28Mhz accuracy (whose clock line is available on the system board).  But it won't work on standard Amigas.

>If you want to hack/learn the latest X86 hardware, its better you go via Linux.

No, not hacking/learning X86 hardware, just trying to use the standard X86 hardware directly so it works on most systems.

[amigaksi]

>by Hammer on 2008/9/6 10:38:02

>>Quote:
    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.

>Instead of re-encoding, refer to transcoding.

I don't see how that would help in preventing further loss if you modified the image according to transformations allowed for in real-time on Video Toaster or put some overlay text on the image.  It would only help if certain 16*16 blocks (or whatever block size you used) remained the same after the image transformation.

[amigaksi]

>by mdwh2 on 2008/9/6 10:44:23

>>...Just tried it on NVIDIA GEFORCE 6100, but be my guest to try it on your system.

>>    Why don't you just do some random search and get a URL like: http://en.wikipedia.org/wiki/Amiga_4000 and "PROVE" that there are no sprites on the Amiga 4000 (or similar system) to argue about. Instead the Amiga 4000 has 48-bit color, 256 Hardware audio channels, ...

>I can't see what that has to do with what I wrote?

Just warning you not to quote some random article on web like you did previously as I will accept deductive logic, something I can experiment on, and/or legitimate company document from Intel/Microsoft/etc.

>>    I tested it with a software sprite engine contained within the Gita CDROM produced by our company (see our website) which has been thoroughly optimized and allows you to select Windows API method of rendering imagery or by writing directly to the video card hardware and also lets you select various VESA modes where supported.

>Do you have any of:

>* A description of what it is you are trying to achieve?

Yes, software sprites on a PC at better or equal speed than Amiga 1000 OCS machine.  I spelled it out exactly by stating 30 sprites across the screen in 40 microseconds.

>* A link to the software you are running?

http://www.krishnasoft.com/krsna.htm.  This software contains the software sprite engine I am using.  It allows up to 256 software sprites w/priority settings and if you run it on your system and then go to preferences, it will give you the frame rate.

>* Along with source code?

Well, I gave you the Rep MOVSD example already.  All I was doing was copying a buffer and it can't achieve the 30 sprites in the 40 microsecond timing limit.  I am not even considering collision detection, priority settings, transparency, etc.

>>    You can use about 30 Amiga hardware sprites to cover up almost the entire screen using about 40 microseconds of CPU time. There's no way you can stamp sprites on a background image (320*240 or 640*400) and send the data to the video card in 40 microseconds or less. You'll be counting in milliseconds.

>As we've said, the existence of 3D software renderers (which are far more complex than just pasting 2D images) running on PCs over a decade ago at >25FPS shows this claim to be false. Unless we have misunderstood you claim, which is why I asked you above to explain what it is you are after.

Well, whoever that "we" refers to, they have misunderstood.  25 fps is only 40 MILLIseconds not 40 MICROseconds.  You may need to go back and edit your replies.  I am not interested in the frame rate, I am interested in meeting or exceeding the Amiga sprite speed.

[amigaksi]

>by shoggoth on 2008/9/6 11:07:14
>>   amigaksi wrote:
    Do you agree that technically it's more accurate to measure something with a ruler marked with cm rather than inches? If so, then you will also agree that having a timing mechanism to accuracy of 1/3.579545Mhz (Amiga) is more accurate than one at 1/1.19318Mhz (PC). Opinions are only good if you don't have the facts.

>Since when did hardware timer granularity dictate how accurately one machine can emulate another?

I gave you an example of something you would have to emulate using hardware that does not have that accuracy.  If you think drifting timers, audio playback, etc. aren't necessary, well then I disagree.

>words. To what extent have you engaged in emulator programming yourself? Any first hand experience?

I have infinite experience.  How much experience do you have that 2+2=4?  Deductive logic does not depend on experience.

>Realtime in this context is most likely connected to the VBL frequency (or HBL frequency for that matter). Having enough juice to provide a result equal to a machine having hardware sprites while still keeping an equivalent amount of spare CPU time to the application should be enough to qualify as "realtime" in this particular context. And that's not a utopia at all.

In this case real-time is defined as 40 microseconds to display 30 sprites using a standard machine.

>>    You can use about 30 Amiga hardware sprites to cover up almost the entire screen using about 40 microseconds of CPU time.

>No.

What are stating no to-- that you can't display 30 sprites or to the 40 microseconds?

>But put CPU cycles per microseconds into that equation - and add a 2-3x faster CPU. Sure, rendering the sprites constitutes overhead, but you'll still end up with more spare cycles for your application.

Sorry, you don't.  Do the calculations and experiment yourself.

[amigaksi]

>by Hammer on 2008/9/6 11:45:24

>>    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.

>Hint; texture compression. Which part of the "PC"?

A graphics card that handles sprites in hardware is not part of a standard PC.  Let's talk about Amiga/PC not digress to Capcom as I am not familiar with it's timers, sprites, audio sampling rates, etc. nor did I state anything regarding it.

[amigaksi]

>by Hammer on 2008/9/7 2:30:08

>>    But there are a couple of issues you missed: (1) Sure, Amiga is hardware and one can build hardware that is equal to or better than it. However, I picked a standard OCS bare-bone Amiga 1000 when compared to a standard PC whose timers are at 1.19318Mhz as late as the latest one I bought a couple of years ago

>Are you claiming nForce chipset having 80 percent of annual X86 chipset unit sales?

If I write a sprite program on an OCS Amiga 1000, it works on all Amigas; if I write a sprite emulation it should work on most of the PCs.  I don't care what graphics card you have and what it can do.

>Remember, annual sales for X86 PC are numbered into ~200 million i.e. just one month of unit sales exceeds the entire CBM Amiga unit sales. Most of them are based on Intel chipsets e.g. "Centrino" or "VPro" brand.

It's not the number; it's the compatibility.  If I target the best graphics card in the market, the software will fail in most machines.

>>    Ahm, the old PIC is accurate to 838 nanoseconds not microseconds.

>Does it include interrupt service routine? The maximum frequency supported by the standard PIC is 8192 Hz, which would result in interrupts generated each 122 us....

You must be using the Vista HLIs (Hardware Limiting Interface, a.k.a API).  You can get more than 8192Hz interrupts with old PIC.  Even the Atari Disk Drive simulator I wrote uses 63Khz.

>Modern PCs can handle Capcom System 2 in emulation.

Don't see what the point is here unless you are claiming Capcom is better than the Amiga in all respects.

[amigaksi]

>by Hammer on 2008/9/7 3:41:43

>Try ACPI. Windows XP's QueryPerformanceCounter API uses PMT.

>The various release of Windows differ in implementation
>PIT (Win2k),
>PMT (WinXP),
>HPET (Vista).

You know newer PCs don't change as much as they used to-- like going from EGA to VGA or ISA to PCI.   So many people don't upgrade to the latest machine especially if it's just for a timer or some CPU speed.  So just because some new timer standard is available, it does not mean you can assume most of the PC owners will have it.

>High Precision Event Timer (HPET) can be access is via memory-mapped I/O (address indicated by the ACPI HPET table), which takes 0.9 μs.

Well, that seems bad 0.9 us as just the emulation of an instruction like Move.w VHPOSR,D0 would require a higher accuracy.

>>    (2) The timing accuracy is not just for the timer IRQ, the Amiga timing also applies to the audio sampling rate, copper-based register modifications, reading certain registers, etc.

>X86 PC world prefers devices that are not tightly tied together i.e. so the platform can adapt and assimilate newer technologies (e.g. next GPU release in 6 month cycle).

Some people prefer not to throw away their machines as they are good enough for what they are doing.  I don't think they should have to throw them away.  And if the newer machines are not backward compatible, you would have to support the features that are.

[amigaksi]

>>http://www.krishnasoft.com/krsna.htm.

>The link seems to be dead...

Okay, it's without the period at the end:

http://www.krishnasoft.com/krsna.htm   .