Gameboy on 32X

mic_ · Post by **mic_** » Wed Jan 21, 2009 10:37 am

Here's something I've been tinkering with a bit lately:

It's dog slow right now, because the code is all plain C that hasn't been optimized or tweaked for the 32X. There's also some weird bug that seems to corrupt the ROM if I add a .gb file larger than 128kB (this doesn't happen with the PC version).

ob1 · Post by **ob1** » Wed Jan 21, 2009 11:19 am

Hey ! Looks interesting.
;)
Any way to look into your sources ?

mic_ · Post by **mic_** » Wed Jan 21, 2009 11:47 am

Perhaps after I've cleaned it up a bit and fixed some bugs. Right now it's quite useless.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Wed Jan 21, 2009 2:06 pm

wow, this is awesome Ö

AamirM · Post by **AamirM** » Wed Jan 21, 2009 6:57 pm

Dude, that is just so cool and awesome!!

Jorge Nuno · Post by **Jorge Nuno** » Wed Jan 21, 2009 9:05 pm

W00t!

Doesn't the gameboy have the Z80 as a CPU? maybe it could be ran "almost" natively on the megadrive.

Shiru · Post by **Shiru** » Wed Jan 21, 2009 9:12 pm

Jorge Nuno wrote:Doesn't the gameboy have the Z80 as a CPU?

Not, it has it's own unique CPU, something between 8080 and Z80, partially compatible.

Jorge Nuno · Post by **Jorge Nuno** » Wed Jan 21, 2009 9:16 pm

Well what if the 68k supervises the code for z80 unknown instructions and handle them, while it feeds the z80 with pure code. I don't know if it is possible to do that fast enough, doing the address translation at the same time.

mic_ · Post by **mic_** » Thu Jan 22, 2009 5:17 pm

I've looked at the SH2 assembly that gcc generates (I'm compiling with -O2) for my emulator, and it's a real piece of crap compared to what even an SH novice like me could accomplish. To achieve any kind of decent speed - especially for the CPU emulation - it'd probably be necessary to write the whole thing from scratch in assembly.

mic_ · Post by **mic_** » Thu Jan 22, 2009 5:22 pm

Just as an example; a function that contains only "return 0;" gets compiled into:

Code: Select all

	mov.l	r14,@-r15
	mov	#0,r0
	mov	r15,r14
	mov	r14,r15
	rts     
	mov.l	@r15+,r14

Plain awesomeness..

That could be reduced by 67%. And it just goes on like that.

TMorita · Post by **TMorita** » Thu Jan 22, 2009 8:36 pm

mic_ wrote:Just as an example; a function that contains only "return 0;" gets compiled into:
Code: Select all
	mov.l	r14,@-r15
	mov	#0,r0
	mov	r15,r14
	mov	r14,r15
	rts     
	mov.l	@r15+,r14
Plain awesomeness.. That could be reduced by 67%. And it just goes on like that.

GCC is creating a stack frame. You need to use -fomit-frame-pointer to disable this.

Toshi

mic_ · Post by **mic_** » Thu Jan 22, 2009 8:43 pm

GCC is creating a stack frame.

Yes, I know, it's the same on most processors. That was just an example of the overall (lack of) quality of the code.

Chilly Willy · Post by **Chilly Willy** » Thu Jan 22, 2009 10:15 pm

mic_ wrote:
GCC is creating a stack frame.
Yes, I know, it's the same on most processors. That was just an example of the overall (lack of) quality of the code.

Except that IS quality code... for code with a stack frame. It's not gcc's fault you made no use of the stack frame when you told it to make one. I'm not saying a compiler can beat hand-done assembly, but the code produced is much better than you're saying.

tomaitheous · Post by **tomaitheous** » Fri Jan 23, 2009 7:56 am

Awesome project

Let's hope you can get GBC cpu core running full speed as well.

mic_ · Post by **mic_** » Fri Jan 23, 2009 8:36 am

Code: Select all

Let's hope you can get GBC cpu core running full speed as well.

The CPU is the same, it just runs at twice the clock frequency. I don't see a system with an 8MHz gb-z80 being emulated at full speed on the 32X. Even at normal frequency it's very far from full speed.