What are the advantages of the present/future Amiga?

[Hammer]

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.

Refer to texture mapped 3D surface in modern GPUs.

As for pure software renderers;

With an appropriate SIMD capable X86 CPU (e.g. Intel Core 2) and Swiftshader 2.0 DX9b JIT X86 "driver", this setup rivals NV’s Geforce FX 5200/5600 GPU.

[Hammer]

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

One should read up on Pentium era APIC timer.

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.


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

To quote Microsoft

Timer Requirements
Chipset vendors should implement an HPET to comply with Intels "IA-PC HPET (High Precision Event Timers) Specification". This spec will be available on Intels web site in the second quarter of 2002 with royalty free licensing terms.

Microsoft is in the process of adding the requirements for the HPET to the Windows Logo Program for Hardware to check for the presence and quality of the HPET in chipsets. Although no timeline has been set in regard to when this hardware will be required for a logo, Windows Hardware Quality Lab (WHQL) tests will begin testing the quality of the HPET, if it is implemented, in the timeframe of the release of Windows Vista. Some of the requirements stated in Intels HPET spec are re-articulated below.


Windows Vista, Windows 2008, x86 based versions of Mac OS X, Linux 2.6 are known to use HPET.

"The accuracy of the main counter is as accurate
as the 14.3818 MHz clock."  - Intel Corp.

HPET is included in following chipsets/southbridges
Intel ICH5
Intel ICH6
Intel ICH7 (e.g. Napa platform),
Intel ICH8(e.g. SantaRosa platform)
Intel ICH9 (e.g. Montevina platform).
AMD/ATI 690 chipsets
AMD/ATI 7x0 chipsets
AMD 8111 chipsets
nVidia nForce 5 chipsets
nVidia nForce 4 chipsets

Refer to http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/30225022.aspx

To quote Intel support

Intel's answer:.  The HPET (High Precision Event Timers) is a component that is part of the chipset.  However, the firmware (BIOS/EFI) needs to enable it, and will provide you with the means to get to it via the various ACPI methods.

Intel(R) chipsets, since quite some time ago (at least a year, if not more), have HPET on board. However, not all vendors that sell machines with Intel(R) chipsets enable HPET in their firmware. Some have it as a BIOS option, and sometimes it defaults to Off.

Edited to add:  HPET has been productized and supported in chipsets since Intel® ICH5 (at least from a client perspective -- embedded and server/workstation specific chipsets may be different).

==

Lexi S.
Intel(R) Software Network Support

PS; To test HPET, Intel recommends Linux.

In this forums, you'll notice engineers from Mitac Technology Corporation i.e. ODM laptop vendor.

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

[Hammer]

See, here's the confusion. Mac's might run Intel CPU's, but they are not IBM compatible, missing several key 8-bit components. Hence why the Hypervisor mode to enable Windows to run, emulating the missing pieces. But whenever anyone mentions an x86 Amiga, they figure on bog standard boards. That will not work. At the minimum we'd need a custom boot loader, Kickstart embedded in the mobo you could say.

Instead of BIOS, Mactel uses Intel's UEFI.

[Hammer]

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.

[mdwh2]

amigaksi wrote:
>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 can't see what that has to do with what I wrote?

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?
* A link to the software you are running?
* Along with source code?

Because then perhaps we can see (a) what it is you are claiming, and (b) why it isn't working. If you are unwilling to do that, then we can't.

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.

Even the Amiga often used "software" sprites (blitter objects) because they were often more flexible.

[shoggoth]

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?

Opinions are only good if you don't have the facts. Your words. To what extent have you engaged in emulator programming yourself? Any first hand experience?

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

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.

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

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

[Hammer]

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"?

One has to pre-load the graphic/data (e.g. textures) assets into GpGPU's memory. Anyway, Radeon HD 3200 IGP(shared with main memory) handles Blu-Ray H264/VC1 @1080p without problems.

In http://www.tgdaily.com/content/view/38145/135/
"Radeon 4800 supports a 100% ray-traced pipeline".
Under CPU's command (i.e. using it as a "command processor"), the GPU handles the bulk of the workload.

NVIDIA's PhysX GPU offloads the physics calculations from the CPU i.e. the GPU directs vertices. Vertices can be generated or manipulated by tessellation unit, vertex/geometry shaders or stream processors in GpGPUs. Pixel shaders handles the look of the pixel. A texture mapping units rotates and resizes a bitmap to be placed onto an arbitrary plane of a given 3D object(a set of vertices) as a "texture".
 

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

*Cough* Capcom System 2 emulators .

How about ray-tracing in realtime @720p HD like Transformers movie trailers? Ops that's overkill.

Anyway, run Swiftshader 2.0 DX9b(Shader Model 2b) "X86 JIT driver" on Core 2 Duo @2.4Ghz and 4MB L2 cache. You will find that this Intel Core 2 based "GPU" kills OCS/ECS/AGA, 3DFX Voodoo 1/2/3/4, Capcom System 2, S3 Virge3D, S3 Salvage3D, S3 Uni-Chrome, NV RIVA/TNT/TNT2, NV Geforce 1/2/3/FX 5200, Intel Real 3D, Sony PS1/PS2, SNES and 'etc'. Any GPU below Geforce FX 5200.

[persia]

Sprites are to modern graphics systems as buggy whips are to space shuttles.  Sprites were a cheat in a way, you didn't have to power to really manipulate the image so you moved a few objects around it instead.

Sprites give that retro feel that we've come to appreciate as collectors of 80's computers but it really can't compare to current technology.

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

[Hammer]

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?

The PIC is included for legacy reasons.

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.

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.

It has to be in hardware first to be in Windows

Why Windows? What happend to AmigaOS or non-Windows X86 options?

If it's Windows, use DX API for gaming or multi-media titles. Refer to Hurrican (Turrican clone) as an example of "old" school style gaming.

Modern PCs can handle Capcom System 2 in emulation.

Hurrican (Turrican clone)
http://www.youtube.com/watch?v=-jk3DNTYx_w
http://www.hurrican-game.de/

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

Unless you can claim nVidia having 80 percent of the X86 chipset market, nForce chipset is hardly the "standard" X86 chipset.

Refer to http://www.windowsfordevices.com/articles/AT2503923807.html
Achieving hard real-time on Windows XP, XP Embedded via Venturcom's RTX extensions.

Seriously, if one wants to build a mission critical X86 platform with hard real time focus, refer to QNX X86 as an example.

[Hammer]

In fact, I don't even I see any API reference for it in the XP SDK.

It has to be in hardware first to be in Windows. Not supported in XP which most people that I know have still.

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

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

Other X86 PC timers;

The Power Management Timer(PMT) was added to the ACPI standard. Its purpose is to deliver timestamps.  Improvements over the PIT (8254 Programmable Interval Timer) are to be found in its higher frequency (3x), larger counter width (e.g. 24 or 32 bits). Can be acessed via 32-bit port I/O (address given in the ACPI FACP table); which takes 0.7 μs.

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.

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

Windows XP Embedded SP2 Feature Pack 2007 includes
"High precision event timer" (HPET)
http://msdn.microsoft.com/en-us/library/aa939400.aspx

2D sprites are a joke compared to 3D surfaces (Z-axis push/pull, rotate, mesh warp, per pixel lighting, alpha,  and ‘etc’). 3D surfaces can be manipulate by shaders(stream processors).

On Amiga’s front, why not compare AmigaOS 4.1 with hardware compositing (Radeon R100/R2x0 GPU) vs AmigaOS 3.9 with AGA.

AmigaOS 4.1 Composition Engine's desktop effects
http://www.youtube.com/watch?v=-MhrbzWePz0&feature=related

MorphOS 2.0's desktop effects
http://www.youtube.com/watch?v=CelcOZMrjuY&feature=related
http://www.youtube.com/watch?v=jg8JkBa32Wg
http://www.youtube.com/watch?v=Wbg07NqDmzU&feature=related

[Hammer]

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.

The link seems to be dead...

In that case, I’ll be using vertex instancing features (reuse and copying the same object 256 times) or create simple 256 3D surfaces with different 640x480 textures. Alternatively, open 256 calculator apps (open @640x480 size) on Vista then click on Win key + Tab.  

If I have a job to do quick 2D game, I'll look into DarkBasic or VisualStudio .NET/XNA.

[mdwh2]

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

Which link? About the NVIDIA card - are you disputing that it has those capabilities?

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.

How many sprites does the Amiga allow? I thought it was 8 on OCS?

How are you measuring the speed on the Amiga side? Or indeed, how are you measuring the speed on Windows? The usual way to measure performance on Windows is the fps, which is unlikely to ever be as high as 25,000 - but then I'm not convinced that the Amiga could ever do this either.

Why is the performance of one particular thing important? All that matters is overall framerate, which just needs to be at least as good as the refresh rate of the screen.

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.

Sorry, I misread as at one point you said 40ms, which means milliseconds. Still, the theoretical peak output of the fillrate of modern graphics cards should equal this if not beat it, but measuring it is hard when you usually only look at final FPS.

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