GBA on DC again!!!!! (sorry if it's like repeating)

Johnnylee_hang · Post by **Johnnylee_hang** » Wed Feb 04, 2004 1:03 pm

It's like the same words and all, but I believe what people who discuss in this Fourm said. Give any sugguestion to me if ya felt me! Let's hope and kept hoping until we get it!

Vchat20 · Post by **Vchat20** » Wed Feb 04, 2004 1:12 pm

as much as id like to see a gba emulator for the dc, i think the major drawback is gonna be proccessing power. cuz so far i havent seen a single rom go more than 10MB. as a matter of fact, i got the roms of the latest pokemon games, Fire Red And Leaf Green (Japanese btw) and they are only 8MB a peice.

edit: scratch that. pparently i was wrong. both are exactly 16MB a peice extracted. but zipped up are only 4.4MB. so in any case the RAM issue should not be a problem.

Strapping Scherzo · Post by **Strapping Scherzo** » Wed Feb 04, 2004 1:26 pm

Vchat20 wrote:as much as id like to see a gba emulator for the dc, i think the major drawback is gonna be proccessing power. cuz so far i havent seen a single rom go more than 10MB. as a matter of fact, i got the roms of the latest pokemon games, Fire Red And Leaf Green (Japanese btw) and they are only 8MB a peice.

edit: scratch that. pparently i was wrong. both are exactly 16MB a peice extracted. but zipped up are only 4.4MB. so in any case the RAM issue should not be a problem.

Memory would be an issue since the DC only has 16MB of main memory. And you can't emulate the game fast enough out of compressed data. It needs to decompressed. So where would the emulator's program fit?! Forget about it.

Ian Micheal · Post by **Ian Micheal** » Wed Feb 04, 2004 1:37 pm

You could do some thing like this

Code: Select all

Why use overlays?
-----------------

Overlays allow you to free up system memory by partitioning a large program
into smaller chunks which are loaded sequentially.

Planning for overlays
---------------------

To use overlays, you need to divide your program into multiple logical pieces
that do not call each other (overlays) which share a common set of routines
(the base).

For example, for a game you may have the intro sequence as overlay1, 
the menu system as overlay2, and the main game sequence as overlay3,
and a high score display as overlay4.

If your 3D library was used by all your overlays, then you would probably
put it in the base to avoid code duplication. If it was only used by one
overlay you would probably include it in the particular overlay.

The rule to remember is that overlays can call any routines in the base
at any time because the base is always loaded. The base can only call
routines in a particular overlay only if the particular overlay is known
to be loaded (you must check manually). Routines in different overlays
cannot call each other.

Actually using overlays
-----------------------

To create an overlay, here's what you do:

First you need an SOA GNU toolset at least SOA-960119 or later.
All versions of the linker before SOA-960119 have a problem
which prevents this overlay technique from working properly.

Given these files:

--> file0.c:

void func1(void) {}
void func2(void) {}
void func3(void) {}

void main(void)

{
	overlay1();
	overlay2();
	overlay3();
}

--> file1.c:

void overlay1(void)

{
	func1();
	func2();
	func3();
}

--> file2.c:

void overlay2(void)

{
	func1();
	func2();
	func3();
}

--> file3.c:

void overlay3(void)

{
	func1();
	func2();
	func3();
}

and you want:

file0.c <- base module
file1.c <- 1st overlay
file2.c <- 2nd overlay
file3.c <- 3rd overlay

with memory map:

0x1000: base module  (file0.c)
0x2000: overlay area (file1.c file2.c file3.c)

Here's how you'd link the files together:

rem Overlay Demo
rem make base.o
gcc -c file0.c
ld -Ttext 0x1000 -r file0.o -o base.o
rem make overlay1.o
gcc -c file1.c
ld  -Ttext 0x2000 -r file1.o -o overlay1.o
rem make overlay2.o
gcc -c file2.c
ld  -Ttext 0x2000 -r file2.o -o overlay2.o
rem make overlay3.o
gcc -c file3.c
ld  -Ttext 0x2000 -r file3.o -o overlay3.o
rem make base module
ld -L<gcc lib path> -L<libc lib path> -Ttext 0x1000 -o base base.o -R overlay1.o -R overlay2.o -R overlay3.o
rem make overlay1
ld -Ttext 0x2000 -o overlay1 overlay1.o -R base.o
rem make overlay2
ld -Ttext 0x2000 -o overlay2 overlay1.o -R base.o
rem make overlay3
ld -Ttext 0x1000 -o overlay3 overlay1.o -R base.o

"objdump --disassemble-all base" yields:

base:     file format coff-sh

Disassembly of section .text:
00001000 <_func1> mov.l	r14,@-r15
00001002 <_func1+2> mov	r15,r14
00001004 <_func1+4> mov	r14,r15
00001006 <_func1+6> mov.l	@r15+,r14
00001008 <_func1+8> rts		(slot nop	)
0000100c <_func2> mov.l	r14,@-r15
0000100e <_func2+2> mov	r15,r14
00001010 <_func2+4> mov	r14,r15
00001012 <_func2+6> mov.l	@r15+,r14
00001014 <_func2+8> rts		(slot nop	)
00001018 <_func3> mov.l	r14,@-r15
0000101a <_func3+2> mov	r15,r14
0000101c <_func3+4> mov	r14,r15
0000101e <_func3+6> mov.l	@r15+,r14
00001020 <_func3+8> rts		(slot nop	)
00001024 <_main> mov.l	r8,@-r15
00001026 <_main+2> mov.l	r14,@-r15
00001028 <_main+4> sts.l	pr,@-r15
0000102a <_main+6> mov	r15,r14
0000102c <_main+8> mov.l	0x104c,r8
0000102e <_main+a> jsr	@r8	(slot nop	)
00001032 <_main+e> mov.l	0x1050,r8
00001034 <_main+10> jsr	@r8	(slot nop	)
00001038 <_main+14> mov.l	0x1054,r8
0000103a <_main+16> jsr	@r8	(slot nop	)
0000103e <_main+1a> mov	r14,r15
00001040 <_main+1c> lds.l	@r15+,pr
00001042 <_main+1e> mov.l	@r15+,r14
00001044 <_main+20> mov.l	@r15+,r8
00001046 <_main+22> rts		(slot nop	)
...
0000104e <_main+2a> mov.b	r0,@r0  <- 0x2000, correct
00001050 <_main+2c> .word 0x0000
00001052 <_main+2e> mov.b	r0,@r0  <- 0x2000, correct
00001054 <_main+30> .word 0x0000
00001056 <_main+32> mov.b	r0,@r0  <- 0x2000, correct

"objdump --disassemble-all overlay1" yields:

overlay1:     file format coff-sh

Disassembly of section .text:
00002000 <_overlay1> mov.l	r8,@-r15
00002002 <_overlay1+2> mov.l	r14,@-r15
00002004 <_overlay1+4> sts.l	pr,@-r15
00002006 <_overlay1+6> mov	r15,r14
00002008 <_overlay1+8> mov.l	0x2028,r8
0000200a <_overlay1+a> jsr	@r8	(slot nop	)
0000200e <_overlay1+e> mov.l	0x202c,r8
00002010 <_overlay1+10> jsr	@r8	(slot nop	)
00002014 <_overlay1+14> mov.l	0x2030,r8
00002016 <_overlay1+16> jsr	@r8	(slot nop	)
0000201a <_overlay1+1a> mov	r14,r15
0000201c <_overlay1+1c> lds.l	@r15+,pr
0000201e <_overlay1+1e> mov.l	@r15+,r14
00002020 <_overlay1+20> mov.l	@r15+,r8
00002022 <_overlay1+22> rts		(slot nop	)
...
0000202a <_overlay1+2a> mov.l	r0,@(0,r0)  <- 0x1000, correct
0000202c <_overlay1+2c> .word 0x0000
0000202e <_overlay1+2e> mov.l	r0,@(48,r0) <- 0x100c, correct
00002030 <_overlay1+30> .word 0x0000
00002032 <_overlay1+32> mov.l	r1,@(32,r0) <- 0x1018, correct
Disassembly of section .tors:
Disassembly of section .data:
Disassembly of section .stack

:

You can gain memory by using some thing like this.

ZacMc · Post by **ZacMc** » Wed Feb 04, 2004 1:45 pm

You can gain memory by using some thing like this.

I don't think that would help you fit a 16mb rom and an emu into 16mb of memory.. but I'm no coder.

Ian Micheal · Post by **Ian Micheal** » Wed Feb 04, 2004 2:03 pm

Who would want to do this much work for a 4fps emulator. I dont see the memory problem as the main one.

You can get larger roms to load using some thing like this but the gain might not be enff any way.

sheng · Post by **sheng** » Wed Feb 04, 2004 2:07 pm

Ian Micheal wrote:Who would want to do this much work for a 4fps emulator. I dont see the memory problem as the main one.

You can get larger roms to load using some thing like this but the gain might not be enff any way.

True, we havn't yet got a SNES emulator that run all games in full speed with sound. Making a GBA emulator will be more impossible.

Strapping Scherzo · Post by **Strapping Scherzo** » Wed Feb 04, 2004 2:18 pm

sheng wrote:Making a GBA emulator will be more impossible.

This statement insinuates that making a full speed SNES emulator on DC is some also impossible. It's NOT impossible and I will do it if it's the last thing I do. Banzai!

Sweater Fish · Post by **Sweater Fish** » Wed Feb 04, 2004 2:26 pm

The existing free emulators on the Dreamcast are all ports (with the exception of SMEG) of emulators that were originally written for the PC and with portable code, an emulator written from scratch just for the Dreamcast would stand a much better chance of running a system like the GBA. The Dreamcast is *EASILY* capable of emulating the GBA if its actual potential was tapped. And how about storing the emulator and emulated system RAM in the DC's 4MB of audio RAM? It would take a ton of work and creativity, but there's no reason a GBA emulator wouldn't be possible.

Personally, though, I'd rather see the most dedicated and talented coders in the Dreamcast scene working on homebrew games than coding emulators for the kiddies. If you want to play GBA games on your teevee, buy a Gamecube and GBPlayer.

...word is bondage...

sheng · Post by **sheng** » Wed Feb 04, 2004 2:30 pm

sorry, I didn't mean that

But it would be nice to have a full speed MegaDrive eumlator tho. Hum... I wounder if we ask sega for a copy of their smack pack source code will they give it? (most unlikly but worth writting to them)

Ian Micheal · Post by **Ian Micheal** » Wed Feb 04, 2004 3:28 pm

Genisis plus SDL version is running at 80% on some games with sound maybe you should try it. This emulator is open source and well hit fullspeed. We dont need segagen.I just have not botherd writing a menu and file selector for it Was hoping some one else would take the source and do that. It's not my main worry. I got it to stay in synic with the music thats all i wanted to do. Helped out by Stef d he wrote the sound code for it. SDL version is well behind in features.

sheng · Post by **sheng** » Wed Feb 04, 2004 4:03 pm

Ian Micheal wrote:Genisis plus SDL version is running at 80% on some games with sound maybe you should try it. This emulator is open source and well hit fullspeed. We dont need segagen.I just have not botherd writing a menu and file selector for it Was hoping some one else would take the source and do that. It's not my main worry. I got it to stay in synic with the music thats all i wanted to do. Helped out by Stef d he wrote the sound code for it. SDL version is well behind in features.

The sega smack pack emulator runs games at full speed or not run at all. The sound also works fine too, just need work on to improve it more. It's sad the sega keeps all it's good codes

I've seen the Smack Pack rip which runs sonic 1 and many other games at full speed!

Storminator16 · Post by **Storminator16** » Wed Feb 04, 2004 4:12 pm

Vchat20 wrote: cuz so far i havent seen a single rom go more than 10MB. as a matter of fact, i got the roms of the latest pokemon games, Fire Red And Leaf Green (Japanese btw) and they are only 8MB a peice.

LOL, this thread isn't closed yet?

sheng · Post by **sheng** » Wed Feb 04, 2004 4:13 pm

nope

Ian Micheal · Post by **Ian Micheal** » Wed Feb 04, 2004 4:29 pm

Well it's not running fullspeed it's faking the sound if it was outputing true fm sound like genesis plus i say it would be slower.

A port of genesis plus will go well past segagen soon enff mark my words.
Dont worry about genesis emulation it will reach fullspeed.

Alexvrb · Post by **Alexvrb** » Wed Feb 04, 2004 6:55 pm

sheng wrote:The sega smack pack emulator runs games at full speed or not run at all. The sound also works fine too, just need work on to improve it more. It's sad the sega keeps all it's good codes

I've seen the Smack Pack rip which runs sonic 1 and many other games at full speed!

Anyone who doesn't think the sound in the smash pack was horrible has obviously not owned a Genesis or had it hooked up to junkyard speakers. Even with an RF connection it sounded better, was much clearer if you had a stereo A/V hookup for it.

I'd have to agree with Sweater Fish, but figure the odds you'll see a from-scratch GBA emu on DC anytime soon. Anyway, this hasn't been locked because, umm, people have built up an immunity to these questions?? We'll see who folds first, I guess.

BlackAura · Post by **BlackAura** » Wed Feb 04, 2004 10:29 pm

Ian Micheal wrote:Dont worry about genesis emulation it will reach fullspeed.

Fullspeed isn't actually a problem. Like Super Famicast, Genesis Plus can run pretty much anything you can throw at it full speed (or faster for some games - it was a bit of a shock when I first saw a game running at 120%) assuming you're using fairly high frameskip, or auto frameskip. The tricky part is getting the frameskip down a bit.

Post by **Quzar** » Wed Feb 04, 2004 10:43 pm

Well Ian's definition of fullspeed doesn't seem to mean 'looks fullspeed' which is what something with frameskip does. I'm pretty sure he means more literally that with no frameskip.

sheng · Post by **sheng** » Thu Feb 05, 2004 1:38 am

Alexvrb wrote:
sheng wrote:The sega smack pack emulator runs games at full speed or not run at all. The sound also works fine too, just need work on to improve it more. It's sad the sega keeps all it's good codes

I've seen the Smack Pack rip which runs sonic 1 and many other games at full speed!
Anyone who doesn't think the sound in the smash pack was horrible has obviously not owned a Genesis or had it hooked up to junkyard speakers. Even with an RF connection it sounded better, was much clearer if you had a stereo A/V hookup for it.

I'd have to agree with Sweater Fish, but figure the odds you'll see a from-scratch GBA emu on DC anytime soon. Anyway, this hasn't been locked because, umm, people have built up an immunity to these questions?? We'll see who folds first, I guess.

The reason for that is because Sega only made the code able to run games that are in Smack Pack run, they did not go byone that. The is the reason for bad sound in Smack Pack, and because this is a emulator that was written from scrach for the DC, it's full speed!

By the way if there's a emulator for NeoGeo which have game file above 16mb. GBA max fill size no more than 16mb unzipped, so I don't see y. But I'm no programer, so I don't know.

Sir Slash · Post by **Sir Slash** » Thu Feb 05, 2004 2:42 am

sheng wrote: The reason for that is because Sega only made the code able to run games that are in Smack Pack run, they did not go byone that. .

....yeah but poorly at that