Homebrew Seeking Help... Nintellivision - an Emulator for the DS/DSi

[Coto]

I managed to get all the speed back... and a little more besides!

And I found out why it's crashing on the DS. I'm out of memory

This is an emulator designed on the PC and they have huge look-up tables... and it doesn't take long for the 4MB to get swallowed up.

On the DSi there's no problem as it's got 4x the memory (16MB vs 4MB).

I'll optimize the memory and get it back to running...

Have you delved yet into streaming from DLDI? There are a lot of NDS projects doing that. From what i've found, it's best to let the SD filesystem read chunks of dldi sectors. FatFS allows to read chunks of sectors (I imagine libfat does the same), and halves the DLDI calls by at least half and that means a small speedup. (also because you'd be skipping the POSIX calls).

This is a VS2012 project implementing petitFS for embedded/baremetal ARM7 (NTR) but also runs in windows for further debugging.
Coto88 / petitfs-tgds — Bitbucket

and this is a VS2012 project implementing FatFS for TGDS ARM9 (NTR/TWL) which features the complete set of POSIX calls you'd use in unix/linux/nds homebrew (TGDS projects and libnds)
Coto88 / toolchaingenericds-helper — Bitbucket

this way you can debug your own NTR/TWL filesystem tasks before doing it manually through DS homebrew, as it lacks the debugging stuff and takes a lot of iterations (maybe months or years, like I used to do).... once you got something working in there, it can be moved easily into NDS homebrew!

 

[wavemotion]

Thanks @Coto - I'll take a peek.

Right now I'm right on the edge of fitting everything in the DS. Looking at the .map file I'm surprised to see quite a chunk of memory utilized by the libnds FAT library. Mostly "debug" stuff I think... is there any way to eliminate this?

.debug_info 0x0000000000000000 0x1c3e1
*(.debug_info)
.debug_info 0x0000000000000000 0x204d /opt/devkitpro/libnds/lib/libfat.a(libfat.o)
.debug_info 0x000000000000204d 0x260 /opt/devkitpro/libnds/lib/libfat.a(disc.o)
.debug_info 0x00000000000022ad 0x3783 /opt/devkitpro/libnds/lib/libfat.a(fatfile.o)
.debug_info 0x0000000000005a30 0x12da /opt/devkitpro/libnds/lib/libfat.a(cache.o)
.debug_info 0x0000000000006d0a 0x2833 /opt/devkitpro/libnds/lib/libfat.a(fatdir.o)
.debug_info 0x000000000000953d 0x2fcb /opt/devkitpro/libnds/lib/libfat.a(directory.o)
.debug_info 0x000000000000c508 0x2c74 /opt/devkitpro/libnds/lib/libfat.a(partition.o)
etc
.debug_abbrev 0x0000000000000000 0x4e5e
*(.debug_abbrev)
.debug_abbrev 0x0000000000000000 0x3e2 /opt/devkitpro/libnds/lib/libfat.a(libfat.o)
.debug_abbrev 0x00000000000003e2 0xd8 /opt/devkitpro/libnds/lib/libfat.a(disc.o)

 

[Coto]

Honestly I wish I could have taken what I wrote earlier a couple of years back in time, it's worth about half the time I've spent with NDS development, as it is mostly file system related tasks, and without debugging really.... not recommended for sanity reasons. lol

Thanks @Coto - I'll take a peek.

Right now I'm right on the edge of fitting everything in the DS. Looking at the .map file I'm surprised to see quite a chunk of memory utilized by the libnds FAT library. Mostly "debug" stuff I think... is there any way to eliminate this?

.debug_info 0x0000000000000000 0x1c3e1
*(.debug_info)
.debug_info 0x0000000000000000 0x204d /opt/devkitpro/libnds/lib/libfat.a(libfat.o)
.debug_info 0x000000000000204d 0x260 /opt/devkitpro/libnds/lib/libfat.a(disc.o)
.debug_info 0x00000000000022ad 0x3783 /opt/devkitpro/libnds/lib/libfat.a(fatfile.o)
.debug_info 0x0000000000005a30 0x12da /opt/devkitpro/libnds/lib/libfat.a(cache.o)
.debug_info 0x0000000000006d0a 0x2833 /opt/devkitpro/libnds/lib/libfat.a(fatdir.o)
.debug_info 0x000000000000953d 0x2fcb /opt/devkitpro/libnds/lib/libfat.a(directory.o)
.debug_info 0x000000000000c508 0x2c74 /opt/devkitpro/libnds/lib/libfat.a(partition.o)
etc
.debug_abbrev 0x0000000000000000 0x4e5e
*(.debug_abbrev)
.debug_abbrev 0x0000000000000000 0x3e2 /opt/devkitpro/libnds/lib/libfat.a(libfat.o)
.debug_abbrev 0x00000000000003e2 0xd8 /opt/devkitpro/libnds/lib/libfat.a(disc.o)

I think that's ELF symbols human readable code/sections, generated by the GCC compiler. It's there when you disassemble the .o files (using GCC tools), so instead of just reading ARM/THUMB assembly, there's actually a line-by-line C source code of what the object was originally assembled into.

If anything, i've found FatFS to be very fast, and also can be shrunk down through a config file.

 

[wavemotion]

I just checked in what will likely be the 1.0 candidate release of NINTV-DS. Not ready for the build yet... needs some testing.

It's as fast as any release yet on the DSi... and on the older DS you can certainly run some games like the AD&D games where speed isn't as critical (or you can turn sound off for full speed). There is a slow memory leak somewhere - on the older DS you can load about a half-dozen games before it runs out of memory... on the DSi I was able to load 100+ games in a row with no problems. But that's a minor problem for tomorrow

 

[wavemotion]

Release 1.0 is out... I started a new thread so I could change the title and not have 3 pages of "why can't I get sound working right" before we get to the GOOD STUFF

https://gbatemp.net/threads/introducing-nintellivision-an-emulator-for-the-ds-dsi.593786/

Please post on the new thread... thumbs and positive comments/critiques continue to be hugely appreciated!