Is Amiga Emulation better than the real thing?

[bloodline]

stefcep2 wrote:

bloodline wrote:
@stefcep2

Don't blame either your computer or UAE for your inability to configure UAE... Would you like me to send you a config?

Oh I can configure Winuae ok:  

Well, clearly not... :-)

I have about a dozen different configs ranging from a 1.3 1 meg ecs A500, through to a 3.1 AGA 1200 with 4 meg, through to a A4000 68040 with P96.  I have also run all of the preconfigured hard files eg AIAB, Amigasys, Amikit, Amiga Classic, even my own A4000 os3.9 install.

Yes, but have you tuned the emulation for the hardware? if you want a perfect experience you have spend a bit of time to try every setting in isolation, and then in various combinations to get the very best emulation.

Its nothing to do with configuration, its everything to do with the fact the emulator is running on top of the host OS, using the host's hardware and graphics drivers to re-target custom chip calls to equivalent functions on the host hardware.

But that isn't how it works...

The software, UAE, actually pretends to be the hardware... there is no re-targeting of calls (except in the RTG emulation)... the Amiga display is built entirely in software and then simply displayed via the host OS.

Sometimes directly equivalent functions exist on the host system or are approximated well enough that you don't notice, sometimes that doesn't work.  Winuae is good but NOT the same as the real thing, yet.

The Amiga was once considered impossible to emulate due to the very tight timings between the chips and the shear number of operations that need to be performed in the right sequence... If the emulation gets anything wrong, things go downhill fast!

[bloodline]

arkpandora wrote:
@stefcep2

Not really. The classic Amiga graphics software such as DPaint, Brilliance, functioned differently to the "24 bit in a window" packages such as Photogenics and Art Effect. Brilliance could work in 24 bit but the way it went about things was very different. Those 24bit in a window programs were trying to imitate the Photoshop way of working, with the use of layers: this type of graphics software didn't originate on the Amiga.

Similarly the 3D first person shooters such as AB3D and Gloom where attempts to copy what the PC was doing with Doom.

I'm not denying that some of these programs have imitated PC programs. You said that "the PC's processing speed and superior graphics display speed made all the difference" : what I mean is that these software were born on the PC because of the latter's popular favour rather than any power advantage.  Favour is also the reason why similar concepts were not developed on the Amiga at the same time : from that point of view there was no imitation, just delay.  

The Amiga was developed with planar graphics, as due to high memory prices in the early to mid 80s, it made sense to allow programmers to chose their colour depth and make a trade off between graphical quality and memory usage.

But the time PCs started to use bit mapped graphics, the late 80s and early 90s, memory prices were much lower and more CPU friendly (ie faster) packed pixel format was used. When people wanted to move beyond 256 colours, palette based gfx were no longer practical... and the chunky pixel formats could easily hold the colour component data within the actual pixel itself.

The Amiga was stuck with the graphics system that made great sense in the mid 80s... but really kinda sucked by the 90s, lets not even talk about the horrifically slow bus that these chips were bolted onto...

Commodore squandered the Amiga for 6 years... and the AGA chipset was only just acceptable by the time it was released (being little more than an upgrade to the Denise chip)...

The PC graphics subsystems were suited to large resolutions with high colour depths, They were simply better. That is why these applications were developed for the PC and not the Amiga... which already had a history in the graphics field!

As software quality has influenced success hence hardware development, eventually this favour also led to hardware advantage.  But originally this mighty favour was only driven by psychology and marketing : it was not justified by any power advantage, except to my knowledge the small advantage Intel had over Motorolla processors.

By the early 90s when people started to demand better Graphics... The PC was not lumbered with a 5 year old graphics system, for which compatibility had to be maintained... Motorola were not developing the 68k as fast  as intel were pushing the x86 (I imagine resources were starting to drift to the PPC teams... or at least the 88K teams...)... hell, by 1990 almost every PC had an MMU as standard... often they had FPUs...

The PC was expensive but offered more power and better graphics, that is where it's popularity stemmed from.

Had Commodore kept up R&D budgets... the world today would be somewhat different.

[bloodline]

arkpandora wrote:
@bloodline

Ah, I prefer this to your insults.

I can do both.

I don't quite follow you, but my technical knowledge is poor.  Do you mean that Amiga graphic cards too are stuck in this planar system ?  

No Amiga graphics cards are built using the same chips as PC graphics cards.

In order to compare a 1990 PC with a 1990 Amiga for example, you have to compare machines that both have a graphic card, or it makes no sense to me, as the PC had no custom chips on the motherboard.

The Amiga was a little bit cheaper than the PC at the high end of the Market. But for the little more that you paid with the PC you got better Graphics. With the Amiga you had to pay the price of the Base machine and the graphics card, this pushed costs to far more than the PC. Plus the Amiga Operating system offered little support (ie none) for these graphics cards. This support had to be added by third party and were often buggy and incompatible.

If you want to compare the Amiga's custom chips to what corresponds to them in the PC world, you have to compare two portable computers (because portable PCs had built-in graphic devices on the motherboard), and then you have to compare an A500 to a 1986 portable PC, as "portable" Amiga availability around 1990 was already negatively influenced by the PC's sucess.  

But in the time frame we are looking at, neither the A500 or the "portable PC" would have been used for serious graphics work.

And from this only comparison you have to conclude that the Amiga had better graphics than a PC, and that the PC's success was independant of graphic processing power.

The Amiga had better graphics at the low end of the market, fine for the type of games available in the 80s and early 90s.

At the top end of the market the Amiga was considerably more expensive to achieve the same results.

So you can't compare the PC's graphic devices to the AGA chipset since the latter is a consequence (not a cause) of the PC's supremacy, which began as soon as the late 80's when most journalists chose to ignore the Amiga 2000 and 3000, in other words the Amiga's power and evolution, especially video gaming magazines.

AGA should have been included in a minor 1988/1989 update to the A500. It is after all little more than a new 24bit Denise chip.

The A2000 is just an A500 with ZorroII slots... the A3000 offered more CPU power, but at considerable cost and with the reason I mentioned above interms of gfx power.

Consequently, in the early 90's it's already too late to attribute the PC's success to a power advantage.  That's why, to my knowledge, the PC's sucess and power advantage are both the consequence of journalism.

The advantage was economic. Amiga's stopped being value for money at the high end graphics market in about 1991... and the low end of the market by 1993. This was Commodore's fault. They assumed that the Amiga like the C64 would just sell, without the need to constantly innovate.

However I agree that Commodore's reaction was inadequate.  But I'm pretty sure that Apple with the same reactions would have survived because Apple did not suffer from journalism (I am caricaturing to make short but I can illustrate).

Apple had a better marketing team, and were more prepared to take risks with innovative devices. Commodore's only achievement was to get the Amiga from the original prototype to market... The A500 was also brilliant, but late... that should have been on the cards with the original Amiga release... certainly within a few months.

[bloodline]

Hammer wrote:

 don't have Slamtilt, but I do have Pinball Illusions AGA.

My WinUAE settings for playing PI-AGA

Model: A1200
ROM:KS ROM v3.0 (A1200) rev 39.106 (512k)

Settings
_Filter:
___PAL/50
_Display:
___FullScreen+VSync
___Render Every Frame
___FPS adj:50

_Chipset
___Cycle-exact
___Sound Emulation, 100 percent
___NTSC: FALSE
___Collision Level:FULL
___Faster RTG: FALSE
___Chipset Extra:A1200

I can confirm that these settings also give perfect video on my MacBook Pro runing WinXP SP2 using WinUAE.

Hammer wrote:

The software, UAE, actually pretends to be the hardware... there is no re-targeting of calls (except in the RTG emulation)... the Amiga display is built entirely in software and then simply displayed via the host OS.

Don't forget AHI, Warp3D, Midi.

I did not wish to confuse the issue and was referring only to Graphics which seems to be the major concern of posters in this thread.

[bloodline]

arkpandora wrote:
@bloodline

No Amiga graphics cards are built using the same chips as PC graphics cards.[/quote]

None ?  And were they significantly less powerful than the PC graphic cards of the same technological generation ? -- I don't mean the same "era" as the delay between PC and Amiga hardware, at the time of the Amiga graphic cards, may be attributed to other factors than power difference between the two standards.
[/quote]

My original sentence should have read:

No. Amiga graphics cards are built using the same chips as PC graphics cards.

Stupid . button failed me.

[bloodline]

-D- wrote:

Hammer wrote:

This also goes for an emulator output set at 50 FPS "synced" to a display refresh of 60Hz

The catch is "FullScreen + VSync" which disables "FPS Adj".

Ah, well, that's where the discrepancy was then. :-) (I'll trash the post I was going to submit basically reiterating what was already said).

BTW, the videos I was going to post:

1. SOTB III (NTSC version), @ 60 FPS/60Hz display refresh, to illustrate very nice scrolling with WinUAE

2. SOTB III (PAL version), @ 50 FPS/60Hz display refresh, to illustrate an unsynchronized emulator/display refresh

For some people, # 1 still isn't QUITE as smooth as the old hardware, my opinion is it's very close, and the differences that do exist might yet be down to some type of configuration problem. (Basically, I haven't screwed around with it enough to know for sure, looks pretty good to to me though.)
 
The only issue you might have is that some amiga stuff was coded for either PAL or NTSC timings, so running, say, a PAL demo at 60 FPS/60Hz might show some weird artifacts (though this is no different from the original hardware).

Running SOTB II doesn't work properly at 60fps, the audio is all messed and the games play too quickly. Instead you have to set the 50fps VSync option.

[bloodline]

mauidj wrote:

persia wrote:
Absolutely yes, who needs old hardware?  Emulation is fast, simple and doesn't take more space on your desk and you can have as many Amigas as your memory allows!

Damn...how'd you do that?
I want it! :headwall:

I don't mean to sound rude... well ruder than I already have been, but are you quite sure you are up to the task of using a computer?

http://www.apple.com/downloads/macosx/unix_open_source/hitoro.html

[bloodline]

mauidj wrote:
For someone not wanting to sound rude you are not doing a very good job.
Thanks for the put down.  :-(
All I wanted was some help.
Obviously came to the wrong place.

Ok... follow the link I provided, and download the Hi-Toro program... It really should be self explanatory from there on... If you have troubles then you might want to read the supplied documentation...

[bloodline]

@amigaski

You really have no idea how an emulator works do you!?

The timing of operations within the emulator must be consistent within the emulator world, not the real world. That is to say operations must be performed within the documented number of emulator cycles... If this is true, then software running on the emulator will function perfectly. Secondly, if the host CPU can run the emulated cycle faster than a real hardware cycle (thus the emulator can then wait until a real cycle would complete), the user will experience will be perfect.

Now which bit don't you get?

-Edit- bah! Shaggoth said it better :-D  

[bloodline]

amigaksi wrote:
>by shoggoth on 2009/1/23 3:54:26

Quote:
--------------------------------------------------------------------------------


amigaksi wrote:
I am clear on what I stated and am sticking to it. I already explained that-- you are just calling it "timing", but it has nothing to do with actual cycle time. But you can write applications (and many already exist) where this cycle time is measuring actual time.


--------------------------------------------------------------------------------


>Ok, so what you're claiming is that no matter how accurate an emulator is, you could write an application that can detect that it's not the real deal?

I don't need to do anything special to detect it's the real deal.  For example, if I shift right the VHPOSR by a few bits and add them to some counter and use that counter overflow to draw a pixel on the screen, you won't get the same effect on the emulator unless you have timed the VHPOSR using a real timer.

As long as the VHPOSR and the counter are synchronized to the same clock, then the effect would be the same as on the real hardware, taking your unstated assumption that they are synchronized to the same clock on the real hardware...

[bloodline]

amigaksi wrote:
>As long as the VHPOSR and the counter are synchronized to the same clock, then the effect would be the same as on the real hardware, taking your unstated assumption that they are synchronized to the same clock on the real hardware...

Hey, we agreed on something.  Just name the clock or register on the PC that you would use.

Given this is a display issue, I would sync it with a virtual electron beam, as Long as the PC can perform all the operations required by the emulator before the real hardware could do it, then by the time of the screen refresh (the point where both the emulator and real hardware interface with the human), the states of the Emulator and the real machine would be identical.

-Edit- @Chaoslord :-D

[bloodline]

amigaksi wrote:
by bloodline on 2009/1/23 9:13:16

amigaksi wrote:
>>>As long as the VHPOSR and the counter are synchronized to the same clock, then the effect would be the same as on the real hardware, taking your unstated assumption that they are synchronized to the same clock on the real hardware...

>>Hey, we agreed on something. Just name the clock or register on the PC that you would use.

>Given this is a display issue, I would sync it with a virtual electron beam, as Long as the PC can perform all the operations required by the emulator before the real hardware could do it, then by the time of the screen refresh (the point where both the emulator and real hardware interface with the human), the states of the Emulator and the real machine would be identical.

>-Edit- @Chaoslord

If you had the Amiga VBI perfectly synched to PC VBI, than you would be resynching every 1/60 second, but still what happens in between those refreshes will be out of sync given different cycles times.  Usually, PC VBI isn't the same rate as Amiga VBI and PC emulation has the latency to begin with and may also be out of phase.

I'm not even sure anything you just said made any sense... But hey ho... I can easily run my gfx cards at 60hz, then use the gfx card's VBI to sync the emulation's virtual VBI to the real world... That would give me a nice NTSC emulation. But if I want a 50hz interrupt for PAL emulation, then I would run the gfx card at 100hz and sync the emulation every two real frames. Given the fact that re granularity of this system is based on the frame rate, since a human being's senses are being refreshed at 50/60hz on both the real and emulated Amiga (and the fact that a PC can do all work that a real Amiga can normally do in 25ms, in ~1ms so it spends most of it's time just waiting for the sync), the emulation and real Amiga will be in the same state WRT the user at all times. This really is elementary stuff...

[bloodline]

amigaksi wrote:
>>If you had the Amiga VBI perfectly synched to PC VBI, than you would be resynching every 1/60 second, but still what happens in between those refreshes will be out of sync given different cycles times. Usually, PC VBI isn't the same rate as Amiga VBI and PC emulation has the latency to begin with and may also be out of phase.

>I'm not even sure anything you just said made any sense... But hey ho... I can easily run my gfx cards at 60hz, then use the gfx card's VBI to sync the emulation's virtual VBI to the real world... That would give me a nice NTSC emulation. But if I want a 50hz interrupt for PAL emulation, then I would run the gfx card at 100hz and sync the emulation every two real frames.

NTSC rate isn't exactly 60Hz, it's more like 60/1.001.  And anyway, your video card isn't doing 262.5 scanlines per field nor is a user response showing up in same time as on emulator given the buffer approach.  

True actually, NTSC is 59.98 or something and that is very slightly too slow but I know the human eye can't see the difference between the two rates... And I personally run my stuff in PAL anyway and 50hz is possible on modern cards by halving the 100hz rate. As for your dislike of the "buffer approach", I suggest you throw away all your amiga games as they all use double buffering... Have you ever writen a game on an Amiga?  

>Given the fact that re granularity of this system is based on the frame rate, since a human being's senses are being refreshed at 50/60hz on both the real and emulated Amiga (and the fact that a PC can do all work that a real Amiga can normally do in 25ms, in ~1ms so it spends most of it's time just waiting for the sync), the emulation and real Amiga will be in the same state WRT the user at all times. This really is elementary stuff...

Not true so not elementary.  For example, if Amiga moves a screen full of sprites in a few microseconds, the PC will take much longer since most video cards can't update their display in a few microseconds so emulators will hope that time will be made up for by other things.  Our senses aren't being refreshed at 60Hz on real Amiga but higher frequency.  Only display is around 50/60Hz.

A modern gfx chip can redraw an entire screen, perform thausands of blitter operations and render a 3D scene... At many times the resolution of the Amiga in far less time than it takes for an Amiga to update the sprite registers...

[bloodline]

ChaosLord wrote:
Bloodline wrote:

I suggest you throw away all your amiga games as they all use double buffering... Have you ever writen a game on an Amiga?

I have, and so have some of my friends.  None of them use double-buffering.  AFAICT double-buffering is only really useful when displaying an FMV movie.  It is often a mistake to double-buffer a whole game on the Amiga.  The Amiga has real-time beam position knowledge with approximately 1/21000000th second resolution (if you want the exact number then consult your HRM).

Unless you are only using sprite and static sceens (or hardware scrolled screens), no double buffering will look like crap... All blitter ops will look nasty... The blitter was the best thing in the Amiga chipset... IMO

[bloodline]

ChaosLord wrote:

no double buffering will look like crap... All blitter ops will look nasty

Wrong.  It all depends on what you are blitting and if you are making use of the Amiga chipset's awesome features (Jay Miner rulez 4eva) and how you have written your code.  Some games require double-buffering and some do not.

I'm not going to be drawn into a debate as to the "correct" usage of the Amiga chipset, suffice to say if you want make a game that looks really good you need to use the blitter quite extensively, and the slowness of the blitter will need to be smoothed out with double buffering, which I might add the Amiga chipset was rather well suited to.

On topic, I could easily set up an Emulation that no one here would be able to tell from a real Amiga... I have just such a WinUAE set up on my MacBook Pro for running Shadow of the Beast II...

[bloodline]

amigaksi wrote:
>A modern gfx chip can redraw an entire screen, perform thausands of blitter operations and render a 3D scene... At many times the resolution of the Amiga in far less time than it takes for an Amiga to update the sprite registers...

You need to calculate this out and you'll see that modern graphics cards cannot redraw an entire screen (repaint).  If they have built-in similar hardware sprite-type stuff, they can probably keep up.

Sorry amigaski, I hate to use the phrase "you're wrong", but you really are... The weakest gfx card I own is able to push 3.4Gigabytes per second... The amiga struggles to keep up with 2megabytes per second and this is using AGA!!! The Amiga is Very Old technology, it is very slow and lacks the resolution and colour depth of modern hardware... It can't compare!