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

Neon64 with Savestates

Neon64 is an awesome NES emulator running on the N64, written purely in U64ASM by Halley's Comet Software (Source)

It only supports SRAM saving to the N64 controller pak, but no savestates for all the NES games without SRAM saving support.

So I hacked together Savestates. My functions copy three memory areas to the expansion pak. 1. The uncached framebuffer, 2. some cached variables and 3. the NES registers.

The menu can be accessed by pressing R+L, there is no CRC, header or whatsoever, so yes you can load garbage into Neon64 with this functionality and crash it. Since its using the expansion pak as a backup area, the N64 expansion pak is mandatory!

Saving: R+L, UP, A
Loading: R+L, UP, UP, A

Neon64 Savestate Menu

There are some color glitches when loading from a completely different level, since the RSP data is not managed. For cheating in the same level this should be no big problem.

The Mapper10 / MMC4 patch by Eisi is also included in my modded version. (Source1, Source2)

TODO (maybe next christmas):
- Add proper RSP data backup handling
- Add permanent savestates for the 64drive


Download:
- Binary
- Source

Happy testing and merry Christmas ;-)

N64 SRAM/FlashRAM results

Just wanted to post my results with implementing SRAM/FlashRAM support into my savegame dumper.

Forum love

The most active retro forums seem to be Benheck and Assemblergames. The first one is closed for new members and on the second it took one week until my thread got unlocked by a moderator. No comments after one week and today the thread got deleted.... Kind of disappointing, because I would have appreciated some external input. 

PIN mirroring

My first idea was to mirror AD0-AD15, ALE_L, ALE_H, VCC, GND and switch \READ, \WRITE.

The problem with this idea is that the 64drive will not start with the flashram connected to the mentioned PINs and if you connect them while the 64drive is already running you will just read crap. I also realized that the XPloder64 was interfering with the reading/writing commands. So I had to desolder the cartridge slot.

Full PIN switching

Because the PIN mirroring was not working I modified the gameshark cartridge so I can switch AD0-AD15, ALE_L, ALE_H, \READ and \WRITE during runtime. VCC and GND can of course be mirrored. This is the hardware setup:

Ugly PIN switch setup

Kind of messy, but works in general.

Writing the dumper

I thought this would be an easy task, because the N64 port of ScummVM already has FlashRAM support. It is based on hkz-libn64. Sadly neither the SRAM nor the FlashRAM routines were working for me at all. So I wrote my own routines based on the code from hkz-libn64 and LaC's n64 hardware dox. Against MESS and the 64drive SRAM/FlashRAM emulation these routines work perfectly. I used the following test to verify the functionality of the routines. I filled a buffer (sie of SRAM/FlashRAM) with values from a pseudo random generator and wrote the buffer to the SRAM/FlashRAM. Then I set the same SEED again for the pseudo random generator and filled the buffer with zeros. Now I read the SRAM/FlashRAM into the buffer and compared it to the results from the pseudo random generator. If this works it is very likely that my routines work.

The results

As mentioned above the routines work great against MESS and the 64drive, but not so much against an actual SRAM, FlashRAM chip. There are some strange read/write errors.

Strange SRAM/FlashRAM read errors

I am still not sure if this a problem of my software routines or because of bad wiring. I rewired several times and resoldered some parts, but I was still getting very strange results. I was able to back up F-Zero X (SRAM), 1080 (SRAM) and Pokemon Stadium (FlashRAM) which tells me that it is working in general. But it is not working perfect so I declared the code routines as experimental and I can not ensure that it will work properly for your games. Games I had no luck with are Zelda OOT (SRAM), Zelda MM (FlashRAM), Jet Force Gemini (FlashRAM) and Paper Mario (FlashRAM). It could just be a bad connection problem, but simply neither have the time nor the urge to create a custom board with full soldering for all 20 important connections with switches. These are all games anyway which I would start from the beginning if I ever wanted to play them again. So I backed up the three games which were most important to me.

The final dumper

Here you can see some screenshots of the dumper with experimental SRAM/FlashRAM support and can download it here.

The main menu

SRAM quick Hexview

FlashRAM copy feature with CRC

Future work

I am only partially happy, because it is no definitive solution, but neither a full soldering setup nor switching to the official N64 setup are solutions I think would justify the effort. The only think I might try is to check if the XPloder64 is compatible with GSuploader. But most likely it wont be compatible, because the Gameshark was from Datel and the Xploder64 from Blaze. The only Xploder64 software seems to be X-Killer 0.6, which would involve setting up a Windows 98 PC again. Maybe I am bored on Christmas...