Retro Revolution Project Game Engine
category: general [glöplog]
Hi!
I would like to announce the opening of a new open game console design, the Retro Revolution Project Game Engine (RRPGE).
This console aims to replicate a system probably possible in the early 90's while designed in a way it may be seamlessly integrated into today's technologies. From the specifications everything is open by the spirit of GNU GPL (with permissive exceptions to make thing practical).
Currently a prototype emulator and assembler is complete for trying things out, the emulator being (hopefully) capable to produce the graphics and sound features of the system. Some example programs are also available.
If interested, check it out at rrpge dot org (and some other tld's; this is my first post, so I rather omit posting direct links).
I would like to announce the opening of a new open game console design, the Retro Revolution Project Game Engine (RRPGE).
This console aims to replicate a system probably possible in the early 90's while designed in a way it may be seamlessly integrated into today's technologies. From the specifications everything is open by the spirit of GNU GPL (with permissive exceptions to make thing practical).
Currently a prototype emulator and assembler is complete for trying things out, the emulator being (hopefully) capable to produce the graphics and sound features of the system. Some example programs are also available.
If interested, check it out at rrpge dot org (and some other tld's; this is my first post, so I rather omit posting direct links).
Are you planning to produce hardware as well?
In a long long way, yes of course :) - but given it even has a custom processor architecture, it is really a long way away (but of course FPGA's are always here for the adventurous). For now the primary goal is emulation, on just about everything and anything. For a nice own hardware "illusion", I am looking at the Raspberry PI in particular, it would make a nifty little RRPGE box!
seen this?
http://www.armigaproject.com
http://www.armigaproject.com
Not yet, but sure, interesting concept!
My deal has a different goal, though. It's primary intended for emulation: I designed it in a way so it is likely that it is technically possible to produce hosts for just about anything existing today, and even then in such a way that it can integrate well. No need to swap around virtual floppies, probably no need to set up controllers, it would just work.
The emulation library itself (within the prototype) is truly freestanding, to that degree it does not even need the standard C library. And as far as I tested, it might be possible to bring it even down to working properly on an old Pentium 200MHz or so. Hopefully this makes the system even appealing for example to hobbyist OS creators: once they have a C compiler, they can compile the library, then with little effort they may get the most important aspects of the system (sound, graphics, some controller), so instant gaming.
Many aspects of the system are constructed so they can be emulated at high performance. The overall design reflects this: a relatively slow (effectively at around 3 MIPS) 16 bit CPU is paired with a strong graphic accelerator and audio mixer, as these accelerator tasks are a lot easier to emulate (there is no instruction decoding).
But just check it out, it works (the sound and graphics parts with all the accelerators), there are some examples as well (source codes available on the GitHub pages).
My deal has a different goal, though. It's primary intended for emulation: I designed it in a way so it is likely that it is technically possible to produce hosts for just about anything existing today, and even then in such a way that it can integrate well. No need to swap around virtual floppies, probably no need to set up controllers, it would just work.
The emulation library itself (within the prototype) is truly freestanding, to that degree it does not even need the standard C library. And as far as I tested, it might be possible to bring it even down to working properly on an old Pentium 200MHz or so. Hopefully this makes the system even appealing for example to hobbyist OS creators: once they have a C compiler, they can compile the library, then with little effort they may get the most important aspects of the system (sound, graphics, some controller), so instant gaming.
Many aspects of the system are constructed so they can be emulated at high performance. The overall design reflects this: a relatively slow (effectively at around 3 MIPS) 16 bit CPU is paired with a strong graphic accelerator and audio mixer, as these accelerator tasks are a lot easier to emulate (there is no instruction decoding).
But just check it out, it works (the sound and graphics parts with all the accelerators), there are some examples as well (source codes available on the GitHub pages).
So a lower level version of SDL?
What about framebuffer accessa and 3D hardware acceleration?
What about framebuffer accessa and 3D hardware acceleration?
Neither that. SDL also has a different goal, my aim was to get something really 90ish done, but in a way it could function well for the end user.
So what you see as developer is hardware: a CPU, peripherals, and a kernel to interface with, which you can (currently only can) access from assembler.
Why I think this approach is a better for this (retro style) purpose than SDL are about the followings:
An interesting trend what I see reinforcing this approach is GOG: For example when I bought Heroes 2 or Master of Orion 2 I was shocked to see that the DOS version was which they revived. For DOS we have a perfect emulator. For Windows - meh. So DOS survives while old Windows games and stuff go down the drain. This applies to SDL games as well: in 10 or so years we will well lose them unless they are maintained. DOS games meanwhile will still be around! (As well as for example C64 or Spectrum stuff)
And no, there is no 3D HW acceleration etc. However the system can go with as low as 6,5 Mbytes per seconds (in 50 Hz refresh rate, assuming no frameskipping) transfer requirement for graphics, then what you do with the data is up to you (for example you could utilize your host system's graphics hardware to produce nice old television look and feel, or whatever "upscaler" pleases you).
So what you see as developer is hardware: a CPU, peripherals, and a kernel to interface with, which you can (currently only can) access from assembler.
Why I think this approach is a better for this (retro style) purpose than SDL are about the followings:
- Well defined specification, like real hardware. Software built with SDL needs maintainance to keep up with technology (even just to keep it runnable). This does not need that: only the emulator has to be maintained and ported, a lot less hassle for who just want to create a retro game (this benefit truly applies to any emulator).
- Simpler system than SDL. The emulation library is freestanding, you can pair with with any sound / graphics / controller solution to create a functional host. With SDL as game developer you have to think about how your game interfaces with the system it is ported to. With this system a lot less so (only the controller aspect needs some consideration from the game developer).
An interesting trend what I see reinforcing this approach is GOG: For example when I bought Heroes 2 or Master of Orion 2 I was shocked to see that the DOS version was which they revived. For DOS we have a perfect emulator. For Windows - meh. So DOS survives while old Windows games and stuff go down the drain. This applies to SDL games as well: in 10 or so years we will well lose them unless they are maintained. DOS games meanwhile will still be around! (As well as for example C64 or Spectrum stuff)
And no, there is no 3D HW acceleration etc. However the system can go with as low as 6,5 Mbytes per seconds (in 50 Hz refresh rate, assuming no frameskipping) transfer requirement for graphics, then what you do with the data is up to you (for example you could utilize your host system's graphics hardware to produce nice old television look and feel, or whatever "upscaler" pleases you).
i just briefly read through your cpu and gfx specs.... and by now i am convinced that someone who knows x86 and pc arch tried to come up with what he thinks is similar to early 90s consoles - but its not.
you should ask yourself what the point of using this is, say over using SNES or similar as target. or if you want more powerful, playstation1. both offer more, in a way.
you should ask yourself what the point of using this is, say over using SNES or similar as target. or if you want more powerful, playstation1. both offer more, in a way.
whats the point anyway, any household pc can emulate those machines with available free software.
The problem with all the 90's and later consoles is that they are all crippled with legal problems. Or is there any for which emulators are possible without navigating in the dark matters?
The CPU is not based on the x86. It is 16 bits, but the similarities end there. Originally (years before) I checked out early ARMs (the Acorn Archimedes in particular), and looked in how they would fare with emulation. Then I had a bit far-fetched goals (going down to be capable of emulating the system even on a 4.86 or so), and tried to scrape off everything from a hypothetical CPU design while keeping things reasonably useful.
The current CPU design is so truly rather based on ARM, but far-far back. The 16 bits direction was taken for the instruction word size: to get things simple and get to a point where the CPU would have an unified addressing scheme, that is all accesses performed with the same word size. 16 bits is probably the most economical opcode size to get here. The CPU performs all accesses (be it data or opcode fetch) at this width.
The way I set up the instruction decoder feeds from the ARM concepts, mixing in the concept seen in PICs (I had seen there first that they implemented multi-word instructions so the second word alone would decode to a NOP).
I dropped flags entirely since they require lots of work from the emulator to emulate (depending on the type and amount of flags), while most of the time they go unused in the program flow. How I solved this seems to work well, I had no problems implementing various algorithms using the available resources (skip instructions: these evolved from ARM's conditional instructions, similar to those found in PICs and maybe AVRs).
The register set shrunk to 8 because of the limitation of the word size (I couldn't fit 16 registers in). However contrary to x86, the bp and sp registers are not included in this set. This is however only a part of the story: essentially with a bit limited access capabilities, you have 16 additional "registers" for your convenience, by the bp relative addressing mode (immediates from 0 to 15 encode in a single opcode word, so no penalty).
Probably check out the examples as well to see how the various features are used in the practice.
The weakness of the CPU comes from that the system is intended primarily for emulation: there the biggest cost is to realize the CPU, the instruction decoder. So I had to scrape stuff off here. In general you are supposed to work with the accelerators to get things fast, in some ways similar for example to Gameduino (where you only have a 8 bit CPU to start with).
By the way I uploaded two screenshots to the site, for those who don't want (or can't) try out the currently existing binaries, to show some possibilities.
The CPU is not based on the x86. It is 16 bits, but the similarities end there. Originally (years before) I checked out early ARMs (the Acorn Archimedes in particular), and looked in how they would fare with emulation. Then I had a bit far-fetched goals (going down to be capable of emulating the system even on a 4.86 or so), and tried to scrape off everything from a hypothetical CPU design while keeping things reasonably useful.
The current CPU design is so truly rather based on ARM, but far-far back. The 16 bits direction was taken for the instruction word size: to get things simple and get to a point where the CPU would have an unified addressing scheme, that is all accesses performed with the same word size. 16 bits is probably the most economical opcode size to get here. The CPU performs all accesses (be it data or opcode fetch) at this width.
The way I set up the instruction decoder feeds from the ARM concepts, mixing in the concept seen in PICs (I had seen there first that they implemented multi-word instructions so the second word alone would decode to a NOP).
I dropped flags entirely since they require lots of work from the emulator to emulate (depending on the type and amount of flags), while most of the time they go unused in the program flow. How I solved this seems to work well, I had no problems implementing various algorithms using the available resources (skip instructions: these evolved from ARM's conditional instructions, similar to those found in PICs and maybe AVRs).
The register set shrunk to 8 because of the limitation of the word size (I couldn't fit 16 registers in). However contrary to x86, the bp and sp registers are not included in this set. This is however only a part of the story: essentially with a bit limited access capabilities, you have 16 additional "registers" for your convenience, by the bp relative addressing mode (immediates from 0 to 15 encode in a single opcode word, so no penalty).
Probably check out the examples as well to see how the various features are used in the practice.
The weakness of the CPU comes from that the system is intended primarily for emulation: there the biggest cost is to realize the CPU, the instruction decoder. So I had to scrape stuff off here. In general you are supposed to work with the accelerators to get things fast, in some ways similar for example to Gameduino (where you only have a 8 bit CPU to start with).
By the way I uploaded two screenshots to the site, for those who don't want (or can't) try out the currently existing binaries, to show some possibilities.
Wouldn't this have been easier? gameduino
Quote:
The problem with all the 90's and later consoles is that they are all crippled with legal problems. Or is there any for which emulators are possible without navigating in the dark matters?
there are no legal problems with emulating a SNES or PS1 at all - if you can live with not being able to run commercial games, which may need the copyrighted bios code. (replacement ROMs exist)
one major problem with your "console" approach is the gfx imho - its not console like at all. a 90s console has sprites, and tile based backgrounds for example. it also has an actual soundchip. if all you have to offer is a framebuffer and dma based dac for sound, i dont know why you dont just use SDL - it has been ported to everything already :)
hmm.. only a frame buffer + no sound chip? In that case all it is is a pretty standard computer with a different instruction set, I don't see much appeal. As groepaz said, SDL, and if you want a retro platform SDL on amiga or whatever.
So this is not for targeted at the demoscene but at game developers? Is that correctly understood?
The project sounds cool indeed – sorta like a piece of "hardware" not depended on any actual hardware.
The project sounds cool indeed – sorta like a piece of "hardware" not depended on any actual hardware.
Why reinvent the wheel? There are several open source game consoles that work with SDL and come with their own emulators. You can even emulate console emulators within the emulator.
other open source game console alternatives
I think it would be cool to design hardware that runs the IBNIZ virtual machine.
- GP2X the other open-source game console SDL library with emulator
- pandora - uses standard libraries such as OpenGL ES and SDL. open source OS
other open source game console alternatives
- game duino with software emulator
- UzeBox open source, retro-minimalist game console emulator
- Fuzebox - Open source 8-bit game console
- Hackvision
- retroWiz
- XGameStation
- GCW Zero open source gaming console. probably lots more like this on kickstarter
I think it would be cool to design hardware that runs the IBNIZ virtual machine.
For the existing projects matter, I knew about most of them. The main problem with those is that it is hard to get out from their constraints if you get to like the idea: neither of them could (easily) get you to a point where you could actually distribute your interactive art preserving it's interactive nature to those type of people who don't have the skills to hack "the real thing". This is quite a barrier IMHO. Of course emulation is possible for all.
For the framebuffer: my solution do have components to compete with the features of the consoles of that time, just differently built. It has a graphics accelerator and an audio accelerator for these purposes, the graphics accelerator can even work in parallel with the CPU.
And why the difference? Initially I started to work my way out from probably the C64's design, throwing in some Atari and Amiga elements I knew about. So I even planned to do sprites. But later in the crafting I realized for one, sprites are not exactly cheap to emulate, for two, they quite constrain the possibilities you can pull out of the system (that is, if you only have sprites, then you do only have sprites...).
The whole design is crafted with having primarily very efficient emulation in mind, aiming at getting these all out with the minimal complexity (there were quite lot reduction passes in the development). The accelerators are built so they both can be emulated very efficiently, and with their proper use, just about any reasonable expectation could be met. I even plan to build some flat polygon 3D games with it.
Of course this release was quite early, I except a few changes to be made in the accelerators (just now I am revising the graphics accelerator to support sprite clipping type tasks proper since that somehow got overlooked until now), and probably a lot in how the controllers would be interfaced.
If you look at the screenshots (or even try the binaries), would you except a measly 3 MIPS 16 bit CPU being capable to do a rotozoom with fading at 15FPS at 640x400 without any extra hardware assistance?
If life permits (this bloody country wont collapse into a civil war or whatnot), starting about right now, I would start designing actual games for the system, meanwhile hopefully also going a bit deeper in music composing (Interesting stuff!). Given the fact I already got here, and I would like to do games, even if no-one would use my system except for me, I still only win if I keep on and use it. I put a ridiculous amount of effort in properly separating even the emulator logic from the presentation and "hardware" (OS) interfacing, so after polishing up the interface it will be very small, and a completely freestanding emulator library backs it.
Once I get the remaining uncertainties of the system fixed through experiments with actual game making, whatever game I complete will no longer need any maintenance to remain playable. Ever. The emulator library itself can also stand quite well the change of time. To keep up with technology, I only need to understand whatever I want to port the thing to, write some host, and done, all games playable on instant.
For the framebuffer: my solution do have components to compete with the features of the consoles of that time, just differently built. It has a graphics accelerator and an audio accelerator for these purposes, the graphics accelerator can even work in parallel with the CPU.
And why the difference? Initially I started to work my way out from probably the C64's design, throwing in some Atari and Amiga elements I knew about. So I even planned to do sprites. But later in the crafting I realized for one, sprites are not exactly cheap to emulate, for two, they quite constrain the possibilities you can pull out of the system (that is, if you only have sprites, then you do only have sprites...).
The whole design is crafted with having primarily very efficient emulation in mind, aiming at getting these all out with the minimal complexity (there were quite lot reduction passes in the development). The accelerators are built so they both can be emulated very efficiently, and with their proper use, just about any reasonable expectation could be met. I even plan to build some flat polygon 3D games with it.
Of course this release was quite early, I except a few changes to be made in the accelerators (just now I am revising the graphics accelerator to support sprite clipping type tasks proper since that somehow got overlooked until now), and probably a lot in how the controllers would be interfaced.
If you look at the screenshots (or even try the binaries), would you except a measly 3 MIPS 16 bit CPU being capable to do a rotozoom with fading at 15FPS at 640x400 without any extra hardware assistance?
If life permits (this bloody country wont collapse into a civil war or whatnot), starting about right now, I would start designing actual games for the system, meanwhile hopefully also going a bit deeper in music composing (Interesting stuff!). Given the fact I already got here, and I would like to do games, even if no-one would use my system except for me, I still only win if I keep on and use it. I put a ridiculous amount of effort in properly separating even the emulator logic from the presentation and "hardware" (OS) interfacing, so after polishing up the interface it will be very small, and a completely freestanding emulator library backs it.
Once I get the remaining uncertainties of the system fixed through experiments with actual game making, whatever game I complete will no longer need any maintenance to remain playable. Ever. The emulator library itself can also stand quite well the change of time. To keep up with technology, I only need to understand whatever I want to port the thing to, write some host, and done, all games playable on instant.
Even if it doesn't get adopted, it is still a great learning experience! Keep up the good work.
