Announcement: Cycle-accurate N64 development underway.

[Fanatic 64]

Correct.

The Legend of Zelda is not World of Warcraft.

But yeah, it doesn't work in most emulators because they don't properly emulate the framebuffer (because it requires writing back the frame from video memory to main memory, which causes slowdown unless you have a powerful PC. I don't know if CEN64 does the same or due to it being CPU-only it can avoid that burden).

 

[Nintendo Maniac]

it requires writing back the frame from video memory to main memory, which causes slowdown unless you have a powerful PC

Hey, isn't that exactly the kind of thing that AMD's whole "HSA" thing is supposed to solve?

 

[rogerhanin2002]

quick report:
compile error for SSSE3_ONLY CPU
in helper.c change USE_SSSE3_ONLY by SSSE3_ONLY
in TCLod.c change #include <smmintrin.h> by
#ifdef USE_SSE
#ifdef SSSE3_ONLY
#include <tmmintrin.h>
#else
#include <smmintrin.h>
#endif
#endif

TIPS (for users):for joystick support add in release.cmd : mingw32-make -s -C .. OS=windows RETROLINK_JOYSTICK=1
if you're lucky it will work else try to change config in Actions.c

TIPS 2: I've make a little batch for windows, just put it in the same directory than cen64.exe and pifdata.bin then just drag and drop your rom.

and last but not the least a little bug report in attachments: SSSE3_ONLY, RETROLINK_JOYSTICK=1, version: 14 september, windows 7 64bit

PS: controller bug report is perhaps false cause D-pad doens't work with cen64.

 

[MarathonMan]

Hey, isn't that exactly the kind of thing that AMD's whole "HSA" thing is supposed to solve?

No. Nothing's done on the GPU in CEN64, nor can ever be, so that's completely and utterly irrelevant for CEN64.

quick report:
compile error for SSSE3_ONLY CPU
in helper.c change USE_SSSE3_ONLY by SSSE3_ONLY
in TCLod.c change #include <smmintrin.h> by
#ifdef USE_SSE
#ifdef SSSE3_ONLY
#include <tmmintrin.h>
#else
#include <smmintrin.h>
#endif
#endif

TIPS (for users):for joystick support add in release.cmd : mingw32-make -s -C .. OS=windows RETROLINK_JOYSTICK=1
if you're lucky it will work else try to change config in Actions.c

TIPS 2: I've make a little batch for windows, just put it in the same directory than cen64.exe and pifdata.bin then just drag and drop your rom.

and last but not the least a little bug report in attachments: SSSE3_ONLY, RETROLINK_JOYSTICK=1, version: 14 september, windows 7 64bit

PS: controller bug report is perhaps false cause D-pad doens't work with cen64.

Thanks, I missed that incorrect conditional when I fixed the other one... I'll look at it later tonight. BTW, the d-pad on my retrolink either doesn't work or the drivers don't show any response when the buttons are pressed.

 

[Nintendo Maniac]

No. Nothing's done on the GPU, nor can ever be, so that's completely and utterly irrelevant

Uhh... then what Fanatic 64 said is incorrect then isn't it? Because he said it's copying from video memory to system memory, and the entire point of hUMA is to have a unified memory space so that you don't need to spend time copying and/or moving data around between your video and system memory pools.

 

[Guru64]

CEN64 doesn't use the GPU, so it doesn't apply.

 

[Nintendo Maniac]

I was pretty sure it didn't use the GPU seeing how I already asked earlier about it running on even the lowest of the oldest Intel iGPs.

So then just what is it that Fanatic 64 is speaking of?

 

[Fanatic 64]

So then just what is it that Fanatic 64 is speaking of?

HLE emulators, which render on the GPU and then write back the frame to main memory. If you paid attention you would notice I explicitly said that since CEN64 does everything on the CPU it does not need to do that.

 

[Fanatic 64]

If you read the wiki page, you'd see that it mentions "paper doll" being a term used since the old pen and paper RPG days. I'm perfectly aware that one IP != another IP. I first heard this term used in Ultima Online, way back in the early days of the internet. So I guess it just kinda stuck for me.

The Legend of Zelda is not a PaPRPG

In emulators, especially HLE such as Dolphin, the frame buffer is implemented as a GL/DirectX object. Writing to and from this object is slow, so many emulators don't bother. Dolphin does however have options for varying degrees of frame buffer emulation, each with pros and cons.

EDIT: Darn, beat me to it!

This.

 

[Fanatic 64]

http://bit.ly/14nF5Ko

You put a troll face over the pope's head! I'm offended!

 

[Mizox]

since some people were mentioning something sorta related on the previous page...

how are you going to go about emulating those games which have extra processing/memory/whatever chips within the cartridge itself? I know there's a few such games... not sure what they are though

 

[MarathonMan]

regarding rogerhanin's post:

Thanks, I missed that incorrect conditional when I fixed the other one... I'll look at it later tonight. BTW, the d-pad on my retrolink either doesn't work or the drivers don't show any response when the buttons are pressed.

Fixed this the other day in the Mac OS X fixes patches.

 

[Nintendo Maniac]

how are you going to go about emulating those games which have extra processing/memory/whatever chips within the cartridge itself? I know there's a few such games... not sure what they are though

I thought that only applied to NES and SNES cartridges?

 

[arbingordon]

MarathonMan, would you mind stopping by #n64dev over the weekend? I have some code to bounce off you. (some run-time dependent controller settings, setting configurations added for keyboard, mayflash64 adapters and xbox 360 controllers, and some EEPROM saving code that makes them persistant)

 

[Nintendo Maniac]

mayflash64 adapters

As an owner of a Mayflash Dualshock to USB and Mayflash Classic Controller to USB adapter, aren't Mayflash USB adapters just seen as generic USB HID gamepads?

 

[arbingordon]

As an owner of a Mayflash Dualshock to USB and Mayflash Classic Controller to USB adapter, aren't Mayflash USB adapters just seen as generic USB HID gamepads?

Yes?

 

[Nintendo Maniac]

Yes?

Well then isn't your code for a Mayflash N64 USB adapter just code for generic USB HID gamepads?

 

[max_power]

Don't know if its of any use to you, but I did some profiling with google's pprof tool, see the attachment. One caveat is that I turned off all inlining to better see whats going on.

Btw I'm not too familiar with git, but is having a submodule for each component not a bit overblown? Seems to me it makes branching, merging, etc. much more difficult.

EDIT: A small bug in debug mode exclusive (the irony): In rdp/Core.c there is
#define RREADIDX32(in) (assert(in <= 0x7FFFFC), bswap32(rdram[in]));

which is later called as
RREADIDX32(dp_current_al & 0x3fffff);

It fails the assert because of the macro and operator precedence doing bad teamwork

 

[Ultix]

As Mizox just said, will CEN64 be able to run games that use the cartridge as RAM & stream from it? Indy Jones & The infernal machine for example

"Factor 5: The big strength was the N64 cartridge. We use the cartridge almost like normal RAM and are streaming all level data, textures, animations, music, sound and even program code while the game is running. With the final size of the levels and the amount of textures, the RAM of the N64 never would have been even remotely enough to fit any individual level. So the cartridge technology really saved the day."

 

[Nintendo Maniac]

As Mizox just said, will CEN64 be able to run games that use the cartridge as RAM & stream from it? Indy Jones & The infernal machine for example

"Factor 5: The big strength was the N64 cartridge. We use the cartridge almost like normal RAM and are streaming all level data, textures, animations, music, sound and even program code while the game is running. With the final size of the levels and the amount of textures, the RAM of the N64 never would have been even remotely enough to fit any individual level. So the cartridge technology really saved the day."

That nothing special and isn't like the actual discrete processing units that were found in NES and SNES cartridges. All it's saying is that the access times are so quick that you don't have to load a level completely into RAM and instead can just load the data in real-time from the cartridge as needed.

To use modern terminology, the game cartridge is essentially a read-only SSD.