PC still playing Amiga catchup

[amigaksi]

If you run a 16bit Windows userland program, it runs within a layer called Windows On Windows (WoW). WoW supports applications using the Win16 API and relies on NTVDM (NT Virtual DOS Machine).

Try running Stunt Car Racer DOS or EA's 688 Attack Sub DOS on Vista.




The AMD64 processor in Long Mode doesn't support Real and Virtual 8086 modes.

Legacy support is best run in Microsoft’s VirtualPC, VMWARE, SUN’s VirtualBox, DosBox(software emulator for DOS/Win16 games) and 'etc'.

So I have to run a 16-bit emulator under Vista-64 to run 16-bit applications although processor supports it in hardware.  It's better to boot into Vista-32.  Are those applications like VirtualPC using processor hardware or doing a software emulation of 16-bit application?

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

[Hammer]

So I have to run a 16-bit emulator under Vista-64 to run 16-bit applications although processor supports it in hardware.

The lack of Virtual 8086 mode when you're in Long Mode is a documented limitation of the x64 ISA.

It's better to boot into Vista-32. Are those applications like VirtualPC using processor hardware or doing a software emulation of 16-bit application?

http://download3.vmware.com/vmworld/2005/pac346.pdf

"VT-x requires small emulator for real mode code".

[Hammer]

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.  

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

[Karlos]

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

[the_leander]

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

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:

[ElPolloDiabl]

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

Symbolically however, the more scans that hit (1/On) the 'harder' the result.

[ElPolloDiabl]

For Hitchhikers fans:


:roflmao:

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

[smerf]

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

Hi,

@Amigaksi,

Try this on your amazingly fast joystick port:

7. Do you need USB 2.0?
Almost every conceivable peripheral has a USB 2.0 version ranging from a HDTV tuner, a micro hard drive to even video card / USB monitor. So, even if you buy a all-in-one HP multimedia PC with all the gizmos, you'll still need something USB. (Maybe not Everything USB).

Should you own a laptop, you may like to know that USB is also your ticket out of the proprietary world. It used to be that docking stations must all match that exact notebook model due to the proprietary connection. Now, you can just plug in a USB 2.0 docking station, and you'll get a USB hub, 7.1 surround audio, serial converters, Ethernet plus a notebook holder.

8. How does USB 2.0 handle today's applications?


Many have asked us how USB 2.0 or Hi-Speed USB mode specifically can handle today's ever-changing applications, particularly in the multimedia field. The original USB has an inherent problem to meet the bandwidth requirement of then current CD burners and hard drives. If memory serves us well, USB CD burners hit the bottleneck at 8x or 1.2MByte/s, and USB hard drives couldn't exceed a pitifully 1MByte/s.
When USB 2.0 introduced Hi-Speed USB mode, it boosted bandwidth to 480Mbit/s or 60Mbyte/s. The forty-fold jump from the original USB's 12Mbit/s has paved way for a number of improved devices. As we've seen, there is a dual SDTV tuner, each of the tuners consumes 8Mbit/s after the MPEG-2 conversion. For DVB-T/B USB tuners, each HDTV stream requires 55Mbit/s or 11% of what USB 2.0 offers. Technically, Certified Wireless USB can handle several HDTV channels simultaneously. For a few USB Video Class-enabled camcorders available, DV mandates 3.6Mbyte/s (or 43Mbit/s) for the linear video stream; it fills up a hard drive at a rate of 13GB per hour.

As for a lot of USB storage, burning a DVD-R at its fastest rate or 16x takes up 21MByte/s or 169Mbit/s. That translates to 35% of overall USB 2.0 speed. Hard drives, however, demand huge amount of bandwidth that USB 2.0 cannot meet; we've seen a USB 2.0 hard drive has sustained 36 to 40MBbyte/s in the absolute best scenario. USB flash drives have also reached 33MByte/s, but there seems to be some limitations in the NAND itself so you shouldn't expect their speeds to skyrocket in a next year or two. For most consumers, there shouldn't be a problem with running out of bandwidth.

Can your amazingly fast joystick port run HDTV?

If USB 2.0 could do this, a joystick should be a walk in the park

smerf

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

[the_leander]

You are being biased.

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

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

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

That's being biased.

I really don't.

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

[Karlos]

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.

No they can't. Many opcodes are not supported on later 680x0 processors that were supported by earlier ones.

The 68020 changed the behaviour of some opcodes on the 68000 that will cause any software using them to crash. You cannot move bits from or to the status register outside of supervisor mode on 68020+. Since most operations on this register were actually condition code related, they added opcodes to read/write the CCR instead none of which can be used on the 68000. So, you can write code that uses the SR in userspace on the 68000 that won't work on the 68020+ or code that uses the CCR in userspace on the 68020 which won't work on the 68000. You either use separate code for each CPU or you install a trap handler of some sort for the privilege violation. It cannot be called opcode compatible any more.

Next, the 68040 threw away dozens of valid 68881 opcodes. You cannot use any of the transcendal operations or use the 68881/2 mathematical constants. You will get an illegal exception if you try to do so. Again, you must either write code that does not use these opcodes, or you install a handler for the unimplemented instruction exception and emulate them on trap.

Next, the 68060 threw away 64-bit integer arithmetic (multiply and divide) that were implemented in 68020, 68030 and 68040. You cannot use any of these opcodes without invoking an illegal instruction exception. Again, you must rewrite your code not to use them or install a handler for the unimplemented instruction exception and emulate them on trap.

The 680x0 series is not fully backwards compatible purely in hardware. It must use software assist. It says so in my copies of the user manuals and the examples above are all easily demonstrated.