Register

Problems with file copying function

Discuss issues related to the Casio Prizm 3rd party development
Senior Member
Posts: 100
Joined: Sun Mar 24, 2013 12:01 pm
Calculators: None

Re: Problems with file copying function

Postby TeamFX » Tue Dec 03, 2013 4:38 pm

Inside LCDR61524A.dll is the text "LCD driver R61524 with touch for CASIO" plus some other touch references. So the touch controller seems to be an integral part of the R61524.

Btw, the fx-CP400 has 16 MB of RAM.
I have been a bit surprised that it is SDRAM and not SRAM (which should be available in 2013). At least they could have used Mobile SDRAM from ESMT which needs less electric current, but they didn't.

Senior Member
Posts: 141
Joined: Wed May 16, 2012 2:50 pm
Location: Portugal
Calculators: Casio fx-CG20

Re: Problems with file copying function

Postby gbl08ma » Tue Dec 03, 2013 5:05 pm

Ah, the version of Simon's docs I have states it has 2 MB of RAM. I always found that to be too low, especially because it has a huge screen, huge heap (Simon's docs say it has over 800 KB of heap), and assuming the memory layout doesn't differ too much from the Prizm and earlier calcs, it should have two even bigger contiguous areas: the "main" stack and the add-in stack.

Back to my file copying problem, I decided to dramatically increase the buffer from 4096 bytes to 51200 bytes.
It keeps working fine this way for smaller files, but on Amsterdam.g3p for example (which is smaller than the buffer size!) it failed somewhere inside the first (and only) copy cycle (target 003094CA, PC 01000000).
It fails somewhere inside ReadFile or WriteFile...
I don't think the problem is with ReadFile, because my add-in can read the problematic files just fine (f.i., to calculate its SHA-256 checksum). So the problem is with WriteFile. At the same time, this very same add-in writes files of bigger size, with no problems (on the calendar function and when copying non-problematic files).
If it were some flag we need to set, I think we would have discovered it by now (otherwise, how could writing other big files not fail?)
The only other thing I can remember of is that Bfile has some bug with writing some specific sequences of bytes, but then how would it not error too, f.i. when saving an eActivity that includes these very same files?

Senior Member
User avatar
Posts: 605
Joined: Sat Sep 15, 2012 6:59 am
Location: Krautland ****
Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750GII, Casio fx-9750GII (SH4), Casio fx-9860G, Casio fx-9860G SD, Casio fx-9860G Slim, Casio fx-9860GII SD, Casio fx-9860GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG20, Casio fx-CG50, Casio Classpad fx-CP400

Re: Problems with file copying function

Postby SimonLothar » Tue Dec 03, 2013 7:24 pm

gbl08ma wrote:Ah, the version of Simon's docs I have states it has 2 MB of RAM. I always found that to be too low, especially because it has a huge screen, huge heap (Simon's docs say it has over 800 KB of heap), and assuming the memory layout doesn't differ too much from the Prizm and earlier calcs, it should have two even bigger contiguous areas: the "main" stack and the add-in stack.
I clearly referred to the fx-CP330+ in my documentation. I'd rather not mix up fx-CP330+ and fx-CP400. As far as I am concerned, the fx-CP400 successfully refused to reveal most of its secrets up to now.
I'll be back!

Senior Member
Posts: 141
Joined: Wed May 16, 2012 2:50 pm
Location: Portugal
Calculators: Casio fx-CG20

Re: Problems with file copying function

Postby gbl08ma » Tue Dec 03, 2013 7:31 pm

SimonLothar wrote:I clearly referred to the fx-CP330+ in my documentation.

True, true. My bad.

EDIT - "progress" on solving the problem with file copy:
I decided to optimize the SMEM on the emulator. The error on Amsterdam.g3p and Amusement_park.g3p is gone, but then I tried to copy another g3p file from the same folder, only to get a system error with the same target and PC as on my last post.
It's really annoying that copying doesn't work even with the filesystem optimized. Well, at least now we know the problem only gets "moved around" as the fragmentation state changes.
At the same time, I wonder if Bfile or the lower-level Fugue FAT routines expose a syscall dedicated to copying files? If such a thing exists, using it would probably put an end to this whole issue, and it would have other benefits such as reducing the size of my add-in.

EDIT 2:
Another thing I've noticed, is that Casio add-ins can read files with long file names, but they never write a file with a long file name or lower case characters. eActivity can save files with long file names and mixed case, without changing the name, but eActivity is not an add-in.
On the calendar function, Utilities can write files with up to 50 KB, but these aren't files with long or mixed case file names - they have at most 8 numbers plus the dot and a 3 char extension.
The big file I can copy without issue doesn't have a long file name, either.
I can't see why LFN files would be written correctly up to a certain point, and then have WriteFile crash the system. It would be understandable if it was a problem with Bfile_OpenFile... but with WriteFile... strange. Furthermore, small files with long, mixed case file names copy fine (most of the time, and on this emulator...). At the same time, helder had a problem when copying a file that didn't have a LFN. I think I'll leave the LFN thing alone for now, but I may look into it later...

Senior Member
Posts: 369
Joined: Tue Jan 03, 2012 11:24 pm
Calculators: Casio Afx 1.0, Casio fx-9860GII SD, Casio Classpad 330, Casio fx-CG20, Casio Classpad fx-CP400

Re: Problems with file copying function

Postby helder7 » Fri Dec 06, 2013 1:27 am

As you suspect that the problem is with the Bfile_WriteFile_OS, I suggest you check if the function still returns the same error codes as fx9860G.

fx9860g sdk manuals wrote:If the function succeeds, this function returns the position indicated by the file pointer. It is greater than or equal to
0.
If the function fails, the return value is an error code. It is a negative value.


If it returns any error code, it may give more clues about the error and might allow to stop copy the file with a break, before reaching a system error. Maybe use a slightly smaller buffer also help.
SiO2 + CaCO3 ----------> CaSiO3 + CO2

Senior Member
Posts: 141
Joined: Wed May 16, 2012 2:50 pm
Location: Portugal
Calculators: Casio fx-CG20

Re: Problems with file copying function

Postby gbl08ma » Fri Dec 06, 2013 4:36 pm

Bfile_WriteFile returns the amount of bytes written on that call (not the file cursor position). This behavior is different from the one in the fx9860G, and I think I already read about it somewhere.
Bfile_WriteFile returns the amount of bytes written, as expected, even before the call that causes the system error. So there's no way to detect that the operation is going to fail.

Senior Member
Posts: 141
Joined: Wed May 16, 2012 2:50 pm
Location: Portugal
Calculators: Casio fx-CG20

Re: Problems with file copying function

Postby gbl08ma » Thu Dec 12, 2013 10:31 pm

Should I consider fixing this problem a lost cause?

Senior Member
User avatar
Posts: 605
Joined: Sat Sep 15, 2012 6:59 am
Location: Krautland ****
Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750GII, Casio fx-9750GII (SH4), Casio fx-9860G, Casio fx-9860G SD, Casio fx-9860G Slim, Casio fx-9860GII SD, Casio fx-9860GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG20, Casio fx-CG50, Casio Classpad fx-CP400

Re: Problems with file copying function

Postby SimonLothar » Fri Dec 13, 2013 8:06 pm

gbl08ma wrote:Should I consider fixing this problem a lost cause?
Not yet. But in this case it is difficult to keep track of the program on its course through the OS. Usually the UBC is used for that, but the internal SMEM procedures are called with interrupts switched off. That disables the UBC, too. As far as I am concerned, I'm still pondering to find a way into the bugs lair. But this may take some time...
I'll be back!

Senior Member
Posts: 141
Joined: Wed May 16, 2012 2:50 pm
Location: Portugal
Calculators: Casio fx-CG20

Re: Problems with file copying function

Postby gbl08ma » Fri Dec 13, 2013 9:59 pm

How does one use the User Break Controller (on "normal" situations without SMEM writes)?

Could you reproduce the problem, with a simpler test program? (or better, did you manage to reproduce the problem at all on non-g3a files, using Utilities?)

It makes sense that interrupts are disabled during SMEM operations. Remember that the simple matter of having a timer installed (even if stopped) will make Bfile calls unstable, crashing very often. One thing is probably related to the other.

Senior Member
User avatar
Posts: 605
Joined: Sat Sep 15, 2012 6:59 am
Location: Krautland ****
Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750GII, Casio fx-9750GII (SH4), Casio fx-9860G, Casio fx-9860G SD, Casio fx-9860G Slim, Casio fx-9860GII SD, Casio fx-9860GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG20, Casio fx-CG50, Casio Classpad fx-CP400

Re: Problems with file copying function

Postby SimonLothar » Sat Dec 14, 2013 7:53 am

gbl08ma wrote:How does one use the User Break Controller (on "normal" situations without SMEM writes)?
Prerequisite is, that you understand the UBC-chapter in the SH-hardware manual.
Then you need three components:
1. an UBC-interrupt-handler, which is some assembler-code, localized to some unused RAM-area (with fx-9860 I use some unused flash areas, too. I do not dare to use this variant with the Prizm). This handler has to "talk" to you in case the break condition occurs (f. i. immediately before or after a certain program counter). I use the serial interface as communication line (I do not see any alternative).
2. an add-in, which copies the above mentioned handler to its RAM-area and which allows to enter and set the program counter, where the UBC should grab control temporarily.
3. a receiver (f. i. a PC-program), which receives the handler's output via the serial interface and displays the information (f. i. register's content) properly, if the program counter has been reached.

gbl08ma wrote:Could you reproduce the problem, with a simpler test program? (or better, did you manage to reproduce the problem at all on non-g3a files, using Utilities?)
That is the thing, which must be achieved first.
BTW: The names of the preinstalled add-ins are hardcoded in the OS, to invoke special behaviours, which I do not know in detail, yet. Perhaps these add-ins are excluded from auto-optimization. While I am writing this, I wonder, if renaming an add-in accordingly would make a difference? Maybe worth a try.

gbl08ma wrote:It makes sense that interrupts are disabled during SMEM operations.
Of course. Never had any doubt. :D
I'll be back!

PreviousNext

Return to Casio Prizm SDK

Who is online

Users browsing this forum: No registered users and 9 guests