M68K for DC

[16Bits]

Stef wrote

Hello 16bits, i'm sure we already had some talks together or maybe i'm confusing with someone else...

hi there, hmm I haven't posted anything on dc related forums before, since I just recently got hold of a dreamcast (with mouse and keyboard) courtesy of my brother!

It's true than RISC assembly is somewhat different from CISC one and specially x86, it appears far more limited !

yes and no, it generally takes alot more instructions in risc to do the same thing as in a cisc, that said, it does have alot of clever instructions such as the indirect addressing with post increment, however, in most cases it just requires alot of extra typing, such as the shift instructions that only handles 1, 2, 8 or 16 bit shifts.

You said SNES is complex, i agree, but not about the 65816 CPU which is (imo) simpler than 68000 cpu, the 8/16 bits trick of 65816 isn't a big problem really...

well, actually I didn't say it's complex, only that it's hard to make fast, which I base on the fact that it has to check the accumulator/x,y registers for 8 or 16bit which slows the emulation down. in 16 bit mode the following would be decoded:
a9 00 00 lda #$0000
8d 00 10 sta $1000

in 8bit mode it would be:
a9 00 lda #$00
00 brk
8d 00 10 sta $1000

however, you are right that the video/sound hardware is the big problem of snes emulation

Second, when you're emulating a CPU, asm always help a lot compared to C, because you have access to some low level instruction as ROR / ROL which need several instruction in C.
So, even with the best C code, i think you can at least do 3 time faster in ASM.

well, usually one of the benefits of programming in assembly is that you can designate registers for specific purposes and thus avoid pushing and poping parameters from stack between calls, which helps speed things up alot in tight loops with calls (such as cpu emulators with it's fetch->decode where the instruction opcode value is usually used as an index into a list of function pointers corresponding to the decoding of that instruction), if I could get it 3 times faster in asm than in gcc -O2 then it would definately be worth the work of programming in sh4 asm. I guess the only way to make sure is to compare c code gas output towards my own assembly and see how much better I can make my code. too bad the weather is so great here in sweden now, that I'm spending far too much time on tennis and soccer, barbeque's and beer instead of programming... hmm.. maybe we'll get some rain soon...

btw, how far is the neogeo cd from full speed?

one of the drawbacks of a general system emulation (such as consoles) versus single game emulation (such as arcade games) is that in for example arcade emulation you map out all the graphics/sound banks and can then modify that data in accordance to your needs before the actual emulation starts, whereas in a general emulation system you don't know where the graphics and sound will reside and thus must do all conversion on the fly. one idea I had for my 6502 emulator was to use it to emulate the cpu of the c64, but instead of emulating the c64's graphics hardware strictly, I was thinking of applying a high level emulation of it, allowing to enhance the graphics and sound by simply mapping the video memory, sprite and sound registers to my own handlers that would examine the contents of the memory/registers and update with my own graphics and sound. naturally, this mapping would have to be done on a game per game basis, and would likely take a bit of effort, but the result would be a game with the exact "feel" of the original c64 game, but with enhanced graphics and sound, ahh, it would be sweet!

well, enough babbling from me! I like this place though, nice people who likes to share information and allows people to throw out ideas without getting trashed! and also the dc scene seems to have alot of people looking to push the dreamcast's boundaries, which is I feel it's greatest aspect, as this is to me the greatest charm with a standarised hardware platform.

[Christuserloeser]

[quote author=16Bits link=board=dcemu;num=1083323639;start=150#150 date=06/01/04 at 17:45:33]btw, how far is the neogeo cd from full speed?[/quote]

@Stef & 16Bits: Give it a try! It runs with backups as far as I know (not tested). I've tested it with my Pulstar and it runs at a very playable speed and with full CDDA support! It is faster than DreamSNES in every way, a good reason to buy all the great NeoGeoCD games out there! Fantastic work by Ian Micheal, Fosters and the team that is!

[quzar]

right now it is being run underclocked by quite a bit ( double cycles ) as well as frameskip that i have come to realize is automatic maxed at 4 (or something close to that).

[wraggster]

Quick question, is PC Engine cd emulation a reachable target for emulation?

[quzar]

yes.

[wraggster]

and ahem hows the Neopocket emu going

[quzar]

:-[ thats all i have to say. well maybe this. i will get it working. i had one month struggling trying to get it to load roms. methods working on every other test would not respond in it, in this time i hacked up soo much of the code that when i got rom loading working, the emulation was broken. so yes. reset for me :P

[Christuserloeser]

Oh, I'd love to play that Cotton game...

I wish you success ;D

[quzar]

;D

[Stef]

[quote author=16Bits link=board=dcemu;num=1083323639;start=150#150 date=06/01/04 at 17:45:33]
hi there, hmm I haven't posted anything on dc related forums before, since I just recently got hold of a dreamcast (with mouse and keyboard) courtesy of my brother![/quote]

Not here, actually it's because of your nick... i'm the author of Gens and i though you were from "16bits" site

yes and no, it generally takes alot more instructions in risc to do the same thing as in a cisc, that said, it does have alot of clever instructions such as the indirect addressing with post increment, however, in most cases it just requires alot of extra typing, such as the shift instructions that only handles 1, 2, Â*8 or 16 bit shifts.

Yeah, but the most irritating for me is loading immediate data in register of course (and hopefully), we can do the same as CISC cpu except it takes almost time more instructions.

well, actually I didn't say it's complex, only that it's hard to make fast, which I base on the fact that it has to check the accumulator/x,y registers for 8 or 16bit which slows the emulation down. in 16 bit mode the following would be decoded:
a9 00 00 Â* Â* lda #$0000
8d 00 10 Â* Â* sta $1000

in 8bit mode it would be:
a9 00 Â* Â* Â* Â* Â*lda #$00
00 Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â* Â*brk
8d 00 10 sta $1000

Here's a way to handle that without any significant speed loss :
i guess base opcode are 8 bits length on 65816 CPU... so we can use a 256 jump table as dispatch method.
If EBX register (x86 cpu) contains opcode in low 8 bits (jmp dword [JumpTable + ebx * 4] for dispatch), we can use bit 9 to store the current operating mode :
0 = 8 bits and 1 = 16 bits...

then we have a 512 lenght jump table, where firsts 256 entries are for 8 bits instructions and lasts 256 for 16 bits ones
I don't know if that could be really applied to the 65816 cpu, but anyway i'm sure we can always find a solution.

well, usually one of the benefits of programming in assembly is that you can designate registers for specific purposes and thus avoid pushing and poping parameters from stack between calls, which helps speed things up alot in tight loops with calls (such as cpu emulators with it's fetch->decode where the instruction opcode value is usually used as an index into a list of function pointers corresponding to the decoding of that instruction), if I could get it 3 times faster in asm than in gcc -O2 then it would definately be worth the work of programming in sh4 asm. I guess the only way to make sure is to compare c code gas output towards my own assembly and see how much better I can make my code. too bad the weather is so great here in sweden now, that I'm spending far too much time on tennis and soccer, barbeque's and beer instead of programming... hmm.. maybe we'll get some rain soon...

I already compared asm generated by GCC against my own asm file and really, we do easily better... specially for the SH-4 cpu where we have many available registers.

@Stef & 16Bits: Give it a try! It runs with backups as far as I know (not tested). I've tested it with my Pulstar and it runs at a very playable speed and with full CDDA support! It is faster than DreamSNES in every way, a good reason to buy all the great NeoGeoCD games out there! Fantastic work by Ian Micheal, Fosters and the team that is!

Is the bios working ? is it sufficient to test emulator speed ? i'll probably give a try anyway...