89 replies to this topic

[Sheddy]

Wow! This is giving amazing results. Excellent stuff Andy. Still not really understanding PWM though. Hard to believe so few IRQs are needed.

Anyone want to have a go at explaining in fairly simple terms? (looked at Wikipedia a while back and thought. Er, what?!) Not looked at the code either yet.

Please correct as necessary! There is a very high frequency tone played, that is too high to hear. At very specific points in time the tone is stopped for a very short time, reducing the average volume for that part of the waveform? Ear only hears average volume.
So, if the frequency is so high, how can you make sure what the exact volume at any point in the wave is if you only have control at wavelength resolution?  is it enough just to be on or off?
Thanks!

[andym00]

Ah, the PWM thing was in reference to some effects that can be used to push the type of sounds beyond plain square waves.. It's simply play this all back as plain 4bit samples at 15.6KHz, although with the interrupts reduced enormously, but still leaving that 15.6KHz timing precision for when it's actually needed..
This isn't playing back using any PWM methods for the sample data itself.. An earlier version did use Phaerons DAC method which had PWM as part of its design, but I stopped using that because a) it eats the entire POKEY resources b) I couldn't see how I could control the rate as simply, although I didn't put much effort into understanding what he'd done to the poor POKEY to get that method working.. The desire for it to be usable over a 4bit DAC, hence a lot of other machines being able to use this, thankfully kept me from pursuing that avenue

The PWM effects I meant were along the lines of because we are in control of generating each single cycle of the waveform, indeed that's the guts of it in that it just generates the transitions between the hi/lo parts at the right time, with pulse width control, that the codes in the position of being able to take a new frequency and pulse width value (well actually it's two frequency values, which describe the pulse width, although it can be stored as only the PW, and then the correct two F values determined) after each pair of transition value are generated, so with we can create for each voice a pulse width modulated stream of data, along with being able to change the frequency as well.. The high pitched carrier in the case doing it like this is in fact fundamental frequency of the note we want to play, so we want it audible otherwise we might as well pack out bags and go home

I've a newer version coming that has more speedups, and also pre-caches the Nintendo APU registers since the amount of time the NSF player is taking is mental.. It means a little pause at startup, but there's enough working still being down with all the registers changes, and frequency and duty calcs, and also the register unpacking, to be representative of what is expected of a decent music driver, well one that I'd write anyway

And for the record, the reason why the CPU time seem to spike alternately, is simply because it builds in 256 sample chunks, so it tends to cycle between building one buffer being built during the screen period, with more DMA, and the next during the screen off period, roughly.. The VBXE versions display the true nature of the beast

[Heaven/TQA]

can someone post MP3s? because Atari800MacX doesn't like this code...

Andy, have you realised that noone mentioned... you are from the evil side?

[andym00]

Emkay did mention it right at the start, but soon decided to forget

[andym00]

Here's the latest effort.. Caches the NES APU output, but the amount of time still spent processing during playback is representative of a decent music driver.. It still has to translate all the registers and the horrendous frequency calculations, balance the levels etc.. And there's still a lot of crap code in that part, but it's staying for now because it does the job, and simulates a reasonable amount of time that would be taken with music playing tasks..

There's ANTIC & VBXE versions in there, each with an IRQ stabilised version, and an unstabilised one too.. Just so you can hear the difference..

Attached Files

•  megavania.zip   42.75K   62 downloads
•  pac-follin.zip   34.79K   58 downloads
•  my_first_tim_follin_cover.zip   36.97K   59 downloads

[andym00]

And since the APU cache can now use multiple banks to store the APU registers, it means the longer tunes now work

Attached Files

•  silver_surfer__level_1.zip   40.62K   53 downloads
•  target_renegayde.zip   40.63K   51 downloads

[andym00]

And one more, featuring Pokey trying to be Keith Moon Or something...

Attached Files

•  meckzjoinskonami.zip   21.13K   57 downloads

[Bryan]

Sheddy, on Wed Feb 29, 2012 3:34 AM, said:

Wow! This is giving amazing results. Excellent stuff Andy. Still not really understanding PWM though. Hard to believe so few IRQs are needed.

Anyone want to have a go at explaining in fairly simple terms? (looked at Wikipedia a while back and thought. Er, what?!) Not looked at the code either yet.

An explanation of PWM? It works like this:

When a frequency is too high to pass through a circuit (such as a low-pass filter), what you get is the average level instead of the rapid changes in level. Of course, unless your filter is perfect, you'll get some of the original frequency, but it collapses to the average level as the filter improves or the frequency goes up. So, this means we can make a DAC using just a square wave and a filter. If the square wave oscillates between 0V and 5V with a 50/50 duty cycle, we get 2.5V out of the filter/averager.  If we change to a 25% low/75% high square, we'll get  3.75V out. And if we flip that wave (75% low/25% high), we'll get 1.25V out. So, it's the width of your pulse that determines voltage, and you can make various analog levels using a single digital output.

[andym00]

And a little test mixing DLIs into the fray.. Works as imagined..
VBL is getting knocked for six sometime due to the buffer building IRQ happening inside the IRQ, but that all needs revisiting and the whole buffer building moving to the main loop, although synchronisation becomes a pain then.. Has to be done though, and will save some precious cycles inside the interrupts to allow better mixing of DLIs and IRQs..
It's not fine tuned cycle wise at all, just a test of the irq interrupted by DLI, interrupted by IRQ idea.. And it works
It doesn't have stable playback with this setup, it's going to be impossible, I think, but the jitter is minimised although needs tuning to each environment really..

Attached Files

•  mixed with DLIs.zip   9.3K   61 downloads

[Sheddy]

andym00, on Wed Feb 29, 2012 4:01 AM, said:

Ah, the PWM thing was in reference to some effects that can be used to push the type of sounds beyond plain square waves.. It's simply play this all back as plain 4bit samples at 15.6KHz, although with the interrupts reduced enormously, but still leaving that 15.6KHz timing precision for when it's actually needed..
This isn't playing back using any PWM methods for the sample data itself.. An earlier version did use Phaerons DAC method which had PWM as part of its design, but I stopped using that because a) it eats the entire POKEY resources b) I couldn't see how I could control the rate as simply, although I didn't put much effort into understanding what he'd done to the poor POKEY to get that method working.. The desire for it to be usable over a 4bit DAC, hence a lot of other machines being able to use this, thankfully kept me from pursuing that avenue

Ah, that'll teach me to skim. That must be a neat trick being able to reduce the interrupts that much without too much overhead - Will be checking it out in more detail later. Thanks

Bryan, on Wed Feb 29, 2012 9:28 AM, said:

Sheddy, on Wed Feb 29, 2012 3:34 AM, said:

Wow! This is giving amazing results. Excellent stuff Andy. Still not really understanding PWM though. Hard to believe so few IRQs are needed.

Anyone want to have a go at explaining in fairly simple terms? (looked at Wikipedia a while back and thought. Er, what?!) Not looked at the code either yet.

An explanation of PWM? It works like this:

When a frequency is too high to pass through a circuit (such as a low-pass filter), what you get is the average level instead of the rapid changes in level. Of course, unless your filter is perfect, you'll get some of the original frequency, but it collapses to the average level as the filter improves or the frequency goes up. So, this means we can make a DAC using just a square wave and a filter. If the square wave oscillates between 0V and 5V with a 50/50 duty cycle, we get 2.5V out of the filter/averager.  If we change to a 25% low/75% high square, we'll get  3.75V out. And if we flip that wave (75% low/25% high), we'll get 1.25V out. So, it's the width of your pulse that determines voltage, and you can make various analog levels using a single digital output.

Thanks for the explanation Bryan   Kinda good to know I was only partially confused (although, as they say, "a little knowledge is a dangerous thing" )

Edited by Sheddy, Wed Feb 29, 2012 1:03 PM.

[Heaven/TQA]

just had a listen to the files. sound good. and the DLI stuff is impressive, too.

what makes me wonder is the 6 channels indicators but only 3 are switched on?

and good to see that you are using different gfx mode... or did you everything with with chars like on the evil side?

[andym00]

Lol, different modes, although the 64 version of this VSPs the CPU meter Would be easier in chapters though
As for 6 channels, it actually setup for 8, only 3 of them are being fed with translated NES music.. I'll do a couple of MMC5 tunes, which is 2 extra channels.. In fact I did post some on FW..


(null)

[Heaven/TQA]

oh I thought that FW has the same content like here...

[andym00]

No.. There's extras there

(null)

[andym00]

Well I've just thrown up the guts of the code on CSDB in case anyone is really interested..
I'm loathe to put it all out because there's lots of embarrassing hackery going on in places, but the code there is the core of the whole thing..

http://noname.c64.or...2&topicid=90296

With that anyone should be able to take this stuff and make lots of funky voices for little CPU overhead, and Emkay should get his dream.. You can now just give the programmer the code and say 'hey add me some software voices!' Good luck..

[simonl]

andym00, on Tue Mar 13, 2012 3:46 AM, said:

Well I've just thrown up the guts of the code on CSDB in case anyone is really interested..

Nice one, thanks

Does anyone have any thoughts on what needs doing to the pokey emulation in Atari800 to get some sound out from these? I'm porting Atari800 to another platform at the moment, and it's a real pain it's not correctly generating the sounds for these.

Cheers,

Simon

[andym00]

Just a wild guess, but does Atari800 support the lax #imm instructions ? These are unstable across the 6502 family, but the lax#$00 instruction is stable due to the AND with 0.. Just a thought, since I did other stuff using the POKEY timers in the same way, some time back, and there were no complaints iirc.. And I've recently started (ab)using lax #$00 a lot

[simonl]

andym00, on Tue Mar 13, 2012 4:36 AM, said:

Just a wild guess, but does Atari800 support the lax #imm instructions ?

Hmmm... doesn't look like it, it has zero page, zero page y, absolute, absolute y, indirect x and indirect y but no immediate as far as I can tell, what opcode value should it be and should Z and N be set as per a normal immediate LDA? I can try adding it and see if that fixes the problem.

Edit: If it's $AB as per the list at http://www.oxyron.de.../opcodes02.html it has this as the following:

OPCODE(ab) /* ANX #ab [unofficial - AND #ab, then TAX] */
Z = N = X = A &= IMMEDIATE;

If that looks like it bears any relation to what you were expecting. I'll check against Altirra which works fine for these exes.

Thanks,

Simon

Edited by simonl, Tue Mar 13, 2012 5:34 AM.

[andym00]

lax #imm is opcode $AB
Though its behaviour is properly unstable for values other than $00..
http://vice-emu.svn....eneral/ane-lax/
http://noname.c64.or...1&topicid=30951

I'm just guessing that might be the cause of it.. I started using that very heavily in this stuff when I realised I can do fast 16bit negates leaving the result in AX like so:

	 lax #$00
	 sbx #lo
	 sbc #hi

It could well be simply the POKEY emulation..

[simonl]

andym00, on Tue Mar 13, 2012 5:39 AM, said:

It could well be simply the POKEY emulation..

Looks like it unfortunately, the ANX imm looks about how you described the LAX imm, I was hoping for an easy fix! I'll let you know if I get anywhere, as it's just making a heinous buzzing noise at the moment.

Cheers,

Simon

[andym00]

Which version is this based on ? Atari800 ? Atari800+ ? Atari800++ ? Or whatever other mad naming convention it could be..
And where can I get all the ROMs from since if I recall it needs the ROMs to do anything sensible..
I'll give it a whirl in the evening and see if I can tell you what's up with it..

[simonl]

andym00, on Tue Mar 13, 2012 8:11 AM, said:

Which version is this based on ? Atari800 ? Atari800+ ? Atari800++ ? Or whatever other mad naming convention it could be..
And where can I get all the ROMs from since if I recall it needs the ROMs to do anything sensible..
I'll give it a whirl in the evening and see if I can tell you what's up with it..

If it works on the latest version of standard Atari800 I can try and patch it from there, the version I'm using is based on Atari800MacX 4.6.0 so probably somewhat behind the trunk.

http://sourceforge.n...jects/atari800/

You can get the operating system ROM from the PC XFormer package here:

http://sourceforge.n...riginal XL ROM/

Cheers,

Simon

Edited by simonl, Tue Mar 13, 2012 2:52 PM.

[andym00]

I don't get very far with that..
It starts up (with crap all over the screen), does its caching, then just locks up dead, with crap on the screen where it should be clear.. Which is odd because all the screen data is >$E000 and is cleared earlier on, and the appearance of the data isn't particularly random either..

That's running it in 130XE mode, which the later versions of this thing needed..
Ummm, without any debugger this isn't going to be a particular enjoyable task

[simonl]

andym00, on Wed Mar 14, 2012 4:05 AM, said:

I don't get very far with that.. It starts up (with crap all over the screen), does its caching, then just locks up dead, with crap on the screen where it should be clear.. Which is odd because all the screen data is >$E000 and is cleared earlier on, and the appearance of the data isn't particularly random either.. erm.png That's running it in 130XE mode, which the later versions of this thing needed.. Ummm, without any debugger this isn't going to be a particular enjoyable task

Strange, it works much better than that on the Mac version, only the sound is messed up on mine. Has anyone else tried it on one of the releases of Atari800 and got it to work? If not, it might be worth raising a bug on the sourceforge tracker for it, it would be a shame if this technique couldn't be more widely enjoyed,

Cheers,

Simon

[Heaven/TQA]

Atari800MacX does not replay Andy's work correctly. At the moment only Altirra does.