Register

Some hints concerning the G1S-type

Learn how to program. Code snippets for creating sprites etc. Submit your own or use those of others.
Senior Member
Posts: 100
Joined: Sun Mar 24, 2013 12:01 pm
Calculators: None

Re: Some hints concerning the G1S-type

Postby TeamFX » Tue Jan 03, 2017 10:50 pm

SimonLothar wrote:The limitation to 800 KiB has been a software (OS) thing. If fxRemote would have existed in these days...

Similar to what is the case for fx-CG20 AU: 16 of 32 MB cannot be used...
Installing a slightly modified fx-CG20 OS should fix this.

Senior Member
User avatar
Posts: 101
Joined: Sun Mar 27, 2016 10:24 am
Location: France
Calculators: Casio Afx 1.0, Casio fx-9860GII, Casio fx-CG50

Re: Some hints concerning the G1S-type

Postby cakeisalie5 » Sat Jan 28, 2017 3:16 am

So I went back on this and wanted to understand more details of this, in order to parse it in the way it was thought (if possible). So I have a few questions about the possibilities, mainly on-calc:

- if I understood well, different types have different indexes (like, there is an enumeration for sectors, one for directories and one for files). Does that mean the dirref/dirnum should in fact be understood as the parent node, where the high two bytes are for the type (numeration to use and the number in the numeration)? have you tried like setting a file as a parent to another file? :p

- in the G1SWalk, you describe the order of the elements (directory followed by elements it contains, file followed by its fragments), but how is that managed by the OS/FA-124? I mean, if there already are some elements after it, will it push them to have the space, or will it put it far away?

- in a more general manner, if the order is not imposed (last question), how are file fragments located? is the hole SMEM scanned?

- you told in your example that there always are 0x800 entries. Where does that limit come from?

- have you got an idea about why the file type is in the fragment subheader, not in the file subheader?

Thanks in advance! :)

PS: Btw, here is my current understanding of the SMEM/G1S.
Part of the Planète Casio community (FR) - main author of Cahute

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: Some hints concerning the G1S-type

Postby SimonLothar » Sat Jan 28, 2017 4:42 pm

cakeisalie5 wrote:PS: Btw, here is my current understanding of the SMEM/G1S.
"The list has 0x800 entries, and occupies the two first sectors (or maybe
* just one, but it looks like data storage starts at sector 3). Entries with
* a type being 0xFFFF should not be read".
As long as the first sector is not exhausted, sector 2 is used for data (just checked with OS 1.03 and OS 2.09 on-calc). Try to replace a large file repeatedly. Possibly sector 2 is used as directory sector, if sector 1 is exhausted.
I'll be back!

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: Some hints concerning the G1S-type

Postby SimonLothar » Sat Jan 28, 2017 6:21 pm

cakeisalie5 wrote:- if I understood well, different types have different indexes (like, there is an enumeration for sectors, one for directories and one for files). Does that mean the dirref/dirnum should in fact be understood as the parent node, where the high two bytes are for the type (numeration to use and the number in the numeration)? have you tried like setting a file as a parent to another file?
You can call the directory the parent node as well. But no, I did not try to flash-write into the SMEM (f. i. setting a file as a file's parent node).
cakeisalie5 wrote:- in the G1SWalk, you describe the order of the elements (directory followed by elements it contains, file followed by its fragments), but how is that managed by the OS/FA-124? I mean, if there already are some elements after it, will it push them to have the space, or will it put it far away?
Once created, a file position is fixed. You cannot change the filesize afterwards. A freshly created file is initialized with 0xFF. A file can be written, if there are no 0->1 bit transitions involved. If you want to increase the size of an already created file, you have to delete it and create it again. All old directory entries are marked as deleted. All new directory entries are consecutively appended at the end, until an optimization is necessary.
cakeisalie5 wrote:- in a more general manner, if the order is not imposed (last question), how are file fragments located? is the hole SMEM scanned?
The fragments are located by HI_logicalsectornumber, LO_physicalsector and BlockSize
cakeisalie5 wrote:- you told in your example that there always are 0x800 entries. Where does that limit come from?
This is 0x10000 DIV 32. One 64 KiB sector divided by the entry size 32.
cakeisalie5 wrote:- have you got an idea about why the file type is in the fragment subheader, not in the file subheader?
Yes. The file subheader has no space left for that. Possibly the programmers decided to have directory entries of the same size. Otherwise the max. count of directory entries would be variable, causing programming expense.
I'll be back!

Senior Member
User avatar
Posts: 101
Joined: Sun Mar 27, 2016 10:24 am
Location: France
Calculators: Casio Afx 1.0, Casio fx-9860GII, Casio fx-CG50

Re: Some hints concerning the G1S-type

Postby cakeisalie5 » Sat Jan 28, 2017 8:01 pm

SimonLothar wrote:
cakeisalie5 wrote:- in a more general manner, if the order is not imposed (last question), how are file fragments located? is the hole SMEM scanned?

The fragments are located by HI_logicalsectornumber, LO_physicalsector and BlockSize

My question was badly formulated, that was not what I meant - but by telling that a file could not be rewritten, I can guess that the fragments are always right after a file, and that they cannot be modified (yup, sounds like fragments are reaaaally useful). I don't understand why they've made this sector thingy, really, that system would have been equally optimized without...

SimonLothar wrote:As long as the first sector is not exhausted, sector 2 is used for data (just checked with OS 1.03 and OS 2.09 on-calc). Try to replace a large file repeatedly. Possibly sector 2 is used as directory sector, if sector 1 is exhausted.

SimonLothar wrote:
cakeisalie5 wrote:- you told in your example that there always are 0x800 entries. Where does that limit come from?

This is 0x10000 DIV 32. One 64 KiB sector divided by the entry size 32.

Somehow I've made bad calculations, and couldn't find 0x800 again. So I suppose I can guess the number of sectors the index occupy by looking at the logical number of the first sectors, if they're gibberish or not (> 0x20 && < 0xFFFFFFFF should be enough).

SimonLothar wrote:
cakeisalie5 wrote:- have you got an idea about why the file type is in the fragment subheader, not in the file subheader?

Yes. The file subheader has no space left for that. Possibly the programmers decided to have directory entries of the same size. Otherwise the max. count of directory entries would be variable, causing programming expense.

I see. Sounds not very smart from CASIO, as they just could've managed the files and directories differently, which even is probably the case, but seems possible. >_>

Thanks! :)
Part of the Planète Casio community (FR) - main author of Cahute

Previous

Return to Tutorials & Code Snippets

Who is online

Users browsing this forum: No registered users and 21 guests