PC still playing Amiga catchup

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

[amigaksi]

This is simply not true.
...
[/quite]
It's true.  You can get more efficient code if you know Assembly language coding.  Just as API is restricting you from hardware so high level languages restrict you from using the full power available of the processor.

>Optimizing code is already quite hard to do in higher level languages*. Going to lower levels does not make it easier, it makes it harder because you now have to both choose the best algorithm (where 95-99% of your performance will come from - even the best assembly coded Bubble Sort ever won't beat even the lousiest Visual Basic Heap Sort ever for anything above say a thousand entries to be sorted), the best way to implement the algorithm you chose considering your application requirements and you also have to do that in the best, most optimal way possible in assembly. ...

You are mixing algorithms with optimizations.  If you have the same algorithm, asm version wins over high level language version.

>Not to mention that modern compilers are actually quite good at doing all the things you suggest as they use the same tricks you describe. Or the fact that todays programs tend to be a 'tad' more complicated than something as trivial as sending some bits over a parralel port.

Well, don't think it's trivial sending bits over a parallel port.  In my application, even the minimal overhead of API call to do parallel port output/input is enough to make application undoable.  It has to be done via direct to hardware method.  Compilers can only optimize the functionality supported by the high level languages and that also according to some preset algorithm.  ASM programming gives you more power for programming.

[amigaksi]

None of those points are specific to Windows or the registry. They affect all systems. I've seen several systems with corrupt registry files as well--several out of tens of thousands. In all cases, the corruption was caused by a disk fault, and all could have been prevented if the end user had been paying attention to the diagnostic warnings generated by the disks.

I've had more issues with corrupt files on OFS/FFS file systems over the last few months than I've had with NTFS file systems over the entire history of Windows NT.

I don't think it's disk fault as reformatting disk drive or reinstalling registry (if you had backup and had used FAT32 and booted via DOS) made system useable again.

Yeah, there's MTBF of disks, but the idea of writing to same file over and over again for all that information verses many different files makes disaster bigger on registry than on Amiga.
Amiga disk failures are due to MTBFs or disks lying around in dirt/damp places.

[amigaksi]

Hardware was standardized. The PC market eventually settled on VGA, and all was well. Along came 3dfx, the Glide API, and Quake, and all of a sudden, VGA didn't satisfy the demands of the market. Nvidia stepped in with the Riva TNT, and along with Id and a few other major software players of the time, Nvidia helped bring OpenGL to the mainstream consumer market. It continues today, albeit with fewer major players.

If hardware were standardized, no one solution would stand above the rest, and the market would stagnate and eventually die. Standardizing APIs allows both hardware and software designers to innovate without interfering with the other's core competencies. It's a good place to be. Really. (The APIs aren't technically standardized either. You have lots to choose from. More competition, more drive to innovate.)

More APIs less hardware standards translates to: (1) More confusion, (2) more inexactness, (3) more restrictions as to what a standard game/application can do, (4) more inefficient code, (4) more bloated OSes with hundreds of drivers and different APIs supported.  If they had just standardized the I/O ports or memory map areas, then the competition can still be there.

[amigaksi]

I'm beginning to think that amigaksi is actually not debating the actual time needed in some of his examples, but purely how many processor cycles it takes to achieve them. I could be wrong here, but if he does it would explain some of his objections.

Needless to say, this is not a very good way to look at things. Almost everything in modern computers (and that includes setting up the GPU) is IO limited and not processor limited. Severly so. Even onboard RAM is considered 'very slow' by the processors of these days. And that doesn't even go into the effects caches, multicore, pipelining, branch prediction, etc have on just how many cycles something takes to do.

In essence the IO overhead limits or even outright negates any API overhead you might incur.

No I am actually looking at time of execution of I/O instructions.  API does have substantial overhead if it's not exactly meant for doing what you want to do with the computer.  Then you have to go through the inefficient API calls and suffer the penalties of inexactness and slowness.

[amigaksi]

Unless it's interupted during the IN AL,DX by say, the task scheduler and gets to do something else. IO is almost always done in an synchronous way on PC's. And I'm pretty sure that waiting on the joyport/parrallel port/serial port/whatever port doesn't actually stop me (and therefore the processor) from doing other things.

...

It's not done in parallel usually.

[amigaksi]

Commodore was unable to react as quickly other companies...

And during VGA standard card development, some bigger companies beat other smaller companies in developing standard VGA cards that had backward compatbility in hardware.

[amigaksi]

Ahem, you did forget firmware’s role?

An ACPI system consists of a series of ten tables. These ten tables define which devices are present on the system and what their capabilities are as they relate to configuration and power management. These tables are built by the system BIOS at boot. When the system boots, it looks for specific entries contained in two of these tables (the Fixed ACPI Description table [FACP] and the Root System Description table [RSDT]) to determine if the system is ACPI compliant. This information is extracted from these tables in the form of an OEM ID, OEM TABLE ID, OEM REVISION, and CREATOR REVISION. If these tables are not present or the information contained in the descriptors above is invalid, the system is assumed to be non-ACPI and the legacy hardware abstraction layer (HAL) is installed.

...

There's more than ten tables.  It looks like they append newer tables as newer hardware is added.  You can fetch various things like I/O port addresses for SMI and so forth and read/write directly to I/O ports.  If all the chaos of various other audio/video/ethernet/etc. cards didn't arbitrarily use I/O port, memory map resources they could have fixed the I/O port addresses but ACPI is dealing with in best way given the chaos of people using their own I/O ports/memory maps.

>It fosters rapid GPU hardware development.

>Depends on APIs.

APIs are always slower than going direct.  You can draw that conclusion logically without having to measure the time.  They still have to develop GPU hardware to newer functions supported by API and still use some I/O method so I don't see how much harder it can be to develop to some specified I/O ports and memory map.

[amigaksi]

actually that port was the easiest to replace because it was relatively unused by most users. those that did use them just went with the flow and upgraded to usb. they were not singling out gameport users. ps2 users resisted the change so they tended to hang around. same with parallel users(until usb printers became common) now they may or may not be there an motherboards. serial ports are sill used for industrial applications even tho outdated so those are usually still on the motherboards.

Must be a billion gameports out there-- perhaps a few million trashed.  So it's hard to make a statement-- it's unused.  Perhaps, you don't use the gameport.  And my motherboard has a parallel port and PS/2 connectors -- no serial port.  So your speculation serial ports are still around is just your experience.  I see more desktops with parallel ports.  By the way, Microsoft must have done some gaming research to come up with XBOX joysticks.

[amigaksi]

i know what you said. but you qualified your statement with "well-behaved."

...

You can have well-behaved of any software-- one that goes direct to hardware or API.

>well-behaved apps could go to the hardware more efficiently BUT this is only if there is no hardware errors in compatibility.

That's worse for APIs.  If there are hardware errors, they are usually published and kept so you know they will be there.  If you fix them in APIs, then you have to worry about whether the user has the erroneous version or newer version.  Sometimes hardware errors are taken as features like enabling 7 bitplanes in OCS to enable a static mask bpldat.

>the api allows a buffer zone as i said so that if the hw has bugs the manufacturer can work around them. also if an api fails then there is coding that will reset the api so the os does not die. however if you go direct to hardware there is no such coding at present to handle this kind of event which has the potential to lock up the os.

Sorry, but application API access is protected by OS but drivers using APIs aren't.  So they are likely to cause OS lockups just as well as one going direct to hardware. But you can also protect applications going direct to hardware using IOPM.

>by definition direct to hardware is DIRECT there is no floodgates in between for protection. if you do we are back to the api model.

Sorry, that's not how IOPM works and there's no API model involved.  If you wanted to protect your hard drive I/O ports, you can protect them via OS and application can go direct to hardware and only OS will get control if application accesses those I/O ports you protected.  Application does not have to use API.  My application (MPDOS Pro) is an example that goes direct to hardware on I/O ports and does not use any API calls and keeps OS stable.

[amigaksi]

Reformatting or restoring the file would most likely place the data on a good sector, leaving the bad sector unused and waiting for the next unwitting block of data to be written to it. It depends on the disk and the allocation scheme used.



Of course, but it could also be caused by an interruption to the OFS/FFS file system routines, which are in no way fault tolerant.

The most likley cause of the problem in both cases (regsitry on NTFS v. arbitrary data on OFS/FFS) is a disk failure or a catastrophic system failure. Edge cases related to file system deficiencies and unsynchronized access to data structures are less common, but NTFS obviously has an edge over OFS/FFS.

Actually, hard drives are more robust now then they were in the past.  But writing to hard drive (especially registry) when there's power outage or you turn off the system can cause corruption of the file and that problem has nothing to do with hard drive failure.  It can happen on brand new hard drive.  My point is that in that case Amiga's simpler style of writing data to separate files would cause less damage.

[amigaksi]

By defining those standards, you limit innovation. How wide are the ports? 1 byte? 4 bytes? 8 bytes? How large is the framebuffer? 256 kilobytes? 4 megabytes? 256 megabytes? 1 gigabyte?

The only surefire way to provide both backward and forward compatibility is an API, regardless of where that API is implemented.

Sorry, but I did give many examples of how this standard can be hardware based and not limit innovation.  VGA was 8-bit initially.  They made 16-bit VGAs (ISA) then 32-bit (VESA) and then 32-bit (PCI) and then AGP and so forth.  Even if you wanted to add new ports, you can still retain the old ones.  API is the inferior method of doing it.  It may be cheaper (save some silicon), but it's worse for the general user who can better optimize things going directly to hardware.

[amigaksi]

It's not? Even the Amiga did things in parallel, hence the sensitivity to actions that interfered with system timing, e.g. a CAS instruction.

Most (not all, but most) new systems sold today have at least two CPU cores, never mind the number of independent execution units on the cores themselves. Parallel execution is now the de facto standard, whether your software is aware of it or not. You can ignore parallel execution, of course, but only to the detriment of the rest of the system.

If you do an IN AL,DX and then switch contexts the stack will save (EAX,EDX) at least which are related to the IN instruction thus no parallel instruction can execute until this one finishes.  I am just speaking of context switching on the same processor.  You have to wait for IN to finish to use the joystick data or whatever other device you are doing IN from.

[amigaksi]

No the hell you didn't. You've just given us platitudes about BS while ignoring how modern hardware works.

You look like you had a bad day.

[amigaksi]

I had a great day.

Then you should have read post #857 where I clearly stated the examples:

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]

Nope, this is wrong. Nobody uses that hardware, no modern machines ship with it. Folks haven't used it in 10 years.

You did have a bad day.  I use IN AL,DX in 2.8Ghz Dell machine and in this other AMD Sempron 3000+ machine.  Unless PCs have this instruction, they aren't backward compatible and not really "PC"s.