An opened source project intended to provide a VM/Emulator for a late 90’s game console that could have, but never actually existed.
The goal of this document is to try to very loosely define the target specs of our imaginary system, currently codenamed Fuselage.
Processor: Since the processor will be imaginary, deciding on a specific architecture is pointless, but I will be studying the 6502, Z80, 680x0, and x86 to get inspiration. The goal is to design a emulated processor that adds all the features necessary to act as the CPU of a virtual game console. For this reason, I will be starting by researching the 6502 and trying to build a basis from that. Nothing is set in stone, but starting simple can get me the experience needed to move forward. Plus it will give me a groundwork onto which I can build. I am not at all against supporting different CPU types. This could help with adoption from programmers who are already familiar with existing CPUs. Eventually, though, my target is to reach capabilities on par with either the Motorola 68060 or the PowerPC.
Graphics: This one is a bit more difficult. My intention is to create a virtual GPU that focuses on layers and sprites. Starting with color depth, I really like the idea of implementing features that were present in hardware back in the 16 bit era. I want color registers, hardware sprites, layers, and bitmaps. I really want to stay away from 24/32 bit color but I also am not sure there is much point in creating artificial limitations. Here is what I do know: I want to create three bitmap layers (Background, Foreground, and Mainscreen), 4 tile layers (16x16 pixel bitmap cells each able to choose from some number of pallets which contain some number of color each), and a text layer. By default the layer priority from furthest back to closest would be as follows: Background, then the Mainscreen can be either in front of or behind the tile layers, Foreground, and finally the text layer which can be front, back, or off. Each layer would be any arbitrary size as long as it would fit in memory, and could be "hardware scrolled" by changing a viewport offset. The bitmap layers would have alpha channels and the tile layers would all have transparency modes of their own. Finally, I want to implement some kind of sprite system. It would essentially be like the tile layers, though each sprite tile would be numbered and arbitrarily located on the screen. All of these are long term goals. In the short term, I can't see implementing any of this in the virtual machine and instead will simply be using high level functions to display graphics. The transition to the virtual GPU will take place in small steps over time. For a while, graphics will have to be handled the way they generally are in modern software: using API calls.
Sound: In the short term it makes the most sense to rely on a library such as FMOD, but eventually I want to incorporate emulation of an advanced synth chip similar to the SID, but with more modern features. While there would be some set limit of sound channels on the virtual chip, it would also have digital channels allowing for more modern style sound output. This would allow the chip to be easy enough to write very traditional chiptunes for the musicians that desire that sound, while still providing the facilities necessary to do the things that modern software designers have become accustomed to being able to do.
Memory: This one is easy. I want dedicated system memory, graphics memory, and sound memory, which will be allocated from the host system's memory pool at execution and will be determined at build time. This way games will be able to allocate only as much as they need, while also locking a set memory footprint into the virtual machine as needed by the game developer. There would be no need for the Virtual Machine to allocate 16 megabytes of ram to run a game that only needs 800k. However, this would also give the developer the flexibility to allocate a few hundred megabytes of graphics and sound memory if it were needed by the game. Since the game data will be stored in a ROM file which would ideally be fully readable by the program at execution time, a well designed game will have a memory landscape that shouldn't change during runtime. This could have the advantage of making the game more stable, easier to debug, and less prone to memory leaks or security concerns. Hopefully.
Input/Output: This one is easy, too. The host system will provide game controllers, keyboards, and mice. The virtual environment will see them as if they were connected to a game console physically. Short term, this will be any USB controller the host system can use. Long term I would like for the virtual environment to be able to recognize the exact type of controller, and provide support for other less common control schemes, such as multiple keyboards, mice, spinners, and unique game specific controllers, such as dance pads and musical instruments. While the host system will be interfacing with these devices through USB or bluetooth, the virtual machine will be completely unaware of the methods by which the available controllers are attached, identified, enumerated, and allowed to be accessed.
---- END OF MESSAGE ----