MiSTer FPGA N64 Core Updates! Getting Closer to Crash Free Conker's Bad Fur Day
HTML-код
- Опубликовано: 11 май 2024
- SUPPORT THE CHANNEL : / videogameesoterica
Robert (or FPGAZumSpass) is doing with active development of the MiSTer FPGA N64 core, giving us 99% of a fully functioning Nintendo 64 on MiSTer FPGA. Let's talk about what happened, when N64 will his MiSTer FPGA Update_All, the videos I have planned for the future and generally just celebrate the progress made on a Nintendo 64 FPGA Core! and a MiSTer FPGA review of the N64 is coming soon...and I have plenty of MiSTer FPGA tutorials and MiSTer FPGA guides on the playlist! Retro game collecting FPGA style! Because even if the N64 is a Retro game console the fpga gaming core is modern!
and now I am researching Conker's Bad Fur Day and have discovered...a basically crash free version of the game that ALSO gives me full debug control as to WHY it crashes in the first place : you need to use the 10/25/2000 build of Conker's Bad Fur Day prototype...which is a fully finished version of Conker on N64 but with a few minor changes...and a full crash handler! and don't press any buttons in cutscenes unless prompted! again...YOUR MILEAGE MAY VARY...and now with MORE information :)
but he ISNT done with the Turbo core as there is a brand new MiSTer FPGA N64 core that expands on the Turbo functionality and brings it in line feature set wise with the stock N64 FPGA core! and it will run The Legend of Zelda: Ocarina of Time and The Legend of Zelda: Majora's Mask at 30 frames per section with the Turbo core and this patcher : github.com/Admentus64/Patcher...
The impossible Nintendo 64 FPGA core just got updated again on MiSTer FPGA! With huge improvements to the MiSTer FPGA N64 core bringing new life to so many best retro games! We now have LOD or level of detail which is another N64 hardware feature added to the MiSTer FPGA N64 core! N64 FPGA fun incoming! and now we have YUV support too so we have a FEATURE COMPLETE N64 FPGA core! and now Bangai-O has been fixed and is playable!
and here comes the big tests! Is MiSTer FPGA as good as real hardware for N64?
and now we have a MiSTer FPGA N64 Turbo core! That runs many games faster and better than a stock Nintendo 64!
SUPPORT THE CHANNEL : / videogameesoterica
If you need a setup guide my previous Nintendo 64 MiSTer FPGA video has that so here you go: • MiSTer FPGA N64 Core G...
Patreon Thanks: Seth Peterson, John Thompson, Paul Daniel, Porch, Jon Anderson, RayceARoni, Kuranghu, Jason Hixon, Alex Tessler, Jonathan Leung, Martin Donlon, Tom Van Deusen, barabob, Steve Randall, Ahab, K-2, Renaissance 2K, Ivar Wennerhold, Adrien Sebbane,
Mike Puelinckx, Tony Escobar, H7, Ben Parfitt, Holger Schmidt, Tim Lehner, Shad Uttam, Dan L, Coupon Joe, Sunder Raj, Dorfus the Maple Syrup Man, John Booty, Richard S, Eric Gutt and Robert Alger!
I asked, you answered...and I try to listen :) Of all the requests for new content on the channel one of the most frequently asked for videos is a series on the Terasic DE-10 Nano MiSTer FPGA hardware...so here it is! Retro gaming goodness.
On this episode of our MiSTer series we are going to be talking about the recent happenings in the MiSTer FPGA scene in regards to the potential of a Nintendo 64 core for MiSTer FPGA! Nobody saw it coming...and it was long considered an "impossible core" but perhaps Nintendo's first 3D console might be coming to MiSTer soon! Which would be amazing as there are a ton of great games for it and software emulation, while much improved, is still a bit hit or miss. Plus modding a N64 for HDMI out is expensive and VERY difficult!
N64 on MiSTer FPGA would be a huge moment for video game history and preservation too!
The N64 core RSP work seems to be getting buttoned up...so next comes the RDP or Reality Display Processor which is in progress and it now has perspective correction built in! . Which means we can now "play" Super Mario 64, Mario Kart 64, Wave Race 64, even The Legend of Zelda: Majora's Mask...and some other items! and most of the corrupted graphics have been solved by this point in time! Plus F-Zero and Pokemon Snap now too! and Cubivore! And Animal Crossing...and 007 (no not GoldeEye yet) plus Pokemon Stadium! And Harvest Moon 64, and Extreme G and Glover 64...plus some beta Ocarina of Time!
But after the PS1 core on MiSTer (developed by Robert as well) and the PSX 2X core…nobody should doubt his talents!
and when it comes out just play Bomberman Hero, the N64 hidden gem of choice around this channel!
Questions? Comments? Just leave them below and I will do my best to answer each and every one of them!
/ videogameesoterica
You can follow us at IG : ChicagoGameCollector , or join our Discord Server : / discord
VGE
#retrogaming #misterfpga #nintendo #nintendo64 #retrogamer #retrogames #emulator #emulation #gaming #gamingcommunity #gamingvideos #gamingvideo 
Игры
Thank you for Testing Conker's Bad Fur Day on Mister FPGA. I wonder if this game will also work on Wiseguy's N64 recompiler too?
I’ll have to look as an adjacent to this project
Holding my thumbs, hoping that you'll come across valuable data. Appreciate the dedication in testing these crashes.
Happy to do it :)
Great video! I hope you guys and your sweet corgi are doing well!
Haha corgi is A ok. Loves to bark
Great work man!
Thanks!
For those wondering why MiSTer on the left has better fps than the emulator on the right - VGE is using the overclocked "turbo core" on FPGA, whereas the emulator is running at stock N64 speed.
Correct. Soon I’ll have all three heads up in a vid
Nice work!
Thanks. More to come
Stunt racer 64 is a game that a lot of emulators struggle with. Mister might be the same
Last I know it was fine on the core
Good luck with this!
I’ll need it haha
@@VideoGameEsoterica I haven't heard of that ares emulator you mentioned, but I haven't messed with software emulation in a few years. Is it good?
Very good. The emulator I recommend for N64
@@GalaxyMythos Usual limits still apply though as with all Windows/Linux based soft emulation, that is latency from user input (USB overheads), latency from the OS overheads and latency from the API, not to mention video latency, it all adds up, and can be quite jarring if you have been using MiSTer with a CRT (or OLED) and SNAC, not to say Ares doesn't help people learn and understand the N64 more though, and it's the best soft emulator for N64 there is, would be cool if it gets ported to the Raspberry Pi for use with RGB-Pi.
@@Wobble2007 Alright, I will sell my MiSTer and go back to software emulation like the good old days.
Regarding recreating crashes, could you capture your game inputs as you play (logging the inputs via an external device)? Then, if you find a crash, you can replay your recorded inputs and hopefully have a way to reproduce the same crash.
Always a thought for sure
This is also a good way to verify if a fix works as well. If it constantly crashed following the same inputs, then a fix is put in and it doesn't occur again, that would be a good sign of progress.
I’ll be looking into it
Very interresting. Reminds me on the very early Betaphase in Vanguard back in the days. There were exactly that same issue. Random freezes. Problem was a memory overflow on the GPU. It took months until they solved it. But depending Conker... I played the game plenty of times on real hardware and never had any freezes there.
It’ll be good to test this version on real hardware soon
Thanks for doing this and the update, it's really appreciated, I'll send some rupees your way on payday, CBFD is expensive eh, and there are so many fake carts out in the wild now, I wonder if the repro locks up like the original CBFD cart can once in a blue moon on real hardware, or it might even lock-up more, maybe that will tell you something, I remember the part that locked up more often on a real N64 was the bit where the room gets flooded and you have to climb to avoid the exposed electric cable, kind of fun trying to work this stuff out, I really hope we get CBFD working on MiSTer eventually though, and that might lead to even getting JFG working, you never know.
It’ll be interesting to show everyone the next round of results for sure with real hardware
Conker saga continues!
Squirrel must behave
It might not be flushing the memory cache correctly or as fast as it should? Especially if the same scene works the second time
Doing some quick calculations from your video, the free and largest free differences always seem to be between 32 and 64K. When I think about that, it sure feels like the 15th and 16th bits (or perhaps any bits higher than 15) of the allocation instruction (hardware) are being pulled low somehow (potentially). If this is the case, this would certainly limit how much memory the hardware implementation is even allowing.
Interesting observation. I’ll look more into it
@@VideoGameEsoterica Another thing that seems interesting to me, and thus another thing to look at, is that the N64 had a shared (i.e. multiplexed address/data bus). It makes me wonder if somehow either address bits are getting "stuck" when data should be present, or vice versa due to multiplex timing. What strikes odd to me is the differed reporting of free memory by the operating environment (between SW emu and HW emu), when the operating environment (Actual N64 SW from the ROM) API (prior to compile) is what SHOULD be what's being called to allocate, free, and thus TRACK what SHOULD be used and free on the system. The fact that the HW emu is reporting a LOWER free number tells me that somehow an allocation earlier in execution than the actual caught exception is going bad. What's further odd, is that if indeed an allocation went bad, why wasn't that caught as an exception when it occurred???
Another good Avenue to pursue for sure. I’ll be running more tests today
Have you tested the turbo core/regular core/Ares all "side by side"? Might be worth trying to see if turbo and regular core have different amounts of free memory.
Stop looking over my shoulder while I work literally right now lol
@@VideoGameEsoterica Gotta close your curtains, bro!
🤣
🤣
Maybe the crash handler should have all the info of the previous frames so you could reproduce directly the crash without having to just play.
I’m hunting a method to replicate a crash with 100% consistency
The guy says he's done with the core and isn't going to touch it anymore, and yet...here we are =). What a legend.
You never know what could happen once I track this bug down
N64 related, I would be interested in your opinion on the latest news regarding N64 recompilation.
It’s on my list of things to look into
It’s cool your doing this. But as an engineer, though I’ve not worked on N64 but I have the DS and GBA, here are my thoughts if I was to put on Robert’s hat.
Memory issues like this tend to be caused by streaming mem invalidation or cache invalidation. It not likely that Robert has a bug in the memory mapping. A few examples, and since this is related to cutscenes often it could be something like this.
A scene requires some chunk of media, the callback for when the render image frame, or audio frame is thought to be done by the game logic but due to timing in a callback from say the audio/rendering subroutines it leaks a few chunks. There could be other causes but that’s a flavor of what could be going on.
How could you best help? Check the real hardware for cutscenes and measure the memory requirements, then check the emulators and find emulator that has the same memory profile as the real hardware. Then check how it performs a on mister. If you could do that and provide a Robert some savestates (one that works from a software emulator) then he could test it on his software emulator and check if there’s a difference, that’s the ideal case then it could fix the logic dealing with these timing issues. Either finding a emulator he can run and ask other developers help with on a memory trace or whatever would be huge for him to track it down
Oh the good news is it’s probably just a single bug and it likely impacts other titles as well. Continuing this would be super helpful to him
Shh don’t the next testing vids lol
Check another game that runs smoother to see if ares has more overhead RAM across the board? I wonder if it has to do with some of the tricks Robert had to pull to get the core running.
That’ll be next steps for sure
I am not very familiar with the N64 hardware but this seems like the MMU is not keeping up with managing the memory. With how much attention to detail Robert puts into his cores I am guessing this is the limitation he was talking about with memory timings. I am guessing that he didn't declare the core finished if he thought this is was easily solvable. His FPGA implementation of the memory management unit is just not able to keep up with high demand requests and that is why it works for the vast majority of games but shits the bed on the games that push the hardware to it's limits.
It does seem memory mapping related as far as I can tell
It's already known that the Linux OS is unable to guarantee that enough RAM is immediately free to allocate fast enough to the MiSTer process when the core needs it, and that this is inherently unfixable due to the non-determinism of a running OS. Have you found or learned anything that contradicts that well-known explanation?
Yes and it’s in the vid. Allocations that aren’t tracking
Never played this, but it's hard to think of a better looking N64 game. Prob gonna check it out on an emu. Also... this shit definitely turned some poor kids into furries.
😱😕💩🤣
I’d say the prettiest N64 game is Banjo Tooie
Lol not sure how to translate this
😹
Best looking game technically probably goes to DK64 or Waverace, followed by Rogue Squadron, Jet Force Gemini, CBFD & Banjo Tooie, either way Rare had most of the eye candy games on N64, they used a lt of heavy compression for the ones that have to squeeze into 4MB RDRAM and don't use the extra 4MB RDRAM Expansion PAK, both JFG & CBFD were developed with it in mind but negged at the last minute prior to release, why? I don't know, I guess they were thinking they would sell more copies.