and now with the new Motorola 68000 by Fox68k

Arqueiro · Post by **Arqueiro** » Mon Oct 11, 2004 5:50 am

totaly written in SH4

what we can do ???

BlackAura · Post by **BlackAura** » Mon Oct 11, 2004 6:10 am

Exactly the same as we could do before, maybe a little faster.

Prophet][ · Post by **Prophet][** » Mon Oct 11, 2004 6:12 am

I know 68000 asm.

Arqueiro · Post by **Arqueiro** » Mon Oct 11, 2004 6:57 am

BlackAura wrote:Exactly the same as we could do before, maybe a little faster.

Post by **Quzar** » Mon Oct 11, 2004 2:55 pm

The only thing that sucks is that the API is really different than musashi or c68k.

DcSteve · Post by **DcSteve** » Mon Oct 11, 2004 7:00 pm

have any of you successfully been able to incorperate this into a dc program?

Post by **Quzar** » Mon Oct 11, 2004 7:45 pm

i havnt tried yet. Looked at the api. it would be quite a bit more work than implementing c68k (which wasnt that hard). I for one am gonna wait till fox releases the documentation.

BlackAura · Post by **BlackAura** » Mon Oct 11, 2004 8:54 pm

Look for the PC version of FAME. Same API, and it has documentation.

Post by **Quzar** » Mon Oct 11, 2004 9:38 pm

BlackAura wrote:Look for the PC version of FAME. Same API, and it has documentation.

i figured there are some differences cause he said he was gonna release seperate documentation for it. but yea i read that stuff.

do you happen to know of any PC emulator that uses that? i cant find any.

BlackAura · Post by **BlackAura** » Tue Oct 12, 2004 4:34 am

There are some, but I don't recall any of them right now.

fox68k · Post by **fox68k** » Tue Oct 12, 2004 8:24 am

quzar wrote:
BlackAura wrote:Look for the PC version of FAME. Same API, and it has documentation.
i figured there are some differences cause he said he was gonna release seperate documentation for it. but yea i read that stuff.

do you happen to know of any PC emulator that uses that? i cant find any.

I will not release separate documentation for it. I said i will release separate documentation for the sources. That way, you will find the documentation for both PC version and SH4 version. And why? Because both libraries have the same API and the same data structure, so there is no need to make separate docs.

Cheers.

fox68k · Post by **fox68k** » Tue Oct 12, 2004 8:36 am

quzar wrote:The only thing that sucks is that the API is really different than musashi or c68k.

Not very different. Maybe the part that could is memory handling. C68k leaves the task to a handling function. This makes the library more simple but at the cost of slower access to memory (not I/O, remember m68k I/O access through memory map). Using FAME you will have to define memory map parts directly to the lib, not inside a C function with several cases (switch... case).

I was looking at Genesis Plus DC sources and i believe that FAME can be integrated in easily.

Greetings.

BlackAura · Post by **BlackAura** » Tue Oct 12, 2004 9:38 am

The way FAME handles memory is a lot closer to the way most other assembly-based CPU emulators handle memory than it is to the way most C-based CPU emulators handle memory. What a shock.

It seems similar-ish to the way that StarScream or RAZE do things. You describe the memory layout to the CPU emulator, and it does most of the work. You only call a handler function if you need to, for hardware registers or such. Not really that hard to deal with, as long as you actually know the memory mapping of the system you're emulating. Having used StarScream, RAZE and some assembly-based 6502 emulator in various projects, it's kind of weird dealing with a callback function. It's slower too.

If you want documentation, just download the thing. The documentation is all there, and the interfaces are completely identical. It even has some additional information about the SH-4 version in there too.

fox68k · Post by **fox68k** » Tue Oct 12, 2004 10:17 am

BlackAura wrote:It seems similar-ish to the way that StarScream or RAZE do things. You describe the memory layout to the CPU emulator, and it does most of the work. You only call a handler function if you need to, for hardware registers or such. Not really that hard to deal with, as long as you actually know the memory mapping of the system you're emulating. Having used StarScream, RAZE and some assembly-based 6502 emulator in various projects, it's kind of weird dealing with a callback function. It's slower too.

You are right. StarScream uses a list of regions and RAZE uses memory banking. Memory banking can not be implemented in a 68000 emulator in the same way as in RAZE since the memory map size is bigger (24-bit addresses) and the I/O is memory mapped. Lists of regions are a good alternative: they are easy to implement, but could be slow when too many memory regions are defined.

But i wanted to go further. I designed an hybrid memory handling method between lists of regions and memory banking. This is, lists of regions externally and memory banking internally preserving both types of memory access in the 68k (mem and I/O). This implies easy and faster CPU context management (externally) and faster memory access (internally) at the cost of some memory statically allocated inside FAME.

DcSteve · Post by **DcSteve** » Tue Oct 12, 2004 1:23 pm

how can this core benefit gpdc in anyway other than speed, since i believe that the speed of the stefs core is more than sufficient.

Hilltopper · Post by **Hilltopper** » Tue Oct 12, 2004 1:41 pm

I am just guessing here, but if this new core is fast enough it would give more cpu time to sound emulation, and BlackAura could even revert back to a display mode that may be slower but more accurate. Again this all depends on how fast it is and what BlackAura wants to do with it.

Post by **Quzar** » Tue Oct 12, 2004 4:05 pm

BlackAura wrote:The way FAME handles memory is a lot closer to the way most other assembly-based CPU emulators handle memory than it is to the way most C-based CPU emulators handle memory. What a shock.

It seems similar-ish to the way that StarScream or RAZE do things. You describe the memory layout to the CPU emulator, and it does most of the work. You only call a handler function if you need to, for hardware registers or such. Not really that hard to deal with, as long as you actually know the memory mapping of the system you're emulating. Having used StarScream, RAZE and some assembly-based 6502 emulator in various projects, it's kind of weird dealing with a callback function. It's slower too.

If you want documentation, just download the thing. The documentation is all there, and the interfaces are completely identical. It even has some additional information about the SH-4 version in there too.

From reading the documentation and what you said here, I now understand better how the memory funtions work, but for me, who doesnt know how emulators work past a certain point, and only having worked with C cpu cores, this is all foreign to me.

Hilltopper · Post by **Hilltopper** » Tue Oct 12, 2004 4:21 pm

I forgot to ask earlier, but does anyone have any idea if this new core will be fast enough to implement SEGA CD emulation?

Arqueiro · Post by **Arqueiro** » Tue Oct 12, 2004 5:02 pm

im wainting for the next year, i tink that on 2k5 we will have a segacd emu

BlackAura · Post by **BlackAura** » Tue Oct 12, 2004 8:15 pm

Unless it's ten times faster than C68k, then SegaCD emulation is out of the question. I've not tried it out yet, so I'm not completely sure.

C68K is fast enough for Genesis Plus / DC when using hardware accelerated rendering. The only catch is that the Z80 emulator eats a lot of the remaining CPU time, leaving very little CPU time for the sound emulation. So a faster CPU emulator (either of them) would give us more CPU time to play with the sound emulation, or do more accurate video emulation.

I still don't think GP/DC is going to be fast enough to use the software-based rendering code with sound enabled. It's fast enough (with C68k) to run at 95% full speed without frame skipping, so I'd guess that it'll be full speed with no frameskipping and no sound using FAME, even if FAME is only a little faster than C68K.

So, we're probably going to have a choice: Hardware rendering with sound, or software rendering without sound. There's still a long way to go with the hardware rendering, but I think I should be able to get it working well (not perfectly, but well enough that you won't notice) on at least 75% of the games I've tried on it. The remainder will either have graphics problems, or they'll be unplayable. For those, you can use the software renderer, but you'll have to sacrifice sound.