Problems with file copying function
39 posts
• Page 3 of 4 • 1, 2, 3, 4
Re: Problems with file copying function
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.
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.
- gbl08ma
- Senior Member
- Posts: 141
- Joined: Wed May 16, 2012 2:50 pm
- Location: Portugal
- Calculators: Casio fx-CG20
Re: Problems with file copying function
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?
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?
- SimonLothar
- Senior Member
-
- 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
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.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'll be back!
- gbl08ma
- Senior Member
- Posts: 141
- Joined: Wed May 16, 2012 2:50 pm
- Location: Portugal
- Calculators: Casio fx-CG20
Re: Problems with file copying function
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...
- helder7
- 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
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.
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.
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
- gbl08ma
- Senior Member
- Posts: 141
- Joined: Wed May 16, 2012 2:50 pm
- Location: Portugal
- Calculators: Casio fx-CG20
Re: Problems with file copying function
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.
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.
- gbl08ma
- Senior Member
- Posts: 141
- Joined: Wed May 16, 2012 2:50 pm
- Location: Portugal
- Calculators: Casio fx-CG20
Re: Problems with file copying function
Should I consider fixing this problem a lost cause?
- SimonLothar
- Senior Member
-
- 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
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...gbl08ma wrote:Should I consider fixing this problem a lost cause?
I'll be back!
- gbl08ma
- Senior Member
- Posts: 141
- Joined: Wed May 16, 2012 2:50 pm
- Location: Portugal
- Calculators: Casio fx-CG20
Re: Problems with file copying function
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.
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.
- SimonLothar
- Senior Member
-
- 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
Prerequisite is, that you understand the UBC-chapter in the SH-hardware manual.gbl08ma wrote:How does one use the User Break Controller (on "normal" situations without SMEM writes)?
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.
That is the thing, which must be achieved first.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?)
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.
Of course. Never had any doubt.gbl08ma wrote:It makes sense that interrupts are disabled during SMEM operations.

I'll be back!
39 posts
• Page 3 of 4 • 1, 2, 3, 4
Who is online
Users browsing this forum: No registered users and 24 guests