FPGAzumSpass
patreon
SRAM saving, PAL, Fog, Faces and many fixes
🕑 Added 2023-09-14 14:02:55 +0000 UTCHi Everyone!
10 days passed since the last update and we can look back at the changes. It's way to much to explain all of them here, but you can see the full list at the end of this post if you really want. Instead I will focus on the main changes in this version.
First I want to thank everyone for joining my Patreon. It really means a lot to me to see all the support. The last weeks have been pure fun for me with the core really coming to life so I can already play some games from my time as teenager and seeing that my excitement is shared by you. Thank you so much!
Now let's look at the changes:
SRAM
Games that use SRAM in the Cartridge to save are now working and also you can save to SDCard, so some of them might already be kind of playable.
PAL
You can now play PAL games at 50Hz. There are some PAL exclusives, but this also might allow you to play in your native language. To be able to use this you need to have a PAL PIF BIOS file names as boot1.rom in your N64 folder.
Fog
The fog blending in the core was completely broken, so the fog color you got didn't depend on the distance properly, but instead was a more or less a random color value for the whole image. In some cases this color was even missing completely(no fog) or black. This should be fixed now and has shown to work in many games now.
The way how fog works might surprise you: the fog is not volumetric at all, it's not even a separate object. All that fog rendering does is modifying the color of one existing object. This also means that the fog will not hide any objects behind it, unless it's really overwriting the whole color of the original object. Therefore it has no practical use to be able to turn it off, as all that you would see is the "nothing" behind it.
Faces
Several things have been fixed to get some faces working.
The Mario face not working was a simple oversight of me, where I forgot to wire a signal. I can still remember I wanted to do it, but didn't do it instantly because it was coming from a different submodule (alpha value used as color), but then forgot it later on. Well, now it's there.
The faces of Kirby and Pikachu have been different texture wrap and mirror modes not being implemented properly. This probably also affected other round objects, but faces are so easy to spot for us, it was really important to get this right.
RAM
I hopefully finished the RDRAM handling over the last week. There are two significant changes.
The first change is the handling of writes and reads outside the memory. For many consoles, the RAM is accesses with wraparound. That means if you write just after the end in the address map, you write to the beginning instea, same for reading. Within the N64 this is different: writes and reads behind the RAM are lost.
This sounds very easy to implement, but don't be tricked, this was a serious task. The reason is that the RDRAM is rebuild using the DDR3 memory of the DE10-Nano using it's built in memory controller. So if you just write beyond the RDRAM area in the DDR3, there is more RAM and it will work just fine, but that is not what games need. They need those writes to NOT be executed.
Writing is actually the easier part, we can just don't write. But reads are much more difficult because they must return something and we read with bursts from the DDR3, but the DDR3 doesn't know that it must not return what is at the position we read from. The solution is as follows:
- when booting the core, an area in DDR3 independent of the maximum 8Mbyte of RDRAM is cleared with zeros
- when a game reads outside of the RDRAM, this read will be redirected to this special memory area
- the DDR3 then returns the zeros that have been written there before. As writes are ignored, those will never change
The second change for the RDRAM handling is the ramsize indicator. This is a number stored by the PIF in RDRAM when the console is booted up and it usually not overwritten by the game. This number tells the game how much RDRAM there is in the console without requiring the game to check itself, for example by trying to write outside of RDRAM.
Until recently this number was zero. This does not only mean that the Expansion Pak wasn't detected by some games....no, some games used that number directly and assumed they only have 0 Mbyte of RAM, which led them to crash instantly. Implementating this initial write into RDRAM has allowed plenty of games to boot, e.g. Pilot Wings, 1080 Snowboarding and Pokemon Stadium.
What comes next?
It could be RDP improvements, Flash saving, controller pak or something else.
Forgive me that there is not much planning currently. I mostly work on the things I'm most motivated for, so priorities can shift easily, but I feel it's the way I make much better progress compared to forcing myself to do "exactly as planned". I hope this has been visible over the last weeks.
The most recrent build(.rbf) is attached for you to this post.
Have fun!
------------
All changes since last post:
- RDP: fix 2 cycle mode trigger generation at end of polygon
- RDP: implement CVG manipulation in z-buffer compare
- RDP: wait for all pixels to be written before reporting polygon as complete
- RDP: fix a bug in blender that would use wrong alpha source (fixes e.g. fog in Mario games)
- RDP: add special blender mode for combining non-force-blended polygons (AA effect)
- RDP: don't fetch framebuffer when the line will never be rendered (performance improved and random stray pixels fetched)
- RDP: fetch framebuffer values 1 cycle earlier so they are not overwritten already (fixes random stray pixels)
- RDP: add alpha texture channels to color combiner (e.g. Marios face)
- RDP: tile address fix for negative indexes (faces in kirby and pokemon snap)
- RDP: implement static Z value mode (e.g. Hexen)
- RDP: fix bug in 9th bit readback when framebuffer is not 16 pixel aligned (e.g. Banjo)
- RDP: fix bug in blender using wrong z select in 2 step mode (e.g. Banjo)
- RDP: implement blender alpha compare check (fixes transparency sprites in e.g. OoT and Dr.Mario)
- RDP: fixed a bug when CVG alpha mode is modifying coverage
- VI: horizontal length dividable by 10 (more stable analog out)
- RSP: fixed a bug where RSP DMA was started multiple times
- RSP: write DMA now forces DDR3 mux to be exclusive and non interruptable (more consistent behavior)
- RSP: new error flag for address collision detection
- RSP: DMA can no longer trigger when CPU/RSP is writing registers it the same clock cycle
- AI: fetch 2 samples at once and keep 1 in buffer (consistent sampling rate)
- added rdramregs memory area
- 4/8mbyte ram switch implemented in DDR3Mux
- don't load ram data on core boot until cart was downloaded
- implement sram functionality in PI and load/save to sdcard
- videoout now has minimum 200 lines height
- remove status update from savestate ui as it can overwrite auto settings coming from database
- implement PAL switch: pif bios file download and video out 50 Hz
- bottom crop option added
- grouped debug options in submenu, activate datacache by default
- Implement RDRAM init for memsize (fixes several games hanging in boot stage)
Comments
Oliver this is alpha, there are some thing that require work and new development. Patient my friend!
Mario Tennis needs the TLB functionality, which is still missing.
olivier bernhard
What would explain why Mario Tennis 64 does not even boot up ? bug or missing important chip implementation ? thanks :)
