Toggle sidebar

nullDC4Wii

  • Thread starter Thread starter niuus
  • Start date Start date
  • Views Views 22,302
  • Replies Replies 211
  • Likes Likes 23
Xale007 said:
If you give me source code of software it has already been implemented, I can try
Click to expand...
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.
 
  • Like
Reactions: 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 :)
 
  • Like
Reactions: corrigo and 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.

depaul said:
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 :)
Click to expand...
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)
 
Last edited by niuus,
  • Like
  • Love
Reactions: corrigo, Garcimak, Xale007 and 1 other person
Xale007 said:
indeed, i'm not sure CHD is relevant, may test someday
Click to expand...
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.
Cris1997XX said:
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
Click to expand...
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... ?

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

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?
 
Last edited by niuus,
  • Like
Reactions: Xale007 and depaul
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:

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)
 
  • Like
Reactions: depaul
Xale007 said:
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:

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)
Click to expand...

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
 
  • Like
Reactions: depaul and Xale007
Ok thank you guys for your research regarding CHD integration feature.

This emulator has made good progress already, keep up the awesome work :)
 
Xale007 said:
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:

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

Not a good idea to integrate this honestly
Click to expand...
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.

Xale007 said:
We can still use compress CDI/GDI anyway (my castlevania is 35mb instead of 1.2 Gb)
Click to expand...
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.
 
Last edited by niuus,
  • Like
Reactions: depaul

Site & Scene News

Go to forum More news

Popular threads in this forum

Seta GX fork

Homebrew app Emulator  VectrexWii - Back in Active Development!

GTA VC WII (ReVC Wii) Wii Port

New Visual Boy Advance GX - with dynamic recompiler

Homebrew  NetSurf Wii

Star Fox 64 on Wii VC has crackling audio

A guide to dealing with nkit.iso on a Mac

Hacking  [RELEASE] vc64_240p — real 240p for N64 Virtual Console on the Wii (no deflicker blur)