Guy Perfect wrote:
Smileys in text are used to indicate humor. They follow passages or messages that aren’t intended to be taken seriously.

Yes… sorry, I should have used more of them. 😉

Guy Perfect wrote:
Configuring the ROM wait controller to use 1 wait makes sense: it speeds up cartridge reads. The register can be configured directly by the C program, but I don’t see any compelling reason to set it to 2 waits, much less have the default (via crt0) be 2 waits.

The default at hardware reset is 2 waits, so I wouldn’t really say the crt0 default is 2 waits (I’m guessing it wasn’t previously setting it at all). Personally, I think setting the waits to 1 should be done in the program, not the crt0. By setting it to 1, you’re requiring the ROM to be <= 100ns. That's fine in some cases, where you're willing to give up compatibility for performance... but not in all cases. I personally frequently use 120ns flash (that's what's in my cart right now), and I'm not sure that all Flashboys have fast enough flash installed (I know at least one of the prototypes used 120ns). The problem is, that if I write a program using your 1 wait state crt0, I can't just set the wait states to 2 in my program for compatibility with my slow flash... where the opposite is possible (starting with 2 wait states, then changing to 1). I can't think of a realistic application where 2 wait states before execution of your init code would be problematic.

Guy Perfect wrote:
Given the macro definition above, that zero was the parameter for configuring the expansion wait controller. Since I had no preference to how that wait controller was configured, I just set it to zero. As School House Rock always liked to say: knowledge is power!

Ah, I see… though it seems that you should always use VUE_WAIT_1 or VUE_WAIT_2, since the value that you put there DOES do something (not a don’t care). Anything other than a valid value could produce unwanted results (yes, in this case, 0 is valid… but to promote just putting 0s in parameters that you don’t care about seems a bit dangerous). 😉

Guy Perfect wrote:
Though it’s worth bringing up that you’re describing the same procedure requried to find out that there’s an array called HW_REGS, which has a subscript called WCR, which can be configured with a constant called ROM1W. It’s a case of the mallard calling the teal a quack.

Not really… like I said, once I know that HW_REGS exists, by referencing the dev manual, I know that WCR, THR, CCR, etc. exist, and exactly what they do (yes, HW_REGS is a bit arbitrary, and if I was to make a change, I’d go with NVC_REGS, VIP_REGS, and VSU_REGS to be consistent). I’d argue that most of the names are pretty easy to remember, but that’s just a matter of opinion. But what is hard to remember is that VUE_CHANNELS[2].play_control is the same as S3INT (and whatever all the other names changed to)… so if I’m referencing the dev manual, there will be a lot of cross referencing to figure out how to make it work.

But, it sounds like we just disagree on a lot of stuff, so I’ll finish up with a great song:

And if you don’t like that song, then I’d say that we have nothing in common… which reminds me of another good song:
http://www.youtube.com/watch?v=1ClCpfeIELw (replace Breakfast at Tiffany’s with Virtual Boy).

DogP

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

Guy Perfect wrote:

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

Just a quick last-minute bump… the boxes are starting to pile up, and I’m planning to do these this weekend, so if you haven’t gotten them in the mail yet, get moving. 🙂

DogP

Good analysis… I would say “told you so”, but it’s never time wasted to prove something to yourself. 🙂

RunnerPack wrote:
Although, given your final analysis, it seems as though, if we want to upgrade the sound hardware on the VB (which I still think hasn’t been taken anywhere near its true potential), we’ll have to take advantage of the cartridge port audio pass-through system the designers built in.

I keep considering doing some sort of add-on using the pass-through… but if only 1% of people playing it can experience it (and require adding support for this unofficial hardware to emulators), it’s probably not worth it (we’d need a Flashboy++ or something to get it into the hands of more people 😉 ).

RunnerPack wrote:

Guy Perfect wrote:

RunnerPack wrote:
Great work building on the groundwork laid by DogP and HorvatM!

Built nothin’. I did this all from scratch. (-:

Well, then, good work reinventing DogP’s wheel 😉

He did this waaaay back in 2008. I thought it was on the site somewhere, but I guess he only shared it via IRC. And then there’s HorvatM’s 8-bit wav player he just posted a few days ago which I assume must use the same idea.

There were a lot of tests and revisions (which were probably only posted on IRC, or maybe a few forum threads), but it was all rolled into my wav converter, which is posted here:
http://www.planetvb.com/modules/tech/?sec=tools&pid=wav2vb , and technical description/discussion here:
http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=8921

Heh, and this reminds me of: http://knowyourmeme.com/memes/events/you-didnt-build-that .

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

DogP

Guy Perfect wrote:
100% – 10% > 0%, you know. I’m not sure what you’re trying to say.

I’m referring to:
>As for being ROM hungry, what novice tries to use uncompressed wave files for music on a system like Virtual
>Boy? It’d be far more effective to use sampled instruments and generate a PCM stream at run-time using the
>other 90% of the CPU. (-:
10%+90% = 100% 😉

Guy Perfect wrote:
In the program attached to the first post, I was using the hardware timer interrupt, which proved to be less than what it said on the label in terms of speed. With the interrupt breaking, stack management and other overhead, it took more than 20 microseconds to get in and out of the interrupt handler.

Right… that’s exactly what I’m saying. I’m not saying it can’t be done any other way, but the intuitive (and friendly) way, while also running a game, is to use an interrupt.

Guy Perfect wrote:
I said it couldn’t update four sound channel properties for each of the left and right signals without audible side-effects. This is an entirely separate issue from the sampling rate.

I wasn’t talking about sampling rate, I’m just saying that computing and updating register values DOES take time.

Guy Perfect wrote:

DogP wrote:
IMO, the advantage of PCM is for realistic sounds that wouldn’t be generated on the fly, like speech… not for creating a better VSU using the CPU). But in the end, if you make a game that uses PCM for everything, and it works well… that’s all that matters.

Ah ah ah, no conjecturing allowed. That is not the scientific method! If you’re creative enough, you’d be surprised just what can be accomplished, even when others say it can’t be done.

Uh… yes, note the _IMO_… I’m entitled to an opinion. Also, note the last sentence… I’m saying I believe it can be done, and if you do it, good for you. I would truly like to see a 41KHz PCM implementation in a full-blown VB game… it would be quite awesome. But my _opinion_ is that utilizing the VSU for all that it’s worth is more worthwhile than doing everything in the CPU. It’s almost like doing everything manually by drawing directly to the framebuffer, rather than using worlds, objs, etc. Yes, you can do it, and in some cases it’s a good idea, but in a lot of cases, it’s not.

Guy Perfect wrote:
46 levels has beautiful quality. Check the sound file I attached to this post. The only problem is that quantization noise. If I can eliminate that, we’re in business.

Well… quantization noise is caused by quantization error. Quantization error is the difference between the desired value and the value that it’s represented by. So, unless you generate a signal where all the values land right on your 46 possible levels, you’re always going to have quantization noise. You can reduce the quantization error (and therefore noise) by increasing the number of bits.

DanB wrote:
Very cool! It sounds great, nice work! I just don’t get how simply changing the volume on a constant tone can result in such different sounds?

No… not changing volume on a constant tone, but on a constant DC waveform.

Guy Perfect wrote:
I wouldn’t say it’s processor-intensive or ROM hungry. You’re making a couple of assumptions that don’t have to be the case. (-:

What about the game? Does that get 0% of the CPU? 😉 Like I said… if you’re not doing anything else, it works great, but I don’t want to spend anywhere near 10% of the CPU on audio in a real application. And 50 cycles/sample would be optimistic IMO, if you count all the overhead involved (assuming it’s actually playing a game, firing an interrupt ~40,000x per second)… and if you’re generating the samples on the fly, obviously that’s even more overhead. Plus, didn’t you say your 8-bit didn’t work, because it took too long? IMO, the advantage of PCM is for realistic sounds that wouldn’t be generated on the fly, like speech… not for creating a better VSU using the CPU). But in the end, if you make a game that uses PCM for everything, and it works well… that’s all that matters.

Guy Perfect wrote:
Absolutely. Here’s a wave pattern I just tested:

Ah, good… I must have been thinking of something else I was working on.

Guy Perfect wrote:
Jumping to conclusions would be foolish. That’s why I made a wav file on my computer with the same 46 levels to see how it sounded. It contained the same static that I heard on the Virtual Boy. (-:

If 46 levels doesn’t have sufficient quality, why even consider it? How many bits do you need before you’re happy with the sound? It sounds like that’s the number you should be shooting for.

DogP

Nice brain dump. A few comments:

First… yes, I believe Galactic Pinball and the T&E Soft games used the 4-bit approach, as does my wav converter.

Regarding the 46-level… you’re saying you can get 46 levels in 3 channels, but you need 6 channels to do 46 levels? I quickly skimmed through it, so maybe I’m missing what you’re saying, but are you saying because of stereo, you’re using 3 channels for each? Why wouldn’t you use the L/R levels for stereo (you get 4 bits for each channel independently, right)?

I took a different approach for more bits when I was experimenting with PCM years ago. I used varying levels of the waveform RAM, since 63 is (basically) 2x of 32, which is 2x of 16, and so on. I liked the waveform RAM, because it’s later in the chain, so all 6-bits get applied (though they could get chopped later if the level is too low).

I tried a couple different methods… one was a dynamic method using a single channel, and always outputting just 5 bits (4-bits L/R, plus 1 bit of ENV), but sliding which 5 bits were output (for example, if the sample was 5, it’d output the lower 5 bits from the low-bit RAM… but if the sample was 250, it’d output the upper 5 bits from the high-bit RAM). This was pretty cool, because it gave more overall dynamic range, but still used the simple 5-bit resolution. Of course you could round, rather than just masking the bits, but that’s more computation (it’d be better to do that ahead of time in the conversion process). The disadvantage of this is the small error, that it really only works for mono (stereo would need a second channel), and that it uses several waveform RAM slots.

The other method was using multiple channels with multiple RAM slots. This way is nice, because you CAN use it with stereo, and you can easily get more bits. Set the first channel’s waveform to 63, and the second channel’s waveform to 4… put the upper 4 bits in the first waveform and the lower 4 bits in the second channel. I guess if you really cared about perfection, you could do 32 and 2, but your low bits may get wiped away if you go too low.

The problem with any PCM though is that it’s processor intensive, and ROM hungry. It’s cool for short effects, where nothing else is happening… like “T&E Soft Presents”, but it’s not really practical for music or in-game special effects. I stuck with 4-bit for the wav converter because the sound is reasonable, you can do 2 samples/byte (5KB/s @ 10KSps mono), and it’s (relatively) easy on the processor.

BTW, are you sure that the RAM is unsigned? It’s been a long time since I’ve looked at any of this sound stuff (I’m pretty much going by memory on all of it), but I seem to remember looking at the output on the scope, and determining that it was signed. But I could be mistaken… IIRC, the dev manual didn’t specify signed or unsigned (which is why I checked it out in the first place). If I could just find half my notes and test code, I’d probably have some better input. 😉

Oh, and I’m not sure that I’d jump to blame quantization error for the static sound. I’d run a few tests first. A simple one would be to make a wav file on your computer with the same 46 levels and see how it sounds. Then convert that, which should (in theory) map perfectly to the VB. Does it sound identical? Also, I’d try generating a tone and look at it on a scope to inspect the quality of the signal (does it look sinusoidal, are the samples evenly spaced, is there any strange behavior). Looking at the spectrum of that signal would probably tell you a lot as well.

DogP

thunderstruck wrote:
Hmm, but why spent money on changing the text if nothing else was planned for the port? My best guess is that nintendo planned some additional accessories for the vb that would have been connected using the link port and they changed the text during early development to not confuse users.

That could be… though I never saw any hints that anything else was considered (barely saw any reference to the link cable). I’m guessing that they knew they were never going to make the link cable, so they got rid of PLAYLINK to reduce the number of calls asking “Where can I get a PLAYLINK cable for my PLAYLINK port?”

That, or another interesting thing is that the US manual calls it the GameLink port. Is it called PlayLink in the Japanese manual? Maybe they changed it to EXT. so all regions (JP, US, and presumably EU if it ever made it there) could use the same mold without inconsistencies on GameLink, PlayLink, etc.

DogP

WoLfMaN wrote:

DogP schrieb:

You can clearly see that they modified the mold from PLAYLINK to EXT.

DogP

Well, not quite. If you look at the other pictures, you see that there is no rectangle…so your theory is somewhat half-way 😉

The quality of the molds definitely vary, but I believe on a couple of the pictures above, you can’t see it in the picture because it’s one of the better quality ones, and the lighting/angle isn’t just right. But at the correct angle, I’m pretty sure you’d be able to see a slight rectangle (maybe Benjamin can confirm). I have two sitting next to me, which I can’t tell, unless I get the glare just right, like this:

(S/N VN10112924[2])

DogP

Attachments:

1. 

   ext.jpg
   

Interesting… I haven’t looked at many JP systems, but the ones that I had seen all had PLAYLINK (most were demo systems, so maybe that’s why).

You can clearly see that they modified the mold from PLAYLINK to EXT. (PLAYLINK looks just like CONTROLLER… EXT. has a noticable rectangle around it, likely where the mold was modified), so I’d guess at some point in the run, they realized that the link cable might not happen, so they changed to EXT. Since the VB was released in Japan first, the mold was probably changed before any VBs made it to the US.

DogP

kkabalka wrote:
Ok I have absolutely no i dea what is going on with my vb. When i am up close to it with my face pressed right into the visor it looks fine with only ocasional glitch ups when the image on screen suddenly changes ect, but when you pull your face back and look through the left eyepiece (Right looks fine even from distance) it goes all fuzzy and glitches up. I dont think its glitchy display and why does it go all wonky when you move away any guesses?

1st image is up close 2nd is glitch up

That actually looks like a typical cable problem (when one of the clock pins isn’t making good contact). I’m not sure why it matters whether your face is in or not, but I remember someone talked about a similar problem, where the displays would act fine in the dark, but not when the lights were on.

Maybe the cable is close enough that the clock is inductively coupling, but when the LEDs gather light, they act as photodiodes and cause a bias… or maybe it’s radiating the clock like an antenna, and the reflection off your head in the near field causes constructive interference… I dunno… I’m just making things up. 😉

But yes, it’s probably the cable.

DogP

Benjamin Stevens wrote:
But then again, the only differences between a Japanese Virtual Boy system and a North American Virtual Boy system are the serial number stickers stuck to them as well as the packaging that they came in.

They’re not quite identical… you can see that they modified the mold for the US version, to change the text “PLAYLINK” (on the JP systems) to “EXT.” (on the US systems).

DogP

I’d send him an email… most likely his database needs to be updated, or possibly the files you’re using aren’t the exact ones that are in the database (if they’re padded differently or something). IIRC, files under a certain size were supposed to run without limitation, but maybe that’s not the case anymore.

Have you tried Mednafen? It looks like it’ll run on OSX, and is probably a more accurate emulator (I haven’t really been following Mac emulators, but I don’t think ViBE has had much development in quite a while).

DogP

Did you “ensure that it the file is valid”? 😉

I haven’t used ViBE in YEARS, but there used to be a CRC check to make sure you didn’t play ROMs that the author didn’t have (er… I mean, that the author didn’t make sure were valid). 😛

That could be the problem (I don’t remember if that was the message)… in which case, you may want to send him an email and ask him to update the database. I would have expected BLOX to have been added though. Do other games work? I assume you unzipped the .vb file from the .zip file? I dunno whether it’ll unzip the ROMs for you.

DogP

All except the floor one… and multiples of some.

DogP

Heh, well to be fair, I wouldn’t expect an undergrad in “Fine Art” to have a clue how to program a VCR, let alone figure out how to program an old video game system. I’m guessing their professor would have no expectation of them actually writing the code… it’s probably the artsy presentation of it that matters.

On a side note… does anyone still have a VCR??? Maybe that saying needs an update. How about programming a DVR?

DogP

Okay… well I’ve got good news and bad news.

First, the good news is that 40 displays will be getting repaired. 🙂

The bad news is that the last spot just filled up. 🙁 If you’re not on the list, feel free to PM me to get on a wait list. If there aren’t too many more, I may be able to squeeze you in. If there are a bunch more, I’ll add you to a possible round 2, which could happen, depending how the first round goes.

DogP

I’d be glad to fix the displays for you: http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=5152&forum=1 .

I know maybe you technically don’t quite qualify with because you’re a day late… but rules are meant to be broken. 😉

Oh, and Benjamin… I’m not sure that I’d lay the blame wholly on Nintendo of Japan. Nintendo in general (America and Japan) chose to use parts from Sanyo, which is the company who actually made the defective display. I’d say Sanyo is mostly to blame because of their bad engineering.

DogP

Just a heads up… we’re just under half the total available slots filled, so if you’re interested, definitely let me know soon. It’s good to see that we’re gonna get a good chunk of systems fixed for good. 🙂

DogP

Just wanted to bump this thread… we’re still trying to make this happen. I think the new simpler design should be more easily manufacturable… I guess we went a bit overboard with the initial design.

And I’ve just about got a PCB designed to go inside the housing, for the USB link… I’ll probably get that board manufactured as soon as it’s ready, so I can test that design.

DogP