Officially: What Can We Expect?

[Kangal]

I just wanted to start a thread so developers can use to update their progress on their software.

I know this wiki is really helpful but its not updated often enough.

So the question is:
What software will be available to use on the Pandora when its: + released (first 500),
_____________________________________________________+ first batch (4,000) and
_____________________________________________________+ second batch (4-6months is widespread verdict)?

It can be software stated in the above wiki, or software which you haven't tagged into it (in which case just give a short description about it)

For instance; I would like to know when the developer's think they would release NullDC (emulator) playable on pandora?

 

[mali]

You are not fully up to date. The 500 figure is pre CNY
I doubt that it's possible to predict the future.

 

[gruso]

There was a similar thread recently. http://www.gp32x.de...-creme-filling/

Don't pin any hopes on NullDCe, unless they have some sort of surprise in store. We don't hear from those guys much, they may be waiting for hardware.

 

[Adventus]

Don't pin any hopes on NullDCe, unless they have some sort of surprise in store. We don't hear from those guys much, they may be waiting for hardware.

Yep, drk||Raziel and Zezu haven't been very active lately, drk||Raziel told me he gave up after he ran across an annoying OGL bug. However, I've contacted them and obtained access to the svn, so some kind of release is possible.... once i've ironed out some bugs. Currently i cannot get past some incorrectly rendered "set time" bios screen so I cannot test the changes I've made. I'll pick up my prototype on monday so that'll probably motivate me to do some more. I'm working on the dynarec (mostly fpu) and the OGL stuff as a long term project.

 

[lamortdream]

good to hear your working on nulldc adventus, lets wait and see what you can do with it

cheers

 

[Kangal]

Oh sorry I didnt see that thread, Thanks Gruso!

[This is speculation, not news]

Based on "working build" status on the wiki, various reports over the last year, and my spidey senses, these are some titles that should be ready to go:

GAMES:
Gianas Return
Abuse
Battle for Wesnoth
BlobWars
Descent 1
Descent 2
Doom
FHeroes Port (Heroes Of Might And Magic 2)
FreeCiv 2.1.9
Hexen II
OpenLiero
OpenTyrian
Pandora Panic!
Powermanga
Quake 1
Quake 2
Quake 3
Reminiscence (flashback)
SuperTux 1
SuperTux 2
Tecnoballz
The Mana World
Ur-Quan Masters
Wolf4SDL

(With the exception of PandoraPanic, everything in that list has been ported by Pickle & Cpasjuste. What an effort - and it's not the whole list.)


EMULATORS:
DosBox
Mupen64plus (big maybe)
PAtari
PicoDrive
PSMS
PSnes
PSX4all (medium sized maybe)
ScummVM
UAE4all
VICE

 

[gruso]

Great to hear Adventus.

[edit] No worries Kangal.

 

[Kangal]

Don't pin any hopes on NullDCe

Yep... However, once i've ironed out some bugs... I'll pick up my prototype on monday so that'll probably motivate me to do some more. I'm working on the dynarec (mostly fpu) and the OGL stuff as a long term project.

good to hear your working on nulldc adventus, lets wait and see what you can do with it

cheers

Thanks for the info. I think its great that your trying. Even if you don't complete it, you could forward it too other developers that might be able to finish it. I mean you walk before you run, and its your parents that help you start walking.
Just want to say the best of luck. I think if you can get it to work even at a decent speed (30fps/50%) I would pay to download that onto my Pandora. In fact, I encourage it. You should be paid for your effort, because without a doubt a Dreamcast emulator will send the Pandora sales on a rocket.

 

[ari64]

Yep, drk||Raziel and Zezu haven't been very active lately, drk||Raziel told me he gave up after he ran across an annoying OGL bug. However, I've contacted them and obtained access to the svn, so some kind of release is possible.... once i've ironed out some bugs. Currently i cannot get past some incorrectly rendered "set time" bios screen so I cannot test the changes I've made. I'll pick up my prototype on monday so that'll probably motivate me to do some more. I'm working on the dynarec (mostly fpu) and the OGL stuff as a long term project.

Out of curiosity, what kind of performance are you getting from the dynarec? Knowing how much CPU time it takes to emulate the N64 CPU on the A8, I'm wondering how fast SH4 emulation is.

FPU is really hard to get right, do you have a known-good reference implementation to compare with?

 

[conso]

Don't pin any hopes on NullDCe, unless they have some sort of surprise in store. We don't hear from those guys much, they may be waiting for hardware.

Yep, drk||Raziel and Zezu haven't been very active lately, drk||Raziel told me he gave up after he ran across an annoying OGL bug. However, I've contacted them and obtained access to the svn, so some kind of release is possible.... once i've ironed out some bugs. Currently i cannot get past some incorrectly rendered "set time" bios screen so I cannot test the changes I've made. I'll pick up my prototype on monday so that'll probably motivate me to do some more. I'm working on the dynarec (mostly fpu) and the OGL stuff as a long term project.

"gave up" sounds like no interest any more. You think your help might motivate them again?

 

[Consequence_9]

"gave up" sounds like no interest any more. You think your help might motivate them again?

i think hardware would motivate them more than anything

 

[Adventus]

Out of curiosity, what kind of performance are you getting from the dynarec? Knowing how much CPU time it takes to emulate the N64 CPU on the A8, I'm wondering how fast SH4 emulation is.

To be honest, I have no idea, I haven't been able to get past the bios screen . However there are video's of the DC running approx half speed, and it is apparently FPU bottlenecked. I'm very surprised how well it works, even without register allocation anywhere (except the context register). One difference between nullDCe and your approach is it uses an intermediate language which is expanded & optimised before being passed to the platform dependent dynarec. There's also a Canonical implementation of every instruction which is called as a dynarec fall back.

FPU is really hard to get right, do you have a known-good reference implementation to compare with?

Apparently accurately emulating the FPU on DC isn't necessary for most games. They already have a PSP/X86/CANONICAL implementation which i can look at, none of which seem to handle rounding modes, double precision or exceptions. For instance the fadd C implementation is simply: void fadd(float *x, float *y){*x += *y;}.

With this in mind I can use some aggressive optimisation techniques, like instruction interleaving and vectorising. The real question though is if I do static/dynamic register allocation and how I allocate them while maintaining ABI. My current Idea is to map the active FP BANK to S0-S15 and the other bank to D16-D23. This means that normal operations like fadd, fmul can either use the VFP = 7 cycles/operation (fmac is 11) or i can use the NEON to emulate Single Precision. ie

FADD FR0, FR2
FSUB FR4, FR6
=
VADD.F32     D24, D0, D1
VSUB.F32     D25, D2, D3
VEXT.8       D24, D24, D0, #4
VEXT.8       D25, D25, D2, #4
VREV64.32    D0, D24
VREV64.32    D2, D25

This is where the interleaving comes into play, assuming no hazards i can get down to 3 cycles per operation. The DC FPU is 5 stages so it should work well for code that is ordered with this in mind. This stuff gets complicated though when you have two operations writing to the same D reg, etc. The alternative is i map each FR to its own NEON D register, this means FADD, etc would be single cycle neon but it would have decreased memory efficiency and no vectorization (especially important for FTRV).

i think hardware would motivate them more than anything

I believe drk||raziel and Zezu have beagleboards. It's just the nature of development, you often work in intense short periods of time.

 

[kingoddball]

Adventus: Enjoy your Pandora tomorrow!
If you get the chance if/when you fix NullDC can you post up some info on frame speed and other such details?

(or is it NullDCe? Whats the 'e' mean?)

 

[mali]

I'll pick up my prototype on monday so that'll probably motivate me to do some more.

 

[ari64]

Out of curiosity, what kind of performance are you getting from the dynarec? Knowing how much CPU time it takes to emulate the N64 CPU on the A8, I'm wondering how fast SH4 emulation is.

To be honest, I have no idea, I haven't been able to get past the bios screen . However there are video's of the DC running approx half speed, and it is apparently FPU bottlenecked. I'm very surprised how well it works, even without register allocation anywhere (except the context register). One difference between nullDCe and your approach is it uses an intermediate language which is expanded & optimised before being passed to the platform dependent dynarec. There's also a Canonical implementation of every instruction which is called as a dynarec fall back.

Doing register allocation for SH4 is a bit easier than MIPS. Since there are only 16 registers, you don't have to spill registers very often.

I do optimize the intermediate representation (eg constant folding) but I try to keep it as close to the original as possible. If you rearrange things too much, it makes dealing with branches very difficult. How much does does nullDCe's internal representation differ from the SH4 code?

FPU is really hard to get right, do you have a known-good reference implementation to compare with?

Apparently accurately emulating the FPU on DC isn't necessary for most games. They already have a PSP/X86/CANONICAL implementation which i can look at, none of which seem to handle rounding modes, double precision or exceptions. For instance the fadd C implementation is simply: void fadd(float *x, float *y){*x += *y;}.

Accurately emulating the FPU isn't necessary for most N64 games either. There are a few that are rather picky about FPU precision though.

This is where the interleaving comes into play, assuming no hazards i can get down to 3 cycles per operation. The DC FPU is 5 stages so it should work well for code that is ordered with this in mind. This stuff gets complicated though when you have two operations writing to the same D reg, etc.

So do you generate something like ARM code, and then reorder the instructions so that they can execute simultaneously?

Maybe I don't understand what you're getting at, but if you actually have two independent instructions that write to the same register then you can eliminate the first one. That is what I do. I don't have any explicit dead code elimination, but the dead instructions get eliminated because the register allocator will not allocate a register if the result is not used anywhere, and when the assembler has no register to write the result into, it outputs nothing.

For maintaining API, I suppose you could make the register mapping fixed at the exit points, and prior to that things can be moved around. You will have to do some clean-up if you get an exception though.

 

[Dead1nside]

Well I'm glad you're getting your Pandora soon Adventus

I'd noticed that drk||Raziel and Zezu hadn't really been active (especially on here) so it's good you've got svn access. Have they been inactive on nullDCe in general, or just the Pandora port? Their website hasn't been updated for awhile, but that's not uncommon. Maybe some Pandora hardware would motivate them. Either way I'm glad you've got access to the code.

It's all getting very exciting here.

 

[Mithrildor]

Make us some vids and pics when you got it!

Have fun with your panda

 

[Adventus]

Alrighty, looks like i'll just go ahead and take over this thread with dev talk.

How much does does nullDCe's internal representation differ from the SH4 code?

Not a huge amount, it basically merges alot of similar instructions.... makes the dynarec alot simpler.

Accurately emulating the FPU isn't necessary for most N64 games either. There are a few that are rather picky about FPU precision though.

Thats good, are you still emulating without VFP? I don't think NEON would really be necessary for the N64.

So do you generate something like ARM code, and then reorder the instructions so that they can execute simultaneously?

Probably not simultaneously, but without hazards. Normally the sequence Vop, VEXT, VREV would be slower than runfast vfp because the RAW hazards causing stalls.

Maybe I don't understand what you're getting at, but if you actually have two independent instructions that write to the same register then you can eliminate the first one. That is what I do. I don't have any explicit dead code elimination, but the dead instructions get eliminated because the register allocator will not allocate a register if the result is not used anywhere, and when the assembler has no register to write the result into, it outputs nothing.

Yeah I'm pretty sure nulldc does something similar to this, but what i was refering to is that: fadd FR0, FR2; fsub FR1, FR5; are both writing to NEON D0 in my register allocation. Each D reg is mapped to 2 FR regs.... the correct output would be:

VADD d24, d0, d1;
VSUB d25, d0, d2;
VEXT.8 d24, d25, d24, #4
VREV64.32 d0, d24

Then more problems are introduced when both operands are in different lanes. ie fadd FR0, FR1... you solve this by doing an initial VREV64 on the input argument. I'm not sure how worthwhile this stuff is though, apparently as long as FTRV is fast your set. For my first implementation I'll just use VFP for these ordinary instructions, and NEON for FTRV, FIPR and a few others.

For maintaining API, I suppose you could make the register mapping fixed at the exit points, and prior to that things can be moved around. You will have to do some clean-up if you get an exception though.

Yeah that's my plan, Though I meant the C ABI for when a function is called (ie a Canonical fallback occurs). For instance the softfp ABI uses S0-S15 as scratch and S16-S31 as variable storage regs, this means i must move the S0-S15 stuff into the upper D24-D31 (or store to memory). Hopefully nothing touches the upper D regs, only the NEON has access to them so i should be safe.... unless a NEON-ized memcpy() occurs.

 

[ari64]

Alrighty, looks like i'll just go ahead and take over this thread with dev talk.

LOL, you scared everyone away.

How much does does nullDCe's internal representation differ from the SH4 code?

Not a huge amount, it basically merges alot of similar instructions.... makes the dynarec alot simpler.

There isn't much to combine from MIPS, other than the constant folding which I already do. I could possibly combine SLL/SRA into a sign-extension instruction. LWL/LWR can be combined, but these are so infrequent that it's not worth the effort.

With SH4 I guess you would want to combine SHLL2/SHLL8/SHLL16/etc.

Accurately emulating the FPU isn't necessary for most N64 games either. There are a few that are rather picky about FPU precision though.

Thats good, are you still emulating without VFP? I don't think NEON would really be necessary for the N64.

Yeah, I tried to get my code to match mupen64plus v1.5 as closely as possible, but then I realized that mupen's fpu emulation was buggy to begin with.

what i was refering to is that: fadd FR0, FR2; fsub FR1, FR5; are both writing to NEON D0 in my register allocation. Each D reg is mapped to 2 FR regs....

So is there a 'partial-register' stall if you write to the upper and lower half separately? I guess I don't understand the NEON/VFP pipeline that well.

 

[Adventus]

So is there a 'partial-register' stall if you write to the upper and lower half separately? I guess I don't understand the NEON/VFP pipeline that well.

It's not really possible to write to the lower and upper half with the NEON, except with the VTBL and VEXT instructions. What i think has confused alot of people is the documentation has renamed all the VFP instructions to be NEON-like, ie vadd s0,s1,s2 .... these are actually VFP executed not NEON. My problem is it adds complexity and edge cases to my interleaver, they could (in theory) execute quicker than the other sequence.

Basically my approach is to emulate single precision, single element operations using the NEON 2-way operations + 8 temporary registers. At best it might be 2x faster than VFP + runfast and still use the exact same register mapping. I suspect VFP + Runfast is essentially do the same operations internally but without being pipeline friendly.