Weird… yours comes up to a screen when you turn it on? Mine never actually showed anything on the screen. I’m not sure where the test software would be on the debugger… there was an EPROM, but I never dumped it… but I wouldn’t think that was a test program since IIRC it was only a single 8 bit chip (which the CPU wouldn’t be able to execute natively).
Yeah, that was the first type that I got. IMO it’s better than the official Nintendo one since it’s less clunky and you don’t have to worry about the power plug falling out of the tap.
Yup… congrats! I was gonna bid since it’s totally worth that, but I didn’t want to screw you out of more money (since you probably bid more that I would have), and you actually need it for your kit 😛 .
Have you tried the gccVB from David Tucker’s site? I’ve never tried using Dev-C++ with any compiler other than mingw, but I remember DT saying something about his gccVB allowing it to compile multiple c files instead of only being able to do a single c file (or with everything #include’d). That could be the cause of “too many arguments” if it’s trying to compile multiple c files. Also, don’t forget, there is no c++ in gccVB.
Yeah, I’ve had the idea for a long time, but I was never really interested in doing it since it requires a lot more than a simple flash cart… and the only way it seems like it’ll be worth the hassle is if it’s able to boot directly off the CF card (which I’m still working on).
Otherwise I’ll probably change to a different technology like SD and just make the I/O 5V tolerant and add a 3.3V regulator to the cart. The PCB routing is ugly w/ a CF socket, Flash, and SRAM… fewer wires w/ a serial device would make that much easier, plus the size is much smaller.
I’ve never looked at how the Yeti engine works… I guess I was thinking it already displayed in real 3D, but it could be just a 2D port at the moment… it’s been a long time since I’ve seen it.
That’s not a Dev Kit by itself… it’s just the display that connects to the Dev Kit. But no… the hardware inside the dev kit display is totally different than the regular VB (since it’s just a display, not a full system).
Yeah, I’m sure it can do polygons… it’d need a very efficient 3D engine, but like you said, there’s the demo, and since the video is double-buffered, it could definately do it, but the frame rate may be slow.
DanB actually ported the GBA Yeti 3D engine… it’s REALLY slow, but with a lot of optimization and rewriting some of it in ASM, it might actually be usable.
Well, only one game could be loaded onto the onboard flash, but you could have as many games as you can fit onto a CF card on the card itself. The loader would just read the file from the CF card and load it into the flash, then just load the game like it was a normal flash cart.
I haven’t gotten the PCB layout totally figured out yet, but I’m hoping to be able to have the CF socket fully inside the cart, but the card will probably stick out a little bit (but the CF card is only needed to load the game, so it could be removed after flashing if you wanted).
I’ve actually got some chips that’d be perfect for saving space if I go with more than a 2 layer PCB with tight tolerances (it’s a BGA chip)… they’re only 8mbit though, so again they wouldn’t play the 16 mbit games unless I used two chips… which would be pretty ugly since they’re 16 bit only chips (no byte mode). I’ll probably end up using some 16 mbit chips though, and hopefully be able to stick with a 2 layer PCB.
With SD, it’ll remain a dream 😛 . There’s a few reasons… the first is because SD is a 3.3V device, the VB is 5V. Also, you’ll need a seperate flash or SRAM to load the current game into, since the IO of the VB requires parallel data, not serial like SD. You’ll also need seperate SRAM to save (once again, because it writes parallel), and you’ll need somewhere it can boot from at startup.
I’m actually working on a cart right now that uses CompactFlash. It’s not as nice as SD since it’s a lot bigger, but it’ll run at 5V or 3.3V, it’s a 16 bit parallel device, and it’s relatively easy to interface with. What I’m trying to do is get it so you can boot directly from the CF card (it’s split into 4KB blocks, so at reset it goes back to the first block, which I can have my code execute from). This can be a very small driver that just loads the WRAM with a loader to read the games from the CF card. The problem is being able to have the loader there and still have the card readable by the PC (which could be solved by making a PC app to put it in my own format, but that’s not as user friendly). Then in the boot menu, read the ROM file and flash it to the onboard flash.
It’d also be nice to have SRAM, which I could do, and have the loader copy the SRAM to a file on the CF when it loads a new game, that way the high scores, save games, etc could be preserved, and the new game could do whatever it wants to the SRAM.
Hmm… I just took the original screw with me to the hardware store and bought the closest size. Every screw they had was a little bit too long and had a pointed tip, so I just cut it to the correct length with a dremel. The width and thread of the screw was the same though.
Well if you look really closely, I think you can sorta see a bubble in the case (at the bottom), which I seem to remember Game Gear cases having. I’ve got a GG w/ cases around here somewhere, I’ll have to check it out.
Actually, I think that is a Game Gear cartridge case… I don’t think anyone actually made a VB cart case, but I seem to remember someone saying that VB games fit in Game Gear cart cases.
Yeah, I agree w/ KR155E… the VB community has always been small, but I think it’s actually growing more popular than it has been. The dev scene has definately been quiet though 🙁 . I’ve actually been doing a lot of dev recently, but nothing exciting for me to talk about yet :/ .
Heh, well if you think about it, I’m sure it’s been dumped, or about to be… If the person he got it from is crazy enough to send an original prototype through the mail, it’s going to be on an EPROM, and KR155E has an EPROM reader, so consider it dumped 😉 . If it’s not an original, he can probably still dump it, but then of course it was dumped before he got it.
Either way, I can almost guarantee you that the ROM won’t be released… if someone was to sell the game, It’d easily go for several thousand $$$… and remember that there still aren’t freely available dumps of the rare Japanese games, which some of them only go for a few hundred bucks.
There are several other VB protos out there, but unfortunately not enough 😛 . I REALLY want to see Zero Racers though 🙂 .
I assume you know that the controller/power supply are good? It sounds like it’s not getting power if you don’t see anything happen. If you know the power is good, there’s probably nothing you can do unless you open it up and check for voltage. Inside, on the top of the board there’s a vertical black blob sorta thing which is the DC->DC power supply.
When you turn the system on, you should see a red light shine through the black blob. If you don’t see that, I dunno what would cause that, but it could be a bad connection or a bad DC->DC supply.
That’s pretty much how I had originally planned on doing it… I’ve found quite a few problems with that though. First, you’re gonna need to completely reverse engineer how the displays work. I hooked the displays up to my logic analyzer, and although how it works seems to be pretty simple, it appears to be VERY timing dependant. I have some notes somewhere on what I found with the displays, but IIRC it’s a nasty combination of serial and parallel output, and not really clocked.
IIRC the brightness was PWM, and I think the display was split up into parallel sections, where those pixels were output serially. It might have been something like split into several parallel pixel sections, where the pixels in each section were output serially and brightness was PWM, but also parallel (the only reason I’m thinking this is because when the cables start to get flaky, a lot of times it seems to only affect certain brightness levels).
IIRC an entire display period is 20ms. 5ms is used for the left eye, then there’s 5ms of nothing, then 5ms for the right eye, then 5ms of nothing (and repeat). That gives the overall refresh rate of 50Hz. Also, both the left and right displays are completely connected except for a single L/R display select.
Anyway, I don’t remember how much parallel stuff there was, but IIRC there’s 30 wires, several of which are power, and one is the select, so lets just take a guess and say the display is split into 14 sections of 16 pixels each. To draw a display, we need 16 pixel cycles per column, and 384 columns. Assuming there’s no blanking time between columns, we need 1/6144th of a 5ms cycle for a pixel. That means that a single pixel is about 0.8us. And 14 of them will be happening concurrently. Now if this is PWM, it will be VERY hard to determine to any sort of precision whether this is a light or a dark pixel (you’d have to use a good input capture… er… 14 of them). Then in a really short amount of time store that data in memory and begin reading the next outputs. If you could accomplish that, converting to the TV output wouldn’t be that bad since it could be done during the 5ms of nothing between display outputs (to go from vertical to horizontal, you could just make a copy of the entire memory to another block of memory rotated). If it was fast enough to be able to capture the display output, it should be fast enough to copy a bunch of memory.
Also, I know the timing isn’t identical throughout the cycle, since the swing of the mirror would cause a distorted image… either narrower or wider depending on the direction that the mirror is moving. So, you’d need to take that into account, and I think since the on time of the display can be longer or shorter because of the mirror position, the processor also increases/decreases the brightness to make it appear even across the display. So, that’s another thing you’d need to take into consideration.
You may want to check the patent for some details on the display, and I’ll try to dig up the notes I took on them, but I really think converting directly from the display output is a very tough solution. It’d at least require a pretty powerful and fast microcontroller. Of course I don’t want to discourage you from experimenting, I just wanted to give you some feedback on what I’ve looked at, and hopefully you can figure out a way around the problems.
The way I’m thinking of doing it now is basically tapping the framebuffer memory. By watching the activity on this memory, you can copy it by writing the data of the section read to a seperate copy stored. A seperate copy would be needed to make sure that you don’t interfere with any manipulation of the original when you’re reading it to output to a display. The nice thing about this way is that you’ll get the exact data stored in it’s original digital format, not converted to a pulse width, and then converted back. There are 4 framebuffers, L0, L1, R0, and R1. Each are 32KB each.
This way also has some problems though. For one, you know the relative brightness (whether it’s a 0, 1, 2, or 3), but you don’t know the absolute brightnesses which are stored in the brightness registers unless you also tap that memory (which is doable, but it may also be okay to manually control the brightness levels). Also, it would need a pretty fast processor to capture data writes if the processor was to handle this, but the way I think I’d do it is to basically add another chunk of memory in parallel with the existing framebuffer memory. I’d need to put a unidirectional buffer on it though to make sure that the memory would get the data when the framebuffer is written to, but not write to the VB data bus when my processor reads the data. By having the memory basically piggybacked, that would take a huge load off my processor, and I could probably use a simple microcontroller to periodically read my copy of the framebuffer and output this to the display (probably synced with the output periods of the display to ensure that the framebuffer has the correct data). That’s the other problem… The VB has two framebuffers per display. I don’t necessarily know which framebuffer is the active one without tapping that memory too.
Or, you could take two cameras and change one’s color to blue, overlay them, and output that to your TV :p .
