Virtual Console?

You mean designing and implementing your own game console entirely in software? This certainly sounds reasonable to me if you have the skill.

Sure as hell is possible, but why on earth would you want to? Unless it's for learning ofcourse.. :)

Quote:

Original post by DvDmanDT Sure as hell is possible, but why on earth would you want to? Unless it's for learning ofcourse.. :)

I've been looking for a hobby project. Since it's possible I'll begin working it out.

Definitely an interesting subject if you enjoy that sort of thing. I'd like to do some hardware design myself one of these days just for fun/education.

I'd recommend making some games/demos for existing consoles before you start to get an idea how they're designed, if you haven't already. Unless you don't care if it could actually be implemented in hardware or not. Then you can just go wild.

Good luck!

Quote:

Original post by OmegaMB Just a quick question: Since there are emulators out their that can imitate systems like the NES, would it be possible to create a original "virtual console" that would play games using an original file type? And no, I'm not talking about creating a emulator for a console.

This is how most emulators do it. They emulate hardware in software, so that original code is interpreted instruction by instruction.

The other option is considerably more complicate. That one translates instructions from original into host's machine code, and is executed natively. This is only possible for mostly compatible instruction sets, and is considerably more difficult to get right.

Emulator here doesn't mean something weird, it means simply emulating entire hardware in software, everything else remains the same.

And many consoles don't have files, they are just distributed as files over PCs, but are actually ROM or CD images.

Quote:

Original post by Antheus And many consoles don't have files

Im not entirely sure what you mean here, but certainly the consoles I have worked on (PS2, PS3, PSP, Xbox1/360, GC and WII) all have files and file systems.

At least in the old cartridge based systems, the ROM is just one long stream of data that's mapped to a range of memory addresses that the CPU can access.

For example on the GBA, the BIOS is mapped to address 0, the cartridge is mapped to address 0x08000000, and control registers for the video hardware and such are mapped to addresses starting from 0x04000000. The ARM7 CPU it uses starts up at address 0, which is in the BIOS. The code there does some setup, and then jumps to 0x08000000. From there you're on your own. Whatever code happens to be at the start of the cartridge gets executed, and how you access the rest of the data is up to you. You can make a file system using filenames, or an index based system using a big table of offsets to files that you can index into, or just use linker symbols to reference all your data like global arrays.

Another point for the OP: If you want to use C/C++, you'll probably want to design your system to use an existing CPU. Preferrably one supported by GCC, since it's pretty easy to configure for different systems. Granted it would be fun to design a CPU and write an assembler for it, but that would add a lot of work to the project, and make it harder to code for when it's done.

Yes you can and it's how the Chip-8 primarily exists today as an interpreted virtual platform.

Sounds like it'd be an interesting hobby project in many ways actually.

Perhaps you could build it around existing cpu emulators such as the Coldfire emulator or an ARM core like the GBA/DS. Keep it simple by having everything in a well documented ROM format so that "files" are just addresses in memory etc as DekuTree64 already suggested.

Actually I'm just reiterating most of what DekuTree64 has suggested now, but yeah sounds like a fun idea.

Andy

There existed (exists?) a system which provides a platform upon which to develop games in a similar capacity to console programming, but provides (apparently) detailed specs, called the X Game Station. Maybe this will be of interest to you.

Awhile ago I decided that I wanted to make a virtual console, but I took a bit of a different route than actually emulating unique hardware. Rather, it was an application that was interacted with like an emulator by the user, but was actually running &#106avascript instead of interpreting byte code. The games were a bundle file format including &#106avascript code files and plain-text data files (including things usually represented in binary formats, like images).<br><br>The way it pulled off a console feel was through artificial limitations: a 160x128 "screen" supporting four shades of gray (black, dark gray, light gray, white), a sound engine supporting three square-wave tracks and a noise track, and limited input options (a direction pad, a start button, and two action buttons). Basically, it was most comparable from the user's perspective to the original Game Boy.<br><br>It was a very fun project. I was able to make games like Snake and Breakout in a matter of hours, which was very enjoyable. I didn't end up releasing it for several reasons, including the fact that the &#106avascript API for interacting with the 'console' wasn't the best I've ever designed and the &#106avascript engine I used was rather messy to work with. I'm now slowly spinning up work &#111;n a second version of the project that uses Lua instead of &#106avascript, and allows for color (think Game Boy Color graphics). Maybe it'll end up being released.<br><br>Essentially, I was more concerned about the end result (old-school games) than the process to get to them (electing to use a modern scripting language running off the full power of a desktop machine rather than actually emulating certain hardware, real or not). Just thought I would toss this out there for your consideration.