14 replies to this topic

[Rigel]

Hi,

Little progress on file system surgery with Pascal

I wanna know why the AFX->PC transfer speed is much higher than PC->AFX with FA123.. I have WinNT4.0; port 1 baud is 9600 b/sec. I checked the previous posts but did not come across this subject. Thanx in advance.

[X-thunder28]

may be the speed of write-to-ram in AFX, no?

[Brazzucko]

I have "see" the same thing in my Windows XP Home and Professional.....

[BiTwhise]

The speed of writing to RAM shouldn't be a limiting factor in itself. However, the way casio organizes memory (Zones are sorted by name and type) might slow down the downloading process

[Casto Productions]

But shouldn't that slow down the upload as well? If the organization of the memory is the problem then I would think the transmitting of the data would be just as slow as the calc (and limited processor) would have to locate the data to send as it's being transmitted.

I know for a while people were working on faster ways to upload to the flash memory, and I think there was some success there. Any chance of using the same methods for BASIC files?

[BiTwhise]

Sending files from memory wouldn't be a problem, since it simply implies reading data from RAM and transmitting it

When recieving (or creating, or editing zones) RAM has to be reorganized to fit the new data. Say you're editing a basic file. when you add text to the file, the data after it in memory has to be pushed down to make room, this include both the later data in the current basic file and the data in any other zone.

If the recieving works by actively resizing the zone as more data comes in (rather than fixing the size to fit the data expected) this process could be rather slow

[Rigel]

Bitwise sounds right.

This topic took me back to mid '80s, the years of 286 PC's. Hard drives were then too slow with Basic-Pascal programs, so we usually had to revert to inline assembly and use Int21H dos function calls. When inserting a certain amount of bytes in the middle of a file you needed a temporary file as a buffer to hold the rest of the main file, insert data, and backup from the buffer file to build up the edited file. Too many clock cycles for the poor 286's..

If the AFX uses a similar approach while rearranging existing files/zones, the 286 will be much slower than the PIII that is transmitting, but the reverse will not be true for a PIII while receiving.

[Brazzucko]

When I transfer one big CAT file whit the FA-123 to my FX 1.0, they took 42 seconds to complete , but whit my other Casio calc ( CFX 9850GB Plus ), the same file is "installed? in only 10!!!!! seconds?.

Why this huge difference?

[huhn_m]

This is probably cause because the FX / AFX sorts files by name and therefor has to move
a lot of data if the program name begings e.g. with an A while on the
CFX the data seems not to be sorted at all and the program is only appended after the last one.

[Brazzucko]

But only this justify this huge ?speed? difference, or there is something more?

[BiTwhise]

It indeed justifies the speed difference

On the CFX data would be appended at the end of used memory (/start of free memory)
While on the AFX data would be inserted at it's appropriate place in memory, thus all data after it will be moved down in memory. If allocation is done per packet recieved, and not per program/zone then it will certainly be slow..

[Brazzucko]

So this explain everything thanks guys??

[CrimsonCasio]

sheesh, why dont they just sort the names? that makes more sense to me.

[2072]

There is also something else, if you look at FA123 files they are not in binary but in text, each byte is stored as 2 bytes in hexa, I don't know how works the transfer protocal but maybe fa123 send 2 bytes for each byte...

btw: dada66 almost finished Flas100 and Gcomm, you already can donload beta versions that work perfectly, now it only takes 17 secondes to upload a whole drive to the AFX!

You also can send drive between 2 AFX.

Gcomm also support memory transfer (basic files, lists, etc...).

[BradN]

I believe the speed difference is only because Casio doesn't optimize their communication - at all... and sending to the calc just happened to be programmed worse than the other way.

It's probably the case that just bad design is responsible for transfers taking so long with FA-123 - if it uses a simple "allocate the space, then fill it in" strategy, it should be able to send at the full communication speed. If BiTwhise's idea on allocating as each packet arrives is correct, then that would probably explain the difference. Why Casio did it this way... who knows.