NeoPop Core Improvements

[nexis2600]

Hey, I am starting a topic here for anybody who wishes to join in on improving the state & speed of the NeoPop core.

So any thing you can post to help will be useful for all who are working on ports of NeoPop.

[nexis2600]

- Improvements -
- fetch24

Location - Core\TLCS-900h\TLCS900h_interpret.c

_u32 fetch24(void)
{
/*
_u32 b, a = loadW(pc);
pc += 2;
b = loadB(pc++);
return (b << 16) | a;
*/
_u32 a = load24(pc);
pc += 3;
return a;
}


Location - Core\mem.c

_u32 load24(_u32 address)
{
_u8* ptr;

ptr = translate_address_read(address);

if (ptr == NULL)
return 0;
else
return (_u32)((ptr[2] << 16) + (ptr[1] << 8) + (ptr[0]));
}

- Observation -
I have noticed that it causes a small boost in performance in some games and in both puzzle link games it causes a significant boost.

[nexis2600]

- Improvements -
- cycle loops

Location - Core\neopop.c

void emulate(void)
{
_u8 i, j;
_u32 uCycleTick;

//Execute several instructions to boost performance
for (i = 0; i < 64 / 4; i++)
{
uCycleTick = 0;

for( j = 0; j < 4; j++ )
{
uCycleTick += TLCS900h_interpret();
}

updateTimers( uCycleTick );
if (Z80ACTIVE) Z80EMULATE
}
}

- Observation -
Will allow for a significant boost in many games (5-10fps boost). You can adjust the range of J from 1-12. 6-8 is optimal but larger the number the more sync issues.

I am using this on the PSP port and I seen games go from a 20-25 fps to a solid 30-34 fps with a frameskip of 1 (and a cpu of 333). With a frameskip of 4. Games like puzzle link does 50-60fps.

- Known Issues -
It causes minor audio sync issues since it does not get to update the z80 more frequent. More tweaking is needed to solve this issue.

[quzar]

I don't know if you already are, but by compiling at higher optimization settings, you may get better results.

A second thing would be to try to replace the z80 core with cz80. it is between 1.5 and 2.5 x faster (on PC and DC) so it should yeild some good results in neopop.

There isn't too much that can be done, unless you can do something related to the hardware itself (which is what I know how to do with the DC, as opposed to cutting corners). What you are talking about is speedups, as opposed to optimizations. What you might also want to do is figure out a full sound disabling system (turning off z80 and sound output) to get fullspeed.

[nexis2600]

I don't know if you already are, but by compiling at higher optimization settings, you may get better results.

A second thing would be to try to replace the z80 core with cz80. it is between 1.5 and 2.5 x faster (on PC and DC) so it should yeild some good results in neopop.

There isn't too much that can be done, unless you can do something related to the hardware itself (which is what I know how to do with the DC, as opposed to cutting corners). What you are talking about is speedups, as opposed to optimizations. What you might also want to do is figure out a full sound disabling system (turning off z80 and sound output) to get fullspeed.

I dont see how the cz80 is faster. on psp it slows it down by 1-2 fps. Maybe you can take a quick look at the ngPsp src posted to see if I implemented it right but I see no improvement what so ever in speed.

Regarding removing the z80, I have to trace through games more to find out why they latch to the z80 so much. A very very small number of games actualy work with out the z80 cstuff tends to work with out the z80.

[quzar]

It's the same reason only a handfull of genesis titles will run at all with no z80 present.

as for cz80 it might be a compiling issue. it uses... non-standard C code, so there is a chance that it's speed is being broken by the cross compiler.

[nexis2600]

Quick interesting note. It's a hard find on google but there is a ngp bios out there that works on the neopop core. You of course loose the hle (so new plugs will have to be writen to get to some of the bios calls) but it does run on the official bios. I notice the puzzle link games break tho (the title screen crashes).

I'm going to poke around and debug some more to see about getting it to more properly run with a real bios.

[nexis2600]

k, well more to add. Hehe.

Here is code I writen for loading a bios. Yeah yeah basic stuff but a few things to note.

- file: bios.c -
- function: bios_install -

after the define of vectable in the funcion add this.

if( system_load_bios( bios ) )
{
//Install a Quick and Dirty Loop Hack
bios[0xFFFE] = 0x68; // - JR 0xFFFFFE (Infinite loop!)
bios[0xFFFF] = 0xFE;

return TRUE;
}

Add a bios loader into any portion of your system functions.

BOOL system_load_bios( char* pBiosMem )
{
// Insert code to load bios file
// Note, Size of the bios must be 64*1024 bytes.
}

wala you are using the real bios.
Now to get it to actualy boot into the internal menu do this.

- file: TLCS900h_registers.c -
- function: reset_registers -

replace
if (rom.data)
pc = rom_header->startPC & 0xFFFFFF;
else
pc = 0xFFFFFE;

with
pc = (*(_u32*)(ram + 0x6C00)) & 0xFFFFFF;

Now it will read the proper address stored in memory. Already from a memory reset in mem.c, it will store the proper location to boot the bios menu providing a rom is not loaded.

Few things to note tho.
1) The internal bios wont work in color mode for some reason. I am looking into that today.
2) Make sure to reset the emulator after installing the real bios so the proper address is loaded into workram for the starting PC address.

[nexis2600]

* Insert very excited man *

Something that sent me off on a search today is now found! A wonderful option the NGPC unit gave when you run a b&w rom on the system is letting you select different palettes like B&W, Red, Green, Blue or Classic.

Anyways here is the new documentation on the register.

================================================== ===========================
006C00 -> 006FFF BIOS Workspace
==================================

6F94 B : Color Mode (B&W Games on Color System)
00 = Black & White
01 = Red
02 = Green
03 = Blue
04 = Classic

Expect more post from me when I figure out how to implement it into the neopop core fully.

[GPF]

I dont see how the cz80 is faster. on psp it slows it down by 1-2 fps. Maybe you can take a quick look at the ngPsp src posted to see if I implemented it right but I see no improvement what so ever in speed.

Regarding removing the z80, I have to trace through games more to find out why they latch to the z80 so much. A very very small number of games actualy work with out the z80 cstuff tends to work with out the z80.

Yeah on my DS port and DC ports its not any faster and actually breaks some games, so iv reverted back to using the built in z80 core.

One thing I have been looking into is instead of copying the emulated framebuffer during the UpdateVBL call, but to render directly to vram instead save the extra copy call, but of course this varies on platform on tearing etc depends on when it draws.

Troy