PC still playing Amiga catchup

[amigaksi]

No, I'm in the relevancy camp. No human can trigger a joystick input at 1 kHz, and no mainstream Amiga-compatible display has a refresh rate of 1 kHz. It's really a question of whether or not both an Amiga and a "PC" can sample, process, and respond to an input event in a timeframe that matters to both the application and the end user. In short, they both can.

Limiting the criteria under which either an Amiga or a "PC" can be said to be "still playing ... catchup" is a sad, sad way to win a debate in general terms. NTSC Amigas are faster than PAL Amigas, but that won't stop anyone from arguing over which is "better" in terms of end user experience. Change of subject: PAL Amiga still playing NTSC Amiga catchup?

My one thousandth post should have been more interesting.

It's still relevant though that joysticks are faster on Amiga since you use up less CPU time even if you read them 60Hz.  As for palette modes, I bet it's faster even on modern hardware to set up a paletted mode for editing cartoons, line-art, cad/cam, schematics, and other things that rely on exact coloring and do not want shading which would bloat the file size unnecessarily.  Paletted pictures would compress a lot more losslessly than saving them as 32-bit image files and would be far less data to deal with when editing them.  So in that case, swapping palette indices is a useful feature.  

If you want to argue PAL Amiga playing NTSC catchup-- you have to compare with timers.  Timers are suppose to work at exact rates.  And in that scenario, the Copper method of doing cycle-exact transactions w/ZERO latency is the ideal method of doing it.  Not only is it ZERO latency w/558ns accuracy, but there's not INTERRUPT overhead involved.  No stacks to save current processor conditions and return from interrupt.  Here Amiga wins as well.

[amigaksi]

How is the registry an abomination? I'm not looking for a debate; I'm just curious as to why you think it is.

A simplified abstraction of the registry is the tooltype, but rather than store named values in a shortcut (which is just an instance of the IShellLink object persisted to disk), they're stored in a centralized database.

The registry is more flexible than an initialization file, and if necessary, the two can be used hand-in-hand through mapping and redirection, assuming standard Windows APIs--GetPrivateProfileString(), SetPrivateProfileString(), et al--are used by the target application. In a multi-user system, you can work wonders with the registry at the data level that just aren't possible with initialization files. (You can get quite crafty with initialization files, but at some point, you end up with a database-like series of overlays, i.e. the registry.)

Granted, the hierarchical nature of the registry often leads to unnecessary complexity, but when used properly, the registry is a valuable tool.

It's useful until it becomes corrupt and renders the entire system unbootable. And of course, you have to deal with applications that write stuff to it and never remove it (bloating it) and spyware/viruses screwing with it. Continuously reading/writing same file means higher probability of failure of system than reading/writing different files.  I have seen several systems that wouldn't go into Windows because of registry corruptions.  I suppose you can get "lucky" if the back-up didn't get corrupted as well.  However, it would still affect start-up/shut-down times since you could corrupt the registry if you just turn off the machine and restoring it would increase start-up time.

[amigaksi]

You have not provided one shred of evidence to back that assertion up.

It's been bugging me for days as to why I've had this sense of deja vu...
...

I did give method on Amiga: $DFF186/$DFF19E for indices 3 and 15.  You save your shadowed registers from RAM to these locations.  As for API method, there's only standard API for setting logical palettes not physical palette entries.

I know you can insult people at a higher rate than USB 2.0 but that won't help you win the argument.

[amigaksi]

Still faster than all Amiga hardware.


Complied shader programs are programs. CPU is fast enough to feed the GpGPU e.g. Fold@Home GPU2 client.

It depends on the I/O port.  Also different motherboards I have timed give different results for same I/O ports.  If you went directly to hardware on PC in standard VGA mode, you can set palette indices faster but the point was making an API do it since nowadays video modes are nonstandard assuming you even have a paletted mode.  CPU is fast enough to feed the GPU but what is the overhead as compared to doing a few MOVE.W on Amiga.

[amigaksi]

then you are not reading too well.
the ability to retarget a command IS the advantage. there is no feasable way to have easy to program direct hardware programming that all chips support and still advance at a reasonable rate.

this is what happens in current systems today.

Hardware>driver(translator)>directX(or other standard api)>program

when new hardware comes out all that needs to be made is a driver to translate to the api. this is the strength of the system. yes there is some sacrifice in speed but even with this sacrifice you don't lose much.

you can't have your cake and eat it too.

I have read it will-- just the simple palette index problem should tell you how inefficient it is to go through APIs vs. doing it via hardware.  

Not everything needs to be retargetted.  It's better to have both API and hardware level compatibility so if you want to retarget go through the API.  Why force people to accept retargetability even if they don't need it and force them to use less efficient means.

There's not just sacrifice in speed though.  You also have restrictions on what API allows you to do with the hardware.  Many Amiga games wouldn't be possible if they only relied on API calls.

[amigaksi]

in c#

Code: [Select]

joystickDevice.Poll();

This is faster for a number of reasons. First of all, I didn't have to write the entire application in assembly language. So what if you can read the joystick with one mov instruction? Reading a joystick ain't hard no matter what the language and API you have to deal with. What's hard is all of the other parts of the game you have to write, especially the graphics. I don't know about you, but I don't like writing graphics code in asm. Some of the crappiest, most inefficient code I've ever seen was written in assembly language. The whole mantra of "code written in assembly is the fastest there is" is an exaggeration beyond belief.
...

It's given someone knows high level language and assembly, he can produce more efficient and faster code in assembly since he can better deal with misalignment, registerizing variables, use the flags optimally, etc.

>Second, I can read the value from two analog sticks and two analog flippers more than once per frame, I can do it as fast as the HID spec allows, and there can be a lot more analog controls on the device than that! Not so on the Amiga, only can do this once per frame. So much for the superior Amiga joy port.

No, now you are comparing another aspect of the Amiga joystick port-- the ability to deal with analog signals as well.  Games pick the better interface-- the digital one.  On PC even you are forced to use the analog joystick since that's the standard.  And even in the analog case, Amiga reads the POTs with one MOVE-- the hardware is doing the sampling for you.  I have never even seen an analog joystick on Amiga-- just paddles in some rare applications.

>With the Amiga Joy port, I get one 1980's era standard boring as hell joystick. Just one per port. Imagine playing Gears of War or Crysis with such a joystick. Might as well sit on the damn thing. On the PC I can have a dozen gaming devices. Mice, keyboards, steering wheels, foot pedals, yokes, game pads, classic style joys, harddrives, video output devices, video input devices, audio output devices, audio input devices, and the list goes on and on. All on one bus. With the Amiga joy port, I get.... a joystick... an old crappy joystick whose metal contact switches tie directly to I/O pins on some bizarre custom chip that's capable of recording the full glory of raw signal bounce. Oh how superior!

Wrong.  PC's gameport doesn't give you those options.  USB bus gives you ability to have faster buffer transfers but Amiga uses a different port for buffer-based transfers.  Digital joysticks are and were the norm for Ataris/Amigas/C64/Vic-20/Sega/STs/etc. whereas PCs were using the inferior analog joysticks.  So the Amiga's joystick port is optimized for digital joysticks.  Analog joysticks are crappy so only computer that used them were PCs which were NOT into gaming.

>USB HID devices output perfect state information to the computer...

That's a speculative remark.  Whatever you read from joystick port you can end up reading from USB HID device.

>All this being said, the Amiga joystick port is just another para interface hanging off a custom chip.

Aren't all ports some sort of interface hanging off a chip-- keyboard port on PC is hanging off some 8042 or compatible.  

>It is unusual in that you can fetch information from it rather quickly. One thing amigaski hasn't done in his argument is actually show real code that reads the joystick port as fast as he claims. He has a product which emulates joystick devices for the amiga by bit banging the para port on the pc, but notice he hasn't claimed there are games which are unusable using his hardware emulation product, which by it's very nature has to use the supposedly inferior db15 standard legacy joystick port or a keyboard for it's input.

I can also read digital joystick data and feed it to Amiga/Ataris not just analog joysticks.  And the fact that I have gone through all these timings is why I am so certain the analog joysticks are slower and inferior to digital joysticks and on top of that the interface for reading even analog values on Amiga is superior (due to less CPU useage).  By the way, the simulation of joysticks is only one part-- the same interface also simulates mice for various machines, disk drives, digitized paddles, etc.

It's not a big deal to write code to read joysticks as fast as I claim.

>The only devices that i'm aware of that actually use the limits of the Amiga joyport are audio digitizers that tie in to that port. I wouldn't be surprised if others on here know of additional devices that can use the capability of this interface. There are two words that accurately describe the Amiga Joystick/Mouse port: weird and suboptimal.

Amazing that you labeled it "mouse port" but did not mention that Mouse is one of the devices that port handles.  And you can send pulses through the joystick port for mouse every few microseconds (not milliseconds).  Joystick port also handles Light Pens, Paddles, Dongle-stuff, and also lets you control pins for input or output for controlling custom devices although there's a parallel port for doing that as well.

[amigaksi]

Erm, modern X86 CPUs includes micro-code translation engines i.e. on-chip firmware (look up tables) based decoders.


Unlike the GPU, the CPU is the host for control code. The application of hit-the-metal vs abstraction are dependent on needs.

However, they are maintaining compatibility, they are USING UP SILICON.  And I really don't think it's a big deal to add some silicon to maintain backward compatibility.  The actual silicon uses up only a small amount of the ICs space anyway so if they made the IC a millimeter bigger, it's no big deal given how miniaturized the fabrication process has become.

Since CPU is the host for control code, it has to spend time doing I/O to tell GPU to swap palette indices (assuming majority of GPUs out there even support paletted mode).

[amigaksi]

All of which still does not change that, despite a slower to react bit of port hardware that the PC will spend less actual time running the code to poll said port, even with the API overhead.

Or in simpler terms: the PC can do more other stuff while waiting for the IO device to be ready than the Amiga can. Which is to say that even though it uses API's to access hardware, thanks to being really, really, really fast it still is faster than the Amiga to execute the relevant code (i.e. poll the hardware).

That it needs to wait longer for the hardware to be ready is irrelevant because this discussion is not about the speed of a parrallel port controller (which is the primary cause newer PC's have slower ports) but about the overhead incurred by the API's and drivers driving said controller.

It depends on what instructions you try to do in parallel.  If you do an IN AL,DX then TEST AL,128 obviously, you processor has to finish the IN instruction however long it takes.  I was giving case where using AMIGA direct access outdoes PC going through API since API is more restricted than going directly to PC hardware.  So, you can't draw the conclusion that API access will be still faster than Amiga going direct to hardware.  If API call was just doing the exact thing you would have done with the hardware, then you can say the overhead is minimal given processor speed of PC.  Also for input like USB input of joystick or gameport input of joystick, you will be doing multiple I/O instructions whereas Amiga does one.

I don't know what you mean by parallel port controller is primary cause of slower ports.  It's not.  Parallel ports are usually PCI in the latest machines that have them; however, there are other I/O ports like 60h..64h (keyboard) that are much slower.

[amigaksi]

I still recall Saddam Virus from mag cover CD on my classic Amiga 500.


This an OS issue. Run AROS X86.

It's an OS issue but that's what that particular point was about.  Amiga OS doesn't fill up some big file which failing causes an entire system failure.  I think they should allow system boot to continue allowing user to disable registry useage.

[amigaksi]

With GPUs, parallelism and maximum math unit counts are the priories.


The thin libCGM didn't solve RSX's design flaw.


Amiga's API is primitive.

Yeah, parallelism and math units may be priority because everything is already standardized toward some API, but it would be better if hardware level compatibility was standardized and then API can still be built on top of that.

Amiga's API may not be as rich as modern APIs but even modern APIs don't offer the flexibility of going directly to hardware.  There are many things that are still inefficient using API approach.  As I stated, it's HLI (hardware limiting interface).

[amigaksi]

perhaps you misinterpret this. there is this movement in the pc world where legacy ports are getting replaced by a single port(to make them cheaper). perhaps that is where the reason lies.

keyboard
at>ps2>usb

mouse
serial>ps2>usb

joystick
joyport>usb

Printer
Parallel>usb

External Modem
serial>usb

see a trend?

There may be move toward USB, but the fact that they left certain ports in while eliminating gameport should indicate they are trying to improve gaming interface.  I.e., they are admitting gameport sucks and user is better off using another interface.  Newer audio cards also aren't using gameport although it was built-in into many audio cards.

[amigaksi]

actually you just told us why an api is important.
...

I never said API is useless-- it's inferior to hardware level compatibility.  What I stated is:

"Not if hardware is backward compatible. You can have well-behaved applications that go directly to hardware. There's many on PCs as well as Amiga. It's just that now PCs are more API-centered which is worse for them."

>now while that is true just because you can don't always mean you WILL have well behaved programs. as such the api offers an easy way to write a program and Forces you to make the program compliant.

You can have API applications that corrupt things as well.  Amiga applications/games that go directly to hardware are being used and there are thousands of them.  Just because someone abused that advantage doesn't mean you should get rid of that advantage.  Perhaps, they should first worry about getting rid of spyware/viruses which use APIs to attack the system.

>another thing a good api has contingencies in case a function does not work. it is not just about speed but also reliability. operating directly on the hardware could cause an exception which could freeze not only the active program but also lock up the os as well. even if that program was written properly.

You can also cause exceptions by kernel drivers bugs which are using APIs but are at ring 0.  Bugs can exist in both.  And for some applications, you don't want the OS involved.  You can still have I/O protection and memory protection in hardware (as exists now) even when application goes directly to hardware.

[amigaksi]

Nope, it's on the Super I/O chip, which can be on it's own IC or integrated into the northbridge. Either way it's on the low pin count bus along with the flash rom and other crap.

What are you saying "NOPE" to?  He stated that parallel port is causing slowdown of other ports which is false.  Each device can cause it's own slow-downs.

[amigaksi]

simply because there is no one entity that can force all hardware manufacturers to abide in any one standard. as such there has to be a buffer this buffer is the api.

...

That's the chaotic scenario now because they are BASING STANDARD on APIs.  Preivously, all manufacturers were complying with hardware standards-- look at PS/2 keyboards and ports, look at parallel ports, look at VGA/EGA/CGA cards, look at serial ports, look at floppy drive interfaces at 3F0..3f7h, etc.  By the way, even now there are devices that are based on hardware standards based on ACPI specification.  So whoever thinks it's not doable nowadays is just speculating.

>this is true however as these new features come into existance the api is updated with functions that allow you to use the features that programmers need and want implemented. as such those games are still possible you just need to be creative with what you have.

You are more restricted with APIs; APIs are slower and inefficient.  APIs are more inexact.  You can also update hardware and allow previous software to still run the same.

[amigaksi]

Yep, its so much better to bang the hardware directly have things break when new machines come out. Or new hardware comes out and the old software runs too quickly.

Coz banging the hardware directly has worked so well for the Amiga. Look where it is now..

You mix up nonstandard hardware with standard hardware.  If hardware is standardized on I/O ports, memory map, etc. the old software still works on new hardware the same way.

You're speculating that Amiga going bankrupt is due to hardware compatibility.  That's one of it's good points.

[amigaksi]

In a perfect world, where programmers are immaculate and hardware documentation is written by God himself. In the real world programmers have a hard time dealing with pointers in C and buffer overruns by 1 are common place. It gets even worse when folks start writing stuff in assembler, especially on processors with complicated opcodes and general purpose registers that aren't really general purpose.
...

We're not talking about some individual's capability to program.  We are talking about OBJECTIVELY which is better-- having ASM and C together is better than just C.  Similarly, having API and direct hardware access is better than just API.

>I'm just writing about the Amiga joystick port you've labeled as "superior". You don't get to dismiss reading potentiometers with said port just because it makes you mad it's so dang slow at doing that operation. Lots of games take in pot values. You're just gonna have to live with that.

More applications use digital joystick since it's superior to analog input.  You are using a self-contradictory argument.  First you state I don't get to dismiss pots and then you go later and dismiss light pens.  And on top of that, I am not dismissing the pots-- I am stating they also use up less CPU time.  But they are not as useful given you also have the choice of using digital joysticks whereas on PCs, you don't.  "Lots of games" is vague.  Majority of games use digital joysticks.  You can also start sampling pots for smaller values rather than wait for scan to complete.  You can also use MOUSE on the joystick port.

>I wasn't refering to the damn db15 legacy PC game port that hasn't been screwed into the side of a case in the past 10 years. The bit about connecting harddrives , sound cards and multiple game pads should have been your clue that I was talking about USB.  

Gameports were on audio cards a few years ago and supported by XP.  Even your USB is slower to read than a MOVE.W on Amiga.

>No it's not. You'll never read signal noise from a USB gaming device. Try it.

Bullcrap.  I can read some joysticks on Amiga w/o any signal noise whereas others have noise.  It depends on quality of joystick.  There's nothing in your USB cable that's going to prevent signal noise.  If you want to perform some special software algorithm afterwards, then you slow down read time even further.

>The 8042 *is* the ps/2 keyboard/mouse controller on the PC. The Amiga joystick port hangs off the Denise chip. A chip that handles video timings and sprite crap, and also apparently, the joystick interface. That's a hack, it probably wasn't even originally designed to be joystick interface.

Mouse on 8042 is ALSO a hack.  Denise was built for controlling multiple devices.  That's really a lame argument.

>Of course reading the pots are slow, it's slow ass legacy hardware, on both the amiga side and PC side. It's been a long time since I've read the data from a db15 legacy pc joy port.

You have no choice but to read analog.  If you had both analog and digital (like Amiga), you will see how quickly people would have used digital in majority of cases.

>...not on modern devices, the kind that plug into the USB port. The issue isn't that the device is slow, or that analog controls are crap, its that the hardware reading them is crap, and old.

For games requiring motion in 8-directions, it's EASIER and FASTER to use digital joysticks.
They now are forced into analog joysticks where they are UNNECESSARY.

>Yea, sure, you can do all that with one port, but only one device on each port. Also, when was the last time you saw a light pen?

See here's your inconsistency.  I never saw analog joysticks being used either but if you want to count them in then mine as well count in all other devices on the joystick ports and there's plenty of them.  There's also trackballs, foot pedals, steering wheels, etc.

>This whole argument that you have is based on two things: One is that you're comparing the Amiga joy port to a legacy db15 PC joy port that nobody uses anymore. That's ridiculous.

We are comparing with REALITY-- PCs have mainly relied on gameport for joystick input and Amiga has relied on digital joysticks.  When you write a game, you have to live with REALITY of what's out there.

>All you're picking up is gobs of signal bounce. It's the farthest thing you could ever get from superior that one can imagine.

You still don't get it.  It depends on the joystick and all that data which you conveniently picked out a few values to suit your needs was NOT bounce.  There are REAL millisecond readings that are not bounce.  If you are so sure about bounce, then explain why you get a series of millisecond readings and also a series of submillisecond readings.  Can that happen using same joystick and both be noise?  And what prevents someone from pressing fire button while moving joystick at arbitrary time?

>If you're gonna make a rational set of arguments, at least compare the Amiga joy port to an actual interface the PC uses, namely, USB. Anything else is dishonest and a waste of time.

I compared to both since both are out there.