I really don’t know anything about the counter version, but if it has the same screws as the regular VB and holes no deeper than 3 inches or so it should work.
DanB wrote:
There is no general requirement to pad them up to 16 megabit. That size is only chosen because of the size of the flashboy and other home made flash carts are that big.
That is the one. The 4.5 security key fits the system screws, but it is too large for the game cartridge screws. So when I ordered I bought one of the 4.5 bits and also one of the 3.8 bits for cartridges.
To give you an idea of the size of the 4.5 bit, it sticks out roughly 1 inch from the deep holes of the VB (after a small amount of grinding, as mentioned above).
I got the bit last night. It was long enough for all but the 4 deepest screws. And when I tried to shove it into the deep holes it got caught on the hex end. So I grinded down half of the hex end with the dremel and eventually I got it to fit without having to make a slot in the end of the bit. So I can use it with my hex screwdriver and I got all the screws out of the VB.
So yeah, I can recommend the bit posted earlier in this thread, but you WILL have to grind down the end a little bit.
Also, the advice about tightening the screws before loosening them was brilliant! I was able to tighten them slightly until I heard a “crack” and then easily unscrew each one. Otherwise it was very hard to unscrew them.
I tried fixing my glitchy display last night using the solder-only method and I think I only made it worse! My solder skills are very high, and I can solder 0603 surface mount parts by hand. But this solder job is even harder than that, and you basically WILL need a microscope/magnifier or at the very least a very bright and clean workspace.
The solder is extremely hard to get off once you get it on and melt the adhesive. The iron has to be very hot to heat up the solder and wick, but also not too hot so that the traces get moved. I’m extremely frustrated with this stupid flat cable, and I’m very close to just taking it off and soldering hard wires to the connections. I’m going to give it another shot today at my work’s solder station, which has much better equipment and a magnifier, but I’m not optimistic. I feel like I may have ruined my VB!
When they’re padded they each take up 16 megabits (commercial and homebrew), BUT I might be able to get around this in firmware. I haven’t decided how I’m going to handle it yet.
svenk91 wrote:
Why not make a flashcart that has an internal 128MB micro-SD card and card reader?
128MB is more then enough since the biggest commercial games are only 2MB and it comes eve ncheaper if you buy them for all flashcarts at once. Plus you can build in the card reader so you still have only a usb port for those that don’t have a (micro) SD card reader.
And if for some reason (secret storage or something :question: ) you really need more space you can open up the flashcart and replace the micro-sd card anyway.
You’d probably still need some flash the VB loads from directly because the VB can’t know what to load on the micro-SD card. And the menu you need to have on that flash that loads games from the SD-card will most likely be the hardest to make.
I know the guys over at neoflash have done such a menu for the N64 and are busy making it for their snes card (SD card reading). It’s open source so maybe you can learn how they did it if any of these consoles is similar to the VB.
Thanks for the tip on neoflash, I’ll have to check out what they’re doing.
There’s no point in using a 128 MB card because you wouldn’t be able to store all your roms on there.
The VB would most likely ruin a chip that runs at 3.3V. The only possibility would be a chip that runs at 3.3V but has 5V tolerant inputs. But those are just as rare as the 5V chips so it doesn’t help.
The only way to get around using some kind of flash/RAM would be to right a routine in my micro that interprets the VB address requests, fetches the corresponding word from the SD card, and places it on the address bus. But I haven’t figured out yet if my micro will be fast enough to do that.
RunnerPack wrote:
Well, that was my point: you don’t have to use flash. The DS carts (I believe) translate back and forth between the DS cartridge interface and the SD card interface, in real-time (with varying degrees of success).
I don’t know how difficult this would be on the VB, but probably no more so than for the DS, and probably less, given an FPGA or ASIC with enough I/O and space for FIFO buffers. And if Vaughanabe13 can do it for $6-$7 per unit, I’d buy at least two of ’em! 😀
First of all, there is absolutely NO way anyone could design, build and sell a programmable VB cartridge for that amount of money. With the DS you have a ton of companies that can just churn out those multicarts in China somewhere in bulk, and that’s why they sell so low. With the VB there are more problems than just what microprocessor to use. You have to take into account the cartridge design, and if you use donor cartridges you have to spend hours removing the components from the donor to use on the flash cart.
I’m not using a flash chip. They’re slow, expensive, and you can’t find any them anywhere except crooked NOS chip suppliers that charge 10x more than they’re worth. I’m using SRAM, probably 16 megabits, which is large enough to hold all VB games, AFAIK.
KR155E, the VB can only address up to 128 megabits, and there is no way to get around that. That being said, finding a 128 megabit flash or really any kind of volatile or nonvolatile 5V ram is impossible. If they do [still] exist, they would be really expensive, since there are much better modern alternatives.
Runnerpack, what’s the point of having a microSD card, you ask?
1) Store every game you own on the card at once and never have to take the cartridge out of the system or connect to your computer.
2) Be able to select what game you want to play via bootloader.
3) Tons of space for homebrew.
4) My design doesn’t use slow flash memory that takes minutes at a time to transfer one game.
5) MicroSD is extremely common and cheap these days. Heck, you can get a 1GB card for $5 USD if you know where to look. And almost every MicroSD card comes with an SD adapter, and just about every laptop manufactured today has a built in multi-card reader. Or you can buy a USB card reader for another 5 bucks. Not to mention many electronic gadgets use MicroSD for storage, like almost every phone that has an external memory slot. So no, it’s not expensive at all and very common.
Also, I did some research and I don’t think it would be possible to translate the ROM data in real time between the VB and SD memory (like a DS multicart), so I’m not going to design it that way. I could do it if I had the full SD protocol, but I would rather not pay thousands of dollars in royalties to Secure Digital. Companies can do that for their designs. I can’t.
Also, I’m just doing this for fun and because there is only so long the Flashboy design will be able to sustain itself, with the rarity of the flash chips and all. If you don’t want to buy one, nobody is forcing you to. And what am I saying, I’m getting way ahead of myself saying that this is something that would eventually be sold. My project is still in the planning stages anyway so it’s probably best if I don’t even talk about it on the forum anymore.
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.
It’s not about “new versus old” it’s about the horrible job Microsoft has done handling Internet Explorer, since back in the day when any novice programmer could create a dangerous exploit in IE. Sorry if I offended you, that wasn’t my intention.
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
