With the progression of Chip8, Gameboy, NES, SMS, I think this is a good next step for someone who wants to try something else that's a little bit more complex but not a lot. Not too many games were released compared to its contemporaries, with most of them being released in Japan. Still, a number of pretty great games did make it (even in America) and it's a system that gets a lot of mileage for its simplicity. I had one as a kid and it was pretty cool. By the way, it was also known as TurboGrafx-16 in America.
Here's some information:
CPU: 65c02 variant called Hu6280. It has all of the opcodes 65c02 has over 6502 plus several new ones specific to the CPU. It also has an MMU which maps the 64KB virtual address space to 8 8KB segments mapping to a 21bit (2MB) physical address space. Can run in two clock speeds, ~7.1MHz and ~1.78MHz (most games will run in the former of course).
Memory: The memory map is quite simple. ROMs can be up to 1MB and take up the first half, RAM is 8KB and takes up a single segment, and I/O also takes up a segment at the end.
Timer: There's a single timer that counts down at a fixed rate (once per 1024 timer cycles). The timer runs at ~7.1MHz, so the actual rate you can get is under 7KHz.
Video: Background graphics are very simple. There is one background composed of 8x8 4bpp tiles. It can be up to 128x64 tiles in size (freely scrolling). There are no tile options, just straight tiles, but because of this you can have quite a number of them (basically, as many as you have room for). 64KB of RAM gives a decent amount of space for graphics, and the palette allows for 241 background colors onscreen. There are 64 sprites which may appear above or beneath the background and are composed of 16x16 4bpp "patterns" such that they may be anywhere from 16x16 to 32x64 in size. There's a limit of 16 sprites per scanline; unfortunately a 32 wide one counts as two so you can't get too far in simulating additional layers with sprites (and expect to still have normal sprites on top of them). Sprites take from a complete separate 241 color palette. Colors in general are 9bpp, so there are 512 different colors to choose from (in other words, you can display most of them onscreen at the same time without even resorting to raster tricks). Speaking of raster tricks, the PC-Engine can generate interrupts mid-scanline at a given scanline number, when the sprite limit is hit, or when scanline 0 collides with the background (so all in all the whole video chip is a lot like an NES PPU on steroids and without the silly limitations). Games use this all the time. The resolutions can vary quite a bit, with three dot clocks to choose from giving a horizontal resolution and 242 lines of vertical display (you can select which of these to actually draw from, and how many tiles per scanline to draw as well).
DMA: The only true DMA on the machine transfers between VRAM (or the sprite table which is in VRAM anyway). However, there are some block transfer instructions too, which should be quite a bit faster than writing loops for it.
Sound: 6 PSGs with some additional functionality. The interesting thing is that you can freely program the waveforms on each of them. PSG #2 can be used to drive an LFO for channel #1 form simple FM synthesis. PSGs #5 and #6 can be set to output noise instead of their waveforms. Finally, you can configure the channels to accept direct digital input, but if you use the timer you won't achieve very high sample rates. I imagine you could use the vertical coincidence interrupts to have audio almost twice that quality (a little under 16KHz) but I don't know if anyone did this.
Add-ons: The big one is the CD-ROM add-on. It only adds the CD-ROM driver itself, more RAM, and ADPCM hardware so it shouldn't be too terrible to emulate on top of a base emulator. There was also a system called "SuperGrafx" which basically was a PC-Engine with two video chips, that would combine the results of the two into layers. Finally, some games had additional hardware (one has bank mapping, another has battery backed up RAM) and there were some more peripherals. For instance, an adapter was needed for more than one player to play a game (only one controller port). There was a mouse too.
All in all I think it shouldn't really be harder to emulate than NES. On the one hand it has more CPU instructions and there's a little bit more to the video (all the resolution stuff in particular) and it has more flexible audio, but on the other hand it provides less in hardware for the audio (ie, no envelopes, sweep, things like that) and you don't have to worry about the huge assortment of mappers. If you already have a 6502 CPU emulator and a framework for emulating video then you should be in good shape for moving forward. What's more, there's even a freely available PC-Engine C compiler called HuC if you want to test your own code against the emulator, but it generates pretty bad code (and doesn't really support a lot of C).
I've been working on one myself for the past couple weeks here and there. Right now it's displaying proper graphics from at least a lot of games (but no sprites, I wanted to work out some CPU bugs first). This is my first time doing a 6502 variant so it was a bit annoying. I still recommend it though.
Some good docs can be found on romhacking.net:
http://www.romhacking.net/?category...ge=documents&level=&docsearch=Go&title=&desc=
Forewarning: I really don't think any of the docs are 100% accurate. They have little errors here and there and don't cover important things (like USA ROM encryption) so if in doubt you should check out a good existing open source emulator like Hu-Go. Hopefully if anyone gets started with this this thread will be a good place to confer information on it.
Here's some information:
CPU: 65c02 variant called Hu6280. It has all of the opcodes 65c02 has over 6502 plus several new ones specific to the CPU. It also has an MMU which maps the 64KB virtual address space to 8 8KB segments mapping to a 21bit (2MB) physical address space. Can run in two clock speeds, ~7.1MHz and ~1.78MHz (most games will run in the former of course).
Memory: The memory map is quite simple. ROMs can be up to 1MB and take up the first half, RAM is 8KB and takes up a single segment, and I/O also takes up a segment at the end.
Timer: There's a single timer that counts down at a fixed rate (once per 1024 timer cycles). The timer runs at ~7.1MHz, so the actual rate you can get is under 7KHz.
Video: Background graphics are very simple. There is one background composed of 8x8 4bpp tiles. It can be up to 128x64 tiles in size (freely scrolling). There are no tile options, just straight tiles, but because of this you can have quite a number of them (basically, as many as you have room for). 64KB of RAM gives a decent amount of space for graphics, and the palette allows for 241 background colors onscreen. There are 64 sprites which may appear above or beneath the background and are composed of 16x16 4bpp "patterns" such that they may be anywhere from 16x16 to 32x64 in size. There's a limit of 16 sprites per scanline; unfortunately a 32 wide one counts as two so you can't get too far in simulating additional layers with sprites (and expect to still have normal sprites on top of them). Sprites take from a complete separate 241 color palette. Colors in general are 9bpp, so there are 512 different colors to choose from (in other words, you can display most of them onscreen at the same time without even resorting to raster tricks). Speaking of raster tricks, the PC-Engine can generate interrupts mid-scanline at a given scanline number, when the sprite limit is hit, or when scanline 0 collides with the background (so all in all the whole video chip is a lot like an NES PPU on steroids and without the silly limitations). Games use this all the time. The resolutions can vary quite a bit, with three dot clocks to choose from giving a horizontal resolution and 242 lines of vertical display (you can select which of these to actually draw from, and how many tiles per scanline to draw as well).
DMA: The only true DMA on the machine transfers between VRAM (or the sprite table which is in VRAM anyway). However, there are some block transfer instructions too, which should be quite a bit faster than writing loops for it.
Sound: 6 PSGs with some additional functionality. The interesting thing is that you can freely program the waveforms on each of them. PSG #2 can be used to drive an LFO for channel #1 form simple FM synthesis. PSGs #5 and #6 can be set to output noise instead of their waveforms. Finally, you can configure the channels to accept direct digital input, but if you use the timer you won't achieve very high sample rates. I imagine you could use the vertical coincidence interrupts to have audio almost twice that quality (a little under 16KHz) but I don't know if anyone did this.
Add-ons: The big one is the CD-ROM add-on. It only adds the CD-ROM driver itself, more RAM, and ADPCM hardware so it shouldn't be too terrible to emulate on top of a base emulator. There was also a system called "SuperGrafx" which basically was a PC-Engine with two video chips, that would combine the results of the two into layers. Finally, some games had additional hardware (one has bank mapping, another has battery backed up RAM) and there were some more peripherals. For instance, an adapter was needed for more than one player to play a game (only one controller port). There was a mouse too.
All in all I think it shouldn't really be harder to emulate than NES. On the one hand it has more CPU instructions and there's a little bit more to the video (all the resolution stuff in particular) and it has more flexible audio, but on the other hand it provides less in hardware for the audio (ie, no envelopes, sweep, things like that) and you don't have to worry about the huge assortment of mappers. If you already have a 6502 CPU emulator and a framework for emulating video then you should be in good shape for moving forward. What's more, there's even a freely available PC-Engine C compiler called HuC if you want to test your own code against the emulator, but it generates pretty bad code (and doesn't really support a lot of C).
I've been working on one myself for the past couple weeks here and there. Right now it's displaying proper graphics from at least a lot of games (but no sprites, I wanted to work out some CPU bugs first). This is my first time doing a 6502 variant so it was a bit annoying. I still recommend it though.
Some good docs can be found on romhacking.net:
http://www.romhacking.net/?category...ge=documents&level=&docsearch=Go&title=&desc=
Forewarning: I really don't think any of the docs are 100% accurate. They have little errors here and there and don't cover important things (like USA ROM encryption) so if in doubt you should check out a good existing open source emulator like Hu-Go. Hopefully if anyone gets started with this this thread will be a good place to confer information on it.