Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

andym00

Members
 View Profile  See their activity

  • Content Count

    1,048

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by andym00

  1. Posted

    makefile projects are what you want, though you don't need a makefile at all..

    Just set it up to use build, clean, rebuild scripts in the NMake tab of the properties and bob's your uncle..

    Helps if you have an assembler that outputs errors and warnings in the MSVC fashion, then you can just F4 and double click on errors and warnings in the output window..

     

    edit: Here...

    post-3913-0-15789800-1331231764_thumb.png

  5. Posted

    Oh, I wasn't saying this the means to the best possible compression, just this offers less memory, and less CPU time than normal methods.. And there's no downsides to it, no quality loss, less memory, less cpu time.. It's not often you can say that about something ;)

     

    Anything more complex is going to eat time, and I'm loving this whole 15.6K playback with less interrupts thing right now..

     

    The issue with anything more than 4 bits is I think you won't get enough repeats to justify it, and also the other methods of playback, like Phaerons ~6.9(ish) bit playback method is that I don't see how you can change the timer values like you would need to.. Though I've not looked at exactly what he does with that..

     

    The C64MP3/Cubase64 stuff is stunning to say the least, but it's not my cup of tea.. I'd much rather be synthesising stuff on the fly..

     

    I just thought given everyone plays samples the same way, that it'd be useful.. I mean sheddy could retrofit it to SH easily enough, giving more cpu, less memory.. Heaven could easily use it.. Anyone playing samples the standard way gets an instant improvement..

     

    What's interesting though.. Encoding synthesised sounds like from my Pulse stuff, encodes stupidly well, as you would imagine.. So you could have a mountain of pre-synthesised pulse sounds, that are stored as samples like this, with very little memory footprint at all.. For reference, when the Pulse stuff is in full flow, with too many high notes, it's often only generating hundreds of samples a second, which would take no memory to store.. So you could have pre-synthesised sounds, done updating voices at many 100's of Hz for faster pitch sweeps and FX, and store with with little memory, and very little overhead to playback, I mean, very very little due to the low number of waveform changes per second..

     

    Again, this one, big fuzzy noisy thing it is, still compresses to only 48K, which isn't too shabby for 8.5 seconds of 15Khz audio, admittedly it's only acheiving a 1.5:1 compression ratio..

     

    Also, you can get some bonkers effects out of it by simply adding values to the length value when you write to the timer, instead of just shifting it to adjust the base sample rate :)

    main.xex

  6. Posted

    It'll benefit.. There's no trade off for this method.. It really is less memory, less CPU time :)

    Just fired it up for the first time after hacking together when I should have been doing other things ;)

    Here's a simple 15.6K test.. Not the best sample, but it'll do to test the encoder and things..

    You can see each colour change is an IRQ, whereas with normal playback every line would have an IRQ..

     

    The first colour is just where the IRQ enters, the grey colour (if you've got enough overscan) is the sample being set..

    Just jiggling the IRQ timing to find the best setting, and least wastage..

     

    This sample is 14K in raw 4bit packed mode, and with this method, 6KB :)

    main.xex

  7. Posted

    In addition to all the pulse sound stuff I've been doing some thinking about regular sample playback..

    The idea is pretty simple, and surprisingly works very well..

     

    It saves memory, and also saves CPU time, lots of CPU time in the case of higher sample rates..

     

    Instead of the conventional packed nybbles of samples, packing 2 4 bits samples into one byte, I had the idea of storing a length in one of the nybbles..

     

    Now, you might think this is a bit silly, but you'd be wrong :)

     

    In a bunch of 15.6K 4bit samples, every single one of them compresses to less, not one is bigger..

    In the below data, remember that the source size listed on each sample is as 8bit samples, so the regular 4bit version is half that size.. I've not been delicate about what I've given it, and it's a right old mixture..

     

    Now, look at the numbers.. It's giving you some quite cool results..

    The individual drums sounds compress amazingly well, 6:1 in some cases!!

    General, very noisy, speech does okay, in the region of 1.5:1

    A recording of some SID music, 2:1

    So there you have it.. A lovely simple way to get more samples in your games, with less CPU overhead :)

     

    Playback is dead simple, you just use the POKEY timers, or 6522/6 to set the delay after setting each sample..

    So, the playback code is literally..

    lax SampleData
and #$0f
ora #$10
sta AUDCx
lda LSR4,x
sta AUDFx

    I'll knock up some tests today when I've got a few hours, but the playback scheme is exactly what I'm doing in the Pulse sounds stuff I've been working on..

    Granted, this really only works well for one channel of sample playback, but there's means and ways to mix compressed sample data in realtime ;)

     

    Anyway.. Thought I'd share this...

    No doubt someone will be along in a second to piss on the bonfire..

    But until then..

     

    Loaded 'samples\606BASS.pcm' size 3800 bytes
4 bit length - Compressed size: 328 bytes

Loaded 'samples\606CHAT.pcm' size 3500 bytes
4 bit length - Compressed size: 1258 bytes

Loaded 'samples\606CYMB.pcm' size 15000 bytes
4 bit length - Compressed size: 6760 bytes

Loaded 'samples\606HTOM.pcm' size 5000 bytes
4 bit length - Compressed size: 580 bytes

Loaded 'samples\606LTOM.pcm' size 5000 bytes
4 bit length - Compressed size: 544 bytes

Loaded 'samples\606SNAR.pcm' size 4374 bytes
4 bit length - Compressed size: 1034 bytes

Loaded 'samples\Jeff-Evolver6581r4.pcm' size 320000 bytes
4 bit length - Compressed size: 77292 bytes

Loaded 'samples\die_hard_yippee2.pcm' size 591830 bytes
4 bit length - Compressed size: 149822 bytes

Loaded 'samples\circle_is_complete_x.pcm' size 240744 bytes
4 bit length - Compressed size: 94618 bytes

Loaded 'samples\apxtwin.pcm' size 1239887 bytes
4 bit length - Compressed size: 492018 bytes

Total source size: 2429135 bytes
4bit size: 824254 bytes

     

    If you got this far, then I also did a bunch of tests that also used different bit sizes for the lengths, a little more work decoding..

    Interestingly the best bit size is 3bits.. On average it's about 10% better than 4bits, but that means you have 8 length values packed into 3 bytes, then the 8 samples packed as nybbles, so every 8 samples you'd need to unravel the next 8 length values.. Not a biggy, but not as elegant as 4 bits, and for only a small gain..

     

    I also did results with other convenient bits sizes that work well, namely, 1, 2, 3, 4, 6, 8 bit lengths values..

    Here's the results for all of them in case you're curious..

    Loaded 'samples\606BASS.pcm' size 3800 bytes
1 bit length - Compressed size: 1215 bytes
2 bit length - Compressed size: 763 bytes
3 bit length - Compressed size: 490 bytes
4 bit length - Compressed size: 328 bytes
6 bit length - Compressed size: 210 bytes
8 bit length - Compressed size: 205 bytes
Loaded 'samples\606CHAT.pcm' size 3500 bytes
1 bit length - Compressed size: 1357 bytes
2 bit length - Compressed size: 1198 bytes
3 bit length - Compressed size: 1198 bytes
4 bit length - Compressed size: 1258 bytes
6 bit length - Compressed size: 1480 bytes
8 bit length - Compressed size: 1746 bytes
Loaded 'samples\606CYMB.pcm' size 15000 bytes
1 bit length - Compressed size: 6261 bytes
2 bit length - Compressed size: 5682 bytes
3 bit length - Compressed size: 6125 bytes
4 bit length - Compressed size: 6760 bytes
6 bit length - Compressed size: 8290 bytes
8 bit length - Compressed size: 9915 bytes
Loaded 'samples\606HTOM.pcm' size 5000 bytes
1 bit length - Compressed size: 1625 bytes
2 bit length - Compressed size: 1059 bytes
3 bit length - Compressed size: 742 bytes
4 bit length - Compressed size: 580 bytes
6 bit length - Compressed size: 500 bytes
8 bit length - Compressed size: 577 bytes
Loaded 'samples\606LTOM.pcm' size 5000 bytes
1 bit length - Compressed size: 1623 bytes
2 bit length - Compressed size: 1042 bytes
3 bit length - Compressed size: 710 bytes
4 bit length - Compressed size: 544 bytes
6 bit length - Compressed size: 455 bytes
8 bit length - Compressed size: 519 bytes
Loaded 'samples\606SNAR.pcm' size 4374 bytes
1 bit length - Compressed size: 1558 bytes
2 bit length - Compressed size: 1212 bytes
3 bit length - Compressed size: 1067 bytes
4 bit length - Compressed size: 1034 bytes
6 bit length - Compressed size: 1153 bytes
8 bit length - Compressed size: 1366 bytes
Loaded 'samples\Jeff-Evolver6581r4.pcm' size 320000 bytes
1 bit length - Compressed size: 113287 bytes
2 bit length - Compressed size: 82620 bytes
3 bit length - Compressed size: 72915 bytes
4 bit length - Compressed size: 77292 bytes
6 bit length - Compressed size: 95088 bytes
8 bit length - Compressed size: 114073 bytes
Loaded 'samples\die_hard_yippee2.pcm' size 591830 bytes
1 bit length - Compressed size: 210877 bytes
2 bit length - Compressed size: 164604 bytes
3 bit length - Compressed size: 147731 bytes
4 bit length - Compressed size: 149822 bytes
6 bit length - Compressed size: 177745 bytes
8 bit length - Compressed size: 212863 bytes
Loaded 'samples\circle_is_complete_x.pcm' size 240744 bytes
1 bit length - Compressed size: 95233 bytes
2 bit length - Compressed size: 84858 bytes
3 bit length - Compressed size: 86459 bytes
4 bit length - Compressed size: 94618 bytes
6 bit length - Compressed size: 117175 bytes
8 bit length - Compressed size: 140556 bytes
Loaded 'samples\apxtwin.pcm' size 1239887 bytes
1 bit length - Compressed size: 485787 bytes
2 bit length - Compressed size: 431052 bytes
3 bit length - Compressed size: 442900 bytes
4 bit length - Compressed size: 492018 bytes
6 bit length - Compressed size: 612777 bytes
8 bit length - Compressed size: 735333 bytes
Total source size: 2429135 bytes
1bit size: 918823 bytes
2bit size: 774090 bytes
3bit size: 760337 bytes
4bit size: 824254 bytes
6bit size: 1014873 bytes
8bit size: 1217153 bytes

     

    If raw compression was your goal then you could easily implement a single player to handle all of those modes, wouldn't be a huge job at all..

    But personally, I think the simplicity of the 4bit length wins the race :)

    • Like 4

  10. Posted

    Would love to see a 68008 board for old 8bits, that'd be awesome, although half of me thinks it'd be ludicrous at the same time, but an A8 with 16MB of linear RAM would be a slightly mental device to say the least :)

    I have to mention DTACK Grounded, for a wonderful tale of 68K fun and games and building 68K boards back in the day, ~81 onwards.. A great read, and there's some fascinating information buried away in there if you've got the time to read all the newsletters.. http://www.easy68k.com/paulrsm/dg/

  11. Posted

    Look at the "interesting" thread. And listen to the results with ANTIC turned on or off.

     

    There is no difference.. In some of them they don't have the stablised timing enabled, the earlier ones when performance was an issue.. The later ones all (mostly) have the stable timing enabled, and that means the sample is outputted at *exactly* the same clock cycle each time, no jitter at all.. It doesn't get any more accurate..

    This is true whether the screen is on or off.. If you're hearing a difference between ANTIC enabled or disabled versions, that have the output stabilisation in it's because you want to..

     

    IRQ_CODE:
!pseudopc $30 {
IRQ0:
pha
irq_sample_index = * + 1
lda sample_buffer
!if STABLE_TIMING  { sta WSYNC }
sta AUDC4
+irq_ack
inc irq_sample_index
irq_length_index = * + 1
lda length_buffer+2
bmi .wrap0
and #$7F
sta AUDF4
inc irq_length_index
pla
rti
.wrap0:
and #$7F
sta AUDF4
inc irq_length_index
cli
pla
jmp Wrap0
}

     

    If the code 'misses' the wsync and waits a whole, the whole audio goes to pot and sounds really quite bad.. It doesn't miss it, and is stable, when I enable stable timing, which is the normal now :)

     

    And the stable timing works in all screen modes, except the char modes that have 32+ bytes badline.. It does still work, but you get a fuzzy output because of the IRQs jittering..

     

    The IRQs timing is arranged such that very few cycles are ever wasted in the wsync, although there's so few interrupts it doesn't really matter anyway ;)

    And in the case of a back to back IRQ, there's spare cycles in between, just! Although the whole bmi/and stuff is coming out, so that'll mean more breathing room inbetween back to back samples..

     

    Anyway.. You're hearing things, if you're actually listening to the right things :)

     

    edit: And before the clever clogs arrive, it uses pha/pla because although the IRQs aren't re-entrant (there's room between them), a DLI can occur before the end of the IRQ, the DLI then enables the interrupts, and then possibly an IRQ will interrupt the DLI meaning that the IRQ has to be re-entrant to support that case..

  13. Posted

    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)

  14. Posted

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

    mixed with DLIs.zip

  17. Posted

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

    pac-follin.zip

    my_first_tim_follin_cover.zip

    megavania.zip

  19. Posted

    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 :)

  21. Posted

    Melody is the developer version of Harmony, same hardware except it's not update-able by the end-user..

    It does a shed-load of things, least of which is being able to run game specific things on the ARM side of things..

    http://www.atariage.com/forums/topic/163495-harmony-dpc-programming/

    http://www.atariage.com/forums/topic/163834-harmony-dpc-arm-programming/

    Check out the Frantic WIP for a good example of what it can make the 2600 do..

    http://www.atariage.com/forums/topic/186560-frantic-2600/

    It puts some A8 games to shame ;)

    • Like 1

  22. Posted

    Insofar as the 2600 goes, BD and BB (if/when done) are state of the art and you'd not get much better on that machine without resorting to something like a fast RISC that sits on the cart and just pumps LDA #$xx / STA $yy instructions through the bus to hit the hardware at the quickest possible speed.

     

    BD is a melody cartridge, so it does have this mythical beast you speak of ;)

  23. Posted

    ANTIC versions, with the a real screen on, doing things, with 15.6K playback rate..

    It does need some memory expansion though!

    Trying to work around the 16K ROM footprint of the the NES music code, and then 16K of RAM needed to capture APU writes (and other things) is just too much of a hole for me too keep working around.. I took the NSF relocator out because it was corrupting some tunes.. I tried some other methods of figuring out if I was looking at code or data but nothing was utterly fool proof.. So.. I resorted to using a 16KB bank to do the capturing.. I didn't want to waste lots of time on something that's not important in the long run.. That aside, something has broken somewhere.. Tunes that once did play have gone a bit wonky here and there, something is corrupting something somewhere.. God.. I hate searching for those kind of bugs!

     

    Anyway... You now get the same display as the VBXE, but using ANTIC, so it's mostly mode E and a real world kind of setup..

     

    And note.... Big note.. This is running with wsync stabilised IRQs which means it's burning more time than necessary, but sounds nicer.. It has highlighted that there's no way on earth that you're going to have 15.6K (with it stabilised) output when using mode 2 or 4/5 with the entire badline.. That said, the non-stabilised version doesn't sound too bad actually ;)

    VBXE be gone.zip

    • Like 4
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...