I think that URL contains erroneous information (it’s quite old). For one thing, it doesn’t indicate how the /OE pins need to be wired; if you don’t have those hooked up, you’re not going to get anything on the cartridge bus. Going by what https://www.projectvb.com/vb/tech/cartpinout.html says, I think what you’re looking for is the following:
Pin 3 on the edge connector is the /WE pin for the “RAM” area on the cart.
Pin 6 on the edge connector is the /CS pin likewise.
Pin 7 on the edge connector is the /RESET pin from the V810 CPU.
Pin 3 on the edge connector should be wired to 27 (/WE) on U2. Pin 27 on U2 is active low, so when pin 3 on the edge connector goes low, /WE goes low (active) on the RAM chip,
Pin 6 on the edge connector should be wired to pin 20 (/CS1) on U2. Pin 20 on U2 is active low, so when pin 6 on the edge connector goes low, /CS1 goes low (active) on the RAM chip.
Pin 7 on the edge connector should be wired to pin 26 (CS2) on U2.
The V810’s /RESET pin is active low, so according to the datasheet for the HY6264A SRAM chip, the above pin assignments mean that CS2 should be active as long as the VB is running, i.e. the SRAM chip is enabled during normal operation. Pins 3 and 6 enable writing to SRAM when both are low. The aforementioned datasheet suggests that /CS1 should go low before /WE, but I don’t know how the VB actually behaves in that respect.
Both run at 60 Hz. However, on the RGB version, composite sync is provided on the vertical sync line, and the horizontal sync line is unused. On the VGA version, both horizontal and vertical sync lines provide sync. If you can hook up the horizontal sync line to a scope, you should be able to find out quickly which version you have.
Since this data shows that reads from RAM are always faster than reads from ROM even when both are set to use 1 wait state, I would like to suggest one additional set of tests alongside your “Cache OFF” and “Cache ON” categories: executing from RAM.
I would expect that the time it takes to execute from RAM would fall between the timings for the “Cache OFF” and “Cache ON” states, since opcodes must still be fetched during execution, but are being fetched quicker from RAM than from ROM. This could be useful in case of routines that need a performance boost but are too large to fit inside the insn cache, sort of like using RAM as a “level 2” insn cache.
Skip steps 1 and 2. Please. You will burn yourself out in frustration after a month.
Disassembling and making sense out of optimized, unsymbolicated assembly is not for the faint of heart and definitely not a task for a beginner. Moreover, analyzing classic Mac OS assembly in 2019 is particularly difficult because Apple has done a fine job of eliminating the requisite API documentation from the Internet. By my estimation there are maybe 30 people left in the world who can decompile classic Mac OS applications, and those folks by necessity maintain a rich working knowledge of that API and its quirks.
If your goal is to make a version of Spectre on the Virtual Boy, very little of the Mac code will help you anyway. Here are a few major points about the Mac version that will not transfer over:
– No QuickTime on the VB. Nothing even close.
– Spectre’s multiplayer is communicated using the AppleTalk protocol. Needless to say, this doesn’t exist on the VB either.
– Graphics on the Mac are predominantly done entirely in software, typically via Apple’s QuickDraw API which, as you can probably guess, also isn’t on the VB. Spectre is designed to do all of its rendering in software, for instance (QuickDraw accelerators might help, but those are rare). Mac graphics coders have the advantage of better control over the back buffers– games, if not rendering to the framebuffer directly, render to an offscreen buffer (which consumes RAM) and make a final blit to the screen. You don’t have this on the Virtual Boy– an offscreen framebuffer would consume 24K, or over 1/3 of the VB’s total working RAM. In addition, video memory on the Mac is organized in horizontal scanlines– contrast this with the Virtual Boy which uses vertical scanlines. In short, you will have to fully rewrite the renderer. The Virtual Boy sports a powerful sprite engine in the VIP that can be leveraged essentially as a GPU. Taking advantage of the greater amount of ROM over RAM to prerender the 3D graphics as sprites will provide major gains in performance.
– All Macs come equipped with some kind of DAC for playing back sampled sound. No such thing on the Virtual Boy– sampled sound can be coaxed out of the VSU, but again, you’d have to do all of that in software, spoon-feeding individual samples to the VSU at a regular rate. This costs you CPU time that could be otherwise spent rendering Spectre’s 3D world and tracking gameplay. Keep in mind that the V810 processor inside the VB is clocked at just 20 Mhz– just slightly faster than a Mac SE/30. Rewriting the sound code to take advantage of the VSU’s native capabilities will win that CPU time back. Most of Spectre’s audio is not terribly complex anyway. 😉
As far as I know, the original source code to Spectre for Mac is lost. If you have your heart set on using “original” code, your best bet is probably the iOS port, which was done using a technique that I suggest you use: a fan meticulously studied the game’s operation and created their own clone using their own engine from scratch. I’m pretty sure its source code isn’t public though, but even if it was, I still wouldn’t use it for this project.
Seriously, I want to see this project succeed, as I too am a huge fan of this game and have many fond recollections of facing off against my sister in the late 90s. But you should approach it from the perspective of what the Virtual Boy is capable of and build from there. The Mac code will just get in your way.
Yep, Mednafen all the way. Best compatibility and a built-in debugger makes it pretty indispensable for homebrewing. Its developer is really passionate about accurate emulation and is very talented too. 🙂
Rift lenses are not going to work very well, as they introduce a significant amount of distortion to the magnified image. You would probably need a dual lens setup, with an additional lens to counteract the distortion, sort of like dual fresnels. Not sure if such a setup could be done at the DIY level and still fit inside the VB. Source: I have a Rift DK1, DK2, and CV1. 😉
Might be worth investigating Cardboard though. I’m not as familiar with those, but as RunnerPack points out, they sure are cheap. 🙂
Hedgetrimmer wrote:
Got one too, thanks for the tip, but dare I say it, with the other forum post being resurrected again, Stand Position, the stand is on backwards 😊
My VB Sound Generator app was only written for OS X, and is pretty much geared only as a sandbox for the chip itself– you can’t use it to write music or anything like that. I do indeed have a music engine in progress, but I haven’t seriously touched VB development in a long time so it just sits in a private Bitbucket repo for now. It’s being written in pure assembly and requires that you architect your engine a certain way, but I already have tools written that ultimately convert MIDI files to my own .VBM format. One of these days I’ll get back to it.
However do note that there are bugs. I recommend you check out what ElmerPCFX has been doing to improve GCC in this thread and apply some of his fixes before building the toolchain.
Guy Perfect wrote:
I understand that you have an emotional investment in using C++ (or, as the case may be, in not using C), but I remind you to think carefully before accusing someone of making unsubstantiated claims. I don’t want a constructive debate to devolve into name calling and hearsay.
Perhaps that was a little harsh and if so, I apologize. My point still stands though– many of your claims so far about your preference for C are unsubstantiated.
Like I said, I don’t care what language you use for your own personal projects– if you love C and want to write in it, great! But starting a topic and making claims like “C is about as close as you can get to machine code without writing architecture-dependent programs, meaning it’ll be about as fast and memory-efficient as they come” and “While the difference in performance is negligible, there’s still a relevant impact when using C++ instead of C” is pretty disingenuous and a bit of a red flag to me. No offense intended to you, but this discussion doesn’t fill me with a whole lot of confidence about this project from the get-go. If I have an “emotional investment” in anything around here, it’s in seeing VB devs succeed– while I’m sure you’ll pull more than your fair share of the weight on this project alone, I predict it will take a much longer time without help or adoption, and I’m having a hard time envisioning a number of folks signing up.
Guy Perfect wrote:
1) Some of the features of C++ necessarily have more demanding runtime requirements to compensate. I mentioned the “new” keyword, which was confirmed to allocate a small block of memory every time an object is created.
But it was also brought up that trapping exceptions–one of the most powerful features C++ offers over C–has a host of overhead making it work. The runtime library required to use a C++ program has a larger memory footprint than the C runtime. While the difference in performance is negligible, there’s still a relevant impact when using C++ instead of C.
No amount of C++ trickery is going to make the emulation core work in a C environment, performance notwithstanding.
Absolutely false. (Seriously, this is the first Google result returned for “c wrapper for c++ library”– did you do any research yourself or are you blindly going by what your “associate” says?)
Look, you personally can write your project in whatever language you want, and that’s fine, but when you as a project leader open it up to the world and then place arbitrary restrictions on its development without supporting arguments that make technical sense, you’re not getting off on the right foot. Code conventions are one thing, but shutting out a huge part of the language that’s been in use for over 20 years because of some preconceived notions that it’s less performant, top-heavy, memory-intensive, or what-have-you without confirming it for yourself first in practice, is at best silly and at worst irresponsible. Are these concerns really all that significant in the overall scope? Is it worth shooing away good C++ coders so you can recoup that .00001%? Worrying about speed or space issues is premature optimization that should be done only after profiling a project to see where the bottlenecks are– otherwise it’s time wasted over a mostly futile effort.
Guy Perfect wrote:
One of my desires is to help lift the veil on the internet that enshrouds emulation in an air of mysticism. An emulator isn’t some arcane box of hocus-pocus: it’s a rigidly-defined set of rules that get from point A to point B. I want people from all over the industry to be able to look at Planet Virtual Boy and, in doing so, learn a lot about how emulation works and maybe take the system a little more seriously in the process. (-:
Developers welcome, but even if I do the programming myself, I’m totally fine with that. Either way, the project will be open-source and a version-controlled source repository will be open to the public… well, it might be restricted to PVB members, but that’s public enough.
If you want to do it yourself, and have a personal passion to write an emulator, then good for you!
But if you just want a “better” emulator than what’s available, have you considered not throwing away the years of work that other people have done, and to actually save yourself a lot of time and build upon one of the existing emulators and improve it?
Any major project is a huge commitment in time. Lots of people start things, and then the projects die because all the details mount up and things get frustrating and no longer “fun”.
In the last couple of years I’ve used Mednafen to hack a large PC-FX CD game, and two PC Engine CD games.
Unless I’m hallucinating, it’s already got 70% of what you want, and the rest isn’t hard to add, because a lot of it is already supported on Mednafen’s other emulations.
For instance VRAM viewing/breakpoints don’t seem to work on Mednafen’s VirtualBoy emulator, but they do work on Mednafen’s PC-FX and PC Engine emulators. So the framework is already there, it just needs someone to add the missing bits for the VirtualBoy.
Might that not be an easier (i.e. more likely to happen) route than just starting from nothing?
Mednafen’s debugger certainly has room for improvement … which is why I spent the time to improve it for my own use, and intend to keep on doing so to add more new features.
But that’s because my goal is to use an emulator to do other things, and not to write an emulator.
You just have to be very, very careful to decide where it is that your programming passion (and capability) lies.
This. All of this.
Creating a new emulator from scratch seems like we’re throwing the baby out with the bathwater. Mednafen works well, has an amazing project lead, has the benefit of being maintained and patched over the years of its existence by countless contributors, and from my evaluation has no technical reasons why it couldn’t be extended to do the things mentioned in the OP.
The VB community is *tiny*– I don’t think I can stress this enough– and we’re lucky to have folks like ElmerPCFX stop by from the PC-FX community to help us out. We should *encourage* folks not in the VB community to contribute to our tools, especially if it’s mutually beneficial. A Virtual Boy-exclusive emulator such as this one only serves to isolate us from possible contributions. Improvements to Mednafen’s debugging facilities, though maybe not always VB-specific, are improvements we get for free. Likewise, do you think the PC-FX community would be interested in helping to develop a Virtual Boy-exclusive emulator? Why would they? (Consider why Red Dragon and Reality Boy are no longer maintained. Hmmm…)
Guy Perfect wrote:
I have made one executive decision, though: the main trunk of the project will be written in the C programming language. Not C++, but vanilla C, for the sake of simplicity. C is about as close as you can get to machine code without writing architecture-dependent programs, meaning it’ll be about as fast and memory-efficient as they come.
I’m going to assume you know what you’re talking about and that you have other reasons for choosing C, and would love to know those reasons, but for the benefit of others, choosing C over C++ for performance reasons is a mistake. C has no advantage over C++ performance-wise, and vice versa. C++ is a superset of C, meaning that you can use some or none of the extra features provided by the language, with no penalty in the latter case.
That aside, C++ affords the programmer many features now taken for granted that simply aren’t present in vanilla C– operator overloading, access specifiers, better const correctness– these are things that make the programmer’s life easier and/or help them not make silly mistakes (We’re all human, after all). Aside from compatibility with legacy code or compilers, I cannot understand why a strictly C-based project is necessary in 2016, but if you continue to insist, then please use at least C99.
