PS2 N64-Emulation on PS2 - a discussion about a possible structure + release (alpha/beta/test)!

T

TnA

Moderator
Developer
Preamble

Alright, so I am opening/creating this thread for a solely technical discussion about possible structures for N64-Emulation (GUI-less! Solely the emulation itself is in the focus here!) on a PS2!

I am not sure how hardware-accurate the PS2-emulation is on other platforms (PC, PS3, PS4, etc.), so I suppose that it won't work on these...

This project is also intended as a kind of 'skill-test' for those who want to 'train' their skill-set! Getting an N64-Emulator running on a PS3, PS4 or XBOX is much less of a hurdle, than on a PS2, but a PS2 seems to be better suited for an emulation of N64 and some other platforms!

Introduction

This thread is intended as a prestage to gather some information, for a possible app.

I will add some stuff to the first and second post (which I am going to reserve) later.
Please add your ideas!


A little introduction to general N64-Emulation...

There are mainly 2 kinds of emulation for N64...

'LLE' ('Low level emulation'/Hardware) and 'HLE' ('High level emulation'/Software-e./Syscall-e./API-e.).
BOTH should be quite possible on the PS2!
 
Last edited:
(Reserved)


This is going to serve as a list of possible implementations/structures globally and for several parts and in both emulation-variations (LLE/HLE/or mixed).


(The rest is going to be edited later.)


Ideas for structural implementation(s)

Globally needed stuff:
  • Storage device-Drivers (and every dependencies like USBD.IRX for USBHDFSD.IRX, etc.)
  • PAD-Drivers
  • etc.

Emulation:

CPU:
(HLE)
  • Method 1: An (Opcode-)[JIT]Recompiler, which acts like a HAL or man-in-the-middle-abstraction and the Opcodes are translated to the platform it is running on.
  • Method 2: Recreate the API-Layers/Upper Abstractions/Syscall-receiving parts.
  • etc.

(LLE)
  • Directly relaying the opcodes, would probably still work for those games which do not use a 64Bit-Opcode.
  • etc.

(LLE/mix)
  • Opcodes could be 'intercepted' in a way, to catch non-supported and recompile them (using a JIT-recompiler) and 'pass' supported opcodes...
  • The interception could be done via an 'Opcode-Mask/Matrix' (essentially a function which decides if an opcode is passed directly, or if it is reworked via the JIT-Recompiler) or something like 'sigill', if the EE supports it.
  • The JIT-Recompiler can be reduced to only rework opcodes which are not supported on the host-platform and also is only invoked in that case.
  • etc.

On another note: Does MIPS or the EE support self-virtualization (of older MIPS-CPUs)? That would make it even easier to implement it...

I am not sure how the opcode-matrix could be written, to not have to double but solely single-cache the instructions...


RCP/'Reality CoProcessor' consists of the RSP/'Reality Sound Processor', the RDP/'Reality Display Processor' the connection to the RAM and the I/O-Interfaces (VI with VBUS, AI with ABUS, PI with PBUS, SI with SBUS)...
  • TLB for RAM-Access. The RCP does that in hardware on the N64 as well, so it should be possible to reuse that feature and make a similar re-implementation for the PS2!
  • etc.

RSP:
  • etc.


RDP:
  • etc.


RAM&ExpansionPak:
(LLE/mix)
  • Partial reimplementation using a TLB
  • 4MB/8MB RAM reserved for it?
  • etc.

Module/Slot-[PBUS-]Emulation (for 'Game Pak' and possibly 'CDs' as well!):
  • I/O-Drivers to read a file/ROM from a device
  • Software-bridge from IO-Drivers to emulation-function
  • Emulation-function
  • Paging should be used (for Game Paks), to spare RAM and loading-time (and to get bigger games running)
  • The module/slot-emulation probably could be done on either the EE or IOP. EE is probably preferable...
  • etc.

Input/Pad-[SBUS-]Emulation:
  • PAD-driver needs to run
  • software-Bridge between PAD-driver and Pad-Emulation
  • Pad emulation could be on IOP or EE, but I suppose EE (core) would be better
  • etc.


Tricks&Other stuff:
  • SIMD/MMI-Instructions could be used... One example is to 'bind' 4 instructions/operations of the same type (i.e. Multiplication) on an integer (and possibly on a float as well?), which could be used for performance-reasons in those cases...
  • etc.
 
Last edited:
Haha!
THX @STLcardsWS, but that's faaar/waaay too early...

I already see the comments on some other sites...
No... Assemblergames.com wasn't the source... It was actually Psx-scene.com in ~2011 and some sites, which discussed it...

Someone has recently put some work into porting daedalus to the PSP...
Maybe he reads it... After fixing the IO-Issues with libc/newlib and the more annoying frame buffer-issues while ignoring some build-warnings and after fixing the black screen or distorted screen issue, you will not get more than 8 frames... 5-6 are more likely...

That's the point, why I started working on a PS2-specific structure/implementation in the first place...
Parts of daedalus however can be reused!
Module-Emulation + Paging and HLE are quite interesting and would spare time for a working N64-emulator...

The proposed 'Opcode-Translation-Mask' however is LLE and could partially be reused for other emulators (especially of MIPS-Based devices)!


I've got a lot more documentations and conclusions (including their reasons) written on a multitude of letters + some 'tricks' (for example, how the ScratchPad, Hi0/Lo0/Hi1/Lo1, MMI/SIM-Instructions and more could be used, etc.). I will look them up and add it to this thread.
 
TnA said:
Haha!
THX @STLcardsWS, but that's faaar/waaay too early...

I already see the comments on some other sites...
No... Assemblergames.com wasn't the source... It was actually Psx-scene.com in ~2011 and some sites, which discussed it...

Someone has recently put some work into porting daedalus to the PSP...
Maybe he reads it... After fixing the IO-Issues with libc/newlib and the more annoying frame buffer-issues while ignoring some build-warnings and after fixing the black screen or distorted screen issue, you will not get more than 8 frames... 5-6 are more likely...

That's the point, why I started working on a PS2-specific structure/implementation in the first place...
Parts of daedalus however can be reused!
Module-Emulation + Paging and HLE are quite interesting and would spare time for a working N64-emulator...

The proposed 'Opcode-Translation-Mask' however is LLE and could partially be reused for other emulators (especially of MIPS-Based devices)!


I've got a lot more documentations and conclusions (including their reasons) written on a multitude of letters + some 'tricks' (for example, how the ScratchPad, Hi0/Lo0/Hi1/Lo1, MMI/SIM-Instructions and more could be used, etc.). I will look them up and add it to this thread.
Click to expand...

Too early? The tweet did the same thing as this post did. Provided awareness on the subject..
That was the sole point of it.
 
Yes, but I am not yet even ready adding all the stuff to it, which I already thought about. That's why! ;)
No problem tho', because I will add it as well.
 
TnA said:
Someone has recently put some work into porting daedalus to the PSP...
Maybe he reads it... After fixing the IO-Issues with libc/newlib and the more annoying frame buffer-issues while ignoring some build-warnings and after fixing the black screen or distorted screen issue, you will not get more than 8 frames... 5-6 are more likely...
Click to expand...

I've recently ported Daedalus to PS2 just to see how it would perform. With dynarec enabled and without sound you can get around 20 - 30 fps in Mario 64. With optimisation like using vu0 for matrices/vertices calculation, move renderer on vu1, sound on iop and should be more. But I still have problem with distorted graphics, hard to find what may cause that.
 
THX for posting to this topic!

I also noticed that I wrote "PSP" in the first sentence you quoted! I meant "PS2" there!


Thanks for the try/work!

20-30 frames (full or half)?
There must have been quite some optimizations, or you just did a better job! o_O


I think theoretically the PS2 can emulate N64 "quite natively", also using some stuff like microcode-execution on the VU (should be partially or even be fully compatible and possible I think... Just the "rastering" is kind of stupid to implement, because the emulation takes place on the CPU [in that case can also be on a VU OF the CPU and not the core/ALU + microcode should be executed on the VUs anyway] and that "raster"-stuff should rather be shifted to the GS. Atleast I think so... :-| ).

I think even 4x speed at something like doubled or 2x speed at tripled resolution, - along other graphical improvements like texture-filter - is possible in SOME games (in theory), but that would likely need A LOT of optimization and work... But hey... It could be "the next FMCB/FHDB/OPL/Homebrew" or "big thing" for PS2-Emulation on the PS2!


You have got a picture right?
What do you mean by "distorted"?
Is it "only" squashed/stretched picture/frame or rather stuff like missing/flickering/corrupted/etc. textures or textures where some "colored dots" are moving into a direction along a polygons "surface", moving/glitching wireframes/polygonal-meshes/etc., wrong tiles, or something else?



I would hope for the "screen" in Mario Kart 64 - which shows the users view in a "window" on some 3D structure -, would work (not blacked out) and would work effectively, without the need for a 2GHz-PC, haha. :) Well... At some point in time hopefully!
 
Last edited:
belek666 said:
But I still have problem with distorted graphics, hard to find what may cause that.
Click to expand...
Probably VFPU written stuff. I never was really into psp mips arch, but i think that VFPU from allegrex have different floats implementation than PS2 EE FPU, and for sure different than PS2 VU. I can be wrong here but PSP VFPU is much closer to IEEE754 than any of PS2 floats implementation. Is possible that you will be forced to do some translation/clamping/rounding/something for floats.

Not sure where in all that stuff is placed N64 hardware with it's FPU as i never looked into that, but i think is much closer to what PSP did with floats, than what PS2 do with them.
 
  • Like
Reactions: TnA
Most games run in "32Bit-Mode" (as it seems to be refered to in other scene-parts and a lot documentations [albeit not official]) anyway and don't use 64Bit-Floats, except for a quite short list of games. I think it was ~80% or a bit more, which ran entirely in 32Bit.

Clamping/Chopping/Rounding some values will probably work, or the 64Bit-Floats have to be calculated in 32Bit (I mean the full 64Bit-Value on a 32Bit-Hardware...), which will need quite more instructions [min. 4?] and dive down speed... I think it can be realized efficiently, if some SIMD/MMI-calls can be used to bind 4 executions on floats!
 
32/64 bits is no issue for PS2/PSP. Problem will be that PS2 have very rare (i think) floats treatment (or behavior, google translation here. Not sure is correct). PS2 is not IEEE754 compilant, and what is more important. PS2 VU and ps2 FPU have DIFFERENT floating points implementation. Something that on psp will be inf, or NaN, on ps2 can be real value in valid range. That work in both sides, and can lead to serious issues when vfpu is involved in display calculation anyhow. This is main issue when we are emulating PS2 on PC.

Fast google suggest that PSP is IEEE754 compilant, but i'm not 100% sure is correct as i never worked on PSP, so on ps2 floats need to be "smoothed" to make them closer to real values. Anyway, i don't know that is real issue here. Maybe is just something GPU related, etc.

Just throwing possible issue idea :)
 
Keep 'em coming!

Btw.: "smoothing"? Naaah! Chopp 0, like cutting a snake in half with a sword! Ha! :D

Well, 32Bit-"Snakes" probably won't "survive" in all games, causing issues...


Well, the question I have is rather regarding the amount of opcodes/instructions (moves, loads, etc.) that an implementation would need.

I know it can be implemented, but am not entirely sure if the PS2 supports 64Bit-Floats. To my knowledge it does not natively but only via a software-implementation using multiple or bound registers and applying the instructions "scalar" (squared instructions minimum so 2 32Bit-Register and 2^2 Instructions, I think).

Is there an instruction, which supports 64Bit-Floats?
Is it executed on the FPU?
It would be "neat" to call or 'redirect' such an instruction and let it execute on the PS2, without setting something up in software... and to have it done by one call (software-wise) and as few instructions and registers (hardware-wise) as possible!


I assume, that some MMI/SIMD-Instructions could help...
...and of course a lot of other optimizations like using the ScratchPAD or some fancy stuff like MISSusing the ScratchPAD as a fast cache.
 
Last edited:
TnA said:
Btw.: "smoothing"? Naaah! Chopp 0, like cutting a snake in half with a sword! Ha! :D
Click to expand...
Haha, yeah maybe more like force them to lower range than round. :D

TnA said:
Well, 32Bit-"Snakes" probably won't "survive" in all games, causing issues...
Click to expand...

Yep, that will need some additional "rounder/extender/calculator " :D.

TnA said:
I know it can be implemented, but am not entirely sure if the PS2 supports 64Bit-Floats. To my knowledge it does not natively but only via a software-implementation using multiple or bound registers and applying the instructions "scalar" (squared instructions minimum so 2 32Bit-Register and 2^2 Instructions, I think).

Is there an instruction, which supports 64Bit-Floats?
Is it executed on the FPU?
Click to expand...

Afaik no, there are only crazy implementations by game developers in software way. Officially it is 64 bits x 2, 32 bits x 4, 16 bits x 8, or 8 bits x 16, and MMI are not FPU or VU instruction set, so theoretically no floats related, but able to do 2 x 64 bit operations which some game developers liked to abuse even with floats in register.

We get it little bit far from eventual problem that @belek666 faced, but maybe not without the reason :D
 
kozarovv said:
Haha, yeah maybe more like force them to lower range than round. :D
Click to expand...
I think it would work (chopping/rounding/"adapting" (in general) them, but it would work for some of the 64Bit-Mode-Games ONLY... For SOME... But the "full execution" would be more interesting, since it would probably work with every game for the N64, (possibly) excluding some games whichare using microcode
S or "tricks" on the original Hardware....

Yepp, that will need some additional "rounder/extender/calculator/etc." :D.
Click to expand...
Yes!

...and it will slow down,depending on the amount of interrupts, moves, loads, and so on... So optimizing this would probably yield a lot potential... Playing "Perfect Dark" or other games with higher resolution, filter, (and so on) on the most spreaded Hardware around, would be nice!


Afaik no,
Click to expand...
Awww... That's sad!

there are only crazy implementations by game developers in software way. Officially it is 64 bits x 2, 32 bits x 4, 16 bits x 8, or 8 bits x 16, and MMI are not FPU or VU instruction set, so theoretically no floats related, but able to do 2 x 64 bit operations which some game developers liked to abuse even with floats in register.
Click to expand...
Arrrr... S&¢# that there is no native opcode for this kind of operation, but nice to know that there is at least a midstep between Hard- and Software-implementation!

This can possibly avoid latencies, which are quite crutial in emulation!

W
We get it little bit far from eventual problem that @belek666 faced, but maybe not without the reason :D
Click to expand...
I think we can only wait for @belek666 or others to reply! If he would share his port (i.e. via his GitHub-Account), this project could yield quite a far stage and multiple people MIGHT help out in it!

Just a thought!
I really hope @belek666 releases this as an "Alpha" and with the source and nowadays possibly with a license (AFL?, GPL?, CC?, etc.?)!
 
TnA said:
20-30 frames (full or half)?
There must have been quite some optimizations, or you just did a better job! o_O
Click to expand...

Full, no optimisation at all, I just made psp dynarec to work on ps2.

TnA said:
THX for posting to this topic!
You have got a picture right?
What do you mean by "distorted"?
Is it "only" squashed/stretched picture/frame or rather stuff like missing/flickering/corrupted/etc. textures or textures where some "colored dots" are moving into a direction along a polygons "surface", moving/glitching wireframes/polygonal-meshes/etc., wrong tiles, or something else?
Click to expand...

Mainly vertices glitching - jumping all over the screen. Triangles coordinates looks ok. I compared them to linux port, only some triangles on ps2 are missing. The big difference is with projection matrix. But shouldn't it affect all stuff on screen?

kozarovv said:
Probably VFPU written stuff. I never was really into psp mips arch, but i think that VFPU from allegrex have different floats implementation than PS2 EE FPU, and for sure different than PS2 VU. I can be wrong here but PSP VFPU is much closer to IEEE754 than any of PS2 floats implementation. Is possible that you will be forced to do some translation/clamping/rounding/something for floats.

Not sure where in all that stuff is placed N64 hardware with it's FPU as i never looked into that, but i think is much closer to what PSP did with floats, than what PS2 do with them.
Click to expand...

EE fpu has only rounding towards 0 but I tested if commenting out function to change rounding mode on linux version make same distortion and it didn't.

Source code:
https://github.com/belek666/daedalus
Binary:
https://uploadfiles.io/6jr3bcz7
Put files/folders on root directory of mass, looks for roms in 'Roms' directory.
 
Great work!

Would a separate thread and a news for that be a good idea, or should I rather add it to the first post(s)?!

Btw.: I'm not quite certain, as to who made what regarding the current release, due to the reference to @z2442's GitHub-Repo!


Could that be a piping/pipeline-issue?
 
Last edited:
@Fanhais: Did you write the folder-name correctly?


@belek666: I adapted the title, so that more sites and users will notice it!

I still think a separate thread or "resource" and/or "news"-post/thread would be appropriate...! It also can be done by someone else, if you don't write such a post, but want it to exist! ;)


You wrote quite some lines to make it to that stage (as it seems)!
 
Last edited:
This is great work, I can write an article up on this or can wait until it progresses .. I do not mind either way.


I am thinking...N64 via PS2...
For sure worth trying on the PS3 in the future, to see what it does via a ps2 classic / iso.
 
Last edited:
This definitely needs a news-echo on ALL scene-sites (related to Homebrew) IMO!

I am just not quite sure, as to who made what regarding the current release...

Initial porting-work: @z2442
Recompiler work: @belek666
?!?
 
You must log in or register to reply here.

Similar threads

Back
Top