For those of you who know about the VB hardware, I have some important questions for the project I’m working on.

What does the VB do right after you turn on the power? There seems to be a delay between when I turn the power on and when I actually see the first game screen, so the CPU must run some self-initializing code before it reads data from the flash chip on the cartridge, correct? Does anyone know how the VB accesses the program instructions from the cartridge memory and how long it takes between power-on and the first instruction read? This could be determined by knowing how many instructions the VB executes during initialization and the operating speed of the CPU, but I don’t know either of these.

Also, what does the VB do when it tries to read data from a cartridge and there is nothing in the cartridge memory? Will it keep trying to read code from the memory until it can start executing instructions, or will the CPU just shut down until you turn the power off and back on again?

Basically, any information about the stuff I just talked about would be helpful. This is really the only missing link in the project I’m working on, and I need to figure some of these things out to see if my idea will be possible. Thanks! 😀

Hey! I can’t really help you with technical things, but I have noticed the delay (4-6 seconds until sound or picture appears) when you turn the power on. My first thought was it is caused by the starting engine inside the VB. When you turn it on, you can hear and fell it working.

But there is one VB game, where the sound already starts 1/2 second after power on the system: Virtual League Baseball/Virtual Pro Yakyuu ’95.

Maybe it is helpful for you 😉

I know some time is spent adjusting the velocity of the vibrating mirrors when you first power the unit on, so that is part of the delay. Thanks for the tip on virtual league baseball, I’ll boot it up when I get home and see if I can get some crude measurements.

AFAIK, the CPU starts immediately after the “power good” signal from the on-board voltage regulator releases the reset line. The delay you see in most commercial software is probably just an aesthetic choice by the developers to wait until the mirror motor is up to speed before displaying anything. As SNK observed, some games start the sound almost immediately, so there is probably very little noticeable delay.

Also, the “PSRAM” (pseudo-SRAM) used by the VB requires a 200us delay before it can be used, although this obviously couldn’t be detected by a human.

Since the cart data lines are likely to float high, the VB would probably read 0xFFFF with no cart inserted (although it would technically be “undermined” and could change at any time because of spurious EM fields, gamma rays, pixie-dust, etc. ;-)). Since this is an invalid opcode for the NVC, it would probably try to jump to the default “invalid opcode” exception handler (if there is one), which would also fail. It would basically lock up the VB until it was physically reset.

Does that about cover it? I assume this has something to do with your flash cart boot loader, right? I’m very interested in that project, although I probably won’t have the funds to get one, at least for a while.

RunnerPack wrote:
AFAIK, the CPU starts immediately after the “power good” signal from the on-board voltage regulator releases the reset line. The delay you see in most commercial software is probably just an aesthetic choice by the developers to wait until the mirror motor is up to speed before displaying anything. As SNK observed, some games start the sound almost immediately, so there is probably very little noticeable delay.

Also, the “PSRAM” (pseudo-SRAM) used by the VB requires a 200us delay before it can be used, although this obviously couldn’t be detected by a human.

Since the cart data lines are likely to float high, the VB would probably read 0xFFFF with no cart inserted (although it would technically be “undermined” and could change at any time because of spurious EM fields, gamma rays, pixie-dust, etc. ;-)). Since this is an invalid opcode for the NVC, it would probably try to jump to the default “invalid opcode” exception handler (if there is one), which would also fail. It would basically lock up the VB until it was physically reset.

Does that about cover it? I assume this has something to do with your flash cart boot loader, right? I’m very interested in that project, although I probably won’t have the funds to get one, at least for a while.

This is excellent information here! I have a few questions. Is the PSRAM you are referring to part of the CPU architecture or are you referring to the RAM on a game cartridge?

I understand what you mean by the lines floating. I actually thought the lines would initially be at ground potential but I guess not.

What is the NVC? I haven’t read the programming manual/wiki for a while and I don’t remember what that stands for. I’m guessing it has something to do with the fetch/decode of the CPU pipeline?

So there is a reset line on the voltage regulator, but is there any other way to reset the system? Every CPU architecture I can think of has a way of “soft” resetting the CPU without losing power.
Honestly I think some of these questions I won’t be able to figure out until I can break out the cartridge pins to a breadboard and stick my logic analyzer on it. But I can’t do any of that until I fix my glitchy display problem, etc. etc.

Yes, this is for a flash cart idea I have been playing around with. I have some theories in my head about how to do this but I need to know as much as possible about the VB before I start investing significant funds in this project. I’m technically still a college student after all!

Vaughanabe13 wrote:
This is excellent information here! I have a few questions. Is the PSRAM you are referring to part of the CPU architecture or are you referring to the RAM on a game cartridge?

I understand what you mean by the lines floating. I actually thought the lines would initially be at ground potential but I guess not.

What is the NVC? I haven’t read the programming manual/wiki for a while and I don’t remember what that stands for. I’m guessing it has something to do with the fetch/decode of the CPU pipeline?

So there is a reset line on the voltage regulator, but is there any other way to reset the system? Every CPU architecture I can think of has a way of “soft” resetting the CPU without losing power.
Honestly I think some of these questions I won’t be able to figure out until I can break out the cartridge pins to a breadboard and stick my logic analyzer on it. But I can’t do any of that until I fix my glitchy display problem, etc. etc.

Yes, this is for a flash cart idea I have been playing around with. I have some theories in my head about how to do this but I need to know as much as possible about the VB before I start investing significant funds in this project. I’m technically still a college student after all!

1. The PSRAM is used as the “work” RAM in the VB. Like the RAM in a PC; used for variables and such. There’s 64KBytes to work with. Also, I guess I didn’t make it clear that the software on the cart is responsible for ensuring the 200us delay. It’s not automatic.

2. NVC means “Nintendo VUE CPU” I think. Anyway, it’s the customized v810 microcontroller that drives the VB.

3. To reset the CPU, you can just jump to the reset vector in the header (Guaranteed to be at 0xFFFF_FFF0, no matter the cart size). However, this won’t reset the peripherals to their default power-on state. I think DogP said it reboots with very quick shorts between the +5V and Gnd rails, but I don’t know how good that is for the health of the system 😛

4. DogP is the world leader in the field of veebology, so keep posting anything you need to know here and I’m sure he’ll reply sooner or later 😉

5. Believe me, I know what you mean about lack of time and funds…

>What does the VB do right after you turn on the power? There seems to be a delay between when I turn the power on and when I actually see the first game screen, so the CPU must run some self-initializing code before it reads data from the flash chip on the cartridge, correct? Does anyone know how the VB accesses the program instructions from the cartridge memory and how long it takes between power-on and the first instruction read?

After it comes out of reset, it begins executing the reset vector. Of course some games have an initialization, but that’s completely up to the game. You’ll notice delays in seeing anything, which is caused by the displays getting in sync. But that has nothing to do with the actual program. If you stop the mirrors during the game, the displays will also turn off. I believe that’s all controlled internally in the VPU.

>Also, what does the VB do when it tries to read data from a cartridge and there is nothing in the cartridge memory?

It’ll just try to execute whatever it reads… which like RunnerPack said, probably all high, but possibly something else… but nothing useful.

>Is the PSRAM you are referring to part of the CPU architecture or are you referring to the RAM on a game cartridge?

PSRAM is Pseudo SRAM, which is the Work RAM internal to the VB (RAM used for programs and stuff).

>What is the NVC? I haven’t read the programming manual/wiki for a while and I don’t remember what that stands for. I’m guessing it has something to do with the fetch/decode of the CPU pipeline?

Heh, you could say that… it’s the CPU 😉 .

>So there is a reset line on the voltage regulator, but is there any other way to reset the system? Every CPU architecture I can think of has a way of “soft” resetting the CPU without losing power.

Yeah, there’s a reset line, which is controlled by (at least) the power good pin on the regulator. Like I mentioned in the other thread, you can reset by jumping to the reset vector.

DogP