Whether it’s your favorite programming language, or your favorite beverage, there’s no denying Java is everywhere. Now, it’s even on the Nintendo 64, thanks to the valiant efforts of [Mike Kohn]. Even better, he’s coded a demo to show off its capabilities!
The project took plenty of work. [Mike] went all the way down to the assembly level to get Java code running on the N64. The project builds on the work that he did previously to get Java running on the PlayStation 2. Notably, both the Sony and Nintendo consoles do have some similarities — both are based on MIPS CPUs.
The demo itself is a work of art. It features the typical “3 billion devices run Java” screen, followed by some truly chunky bass and wailing guitar sounds. It’s followed by all the dancing shapes, sinusoidal text, and bright colors you could shake a stick at.
For those interested in the nitty gritty, [Mike] delves deep into the details of what it took to get everything running. That includes both using the code in an emulator, as well as how to get it going on real Nintendo hardware, something we’ve looked at before.
The joke was when the Nintendo 64 first hit the streets around a quarter century ago, that the 64 in the name referred not to the technology on board, but to the excessive cost of the cartridges. Whatever the truth in that, it’s something now completely laid to rest by [Konrad Beckmann] with his Nintendo 64 flash cart powered by a Raspberry Pi Pico (Nitter Link).
The schematic is surprisingly simple, in that the Pico does everything required to both interface to the N64 and to an SD card to hold the software. The clever work is done by the RP2040 firmware, which can be found along with the hardware details in the “develop” branch of the project’s GitHub repository. And while the earliest version was a Raspberry Pi Pico with a host of jumper wires, the more polished version focuses on a custom PCB and bare RP2040 chip.
Perhaps the N64 hasn’t received the attention it should have over the years, overshadowed as it was by its competitors such as the original PlayStation, but it’s projects like this one which remind us that there’s still life in Nintendo’s ’90s flagship. Speaking of which, if you were on Team Sony back in the day but still want to put your Pi Pico to use, check out this DIY PlayStation Memory Card we covered recently.
When Portal came out in 2007, developers Valve chose not to release the groundbreaking title on an obsolete Nintendo console long out of production. Nobody cared at the time, of course, but [James Lambert] is here to right that wrong. Yes, he’s porting Portal to the N64.
The port, or “demake,” as [James] calls it, has been under construction for some time. The project has posed some challenges: Portal was developed for PCs that were vastly more powerful than the Nintendo 64 of 1996. Thus, initial concerns were that the console wouldn’t be able to handle the physics of the game or render the recursive portal graphics.
However, hard work has paid off. [James] has chipped away, bit by bit, making improvements to his engine all the while. The latest work has the portals rendering nicely, and the companion cube works just the way you’d expect. There’s also a visible portal gun, and the engine can even render 15 recursive layers when looking through mirrored portals. Sixteen was too much.
Of course, there’s still lots to do. There’s no player model yet, and basic animations and sound are lacking. However, the core concept is there, and watching [James] flit through the not-quite-round portals is an absolute delight. Even better, it runs smoothly even on original Nintendo hardware. It’s a feat worthy of commendation.
We had no idea what [James] had in store back when we featured his work creating real-time shadows on N64 hardware. Now we know! Video after the break.
When working on any software project, the developers have to balance releasing on time with optimizations. As long as you are hitting your desired time constraints, why not just ship it earlier? It’s no secret that Super Mario 64, a hotly anticipated launch title for the Nintendo 64 console in 1996, had a lot of optimizations left on the table in order to get it out the door on time. In that spirit, [Kaze Emanuar] has been plumbing the depths of the code, refactoring and tweaking until he had a version with serious performance gains.
Why would anyone spend time improving the code for an old game that only runs on hardware released over two decades ago? There exists a healthy modding community for the game, and many of the newer levels that people are creating are more ambitious than what the original game could handle. But with the performance improvements that [Kaze] has been working on, your budget for larger and more complex levels suddenly becomes much more significant. In addition, it’s rumored that a multi-player mode was originally planned for the game, but Nintendo had to scrap the feature when it was found that the frame rate while rendering two cameras wasn’t up to snuff. With these optimizations, the game can now handle two players easily.
Luigi has been waiting 26 years for his chance to shine.
[Kaze] has a multi-step plan for improving the performance involving RAM alignment, compiler optimizations, rendering improvements, physics optimizations, and generally reducing “jankiness.” To be fair to the developers at Nintendo, back then they were working with brand new hardware and pushing the boundaries of what home consoles were capable of. Modeling software, toolchains, compilers, and other supporting infrastructure have vastly improved over the last 20+ years. Along the way, we’ve picked up many tricks around rendering that just weren’t as common back then.
The central theme of [Kaze]’s work is optimizing Rambus usage. As the RCP and the CPU have to share it, the goal is to have as little contention as possible. This means laying out items to improve cachability and asking the compiler to generate smaller code rather than faster code (no loop unrolling here). In addition, certain data structures can be put into particular regions of memory that are write-only or read-only to improve resource contention. Logic bugs are fixed and rendering techniques were improved. The initial results are quite impressive, and while he isn’t done, we’re very much looking forward to playing with the final product.
Although the Nintendo 64 console has in the minds of many been relegated to the era of ‘firmly obsolete graphics’, since its graphic processor’s (GPU’s) lineage traces directly to the best which SGI had to offer in the 1990s, it too supports a range of modern features, including dynamic shadows. In a simple demo, [lambertjamesd] demonstrates how this feature is used.
As can be seen in the demonstration video (linked after the break), this demo features a single dynamic light, which casts a shadow below the central object in the scene, with a monkey object floating around that casts its own shadow (rendered into an auxiliary frame buffer). This auxiliary buffer is then blended into the main buffer, as explained by [ItzWarty] over at /r/programming on Reddit.
This effectively means that the main scene uses a shadow volume, which was used extensively with Doom 3. The primary reasons for why the N64 didn’t use shadow volumes all over the place was due to the limitations this places on the shadow caster (objects) in the scene, such as the need to be convex, and overlap is likely to lead to artifacts and glitches.
Doom 3 would fix this with the use of a stencil buffer that would further refine the basic dynamic lighting support on the N64, which ultimately would lead to the fancy video game graphics we have today. And which no doubt will look properly obsolete in another decade again, as usual.
We’ve seen quite a few retro gaming consoles physically modded to house modern emulation hardware, but the NUC-64 by [RetroModder] stands out as one of the most impressive Nintendo 64 guttings that we’ve seen to date.
Observed from the front, the NUC-64 almost resembles a stock Nintendo console. The project’s name is printed across the vestigial cartridge slot, and two suspiciously modern wireless networking antennas can be seen poking out from the back. The console’s modifications are fully revealed when looking at it from the rear – gone is the power brick socket, which now houses the I/O for the replacement motherboard. A custom 3D printed I/O shield keeps everything looking neat and tidy.
Internally, the new hardware is no slouch. The Intel NUC is a small-form-factor PC, and this miniature battlestation sports an 1.6GHz Intel N3700 Pentium processor, 4GB of DDR3 RAM, WiFi/Bluetooth connectivity and an M.2 SSD. This hardware runs circles around the original Nintendo 64, and is more than capable of emulating games from that system.
Most total conversions would call it a day here, however [RetroModder] has taken it a step further by producing a custom PCB that neatly ties together the console’s front I/O. Most importantly, two Mayflash N64-to-USB converters means that your favorite 1990s games can be enjoyed with the original controllers. The original power LED and reset switch are present, as is the sliding power switch which retains its original purpose, thanks to a simple 555 circuit that sends the expected power-on and power-off signals to the motherboard with each slide of the power switch. Additionally, a system of 3D printed mounts and brackets keeps everything secure inside the case.
All the build details can be found here. The NUC-64 follows on from last month’s GamecubePC. The build quality and attention to detail makes this conversion rather special, and it’s clear that a lot of care and planning was taken to pull this off. Hopefully the original N64 hardware can be repurposed as well, perhaps as a new portable console?
The Nintendo 64 was one of the consoles that properly heralded in the era of 3D gaming. However, its controller is of a design we wouldn’t consider ideal today. For the FPS games that were so popular on the N64, a mouse and keyboard could do much better. [The Hypocaust] set out to make it happen.
The N64 polls the controller and receives button and analog stick data in return. Four bytes are sent by the controller, with 14 bits covering the buttons and 8 bits covering the horizontal and vertical axes of the analog stick, respectively. Thus, if keyboard presses and mouse movements from a PC could be pumped to a microcontroller which reformatted the data into signals the N64 could understand, everything would work nicely.
Initial attempts to get things working with code borrowed from a [James Read] faced an issue of a 3-second lag between keypresses and actions reaching the N64. Upgrading to a faster microcontroller only made things worse, taking the lag out to a full 16 seconds. The problem? The code borrowed for the project was storing keypresses in a buffer that was creating the delay. Once eliminated, the system worked.
An installer for the software is available, but you’ll have to be comfortable with running a strange executable if you want to use it. We’ve seen similar work before too, such as the USB64 project. Video after the break.
