I have this (not original) idea of easily being able to play any game I’d like without having to connect it to my computer every time to change games…

The size of the VB games makes it uncomfortable to use plain eproms – at least if you want a low cost per MB and want to fit it in a standard sized cartridge shell.

I think using a microSD card would be a neat solution, imagine copying all the games you want onto a microSD card, put it in a cartridge and then select any game from a meny and start playing.

If there’s a new version of a homebrew or a brand new one, just move it to the card and put it back in the cart.

Any reasonably priced card would hold every last VB homebrew or different version of it.

There are these types of interfaces for other game systems – like the C64.
http://www.c64-wiki.com/index.php/SD2IEC

.. PowerPak for NES – although it’s using a CF-card instead.
http://www.retrousb.com/product_info.php?cPath=24&products_id=34

It should be even easier for the Virtual Boy!

As far as I have thought about it this is what is needed:
microSD card holder
voltage shifter to interface with the card
5V µP, either PIC or an Atmel ATmega
1Mb x 16Mbit ram (or eprom)

Operation:
At start up the µP copies a menu-program from the SD-card to the C-memory (Cartridge memory) and after that it resets – if a reset is possible hardwarewise from the cartridge port?

I don’t know what happens at startup, how much would be possible to do before VB starts reading at 0x07000000?
What happens if it tries to read but it cannot access it because it’s busy being written to? Does it wait or does it do something else?

Perhaps enough code to write a wait loop that would be copied to somewhere in the VB ram and then have it wait there while the rest of the code is copied to the C-memory?

So… at start-up the µP copies a tiny tiny “stall program” to C-memory in time for when the VB starts to reads from 0x07000000.

This small program then simply writes a waiting loop to VB ram and jumps there. The waiting program in VB ram also signals the µP in the cart to start copying the menu program to C-memory. When done it resets, or sends a signal so that the program in VB ram jumps to 0x07000000 and starts the menu-program… A reset would perhaps be best to start everything from scratch.

Copied to C-memory are also names of all the files on the card (all .vb files at least) and the menu program read these and presents a list of them that can be chosen.

Perhaps a write to the Expansion Area could be used to trig it the µP to do things – using only the /ES signal or maybe also read the data or part of it from the data line?

Does anyone know if the Expansion Area is accessed anytime during start-up?

The µP would have to do this:
At first start
copy small routine placed as data in the µP to C-memory
the data is a VB program that copies a loop to VB ram and
jumps to it

After that it waits for a signal to proceed (/ES, /ES + data ?)

Now VB runs the program in RAM, µP starts copying the data of menu.vbp from the microSD-card to C-memory.
After that it reads the names of all *.vb files on the card and copies their names to a certain address in the C-memory.
When done it initiates a reset or signals (via /INTCRO or by writing a certain value to a certain address that that program checks of the C-memory?) so that the program in VB RAM either jumps to 0x07000000 or resets.

While the user is in the menu, the µP waits for signal to copy a certain program. If /ES can be used several bytes of data can be shipped that way. When the µP is signaled it gets information on what file to copy and does so just like when copying the menu file.

µP then needs to do noting, it will start over as it looses power and is re powered

When in the menu there’s a little more time for a more interesting waiting program to be loaded into VB RAM while the game is copied from SD card to C-memory. Perhaps a tiny tiny game, a boring “Wait for program to load” animation, a text displaying “Wait” with rolling dots or a static text “Wait.”… When it’s loaded it could either just reset or ask for user input (press START). If there’s a minigame, asking for a key press is perhaps a good way to go.

So. Can a reset be initiated hardware wise from the cartridge? Is the /ES signal used on startup or in programs as far as anoyone knows?

Enough I/O pins on the µP is needed for the data as well as all adress and enable pins.

I think a better idea would be to have a small FlashROM with a boot-loader program on it, some SRAM or flash for the loaded ROM image, the SD card itself, and an optional microcontroller or programmable logic. All communication with the microcontroller or SD card would be through the Exp bus.

The VB would boot normally from the boot-loader flash and present a menu of some kind by accessing the microcontroller (or the SD card either directly or through programmable logic). A “please wait” program would also be loaded into WRAM to be called during the copying process.

When a program is selected, the VB goes to the “please wait” screen while the game is copied to the SRAM/Flash bank (this program may be doing the actual copying). The boot flash would be disabled by disconnecting its /OE pin from the VB and tying it high (it would need to be reconnected automatically on reset/power-up). When the copying is complete (the “please wait” program could poll some location in Exp to find out) the SRAM/Flash bank would be enabled (using the /OE just like the boot ROM, except disabled by default) and the loading program would jump to the reset vector like any normal VB ROM starting up.

It would also be possible to patch an exit function into the (ROM or source) code of a program to re-enable the boot-loader to allow loading a new program without power-cycling.

Some good ideas here. I thought about doing this myself. But then I realized how hard it would be. The concept is fairly straight forward but getting everything to work would be a nightmare. More power to you if you want to take on something like this, I’d be happy to help. Microcontrollers are my specialty

Well, if you do one little piece at the time it would eventually be done. There are finished routines for reading files from an SD card for various PIC and AVR processors…

Might I suggest using a PIC24F? You could get 16MIPS with the 8MHz internal clock and a 4x phase-lock-loop enabled. And the Microchip C32 compiler has some good file management libraries you could use for the micro SD card.

Go for it.

I don’t know anything about how the VB interfaces with a cartridge, how it reads memory from the ROM, any of the pinouts, and I haven’t done any VB programming (yet) so I wouldn’t be very good at this project.