Home Artists Posts Import Register

Downloads

Content

Hi everyone,

several things happened over the last two weeks, so I want to summarize them for you and tell you about the current work.

The COP0 part of the n64-systemtest, mentioned in the last post, is now fully working. The change was some edge case handling of reserved COP0 registers. But after fixing it, I noticed that the other CPU subtests (exceptions, traps, overflow) cannot be tested now, because the n64-systemtest does require the FPU(Floating Point Unit) for them.

I tried to modify the source together with Lemmy, the creator of the testsuite, to remove the FPU requirement, but the potential effort just got bigger and bigger and so I finally decided to not invest too much time and skip it until the FPU is in place, because it will be needed anyway.


Because the FPU will be a long job, I wanted to do something fun before and I implemented the rasterization part of the RDP.  The Reality Display Processor is the GPU of the N64 and while texturing and all the other RDP features are still missing, we can now get flat shaded polygons.

Maybe you still remember the NICCC demo from the PSX core. Well, it's back now for the N64 core. The visuals are more or less the same, but it's always great to see a 3D scene rendering in full 60fps stable over some time. It proves quite some things of the system are already working well.

You can try this demo yourself, I attached a core build(rbf) together with the NICCC demo to this post. Please refer to the post from May 27 if you don't know how to setup the N64 core.


Overall, this was a rather short excuse from the FPU work I have to do and I finally started tackling it. There are several steps to be done to get the FPU working in the FPGA and the first step goes back to my software emulator. But Why? The FPU is working in my emulator already, right? 

Well yes and it fulfills all available tests. But...it's not 100% low level. To implement the FPU in the emulator, I have used standard C++ floating point operations, like any sane developer would do it. To do a floating point ADD, the code looks like this:

result = a1 + a2;

That looks easy, right? Well, the operation you see there, this simple "+" does way more than just add two numbers. If you want some overview, the wikipedia article is a good starting point:

https://en.wikipedia.org/wiki/Floating-point_arithmetic#Addition_and_subtraction

This is a super simplified version however, as it completly ignores all the special situations that can happen with floating point numbers, like results being too large or too small, adding invalid numbers or strange things like "0 + infinity".

All these special things are handled nicely for us in the standard and we don't have to care....until someone wants to do that in FPGA logic. In this case all the special stuff has to be implemented down to the bits. What makes this even harder is that the N64 FPU can do both Single(32 Bit) and Double(64 Bit) precision floating point as well as plenty of special operations.

To make it short, this is my plan for making all that possible:

- Implement C++ code that calculates all required floating point operations in integer logic, which could be implemented into the FPGA and run it against the standard library for comparison.

- Once an operation (e.g. ADD 32bit floats) is fulfilling several million random testcases against the library function, I will transfer it to my N64 emulator and let it run the n64-systemtest for this operation, modifying all the special cases the N64 CPU handles different from the C++ library

- When all operations are passing the tests in the emulator and run fine with games, I will start implementing that logic in the FPGA.


As I started some days ago, there is already some progress. These operations are already fully working in my emulator:

- ADD, SUB, MUL, MOV

- Conversion from 32 Bit Integer to Single/Double


What is still missing:

- DIV, SQRT, ABS, NEG

- rounding operations (Ceil, Floor, Round, Trunc)

- 6 more conversions (64 Bit Integer to Single/Double, Single/Double to 32/64bit Integer)

- comparisions of floating point numbers(equal, greater, lesser, ...)


Overall, I might have around 25% done for the emulator part. Given how many operations exist overall, I will be busy for some weeks getting all the low level calculations correct, before I can start working on the FPGA part, but I will keep you up to date with the progress.


Have fun!

Files

Comments

Richard Simpson

Reading through your technical writeups is giving me more motivation to start learning 68k assembly. It has always been a goal of mine. Solid write up and congrats on the progress!

Anonymous

Oh, man! Very impressive! I wish you a smooth FPU implementation :)