PC still playing Amiga catchup

[amigaksi]

Temper, temper. Just mirroring your pedantry. Struck a nerve, did it?

No, you didn't answer the point.  What makes the timing consistent throughout ECS/AGA/OCS if crystals are so different as you claim?

[amigaksi]

The data the guy posted and is defending has sub millisecond entries. He's arguing that 10 microsecond state changes on the joy port are important for playing games.

You are drawing that conclusion by distorting the truth.  I only stated 1Khz but if you think about it you can see that someone releasing a fire button and moving joystick can have sub-millisecond intervals as well.

[amigaksi]

No, he's not lying. He took at look at the data and came to the same conclusion that I did, he just managed to drop his post a few minutes before I got done with mine. I actually dumped your table into excel and did some analysis.

To begin with, you didn't disclose how you got this information. You didn't tell us what the other bits are for either. The first issue alone makes your data worthless. Another, more important issue is that you have no idea how often the software polls the port and you stated as such.

Your data shows state changes on the joy port with a time interval of 0.01 milliseconds. This is physically impossible for a human and mechanical switches are unable to guarantee a clean state at this frequency.  It's classic undebounced garbage signal noise. I see that you've slammed folks about one thing or another about the chipset, yet you seem to know nothing about basic hardware issues. For all your hemming and hawing about cycle count this and sync that on ancient hardware, you fail to unserstand how a contact switch works.

You didn't plot the data where the switching does occur without the submilliseconds intervals:

239 154.648544 ms
255 572.020930 ms
251 797.851018 ms
235 15.316622 ms
239 174.151571 ms
255 253.714007 ms
247 63.774948 ms
231 109.837404 ms

You're only showing part of the data.  And your distorted conclusion that I'm talking about UAE is your speculation.  I never mentioned anything about UAE in this topic nor EVER used it in my life.  Stick to reality and drop the bias.  I don't see why an emulator could not handle 1Khz joystick input.

[amigaksi]

Erm, as was pointed to in Karlos's drumbeat example:

There is no consistant timing


Now watch and learn as the rest of your argument is slowly chewed up and spat out.

He hasn't proven anything about the timing of audio interrupts, CIA interrupts, Copper timing being different or varying over time.

You don't need to reference him; I read his posts.

[amigaksi]

No, it's fairly obvious that it's contact bounce:



1/(0.01ms / 1000) = 100000Hz. This is not joystick input from the user, this is contact bounce/noise. This is not speculation, it's an obvious conclusion based on your own readings. You on the other hand have interpreted this as "holy cow, this is accurate" - while it's actually not accurate at all.

Bullcrap.  You are taking only a small part of the data where fire button and joystick directions are changing.  It's not obvious if you take the data as a whole and see that the sub-millisecond timing only occurs sometimes.  If I stated microsecond changes as "accurate user input", I wouldn't be stating 1Khz.

[amigaksi]

That's funny

...
But then, PC catched up, and even went beyond, with faster gfx, more colors, even smooth scrollings, etc... Sure, it took time. But meanwhile, Amiga only went from OCS/ECS to weak AGA.
...

I asked you to reply to post #275; you did not but are now expressing your opinion again.

>Well, arguments as stupid as "you may poll the joystick port 1000 times a second, the PC cannot". Well, it's certainly *true*. But it is so useless that no one in the entire Amiga's existence ever mentionned or used it. No one but you...

The people who don't understand the argument are stupid.  Doing a MOVE.W $DFF00A,D0 is superior to polling an analog joystick (period) via port 201h or via USB.  Then I gave an example of River raid where 1Khz sampling can be used (and I did use it in a "Replay" mode) and this sampling is UNDOABLE on a gameport.

>That was my two cents. You can keep on posting detailed reports on how you can poll the Amiga joystick port faster than anything else, but this won't change anything to that...

You haven't shown PC doing faster joystick port input so we can move on to the next advantage Amiga has over PC.

[amigaksi]

That's true until you sample faster than the switch time of the joystick switches. Then you're recording contact bounce. Which you did.

You should take into account the FACT that pressing fire button or releasing it is INDEPENDENT of joystick direction motion.  You can in fact get an extremely low time reading so just declaring it all noise is your speculation.

[amigaksi]

We're yet to be convinced that:

1) Any amiga game, other than your code, samples the joyport at this rate.

The one example I can think of where high joystic sampling rates may be used would be the ZXAM tape interface.
...

Given the fact that you can get a millisecond state-change reading from a joystick, it should be clear that sampling at 1Khz is useful.  Just like sampling audio at higher rates is useful although most frequencies are accounted for even if you sample at 30Khz.

>2) That the ability to sample the joystick represents a genuine advantage. Your sample data suggests that you are able to observe the electrical properties of the micro switches as they close and open. I'm certainly not convinced that this resolution is useful unless you intend to produce time a averaged sample of the observed state at a lower resolution. For example, averaging the entire set of samples at 1kHz every frame into a value that you assume is "on" for the frame if more of the samples were in the on state than the off state. I'm not convinced any game does this. It more likely reads a sample once a frame and moves on.

Getting millisecond responses is not necessarily electrical property of micro switches.

>3) You can't really infer what the sample rate of an application is just by attempting to sample the signal yourself and reproduce it the behaviour of the original application from it.

But you know it can be theoretically anything so the higher the sampling rate the better.  Heck, even if you consider it noise, it is actually happening and should be taken into account.

>What you should try is sending simulated pulses at different rates to the joyport from another device from which you can control the pulse of and see wether or not the game is capable of responding to it in a predictable fashion.

It is being sent from a PC to an Amiga/Atari via a PCI parallel port.

[amigaksi]

You should disassemble the game and find its input handling code before claiming it is using 1kHz sampling. As I've pointed out, you can't base this assumption on attempting to see what minimum sampling rate you need to use to replicate it. I can produce a signal on a machine that I need to sample at 44kHz to get it sounding "just right", but this by no way suggests the signal source is operating at a comparable resolution.

There are plenty of games which do NOT use VBI to read joystick port on Atari and Amiga.  Only when you read the potentiometers, you need to wait for VBI since they are sampled synched up to the video scanlines.  Even in many basic games which I have source code for, they just read joystick and do the appropriate action in main loop.  This can be as fast as machine allows them to do the main loop.  It's more significant to understand that millisecond sampling gives a better state of the joystick reading than 100 ms than to try to play by what SEEMS like good enough.  You don't need examples, but I'll dig up some if you really don't see how it's relevant data at 1 ms sampling.

[amigaksi]

And that's a problem totally non-existent on the Amiga...

...

Yes.

>So you're trying to tell me that decompressing an image and writing it to the frame buffer is faster than directly writing an uncompressed image directly to the buffer. That might be true if you are typing the data down by hand from paper.

You can time it yourself.  If you move uncompressed frame to video area vs. decompress one to video area (as in anim format), the uncompressed frames can't achieve the speed of the decompression.

>Yes, I can agree with that. But that doesn't mean that all "ocs software" is compatible with any Amiga. There is more to it than the chip set, as I pointed out. I think you understand this as well as I do, but you are playing a fool to be able to dismiss my argument.

Hold it right there.  The argument is ability to access hardware registers directly to produce tighter code and for better response time (as in real-time events).  OCS software being incompatible has NOTHING to do with the hardware registers so those hardware registers can be used.  Processor speeds changing and ROM versions changing don't involve hardware registers.

>Yes you can, if you know the exact hardware configuration.

No, we're talking about making the software work in general on PCs across the board-- that's why we're even talking about OCS/ECS/AGA compatibility.

>Yes, because the concept of kernel mode drivers exists in every operating system available for the PC...

At hardware level programming, the PCs are the same but nowadays you HAVE to go through APIs for much of the hardware.

>Data existing is not in itself an indicator that it is important to the end user. As pointed out, the sub-ms state changes are results of switch bouncing. Just because there are millions of magazines in the world doesn't mean that I am missing out stuff that is important to me by not reading them all.

You fell for that speculation that it's a result of switch-bouncing; nonetheless, I wasn't talking about sub-ms.  I answered this in another message.

>Not in a computer game, when the screen redraw is sometimes the only feedback you get.  

User can cause motion via joystick that is faster than refresh rate; he does not have to depend on feedback from display to make moves on the joystick.

>No, it's not bullcrap. YOU HAVE YET TO SHOW ME A GAME THAT USES AND BENEFITS FROM 1 kHz JOYSTICK SAMPLING. That's still true, as it has been since I first pointed it out. As far as I know, there are VERY few games in the River Raid era where even the game logic (all the moving, AI decisions, counting of score etc) operates faster than the screen update.

It's better to understand the LOGIC that millisecond state changes are there and not result of noise.  Also, try to understand that noise is also considered input to machine.

>If you'd ever used joysticks for other things than measuring the time between state changes, you'd know that the values that the joysticks are precise enough, and no, while they are not usually exact they give you more precise control over direction than four on/off switches. You'd also know that in most games that utilize the analog sticks, the walking/turning speed/direction correlates exactly enough to the input.

I know that most games don't need analog sticks and it's a waste of time in reading such sticks for PCs since they end up using some threshold to make them act like digital joysticks do.

>If digital sticks with one button were superior for controllability, their market wouldn't have died out in the early 90s.

That's speculation.  They still exist and are being marketed.  You can market "garbage" and sell more of it than something valuable and more useful.  Marketing has NOTHING to do with the product being superior/inferior.

>No, that was not what I was claiming. I said that developers are trying to move further away from hardware, which is why there are abstractions like drivers and APIs. If you think that the average software developer has as much use of accessing the hardware as before you are wrong.

I am saying it's more optimal to have both available.  APIs and hardware access, but PCs are now getting more and more restricted to APIs so Amiga wins in this catagory.

>The Amiga can read four analog values at the same time and digitally convert them without hardware modification? The PC doesn't need any additional hardware besides what's in the joystick.

That wasn't the point.  We were talking about timing things exactly not joysticks here.

>No of course, why would you want to teach them anything? Your kids are none like the kids I know. Either way your story is very anecdotal and not enough to support your argument. The truth is that most kids these days handle and enjoy far more advanced games and joy pads.

It doesn't have to be kids.  I tried out some of the XBOX/playstation crap (sticks and games).  You try a few of them and you quickly find out, you can't tell which button is used for what.  And even worse, some of the games play by themselves as if they were demos.  I played this baseball game-- very good graphics but couldn't figure out what I had to do in the game-- it just kept playing itself.  So it's not just eenie meenie minie moe for the buttons.

>And you think that mp3 vs uncompressed audio is completely analogous to 100 Hz vs 1000 Hz?

Actual that's an example where a person can't tell the different although there is a difference.  A better example is 44Khz sampling vs. 32Khz sampling of audio.  A few frequencies may get added in the higher rate which hardly anyone notices.

[amigaksi]

You haven't shown that your own code is accurate yet either. But regardless, even if by some miracle it is I do have a question:

How is it in any way an advantage when both the Amigas and PC-USB based control systems are far quicker then human reaction times?

If it's a miracle, it has already happened.  If you look at it logically:
(1) move a joystick from one diagonal to another and you can expect quite a few states it goes through; (2) move a joystick quickly up to down or left to right and it has to go through a state where nothing is pressed for extremely short time; (3) as already mentioned, pressing fire and moving joystick are independent so those states can have any small time amount in between.  (4) Even if you consider some noise in the data, it can ALSO get sampled in by the game and it would take it just as good as real data.  Human reaction times may be slower, but the game should play exactly according to joystick movement so taking into account more of the state changes means a more accurate reading.

I don't know which code you are referring to being accurate.  That dump of the data was using this code:

/* DUMPREC.C: Dumps joystick .REC file (c) 2009 KSI */

#include
#include
#include

#include

#include "types.h"

int main(int argc,char *argv[])
{
   FILE *f, *df;
   unsigned currstate,newstate,i,j;
   unsigned long dtL,dtH;
   char scratch[128];
   double ProcessorSpeed,cnvrt;

   if (argc<2)
   {
Syntax:
     printf("Syntax: DUMPJOY infile.REC outfile.txt\n");
     printf("Dumps joystick recordings done with MPDOS SuperPro.\n");
     printf("If you don't specify outfile, infile.txt will be outputted.\n");
     return 0;
   }

   f = fopen(argv[1],"rb");
   if (!f) goto Syntax;

   i = strlen(argv[1]);
   if ((argv[1][i-4]=='.')&&(argv[1][i-3]=='r')&&(argv[1][i-2]=='e')&&
      (argv[1][i-1]=='c'))
   {
     argv[1][i-3]='t';
     argv[1][i-2]='x';
     argv[1][i-1]='t';
   }
   if (argc==3) df = fopen(argv[2],"wb");
    else df = fopen(argv[1],"wb");  //default output file
   fread(&dtH,4,1,f);
   currstate = dtH&0xFF;  //current joystick state
   fread(&dtL,4,1,f);
   ProcessorSpeed = (double)dtL/32768.0;  //accurate to 838ns (max)
   printf("Recorded on processor running at %lf MHz\r\n",ProcessorSpeed);
   for (i=0; i<65535; i++)
   {
     j=fread(&dtH,4,1,f);
     if (j==0) goto ItsEOF;
     fread(&dtL,4,1,f);
     newstate = dtH&0xFF;
     cnvrt = (double)dtL/(ProcessorSpeed*1000.0);
     sprintf(scratch,"%d %lf ms\r\n",currstate,cnvrt);
     currstate = newstate;
     printf("%s",scratch);
     j = strlen(scratch);
     fwrite (scratch, j, 1, df);
   }
ItsEOF:
   fclose(df);
   fclose(f);
   return 0;
}

[amigaksi]

If there is variance of clock speed (even by a fraction of a second) between two otherwise identicle systems using the same cycle, both cycles will still be identicle, but the timing will be different. This is demonstrable for anyone who owns more then one Amiga, even of the same model.

You're mixing up your definitions again, I personally think deliberately here.

The NTSC/PAL crystals are by spec given a fixed frequency.  Now even if they deviate by one billionth or something, it's within the tolerance of the TVs and they are still considered to be at the same frequency.  You don't say my TV runs faster than yours.  Amigas use the same timing as NTSC/PAL crystals.  So I can say that CIA interrupts, Audio Interrupts, Copper lists, etc. all run at the same frequency across the board for OCS/ECS/AGA.

[amigaksi]

That's why I pointed out timing specifically "in units of time", rather than "in cycles" However, our friend here has been throwing around statements like "558ns with no +/- bullcrap", which is why I felt the need to clarify.

eg:



Absolutely no way can you say you can claim "558ns accuracy" when the clock signal itself is subject to variance.
...

You are making an absurd claim.  PC timers also claim a certain accuracy and their crystals are subject to same conditions as Amiga timers.  And that has NOTHING to do with latency.  Latency is the hardware deviating by a few cycles from the exact point when the event was supposed to occur.

>Furthermore, the clock speed is slightly different between NTSC and PAL Amigas. For example, in a base A1200, the CPU is driven from the same clock as the rest of the native hardware and the stated clock speeds are 14.32 MHz for NTSC and 14.18 MHz for PAL.

Just answered that for someone else:

The NTSC/PAL crystals are by spec given a fixed frequency.  Now even if they deviate by one billionth or something, it's within the tolerance of the TVs and they are still considered to be at the same frequency.  You don't say my TV runs faster than yours.  Amigas use the same timing as NTSC/PAL crystals.  So I can say that CIA interrupts, Audio Interrupts, Copper lists, etc. all run at the same frequency across the board for OCS/ECS/AGA.


T = 1/F that's how you get 558ns.

[amigaksi]

I know how to convert period to frequency, thanks. The point is that you are being very loose with your terminology.

No crystal timer is guaranteed to allow you to time something to exactly 556ns, no two amigas run at exactly the same speed, which is what your earleir posts were claming. No two PC's do either. They all operate within a certain tolerance

If you had stated your case in bus cycles, rather than nanoseconds, I wouldn't have pointed this out. As it goes, I was being deliberately pedantic in this regard so that you could appreciate how some of the pedantry in your argument sounded to the rest of us.

They also say the meter always isn't the same size.  I consider all these rubbish arguments.  They also claim PIT (8253) original timer runs at 1.19318Mhz which comes out to 838ns and has been used to update time in a PC.  So take your rubbish elsewhere.  You have to go by the spec.  There's also ways to make sure frequency is fixed using PLLs or other such mechanisms.  I still claim it's 558ns accurate.  I have no reason to claim it isn't.  All Amiga audio interrupts, cia interrupts, copper lists run at the same speed (NTSC).

[amigaksi]

... I'd expect code that reads from the joyport register address once per frame and whatever value was there at that particular instant is taken at face value by the application.




Can you elaborate on that?

Look, here's a real experiment that can be attempted and repeated:

Why not try sending completely synthetic 1ms wide pulses once a second for the fire button and seeing how the game responds. If it fires every second then you know the sampling must be high enough (or at least has some clever latching). If, OTOH, it fires only very sporadically, it isn't likely to be sampling at a high rate.

By widening the pulse until you get your 1 fire event per second being registered systematically in your application you will get a better appraisal of what the sampling period is likely to be. It will at least be in the right order of magnitude.

I would only be able to test that with games that allow you to fire more than once before the previous missile reaches its target or goes out of bounds.  But anyone can easily right an application that reads the joystick port and moves a sprite around within a few machine cycles and he doesn't have to wait for any VBI.  Joystick port is digital and can be read anytime unlike the potentiometers.

[amigaksi]

Are you sure?

Yep, just read the HPET spec which deviates by 2 clocks + or - from where actual tick count finishes.  Just run some copper color change in the middle of the screen (horizontally and vertically) and reply back when it changes position.