Hi!

I know this has been discussed in the past. I can not find the threads anymore.

I notice the Sio2USB is reading (and writing) slower on higher sectors on large partitions. Especially 16MB partitions.

I know there is a workaround to format with a HIGH clustersize, but still... this is not a complete fix.

I know this problem did exist on Sio2SD too, and it was rather easy to change this through firmware. I am not 100% sure, but I remember that author of firmware emailed me something about increasing buffer-size in the firmware.

Is this an option in sio2usb too?

When someone is interested... I still have a read-test tool I wrote for sio2SD to prove that the higher sectors are accessed slower.

When I start this here locally on my Sio2USB the loading is slower from $8000 and up... and REALLY slower from sector $C000 and up.

Since this does not occur on Sio2SD and not on Sio2IDE I assume this could be 'fixed' in Sio2USB firmware too?

Thanks
Marius

I rewrote my readtest...

I use a 1GB USB stick. FAT formatted. ClusterSize 64KB.
It is NOT Fat32 formatted, since FAT32 does not allow me to format on higher sectorsize.

The speed is slower around sector $8000 or $9000 ... this depends (I guess) on where the clusterboundary is located on the particular 16MB partition.

The tool checks sector: $0004 - $00FF, $8000-$80FF, $9000-$90FF, $C000-$C0FF and $F000-$F0FF

Please test this on a HIGH SPEED SIO enabled OS, like Qmeg.

You'll notice that there are only 'two' speed variations. This is on 64KB clusersized format. When you use smaller clustersize, there will be even more (and slower!) speed variations.

I hope someone will take a look at that idea of increasing the BUFFER in the firmware. If that was the solution for Sio2SD, it might be the solution for Sio2USB too!

Thanks
Marius

p.s. when the sio is slowing down, the display of my sio2usb has hard time too. Every sector creates a small flickering in the screen.

From my technical knowledge this is a "feature" of the FAT filesystem, and the cluster linkage there.

PC operating systems solve this issue by using a big cache. However SIO2USB has very little RAM, there is no space to keep the FAT (File Allocation Table) in memory all the time. It needs to re-read often, that slows the access down.

I don't see a technical solution for this issue with the current hardware.

-- Carsten

@cas

I understand 100% what you write. I only get 'confused' by the fact that Sio2SD had 100% the SAME issue in the past, and Sio2SD got fixed rather easily.
I wrote this 16MB readtest for Sio2SD, for testing purpouse for the development of a bug-fixed Firmware. Now I rewrote it for Sio2USB.

The person who updated that Firmware of Sio2SD wrote me that it was a rather 'simple' fix. It had something to do with some kind of buffer setting in the Firmware. That was all.

I can't believe Sio2SD-hardware is better than Sio2USB. In fact I think Sio2USB has more 'on board' compared to Sio2SD.

So I really hope the development-team of Sio2USB will think it over, and perhaps they might contact the author of Sio2SD firmware to ask how he fixed it.

I'm rather sure it can be fixed. And I think it will be a good idea too!

By the way: even Sio2IDE 3.3a (compared to Sio2USB a very small system!) does not have this problem, and reads all sectors at the same speed.

So when both Sio2IDE and Sio2SD don't suffer from this problem. Why does Sio2USB? All those interfaces do (almost) the same, with little hardware...

Greetz!
Marius

Hi Marius,

I have not done the hardware development, for that you need to ask Thomas or Harry.

However I know that SIO2SD is using ATMEL, while SIO2USB is using PIC Microchip, which are quite different to program in terms of bankswitching and how the memory can be used.

The SIO2USB design and chip used is a few years older (the development took a long time) than that of the SIO2SD.

My understanding is that there is no free single byte in the firmware RAM. All is used for sector buffer and some variables. But again only Harry or Thomas can give you an authoritative answer, as the sourcecode is not open.

-- Carsten