Atari v Commodore

[atariksi]

Doubt it.

 

emkay should know every little nuance of emulated Pokey sounds - he's usually the first to step up and criticise it.

Why don't you just try it?

 

So long,

Thomas

 

You can't judge the whole by a small sampling. You need a deductive process to prove it's actually simulating the POKEY audio part properly. (Obviously, it's not simulating the POT inputs or timer IRQs as those resources don't exist on PC).

 

Your "logic" is akin to someone looking at the earth and declaring it flat without any deeper analysis.

Why don't you just try the *emulator*? First *test*, then *criticize. In that order. I'm always open to suggestions if that doesn't fit your needs. So please don't tell me want I can and what I can't.

 

Thank you.

 

It does not prove, it's emulating the POKEY if you get it to work with a few samples.

[thorfdbg]

It's not really a simulation if everything is delayed and out of sync with rest of hardware.

Do you realize you can set the audio latency? Want a 60th of a second buffer? You just have to stuff it more often. I don't understand the obsession with timers and whatnot for emulation. If you need cycle-exact everything, there's only so much you can do on non-native hardware, but the PC can emulate every real-time change to the raster and every real-time change to the audio (provided the library supported it) and the results can all be lined up quite accurately. Maybe the IO ports have to be simulated, but I feel like your objective is to somehow declare the Atari to be a superior computer to the PC.

 

Timing plays a role in real-time changes to audio. You can modify audio at a much higher rate than 60Hz. You can stop speculating regarding what I am trying to declare as I am only looking at one hardware aspect here-- timed audio. PC cannot do every real-time change given it's less resolute timers. Unless you have a PC with some higher resolution timers or audio hardware (Non-standard).

The timing on the PC side is rather irrelevant. What is relevant is the latency of the overall audio buffering, i.e. how "short" a sample to be played by the audio hardware can be. This doesn't depend on PC timers at all since the timing isn't driven by the PC timer in first place. It is driven by the emulation speed, and by the ability of the operating system (or its underlying sound system) to provide a latency short enough to ensure that the CPU time in the emulated machine doesn't "lag" too much compared to the PC time. You don't use PC timers to time Atari audio - this is just folly.

 

Interestingly, the Linux "alsa" system seems to be much more capable than windows DirectX sound system, which I found astonishing. Alsa has a latency that is about half as long as the DirectX latency...

 

So long,

Thomas

[thorfdbg]

It does not prove, it's emulating the POKEY if you get it to work with a few samples.

 

Sigh. What's so hard to understand on this simple concept: *If* you think something doesn't work, please provide me with details *what* doesn't work. You stand here claiming that the sound emulation isn't working as it should be, declaring things impossible that might not be quite impossible as you might believe. But anyhow, as I'm a physicist, I believe in evidence by experiment. What's so hard about simply first trying, and then stating what is and what isn't possible. Doesn't that sound fair enough?

 

I'm not trying to *prove* that everything works correctly - simply because I know that there are certainly gaps - but I would believe that it is highly likely that more things are working than you would believe to be working.

 

So long,

Thomas

[atariksi]

Everything is delayed, just like it is with the graphics as well

This wont affect the accuracy of pokey sounds though

 

It sure will-- it depends on how much you delay and how much of the audio the application is modifying.

 

And delaying will throw off any synchronization between the picture and audio and joystick input. Or are you going to buffer joystick input as well!

 

The application running under emulation should be completely unaware of any timing at all. The delay is external to the emulator.

You are correct about joystick input - that will be synced with a constant delay, but the audio and video should remain locked.

 

That's the problem w/buffered approach is that the delay. The audio/video does not show up as real (in experience) until that delay whereas it shows up as real on the Atari without the delay. You can't state "synced" and "with a constant delay"-- that's not synced. Even audio and video does not remain locked as I have done this already-- play digitized audio at some rate (4Khz...48Khz). You will notice the drifting error in total time to run the sample due to crystal timing issues. For example, Sound Blaster has 1Mhz crystal and to get 11025 Hz playback, your choice for dividers are: 90 or 91 which gives 10989Hz or 11111Hz. On Atari, 11025Hz uses a dividers of 162 or 163 giving 10980 or 11048Hz. The error is greater with lower timing crystal. Now if you have synced up video to this, it will eventually drift. And then add in dynamic effects like echo or something which modifies the waveform and you are in even more trouble with a buffered approach.

[Bryan]

You are obsessed with minutiae.

[Fröhn]

That's the problem w/buffered approach is that the delay. The audio/video does not show up as real (in experience) until that delay whereas it shows up as real on the Atari without the delay. You can't state "synced" and "with a constant delay"-- that's not synced.

And just like the audio has a delay, the video has a delay too. So the only thing you need to do is to make the delay the same by choosing a suitable sound buffer size.

Edited December 16, 2008 by Fröhn

[Crazyace]

That's the problem w/buffered approach is that the delay. The audio/video does not show up as real (in experience) until that delay whereas it shows up as real on the Atari without the delay. You can't state "synced" and "with a constant delay"-- that's not synced. Even audio and video does not remain locked as I have done this already-- play digitized audio at some rate (4Khz...48Khz). You will notice the drifting error in total time to run the sample due to crystal timing issues. For example, Sound Blaster has 1Mhz crystal and to get 11025 Hz playback, your choice for dividers are: 90 or 91 which gives 10989Hz or 11111Hz. On Atari, 11025Hz uses a dividers of 162 or 163 giving 10980 or 11048Hz. The error is greater with lower timing crystal. Now if you have synced up video to this, it will eventually drift. And then add in dynamic effects like echo or something which modifies the waveform and you are in even more trouble with a buffered approach.

 

I think your argument is something different, about real PC audio HW against real Atari audio HW?

I wont comment, as I haven't used anything with a Soundblaster for a long long time - and my motherboard audio seems to be driven from the processor clock ( higher than 1MHz ) so I couldn't comment on how accurate it is - it seems to be 44100 or 48000 as basic sample rates. ( I actually preferred the Gravis Ultrasound over the Sound Blaster when it first came out )

 

For emulation, as Frohn states , the output delays can be matched, and it seems to work ok - normally there are far more problems with video refresh ( specially for 50Hz emulation )

[Fröhn]

The main probem is that the "Atari-waves" are not Square waves as handled in the emulation. The correct terms might be Square- with Sine - Waves.

To me this sounds like the normal the normal ringing effect which occurs when you low-pass filter a square wave:

 

ringing artifacts

 

Since the ideal square wave does not exist outside theory, you will always have ringing when you try to have a square wave in real world.

[supercat]

Since the ideal square wave does not exist outside theory, you will always have ringing when you try to have a square wave in real world.

 

Real-world waves will not be square, but that does not imply the existence of ringing. A square wave which is overdamped or critically damped will not have ringing (for a given amount of bandwidth, one can get 'squarer' waves if ringing is acceptable than if it isn't, but if waves are sufficiently 'rounded' they need not ring at all).

[supercat]

And just like the audio has a delay, the video has a delay too. So the only thing you need to do is to make the delay the same by choosing a suitable sound buffer size.

 

Suppose I have a game where the player is supposed to push a button as soon as the game shows a certain object on the screen or makes a certain noise. Someone who is playing the game on real hardware would likely have about a 1/60 second advantage over someone who is playing on emulation. In some types of 'twitcher' games, a 1/60 difference can have a noticeable effect on gameplay.

[atariksi]

It's not really a simulation if everything is delayed and out of sync with rest of hardware.

Do you realize you can set the audio latency? Want a 60th of a second buffer? You just have to stuff it more often. I don't understand the obsession with timers and whatnot for emulation. If you need cycle-exact everything, there's only so much you can do on non-native hardware, but the PC can emulate every real-time change to the raster and every real-time change to the audio (provided the library supported it) and the results can all be lined up quite accurately. Maybe the IO ports have to be simulated, but I feel like your objective is to somehow declare the Atari to be a superior computer to the PC.

 

Timing plays a role in real-time changes to audio. You can modify audio at a much higher rate than 60Hz. You can stop speculating regarding what I am trying to declare as I am only looking at one hardware aspect here-- timed audio. PC cannot do every real-time change given it's less resolute timers. Unless you have a PC with some higher resolution timers or audio hardware (Non-standard).

The timing on the PC side is rather irrelevant. What is relevant is the latency of the overall audio buffering, i.e. how "short" a sample to be played by the audio hardware can be. This doesn't depend on PC timers at all since the timing isn't driven by the PC timer in first place. It is driven by the emulation speed, and by the ability of the operating system (or its underlying sound system) to provide a latency short enough to ensure that the CPU time in the emulated machine doesn't "lag" too much compared to the PC time. You don't use PC timers to time Atari audio - this is just folly.

 

Interestingly, the Linux "alsa" system seems to be much more capable than windows DirectX sound system, which I found astonishing. Alsa has a latency that is about half as long as the DirectX latency...

 

So long,

Thomas

 

Timing is relevant; with a buffering approach, you are just precalculating timing into the buffer at the cost of introducing delays (latency) which does not exist on Atari. There are two other appraoches-- one of which involves writing to DAC register (exists on SB) where there's zero latency involved by you have to do the timing yourself which would involve the PC timer (@1.19Mhz) (it's not a folly-- it works). And latency is not the only issue with the buffering method-- you still have timing and frequency issues as the Atari DACs can be played at different frequencies. Suppose you have a buffer at 48Khz, if you play 11Khz samples you are distorting samples. If you make rate 44Khz, then 11Khz plays fine but another channels running at 12Khz will distort samples. This is all not mentioning how complex your 60frames/second will become since DACs will need to be updated even while you repaint the screen as you cannot repaint the screen in 1/sampling rate time.

[atariksi]

It does not prove, it's emulating the POKEY if you get it to work with a few samples.

 

Sigh. What's so hard to understand on this simple concept: *If* you think something doesn't work, please provide me with details *what* doesn't work. You stand here claiming that the sound emulation isn't working as it should be, declaring things impossible that might not be quite impossible as you might believe. But anyhow, as I'm a physicist, I believe in evidence by experiment. What's so hard about simply first trying, and then stating what is and what isn't possible. Doesn't that sound fair enough?

 

I'm not trying to *prove* that everything works correctly - simply because I know that there are certainly gaps - but I would believe that it is highly likely that more things are working than you would believe to be working.

 

So long,

Thomas

 

It's okay to experiment, but it's better to know the hardware specs since the hardware restrictions set your upper bound of what you can achieve with your experiment (to what degree the software emulation can be achieved). It's better to know the rational of why NOT to smoke rather than find out by experiment (the hard way). Without ever trying an emulator, I can draw certain conclusions based on the two audio hardwares involved.

[atariksi]

That's the problem w/buffered approach is that the delay. The audio/video does not show up as real (in experience) until that delay whereas it shows up as real on the Atari without the delay. You can't state "synced" and "with a constant delay"-- that's not synced. Even audio and video does not remain locked as I have done this already-- play digitized audio at some rate (4Khz...48Khz). You will notice the drifting error in total time to run the sample due to crystal timing issues. For example, Sound Blaster has 1Mhz crystal and to get 11025 Hz playback, your choice for dividers are: 90 or 91 which gives 10989Hz or 11111Hz. On Atari, 11025Hz uses a dividers of 162 or 163 giving 10980 or 11048Hz. The error is greater with lower timing crystal. Now if you have synced up video to this, it will eventually drift. And then add in dynamic effects like echo or something which modifies the waveform and you are in even more trouble with a buffered approach.

 

I think your argument is something different, about real PC audio HW against real Atari audio HW?

I wont comment, as I haven't used anything with a Soundblaster for a long long time - and my motherboard audio seems to be driven from the processor clock ( higher than 1MHz ) so I couldn't comment on how accurate it is - it seems to be 44100 or 48000 as basic sample rates. ( I actually preferred the Gravis Ultrasound over the Sound Blaster when it first came out )

 

For emulation, as Frohn states , the output delays can be matched, and it seems to work ok - normally there are far more problems with video refresh ( specially for 50Hz emulation )

 

That's still a problem if you have different hardware having different methods of computing sampling rates. I don't think the API lets you get the crystal timing value. I know some sound cards only allowed the 11025, 22050, 44100 rates and newer SB cards were modified to support these Windows standard rates so they are exactly at those rates.

 

Frohn forgot about user input which cannot be buffered as it's reality already.

[Rybags]

The Atari pure tone has been discussed before. The actual waveshape is more like an ADS type effect.

 

I have to clarify here, I'm not slagging off the Pokey emulation - it's a great effort, but I don't agree on it's accuracy. For general gaming it's fine, but when you're developing stuff it's deficiencies especially show.

 

Digital effects is another obvious downfall. You can play samples at practically any speed on a real machine (OK, maybe a practical limit would be 400 KHz or so).

 

In emulation, it especially shows it's weakness if you play samples at anything that's not near an integer divisor of whatever sample speed you have it set to (48, 44.1, 22, 11 etc)

[Allas]

31 - KORONIS RIFT

 

Atari screenshots

 

Impressive work for both versions, the programmers worked with very high details in it. However the Atari graphics is impressive, maybe one of the few games that use all GTIA capabilities. You will need a manual to understand how to play this, not easy or intuitive interface.

 

C64 screenshots

[frogstar_robot]

Interestingly, the Linux "alsa" system seems to be much more capable than windows DirectX sound system, which I found astonishing. Alsa has a latency that is about half as long as the DirectX latency...

 

So long,

Thomas

 

It isn't uncommon for serious Linux audio enthusiasts to use a kernel that has been patched for lower latency and/or some form of "realtime". These enthusiasts also tend to run pro or semi-pro audio cards that can be synced to studio time sources. Though it runs on top of ALSA, most prosumer Linux audio apps also run on top of an audio system called JACK which is intended to keep multiple sources locked to each other within a minimum amount of latency. All of these latency tweaks probably degrade raw i/o throughput to some extent so these systems aren't the best for non-audio non-realtime work.

 

I suppose a hard-core emulator author could exploit this but it seems too little gain for too much pain.

Edited December 17, 2008 by frogstar_robot

[ijor]

...PC timer freq is 1.19318Mhz (standard PCs-- new nonstandard HPET doesn't qualify as most PCs don't have it nor can access it directly via applications),

...

Unless you have a PC with some higher resolution timers or audio hardware (Non-standard).

 

atariksi, where did you get those strange ideas?

 

Almost every new PC do have HPET. For starters, HPET is a mandatory requirement to get a Microsoft Vista Logo. HPET was standard even before Vista. Intel has been shipping HPET in all their chipsets for several years.

 

There are other high resolution PC timers that predate HPET by many years. E.g: you have the ACPI/PM timer, and you have the APIC timer. Lastly, you have the Pentium RDTSC timer, whis is available since too long ago.

 

Of course that high precision timing in the PC have many issues, OS issues being probably the most important ones. But claiming that the only standard PC hardware timer is the 1.193182 MHz PIT, is wrong.

 

or a standard sound blaster which only has a 1Mhz crystal to produce it's sampling rate. Perhaps, you are using non-standard hardware that's better than the standard.

...

For example, Sound Blaster has 1Mhz

 

That doesn't make any sense. Since about a decade, that any audio card has an AC97 interface, or compatible, or similar. AC97 requires a 12.288 MHz (or multiple) clock. There is no way that a modern audio card would be clocked at 1 MHz.

 

Check the oscillators on many audio cards, and on most of them you would find 12.288 MHz, or 24.576 MHz (just the same, but x2), or sometimes 18.432 MHz. And even if it has some other crystal or oscillator, that doesn't mean that is the frequency that is clocking the board. A modern PLL can get any of those frequencies from, say an 1 MHz clock.

 

Now, I do agree that emulation is not perfect. And I also fully agree that there are some hardware limitations that would prevent the "experience" to be identical to the one in real hardware. But the hardware timers have very little (if at all) to do with this.

 

E.g: An USB joystick has a significant latency. The latency is intrinsic to the USB protocol and interface. No hardware timer would help you here.

Edited December 17, 2008 by ijor

[potatohead]

It's not really a simulation if everything is delayed and out of sync with rest of hardware.

Do you realize you can set the audio latency? Want a 60th of a second buffer? You just have to stuff it more often. I don't understand the obsession with timers and whatnot for emulation. If you need cycle-exact everything, there's only so much you can do on non-native hardware, but the PC can emulate every real-time change to the raster and every real-time change to the audio (provided the library supported it) and the results can all be lined up quite accurately. Maybe the IO ports have to be simulated, but I feel like your objective is to somehow declare the Atari to be a superior computer to the PC.

 

Timing plays a role in real-time changes to audio. You can modify audio at a much higher rate than 60Hz. You can stop speculating regarding what I am trying to declare as I am only looking at one hardware aspect here-- timed audio. PC cannot do every real-time change given it's less resolute timers. Unless you have a PC with some higher resolution timers or audio hardware (Non-standard).

 

...or you base the emulation off of one shared clock for all the elements. That leaves only the problems of latency (how fast can the emulation iterate a cycle of that clock), and correlation to real world speeds. And that real world speed is for the WHOLE emulation working off of it's common clock, not just one part here vs another part there. So then, if that is established well within the human tolerances necessary for quality perception, you then have a good quality emulation. It's just that simple really.

 

And to be really clear, that's a software clock, not some hardware timer. Hardware stuff can be used for the correlation, but isn't necessary for cycle perfect emulation. That's possible and only limited by the authors understanding of what the hardware does, not any artifact of the PC it happens to be running on.

Edited December 17, 2008 by potatohead

[ijor]

Interestingly, the Linux "alsa" system seems to be much more capable than windows DirectX sound system, which I found astonishing. Alsa has a latency that is about half as long as the DirectX latency...

 

Thomas,

 

Direct Sound is not really "direct" anymore, since XP. Only on W2K/9X/Me, DirectSound was going (almost) directly to the hardware and then it had low latency. Microsoft, in its infinite wisdom, decided that low latency and low level access is not important anymore. There is not Direct Sound hardware acceleration anymore.

 

There are some other low(er) latency audio interfaces on Windows that replaced Direct Sound, but they are clumsy and rarely used. For example, XP introduced kernel audio streaming.

[frogstar_robot]

There are some other low(er) latency audio interfaces on Windows that replaced Direct Sound, but they are clumsy and rarely used. For example, XP introduced kernel audio streaming.

 

Professional audio work in Windows is usually done with ASIO.

 

http://en.wikipedia.org/wiki/Audio_Stream_Input/Output

 

The basic idea is to bypass as many Windows APIs as possible give applications thin driver that gives very low level access to the sound card. This thin driver still presents a consistent interface but pretty much only pro sound apps use it as it throws out the standard Windows sound APIs. Incidentally, I imagine modern pro audio cards have hi-res timers in them and the ability to sync from studio time sources besides.

[peteym5]

For Jungle Hunt....

 

Gotta say - both versions look like they were programmed by someone with bad colour-blindness.

 

So many Atari games were let down by something as simple as piss-poor colour choices.

 

Love that comment, some games have that issue where someone made poor color choices and wonder if their monitor or TVs color was messed up. Perhaps maybe they were programming on a monochrome monitor or B/W tv.

 

I noticed people debating the issue which computer has better colors and that is a vague issue because it comes down how someone utilizes the available colors in their game in either machine.

[athleos]

WOW. so. which is better?

[Crazyace]

The Atari pure tone has been discussed before. The actual waveshape is more like an ADS type effect.

 

I have to clarify here, I'm not slagging off the Pokey emulation - it's a great effort, but I don't agree on it's accuracy. For general gaming it's fine, but when you're developing stuff it's deficiencies especially show.

 

Digital effects is another obvious downfall. You can play samples at practically any speed on a real machine (OK, maybe a practical limit would be 400 KHz or so).

 

In emulation, it especially shows it's weakness if you play samples at anything that's not near an integer divisor of whatever sample speed you have it set to (48, 44.1, 22, 11 etc)

 

I think it would be trivial ( in terms of coding ) to increase the percieved pokey rate to the 400khz range - and support much more esoteric uses - but I guess it's only going to happen if there are titles that require it ( ie they sound terrible without it ) , as you said the current emulation works well for most games.

[Rybags]

Even though the Atari can in theory generate a ~ 900 KHz sound, you can't play it back anyway.

 

Speaker response is nowhere near good enough. And, imagine how fast the cone would have to travel?

 

Take an example where the speaker might move 1 mm from peak to peak of a waveform. 800 KHz means it would have to travel 1.6 Km (a mile) per second if it was accurately producing that sound. In fact, it would be supersonic velocity, so maybe you'd get a mini sonic boom across your desktop.

[Crazyace]

Even though the Atari can in theory generate a ~ 900 KHz sound, you can't play it back anyway.

 

Speaker response is nowhere near good enough. And, imagine how fast the cone would have to travel?

 

Take an example where the speaker might move 1 mm from peak to peak of a waveform. 800 KHz means it would have to travel 1.6 Km (a mile) per second if it was accurately producing that sound. In fact, it would be supersonic velocity, so maybe you'd get a mini sonic boom across your desktop.

 

Cool , as Atariski would say , that's something else you could only do on an Atari