Pokey sound emulation code ?

[andym00]

I thought I'd ask here, since the 8bit forums seem mostly frequented by tumble-weed

 

Is there a Pokey emulation libary or source code available that's considered the best, or in fact absolutely bang on cycle accurate ?

 

I'm just looking for something that I can hook up it to a sound editing tool that's running a 6502 emulator with some sound drivers, and get as close as possible emulation of what I'd get on the real thing ?

 

Does such a thing exist ? If so, which is the best ?

[thorfdbg]

I thought I'd ask here, since the 8bit forums seem mostly frequented by tumble-weed

 

Is there a Pokey emulation libary or source code available that's considered the best, or in fact absolutely bang on cycle accurate ?

 

I'm just looking for something that I can hook up it to a sound editing tool that's running a 6502 emulator with some sound drivers, and get as close as possible emulation of what I'd get on the real thing ?

 

Does such a thing exist ? If so, which is the best ?

What is "cycle accuracy" for you? The problem is that for sound emulation you usually have the problem that the emulation procedure is not in agreement with the frequency of the sound output. Thus, what you usually want is a pokey emulation that can create the sound output for the next "N" cycles of the machine, filling an output buffer of "M" bytes, where on the real machine "N" and "M" would be identical, but due to emulation are not.

 

If that is your concern, the atari++ pokey implementation is fairly good, I believe. What is not supported is the sound modulation

due to SIO activity. The SIO base frequency is, however, included.

 

So long,

Thomas

[pseudografx]

I thought I'd ask here, since the 8bit forums seem mostly frequented by tumble-weed

 

Is there a Pokey emulation libary or source code available that's considered the best, or in fact absolutely bang on cycle accurate ?

 

I'm just looking for something that I can hook up it to a sound editing tool that's running a 6502 emulator with some sound drivers, and get as close as possible emulation of what I'd get on the real thing ?

 

Does such a thing exist ? If so, which is the best ?

ASAP is the closest to the real thing though it cannot handle emkay's and analmuxes experiments properly :-P

see asap.sourceforge.net

[andym00]

I thought I'd ask here, since the 8bit forums seem mostly frequented by tumble-weed

 

Is there a Pokey emulation libary or source code available that's considered the best, or in fact absolutely bang on cycle accurate ?

 

I'm just looking for something that I can hook up it to a sound editing tool that's running a 6502 emulator with some sound drivers, and get as close as possible emulation of what I'd get on the real thing ?

 

Does such a thing exist ? If so, which is the best ?

What is "cycle accuracy" for you? The problem is that for sound emulation you usually have the problem that the emulation procedure is not in agreement with the frequency of the sound output. Thus, what you usually want is a pokey emulation that can create the sound output for the next "N" cycles of the machine, filling an output buffer of "M" bytes, where on the real machine "N" and "M" would be identical, but due to emulation are not.

 

If that is your concern, the atari++ pokey implementation is fairly good, I believe. What is not supported is the sound modulation

due to SIO activity. The SIO base frequency is, however, included.

 

So long,

Thomas

 

That's not an issue for what I want.. I'm not interested in generating a screen at all.. All I want to do is running a raw 6502 emulation in a bare 64K address space with a Pokey mapped in there.. Since I'm not generating a screen, I'll using the audio output to clock directly..

 

If Pokey is actually clocked at 1.79Mhz then I'm quite happy to run one cycle of CPU, then one cycle of Pokey then I'll sample it at that rate and downsample for the output.. It's just the sound I'm after nothing else.. Whatever method it uses I'm quite happy with, as long as I can ask it to emulate for X cycles on it's own..

 

The idea is I want to write a PC hosted sound effects editor, so I want to put together a little black box consisting of 6502 & Pokey, with the 6502 running the sfx code driving pokey and the PC tool allowing my some nice editing environment.. That's all

 

I'll go give that a go then.. Thanks

 

edit: I did exactly the same thing on the 2600 for writing some sound stuff on the TIA when I wanted good a reproduction as possible, without emulator foibles and frame rate issues..

Edited September 15, 2009 by andym00

[andym00]

ASAP is the closest to the real thing though it cannot handle emkay's and analmuxes experiments properly :-P

see asap.sourceforge.net

 

Ah, didn't realise that was what RMT used.. I'll give that a go then as well..

[analmux]

That's not an issue for what I want.. I'm not interested in generating a screen at all.. All I want to do is running a raw 6502 emulation in a bare 64K address space with a Pokey mapped in there.. Since I'm not generating a screen, I'll using the audio output to clock directly..

Well, sorry, I don't want to throw salt in your coffee, but handling of Pokey depends on DMA schemes.

 

It's possible to reset the random patterns (and all other polycounter schemes) to an exact cycle. This means, we have control of when the pattern starts. But, the effect of the resetting code depends on if it's executed during 20 or 30 cycles. The 30 cycle case is f.e. when screen DMA is turned on. Also don't forget the DRAM refresh cycles etc.

 

So, when you're planning real cycle critical stuff, you'd have to take DMA cycle stealing into account.

 

I recommend you to look for someone here on the forum who has a real machine, if he/she can do the tests for you.

[andym00]

Well, sorry, I don't want to throw salt in your coffee, but handling of Pokey depends on DMA schemes.

 

It's possible to reset the random patterns (and all other polycounter schemes) to an exact cycle. This means, we have control of when the pattern starts. But, the effect of the resetting code depends on if it's executed during 20 or 30 cycles. The 30 cycle case is f.e. when screen DMA is turned on. Also don't forget the DRAM refresh cycles etc.

 

So, when you're planning real cycle critical stuff, you'd have to take DMA cycle stealing into account.

 

I recommend you to look for someone here on the forum who has a real machine, if he/she can do the tests for you.

 

No worries, I can stand a bit of salt in my coffee

 

I wasn't planning on going that far, maybe in the future, but certainly not right now.. I just want a nice editing tool and environment to play with on the PC to develop a nice multi-rate SFX driver, but with a nice front end to work with, and as close as possible emulation of the audio.. I mean I've already got all code I need to build such stuff from many previous creations, and I'd much rather build an editor on the PC rather than build a whole editing environment on natively on the A8..

 

But either way, I don't see that adding refresh cycles and 'pseudo' dma accesses to it would be such a big job if I went that route either..

 

I'm not interested in music just yet, that comes later, for now just SFX

 

edit: And I've got a 65XE now plus an 800XL but just need to sit down and finally go through all the PC connectivity options and then I can finally start to test on the real thing.. Very soon

Edited September 15, 2009 by andym00

[thorfdbg]

That's not an issue for what I want.. I'm not interested in generating a screen at all.. All I want to do is running a raw 6502 emulation in a bare 64K address space with a Pokey mapped in there.. Since I'm not generating a screen, I'll using the audio output to clock directly..

 

If Pokey is actually clocked at 1.79Mhz then I'm quite happy to run one cycle of CPU, then one cycle of Pokey then I'll sample it at that rate and downsample for the output.. It's just the sound I'm after nothing else.. Whatever method it uses I'm quite happy with, as long as I can ask it to emulate for X cycles on it's own..

 

The idea is I want to write a PC hosted sound effects editor, so I want to put together a little black box consisting of 6502 & Pokey, with the 6502 running the sfx code driving pokey and the PC tool allowing my some nice editing environment.. That's all

 

I'll go give that a go then.. Thanks

 

edit: I did exactly the same thing on the 2600 for writing some sound stuff on the TIA when I wanted good a reproduction as possible, without emulator foibles and frame rate issues..

You probably don't understand. The problem is *not* the screen. The problem is running the emulated CPU (somehow you must feed Pokey, right?) at *exactly* the clock rate as in the real Atari to have a CPU-cycle to sound-cycle relation. Of course, you cannot. There will always be glitches, Linux and windows are multitasking operating systems. This means that you have sometimes more and sometimes less time available for your emulation. However, the sound output of the host operating system will *always* run on a precise frequency, namely the sample rate of the audio output. You somehow need to compensate for these differences. The difference of the speed of an emulated CPU to the speed of the sound output.

 

So long,

Thomas

[PeteD]

The actual host machine interrupting the emulation isn't the problem either, as long as the buffer is filled in time to be sent to the sound card it makes no difference, you don't "stream" your emulation sound to the soundcard in realtime. All cycle exact stuff is done internally to the emulation, so it is the screen dma, the other interrupts, dma of any other type "internal" to the emulation where the cycle exact nature would be important. So, no emulation/host compensation is needed.

 

 

Pete

[andym00]

You probably don't understand. The problem is *not* the screen. The problem is running the emulated CPU (somehow you must feed Pokey, right?) at *exactly* the clock rate as in the real Atari to have a CPU-cycle to sound-cycle relation. Of course, you cannot. There will always be glitches, Linux and windows are multitasking operating systems. This means that you have sometimes more and sometimes less time available for your emulation. However, the sound output of the host operating system will *always* run on a precise frequency, namely the sample rate of the audio output. You somehow need to compensate for these differences. The difference of the speed of an emulated CPU to the speed of the sound output.

 

I love the day starting off being accused of not understanding something..

 

Lets just leave the OS out of the equation, they have absolutely no bearing in the situation at all..

 

There won't be glitches, there won't be any problem with more or less time..

All there is a large polyphase filter bank which is doing the downsampling from 1.79Mhz to 48Khz (or in fact any sample rate I choose), nothing more nothing less..

 

So with a core generation loop that looks like this:

Emulate one 6502 cycle

Emulate one pokey cycle

Stuff into audio buffer

Please explain why I can't can't have the exact cycle to cycle relationship ? I'm only interested in Pal, so the other clocking modes are exact ratios of the base clock frequency, and I'd hope the Pokey emulation (I've not had time to look properly yet) would take care of this internally..

 

So assuming Pokey and CPU share same clock, then there's no problem right ? So we can forget about that whole issue.. So there's no problem then is there..

 

The emulation is driven from the sound output code[1], so as the audio output needs more samples, we emulate more cycles..

 

It's not rocket science..

 

[1] Well not directly.. The audio generation sits in another thread from the DirectSound/ASIO/KS output code since we want as low latency as possible ~10-20ms, so it just reads from a ring buffer and signals an event from the realtime priority audio thread that handles the audio provider, which is picked up instantly (due to thread priorities) by the emulation thread which has an above_normal thread priority and is invoked immediately after the audio stuffing thread relinquishes control, and does the emulation and polyphase resampling for as many samples as we can into a ring buffer the direct sound stuffer thread actually uses..

Edited September 16, 2009 by andym00

[Rybags]

I don't see a problem with DMA.

 

Of course, if you're talking digitized sound, then you'll have issues.

 

If you're talking generic Pokey chiptune stuff, and you're not fussed about stuff like Distortion "C" producing different sounds for certain Freq values dependant on the Poly cycle, then it's a non-issue.

 

One thing you don't get though is the effect the external circuitry has on the resultant sounds. I sampled at the Pokey pin with an oscilloscope and you get true square waves, but in real life through the sound circuitry we actually get a "squashed" square with a kind of attack/decay of the level.

 

The other issue is that I don't know if any existing emulation handles the interaction of 1.79 Mhz waveforms properly.

[andym00]

The actual host machine interrupting the emulation isn't the problem either, as long as the buffer is filled in time to be sent to the sound card it makes no difference, you don't "stream" your emulation sound to the soundcard in realtime. All cycle exact stuff is done internally to the emulation, so it is the screen dma, the other interrupts, dma of any other type "internal" to the emulation where the cycle exact nature would be important. So, no emulation/host compensation is needed.

 

Much better put than my waffling coffee and nicotine deprived post

[PeteD]

I don't see a problem with DMA.

 

Of course, if you're talking digitized sound, then you'll have issues.

 

If you're talking generic Pokey chiptune stuff, and you're not fussed about stuff like Distortion "C" producing different sounds for certain Freq values dependant on the Poly cycle, then it's a non-issue.

 

One thing you don't get though is the effect the external circuitry has on the resultant sounds. I sampled at the Pokey pin with an oscilloscope and you get true square waves, but in real life through the sound circuitry we actually get a "squashed" square with a kind of attack/decay of the level.

 

The other issue is that I don't know if any existing emulation handles the interaction of 1.79 Mhz waveforms properly.

 

DMA and other "interrupting" processes will only make a difference if timing of when POKEY registers are changed makes any difference to the sound output. I know it does on SID because I've written a 6502+SID emu and it's surprising just what difference it does make. I don't think on POKEY it will be as drastic.

 

It'd be great to get you POKEY "fiddlers" talking together with the emu coders to get POKEY sounds/timers etc emulated properly because it does seem to be one of the more lacking areas of the emulation and you guys seem to have more info about it all than they do.

 

 

Pete

Edited September 16, 2009 by PeteD

[andym00]

I don't see a problem with DMA.

 

Of course, if you're talking digitized sound, then you'll have issues.

 

If you're talking generic Pokey chiptune stuff, and you're not fussed about stuff like Distortion "C" producing different sounds for certain Freq values dependant on the Poly cycle, then it's a non-issue.

 

One thing you don't get though is the effect the external circuitry has on the resultant sounds. I sampled at the Pokey pin with an oscilloscope and you get true square waves, but in real life through the sound circuitry we actually get a "squashed" square with a kind of attack/decay of the level.

 

The other issue is that I don't know if any existing emulation handles the interaction of 1.79 Mhz waveforms properly.

 

For a first pass I just want the basics of Pokey working so I can get a feel for it in it's basic form and cook up some nice sound effects player.. For that I'll skip the refresh and DMA emulation..

 

But later on no doubt I will want to experiment with the slightly more esoteric side of Pokey, and will for sure put those in.. I don't see it being a particularly big job either, but it's not on the list of priorities right now, and by the looks of it the emulations of Pokey at the moment aren't really up to the job anyway..

Edited September 16, 2009 by andym00

[andym00]

It'd be great to get you POKEY "fiddlers" talking together with the emu coders to get POKEY sounds/timers etc emulated properly because it does seem to be one of the more lacking areas of the emulation and you guys seem to have more info about it all than they do.

 

Pokey needs its very own Antti Lankila

Edited September 16, 2009 by andym00

[thorfdbg]

Lets just leave the OS out of the equation, they have absolutely no bearing in the situation at all..

 

There won't be glitches, there won't be any problem with more or less time..

All there is a large polyphase filter bank which is doing the downsampling from 1.79Mhz to 48Khz (or in fact any sample rate I choose), nothing more nothing less..

 

So with a core generation loop that looks like this:

Emulate one 6502 cycle

Emulate one pokey cycle

Stuff into audio buffer

Please explain why I can't can't have the exact cycle to cycle relationship ? I'm only interested in Pal, so the other clocking modes are exact ratios of the base clock frequency, and I'd hope the Pokey emulation (I've not had time to look properly yet) would take care of this internally..

 

So assuming Pokey and CPU share same clock, then there's no problem right ? So we can forget about that whole issue.. So there's no problem then is there..

 

The emulation is driven from the sound output code[1], so as the audio output needs more samples, we emulate more cycles..

 

It's not rocket science..

Well, the 6502 clock speed itself isn't yet a good basis for the sampling frequency, obviously, so you still have an N:M scheme, i.e. generate one sample per N clock cycles. But otherwise, an "offline sound rendering" that doesn't require real-time features would be sufficient.

 

So long,

Thomas

[andym00]

Well, the 6502 clock speed itself isn't yet a good basis for the sampling frequency, obviously, so you still have an N:M scheme, i.e. generate one sample per N clock cycles. But otherwise, an "offline sound rendering" that doesn't require real-time features would be sufficient.

 

So the sample ratio isn't ideal.. Why do I need to worry about that ?

 

I just new up a filter bank, tell it it's input is 1.79Mhz, its output is 48Khz and bobs your uncle, job done.. No more worrying, and it's as good a you will ever want it to be.. In my opinion much better to start with the right solution than some half-cocked solution that might work..

 

I'm not programming it for a P300 or something, and doing it this way makes only a slight dent on my Quad Core i7, so why shouldn't I just use the code that I have already rather than re-inventing the wheel when it's totally unnecessary, and just get it right first time.. It's a tool to achieve a task, not a whole project in it's own right..

 

Off-line rendering isn't an option.. It's for a tool to allow me to interactively edit sounds, as I mentioned earlier.. Pressing play to hear my noises isn't acceptable.. It must run continously as I play around with all my gadgets and gizmos on the screen

Edited September 16, 2009 by andym00

[Rybags]

The way I see it, if you're tying together a 6502 and Pokey emulator, modifying it to emulate various DMA cycle-loss scenarios would be a simple obstacle to overcome.

 

It's not as if you need to cater for every possibility, because it adds up to millions. Just something like a simple Antic "simulator" tacked on would do it. Then just have an array of 312x114 or whatever bitflags which can be preset according to various screen setups. You could even simulate various VBlank and DLI NMI overheads.

[PeteD]

The way I see it, if you're tying together a 6502 and Pokey emulator, modifying it to emulate various DMA cycle-loss scenarios would be a simple obstacle to overcome.

 

It's not as if you need to cater for every possibility, because it adds up to millions. Just something like a simple Antic "simulator" tacked on would do it. Then just have an array of 312x114 or whatever bitflags which can be preset according to various screen setups. You could even simulate various VBlank and DLI NMI overheads.

 

Yeah, that's the direction I was heading in with my SID emu. Basic stuff like Badlines etc. Unless you want to end up writing a full A8 emulator more than the basics aren't needed but using a sensible method in the 1st place means if you did want more accuracy bolting it on later is easy.

 

 

Pete

[andym00]

The way I see it, if you're tying together a 6502 and Pokey emulator, modifying it to emulate various DMA cycle-loss scenarios would be a simple obstacle to overcome.

 

It's not as if you need to cater for every possibility, because it adds up to millions. Just something like a simple Antic "simulator" tacked on would do it. Then just have an array of 312x114 or whatever bitflags which can be preset according to various screen setups. You could even simulate various VBlank and DLI NMI overheads.

 

That's exactly the way I had in mind of doing it, when/if it comes to needing to implement it and go that far.. But for now it's not necessary.. But I must admit I had forgotten about the DLI overheads though

[thorfdbg]

Off-line rendering isn't an option.. It's for a tool to allow me to interactively edit sounds, as I mentioned earlier.. Pressing play to hear my noises isn't acceptable.. It must run continously as I play around with all my gadgets and gizmos on the screen

Then you have again the problem I mentioned earlier. Just to say that again:

 

*Emulated clock time is unequal to real physical time*

 

That is, while your emulation spends the time to emulate one clock of the CPU and of POKEY, an unknown amount of physical time have passed.

 

Or, to make it more concrete:

 

In a real Atari, it takes 1.79 million cycles to generate sound for one second (on a PAL system, roughly). This is because the base frequency is 1.79 Mhz.

In an emulated environment, it also takes 1.79 emulated cycles to generate sound for one second of real sound (because you want to keep this relation). While it takes also exactly one second to play that sound, namely all the samples generated for that second, it will *not* take one second (as in the real hardware) to compute all those samples. So what do you do in the remaining time? And what do you do if the "real time" on-line physical user changes the sound parameters for

sounds that are to be played half a second later?

 

*This* is the fundamental problem of emulation. Emulator time will *never* be in precise agreement to physical time. You need to make compromises.

 

For example, one compromise would be to generate the sound for ~25msecs, and fill a buffer with that. This will hopefully take *less* than 25 msecs on a modern hardware. Then play the sound, and pause the emulation until emulated time and physical time are again in agreement. Problem is that the sound will always lag behind the "physical" user control in front of the emulator by 25msecs (approximately), though from "within the emulated machine", CPU cycles and POKEY cycles are in perfect agreement.

 

Of course, you can make that timespan shorter (and the buffer smaller), then risk buffer underruns, increasing the overhead spend in the Os by waiting for shorter and shorter time spans.

 

In either case, you get not 100% accuracy, unless you render off-line (thus do not care about the physical time required to generate the samples).

 

Atari++, for example, uses a hybrid strategy. It generates new samples whenever the sound parameters change, and it also generates samples on the VBI whenever the emuluation pauses, but the buffer runs empty. In then has a complicated control loop that adjusts the amount of samples to be created per VBI. Not easy.

A shorter synchronization (say, on a horizontal blank basis) might be feasible with today's hardware, but even with the current scheme, Windooze DirectX has sometimes problems to keep up the pace by which buffers are filled and played. Interestingly, ALSA on Linux is considerably less critical.

 

So long,

Thomas

[andym00]

Then you have again the problem I mentioned earlier. Just to say that again:

 

*Emulated clock time is unequal to real physical time*

 

That is, while your emulation spends the time to emulate one clock of the CPU and of POKEY, an unknown amount of physical time have passed.

 

Or, to make it more concrete:

 

In a real Atari, it takes 1.79 million cycles to generate sound for one second (on a PAL system, roughly). This is because the base frequency is 1.79 Mhz.

In an emulated environment, it also takes 1.79 emulated cycles to generate sound for one second of real sound (because you want to keep this relation). While it takes also exactly one second to play that sound, namely all the samples generated for that second, it will *not* take one second (as in the real hardware) to compute all those samples. So what do you do in the remaining time? And what do you do if the "real time" on-line physical user changes the sound parameters for

sounds that are to be played half a second later?

 

*This* is the fundamental problem of emulation. Emulator time will *never* be in precise agreement to physical time. You need to make compromises.

 

For example, one compromise would be to generate the sound for ~25msecs, and fill a buffer with that. This will hopefully take *less* than 25 msecs on a modern hardware. Then play the sound, and pause the emulation until emulated time and physical time are again in agreement. Problem is that the sound will always lag behind the "physical" user control in front of the emulator by 25msecs (approximately), though from "within the emulated machine", CPU cycles and POKEY cycles are in perfect agreement.

 

Of course, you can make that timespan shorter (and the buffer smaller), then risk buffer underruns, increasing the overhead spend in the Os by waiting for shorter and shorter time spans.

 

In either case, you get not 100% accuracy, unless you render off-line (thus do not care about the physical time required to generate the samples).

 

Atari++, for example, uses a hybrid strategy. It generates new samples whenever the sound parameters change, and it also generates samples on the VBI whenever the emuluation pauses, but the buffer runs empty. In then has a complicated control loop that adjusts the amount of samples to be created per VBI. Not easy.

A shorter synchronization (say, on a horizontal blank basis) might be feasible with today's hardware, but even with the current scheme, Windooze DirectX has sometimes problems to keep up the pace by which buffers are filled and played. Interestingly, ALSA on Linux is considerably less critical.

 

So long,

Thomas

 

Clearly there's an agenda here with the Windows comments and lifes too short to play those games.. As long as the playback meets my requirements that's all that matters.. Currently it's playing, right this second, and it's outputting via ASIO @96Khz (set to 256 sized buffers), and the reported latency is 6ms, and I've not even twiddled to see how low it can go, that's settings that just work for everything I run on a day to day basis..

 

I don't care about how the emulators do the damn thing because they're trying to keep everything in sync with the frame rate which is an ungodly job.. I'm not trying to do that.. I don't care what's being displayed, in fact there is no display what so ever, and there never will be.. Just a virtual black box consisting of a Pokey, a 6502 and a memory chip that ticks along at 1.79Mhz.. Synced to nothing but my demands for samples and a dirty great Polyphase filter doing the resampling..

 

When I change numbers on my tool, I'm, changing numbers in the memory which my 6502 driver is doing things with.. I think you've missed the point entirely here completely..

 

The latency is utterly utterly utterly irrelevant in this context.. The audio driver itself is running at only 200hz, so there's a chuffing big latency there already between me sticking numbers into memory and the driver acting upon them.. And even if I cranked that right up, it'd still make bugger all difference to the end result..

Edited September 16, 2009 by andym00

[PeteD]

*Emulated clock time is unequal to real physical time*

 

True BUT it's still all internal to the emulation. That's the idea of emulation, to emulate the whole. The only thing sound has to do with anything external to the emulation is when and how its heard ie sent to the PC sound output. It's basically the same as doing it offline BUT your emulation is fast enough (at least on modern hardware) that the "offline" time to generate say 50th/second is actually less than 50th/second on the host cpu. One has nothing to do with the other unless the emulation takes too long and then technically the emulation is still accurate, just what you're hearing isn't. An unknown amount of physical time may have passed but that doesn't matter because it's still made that sound buffer in time.

 

Trust me, I've written sound emulation stuff that runs a 6502 and a reasonable SID emulation in 16mhz so it's VERY possible on modern hardware to do it cycle exact.

 

If that's all you're saying, that there CAN be problems syncing the emulation output to the host machine then I think you're just telling us stuff we already know and it's a non issue if you write your code properly

 

 

Pete

Edited September 16, 2009 by PeteD

[thorfdbg]

Clearly there's an agenda here with the Windows comments and lifes too short to play those games.. As long as the playback meets my requirements that's all that matters.. Currently it's playing, right this second, and it's outputting via ASIO @96Khz (set to 256 sized buffers), and the reported latency is 6ms, and I've not even twiddled to see how low it can go, that's settings that just work for everything I run on a day to day basis..

 

I don't care about how the emulators do the damn thing because they're trying to keep everything in sync with the frame rate which is an ungodly job.. I'm not trying to do that.. I don't care what's being displayed, in fact there is no display what so ever, and there never will be.. Just a virtual black box consisting of a Pokey, a 6502 and a memory chip that ticks along at 1.79Mhz.. Synced to nothing but my demands for samples and a dirty great Polyphase filter doing the resampling..

 

When I change numbers on my tool, I'm, changing numbers in the memory which my 6502 driver is doing things with.. I think you've missed the point entirely here completely..

 

The latency is utterly utterly utterly irrelevant in this context.. The audio driver itself is running at only 200hz, so there's a chuffing big latency there already between me sticking numbers into memory and the driver acting upon them.. And even if I cranked that right up, it'd still make bugger all difference to the end result..

 

Then, my question is, what do you mean by "cycle precise". You can clearly write an emulation that creates the *correct* pokey output for the given pokey settings. Correct here means: It is in 100% agreement to what a real pokey would generate if registers would be in the same settings. Atari++ has such a routine, except that the impact of the serial shift register is not emulated (I haven't seen it used for audio purposes, but it could).

 

*However* trouble is in sight if you change those registers since, apparently, it matters *when* such modifications happen. As long as such modifications are purely algorithmic, i.e. driven by the CPU only without user interaction, no trouble, as you can keep the emulated CPU and the emulated pokey in sync, and just drive both (CPU and POKEY) by the requirements of the sound/audio output.

 

As soon as you modify the pokey settings as a reaction from some external event, you need to take care of the latency, i.e. the emulation will not be in 100% agreement to what would happen on a real Atari: As soon as the event reaches the emulation, quite some samples are already in the audio output buffer, and thus you cannot react immediately. Thus, it is in this sense not "precise".

 

Whether this matters for you I don't know, but it is unavoidable.

 

So long,

Thomas

[PeteD]

True, but that's what we've been saying all along, it's latency and with modern machines is perceptually unnoticeable so taking what Andy is doing to the extreme the core emulation can be cycle exact and produce cycle exact sound but may not interact with external events to a cycle exact nature but then what events would you want? It would take longer for your brain to tell your finger to press a key, your arm/hand/finger to move, press that key down, the signal to go from the key.... etc than the perceptual time difference between doing that on a real machine and an emulation.

 

 

Pete