Homebrew Homebrew Development

[spinal_cord]

Yes, but if you use 1M for stack you havr less ram for you code, and I'm always in short of it in my game ports.

--------------------- MERGED ---------------------------


Try tracing the free memory. If the emulated floppy try to allocate 1.44M of space, probably you are consuming all the RAM left. Chech if malloc returns NULL too. Some program can omitt this assuming to run with system with a lot of phisical ram (and maybe vram)

C64 floppys are only 170k

--------------------- MERGED ---------------------------

The stack size is defined weak. So you can override it in your source and set it to a larger value - say 1MB.
u32 __stacksize__ = 1* 1024 * 1024;
https://github.com/smealum/ctrulib/blob/master/libctru/source/system/stack_adjust.s

Where abouts would I have to do this exactly?

 

[Coto]

Thanks, for now though, I'll just leave it out until I can get everything else working....

On that note, does anyone want to have a look at my latest frodo attempt? So far its up and running, but any attempt to reset the emulated console crashes. citra throws me into an unmapped read32 error loop.

http://socoder.net/uploads/124/BreadBox_21_08_17.zip

The issue appears to be caused by TheCPU->AsyncReset() -- called from void C64::Reset(void) in C64.cpp

For the record, it worked fine in whatever older version of devkitpro I had back in 2016. The TheCPU->AsyncReset() function has not changed at all.

just passing by to say:

are you allocating memory somewhere? what is the memory allocation mechanism used? if malloc, you need to free once unused. The sbrk takes linear memory as source. Otherwise it's returning return (void *) -1; (0xffffffff). Also, if you allocate memory marked as used by other process (MMU level) or simply empty the linear memory, and try to access, it will raise data aborts.

So basically, check where you are allocating memory, and on exit, make sure to identify the thread that allocated memory, so it is freed.

also for "unmapped read32", that's a hint for some emulator layer, that says you are trying to access an invalid access as 3DS hardware/emulator so it definitely won't work.

 

[spinal_cord]

on an unrelated note, how do I know if I'm running at full clock speed on n3ds? is there something I can set for that?

[edit]
I have tracked the cause of the issue to this...

                // set current disk
                Prefs *prefs = new Prefs(ThePrefs);
                strcpy(prefs->DrivePath[0], filelist[currentFile]);
                this->NewPrefs(prefs);
                ThePrefs = *prefs;
                delete prefs;

Can anyone see anything wrong with that? because to tell the truth, I'm not 100% sure what it's doing.

 

[elhobbs]

just passing by to say:

are you allocating memory somewhere? what is the memory allocation mechanism used? if malloc, you need to free once unused. The sbrk takes linear memory as source. Otherwise it's returning return (void *) -1; (0xffffffff). Also, if you allocate memory marked as used by other process (MMU level) or simply empty the linear memory, and try to access, it will raise data aborts.

So basically, check where you are allocating memory, and on exit, make sure to identify the thread that allocated memory, so it is freed.

also for "unmapped read32", that's a hint for some emulator layer, that says you are trying to access an invalid access as 3DS hardware/emulator so it definitely won't work.

As a note there is a region of memory on the 3ds that is referred to by the name "linear". This is different from main memory used by malloc - where linear can be used to describe the memory as sequential. On the 3ds the memory for malloc is referred too as "main".

 

[Coto]

As a note there is a region of memory on the 3ds that is referred to by the name "linear". This is different from main memory used by malloc - where linear can be used to describe the memory as sequential. On the 3ds the memory for malloc is referred too as "main".

But that will still mean Malloc using linear memory. (as of newlib ), that's a requisite. Thus, requiring to be freed to be properly re-allocated later. Otherwise you get an invalid pointer.

So if either "main" or "linear" memory is used in malloc implementation, those should be linear. If the other is non-linear then a custom allocator, non newlib standard, must be used. And by quickly looking at the ctrulib allocator it is already implemented.

 

[elhobbs]

But that will still mean Malloc using linear memory. (as of newlib ), that's a requisite. Thus, requiring to be freed to be properly re-allocated later. Otherwise you get an invalid pointer.

So if either "main" or "linear" memory is used in malloc implementation, those should be linear. If the other is non-linear then a custom allocator, non newlib standard, must be used. And by quickly looking at the ctrulib allocator it is already implemented.

I have no idea what point your are trying to make.

 

[Coto]

I have no idea what point your are trying to make.

basically this:

But that will still mean Malloc using linear memory. (as of newlib ), that's a requisite. Thus, requiring to be freed to be properly re-allocated later. Otherwise you get an invalid pointer.

The bold part means invalid pointer allocated. Now: If data abort == "main" memory, if no data abort but crashes, could very well be "linear" region address.
edit: invalid pointer from linear memory comes from not freed memory earlier.

But yeah, it was an idea.

 

[spinal_cord]

Is there a really basic example of a file selector around somewhere? There's obviously something very wrong with what I'm using.

 

[nop90]

Is there a really basic example of a file selector around somewhere? There's obviously something very wrong with what I'm using.

If a simple selecor made using the console is ok, look at the code Neopop SDL on my github and gram menu.c and menu.h. But remove the global variable used to check if the emulator is already started.
There are some option configurator menu. You can delete them or change the structure for your needs. It should be easy to adapt.

 

[spinal_cord]

Does anyone know if there are any current issues with accessing the sd card in the latest (or any) versions of devkitpro/libctru? I'm checking my path and filename before loading, but unless I reset citra (same with real hardware) I can't access files.
I'm checking the current path with

                    char cwd[64];
                    getcwd(cwd, sizeof(cwd));

and testing the file with

                FILE *file;
                if (file = fopen(ThePrefs.DrivePath[0], "r")){
                    // file OK
                    fclose(file);
                }else{
                    // file NOT OK
                }

When ever I try to change the file path I can't read the new file, even though the path and filename are 100% correct.
Any ideas?

 

[elhobbs]

Does anyone know if there are any current issues with accessing the sd card in the latest (or any) versions of devkitpro/libctru? I'm checking my path and filename before loading, but unless I reset citra (same with real hardware) I can't access files.
I'm checking the current path with

                    char cwd[64];
                    getcwd(cwd, sizeof(cwd));

and testing the file with

                FILE *file;
                if (file = fopen(ThePrefs.DrivePath[0], "r")){
                    // file OK
                    fclose(file);
                }else{
                    // file NOT OK
                }

When ever I try to change the file path I can't read the new file, even though the path and filename are 100% correct.
Any ideas?

The console window in citra should display information about the file you are trying to open and the reason it failed. You can use this to confirm it is trying to open the correct file.

--------------------- MERGED ---------------------------

The console window in citra should display information about the file you are trying to open and the reason it failed. You can use this to confirm it is trying to open the correct file.

The console window in citra should display information about the file you are trying to open and the reason it failed. You can use this to confirm it is trying to open the correct file.

what is this -
ThePrefs.DrivePath[0]? It looks like it is the first character of DrivePath. Or is DrivePath an array of file names?

 

[spinal_cord]

It's an array of filenames...
Drivepath [4][256]
Citra is just giving me unmapped read32 if I try to access a file that it thinks isn't there.

 

[elhobbs]

It's an array of filenames...
Drivepath [4][256]
Citra is just giving me unmapped read32 if I try to access a file that it thinks isn't there.

So the file is there but the app fails to open it? if you look above the read32 errors you will see the file name it tried to open. If the file does not exist or fopen returns null then trying to use the file pointer could lead to errors if you do not handle it properly.

 

[spinal_cord]

[   4.362703] Audio <Debug> audio_core\time_stretch.cpp:Process:58: Dropping frames!
[   4.765376] Service.FS <Debug> core\hle\service\fs\fs_user.cpp:OpenDirectory:389: type=4 size=4 data=[Wchar: /]
[   4.768898] Service.FS <Debug> core\hle\service\fs\fs_user.cpp:OpenDirectory:389: type=4 size=6 data=[Wchar: /.]
[   6.606436] Service.FS <Debug> core\hle\service\fs\fs_user.cpp:OpenFile:68: path=[Wchar: /mayhem.d64], mode=1 attrs=0
[   6.607042] Service.FS <Debug> core\file_sys\archive_sdmc.cpp:OpenFileBase:33: called path=[Wchar: /mayhem.d64] mode=1
[   6.608363] Service.FS <Critical> core\file_sys\archive_sdmc.cpp:OpenFileBase:79: (unreachable) Unknown error opening C:\devkitPro\citra_emulator/user/sdmc/mayhem.d64
[   6.609500] Service.FS <Error> core\hle\service\fs\fs_user.cpp:OpenFile:76: failed to get a handle for file [Wchar: /mayhem.d64]
[   6.610448] Service.FS <Debug> core\hle\service\fs\fs_user.cpp:OpenDirectory:389: type=4 size=24 data=[Wchar: /mayhem.d64]
[   6.611903] Service.FS <Error> core\file_sys\archive_sdmc.cpp:OpenDirectory:279: C:\devkitPro\citra_emulator/user/sdmc/mayhem.d64 not found
[   6.612954] Service.FS <Error> core\hle\service\fs\fs_user.cpp:OpenDirectory:397: failed to get a handle for directory type=4 size=24 data=[Wchar: /mayhem.d64]
[   6.614260] Service.FS <Debug> core\hle\service\fs\fs_user.cpp:OpenFile:68: path=[Wchar: /mayhem.d64], mode=1 attrs=0
[   6.614680] Service.FS <Debug> core\file_sys\archive_sdmc.cpp:OpenFileBase:33: called path=[Wchar: /mayhem.d64] mode=1
[   6.617241] Service.FS <Critical> core\file_sys\archive_sdmc.cpp:OpenFileBase:79: (unreachable) Unknown error opening C:\devkitPro\citra_emulator/user/sdmc/mayhem.d64
[   6.618078] Service.FS <Error> core\hle\service\fs\fs_user.cpp:OpenFile:76: failed to get a handle for file [Wchar: /mayhem.d64]
[   6.619065] HW.Memory <Error> core\memory.cpp:Read:184: unmapped Read32 @ 0x00000070
[   6.619426] HW.Memory <Error> core\memory.cpp:Read:184: unmapped Read16 @ 0x0000000C
[   6.620341] HW.Memory <Error> core\memory.cpp:Read:184: unmapped Read32 @ 0x00000060
[   6.621279] HW.Memory <Error> core\memory.cpp:Read:184: unmapped Read32 @ 0x0000005C
[   6.622198] HW.Memory <Error> core\memory.cpp:Write:224: unmapped Write32 0x00000000 @ 0x0000005C
[   6.622839] HW.Memory <Error> core\memory.cpp:Write:224: unmapped Write32 0x1FF82000 @ 0x00000060

I can't understand why I'm getting "C:\devkitPro\citra_emulator/user/sdmc/mayhem.d64 not found" when I'm browsing and selecting the file within my program. The file is 100% there because I'm able to find it and select it.

 

[elhobbs]

[   4.362703] Audio <Debug> audio_core\time_stretch.cpp:Process:58: Dropping frames!
[   4.765376] Service.FS <Debug> core\hle\service\fs\fs_user.cpp:OpenDirectory:389: type=4 size=4 data=[Wchar: /]
[   4.768898] Service.FS <Debug> core\hle\service\fs\fs_user.cpp:OpenDirectory:389: type=4 size=6 data=[Wchar: /.]
[   6.606436] Service.FS <Debug> core\hle\service\fs\fs_user.cpp:OpenFile:68: path=[Wchar: /mayhem.d64], mode=1 attrs=0
[   6.607042] Service.FS <Debug> core\file_sys\archive_sdmc.cpp:OpenFileBase:33: called path=[Wchar: /mayhem.d64] mode=1
[   6.608363] Service.FS <Critical> core\file_sys\archive_sdmc.cpp:OpenFileBase:79: (unreachable) Unknown error opening C:\devkitPro\citra_emulator/user/sdmc/mayhem.d64
[   6.609500] Service.FS <Error> core\hle\service\fs\fs_user.cpp:OpenFile:76: failed to get a handle for file [Wchar: /mayhem.d64]
[   6.610448] Service.FS <Debug> core\hle\service\fs\fs_user.cpp:OpenDirectory:389: type=4 size=24 data=[Wchar: /mayhem.d64]
[   6.611903] Service.FS <Error> core\file_sys\archive_sdmc.cpp:OpenDirectory:279: C:\devkitPro\citra_emulator/user/sdmc/mayhem.d64 not found
[   6.612954] Service.FS <Error> core\hle\service\fs\fs_user.cpp:OpenDirectory:397: failed to get a handle for directory type=4 size=24 data=[Wchar: /mayhem.d64]
[   6.614260] Service.FS <Debug> core\hle\service\fs\fs_user.cpp:OpenFile:68: path=[Wchar: /mayhem.d64], mode=1 attrs=0
[   6.614680] Service.FS <Debug> core\file_sys\archive_sdmc.cpp:OpenFileBase:33: called path=[Wchar: /mayhem.d64] mode=1
[   6.617241] Service.FS <Critical> core\file_sys\archive_sdmc.cpp:OpenFileBase:79: (unreachable) Unknown error opening C:\devkitPro\citra_emulator/user/sdmc/mayhem.d64
[   6.618078] Service.FS <Error> core\hle\service\fs\fs_user.cpp:OpenFile:76: failed to get a handle for file [Wchar: /mayhem.d64]
[   6.619065] HW.Memory <Error> core\memory.cpp:Read:184: unmapped Read32 @ 0x00000070
[   6.619426] HW.Memory <Error> core\memory.cpp:Read:184: unmapped Read16 @ 0x0000000C
[   6.620341] HW.Memory <Error> core\memory.cpp:Read:184: unmapped Read32 @ 0x00000060
[   6.621279] HW.Memory <Error> core\memory.cpp:Read:184: unmapped Read32 @ 0x0000005C
[   6.622198] HW.Memory <Error> core\memory.cpp:Write:224: unmapped Write32 0x00000000 @ 0x0000005C
[   6.622839] HW.Memory <Error> core\memory.cpp:Write:224: unmapped Write32 0x1FF82000 @ 0x00000060

I can't understand why I'm getting "C:\devkitPro\citra_emulator/user/sdmc/mayhem.d64 not found" when I'm browsing and selecting the file within my program. The file is 100% there because I'm able to find it and select it.

Is the file open by another process or marked as read-only? Try to open the file with notepad and see if you get an error?

 

[spinal_cord]

Is the file open by another process or marked as read-only? Try to open the file with notepad and see if you get an error?

That sounds reasonable. I'll give that a check when I get a chance.

 

[elhobbs]

That sounds reasonable. I'll give that a check when I get a chance.

If you are really stuck then you can try this - https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
Then you can see the operating system error code when it tries to open the file.

 

[spinal_cord]

If you are really stuck then you can try this - https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
Then you can see the operating system error code when it tries to open the file.

Weirdly it may have fixed itself, I din't do anything, but it seems to work...

 

[elhobbs]

Weirdly it may have fixed itself, I din't do anything, but it seems to work...

Most likely the file was locked by another process.

 

[spinal_cord]

It was doing it with most files both in citra and on hardware. I did disable double buffering, maybe it was a memory issue...