I love the hardware architecture. From the CPU choice and modifications, to the memory layout, to the interfaces of the custom chips, its a masterpiece.
Benjamin Stevens wrote:
Yes, the history given in this article is excellent. Overall, the article is well-researched and well-written, and it even gives a good mention of Planet Virtual Boy, which is nice to see.
Now, the article just needs a little bit of Photoshop work done on it, to get the text more parallel with one’s computer screen. 😉
I’ll do ya one better (see attachment).
I agree; very nice article. Not the standard “here’s why the VB sucks” boilerplate that 99% of other articles offer as “journalism”. Kind of interesting that it was almost a Sony product 🙂
One possible nitpick: he says the prototype was called “VR3D”. I’m not 100% sure, but I think that should be “VR32”. Other than that, not too shabby.
Yeti_dude wrote:
Yea, I dunno how much assembly programming is needed for developing homebrew with VB, but I figure it can’t hurt to know about that stuff. At the very least, my learned from my class how to make procedures in assembly and then use them in C programs.
That’s a handy skill to have…
Are you more familiar with Intel (x86) or AT&T (gcc) asm syntax? I’ve only dabbled in x86 assembly, so I don’t have the Intel syntax baggage, which probably makes it easier to study the V810 architecture (which differs quite a bit from that of the x86).
I’ve gotten VIDE set up and I’m beginning to mess with some of the demos. What I’d really like to do is learn more about the virtual boy rom file types.
I’m not sure what you mean… There’s only one ROM file format for the VB. It’s just a straight dump of the contents of the ROM chip. The layout of said dump is pretty simple, too: it’s just a big chunk of code and data with a fixed-size header stuck on, at the very end of which is the interrupt jump-table.
Specifically I’d like to be able to compile the VBgcc stuff and look at assembly output for it, but I don’t know if that is possible.
That’s an easy one:
v810-objdump -d main.o > main.s
I’m just gonna keep looking through the VBgcc headers and reading the programming guides to learn more about the VB and how games operate on it.
Sounds like a plan. Be sure to check the Wiki and ask questions here if something is unclear.
Thanks for the welcoming post!
And thank you for taking the time to see what makes our little red outcast tick. The more experienced programmers we have, the bigger the VB library will grow!
Yeti_dude wrote:
I just finished a systems programming class at college where we used assmebly programming. It looks like most programming for VB is done in C with a little bit of assembly. I feel pretty comfortable interfacing both of these now so I think that means I’m ready to start tinkering with VB programming.
Actually, at this point, most things can be done without touching asm. However, if you want to upgrade or add to the standard library with some speedy/tiny asm code, I for one would appreciate it (especially if it has good comments)!
Any suggestions for first (easy) projects? I’m still a little unsure of how game logic works or how the display is created with worlds and sprite, etc… I’ve read most of the documentation on programming for the VB and I guess at this point I should dive in to other people’s code to get a feel for how these games are structured. Anyone’s advice on how to get started from where I am would be greatly appreciated!
Just do some tests to get used to the graphics (sound, etc.) hardware. My first few programs were “hello world” programs to mess with the graphics stuff. When you want to start a real project, if you don’t have any good ideas of your own, just pick some game you really like and make your own version.
Hate to break it to you, In3D, but there never really was a “Reality Boy Team”. The last person to work on it at all was DogP (he added the current networking support) and that was upwards of a year (or two?) ago…
AFAIK, the only VB emulator in active development is the 9.x branch of Mednafen, and (again, AFAIK) it doesn’t even have the current networking support (although it would probably not be too hard to add).
That being said, there’s really no reason the feature can’t be added to any of the existing emulators. All of them but ViBE (?) are open-source, after all.
RunnerPack wrote:
Assuming you know something about how to read code, getting a GC toolchain and libraries installed is probably a good first step. devkitPPC is a good choice (it’s likely what the WiiMednafen developer is using). Building and running some kind of GC demo code will make sure all your tools work and libraries are installed.
I think I’m gonna go with option 2, but I don’t have my SD Media Launcher yet so in order to try the demo code I would have to use an emu. Is that OK?
It’s okay with me if it’s okay with you 😉
The only problem with using an emu is that, even if it doesn’t run, that doesn’t necessarily mean the game/demo is broken. On the other hand, most developers probably target an emulator during most of the coding process, for convenience, so most things probably work fine.
in3D wrote:
So where should I start? (If this is gonna be too hard for someone with no dev experience, please say so!)
First of all, you’re the only one who can determine if something is “too hard”. People with “dev experience” didn’t always have it. Said experience has to come from somewhere, so why not from porting Mednafen to GC? 🙂
That being said, if you can’t read C code at all, this is going to be a very long process. You may want to read some C tutorials first.
Assuming you know something about how to read code, getting a GC toolchain and libraries installed is probably a good first step. devkitPPC is a good choice (it’s likely what the WiiMednafen developer is using). Building and running some kind of GC demo code will make sure all your tools work and libraries are installed.
At this point, you have two choices: 1) Get the latest Mednafen WIP sources and port it to GC, as was done with WiiMednafen for the Wii, or 2) get the WiiMednafen code and port that.
If you go with #1, you have to use GC-compatible libraries for things like graphics and sound, and convert all the function calls accordingly.
Option #2 is just a matter of replacing Wii code with equivalent GC code. This is going to take lots of study time with the Wii and GC developer docs. You probably won’t find a “How to Port Wii Code to Gamecube” tutorial, but maybe you can find the reverse and… reverse it 😛
Either of these two options is going to take a lot of work and time, especially if you’re inexperienced. It’ll be a great learning experience, but it you’re only concerned about the final product, you may be better off changing your plans to include a used Wii in place of the Gamecube…
It would be a better idea to start with the Wiirtualboy source or the full Wii Mednafen source. You’ll get more-compatible (and probably faster) emulation and it’s already very close to GC-compatible code.
Yeah, but I meant that it would be easier for him to start with one of those than the first thing I linked to. But I’m sure he knows what would be the best place to start, assuming he knows or finds out that the VB pad is essentially an SNES pad with extra buttons.
I took a look at the code for the “x2wii” to see if I could do it, but I have absolutely no experience with AVR assembly. I was able to figure out how the GC data packet was built, but not enough to see how to add conversion of the right D-pad to the C stick directions…
Anyway… I hope he adds it soon, because I would like to get/make one of his “Multiuse tiny 1” boards and use it for Wii Mednafen (among other things).
Unlike Windows/DOS, Linux doesn’t search for executables in the current directory. Try qualifying the filename, like so:
./rboy_linux bh.vb -dspmode side -flip -palette red
You might also try:
make install
To see if it installs the executable somewhere in the executable search path, which should allow you to run it from any directory using a command-line similar to what you’ve already tried.
in3D wrote:
Does anyone know if it’s possible to make an adapter that would allow hooking a VB controller to a GameCube? The tricky part is that the VB controller has batteries, so maybe taking apart a wavebird would work because it’s designed for AC power.
The battery pack is almost completely separate from the actual controller (except for the battery meter) so it doesn’t need any special consideration.
As far as the actual conversion goes, this guy could make it happen in a few minutes:
The thing I linked to outputs N64 signals, but the N64 and GC use the same hardware protocol, so conversion would be simple. He also has SNES/NES/VB pad reading down for his USB adapter, so again, trivial to implement. He does sell small microcontroller boards for this purpose, so it would be a simple matter of wiring and firmware.
All you have to do is convince him that it’s worth his time (say, by ordering four of them) and he’d probably whip some up for you. It’s worth a shot, anyway…
