nullDC4Wii

[niuus]

Put your GDI in SD:/dicsc before testing USB

Post automatically merged: Aug 21, 2026

alpha0.63 released

https://github.com/BenoitAdam/nullDC4Wii/releases/tag/alpha0.63

Will play it in some hours.

DualShock 4 / DualSense in the future?

 

[Xale007]

If you give me source code of software it has already been implemented, I can try

 

[niuus]

If you give me source code of software it has already been implemented, I can try

A flexible implementation would be this one, as it uses .ini files read from the SD/USB for a big range of supported controllers (generic HID USB even), once implemented these can be manually customized or created by the users, which was very useful some years ago to create my own .ini profile for the PSX mini USB controller.

 

[depaul]

Thank you guys for your great work. Just a request please: to support CHD format, since CHD files are smaller compared to CDI/GDI (maybe 30%-50% smaller).

Thanks for this wonderful emulator! I'm enjoying Dreamcast booting sound on my Wii U

 

[niuus]

@Xale007 a bug I just noticed today due to a media data migration, as the SD I used previously died: no presets are ever being read when you load the emulator from USB.

The folder show all the files inside the USB storage, but games don't launch. It returns back to the Homebrew Channel.

The nulldc.cfg file is being created at the root of USB.

ndclog.txt file is being created at the root of SD.

Also the emulator starts reading using the SD storage, which shouldn't exactly be the case if it is starting from USB.

Thank you guys for your great work. Just a request please: to support CHD format, since CHD files are smaller compared to CDI/GDI (maybe 30%-50% smaller).

Thanks for this wonderful emulator! I'm enjoying Dreamcast booting sound on my Wii U

Good idea for the future. Added to the QoL suggestions at the main post, plus a tidy folder structure suggestion for the emulator:

• root://nullDC4Wii/bios/ (for all the related Dreamcast files)
• root://nullDC4Wii/bios/dc_flash_wb.bin (dc_flash saved user data)
• root://nullDC4Wii/data/dynarec_*.bin files
• root://nullDC4Wii/games/ (for all the Dreamcast discs)
• root://nullDC4Wii/vmu/vmu_save_*.bin (for all the VMU files)
• root://nullDC4Wii/ndclog.txt (for the log file)

 

[Cris1997XX]

CHD files are compressed and the Wii's processor is very weak by today's standards, I'm not sure it could handle decompressing a game while running it

 

[Xale007]

indeed, i'm not sure CHD is relevant, may test someday

didn't realise you can load app from USB so yeah... there is something to change here I guess

 

[niuus]

indeed, i'm not sure CHD is relevant, may test someday

It is useful for not wasting a ton of space with GDI images filled with zeros. The important thing would be to determine it doesn't cause too much overhead for nullDC4Wii. CHD is just a container so you can even pick a lighter compression if the default is too much for your emulator.

CHD files are compressed and the Wii's processor is very weak by today's standards, I'm not sure it could handle decompressing a game while running it

I think at least a dozen projects I've tested over the years already support CHD since a long time (even newer ones like Seta GX / Z-GX), so... ?

didn't realise you can load app from USB so yeah... there is something to change here I guess

I even thought you used to test from USB, so it was a surprise to find out it doesn't even work at all. I'm just finding out, so it never did before?

 

[Xale007]

about CHD :

Will the CHD be decompressed at the beginning once and for all or during the game?
- if at the beginning : how much time will it take
- if during the same : will that cause slowdown ?

During the game — CHD isn't a "decompress once at boot" format. It's read in small chunks (hunks, ~19KB each) on demand, exactly when the emulator requests that sector — same access pattern as reading a raw GDI/CDI. There's no upfront full-decompress step (and you wouldn't want one: a full GD-ROM image is ~1GB, you don't have RAM to hold it decompressed).

Will it cause slowdowns?

With zlib-compressed CHDs (cdzl): unlikely to be noticeable — decode is fast enough (~2ms/hunk estimated) to hide behind normal disc I/O latency.
With LZMA-compressed CHDs (cdlz, the common default from chdman): possible micro-stutters during heavy streaming moments (texture loads, FMV, level transitions) since decode cost (~4-9ms/hunk estimated) starts competing with your already-tight frame budget.
Bottom line: yes it'll cause slowdown risk if you accept off-the-shelf LZMA CHDs, but negligible risk if you require zlib-compressed ones.

Post automatically merged: Today at 6:16 PM

TLDR depending of CHDs some will work, some can micro-stutters...

Not a good idea to integrate this honestly

We can still use compress CDI/GDI anyway (my castlevania is 35mb instead of 1.2 Gb)

 

[Disorarara]

about CHD :

Will the CHD be decompressed at the beginning once and for all or during the game?
- if at the beginning : how much time will it take
- if during the same : will that cause slowdown ?

During the game — CHD isn't a "decompress once at boot" format. It's read in small chunks (hunks, ~19KB each) on demand, exactly when the emulator requests that sector — same access pattern as reading a raw GDI/CDI. There's no upfront full-decompress step (and you wouldn't want one: a full GD-ROM image is ~1GB, you don't have RAM to hold it decompressed).

Will it cause slowdowns?

With zlib-compressed CHDs (cdzl): unlikely to be noticeable — decode is fast enough (~2ms/hunk estimated) to hide behind normal disc I/O latency.
With LZMA-compressed CHDs (cdlz, the common default from chdman): possible micro-stutters during heavy streaming moments (texture loads, FMV, level transitions) since decode cost (~4-9ms/hunk estimated) starts competing with your already-tight frame budget.
Bottom line: yes it'll cause slowdown risk if you accept off-the-shelf LZMA CHDs, but negligible risk if you require zlib-compressed ones.

Post automatically merged: Today at 6:16 PM

TLDR depending of CHDs some will work, some can micro-stutters...

Not a good idea to integrate this honestly

We can still use compress CDI/GDI anyway (my castlevania is 35mb instead of 1.2 Gb)

I agree it might not be worthwhile to spend time on CHD support when the Dreamcast is easily the heaviest console for the Wii to try and emulate - every CPU cycle counts in this case

 

[depaul]

Ok thank you guys for your research regarding CHD integration feature.

This emulator has made good progress already, keep up the awesome work

 

[niuus]

about CHD :

Will the CHD be decompressed at the beginning once and for all or during the game?
- if at the beginning : how much time will it take
- if during the same : will that cause slowdown ?

During the game — CHD isn't a "decompress once at boot" format. It's read in small chunks (hunks, ~19KB each) on demand, exactly when the emulator requests that sector — same access pattern as reading a raw GDI/CDI. There's no upfront full-decompress step (and you wouldn't want one: a full GD-ROM image is ~1GB, you don't have RAM to hold it decompressed).

Will it cause slowdowns?

With zlib-compressed CHDs (cdzl): unlikely to be noticeable — decode is fast enough (~2ms/hunk estimated) to hide behind normal disc I/O latency.
With LZMA-compressed CHDs (cdlz, the common default from chdman): possible micro-stutters during heavy streaming moments (texture loads, FMV, level transitions) since decode cost (~4-9ms/hunk estimated) starts competing with your already-tight frame budget.
Bottom line: yes it'll cause slowdown risk if you accept off-the-shelf LZMA CHDs, but negligible risk if you require zlib-compressed ones.

Post automatically merged: Today at 6:16 PM

TLDR depending of CHDs some will work, some can micro-stutters...

Not a good idea to integrate this honestly

cdzs is approximately 16 times faster than cdlz, and 3-4 times faster than cdzl. cdlz isn't even used by emulators on Wii, cdzl being the favored one, and cdzs for a couple of others.

chdman does all 3 formats, cdzl being the default.

We can still use compress CDI/GDI anyway (my castlevania is 35mb instead of 1.2 Gb)

CDI is not a compression system, though. You need to manually unpack and edit the image file (identify and erase dummy files, hack others, recompress audio and video, sometimes delete audio tracks, etc.), then reconstruct it as a virtual CD, on a case-by-case basis.