Some topics of Homebrew Video Gaming System
John A. Zoidberg
Posts: 514
Hey there,
I know of the Hydra video game development system sold in the Parallax store. Also, anyone actually program video games into the Propeller C3 or those Propeller w/emulation of classic hardware? I'm very curious to know about it. So far I checked the net but not much about videogames on Propeller (I've seen a number of SX and the Uzebox).
Also, a more advanced video game might be using sampled *.wav sounds. How do they actually mix a few channels of *.wav? I suspect they might be using some sort of killer DSP inside.
Note that "video games" in this thread does not include "3d-graphics" and "wireframe-graphics". These are too complex - FPGA might be the option. (Other approaches are welcome and I'm happy to hear that!)
I know of the Hydra video game development system sold in the Parallax store. Also, anyone actually program video games into the Propeller C3 or those Propeller w/emulation of classic hardware? I'm very curious to know about it. So far I checked the net but not much about videogames on Propeller (I've seen a number of SX and the Uzebox).
Also, a more advanced video game might be using sampled *.wav sounds. How do they actually mix a few channels of *.wav? I suspect they might be using some sort of killer DSP inside.
Note that "video games" in this thread does not include "3d-graphics" and "wireframe-graphics". These are too complex - FPGA might be the option. (Other approaches are welcome and I'm happy to hear that!)
Comments
You've hit on a topic near and dear to me.. I host http://software.propellerpowered.com (Thanks for posting that Bill) and there is some really great gaming to be done on the Propeller!
The software.propellerpowered.com site is next to be upgraded with a bunch of new information, so keep eyes on it.
Also, I'd invite you to the basic tutorial I just did on Propeller gaming here..
http://www.gadgetgangster.com/tutorials/358
OBC
Cool stuff you have here man.
By the way - is one core of Propeller equivalent of uh... let's say 6502? Or the Z80?
I would want to closely model the Propeller to some sort of oldie video game sets, but not exactly the instruction sets (that'll be emulation - a seperate topic).
Take a look at this thread..
http://forums.parallax.com/showthread.php?119075-Hydra-NES-Pacman-Emulator
Also, this may catch your attention as well.
http://forums.parallax.com/showthread.php?122361-Colour-Genie-EACA-EG2000-emulation
OBC
Propeller games so far typically use the various cores to perform various tasks. One might do game controllers, another sound, a few together video, one for the CPU, and maybe one for SD card, or fetching data from external RAM.
The game itself can be done in SPIN, which makes for a quite nice environment.
There are some emulations. RAM is a significant challenge, though we do have high speed external RAM interfaces now, some that can do 3-4Mb / sec. IMHO, that's a lot for retro emulation or video gaming. We don't have a lot of driver code using that RAM yet, but the interfaces are there along with the core code needed to make it go.
Just a matter of time before we see video, etc... operating largely out of those RAM devices. At TV resolution, the speeds are high enough to make it work. I don't think VGA is so easy, but then again, I've not really explored them yet. I have a Dracblade, and need to pick up a C3, or Nick's new RAM to play!
This is some older material that needs to be updated and freshened up a bit, but you may find it interesting.
http://www.propellerpowered.com/gaming.html
OBC
This is what keeps the Propeller fun... There is so much untapped potential in this chip!
OBC
Additional discussion around the specific driver (ORE) that is used in the example is available on SavageCircuits.com.
If you search through the stickies in the main Propeller forum, and find the old Hydra Master Projects List, you will find lots of "gems" that you may be able to use, learn from, or ask questions about. Some of the forum members are still around/active, and others are not. Most likely though there will be someone around that can at least point you in the right direction if you have a specific question.
If you are looking for the source code for some of the utilities in the ORE examples--some of it is available here:
http://code.google.com/p/trodoss-prop
(Others would be part of posts that should be part of the main Propeller forum, as it contains the old Hydra forum posts)
There is one game made with the same driver (Fantasy Fighter), and there are plenty of others with a variety of other drivers/tools that could be used. Some of the code posted in the C3 FTP site might also be of interest. A lot of the "Hydra Book" code has been posted (and updated) there.
Hopefully that helps.
--trodoss
Depends. That is a pretty vague answer, I know. However, it might help if I provide an example:
The first game on the Propeller that I had made, I had thought that with 32K containing the graphics driver, sound driver, and embedded game logic/level data that I might be able to get in say, 2-3 levels of a game without running out of resources. The farther along that I got in that project (and with a little compression--using "old school" techniques) I found that not to be the case. By the time the game was playable, I had added 8 levels and was really only at 16K of code+RAM. I could have easily added more levels/graphics/features and had a nice game. It really speaks to how compact Spin bytecode is, and, with a little work, how you can get done more than you think.
If you take the same approach, and add an SD card (or an EEPROM), and only load elements "on demand" you really could make games on the scope of even some of the largest of the NES titles. Added RAM will always help (especially fast RAM for screen buffering). Classic consoles (like the NES) didn't always have the luxury of more RAM, and were working off of tileset graphics and trying to do as much as possible between screen refreshes.
You should join us over a Savage Circuits from time to time.. The Propellerpowered group there has become a haven for refugees from the Hydra/Gaming forums that Parallax had.
http://www.savagecircuits.com/forums/
Not that we want to keep you from these fine forums, but add it to your rounds.
OBC
I just browsed through the NES schematics and found out that they uses two 2K SRAM modules inside the console. One is for the PPU (picture processing unit) and one is for the CPU itself. The rest of the address buses for both PPU and CPU are to the cartridge.
Inside the catridge, there is a (basic) 32768x8 ROM and another 8192x8 ROM for the character ROM.
I wonder if I can substitute the CPU and PPU together as a Propeller, and both SRAM modules are replaced by one 4K and above SPI RAM. For the catridge part, I'm still thinking.
Unfortunately, Parallax Propellers only take in 32KB of program (game) code, which might be good for a few levels only. The bootloader might work, but it only accepts 32KB at one go and not even more than that.
Is it good if I substitute the PPU and the Sound Generator as one Propeller, and then I will use Bill Mensch's 6502 and the external PROM and SRAM as the main processor?
Or any other ideas how to extend the program code up to 2 megabytes?
What is "good" really depends on what you are wanting to get done. 32KB is a lot on the Prop for games. Adding to that has trade-offs all over the place.
So, what kinds of games? How do you intend to develop them? What graphics facilities are needed, or desired? Display output? Controller Input? Storage?
IMHO, a whole lot of that should be put on the table for good advice.
A Propeller can do a 6502 emulation more or less at NES speed. It can do various graphics systems too. We have a SID, and AY sound emulations that are quite good too. Lots of great pieces, as well as some pretty nice games!
It's pretty easy to fetch data from the SD card, which could be program or level data.
Ok..to answer some of the questions:
Games: Could be as long as the Super Mario game. Take this as an example. Or maybe the Contra. Or the Bomberman with 50 levels.
Graphics: 56 colours (if I'm not mistaken) palette. If the libraries supply more than 100, it's not an issue. I'm not making it an exact copy of NES anyway. Some stuff about the PPU is there too so to facilitate programming.
Controller: Hmm, nothing much. Like all of those NES controllers. I could buy it over there in my place, they have el-cheapo clone NES controllers still around.
Sound: Again, just use the libraries.
Storage: The game catridge in NES systems might have like the most, 2 megabytes. It could be the graphics, or some other stuff put inside as well. Unfortunately, the Props could only use up to 32KB of program code at maximum. (Been digging about the approximate program size for each NES game available too, many of them are between 5kbytes ~ 1.5mbytes) I'm thinking of offloading the program code to a seperate, bigger EEPROM alongside with the graphics elements, but I don't know how that could be achieved. I've searched around too, nothing much about that has been addressed. (Or I'm not searching really hard enough)
If we stow all the graphics and sprite data all from the EEPROM to an external RAM during bootup phase, we could be already making a full-fledged video game set. But the issue is, retriving the data from RAM isn't too fast (if it's a serial).
I may need to read and use the Hydra for some examples too. Will try some examples on the Gadget Gangster tutorials too.
If it needs to play NES games, there is a significant challenge in using the external memory, and doing emulation, etc...
If it just needs to be NES like, it's perfectly possible to put the graphics needed at the time in the HUB, and fetch graphics and code as needed from other storage. A lot can be done with the 32K, particularly given video drivers that dynamically draw things.
Are you planning on having others, or you write games? If so, consider structuring things around the strengths of the Propeller. If emulation, then you've got to balance hardware vs software trade-offs. IMHO, using actual cartridges is going to be tricky because of the large number of I/O resources required. The same is true for a external set of chips.
On the other hand, files fetched from SD card can be loaded into the Prop. So a small program boots, loads up the external storage, then fires off the final program, which then can load drivers, graphics data and code as needed. We've got pretty much all the pieces for that kind of project now.
Nobody has hauled off and done it for a larger scale game though. Dr_A has done some impressive work with Catalina to have code running out of external memory, keeping most of the HUB free for specialized things.
*Whew* NES-like. I can't emulate NES-games due to the copyright issues, and it's a very very tedious thing to do.
Oh I'm planning to write my own games. I might be using the market available Serial EEPROM and SRAM for simplicity.
I'll go dig around some more about the SD-card bootloader. But, there is a limitation that all the other programs in SD-card (*.hex) must be 32kb in size?:)
Props can do lots of things. If you stick with the simple SPIN + PASM, you can get up to 14K of your PASM (assembly language, typically driver type ) programs running in the COGs, accessing data, and communicating with a SPIN program running out of the HUB.
That's enough to do a LOT, particularly given that program can fetch data from other sources.
If you want to develop in C, we've got program memory sizes that are considerably larger, where programs can run out of external memory. See Catalina thread, among others.
One last question: Have you written some games before?
I'm asking, because it's probably very simple and straightforward to setup a prop for VGA or TV output and write some smaller projects to get familiar with the chip, what it can do in all of it's various modes, get to know the video driver options that have been written to date, etc... There is a great game oriented one in my blog, under the title "some pixel art", that Baggers and I just completed.
It does full color tiles and sprites. That means all the standard "reference" Propeller colors, 64 in VGA, 120 or so TV, can be used anywhere in any tile, and in any sprite.
That driver does 256x240 resolution on VGA, and 256x200 on TV. It uses multiple COGs to render tiles and sprites. one COG will get you tiles. Two will get you a few sprites, and a few will get you a ton of sprites. ~30 or so per line easy. One additional cog is needed to draw the screen image to the TV.
The HYDRA CD contains some great game related drivers, and there is a lot of published game code to work from.
32K was enough to render, with a full on raycaster mind you, the first level of WOLF3D, just for a example of what can be done. Classics like DEFENDER and PAC MAN fit easily.
Just to clarify the above, when a driver is launched, it comes from the HUB, and once loaded and running in the COG, can be overwritten in the HUB, freeing that memory for a screen buffer, or something else. COG code can be fetched from SD card too, so a large program could leave a 2K buffer, grab something for a COG, launch it, then grab something else from SD, launch that, then use the buffer for variables, or data, both potentially fetched.
The C approach, called XMM, literally reads instructions from the external memory, executing them, then fetching more, allowing for larger, but slower programs.
SPIN is fast enough to do most classic games, leaving PASM for the time critical things like graphics and sound and controller I/O.
For the games, nope, I haven't made any games before. I'll start simple, of course.
I'll look into the XMM too. It looks pretty amazing.