I’m still working on the same project I’ve been hacking away at for years now. Didn’t have time to finish it for the 2013 compo, but who knows maybe another one will light a fire under me… 😉
Sorry, I must have missed the part where you clarified that it wasn’t the same across resets (fresh CPU and hardware state), in addition to being different across subsequent executions in the same program loop.
Is the output consistent across hardware resets? The V810 doesn’t have a RNG. There has to be *something* deterministically causing that undefined behavior. Not that I’m volunteering to find it… 😉
Very interesting indeed. Have you tried playing around with any of the unused/reserved areas of the memory mapped registers? I’m not-so-secretly hoping there’s a writable flag somewhere that the VIP checks to determine whether or not to swap/clear the frame buffers each frame.
Short answer is yes it is compiler-dependent. At least, GCC 4 reserves r3 for the stack pointer, and the remaining registers in the range r1-r5 save for r2 are set aside for internal uses. As I look at the v810 patch, r11 may also be used for long jumps, but I’ve never seen that code generated in my own projects. r30 might cause a problem with bitstring instructions depending on what compiler you’re using– you can either disable the frame pointer using -fomit-frame-pointer or just use GCC 4 where it’s patched to use r25 as the frame pointer. 🙂
There is no “OS” built into the system, nor is there a “heap” (unless you implement one)– Whatever code you write is all that it runs. I personally have my own crt0.s that does nothing but initialize the stack, data and bss sections; the rest is handled in my C code. If you don’t have any interrupts firing though, then I would say feel free to use any register you want other than r3 and I believe r31, since it’s used as the link pointer for returning from the jal instruction.
Caveat emptor; it’s been a while since I’ve done any VB coding. Maybe dasi or DogP can chime in with some insight. 😉
Just chiming in here– IMO this is solving a problem that doesn’t exist. Currently there are no games (or flash cart hardware for that matter) that make use of the expansion RAM, and until there are, we’re putting the cart before the horse by designing a file format that we don’t even know how it will be used. Like Tauwasser hinted at, VB games already know what hardware is used just by virtue of what the code does– if the code talks to SRAM, then it uses the SRAM; if the code talks to the link port, then it uses the link port; etc.
No need to overengineer a special format describing “mappers” or other capabilities when such things are merely hypothetical right now. Just stick with the straight ROM images.
Display unit at Toys ‘R’ Us, back probably around 1996, because it was right on the cusp of when the N64 was about to be released. There were (original) Game Boy displays, N64, SNES, PS1, and Saturn kiosks set up. Every once in a while you’d see a Pico too. *rolls eyes*
I joined PVB in 2007 while in college, after lurking for a couple of years. Had just bought my first VB off of a childhood friend of mine and thought it would be fun to develop for. Back when David Tucker and Alberto would still pop in every once in a while… 😉
The way the VB is designed, you’re supposed to hold the controller *behind* the stand, almost like you’re hugging the VB as you play. When the stand is backwards it makes holding the controller that way difficult to do comfortably.
“In 1995, the videogame market was literally packed with options, so it is no surprise that Nintendo’s unusual Virtual Boy system came and went in a flash. A standalone console, the Virtual Boy features a red and black display with impressive built-in 3D capabilities, if you can get through more than 15 minutes without a migraine! Seriously, we love the Virtual Boy, which will always hold a place in the history of videogaming.”
Mine is written in Objective-C++/Cocoa, so you’re only going to be able to compile it on a Mac. 😉 The VSU and audio engine parts are written in C++ though, so really only the GUI part would have to be rewritten.
Even though I cautiously left space in the GUI for it in the lower right, I didn’t port over your entire vb_snd_gen, just the part that generates the audio. I modified it to generate it on the fly, since my primary motivation was to play around with the noise channel in order to find register values of percussion sounds I liked for my music engine. Creating files and playing them back simply took too long. 😉 I pretty much took inspiration from this mock screenshot http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=9560#forumpost9560 but stopped short of porting over the sequencer/code generation aspect of what you did, since I didn’t need that. 😛
The waveform-based emulation code is pretty accurate to my ears, down to the aliasing artifacts– haven’t done a wave-to-wave analysis vs. the hardware though. Verdict is still out on the noise channel, after also messing with it in Mednafen. Will have to try on hardware soon. However I’m still not sure how “interval” actually works, since both in that generator and in my own experiments writing for the VSU, all I get is silence. I must be doing something wrong.
affection wrote:
Do you think I could use the Flash memory from the FlashBoy to off load some of the files from RAM? Also is there any VRAM in the VB or does it just use the normal RAM for graphics?
If you include the OAM area, which is shared between the graphics processor and the CPU, then the VB has a grand total of almost 200K of usable RAM, but this area of memory is physically located elsewhere on the motherboard and isn’t as fast as the WRAM (http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=5369&forum=2) The Flash memory on the FlashBoy is an EEPROM which is programmed using the FlashBoy software on a Windows PC. Once programmed it’s no different than ROM to the VB itself. A good idea as mentioned in my previous post is to precompile graphics and lookup tables into ROM, rather than generating them dynamically in the sparse RAM, especially if they’re static once created.
affection wrote:
We know that the Virtual Boy is’t a powerhouse but our own programming langauge called ‘CrystalScript’ cuts out alot of hassle over high level programming langauges have, by still allowing some low level features such as memory allocation so you still have the control and better optimation than most high level languages.
The Virtual Boy with an unmodified original FlashBoy has only 64KB of working RAM– 8KB of additional SRAM if you have a FlashBoy+. A generic memory allocator with its required overhead probably would have little use within such boundaries. Most games I see try to use statically allocated RAM (usually just temporarily) and try to offload generation of things like LUTs and other data to the compile phase, rather than at runtime, to take advantage of the comparatively ample ROM space.
Unless you’re just learning the basics or making a very simple game, the VB really isn’t the place for high-level “scripting” languages. If you want to make a serious VB game, using C and dropping down to V810 assembly in critical sections is the only practical way to do it. The community’s biggest struggle within the past few years has been getting our toolchain cleaned up and modernized from an ancient version of GCC 2 built back in the mid 90s.
Now what we’re most happy about over here is the the compiler we’ve created, it isn’t like C where the compiler is Trans-compiled, our language is compiled using a technique called Machine code generation, that compiles staight to Binary without steping down to an other language.
So… you created the equivalent of GCC? 😛 (I kid, I kid)
I’m not an expert on the hardware, but it’d definitely be a nontrivial effort at best. Each VB display is actually a single column of 224 pixels, reflected off a mirror that is oscillated back and forth to produce the full image you see when looking into the unit. The mirror servos are driven by custom Nintendo chips so you would basically have to recreate that hardware from scratch.
Doing it in software might be more feasible if you wrote a video player for the VB that looks for video information in cartridge RAM. A lightweight codec like Cinepak might work for this purpose. But even then you’d have to mod the cartridge to allow for an external hookup and possibly a buffer, and that would also be an involved effort.
I wouldn’t jump to conclusions so quickly… the commercially released ROMs topped out at 2MB, but the VB itself can address well more than that in the cartridge address space. Personally I have plans for much larger games given enough space and cartridge hardware to support it.
