The ends of my stand point away from me. I keep the controller behind the stand while playing and “hug” the Virtual Boy as I play. I think that’s the way it was designed.
blitter wrote:
Nice. I had not realized this. Could definitely do six independent PCM voices then!
If you control a PCM stream, you can put as many voices as you want in it. You won’t need multiple sound channels in that regard. I’m only using them here to increase my sample size.
Doing that in real-time though will significantly bump up the CPU usage, right? Probably better to leverage the VB’s mixing hardware as much as possible. Six channels of 4-bit sound looks to me to be the most efficient way of doing multi-channel PCM audio on the VB.
Guy Perfect wrote:
We luck out again, because the noise channel can actually be used as that sixth channel. See, the way the noise algorithm works, the first 7 samples generated during a sequence will always be 63, the maximum value. And the sequence is reset whenever the tap location is configured. So if we just set the tap location every time we update the volume, we get a constant high signal out of the noise channel!
Nice. I had not realized this. Could definitely do six independent PCM voices then!
DogP wrote:
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
ViBE hasn’t had an update in about a decade– I’d be surprised if he still would support it.
Mednafen works very well in OS X if you don’t mind building and running it yourself from Terminal. I use it for my VB development, I think it’s that good.
Just wanted to chime in here and offer my kudos to UncleTusker– got my BH set at work today and it is very professionally done. A couple folks on my team were amazed at how official it looked– they didn’t believe it when I said it was a fan repro. To all of you still waiting– I can’t find anything about this set that is unimpressive.
void drawPixel(u16 x,u16 y, u8 color){
//Find the byte for the pixel
color = color<<6>>6;
xbytel = x*256; //multiply by number of pixels per column
ybytel = y;
yleft = ybytel & 0x0F;//grab 1st 4 bits
if(yleft>0) yleft = yleft<<1;
xbytel >>= 4;//divide by 16
ybytel >>= 4;//divide by 16
LFB1[(xbytel + ybytel)] |= (color << yleft);
RFB1[(xbytel + ybytel)] = LFB1[(xbytel + ybytel)];
//LFB2[(xbytel + ybytel)] = LFB1[(xbytel + ybytel)];
//RFB2[(xbytel + ybytel)] = LFB1[(xbytel + ybytel)];
}
Why are those last two lines commented out? The XP swaps the framebuffers each frame, so if your second set of buffers are never filled with anything, the screen will rapidly alternate between your drawing and black, causing the flickering.
Take your time, Vaughnabe13. I’m particularly excited about this board and the potential for it (or a future revision) to allow for additional space in the expansion RAM area for bigger games. My current project is being developed for the FlashBoy and is taking quite a long time, so don’t feel too pressured from me anyway. 🙂
P.S. Are you the same Vaughnabe13 on the MTBS3D forums? *waves*
Dreammary wrote:
If it was 2-bit graphics it would be blocky like Atari 2600; you are confusing color resolution with graphics resolution. 2-bit meaning red and black are the only colors on the screen simultaneously but it’s graphics capability is 32-bit.
Umm… huh?
Virtual Boy is without question a 2-bit graphical display for the reasons colesonwilson mentioned. 4 colors == 2^2. The Game Boy also had 2-bit graphics / 4 monochrome shades. Even taking into account that each BRTx register on the VB can be set to values up to 185 (that seems to be the range from my experimentation), you still only have a palette of 4 colors to choose from. To compare to the venerable Atari, you could say the 2600 had a 7-bit palette, as it allowed up to 128 distinct colors on an NTSC television.
The VB CPU was 32-bit, as were the other systems of that era (PlayStation, Sega Saturn).
The SNES CPU was 16-bit, like the Sega Genesis of that generation.
The GB CPU was 8-bit, like its predecessors the NES and 2600 as well.
I am very confused by how you define its “graphics resolution” as 32-bit… what do you mean “graphics resolution?” If you mean its screen resolution then the remainder of your comparisons make no sense– the VB has a 384×224 display, the Game Boy has a 160×144 display, and even the “2-bit” Atari 2600 could output 160×192 on NTSC with clever programming of the TIA chip (better than the GB!), so I’m not sure where your figures are coming from…
