FAME SH4 is here!

And finally, after a long time, i have just finished my Motorola 68000 emulation library written entirely in SH4 assembly. ;D

I would love to see full emulation speed in many emulators out there like NeoGeo CD and UAE4ALL among others. So i encourage every DC emu coder to use this lib and to help me with bug fixing. I will try my best. ;)

It is not completely tested but i could wait no longer to see this lib out. Of course, it is in a very early development stage (alpha) so do not except bug free.

You can download the library here.

I will release a source package (including sources and notes about development) in a few days.

P.D: FAME site is not updated with news yet.

Great news fox68k :o downloading it now..

awsome. gonna test it out.

edit: is this api compatible with the x86 version of FAME?

Excellent work Fox

ian can you email me a version of the neocd emu with sound enabled to test on the overclocked dc?

[quote author=qatmix link=board=dcemu;num=1097277534;start=0#3 date=10/09/04 at 03:12:59]Excellent work Fox

ian can you email me a version of the neocd emu with sound enabled to test on the overclocked dc?[/quote]

The sound is enabled in version 9.3. Or that is to say the sound CPU is running, its just not outputting properly. 9.3 runs at the speed that it should run if sound was working with the current z80 emulation core.

FOX, that's an incredible work, I promise that will be tested until last drop, and of course included in our emus for DC. Great Work !!! and keep on the core. PUXA ASTURIES !!!!!

amazing work FOX ! we are wainting for this !
this is a gift to the scene :P

[quote author=quzar link=board=dcemu;num=1097277534;start=0#2 date=10/08/04 at 20:33:19]awsome. gonna test it out.

edit: is this api compatible with the x86 version of FAME?[/quote]

Fully compatible. 8)

Cheers.

[quote author=quzar link=board=dcemu;num=1097277534;start=0#4 date=10/09/04 at 03:46:25]

The sound is enabled in version 9.3. Or that is to say the sound CPU is running, its just not outputting properly. 9.3 runs at the speed that it should run if sound was working with the current z80 emulation core.[/quote]


Wow that means it runs super smooth and in a frame! Any news on progress with this emu and workign sound?

have any of you successfully been able to incorperate this into a dc emu? I request a of compile it with the last release source of genesis plus for dc..

http://files.frashii.com/~sp00nz/Doo...-pvr-5.tar.bz2

It requires a version of KOS with SPU DMA. He's using 1.3.x incr 133.

[quote author=qatmix link=board=dcemu;num=1097277534;start=0#8 date=10/11/04 at 11:48:34]


Wow that means it runs super smooth and in a frame! Any news on progress with this emu and workign sound?[/quote]

actually i guess i wasnt clear on that. sound isnt working not because there isnt enough speed for it (that is what frameskip is for) but because it is literally broken. The sound processor is running, but not at fullspeed. This is how ian got it to slowdown after taking out my frame limiting code =\.

Since ian quit i dont know if there are gonna be any more updates on the emulator. The only thing i can think of would be to redo the z80 emulation with another z80 emulator that is prooven to work on the dc. either that or take out some compiler flags that ian used with it that i have heard to be problematic in stuff.

[quote author=quzar link=board=dcemu;num=1097277534;start=0#10 date=10/11/04 at 22:24:13]

Since ian quit i dont know if there are gonna be any more updates on the emulator. The only thing i can think of would be to redo the z80 emulation with another z80 emulator that is prooven to work on the dc. either that or take out some compiler flags that ian used with it that i have heard to be problematic in stuff.

[/quote]

ian quit the scene ?????????????

Else about sound, I currently started to implement it in the actual WIP version (of the ps2 port of course), and I finally completely removed the streams functions (stream.c & stream.h) and directly update both cpu sound and mix them for each frame, result is that it's starting to work more or less. fm sound is working more or less, and sfx are working but not on all games.
Ym2610 sound core is also almost 10 years old, so I think to update it with a more recent one.
Anyway, I'm also thinking to replace the z80 core, as this is strange that some games have sound working, and others no...

so is the DC version dead? Â*???

Well, im pretty sure I am the DC coder with the second most experience with it. If evilo is willing to help me implement some of the things he did in the PS2 version, maybe I can try to make an update?

It's at times like this I wish someone had a picture of a PS2 hugging a DC saying it will be ok.

[quote author=Cereal link=board=dcemu;num=1097277534;start=0#14 date=10/12/04 at 23:07:51]It's at times like this I wish someone had a picture of a PS2 hugging a DC saying it will be ok. [/quote]

considering we have all seen the picture of the PS2 beating the DC to within an inch of its life, that would be a nice change.

great stuff, It would be really sad not to get sound working on the NEO CD emu. as its soooo close (ish).

[quote author=quzar link=board=dcemu;num=1097277534;start=0#13 date=10/12/04 at 16:11:57]Well, im pretty sure I am the DC coder with the second most experience with it. If evilo is willing to help me implement some of the things he did in the PS2 version, maybe I can try to make an update?[/quote]

I will help you with pleasure on fixing the sound code. I already provided fixes to ian on the z80 core, and he also provided me with fixes on gfx issues. ps2 or dc or even gc or whatever platform it is, we are anyway all in the same community !
Neocd/ps2 is also an open source project, so once next release will be out (once, additionaly to others additions, I will reach a good state for the sound support) you are free to pick it up from my site (neocd.ps2-scene.org) and report my modification to the dc source code, or if you want contact me to my email address ([email protected]) and I will send you current ps2 sound implementation. About helping you more deeply, yes but be aware that the ps2 is NOT using the SDL library, and that I don't have the DC SDK installed, so apart for the code itself, I won't be able to go further with any assistance.

see you soon.

And best wishes to ian :)

I've never see a coder of another system show such great respect and friendly ness toward other systems coders. It's great to see these kind of things in the comuinity.

wow, you seem to know alot about fixing the sound. Do you think you can fix the sound in this genesis emulator for dreamcast? It works but it keeps looping..

http://files.frashii.com/~sp00nz/Doo...-pvr-5.tar.bz2

It requires a version of KOS with SPU DMA. He's using 1.3.x incr 133.

KOS is for DC only and he's a PS2 coder why would he know anything about that?

well technically there is a branch of KOS for the PS2 :)

Don't know how mature the branch is though.

[quote author=GPF link=board=dcemu;num=1097277534;start=15#21 date=10/13/04 at 14:43:01]well technically there is a branch of KOS for the PS2 :)

Don't know how mature the branch is though.[/quote]Holy Fly dog pooh batman I never knew that. Did Dan make that also?

kos has implementations for the DC, PS2, and GBA.

evilo: I'll keep an eye out for the next version and try to keep a lookout for the changes in it. At the moment I'm a bit busy with a little thing I'm trying to get working called DCPS ;)

DCPS eh. Lets just stomp any hype and rumors right now. Thats not a PlayStation emulator for DC right?

ah, time to change the name.... i hadnt even though of that :P

[quote author=quzar link=board=dcemu;num=1097277534;start=15#23 date=10/13/04 at 15:16:07]At the moment I'm a bit busy with a little thing I'm trying to get working called DCPS ;)[/quote]Working on the children's game contest, eh?

With the "DreamCast Play-doh Simulator"? ;D

Dude that would be totally awsome. Like to play with 3d playdoh and create animations. A mario paint thing with clay. Wow that would be awsome.

Well, based on my recent posts on DCemulation, its probably clear what im doing =P

That play-doh idea does sound cool though =P

But why are you naming a CPS1 emulator or whatever mame thing your working on by that title?

DC+CPS = DCPS

I have a few novel Ideas for how to get some of the larger games working even though it is a full emulator. My goal though is to get it up to 50% real speed without changing out the cpu core, and without any sort of underclocking or frameskipping. I think im doing kindah good cause so far ive gotten it from 10% to around 20% speed (this is all with sound running).

[quote author=dcsteve link=board=dcemu;num=1097277534;start=15#19 date=10/13/04 at 13:56:17]wow, you seem to know alot about fixing the sound. Do you think you can fix the sound in this genesis emulator for dreamcast? It works but it keeps looping..

http://files.frashii.com/~sp00nz/Doo...-pvr-5.tar.bz2 Â*

It requires a version of KOS with SPU DMA. He's using 1.3.x incr 133. [/quote]

I don't remember if this version still use my basic sound code... but if it's the case, it's normal the sound loop a bit : the code is quite simple and can work correctly only if the emulator is running at the correct speed (with frame skip or not).
We can modify it to work even without having 100% speed, but as 100% speed is (imo) a must, it will be a waste of time... i think it's better to just wait of having the emulator running at correct speed instead :)

It is using your basic sound code still. The version I was playing with has a different sound system, but is also has synchronisation issues. They just sound completely different - you get periods of terrible noice instead of looping.

One question about FAME. In the documentation it says:

Quote:

---

The last field is a 32-bit pointer to the data of the memory region. The data pointed by it must be allocated in native (Motorola) format. If not, the data will be fetched incorrectly. Make sure of this fact.

---

However, the example program actually byte swaps the program it loads. Does that mean that FAME needs the program / RAM to be in Intel byte order, or Motorola byte order? It seems a little unclear on that point. And, if it's in Motorola byte order, are all the paramaters (address, data) passed to the callback functions in Intel or Motorola byte order?

I'm around half way through trying to get the PC version of Genesis Plus working with FAME. I can switch the byte-orderness of the emulator by changing a #define anyway. All I really need to do is break the memory read/write functions up into separate functions, so FAME can call them by itself, and hook the CPU code up. Stef's adapter layer makes it pretty easy to change CPU emulators.

Well, I can't get it to work. It seems to be executing code, but it keeps resetting. As near as I can tell, it's writing to the bits of the M68k address space than cause the system to crash, which means something's gone quite badly wrong. Here's the debug output from trying to run Sonic 1

Code:

---

PC:00000206  SP:00FFFE00
PC:00000206  SP:00FFFE00
Lockup 00A07F00 = 7C (000018C0)
reset!
PC:00000206  SP:00FFFE00
Lockup 00A07F00 = 7C (000018C0)
reset!
PC:00000206  SP:00FFFE00


PC:0000032E  SP:00FFFE00  SR:2771
D0:0007FFFF  A0:0004F534
D1:00004C0F  A1:000001A4
D2:00000000  A2:00000000
D3:00000000  A3:00000000
D4:00000000  A4:00000000
D5:00000000  A5:00000000
D6:00000000  A6:00000000
D7:00000000  A7:00FFFE00

PC:0000 SP:0000
AF:0040 AF:0000
BC:0000 BC:0000
DE:0000 DE:0000
HL:0000 HL:0000
IX:FFFF IY:FFFF

---

The only place I'm doing any interfacing with FAME is in cpu68k, and I'm just using the existing memory read/write functions to do everything, so my setup is very simple:

Code:

---

struct M68K_CONTEXT cpu_contxt;
struct M68K_PROGRAM prg_fetch[] =
{
  { 0x000000, 0x3FFFFF, (unsigned)cart_rom },
  { 0xFF0000, 0xFFFFFF, (unsigned)work_ram },
  { -1, -1, NULL }
};

struct M68K_DATA data_rb[] = {
  { 0x000000, 0xFFFFFF, m68k_read_memory_8, NULL },
  { -1, -1, NULL, NULL }
};

struct M68K_DATA data_rw[] = {
  { 0x000000, 0xFFFFFF, m68k_read_memory_16, NULL },
  { -1, -1, NULL, NULL }
};

struct M68K_DATA data_wb[] = {
  { 0x000000, 0xFFFFFF, m68k_write_memory_8, NULL },
  { -1, -1, NULL, NULL }
};

struct M68K_DATA data_ww[] = {
  { 0x000000, 0xFFFFFF, m68k_write_memory_16, NULL },
  { -1, -1, NULL, NULL }
};

---

[quote author=BlackAura link=board=dcemu;num=1097277534;start=30#32 date=10/14/04 at 02:51:40]One question about FAME. In the documentation it says:

However, the example program actually byte swaps the program it loads. Does that mean that FAME needs the program / RAM to be in Intel byte order, or Motorola byte order? It seems a little unclear on that point. And, if it's in Motorola byte order, are all the paramaters (address, data) passed to the callback functions in Intel or Motorola byte order?

I'm around half way through trying to get the PC version of Genesis Plus working with FAME. I can switch the byte-orderness of the emulator by changing a #define anyway. All I really need to do is break the memory read/write functions up into separate functions, so FAME can call them by itself, and hook the CPU code up. Stef's adapter layer makes it pretty easy to change CPU emulators.[/quote]

Every map region (fetch and data) has to be in big (Motorola) endian ordering.

About memory read/write functions take a look at "Memory handling" section where you will find enough information about parameters and other details.

If you have any doubt after that, do not hesitate in ask again.

[quote author=BlackAura link=board=dcemu;num=1097277534;start=30#33 date=10/14/04 at 05:33:11]The only place I'm doing any interfacing with FAME is in cpu68k, and I'm just using the existing memory read/write functions to do everything, so my setup is very simple:

Code:

---

struct M68K_CONTEXT cpu_contxt;
struct M68K_PROGRAM prg_fetch[] =
{
 Â* Â* Â*{ 0x000000, 0x3FFFFF, (unsigned)cart_rom },
 Â* Â* Â*{ 0xFF0000, 0xFFFFFF, (unsigned)work_ram },
 Â* Â* Â*{ -1, -1, NULL }
};

struct M68K_DATA data_rb[] = {
 Â* Â* Â*{ 0x000000, 0xFFFFFF, m68k_read_memory_8, NULL },
 Â* Â* Â*{ -1, -1, NULL, NULL }
};

struct M68K_DATA data_rw[] = {
 Â* Â* Â*{ 0x000000, 0xFFFFFF, m68k_read_memory_16, NULL },
 Â* Â* Â*{ -1, -1, NULL, NULL }
};

struct M68K_DATA data_wb[] = {
 Â* Â* Â*{ 0x000000, 0xFFFFFF, m68k_write_memory_8, NULL },
 Â* Â* Â*{ -1, -1, NULL, NULL }
};

struct M68K_DATA data_ww[] = {
 Â* Â* Â*{ 0x000000, 0xFFFFFF, m68k_write_memory_16, NULL },
 Â* Â* Â*{ -1, -1, NULL, NULL }
};

---

[/quote]

Your code looks ok, but may be the handling functions are not working in the expected way.

I have set up a little example with only one memory region. Take a look at the way function handlers work:

Code:

---

int readbyte(int address, struct M68K_DATA *ds) {
  printf("Calling read byte memory handling...\n");
  printf("Direccion: %08X\n",address);
  printf("Lectura: %02X\n",ram[address^1]);
  return ram[address^1];
}

int readword(int address, struct M68K_DATA *ds) {
  printf("Calling read word memory handling...\n");
  printf("Address: %08X\n",address);
  return ((unsigned *)ram)[address>>1];
}

void writebyte(int address, int data, struct M68K_DATA *ds) {
  printf("Calling write byte memory handling...\n");
  printf("Address: %08X  Data: %08X\n",address,data);
  ram[address^1] = data & 0xFF;
}

void writeword(int address, int data, struct M68K_DATA *ds) {
  printf("Calling write word memory handling...\n");
  printf("Address: %08X  Data: %08X\n",address,data);
  ((unsigned *)ram)[address>>1] = data & 0xFFFF;
}

. . . .

// Defining memory map
M68K_PROGRAM p68ks[2] = {
  {0x000000, 0x03FFFF, (unsigned)ram},
  {-1,-1,NULL}
};

M68K_DATA d68_rb[2] = {
  {0x000000, 0x03FFFF, readbyte, NULL},
  {-1,-1, NULL, NULL}
};

M68K_DATA d68_rw[2] = {
  {0x000000, 0x03FFFF, readword, NULL},
  {-1,-1, NULL, NULL}
};
 
M68K_DATA d68_wb[2] = {
  {0x000000, 0x03FFFF, writebyte, NULL},
  {-1,-1, NULL, NULL}
};
 
M68K_DATA d68_ww[2] = {
  {0x000000, 0x03FFFF, writeword, NULL},
  {-1,-1, NULL, NULL}
};

---

I hope you find this useful.

Cheers.

Actually, I can't make any sense of it. Those handler functions work the same way as the ones in Genesis Plus anyway, but Genesis Plus stores everything in Intel byte order instead of Motorola byte order.

When it loads a ROM image, is runs through and does byte swapping, so if you're reading a single byte, you're actually reading from [address ^ 1], and you can read a word from memory and it'll be in native (Intel) byte order. That seems to be what your handlers are doing. As far as I can tell, this is what the example program included with FAME does too.

But that doesn't make sense if everything is stored in Motorola byte order. If the ROM or RAM image is in Motorola byte order, that means that it's stored exactly as it would be in a real system's memory, so you wouldn't need to change the address for byte accesses, and you'd need to byte-swap all word accesses.

This is what's confusing me. All the example code you've given seems to indicate that it works in Intel (little endien) byte order, but all the documentation and descriptions indicate that it works in Motorola (big endien) byte order.

I can only get the emulator to do anything if I store the ROM and RAM images in Intel byte order. It initialises the video hardware, changes the video mode, enables interrupts on the VDP and the CPU, and then it runs for about ten frames, and crashes by writing to an invalid memory address. If I'm storing things in Motorola byte order, the initial SP and IP are incorrect, and it does absolutely nothing.

Well, i will try to explain how FAME is working... and how is the process implied in.

- We have a ROM image; we load it in RAM, so it is stored in little endian format. After that we do the byte swapping, so now, the memory ROM located in the PC RAM is in big endian format, right? ok.

- But, why did we byte-swap the ROM? because the CPU emulators (FAME in this case) usually fetch and decode the opcodes from that memory (ROM) so it has to be in big endian format (the 68k endianness). ok for the opcodes.

- Now it is time to read words. Every memory region is in big endian format, so read/write the whole word directly. Not swap needed.

- And the last issue is about read/write bytes. Here, the point is the access type. Unlike with the word access, we are accessing a byte, which is inside the word, so the endianness matters in the read/write process. We are reading/writting in a little endian fashion, and the memory is in big endian format, so we have to byte-swap the access address.

This byte-swap is done internally in the case of memory regions pointer by the "data" pointer but not performed in the case of function handlers so it is responsability for the programmer.

- And now about the debug output i found that this result in the PC and SP looks to be correct:

PC:00000206 SP:00FFFE00

The problem is probably in the read/write accesses. Take a look at how they work and if they are compatible with the read/write process used by FAME.

Anyway, if you can not fix the problem, get in contact with me by PM and i will try to see what is happening there. ;)

Ah... I see. Just a difference in terminology. I would consider the raw image to be in big-endien format, and the byteswapped version to be in little endien format. Which means FAME works exactly the way I thought it worked, which is the same way that C68k or StarScream already work, and the same way that Musashi had been configured for Genesis Plus anyway. No problem there then.

As far as I can see, the read/write handlers work the same way as FAME expects them to. A word access just does a word access, and a byte access flips the last bit of the address before doing anything. I have FAME handling all ROM accesses, and accesses to the most commonly used copy of RAM (FF0000 - FFFFFF), and the read/write handlers aren't being called for RAM or ROM access at all in the game I'm testing with (Sonic 1).

It seems to be reading from ROM or RAM correctly, but then it starts going weird. For Sonic 1, it seems that a loop that's supposed to fill a region of memory never stops running, and it eventually hits part of the address space that causes a real MegaDrive to lock up, or causes GP to reset. Most other games actually crash the entire emulator...

One question - what's the x86 ELF version supposed to be used for? I'm trying to use it on Linux, with GCC 3.3.3 and Binutils 2.14. I haven't tried the SH-4 version out yet, because it's usually easier to debug things on a PC...

[quote author=BlackAura link=board=dcemu;num=1097277534;start=30#38 date=10/15/04 at 23:45:30]One question - what's the x86 ELF version supposed to be used for? I'm trying to use it on Linux, with GCC 3.3.3 and Binutils 2.14. I haven't tried the SH-4 version out yet, because it's usually easier to debug things on a PC...[/quote]

It is for Linux, yes.

It is best to set up the emulator in PC when possible because it is easier and when you have got it running, you only have to replace the library file.

Please, let me know about your progress with FAME integration to help with any problem/issue.

Cheers.