A few questions regarding how to use some of the functions declared in the fxcg-10/20's version of "stdio.h":


Bfile_OpenFile_OS seems rather awkward for many reasons: first off, why does it need a pointer to a string of unsigned shorts? Is this for 2 byte character sets? It compiles fine with a pointer to a string of chars, (of course it throws a warning, but no error) but do I need to manually input byte sequences to access non-ASCII characters (that was worded bad, but basically, do I need to input different characters to represent the same ones if this parameter is not meant for ASCII characters)?

Secondly, files have to start with "\\fls0" -- though PrizmWiki doesn't tell how the rest of the file extension has to be represented. Is "\\fls0\city.pcc" as valid extension?

Thirdly, for Bfile_CreateEntry_OS, what type of modes are available (apparently I should use mode (int) 1, but are there other options?) and what do they do? Why in god's name do we need to pass the parameter for size as a pointer to the int that holds the size value? How do you specify where to save it?

For those interested, here's a snippet of code dealing with it (from my contest entry, but I snipped out everything not in question with a "...":


Code:

hmm.. bump.

Sorry for the slow response; had this open in a tab since yesterday.

You hit the nail on the head: tokenized special characters, which are one or two bytes.

Sounds to me like you should experiment and find out. Since you can load arbitrary files when using the calculator as a mass storage device, I tend to think it cares not about the filename and extension.

I'm not sure, I need to look at some documentation. It's either a text/binary flag, a truncate/append flag, or both.

I presume so that as you and/or the OS updates it, you both know where to look, up until you close the handle?

Interesting.. Thanks for the ideas Kerm. I'll do some more tests regarding the I/O functions today and post any results I find.

Excellent, I look forward to your results. I'll learn something too, especially with being unable to access the Prizm wiki.

I think I now realize what's wrong, after I saw GCC didn't know what escape sequence '\c' was...

Since the "\\fls0" isn't escaped, it's not represented right. It should be "\\\\fls0\" instead. Found the error

EDIT: nope, still non-working :/

Try something like L"\\\\fls0\" for the filename to pass a wide-character string to the function. This assumes that wchar_t is the same size as short, though. It might be 32 bits wide, which probably won't work for this function.

I thought there was a W prefix somewhere, is there not? I could have sworn I ran across that in the C99 spec when I was writing my own compiler.

SimonLoathar has suggested using Bfile_StrToName_ncpy() to change a normal string to a file compatible one. Will try, and edit in results.

Do you have any explanation of what that function actually does?

It seems, from what he said and the name, to take an string of characters and make them into a file-name compatible short* string.

EDIT: and by jove's name, *it works now* Thank you Kerm, Christop, Simon, et al.

In addition, so that others know *exactly* what to do in the future, here's some code to achieve opening files:


Code:


I found that you *must* close the file withBfile_CloseFile_OS( int HANDLE ) because if you don't, or if you open the same file twice, until the next mem clear (like a system error or a battery pull), the file cannot be deleted on-machine, and will return an error on subsequent opens and creates with the same name. Probably obvious, but documentation_for_the_masses++

That just means that the OS doesn't close the file properly, but if you already have it open and they leave your app I assume the OS would keep another app from editing it.

That's unfortunate that the OS doesn't deal with closing open files for you, but I bet it has something to do with the [MENU] sort of design, since programs only stop running when another program starts running. Ashbad, nice code, although I have some criticisms. Using magic numbers like 0x03 and 256 and 1000 in your code instead of named CONSTANT_POUND_DEFINES is frowned upon. Other than that, well done.

Here's how the cool kids use the Bfile_* functions using gnu++0x:


Code:


You must be using C++ and compiling with -std=gnu++0x

I'm not sure that'll always work, considering the Prizm uses some weird 2-byte character defines at times; I still suggest using Bfile_StrToName_ncpy for conversion.

The u means that it will use 16-bit shorts instead of 8 bit chars. Just like L"abc" gives you 32-bit wchar_ts.

Well, that's not the problem with it, it's just that I'm not sure all prizm 16-bit character defines match up with what GCC would be doing to convert them (i.e., the ASCII values may change because casio is dumb at times, and that syscall I threw out there also may format the string specially for use before use)

False. The cool kids use them like this:


Code:


Edit: I was going to complain that the \0 in there was unnecessary, but now I'm not so sure. I _think_ that the u prefix means GCC will append a two-byte \0 to the end on its own without the \0 inside, but I'm suddenly doubting myself.

I should have taken the \0 out, my fault. The u prefix was an addition to allow more control on UTF-xx strings, proposed and used since gcc 4.4 here. u makes the string UTF-16 of the type char16_t*