What's new

PC-Engine

Exophase

Emulator Developer
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.
 

d0u6

New member
lets start.

i will begin from zero..... Soon I'll post my state and my doubts....

This forum is very down lately, and I hope this topic change this......

I'll post my progress in my site (www.infotalkers.com).

Ps, i write my site both in english and portuguese, because there are few document about this subject in portuguese......
 
OP
E

Exophase

Emulator Developer
d0u6; You should let us know if the Portuguese docs have anything the English ones don't. You can translate for us. :B Good luck! BTW, your page appears to be down :(

Here's hoping we can get this thread stickied like the rest of them.
 

d0u6

New member
Hi...

There are few portuguese docs about emulation. I'm doing several of them based on my experience reading the english ones..... There are few people that do (and did) that.
I love to program this type of software, but my progress is slow, because I have to do this on my free time. :(

And my site will be down untill tomorrow. Sorry...:(
 
Last edited:

aprentice

Moderator
i'll sticky this thread once i see everyone is serious about it, i'm looking to do another emulator but only for a well documented console ;)
 
OP
E

Exophase

Emulator Developer
i'll sticky this thread once i see everyone is serious about it, i'm looking to do another emulator but only for a well documented console ;)

I think it's well documented enough, there are just some ambiguities and a few mistakes. The sufficient docs aren't all in one single location unlike all the consoles Martin Korth got to (and others like anomie on SNES), but I think the information is largely there. These docs should be enough to cover everything you need to emulate most games correctly:

- Charles MacDonald's TG16 hardware notes covers the VDC, VCE, DMA, Timer, IRQ, and I/O in mostly sufficient depth, and also has information on CD-ROM. It's as close as you'll get to a centralized piece of PC-Engine documentation. The only major things that aren't really complete are CPU info, PSG, and some VDC register locations. The other docs will get you covered for this. NOTE: The I/O bit designations appear to have an error, you should swap right and down.

- 65xx Processor Data has in-depth information on Hu6280, although I think some of it might be slightly innaccurate - it's probably best to go with Charles MacDonald's doc in the areas that don't agree with each other. http://www.romhacking.net/docs/65xx-Processor-Data.zip

- VDC/VCE registers are all described in this document:
http://www.romhacking.net/docs/301/
This is a good hard reference for register locations (Charles MacDonald's VDC information doesn't list all of them but does refer to most of them by name)

- PSG is documented well in psg.txt here: http://www.romhacking.net/docs/[356]PC_Engine_docs.zip

There are a couple other things that I haven't found in the documentation, but I'm sure exists somewhere (aside from source code of other emulators, which is where I found it). Big ones that you need to get some ROMs working are encryption that's present in some USA (TurboGrafx) games, and the weird mirroring of 384KB ROMs. I can describe both of those here (but not in this post)
 
OP
E

Exophase

Emulator Developer
Note: The SAT (sprite attribute table) isn't actually in VRAM like I thought it was (like the VDC document I linked to seems to state), there's a dedicated 512 byte block of RAM for it. However, you can only access it by using DMA from VRAM to it. This means that you need to have a shadow buffer for it in VRAM, and I think this is the buffer the documents are referring to (called SATB, I guess SAT buffer). The important thing is that changes to this buffer don't actually reflect changes in the sprites until the DMA is performed. I think that the DMA can only be done during vblank, so this means it's impossible to change sprite attributes mid-scanline. The good thing about this is that it means you can pre-scan sprite attributes at the beginning of a frame (or during the vblank of the previous frame) to determine where the overflow will occur and where sprite 0 IRQ may occur.

However I need confirmation that the SAT DMA can only happen during vblank (and gets delayed until it otherwise). Charles MacDonald's doc only says this about VRAM to VRAM DMA.
 
OP
E

Exophase

Emulator Developer
Nobody cares about PC-Engine :(

I haven't been working much but in a fit of insomnia, stress, and irritation with myself I pulled through and got more stuff working last night (and then only got 4 hours of sleep, yay). I'll post screenshots later today, not that anyone cares :B
 

Danny

Programmer | Moderator
Nobody cares about PC-Engine :(

I haven't been working much but in a fit of insomnia, stress, and irritation with myself I pulled through and got more stuff working last night (and then only got 4 hours of sleep, yay). I'll post screenshots later today, not that anyone cares :B

Cool you have a PC-Engine emulator running some stuff? I would like to see screens :D
 

aprentice

Moderator
Nobody cares about PC-Engine :(

I haven't been working much but in a fit of insomnia, stress, and irritation with myself I pulled through and got more stuff working last night (and then only got 4 hours of sleep, yay). I'll post screenshots later today, not that anyone cares :B

Post some screens and tell us what you done so far ;)
 
OP
E

Exophase

Emulator Developer
Thanks aprentice XD

Here are some screenshots that aren't totally glitched out.

I think a lot is still broken (with the CPU emulation I suppose...), and a few important things are unimplemented (well, the graphics are pretty crude at this point)

For some reason emulating it has been more annoying than I thought it'd be. Oh well, I should have some more momentum now.
 

xtra krazzy

Dolphin Developer
Looking good, I don't see too many graphic flaws (compared to DS emulation one year ago :p).

What is the problem with CPU emulation? Unimplemented instructions? Speed issues?

Do you emulate the sound? How? MIDI?

FPS plz.
 
OP
E

Exophase

Emulator Developer
Looking good, I don't see too many graphic flaws (compared to DS emulation one year ago :p).

What is the problem with CPU emulation? Unimplemented instructions? Speed issues?

Do you emulate the sound? How? MIDI?

FPS plz.

There's no sound yet, I'm not going to use MIDI, that'd be very inaccurate. There aren't unimplemented instructions except the clock speed ones that don't really matter (as far as I know).. If I knew what was wrong I'd fix it. Those are things to figure out when doing any emulator -_-

I'm not going to focus on optimizing it that much for PC. But the graphics are probably really slow right now because it's not properly caching tiles (but it still runs fine at full speed because it's on a modern computer that's more than fast enough >_>).. I did put some thought into putting down a framework that'll be fast enough while being easy to make accurate, though.

I do plan on optimizing the code for ARM later.
 

Danny

Programmer | Moderator
There's no sound yet, I'm not going to use MIDI, that'd be very inaccurate. There aren't unimplemented instructions except the clock speed ones that don't really matter (as far as I know).. If I knew what was wrong I'd fix it. Those are things to figure out when doing any emulator -_-

I'm not going to focus on optimizing it that much for PC. But the graphics are probably really slow right now because it's not properly caching tiles (but it still runs fine at full speed because it's on a modern computer that's more than fast enough >_>).. I did put some thought into putting down a framework that'll be fast enough while being easy to make accurate, though.

I do plan on optimizing the code for ARM later.

How long has this taken you out of interest?

You are like a emulator coding speed machine :p
 

Danny

Programmer | Moderator
Few weeks, but I haven't really been working on it very much -_-

Screens are looking great :D Nice work :)

And with you I guess that means like a hour a day :p

I still remember how fast you made that chip8 emulator :evil: Thats not to say the pc engine is as easy as chip8 mind :p You still did one amazingly fast :drool:
 
Last edited:

Top