Small Neon64 HDMI Audio fix

I finally got my UltraHDMI mod and can now reproduce the reported high frequency “loud broken screech” in the L+R menu. It happens roughly 50% of the time if you enter the L+R menu. It is only present over HDMI audio and is not present on the RCA Audio.

I debugged it down to the audio smoothness function of Neon64. Neon64 fills the audio buffer with the same byte, which creates silence over RCA, but a constant sound over the UltraHDMI Audio.

As a small workaround I am now clearing the audio buffer every time the L+R menu is entered, which creates a short “plop” sound, but no more constant sound.

The small fix is attached below as version 0.3c.

In short, if you are using RCA audio stay with 0.3b for audio smoothness and if you want to use HDMI audio try version 0.3c.

As a full fix, the libdragon audio pause silence interrupt handler could be ported to Neon64 or the UltraHDMI Audio could maybe behave similar to the RCA audio.

Download

- Binary
- Source

Play Diddy Kong Racing (USA) (NTSC) in German

For whatever reason the US NTSC version of Diddy Kong Racing contains the full German texts from the European PAL version. It is not selectable in the options menu but you can enforce it by editing the options via the EEPROM.

Set offset 0x78 - 0x7F of the EEPROM to:

56 00 00 00 03 FF FF F3 – for English

5A 00 00 00 03 FF FF F7 – for German

5E 00 00 00 03 FF FF FB – for French

Works on version 1.0 and 1.1 of the US NTSC version.

Neon64 screenshot functionality

Final version of mod (for now) with rewritten pattern table restoration handling and palette fixes.

Persistent save state now works for much more games

Features of 0.3b mod compared to original 1.2b:

• Temporary save state in Expansion Pak memory
• Persistent save state in N64 SRAM
• NES SRAM to N64 SRAM redirection (saving to Memory Pak can still be used)
• Screenshot functionality (64drive USB)
• Dither filter disabled

Requirements:

• Expansion Pak
• Dezaemon 3D SRAM (emulation)

Screenshots can be done with the following steps:

Screenshot from actual Neon64 emulator via 64drive USB

1. Use L+R menu and select "Screenshot - 64driveUSB"
2. Dump framebuffer via USB: 64drive_usb -d C:\your_folder\framebuffer.bin 1 0x300000 0x23000
3. Convert to BMP: python neon64capture.py
4. Convert to PNG: convert screenshot.bmp screenshot.png

Another Screenshot done via 64drive USB

Download

- Binary
- Source
- Screenshot util for 64drive

Neon64 with improved persistent Savestates

Main changes in version 0.3

• RSP DMEM backup code added
• SRAM savestate error handling 
• NES Graphics Compiler Cache invalidation 

Other stuff:

• disabled dither filter (thx marshallh)
• reordered L+R menu more logically
• small boundary errors fixed

RSP DMEM backup code added

Fixes wrong background colours when loading states in some games. Applies for Expansion Pak and SRAM state loading. E.g. Super Mario Bros. 1 and 3 have no more permanent wrong colours after loading.

SRAM savestate error handling

SRAM savestates now also have header and footer. So no more loading garbage by accident. (No SRAM emulation or no prior saving) Since no CRC is used the SRAM content can still be changed for cheating. The complete NES memory is also part of the savestate, so you can cheat by editing the SRAM on the SD card.

NES Graphics Compiler Cache invalidation

Persistent SRAM savestates are now fully usable in Super Mario Bros. 1 and 3.
In most other games loading the SRAM savestate, killing yourself in game, wait for the game to reload the level and loading the SRAM state again can restore the cache. This works e.g. in Super Mario Bros. 2, Contra, Kirby's Adventure, Metroid and Megamen. The emulator is not designed to get its entire pattern table cache deleted between two frames. So the results will vary depending on the game. The described strategy works for me on the tested games.
You should not use the Expansion Pak savestate while the screen is still showing garbage since it would back up the garbage.

Big thanks to marshallh the 64drive developer for activating the SRAM emulation in the 64drive menu, useful hints how to further improve the Neon64 emulator and the 64drive as a great N64 development device in general.

Download

- Binary
- Source

Neon64 NES-SRAM to N64-SRAM redirection

Requirements for new version

• N64 Expansion Pak
• Good: 256kbit SRAM -> NES-SRAM Saving
• Better: 768kbit SRAM (Dezaemon 3D) -> NES-SRAM Saving + permanent save state (BETA)

Note

Until the SRAM handling for the emulator is activated in the backup devices (64drive) menu the new features will only work via USB or via an appended ROM file and manual SRAM activation.

New features in version 0.2

NES-SRAM to N64-SRAM redirection

The NES-SRAM can now be loaded and stored to the N64-SRAM. A part of the first 256kbit SRAM is used, so common 256kbit SRAM and 768kbit SRAM (Dezaemon 3D) is compatible for this feature.

NES-SRAM loaded from N64-SRAM

Loading NES-SRAM

If the NES game supports SRAM, Neon64 will first try to load the SRAM from the Controller Pak in Controller 1, if no Controller Pak is present it will try to load the NES-SRAM from the N64-SRAM. So you can use Controller Pak and N64-SRAM as source. This happens automatically during rom loading.

Saving NES-SRAM

Saving NES-SRAM has to be triggered manually via the L+R Menu (see picture). Options for saving to the Controller Pak and the N64 SRAM exist. The latter is recommended for easy SRAM on SD card management.

L+R menu to save NES-SRAM to N64-SRAM oder Controller Pak

Temporary save states basic error handling

It is no longer possible to load the save state from the Expansion Pak without saving once beforehand.

Permanent save states in N64-SRAM (BETA)

If your backup device supports 768kbit SRAM (Dezaemon 3D) the extra space can be used to save the current Neon64 state. This feature is unfinished because the cache of the NES graphics compiler (background pattern table) is not saved/loaded. So the game will show a lot of garbage but will work normal otherwise. The pattern table is far too big for N64-SRAM saving. So for this to work I will either have to rewrite parts of the compiler, implement some compression, or figure out how to invalidate the compiler cache. The current results highly depend on the game and how it utilises sprites. Walking around can partially fix some games. The more complex the game the more garbage you will see on screen.

NEON64 is great

Download

- Binary

- Source

Future work:

• Add proper RSP backup code to fix wrong colours
• Fix pattern table cache handling