PC still playing Amiga catchup

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

[Karlos]

If you look at just the I/O overhead involved for fetching state of joystick, you will see that it involves multiple I/O instructions and other overhead and it's slower than a MOVE.W of Amiga.  And you are going through API which doesn't allow you to take over the USB for just joystick.

Nobody wants to poll the joystick at 1kHz. Nobody anywhere in the entire world. Nobody, that is, except for you.

Let's just distil all this down to the basic facts here.

You have not given any evidence, anecdotal or otherwise to demonstrate that any commercial software ever written for the Amiga uses high resolution joyport polling to better capture the user's input.

The single, meaningful example of why polling the joystick at anything like the kHz range makes sense was given not by you, but by me. That example was the cassette tape interface for ZXAM which basically converts the incoming tape audio to a series of pulses on the joyport fire pin.

Your ability to record the joystick at a high rate in no way whatsoever demonstrates that River Raid (your chosen example) does so. Your sole evidence for this was that replaying events captured at a higher rate gave better, more predictable results. That does not tell you anything about the actual sample rate of the game itself. All it tells you is that you can better reconstruct the original joystick event stream by recording it at a higher rate. This is basic sampling theory: the reconstruction of any signal is better at higher sampling rates. It does not mean that the game is sampling at this rate. For instance, if I sample spectrum audio at 8kHz, replaying it back to the spectrum tends not to work very well. Recording and replaying at 22kHz works very well. We do not infer from this that the spectrum is reading data at 11kHz (the highest frequency you can hope to reconstruct at 22kHz). Far from it, it switches between 1-2 kHz using PWM encoding for bits.

The joystick example is the same. Even if River Raid samples the joystick once per frame only, you will be able to replay a recorded sequence of events more accurately if that recording is at a much higher sample rate than the game is using, simply because your recorded signal more closely resembles the original signal at higher rates and not because the game requires it.

So, you might very well be able to poll your joystick at a faster rate using CIA timing but I'm still waiting for an explanation as to what tangible advantage this gives with respect to human input for a joystick.

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

[EvilGuy]

Actually, I would favor not even fixing hardware bugs in future upgrades to hardware-- so it remains consistent.  In fact, many people use the hardware bugs as features in their applications and expect them.  

And here folks is one of the reasons why the Amiga croaked. You get an installed base of
"programmers" who know everything and expect bugs not to be fixed.

[persia]

Yep, why would anyone at Microsoft would know or care about a computer that died 15 years ago?  Oh, they are in Seattle and if they are ice hockey fans they might have heard of the Amiga Centre at Kent....

[Trev]

Actually, I would favor not even fixing hardware bugs in future upgrades to hardware-- so it remains consistent.  In fact, many people use the hardware bugs as features in their applications and expect them.  I know in Atari GTIA chip has a color clock delay in one of the graphics modes which people use to produce interlaced modes with double resolution.

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.

[Trev]

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.

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.

[stefcep2]

What really gets to me on the pet peeve level is that in 2009, a full 15 years after the death of Commodore, there are still those so desperate to hang on to "what used to be", that they invent the smallest, most asinine reasons that they believe the Commodore Amiga -- a computer almost 8 times removed from Moore's Law -- is still a commercially competitive (not to even mention viable) platform...

who said they believe the Commodore amiga is still commercially competitive platform?

[stefcep2]

I find it doubly bizarre that those who regard it in that light are usually quite dismissive of things like UAE that can actually transform an OS3.x installation into a platform that can actually hold it's own thanks to the exponential increase in raw horsepower you get from it.

Interesting.  So what you are saying is that its the lack of raw computing power of the hardware-not the OS itself- that prevents it from holding its own?

[Karlos]

Interesting.  So what you are saying is that its the lack of raw computing power of the hardware-not the OS itself- that prevents it from holding its own?

In this day and age, I'd say the lack of horsepower was the bigger handicap compared to modern machines. More horsepower allows you to upgrade almost everything else about the system without it impacting on the end user experience. OS3.x has a few fundamental deficiencies that horsepower alone can't really fix (lack of protected memory, no SMP capability etc) but as far as the basic role of an OS goes, I don't think it's nearly as antiquated as the hardware. AmiKit demonstrates this quite well. You can run it on a real amiga, but it feels slow (certainly on my kit) compared to an unmodified 3.x. On UAE, however, it's fine. Faster than basic 3.9 is on my 040 by a wide margin.

[Hammer]

I am not familiar with those applications.  Perhaps, you want to give description of what needs to be addressed from hardware standpoint?

Access conflicts.

[Roondar]

Nobody wants to poll the joystick at 1kHz. Nobody anywhere in the entire world. Nobody, that is, except for you.

Let's just distil all this down to the basic facts here.

You have not given any evidence, anecdotal or otherwise to demonstrate that any commercial software ever written for the Amiga uses high resolution joyport polling to better capture the user's input.

The single, meaningful example of why polling the joystick at anything like the kHz range makes sense was given not by you, but by me. That example was the cassette tape interface for ZXAM which basically converts the incoming tape audio to a series of pulses on the joyport fire pin.

Your ability to record the joystick at a high rate in no way whatsoever demonstrates that River Raid (your chosen example) does so. Your sole evidence for this was that replaying events captured at a higher rate gave better, more predictable results. That does not tell you anything about the actual sample rate of the game itself. All it tells you is that you can better reconstruct the original joystick event stream by recording it at a higher rate. This is basic sampling theory: the reconstruction of any signal is better at higher sampling rates. It does not mean that the game is sampling at this rate. For instance, if I sample spectrum audio at 8kHz, replaying it back to the spectrum tends not to work very well. Recording and replaying at 22kHz works very well. We do not infer from this that the spectrum is reading data at 11kHz (the highest frequency you can hope to reconstruct at 22kHz). Far from it, it switches between 1-2 kHz using PWM encoding for bits.

The joystick example is the same. Even if River Raid samples the joystick once per frame only, you will be able to replay a recorded sequence of events more accurately if that recording is at a much higher sample rate than the game is using, simply because your recorded signal more closely resembles the original signal at higher rates and not because the game requires it.

So, you might very well be able to poll your joystick at a faster rate using CIA timing but I'm still waiting for an explanation as to what tangible advantage this gives with respect to human input for a joystick.

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.

[Hammer]

Didn't see that bottom part-- even CGA had method of setting frequencies that damaged monitors but VGA didn't allow for that on hardware level.  

Actually, I would favor not even fixing hardware bugs in future upgrades to hardware-- so it remains consistent.  In fact, many people use the hardware bugs as features in their applications and expect them.  I know in Atari GTIA chip has a color clock delay in one of the graphics modes which people use to produce interlaced modes with double resolution.

Such statements would be unwise in the light of Geforce FX VLIW experiment.

[Hammer]

How is it clearly not true?

PCs have been playing catch-up ever since Amiga was introduced.  
They have had higher processor speeds/computational power even before Amiga was introduced.  They are still playing catch-up in some areas.  Their API method of approach is making it worse for them.

Classic Amiga wasn't a serious threat against SGI and it's OpenGL standard. Both ATI and NVIDIA follows the SGI’s approach.

Classic Amiga is not competing against the “PC” i.e. it’s competing against redressed old school RISC vendors e.g. DEC (AMD, Intel, Microsoft), SGI (ATI, NVIDIA).

[Hammer]

You are thinking doing multitasking while someone is accessing directly the hardware and trying to avoid conflicts, but I am talking about just allowing an application to use hardware directly.  You can do that with IOPM or Amiga does it by the application not allowing other applications to run at the same time.

>uh nope if a piece of software requires directx 10 or higher it is cut and dry. directx 10 even has backwards compatibility with previous versions. also this piece of software installs the version it needs on install.

But they also fixed bugs in higher and higher versions of DirectX; so you need to know whether to avoid the bugs or not.  

>yea i do have a shallow understanding of it. but what i understand is that it is a gate system. and the port is open or closed. that it is very simplistic in operation. but closing the barn door after a lockup is not of any use.
>In order for the os to really control the flow you will have to adopt some form of api this way the os can refuse to pass on something that is not properly executed. this is the point of an api.

No, you don't need an API.  Windows for each task keeps track of an IOPM and it can set IOPM to enable hardware ports needed by that application and application directly accesses that port without any API/drivers involved.

"Hit the metal" userland applications would break on Windows Terminal Environment and reduce stability.

[jkirk]

You are thinking doing multitasking while someone is accessing directly the hardware and trying to avoid conflicts, but I am talking about just allowing an application to use hardware directly.  You can do that with IOPM or Amiga does it by the application not allowing other applications to run at the same time.

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.

But they also fixed bugs in higher and higher versions of DirectX; so you need to know whether to avoid the bugs or not.  

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.

No, you don't need an API.  Windows for each task keeps track of an IOPM and it can set IOPM to enable hardware ports needed by that application and application directly accesses that port without any API/drivers involved.

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.