PC still playing Amiga catchup

[ElPolloDiabl]

He basically implies, that today’s engineers are dumb and stupid.

Speaking of Engineers does anyone know if the original 3DFX creators are still at the helm of NVidia?

I'm asking because the attempts I've seen to emulate reflections and shadows in 3D games is pretty dodgy.

[ElPolloDiabl]

And also...

I've seen better physics simulations from Wile E. Coyote and Road Runner compared to the CGI in Mr. Spielbergs War of the Worlds.

I hate to say it, but CGI in most movies is nonsense because they don't properly calculate the physic, light distortion, light scattering etc.

[Karlos]

But Smerf don't you get their standard reply yet:  "they don't use a floppies, so they don't format them, they don't care, it doesn't matter.  PC wins"

It's true that my current system has a multiformat card reader where the floppy might fir but my old AMD duron has a floppy disk drive and I never had any problems using it with either Win2K, WinXP or Linux.

I do fully recognise the "floppy death" syndrome that seems to infect PC's from a decade ago when people were using Win9x. I think it had more to do with the design of Windows than the hardware.

Actually, my work PC also has a floppy drive. Let me mount /dev/floppy and see what it does...

[Karlos]

Nope, no real handicap from using the floppy drive. Finding a disk to test was much more difficult :lol:

[jkirk]

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.

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.

[jkirk]

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

i know what you said. but you qualified your statement with "well-behaved."
well-behaved apps could go to the hardware more efficiently BUT this is only if there is no hardware errors in compatibility. 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.

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.

yes you can however the api reduces that chance and also can recover from bad coding easier.

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.

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.

from the direcX wiki

DOS allowed direct access to video cards, keyboards and mice, sound devices, and all other parts of the system, while Windows 95, with its protected memory model, restricted access to all of these, working on a much more standardized model. Microsoft needed a way that would let programmers get what they wanted, and they needed it quickly; the operating system was only months away from being released. Eisler (development lead), St. John, and Engstrom (program manager) worked together to fix this problem, with a solution that they eventually named DirectX.

[persia]

It really hard to think of a use for a floppy, they hold about a quarter of an average song or half a holiday snap.  My Flash drive is far smaller and holds 8 GB.

My experience with floppies was not a happy one, they were prone to failure, slow and just cantankerous.   I don't miss them one bit.

I hate to nitpick, but he stated 'probably 15 years ago'.
I'd hardly see you doing any of those things on a bog standard PC from 1994

Heck, most of the PC's out there today can't do all of those things, let alone at the same time.

(Disclaimer: this does not mean I don't feel PC's have long since surpassed the old Amiga, it merely means I feel most people on these boards overstate the capabilities of the average PC)

It's true that my current system has a multiformat card reader where the floppy might fir but my old AMD duron has a floppy disk drive and I never had any problems using it with either Win2K, WinXP or Linux.

I do fully recognise the "floppy death" syndrome that seems to infect PC's from a decade ago when people were using Win9x. I think it had more to do with the design of Windows than the hardware.

Actually, my work PC also has a floppy drive. Let me mount /dev/floppy and see what it does...

[bloodline]

It really hard to think of a use for a floppy, they hold about a quarter of an average song or half a holiday snap.  My Flash drive is far smaller and holds 8 GB.

My experience with floppies was not a happy one, they were prone to failure, slow and just cantankerous.   I don't miss them one bit.

I miss floppies, like I miss smallpox...

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

[bloodline]

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.

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

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