reading the content of /rd

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
Post Reply
User avatar
lerabot
Insane DCEmu
Insane DCEmu
Posts: 134
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Sun Nov 01, 2015 8:25 pm
Has thanked: 2 times
Been thanked: 19 times

reading the content of /rd

Post by lerabot »

I've been going a bit crazy over the last couple hour.

First of all, I never realized the maximum file you could get out of a romdisk at once is 16!
I've tried chanding the #define MAX_RD_FILES 16 flag. Do I need recompile kos for this to work?

Also, I have a full working way to display the content of the root of the vfs, /cd, /pc... for some reason I can't get the ram to work!
I'm trying to verify that all the files are fully transfered to ram.

Any clues?

Code: Select all

void printDir() {
  file_t    d;
  dirent_t  *dir;
  const char * path = "rd";

    char buf[512];
    d = fs_open(path, O_RDONLY  | O_DIR);
    if (d) {
      printf("Checking Romdisk\n");
      while (dir = fs_readdir(d)) {
        printf("%s\n", dir->name);
      }
    } else {
      printf("No file in /rd\n");
    }
    fs_close(d);
}
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5663
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: reading the content of /rd

Post by BlueCrab »

You can only have 16 files actually open at a time on the romdisk. In order to change that limit, you would need to change that macro and recompile KOS. Mind you, there's usually not much of a reason to have more than 16 files actually open at one time, which is probably why that number was chosen.

The code you've included should list the files on the romdisk, not the ramdisk. The built-in ramdisk is mounted at /ram, not /rd.
User avatar
lerabot
Insane DCEmu
Insane DCEmu
Posts: 134
Joined: Sun Nov 01, 2015 8:25 pm
Has thanked: 2 times
Been thanked: 19 times

Re: reading the content of /rd

Post by lerabot »

I've double cheked all of it.

I can read the content of /cd, /pc, and root. any romdisk that I mount doesn't work.
I've checked /ram /rd and tried with different mount points.

Also, there's something super strange going on with file naming or handles.

Let's say I have a file called spritesheet.json in my romdisk. I'll try to open if using fs_open(path); and get an error that the file is not present.
If I load the same exact file from the /pc, it works.
I'll rename both the file and char *path to sprite.json, everything is fine.

FOUND A POSSIBLE SOLUTION- COULD BE USEFUL FOR ANYONE ELSE USING ROMDISK

This drove me NUT! I checked the fs_mount_romdisk.c file and turns out that the filename probably get cut short since it's stored in filename[16]

spritesheet.json is 16 char, so I don't know if it's not storing the null char at the end or something, but renaming all my spritesheet.json to sprite.json makes everything work again.

Could this be mentionned in the documentation? Or perhaps I should update my Romdisk tutorial to include this info
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5663
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: reading the content of /rd

Post by BlueCrab »

That's... quite strange, since there's no copy into one of those structures anywhere -- the code is just overlaying that structure over the memory that the romdisk is present in. Unless GCC is doing something weird and short-circuiting the strlen() or strncasecmp() calls, that shouldn't happen.

Just out of curiosity, can you try changing the "char filename[16]" to "char filename[]" on line 48 of fs_romdisk.c, recompile KOS, and see if that maybe fixes the issue with opening files with longer names? It almost assuredly break reading files without adjusting line 234 of the same file, but I'm curious if it fixes opening them... I'd check myself, but I probably won't get a chance before tomorrow afternoon to do so. :?
User avatar
lerabot
Insane DCEmu
Insane DCEmu
Posts: 134
Joined: Sun Nov 01, 2015 8:25 pm
Has thanked: 2 times
Been thanked: 19 times

Re: reading the content of /rd

Post by lerabot »

I haven't changed it because shortening the filename seem to work. But there's defenitly something strange with similar name.

I have a romdisk with 9 button named b1.png to b9.png.
I also happen to have 2 sound files called b1.wav and b2.wav.

When I load my 9 buttons, b1.png and b2.png won't load.

I know this doesn't really count, but all of the mentionned above works in emulator, just not on real console.
User avatar
lerabot
Insane DCEmu
Insane DCEmu
Posts: 134
Joined: Sun Nov 01, 2015 8:25 pm
Has thanked: 2 times
Been thanked: 19 times

Re: reading the content of /rd

Post by lerabot »

I still have some wierd naming issue. I might just skip using romdisk entirely if I can't figure this one out.
My project has a bunch of files now and I'm wondering if the sheer number of file make things problematic. I'm at around 1200ish files (assets, sound, code, etc)

I've went around and tried to to change that filename thing and got a compile error

Code: Select all

Makefile:47: warning: overriding commands for target `clean'
/opt/toolchains/dc/kos/Makefile.prefab:19: warning: ignoring old commands for target `clean'
./make_banner.sh
error: unknown option `broken'
usage: git describe [options] <commit-ish>*
   or: git describe [options] --dirty

    --contains            find the tag that comes after the commit
    --debug               debug search strategy on stderr
    --all                 use any ref
    --tags                use any tag, even unannotated
    --long                always use long format
    --first-parent        only follow first parent
    --abbrev[=<n>]        use <n> digits to display SHA-1s
    --exact-match         only output exact matches
    --candidates <n>      consider <n> most recent tags (default: 10)
    --match <pattern>     only consider tags matching <pattern>
    --always              show abbreviated commit object as fallback
    --dirty[=<mark>]      append <mark> on dirty working tree (default: "-dirty")

./make_banner.sh: 47: [: unexpected operator
awk -f make_authors.awk < ../../../../AUTHORS > authors.h
kos-cc  -c banner.c -o banner.o
In file included from banner.c:7:0:
banner.h:2:1: warning: missing terminating " character [enabled by default]
banner.h:2:1: error: missing terminating " character
make[4]: *** [banner.o] Error 1
make[4]: Leaving directory `/opt/toolchains/dc/kos/kernel/arch/dreamcast/kernel'
make[3]: *** [_dir_kernel] Error 2
make[3]: Leaving directory `/opt/toolchains/dc/kos/kernel/arch/dreamcast'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/opt/toolchains/dc/kos/kernel/arch'
make[1]: *** [_dir_arch] Error 2
make[1]: Leaving directory `/opt/toolchains/dc/kos/kernel'
/bin/sh: 1: exit: Illegal number: -1
make: *** [all] Error 2
Here is the content of that make_banner.h file (which is a bit tricky to make sense of ;P)

Code: Select all

#!/bin/sh

# Re-creates the banner.h file for each compilation run

printf 'static const char banner[] = \n' > banner.h

gitrev=''
relver='##version##'

printf '"KallistiOS ' >> banner.h
if [ -d "$KOS_BASE/.git" ]; then
    printf 'Git revision ' >> banner.h
    gitrev=`git describe --dirty --broken`
    printf "$gitrev" >> banner.h
    printf ':\\n\"\n' >> banner.h
else
    printf "$relver" >> banner.h
    printf ':\\n\"\n' >> banner.h
fi

printf '"  ' >> banner.h
tmp=`date`
printf "$tmp" >> banner.h
printf '\\n"\n' >> banner.h

printf '"  ' >> banner.h
tmp=`whoami`
printf "$tmp" >> banner.h
printf '@' >> banner.h

if [ `uname` = Linux ]; then
    tmp=`hostname -f`
else
    tmp=`hostname`
fi

printf "$tmp" >> banner.h

printf ':' >> banner.h
printf "$KOS_BASE" >> banner.h
printf '\\n"\n' >> banner.h

printf ';\n' >> banner.h

printf 'static const char kern_version[] = \n"' >> banner.h

if [ "$gitrev" == "" ]; then
    printf "$relver" >> banner.h
else
    printf "${gitrev#?}" >> banner.h
fi

printf '";\n' >> banner.h
Thanks for checking that out by the way :)
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5663
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: reading the content of /rd

Post by BlueCrab »

I guess you're using a slightly older version of git? Anyhow, I've just pushed a new revision to remove that, so just update KOS and try again.
User avatar
lerabot
Insane DCEmu
Insane DCEmu
Posts: 134
Joined: Sun Nov 01, 2015 8:25 pm
Has thanked: 2 times
Been thanked: 19 times

Re: reading the content of /rd

Post by lerabot »

I've just updated git and and commented that whole make_banner thing cause it still prevented the make completion.
I haven't tested those modification but it's good to know that re-compiling kos doesn't seem to break my project :)

I'll make a test project will a bunch of test case for the romdisk this weekend and put it on git.
We'll be able to test thing further.
User avatar
lerabot
Insane DCEmu
Insane DCEmu
Posts: 134
Joined: Sun Nov 01, 2015 8:25 pm
Has thanked: 2 times
Been thanked: 19 times

Re: reading the content of /rd

Post by lerabot »

Ok, so I did make a test
Here's a github link https://github.com/lerabot/romdisk_test

There's more info in the readme, but this basically confirm my theory.
Everything in the original romdisk is fine. Longer names, everything.
When you load a second romdisk, you get issues.

You can find my result in the result.txt file.

*Edit* Also, keep in mind that the second romdisk use gz compression.
Could the compression lib mess with the filename? I'll test this this afternoon.
User avatar
lerabot
Insane DCEmu
Insane DCEmu
Posts: 134
Joined: Sun Nov 01, 2015 8:25 pm
Has thanked: 2 times
Been thanked: 19 times

Re: reading the content of /rd

Post by lerabot »

FOUND THE ISSUE!

GZ compression is the culprit!!!!!
I'll update the git soon! I'm testing different .gzip compression to figure out if it's a compression issue.

Otherwise i'll drop the gz compression altogether.
Post Reply