PC still playing Amiga catchup

[bloodline]

I have been itching to try it at 6-6-6, just to see what happens...

I set my memory timing to something stupidly low (especially given the cheapness of my RAM modules).. the machine just got stuck into a reset cycle... I had to reset the BIOS to restore.

[bloodline]

My motherboard has "dual bios", so that shouldn't be a problem. You can roll back any destructive change.

Oh... So we are gonna have a "My BIOS is bigger than your's" argument eh? Fine... most of my machines use EFI... hmmm that's probably not something I want to brag about  :roflmao:

[bloodline]

"Boot-time whining"?  You don't think boot times are significant?  Why then at many Windows discussion forums do people regularly make posts about boot times being too long for Windows based PC's especially those that run Vista, why are there so many articles about how people can modify windows to improve boot times, why is Microsoft itself making a big deal that Win 7 boots faster on the same machines than Vista?  The woman in charge of Vista has publically said that Win 7 & MS will attempt to address something they have failed to do in the past: make the PC responsive to the user, put the user in control, meaning that its an admission that its previous OS's weren't this, something the Amiga always has done.  Boot time is one of the top two or three things that concern MS and PC users, it MATTERS.

I use a Mac, I rarely turn my machine off... I just put it to sleep... I don't care about boot times.

[bloodline]

>No, if you write an app that uses standard OCS hardware (let's say an old A500) or even uses the kernel functions that's in no way a guarantee in itself that it will work on other Amiga systems.

Bullcrap.  AGA is backward compatible with OCS/ECS as per spec.

You have never programmed an Amiga then... AGA was not that compatible with OCS/ECS... the chipset even contained a compatibility mode that could be switched on during the early boot sequence to degrade the chipset features to the older spec.


I have tried to follow your weird Joystick argument... I can't think of a single game that I or anyone else has ever written on the Amiga that checked the Joystick status more than once a frame... if it did then any related animation would be jumpy, since there would missing frames...

You can read any register on any system as fast as the busses will allow... but if you can read the port faster than you need to, and you do read it faster than you need to, you are just wasting bandwidth.... with the Amiga there is precious little bandwidth, wasting it all trying to read the joystick one thousand times a second would just steal the bus time away from the audio and gfx circuits that do need to read memory and registers that quickly.
If you want to sample something at a stupidly high rate there are plenty of available options on the PC... I use an FA-101 Firewire box to sample 10 channels of 32bits at 192Khz... that can be processed in realtime... that sort of pisses on your weird little 1khz joystick port...

[bloodline]

spec sheet says 6 24bit channels in at 192KHz.

you're quite right, it's only 96khz with 10 channels :lol:

[bloodline]

@amigaski

If you are going to pivot the crux of your argument around precision timing with this degree of anality, then I am forced point out that the argument that all amigas have exactly the same timing, expressed in units of time (as opposed to cycles), is not true. You have not factored manufacturing tolerances of the clock crystals, nor have you factored in nonlinear effects caused by slight differences in temperature and voltage.

No two clock crystals give exactly the same timing, they just aren't that good.

And certainly when the Amiga was being manufactured (not to mention the cheapness of Commodore) the tolerance of the crystals were very very poor... fortunately the quality of the display and audio equipment of the time were so poor the timing could be quite imprecise.

[bloodline]

Dude, you've recorded contact bounce (which means that you actually need to sample multiple values, which in turn means you get much longer readings than the ones you discussed earlier).

:lol: amigaski has forgotten that physical switches have a maximum switch frequency... any amiga joystick will use cheap switches that will switch far bellow 1khz

[bloodline]

The funny part is that it's fairly common to poll the joysticks only once per VBL, which generally means every 20ms on the Amiga...

And polling at the frequency he mentions gives erroneous values - that actually means it's inferior to modern counterparts - which is even more funny considering the argument used in this discussion.

So in fact the Amiga hardware is inferior to the PC since it doesn't debounce the input signal hahaha

[bloodline]

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.

I have an A500 here, with an ActionReplay Mk3... I can show the system clock speed down (to assist with difficult parts of games), despite changing the clock speed, the A500 remains cycle accurate.

By Amigaski's definition, my A500 is no longer cycle accurate... weird thought... also by slowing the machine's clock speed down I can test if any game really does use a sampling frequency higher than the frame rate.

[bloodline]

For a single pot value, doing 441 multiplications, 440 additions (most of which could be optimised using multiply add style instructions) and a square root might take at most a few hundred cycles. You can even get rid of the square root all together and just have the values in your calibration table squared and look up the nearest match. However, even with the square root, on a GHz class machine that's peanuts, you are looking at microseconds. Given that searching through the 441 samples will require as many memory accesses, which are by far the slowest operation in the task for a modern CPU it probably wouldn't be faster.

I think encoding the x/y signals in a single channel, while efficient and the "right way" to do it, is overly complex for this application... just have two square wave oscillators, and alter the amplitude depending upon position... the Audio interface I referred to has 10 channels, but even the simplest audio input has two channels... x on left, y on right.. simples

[bloodline]

I wasn't encoding them into a single channel, I was suggesting the attenuation of the output of one mono oscillator separately into left and right (the volume levels for left and right representing representing X and Y respectively) and then analysing the RMS values of each 441 sample frame for left and right independently to infer the X/Y pot values.

The reason for RMS is to calculate a representative value since you'll never get an exact number of oscillator cycles (regardless of waveform shape) in a single frame.

If you are going to go to the trouble of 1kHz sampling of your analogue joystick, there's no point in doing it half arsed, eh?

Well... I can't really see the point of a joystick sampling at 1Khz... so it wouldn't make much difference, in reality...

[bloodline]

What? Are you insane? :p

:lol:

[bloodline]

Hardware is not supposed to suddenly change-- it's suppose to retain backward compatibility like for example 8253 is still in modern PCs although they added other means for timing things.  It's more efficient to do ASM instructions that directly read/write I/O ports than go through API calls.

Have you ever read the errata page of a modern chip?

[bloodline]

the only reason this is there now is for a generic driver in the bios to display bootup messages. and windows to load a generic driver on initial bootup. this is not backwards compatibility just a basic commandset.

as for processors the same thing goes as vid cards. there is just enough functionality for bootup processes. this coding has to be standardized to get the system going due to the small size of the bios.

nearly all soundcards use the soundblaster 16(compatible) commands also for a generic driver.  however to get the most out of it you need the driver for the card you are using. all they did was create a subset on the chip for the most basic functionality. so no there is no backward compatibility just SB16 compatibility.

simply you are mistaking backward compatibility to a basic codeset for initial bootup.

More often than not, this backward compatibly that the hardware offers, is actually just an emulation... which links nicely to amigaski's other "ignorance thread"...

[bloodline]

They speed up processors and functionality while maintaining compatibility; they sped up VGA and functionality while maintaining compatibility; Creative Labs made all those Sound Blaster cards while maintaining backward compatibility.

I though I'd find a nice little article for you that details the problem Apple have faced:

"
Managing the platform

Another aspect to keeping technical specifications out of the limelight is that Apple is careful to expose access to hardware components in a manageable, sustainable manner. If developers are allowed to write "to the hardware," the result is a broken platform where the vendor can't move forward without breaking the apps.

Apple experienced this problem in the clever hacks to the classic Mac OS which resulted in destabilizing the system, a problem that got progressively worse after the company sanctioned the system patches in System 7 under the name Extensions. In Mac OS X, reference releases have been plagued by Input Manager hacks that similarly caused some serious compatibility problems.

That has led Apple down the road of a tightly managed iPhone platform where the execution of third party software requires code signatures and sandboxing, and where access to hardware has been roped off until the company could perfect abstracted public access to features in a way that can accommodate new underlying changes as future models are released.

Users shouldn't need to know how much RAM is available to the operating system of a mobile device, or how fast its primary CPU core is clocked at; what they should care about is how usable the device is and what it allows them to do. That's the message Apple is working to control."