I did this a long time ago, but it just crashed...

[OneThirty8]

Nice work! Good luck with this! ;D

[Darksaviour69]

wow your going to be very popular when u release! btw whats the speed like?

[quzar]

frankly the speed is crap. Ive already managed to pretty much double it thoug by removing SDL controls, but it still has a long way to go.

[BlackAura]

What kind of setup (KOS/SDL/Whatever, compiler, newlib/koslibc) are you using at the moment?

From the specs, it sounds like you'll have the same kind of speed problems we've been having with Genesis Plus. If you can find some technical documents on the PCE's graphics hardware, you might be able to pull off the same stunt I did with Genesis Plus. Assuming there's nothing completely insane about the graphics hardware (and there might be - look at the NES or the SNES for example), it might actually be easier, because the graphics hardware seems a lot less flexible than the MD's...

Just found some documentation on it...

http://cgfm2.emuviews.com/txt/pcetech.txt

It seems that the PCE's graphics hardware is quite similar to the MD. The three main differences:

More available colours (256 for backgrounds, 256 for sprites)
Only one background layer
Tile data is stored in planar format (aaaaaargh!)

So, actually rendering things to the screen using hardware acceleration would be easier, assuming few games need really accurate emulation, and converting the tile data into a usable format would be much harder...

[quzar]

frankly i dont know how to do that. not only would i be at a loss without studying the code already in hugo, at the moment its all so cluttered that i can barely understand it.

my setup is kos 1.1.9/ SDL that ian released on his site [not sure whatversion] , gcc 3.3.3, and the libc is the kos 1.1.9 version.

also, what i really need is documentation on the SuperGraphx because as far as i can tell, this emulates that, not the original TG-16/PCE

[quzar]

For anyone familiar with this game, you'll know that its a CD game =).

[BlackAura]

Doing hardware acceleration for a Supergrafx would probably be more difficult than a MegaDrive, actually. The Supergrafx has two separate video chips, and the output is composited by an extra video chip, based on all sorts of funky things. I did find some documentation on it though, which is only useful if you have the TG16 documentation too.

http://cgfm2.emuviews.com/txt/sgxtech.txt

The same guy who wrote boththose documents also wrote Genesis Plus, the documents I've been using as a reference for the MD VDP, and a TG16 emulator. His code is probably a lot neater than the HuGo code, so you could probably read through that and compare them. The only way I managed to understand the MD VDP as well as I do (which isn't all that well) was by studying the documentation, a couple of MD emulators, and writing an emulator for it.

Of course, you shouldn't bother doing that until everything else works as well as it's going to, and even then only if you can't think of a better way to speed it up. It's kinda tricky, mostly because dealing with the Dreamcast's hardware is tricky.

Speaking of which, nice job getting CD emulation working. Is that running from a CD image, or a CD?

[quzar]

Whats funny is that it actually has run CD games the whole time, i just hadnt tried =P. Its running off an ISO. I have yet to test an actual CD but I seriously doubt it would work because I had to hack out some key CD reading funcions in order to get it to compile (ive gotta figure out how to re-write that later =\). I'm also not sure wether or not it can read the mp3 files corresponding to the isos (or how this will affect speed).

The next biggest thing I need to do is rewrite the SDL rendering to PVR rendering. Right now the way it works is that there is are multiple 'osd' versions of the screen display routine, while the core renderer is portable. Ill be looking at a few DC emulators to see about how to do so.

[BlackAura]

The MP3 decoding will just slow things down too much. Unless it's running well above 100%, then it's not worth it. It you get support for real CDs working, it won't even be necessary - you can just use CD audio. Failing that ISO + uncompressed WAV would work...

I wouldn't bother with a PVR renderer at the moment. Unless you want to be able to stretch the screen easily, it would be easier to just dump the image directly into the framebuffer. If the video output is 16-bit anyway, this should be very easy. If you need to do any kind of pixel format conversion first, it can get a little trickier, but no trickier than using the 3D hardware. Get it into 16-bit colour format, then copy it over using store queues.

[quzar]

Actually, I do kind of need screen size manipulation, because right now that is done in software by SDL.