Hey,
I haven't seen a Commodore 64 in my life , But I am writing a Commodore 64 emulator for fun , I have searched the net and downloaded some docs on commodore 64 architecture and other specs . Anyone having links to interesting C64 resources ?
I am also planning to make a small video game console based on z80 processor , Anybody here having experience building video game consoles ?Any suggestions ? Any pointers and links that could be useful ?.
Regards
Shrek
Commodore 64 and misc
-
JohnnyTheDon
- Member
- Posts: 524
- Joined: Sun Nov 09, 2008 2:55 am
- Location: Pennsylvania, USA
Re: Commodore 64 and misc
http://www.xgamestation.com/
I own one of the books that guy wrote. He basically outlines how to make a video game system, and has some prebuilt stuff on that website.
I own one of the books that guy wrote. He basically outlines how to make a video game system, and has some prebuilt stuff on that website.
-
AndrewAPrice
- Member
- Posts: 2299
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
Re: Commodore 64 and misc
I use to have a C128! It could run in C64 mode by holding down the Commodore key while booting. Those were fun times...
I created a virtual video game console and wrote a tool chain and emulator for it.
My biggest suggestion is to use a well-known CPU architecture. I didn't go down this route, and therefore I had a hard time porting several C compiler backends, finally getting one PARTLY working (which still broke when you tried doing more complex things), and trying to port the C compiler took well over half my development time on this project. I eventually gave up and wrote my sample game in pure assembly (The assembler I wrote myself). My suggestion to you is if you want a high-level language running on your console, emulate a CPU that already has a backend for a compiler ported to it.
However, I thought making my own CPU architecture was one of the funnest parts, so if you're still keen then try not to do anything that would be hard to emulate. For example, I had a 1kbit register, which was recursively subdivided down to 2x 512bit, 4x 256bit, 8x 128bit, 16x 64bit, 32x 32bit, 64x 16bit registers. When implementing the the emulator, I was unable to find a math library that let me work with 128/256/512-bit integers all pointing to the same areas of memory. Due to time constraints I gave up and changed the specification to say arthritic only worked on subdivisions of 64 bits and smaller.
I wrote my own assembler/linker tool - if you don't make your own CPU arch then you could probably skip this step and just use GAS/LD in GNU Binutils.
You will need a firmware, which initialises the hardware (all mine did was remember if the user was using standard or high-definition graphics output) and load the executable off the cartridge (mine was just a flat binary that was copied into memory). My cartridge also had a read-only file system that was constructed at build-time (it was a just table of files with their offsets/sizes at the front of the cartridge), and any room past the last file on the cartridge was free for the program to do whatever it wanted (e.g. save games or possible a more advanced read/write fs). I guess a firmware can be avoided if your console can do something funky (e.g. directly maps the first memory page to the first page on the cartridge on start up and books straight from there).
You also might want to study into several different consoles to see how they handle audio and graphics. For example, you might want to do tile-based graphics (which can be very fast and powerful) or MIDI music.
I recommend against having a flat linear frame buffer (although it could be an alternative video mode if required). The reason being, it's an emulated system and each instruction takes emulation time, so if it takes 10,000,000 instructions to update some 500,000 pixels per frame (15 cycles per pixel), at 30fps, that's around 300MHz (assuming 1 instruction = 1 cycle on your system) you need to continually be achieving to keep the graphics running smoothly (not taking into account complex game logic, updating input, audio, physics, AI, etc). That is why you need to employ a variety of tricks through hardware acceleration.
For example, in tile-based rendering, you load in a palette of tiles, and then you can place these tiles (via their index number) onto multiple background layers (advanced chips that Nintendo use allow these background layers to be rotated, scaled, and scrolled), which are loaded into the GPU registers. These are persistent, so there is no per-frame logic required to keep the background drawn (unless it is scrolling, then you need some logic to change the layer's offset and load the tiles along the side (perhaps in the 100s of instructions per frame in comparison to 10,000,000 in a linear frame buffer)). You can also have hardware accelerated sprites, that can be moved/rotated/scaled/animated by tweaking a few GPU registers.
In my console, I provided hardware accelerated 2D rendering of quads/triangles/lines that could be rendered into textures. I intended the system to use a variety of tricks rather than rendering directly to the screen. For example, you would render a complex background that required many render calls into into a single texture you could render with just one. The same with characters (render several layers with blending effects to construct the final frame of a character's animation). Though not as fast as tile-based rendering, I was impressed with how it preformed in my emulator.
Designing your hardware so you can keep things down to as minimal cycles as possible I think is essential. Especially since the emulation isn't going to be that particularly fast. I even had a memory acceleration chip that hardware accelerated memset/memcpy, so the emulator could do that natively (e.g. when loading textures) much faster than emulating each instruction for each byte of memory to copy.
I created a virtual video game console and wrote a tool chain and emulator for it.
My biggest suggestion is to use a well-known CPU architecture. I didn't go down this route, and therefore I had a hard time porting several C compiler backends, finally getting one PARTLY working (which still broke when you tried doing more complex things), and trying to port the C compiler took well over half my development time on this project. I eventually gave up and wrote my sample game in pure assembly (The assembler I wrote myself). My suggestion to you is if you want a high-level language running on your console, emulate a CPU that already has a backend for a compiler ported to it.
However, I thought making my own CPU architecture was one of the funnest parts, so if you're still keen then try not to do anything that would be hard to emulate. For example, I had a 1kbit register, which was recursively subdivided down to 2x 512bit, 4x 256bit, 8x 128bit, 16x 64bit, 32x 32bit, 64x 16bit registers. When implementing the the emulator, I was unable to find a math library that let me work with 128/256/512-bit integers all pointing to the same areas of memory. Due to time constraints I gave up and changed the specification to say arthritic only worked on subdivisions of 64 bits and smaller.
I wrote my own assembler/linker tool - if you don't make your own CPU arch then you could probably skip this step and just use GAS/LD in GNU Binutils.
You will need a firmware, which initialises the hardware (all mine did was remember if the user was using standard or high-definition graphics output) and load the executable off the cartridge (mine was just a flat binary that was copied into memory). My cartridge also had a read-only file system that was constructed at build-time (it was a just table of files with their offsets/sizes at the front of the cartridge), and any room past the last file on the cartridge was free for the program to do whatever it wanted (e.g. save games or possible a more advanced read/write fs). I guess a firmware can be avoided if your console can do something funky (e.g. directly maps the first memory page to the first page on the cartridge on start up and books straight from there).
You also might want to study into several different consoles to see how they handle audio and graphics. For example, you might want to do tile-based graphics (which can be very fast and powerful) or MIDI music.
I recommend against having a flat linear frame buffer (although it could be an alternative video mode if required). The reason being, it's an emulated system and each instruction takes emulation time, so if it takes 10,000,000 instructions to update some 500,000 pixels per frame (15 cycles per pixel), at 30fps, that's around 300MHz (assuming 1 instruction = 1 cycle on your system) you need to continually be achieving to keep the graphics running smoothly (not taking into account complex game logic, updating input, audio, physics, AI, etc). That is why you need to employ a variety of tricks through hardware acceleration.
For example, in tile-based rendering, you load in a palette of tiles, and then you can place these tiles (via their index number) onto multiple background layers (advanced chips that Nintendo use allow these background layers to be rotated, scaled, and scrolled), which are loaded into the GPU registers. These are persistent, so there is no per-frame logic required to keep the background drawn (unless it is scrolling, then you need some logic to change the layer's offset and load the tiles along the side (perhaps in the 100s of instructions per frame in comparison to 10,000,000 in a linear frame buffer)). You can also have hardware accelerated sprites, that can be moved/rotated/scaled/animated by tweaking a few GPU registers.
In my console, I provided hardware accelerated 2D rendering of quads/triangles/lines that could be rendered into textures. I intended the system to use a variety of tricks rather than rendering directly to the screen. For example, you would render a complex background that required many render calls into into a single texture you could render with just one. The same with characters (render several layers with blending effects to construct the final frame of a character's animation). Though not as fast as tile-based rendering, I was impressed with how it preformed in my emulator.
Designing your hardware so you can keep things down to as minimal cycles as possible I think is essential. Especially since the emulation isn't going to be that particularly fast. I even had a memory acceleration chip that hardware accelerated memset/memcpy, so the emulator could do that natively (e.g. when loading textures) much faster than emulating each instruction for each byte of memory to copy.
My OS is Perception.
Re: Commodore 64 and misc
Sigh, that is so cool... Any images on-line perhaps? Since I know squat about hardware, I once wrote an emulator for a home computer style computer (16 bit CPU, 64 KB of memory, 512x384 display of max. 16 simultaneous colours (out of 64), OPL style sound). If only I knew something about FGPAs, I'd implement it in hardware...MessiahAndrw wrote:I created a virtual video game console and wrote a tool chain and emulator for it.
JAL
-
DeletedAccount
- Member
- Posts: 566
- Joined: Tue Jun 20, 2006 9:17 am
Re: Commodore 64 and misc
Hi,
Thanks MessiahAndrw for your reply . It really was helpful . Thanks to JhonnytheDon too , I have purchased that book [:)] . This book was my first purchase from amazon , first thing i did for myself when i got my first salary
But you seem to use Open GL ,MessiahAndrw , I am using the plain old GDI for graphics . I will post the some links and resources after I am done .
Waiting for reply from other members too .....
Regards
Shrek
Thanks MessiahAndrw for your reply . It really was helpful . Thanks to JhonnytheDon too , I have purchased that book [:)] . This book was my first purchase from amazon , first thing i did for myself when i got my first salary
But you seem to use Open GL ,MessiahAndrw , I am using the plain old GDI for graphics
. I will post the some links and resources after I am done .Waiting for reply from other members too .....
Regards
Shrek
-
AndrewAPrice
- Member
- Posts: 2299
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
Re: Commodore 64 and misc
Pretty cool, and basically what I have started years ago. Seeing your project, I think I'm gonna restart mine, it's so cool to do this stuff :)).MessiahAndrw wrote:Here you go:
JAL