Quote:
Guy Perfect wrote:
What you said was that the CPU doesn't have enough power to make PCM feasible. What I said is that making a Virtual Boy program in C won't get you enough power to make PCM feasible. I will continue to testify that a VB program written in assembly can be powerful enough to make some level of PCM useful as the sole source of audio in a game.
No... I never said that the CPU doesn't have enough power... actually, I said the opposite. If you read back, I said that I _do_ think that it's possible, but not worth it. If you write a game in assembly, counting cycles, etc... sure, you can probably make something work. But like you said, nobody is going to do that (unless you call pong with an amazing sound engine a worthwhile game).
And I'm also not talking about "some level of PCM"... I've already seen and shown that 4-bit from ROM is kinda quick, easy, etc. But it is pretty ROM hungry, still wasteful of the CPU, and not great quality (the Gameboy had 4-bit audio... we have 10 bits @ 41KHz, why throw that away?). You were talking about 40KHz, 8-bit, with waveforms generated on the fly (so the audio, PLUS a game fit in 2MB, not just the audio, like your one track that by itself barely fit in 2MB). I say a functional technical demo of this would be reasonable, but a full blown game where a large portion of CPU time is wasted on audio... I don't see the point. Reducing the sample rate reduces the load on the CPU, which is fine for speech, or special effects... but who wants an entire music score/sound effects limited to ~5KHz?
Though you seem to want to think I'm saying it's not possible, so you can prove me wrong... so if that's motivation for you to do it, I'll gladly say that it's not possible.
Also, regarding dithering... that won't work in this case. You'd need a LPF after the dithering... since the highest rate that you can dither is within the system's producable output range (it is being output), so you're just summing a 1-bit high frequency signal on top of your other signal. Look at the design of a sigma-delta DAC... that's similar... without the LPF, it's not much of a DAC (well, it's a 1-bit DAC).
Quote:
Guy Perfect wrote:
Quote:DogP wrote:
BTW... you don't need to modify the crt0 to set the waitstates... you can set it in your code like: HW_REGS[WCR]|=ROM1W; (where WCR is 0x24 and ROM1W is 0x01).
We libvueians have no need for such archaic, outdated technologies. (-:
VUE_WAIT_CONTROL = vueWaitControl(VUE_WAIT_1, 0);
Woah! You libvueians must be some advanced race. Why did you modify the crt0, when you had such an amazing and intuitive control mechanism for it? x++; is pretty archaic too, right? Is the libvueian way to do it x=addOneToThisValue(x); ? That's too advanced for me... I'll just stick with my stone and chisel.
On a serious note, is the last 0 saying that it's the ROM bit, not the EXP bit? Maybe defining that would make it a bit more clear... everything else is actually descriptive, but a stray, undescriptive 0 looks arbitrary and out of place.
I still prefer specifically setting the bits, because I can read the dev manual, decide which bits I want to set, and set them, without digging through header files to figure out that what I want to do requires something called VUE_WAIT_CONTROL, vueWaitControl, and an argument of VUE_WAIT_1 (and apparently a 0 for some reason)... my way (as in the way it's been done until the libvueians decended to Earth to spread their superior knowledge) has the names defined the same as the register names from the manual... but if that's too "archaic" for you, that's your own call. But I'm sure you're gonna say that libvue will have full documentation explaining every part of it... yay. My archaic way already does.
DogP
USA
boxes.jpg (175.89 KB)
![Open in new window](javascript:CaricaFoto("http://www.planetvb.com/cache/10_518efc2525b45.jpg");)
