FAME SH4 is here!

[quzar]

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).

[Stef]

[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

[BlackAura]

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:

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.

[BlackAura]

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

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:

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 }
};

[fox68k]

[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.

[fox68k]

[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:

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:

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.

[BlackAura]

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.

[fox68k]

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.

[BlackAura]

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...

[fox68k]

[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.