PC still playing Amiga catchup

[amigaksi]

I did not say they used a VBI interrupt to read the joystick port. I said they polled it once per main loop. And I also stated that this main loop will run once per frame.
...

Once per frame boils down to VBI or some IRQ that's 1/60 second.

>Anyway, C64 games do it exactly as I describe and no one ever commented about C64 games being less accurate to control than Atari 8 bit ones. Ever. On top of that I seriously doubt that 8 bit Atari games have a main loop that runs faster than once a frame.

Believe me, all sample codes you find in books in BASIC and w/inline ASM don't wait for any 1/60 second IRQ/VBI to read joysticks.

>Furthermore.... Amiga basic programs!?
>Sigh. Amiga basic is dead slow. You are not seriously telling me you think these games update their main loop more than once per frame?

Sure, especially if code is small and running on 68020 or better.

>This is not relevant, because the games don't actually do it. And no one seems to notice.

You can just base it on someone's experience of noticing it that's why the examples of 22Khz/11Khz and MP3 were relevant.

>8 Bit CPU's did not have the time available. They ran their game loops once a frame.

You can't generalize on that since there's code that does read joysticks and there's no frame interrupts involved.

>Humans cannot react much faster than 200 or so ms. This means any input polling above twice that rate (100 ms) is not needed because this will perfectly reproduce the original input (per http://en.wikipedia.org/wiki/Sampling_theorem)...

As stated before, one human reaction does not translate to one joystick state.  

>And how many 8 bit machines had enough CPU power and memory to both read at that rate and actually do something with the results?

Two scanlines is 228 CPU cycles on Atari; they have entire DLIs running per scanline so you can do something with it.

>What really happened is that they read the results at a set frequency and interpolate the result based on the prior reading. Now, I did not do much with paddles and the like, but I'm willing to bet I already know at what frequency games such as breakout/arkanoid are sampling the analog input.

I never said you have to sample at higher rates, but that it's more accurate.  You have to apply Nyquist rate to the highest frequency component present in the signal if you want to PERFECTLY reproduce the signal and don't know the phase shift (which is true in this case).

[amigaksi]

Strange that the lack of 16-bit mode in AMD64 is lambasted but the lack of direct hardware backwards compatibility for the 680x0 series is ignored

I already made it clear there are some minor differences even in x86 architecture but they are still sold as and documented as "backward compatible".  To be technically strict about it, if a program is emulating 68000, it should run like a 68000.  If a program emulates 68020, it should run like a 68020.  Not that I run a 68000 emulator and it runs like some hybrid between 68000 and 68020 w/screwed timing and latencies of frames and audio.

To eliminate 16-bit mode is a MAJOR difference as there are millions of DOS programs and Windows 3.x programs out there.  As far as I know, you can disable caching on the later 680x0 processors to make them more compatible.  Strictly, you know the frequencies are incompatible but at least they can be called opcode compatible.

[amigaksi]

Ahh, but you have to understand, this is what he means by "objectivity".

It only counts if it can be twisted (no matter by how much) to support his argument. :lol:

You are being biased.  If I go from 680x0 to 80486, I can say they are NOT compatible.  If I go from 68000 to 68020, you can't treat it the same way "NOT compatible."  That's being biased.

[amigaksi]

A digital joystick doesn't register "how soft" and "how hard" is the reaction.

But it does register many states for a given reaction.  You move from left to right and you get a state of no direction for some time.  You press a fire button and change directions independently so there's possibility of states that last for millisecond or less.

And as far as the argument:

>This is not relevant, because the games don't actually do it. And no one seems to notice.

You can't base it on experience of noticing but have to take into account the actually what can happen.  Just like audio digitizing and MP3 conversion from wave files.

[amigaksi]

I do not think that word means what you think it means.



Did you even bother to read... No wait, by your responses I already know the answer to that one.  



I really don't.

You are biased if you think the 68000 is incompatible with 680x0 processors.  They are opcode compatible although there are minor differences.  I already stated the problem with frequency changes.  You don't know what biased means although you are exemplifying it.

[amigaksi]

Hi,

@Amigaksi,

Try this on your amazingly fast joystick port:

7. Do you need USB 2.0?

...

I already admitted for buffer transfers, USB is faster than joystick port.  But Amiga doesn't use joystick port for buffer-type transfers.

[amigaksi]

There are incompatabilities and they're so great that they need emulation to cover. They also change from model to model.

...

"Great" for you.  They purposely tried to make them compatible-- what minor differences there are don't compare with eliminating the 16-bit mode completely.

>Disagreeing with your patent and demonstratable nonsense!=biased.

Nonsense that I think 68000 is compatible with 68020 and you don't.  If you can establish that 0x86 is less incompatible, perhaps I can take you seriously.

[amigaksi]

See my previous post.

...

I did, it's your normal misunderstanding.

>Citation please. I think you'll find no such post where I say these two models are "incompatable".

So they are compatible like it states here:

http://www.cpu-world.com/CPUs/68020/

[amigaksi]

whatwhatwhatwhat!?

That's incredible, if you didn't exist, someone should have invented you: every night I come here to see if there are any news, and you always bring to me some delight.

Ok, so X64 architecture has dropped 16 bit compatibility. And now? How can we live with this? "there are millions of DOS/Win31 programs out there". One for every gameport? Once again, I have to inform you that we are in (late) 2009, 10 years after that 16-bit programming has been considered "deprecated" on the x86 architecture, and that today almost nobody still uses DOS. So anyone willing to use ancient code and ancient programs has the ability to run them on a virtual machine.

What are you? Some sort of technoecologist, desperately fighting for obsolete solutions preservation?

Some people still use DOS and Win98SE and other OSes that boot up in real-mode (16-bit).

The argument is whether it's considered compatible w/o 16-bit support not how many people still use it.  VGA still has CGA modes but hardly anyone uses them.

Insults can be said by anyone-- so stick to rational arguments.

[amigaksi]

Yeah, the reason for backward compatibility is to provide a bridge so that software manufacturers can catch up with the new system.  You provide it for a reasonable amount of time and then you move on.  The only reason anyone is interested in running 15+ year old software for the Amiga is because the company that produced the Amiga *DIED* 15 years ago.  If they had survived *nobody* would care if the current Amiga OS was compatible with with the old stuff.

I couldn't do 10% of what I do now on 15 year old software.  Life moves on.  That's the way in the computer world.  In the Mac world Carbon is finally being put to bed, it's junk but it had to be there initially, now it's just a waste of good electrons...  This is what happens in living systems.  You evolve and progress or you die.

Believe it or not some software is more efficiently done in real-mode.  You get to take over the system and write software that works almost exactly as you want it (not as good as Amiga) but as close as you can get it.  Win98SE, Win 3.x, DOS, and some others still support real mode.  I still use MS-Word 2.0-- it's fast and loads almost instantly and the OS to use it fits on a floppy drive.

[amigaksi]

Aparently I understand enough about the differences to know that as each model was produced, more and more emulation had to be put in place to cover. The situation by the time we get to the 040 and the 060 those differences are so great that AmigaOS will not boot without having patches in place. Something you are trying to squirm around that now by citing the 68020 only. Bt

...

Looks like you corrected yourself here.  Also, your "great" word is questionable.  All of my 68000 software runs fine on various AGA/ECS machines with various 680x0 accelerators and no libraries are involved.

>Oh no you don't, you accused me of being:

In post #1169, you stated there are incompatibilities and you also claimed they are "great".  If the incompatibilities are great, that sums up to saying the processors are incompatible.  If they are minor and involve some rarely used instruction, the processors are still considered compatible.

>So again, citation please. I think you'll find no such post where I say these two models are "incompatable".

It sums up to that w/post #1169 and word "great."

>LOL! You call that evidence? So we have Karlos who has the actual Motorola manuals, which explain the various difficulties and potential coding pitfalls with regard the 68k. ..

I also have many manuals stating they are opcode compatible.  I wanted to give a link on web since I don't want to go through all my manuals.

>You have the rest of the Amiga using world knowing full well that if you yank the 040 library from an 040 Amiga system it won't boot (same for the 060) and you have what amounts to a magazine brochure... Come back when you get a clue.

Looks like you corrected yourself here.  So you needed to get a clue.  I use boot disk-based applications that don't involve installing any libraries.

[amigaksi]

Seems like Amiga people chosed neither... They definitely don't want to progress or evolve, neither want to die. Or at least admit they are dead.

Guess this whole thread shows that clearly. Amiga is dead but its gameport is still the best... and so on.

You need to go on with "and so on" and state the other reasons why Amiga is still useful.  If PC is playing catch-up in some areas, PC needs to evolve in those areas so you have no argument.

And why does one have to update to 3Ghz if the work can easily be done with a sub 100Mhz machine with a superior direct to hardware compatibility where you know exactly what is happening in the system from software perspective and don't have to play guessing games.

[amigaksi]

What is this "floppy disk" of which you speak? I don't think I've seen one on a modern computer?

Because you live in a world of illusion where bloated applications and inexact OSes rule and overrun by spyware/viruses and require gigabytes of data to keep your OSes functioning.

[amigaksi]

I stand corrected.

My system had any number of patches that necessitated the need for the MMU's presence. Having to loose most of the performance both in terms of software patches and hobbling the cpu would imho be as bad as it simply not booting - the result would be much the same as I wouldn't be able to use half of the software I owned at the time. Also having to pray that none of the software I could still use called one of those unsupported instructions does not inspire confidence.

Get a clue.  I am talking 680x0.  There is NO "great" difference to need a library.  You want to exaggerate and distort the truth and claim there's a great difference then that's as good as saying they are incompatible.  Biased.

[amigaksi]

Because that'd blow his argument up! Don't you follow this thread? He's being "objective" - which apparently means you have to dismiss any information that is contrary to your position and call anyone who points this out biased.

:laughing:

You are the one correcting yourself and you're the one who is baised exaggerating minor differences and dare speak of "objectivity."  You have first BE OBJECTIVE before you can accuse others; hyprocrite.

[amigaksi]

See my earlier post. Any software needing 68881/2 instructions not directly implemented in the 040 FPU will fail on 68040 without the 68040.library loaded. You will just get a fatal F line exception based guru instead. Beyond that, all software will run significantly slower without the 68040.library since the data cache cannot be readily enabled without the library.

The situation is even worse on the 060 where any 32x32->64 bit integer multiplication will fail without the proper 060 support code installed.

They are not minor differences.

But we are talking compatibility; to use the enhanced features, you can use a library or enable them directly with some MOVEC or whatever.  It's better that they don't enable the enhanced features by default.  68881 is not a standard feature of 68000 machines.