real amiga vs winuae

[Hammer]

Hi,

@danybebe,

Depends how much you are willing to spend, I have an Amiga 4000 and an Amiga 3000, to play a lot of the games you have to look to see if it is pal or ntsc, then you have to look at what kind of graphics it uses, aga or occ or ecc, then you have to decide wheter or not it needs the program degrader, keep a pen handy so that you can mark all your disks with what it took to start up that software on the Amiga you decide to use.

Now the Emulator, I use AF2008, on a Quad Core, it is super fast, the music rarely slows it down but does not give the same sound quality as the original Amiga, the graphics are a little blocky compared to the original Amiga (i will probably get flamed for this but i will try to explain) the pc uses square pixels while the Amiga used round pixels the round pixels seem to blend better than the square pixels on the PC you can especilly see this in some old Amiga demos, while they looked good on the orginal Amigas they look squared out on the PC emulation. I use Amiga forever with Amikit, and am completely happy, but once again getting your software there and running is sometimes a pain, you have to try to convert it over with WHD or something like that. I can't remember the program since I bought a CD off ebay with something like 3500 games on it in this format, with AF 2008 it loads it right in off the CD.

smerf

I use to have an Amiga 3000/030@25Mhz connected to a PC SVGA monitor and the pixels are not rounded.

[Hammer]

Hi,

I had my Amiga attached to a Panasonic monitor and te pixels were rounded.

smerf

The dot pitch is not small enough. 320x200 NTSC on a good 15 inch SVGA monitor shows blocky pixels and they not rounded.

[Hammer]

I never tried to impress upon anyone my knowledge of Amiga hardware.  Perhaps, that's what you are trying to do.  I was just asking someone about Pegasos which I never heard of before.  I don't have any 68060 system so I stated my comments with "if".

>So, to suggest that the 68000 was not an integral part of the overall hardware design, is frankly bollocks.

If you did not rely on the timing of the 68000 in your code and just relied on the instructions getting executed and used the CIA, Copper, and other timers for the timing, then it shouldn't matter if it's 68000, 68020, or other backward compatible processor.

>Faster CPU's only work in there thanks to the Fast RAM side of the design. The moment you put even a 68020 into the original design, without Fast RAM, it is crippled. It doesn't fit into the original one access every 2 cycles design as it is capable of a memory access every cycle and is thus forced to wait. Even with Fast RAM, thanks to the instruction cache, it's also no longer compatible with just "any old" 68000 code. Anything self modifying is doomed to fail spectacularly since the instruction cache is never, ever written to by data writes.

The 68020 is still called backward compatible with 68000 just like Pentium is backward compatible with 8088 although it has similar problems with caching.

Somebody needs to read up on Pentium Pro/Pentium II's handling of self-modify code and cache.

Part1

Part2

[Hammer]

Your first link states that this book cannot be used.  

It can be used, but be aware of performance penalties. Most X86 desktops includes a working cache coherency hardware.

The point is caching did affect self-modifying code on later than 8088 processors (not just Pentium I/II) but they are still considered backward compatible.

AMD K8 (which includes Northbridge) keeps the instruction and data caches coherent in hardware, which means that a store into an instruction closely following the store instruction will change that following instruction. Other processors, like those in the Alpha and MIPS family, have relied on software to keep the instruction cache coherent. Stores are not guaranteed to show up in the instruction stream until a program calls an operating system facility to ensure coherency. The idea is to save hardware complexity on the assumption that self-modifying code is rare.

The reason why AMD K8 includes additonal hardware complexity is to support for self-modifying X86 code.

For Intel Core 2, Errata AW46 i.e.
"Self/Cross Modifying Code May Not be Detected or May Cause a Machine Check Exception"
Workaround: It is possible for the BIOS to contain a workaround for this erratum.

I assume you know about Intel micro-code patches.

This issue was fixed in E0 and R0 stepping.
AW = "Intel® Core™ 2 Duo processor E8000 series".

[Hammer]

I know some processors also had turbo/normal mode
.

My post has nothing to do with clock speed changes.

to even have compatibility with tasks that used the processor speed to time things.  However, as it stands the 680x0 series and x86 series are considered backward compatible even with different processor speeds and some differences in pipelined/cached instruction execution.

Except 680x0 is a bit fuzzy when comes to legacy support.

[Hammer]

My point was some processors did have that extra compatibility features like clock adjustments, but even without that they are still considered backward compatible.  If you want to state the "fuzziness" is 68000 instruction execution, then give example(s).

As an example, 68060 and 68040’s software instructions emulation. Then you have ColdFire.

In terms legacy investment while moving forward, nothing beats X86.

[Hammer]

I know some processors also had turbo/normal mode to even have compatibility with tasks that used the processor speed to time things.  However, as it stands the 680x0 series and x86 series are considered backward compatible even with different processor speeds and some differences in pipelined/cached instruction execution.

I was referring to self-modifying code and how the modern X86 CPU handles it i.e. X86 world added additional hardware. Motorola is !@#$%^&-all on legacy.

[Hammer]

I was saying both x86 and 680x0 are considered backward compatible.  I have been able to run all 68000 software on AGA machines except those that rely on processor frequency being fixed at 7.16Mhz.  If the frequency/timing does not matter to application (application does not use it internally as a factor), then as long as 68060 can execute the instructions in equal or better time, it's fine however it executes those instructions.  Emulate = "equal or excel" here.

Ahem... 68040.libarary...

[Hammer]

Never had any of those libraries in software I tested or even if it were present in some disks in some folder whether it was actively loaded and being used.  I put in a 68020 board in A2000 and didn't install any libraries-- ran the same software as before.  And some of this software is just a complete ANIM file and player software-- no 68020 or 68040.library.

It's abit pointless to use 68040.library on 68020 based machine.

[Hammer]

Sorry, I was away for a few days; perhaps, I should stay away -- nothing rational only Hammer took it logically and showed how PC may be able to sample joystick at 1Khz.

Well, there's a *market* for a fast gaming mouse. I don't see a business case for a fast digital joystick.

[Hammer]

Hey, I agree that was the main reason they never used digital joystick to begin with-- it's was cheaper and easier to just put a gameport analog type joystick via a plug-in card since it was a business type machine.

I was referring to the type of games that promotes the use of analogue type inputs e.g. Wing Commander series, F16 Falcon series, Microsoft Flight Simulator series and 'etc'.

Note that Xbox 360 is a game console i.e. it uses XInput APIs and includes analogue type controls.

 It's the people in fantasy land and in denial of reality who think that PC still surpassed Amiga in that catagory through osmosis.

Classic Amiga style games and controls system is not competitive against the
1. Xbox 360 e.g. http://www.youtube.com/watch?v=iFwNP5zrvso
2. PS3 e.g. http://www.youtube.com/watch?v=jvXgoyiAQOs
3. PC (AMD GAME!) e.g. http://www.youtube.com/watch?v=jN_aGKt7uhw

It wouldn’t be natural to play 3D simulation type games with classic Amiga style digital stick.