PC still playing Amiga catchup

[amigaksi]

lol i think you should look again. nearly every machine i have seen that has parallel has at least one serial port.
...

Sorry, 10 of the 12 machines I have do not have serial ports but have parallel ports.

>let it go this was old tech.

Sorry, gameport is more recent than you think.  

>http://en.wikipedia.org/wiki/Game_port
>http://www.computer-engineering.org/ps2keyboard/
>eh only 6 years apart.

You miscomputed.  Game ports were on motherboards in 1990s as well as on audio cards.  I bought an audio card w/gameport just a few years ago.

>things developed for one market can often be used in other markets. the xbox controller was made for xbox. people wanted to use it on a pc so when the market speaks things happen (well sometimes, it sure made them think about it then.)

Original point was that someone is giving a hoot about gaming interface.

[amigaksi]

And this is different to hardware bugs, or (unknown to the author) unexpected differences in hardware how?
...

anwered recently.


>If that's the case, why, in the name of all that is holy, have you been railing against windows and specifically its APIs like they nailed your mom in your bed for 50+ pages?

There's mechanism in hardware to support varous I/O port direct access but if audio/video/etc. boards don't even use same I/O ports or same method of accessing them, what use are they.  First you need hardware level compatibility.

[amigaksi]

USB "High Speed" spec has 125 usec. IF the APIs brought USB "High Speed" to Amiga’s joystick speed, you shouldn't see USB "High Speed" having 40MB/s effective bandwidth.

From usb faq
Signals
1.   Does USB support data rates besides 12 Mb/s and 1.5 Mb/s?

A:   Yes. The new hi-speed data transfer rate is 480 Mb/s. There is, however, wide variation in edge rates. With typical line loads, full speed devices usually fall in the 12-25 ns range, and low-speed devices typically range 110-225 ns.

Only if you do buffered transfers are you going to get high transfer rates.  For fetching just state of joystick, you have considerable overhead.  And there's a big "IF" there as well since USB joysticks are using very low rate to begin with.

[amigaksi]

What's not clear to me after reading Intel's manuals is whether or not IN/INS/OUT/OUTS assert LOCK# (they don't appear to do so explicitly), or if it's the responsiblity of the system designer to manage locking in a multiprocessor environment based on the state of M/IO#. The documentation implies that IN/INS/OUT/OUTS should be atomic at the processor level, which I assume means the package itself, multiple cores inclusive. I'm obviously fuzzy on the details.

Memory mapped I/O appears to play by the same rules associated with all other memory accesses, i.e. atomicity is either implied by the instruction, explicitly requested via the LOCK prefix for compatible instructions, or managed by the programmer via higher level methods.

Anyway, if you have one task polling I/O and another task processing the data, you obviously have to coordinate between the two. On a modern system, if you haven't explicitly set the affinity of the task, you have to assume the tasks may run simultaneously on separate processors. Unnecessarily stalling one processor while it waits for another would be indicative of a bad design.

Xchg does a LOCK even if you don't specify one.  IN/OUT also can be delayed by device w/wait states so it's not that they have some fixed time of execution that you can multitask on for a fixed amount of time.  Plus, they use the bus-- address/data lines to do the IN/OUT.

[amigaksi]

and all 5 of mine and the 6 computers i have worked on did have serial and parallel. as well as the 3 computers i have at work.
...

That doesn't prove that serials are preferred over parallel.  They did have both and then they dropped serial before parallel.

>sorry but 1990 is not recent. also if it was that recent microsoft wouldn't have dropped support for it.

Hello, AT DIN5 connectors went a long time ago before gameports.

>no your point as stated was that you believe someone created the hardware because they cared about the poor performance of the joyport. the hardware transition was more about eliminating old standards to reduce cost. even if the usb interface had no performance increase they still would have eliminated the joyport(among other ports) since they would not have to license the use of many ports and could focus on one style of input port.

Sorry, but they made newer joysticks for USB-- they had to substitute with something.

[amigaksi]

Today, they're called exploits, and both hardware and software vendors are under extreme pressure from trillion dollar industries to close them as quickly as possible.

But they (hardware bugs) are useful to have around if they help to make better more optimal software.

[amigaksi]

Lots of instructions have implied locks, but I was talking about port-based I/O specifically. Latency aside, I'm curious about the implications to multiprocessor systems. In a NUMA system, if remote nodes are not prevented from executing while another node is busy, you could run two I/O-related threads out of phase, preventing stalls and linearly scaling the performance of the system, i.e. it would be perfectly parallel--in so far as the system allowed. You'd still have to deal with latency, but only per-processor. While one processor is waiting on the next I/O, the other processor is processing the previous I/O. I need to look at the AMD manuals.

Well go look at the manuals because I don't think you can parallel process two I/O instructions.
Implicit locks are only on XCHG as far as documentation on Pentium that I have.

[amigaksi]

Well, I'm not sure about Amiga games -since I didn't seriously look into how their inner loops work- but I am sure about C64 and other 8 bit games.

On these machines the CPU is usually the limiting factor and most games just run one game loop per frame displayed. On the C64, since most interesting things are done through clever usage of interrupts, this effectively means a 50/60Hz polling rate for user input*.

On machines without raster interrupt such as the Spectrum it's more tricky to accurately say, but the average Spectrum game is quite lucky if it actually reaches a 60Hz update cycle for it's graphics. And since these games also update input once a frame at best you get a roughly 20-60Hz polling rate for user input*.

Now, like I said, I'm less sure about this on the Amiga. But I'm willing to state that most games on it will still follow the same model: update (most) everything once a frame, leading to a 50Hz/60Hz joystick polling frequency.


On a sidenote, the average human adolescent has a reaction time of about 215 milliseconds (http://en.wikipedia.org/wiki/Reaction_time), this drops with age. This translates to a reaction time of slightly over 10 frames (at 50Hz).

*) The assumption here being that the designer did not deliberately slow down reading user input. Though I've not seen this myself I'm pretty certain that a game updating its screen at 25Hz can get away with sampling the joystick at 25Hz without people noticing this much if at all.

Problem is more about getting all states of joysticks regardless of what a human's reaction time is.

[amigaksi]

locking up the hw so only one program can access at a time is not my idea of an efficient way of doing things. furthermore in this environment of multitasking this is not feasable.
...

It is efficient-- that's what I meant by taking over the hardware.  So some critical application can write the most optimal game or application.  OS still exists and can do it's own multitasking.  See Amiga computer as an example.

>bugs? what bugs? srry but if a bug exists the only person that has to deal with it is the programmer and driver writer. the end user don't see the issue typically.

We are talking about programmer.

>you are missing my point. iopm to my knowledge has no error correcting built in. it opens the ports for one app then if that app crashes iopm don't immediately close the ports and reset the hardware. then the next app comes in but either can't open the port or open it then crash. an api can detect and correct as well as make programming more uniform.

No, IOPM will only protect disk i/o or other things it doesn't want accessed and allow application to go directly to hardware and leave it to application if it wants to crash itself since it won't hurt the OS.

[amigaksi]

Classic Amiga isn't competing against anything, the company that produced it went belly up 15 years ago.  It's a hobby machine that some of us find fun to play with, it's a bit of history.  It's a great learning tool to learn the basics.  Modern OSs do everything for us, the Amiga doesn't, it forces you to understand what you are doing and do it manually.  There is no competition for classic Amiga except the competition against time and electronics...

There are still things Amiga does that modern PCs cannot do.  In fact, many retro machines allow for doing things in more accurate manner than PCs and Amiga is the top gun of those machines.  Have you ever written some method of timing how long a piece of code takes on a PC?  Take into account the caching, various CPU frequencies, power management, C1 states, memory speeds, I/O speeds, etc.  

And what makes it all the worst-- APIs!   You don't know what code is behind the APIs on different systems.  It's  all hodge podge when it comes to estimating time of code.

[amigaksi]

This one line does not negate my post somehow you know. If you have a point regarding what I wrote, please make it instead of writing something that only adresses a single line of text in there and totally ignores the rest.
...

Because the rest of your message was already dealt with before.  Don't get that much time to look-up references back in the same thread given size of thread.  You may be confusing games polling analog joysticks during only VBIs or such but joystick ports are read any time without requiring any interrupts or VBIs.  There are many programs on 8-bit (on Atari) that just have a main loop that reads the joystick and sets appropriate graphical elements or flags.  From the BASIC source codes I have on Amiga, they also don't use any VBIs to read joystick ports.

>For a joystick port, the only 'problem' facing programmer is to read out the joystick fast enough a human can't notice you did so. The old 8 bit computers where slow, but the programmers of the time managed to fix this 'problem' by reading the state of the joystick at between 20-60Hz. This was more than plenty for people, it looked as if the ship/ninja-dude/thing-on-a-spring/whatever reacted directly instead of with a delay (exceptions here being due to slow animations, not slow joystick reading).

The argument given before was that you can sample audio at lower rate like 11Khz and it may appear the same as 22Khz but there is a difference of accuracy of some frequency components.  And the other example given before was that of MP3 audio which distorts certain samples to get higher lossy compression ratios but sounds basically same as linear audio.  You can't prove just by looks-- you have to take into account whether reading at those higher rates ACTUALLY improves accuracy of input.

>This means that polling a joystick at a rate of 20ms or faster is quite ok. You don't actually need it to be any faster and I'm 100% certain that programmers (being I know how they think as I a) am one and b) observed the works of the 8-bit crowds) only do what is needed and no more: they poll the joystick state once every frame. Not two times, not ten times. And definitely not at 1 KHz, which would be an utter waste of resources.

The question is not what you can get away with but what is more accurate.  It's not a waste if you have that time available; if processor is idle-- mine as well let the main loop run as fast as possible.  

>Now, had you written this about mice you actually may have had a point. But then, we do have PC mice that track at 1KHz. Notice that these mice are USB based and no one seems to have lag issues with them.

If you examine technical description of 8-bit machines, you will find that even C64/Ataris had a FAST polling mode for their potentiometer readings-- fast pot scan which scanned in the potentiometers within 2 TV scanlines which translates to 15.75Khz/2 polling capability.  So whatever the purpose, it was there in the hardware.

[amigaksi]

PC-DOS 1.0

"It booted flawlessly on a 3.00GHz PIV."

Refer to http://vetusware.com/download/PC-DOS%201.00/?id=4356

That's what I figured-- processors are backward compatible so DOS should work but OS purposely is not allowing older 16-bit applications not to run.  Another case of APIs/high level stuff limiting what the hardware is capable of.

[amigaksi]

Hi,

@Amigaksi,

You made the statement:

"There's good reason for it. Most computer companies used digital joysticks while PCs went for analog ones. Amiga also has analog interface as well, but people purposely chose digital joysticks."

Now I just found one of my old Amiga joysticks that don't work, I opened it up and it seems like it has a couple pieces of copper in there that act like springs and open and close like a switch, maybe you could explain how when these springs touch that I get a digital signal out of it, I am really confused and maybe you can help me figure out what went wrong with my joystick, I tried hooking up a VOM to it and it doesn't even move when I press the joystick, I looked for a digital signal comming out when I closed the good copper pieces, but my friend who owns it says that now signal is comming out of this joystick, and that it is totally useless and broke. Maybe you can help me out in troubleshooting this joystick.

smerf

I know there's a common problem with joysticks where the wire going into the connector goes bad so even if joystick is fine, you need to replace the wire.

[amigaksi]

Constant switching between 16bit and 32bit modes introduces performance penalties.
...

Hah.  They allow 16-bit applications to run fine under 32-bit versions of Vista but not 64-bit versions.  There's no constant switching going on.  Processor supports it but Vista 64-bit won't allow 16-bit applications.  

>Another case of your lack knowledge on how modern X86 processors work.

No, processor is fine.  It's another case of a big bully (Microsoft) trying to control things and make decisions for the rest of the world.

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