For those of you expert VB programmers, is it possible to reset the VB from a software command? If not, is there any way to reset the VB without turning off the power switch? I know some CPU’s will reset if you make a brief connection between +5V power and ground – will that trick work with the VB?

Going along with this, I heard through the grape vine that it is possible to hotswap cartridges while the game is on. Anyone have information on that?

Vaughanabe13 wrote:
For those of you expert VB programmers, is it possible to reset the VB from a software command? If not, is there any way to reset the VB without turning off the power switch? I know some CPU’s will reset if you make a brief connection between +5V power and ground – will that trick work with the VB?

Going along with this, I heard through the grape vine that it is possible to hotswap cartridges while the game is on. Anyone have information on that?

At reset, the VB starts executing from the reset vector (0xFFFFFFF0), so simply jumping to address 0xFFFFFFF0 would reset, assuming you just want a program reset, not necessarily a CPU reset. Heh, shorting +5V to GND will certainly reset the processor, but I recommend against it, since it could also blow the regulator 😛 . You might as well use the power switch because you’re killing the output from the regulator.

Hot swapping is possible, though of course your program has to be running from RAM, and you have to make sure there’s no glitch on the address/data lines, since it’s shared with the rest of the system. IIRC, hot swapping carts with the backup battery doesn’t seem possible without modification, because one of the pins (pin 9 maybe?) causes the system to reset. Lifting one of the pins fixes that… I think pin 9, which must have caused an interrupt, resetting the program (I’d have to look back at my notes for all the specifics).

BTW, I got your PM and started to reply, but I’ll just fill in what hasn’t been answered already in your posts… probably better that the information is posted publicly anyway 🙂 .

DogP

[Vaughanabe13]

OK, here’s my take on the reset method by connecting the 5V rail directly to ground. I understand that it is not good for the VB hardware to do this, but this is how I would do it to prevent damage to the regulator or other electronics in the VB:

1) Connect an I/O pin of my micro to the base of an NPN transistor. Then I’ll connect the collector to 5V and the emitter to ground with a series current-limiting resistor. At all times the I/O pin will be at logic 0 and the transistor will be off, so it’s an open circuit with very little leakage current.
2) To reset the VB completely (thus going through all the initializations and program loading again), I simply output a logic 1 on the I/O line of the micro, which turns the transistor on and connects 5V to ground via the series resistor. This will create a small(ish) current between the 5V rail and ground, determined by the series resistor. The pulse is nearly instantaneous this way because as soon as the power goes down the micro also resets and thus the I/O line of the micro drops immediately to 0V, thereby turning off the transistor and instantly releasing the reset pulse. Then the VB boots up again. At speeds that fast and with a low-current pulse, I have a hard time believing the regulator would sustain any damage or get heated up at all. But again, this is just my theory and I have yet to test this.

What do you think, DogP? I’ll watch for your PM but like I said, I’m not in a hurry or anything.

Thanks for the tip on the reset vector though, that will definitely be useful at some point. I need to go back and read all the programmer info again.

• This reply was modified 14 years, 3 months ago by Vaughanabe13.

Heh… I think it’s a bad idea, and I don’t see why it’s necessary. Your resistor will have to be very low resistance and high power. I know the 5V rail can supply a steady 5V @ >500mA. To drag that down to brownout level, you’d need to draw probably ~2A. I’d guess the power supply would detect the power bad and reset the CPU before the CPU actually resets from low voltage (I’ve run the VB at 3.3V and the CPU works fine).

So, 2A on a 5V rail is 2.5 ohms, and 10W. Of course the voltage would drop, so it’d be less than 10W because it wouldn’t actually draw 2A… but you get the idea. And I’m sure that’s not good to repeatedly stress the regulator like that.

If you’re talking about just using a high value resistor between +5V and GND, that’ll just be a pointless heater 😉 . You’ll have to draw at least more than 500mA through the resistor.

There’s an interrupt line available on the cart edge, but to use it, you’d need to make sure it’s not already handled. If you modified the ROM when burning, you could use the EXT interrupt to jump to the reset vector, since the EXT area is basically unused. I have a VB that I modified with a switch there, and use it basically as a reset switch for homebrew.

DogP

I would also recommend against shorting the regulator. On top of the reasons DogP gave, there’s also the fact that you can’t guarantee your microcontroller pin won’t get stuck, keeping the transistor in conduction and probably blowing the regulator. In fact, don’t most uC I/O pins default to open-drain inputs with internal pull-ups?

You should probably just go with the /INTCRO pin and patched ROMs.

I guess my question was kind of loaded because basically what I’m getting at is I need to be able to reset the VB from the micro and not specifically from a ROM that the VB is reading. So it’s not as simple as writing a dummy ROM or modifying a ROM with the reset vector.

OK, I get your point about the short not being a good idea, I will have to think of something else.

I think what I will do is manually send the reset vector to the VB using my micro, by placing the reset vector on the data bus when it is time to reset. There’s something I need to know though (and it may have already been answered but I can’t remember). In the event that the VB powers up and there is no ROM data that it can execute, will it continue to try and read instructions from the flash, or will it freeze up and not do anything?

Anyway, this would work fine if there is no ROM data on the flash and the data pins are floating, however I will be interfacing with the flash and the VB will start to read garbage data from the flash at the same time it should read the reset vector from the micro.
So my next solution is to use a transistor as a buffer between the VB chip select line and the flash CS line. So I can control when the VB is reading instructions from the flash and when it is reading instructions directly from my microcontroller. Basically like a pseudo-mux.

Also for the record, when the micro resets the I/O pins become high-impedance inputs, and it doesn’t matter if they are open drain because there would be no pullup to 5V, so there’s no current to drive the transistor and the pin would be “off.” But I can see other reasons why this wouldn’t work, as pointed out by DogP.

DogP,

To refine my question: If I force the VB flash data bus to the reset vector on powerup, will the VB constantly reset->load reset vector->reset->load….etc until I put a real address on the data lines?

The pseudo code would be like this:

(powerup)
-Assert reset vector immediately on the VB data bus
-VB processor keeps loading the vector and resetting while I do other work. Power remains on at all times.
-When I’m ready, I remove the reset vector from the data bus and latch the first address of a ROM onto the data lines.
-The VB starts executing the ROM and continues as if it was just powered on with a cartridge inserted

So would that work?

Well… a CPU keeps executing whatever is handed to it, and keeps incrementing the PC… so that’s what’ll happen. Odds are it’ll just keep running away until it hits something that throws it off… like maybe a HALT command.

If you want to keep feeding it something, I’d either feed JMP $FFFFFFF0, so it keeps going back to the reset vector, or BR -2 to keep the PC from moving.

DogP

Shoot, I just realized this is going to be harder than I thought, since the VB reads 32-bit instructions. How does the VB normally grab one full instruction from ROM then? This is how I imagine it works:

1. Make /CS a logic 0 to enable ROM, and put address of first 16 bits of instruction on the address bus.
2. Make /OE a logic 0, which will cause the ROM to produce the first half of the instruction on the data bus.
3. VUE reads the bus into a buffer and makes /OE a logic 1 again.
4. VUE increments the address bus by one.
5. Make /OE a logic 0 again, so the ROM produces the next 16 bits of data on the bus.
6. VUE reads the bus into a buffer and assembles the data to form the complete 32-bit instruction.
7. Repeat

Is that how it works? If not, could you modify my steps to show how it reads instructions from the program memory? I realize my questions are getting off-top and this is more of a running dialog than specifically talking about the question in the title of the thread. Sorry if this is confusing.

Yep… that’s pretty much it, though not all instructions are 32 bit. Some instructions are 16, some are 32, and since there’s a 16 bit bus, it just reads 16 bits at a time and either executes the instruction, or knows that it’s 32 bits and reads the last half of the instruction, then executes that.

DogP

Vaughanabe13, you might find some useful info in this old thread:

http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=2937

Thanks, I’ll read through it.

Hey DogP, I sent you a long PM just now. I’d appreciate it if you could read through at some point and send me your opinions.