Android application to manipulate sd image from the site

I’m not sure its a good idea mainly on speed grounds but it should work.

Writing to zip file across the network (ShareFS, LanMan98 etc) does work but isn’t totally reliable we’ve found.

aaaa

The build system expects to be able to write to whatever location the build tree is in. Modifying it to allow it to write elsewhere would be a lot of work.

Why can’t you just extract the source code to somewhere else and build it from there? You’ll need a bunch of extra support files anyway (boot sequence, C compiler, etc.)

aaaa

aaaa

Unfortunately it does have to modify files – the C compiler outputs dependency information for each source file, which then gets appended to the end of the makefile. But if you’re going to support adding new files then you might as well just make it a generic overlay filesystem which can support replacing files as well.

Gratuitously worked example as it is raining and I’m bored… Enjoy! ¹

RISC OS zip extra field data:

typedef struct {
  short         ID;          // 0x4341     "AC"
  short         size;
  int           ID_2;        // 0x30435241 "ARC0"
  unsigned int  loadaddr;
  unsigned int  execaddr;
  int           attr;
  int           zero;
} extra_block;

Live test from a small zip on my website randomly selected → http://www.heyrick.co.uk/random/miditest.zip

50 4B 03 04 14 00 02 00 08 00 22 BB 59 42 38 61  PK..........YBSa
64 4C 92 11 00 00 47 26 00 00 08 00 18 00 6D 69  dL....G&......mi
64 69 74 65 73 74 41 43 14 00 41 52 43 30 53 FB  ditestAC..ARC0S.
FF FF C2 43 C4 23 03 00 00 00 00 00 00 00 8D 5A  ...C.#.........Z
0D 6C 5C D5 95 F6 CF D8 33 1E CF 35 D4 09 10 42   |\.....3..5...B

Beginning after the filename: AC, size &14 (20) bytes. First word is “ARC0”. Second word, load address, is stored backwards² – &53FBFFFF becomes &FFFFFB53. Third word, exec address, likewise – &23C443C2. The attribute word is &00000003. And the final word called “zero” is exactly that.

Breaking it down:

  Load  = &FFFFFB53
  Exec  = &23C443C2
  Attr  = 3

Which means the filetype is &FFB (BASIC) and the datestamp is &23C443C2 with the extra &53 added to be the fifth byte of the time. The attribute is 3 which is RW/.

Therefore:

>DIM t% 5, s% 256
>!t% = &23C443C2
>t%?4= &53
>SYS &C0,t%,s%,255 TO ,n%
>n%?0 = 13
>PRINT $s%
23:25:05 25-Feb-2013
>

The SWI called is OS_ConvertStandardDateAndTime (or something like that).

There’s another file in that archive, beginning at offset +11F6. Over to you… :-)

¹ Unpleasant and annoying Americanism added to please John. ;-)

² I’m using Hextreme on the PC to view this, but checking later, it looks the same in Zap.

aaaa

GCCSDK builds a copy of zip which supports filetypes (via the standard ,xxx suffix)

…which isn’t the “standard” way of embedding filetypes in zip files, note. That’s the way to preserve filetype information across systems that don’t support such things (Samba, I think; HostFS; etc).

My fear is that if I opened such a zip file (if one existed) to upgrade my sources, then SparkFS may deal with the comma suffixes rather literally…

Second word, load address, is stored backwards – &53FBFFFF becomes &FFFFFB53.

That’s normal. We’re using little-endian CPUs, remember. &53 is the lowest byte of the word, the struct is written out in one block using fwrite(), and so &53 will come first in the file.

GCCSDK builds a copy of zip which supports filetypes (via the standard ,xxx suffix)

…which isn’t the “standard” way of embedding filetypes in zip files, note. That’s the way to preserve filetype information across systems that don’t support such things (Samba, I think; HostFS; etc).

This is a version of Zip which runs on a Unix-like host. So when you use it to create a zip, if any of the files has a ,xxx suffix, it strips it off of the filename and outputs an ‘AC’ extra data block in the zip.

aaa

aaaa

An advantage of using filecore compressed image is that it would probably be easier for sharefs to manipulate it than a zip file.

I am confused. How should ShareFS interpret any image whatever format it would have?

aaa

aaaa

Squash is not a filing system… but it would be cool to have a squashfs :)

aaaa

If i understand well, TBAFS is doing this no ? it can use some kind of image filing system that use squash compression ?

Yes. DOSFS does this too, without compression.

Compression is really not a good idea if you want to write files. The best would be to have 1/ an image filesystem, with no compression 2/ a tool that make the compression.

For example, DOSFS or TBAFS as an archiver, and a yet to be written SquashFS for realtime compression/decompression of files, and so, also of image files. The same way ImageFS worked, even if I don’t know how to code that :)
For other OSes, a tool to manually decompress/compress/crypt/decrypt files could be provided.

This technique could be used to simulate the NTFS compression behaviour, or to go even further with encryption functionalities.
Almost everything can be done with file systems under RISC OS. Just need more examples and documentation.

It would be very funny to be able to say “squash this directory or file”, “crypt these resources”, “autoconvert my images” and then use all your squashed, crypted and converted files as usual.

Foe example, LinkFS uses an image filing system to provide symbolic links.
https://compton.nu/riscos/linkfs/

RaFS is provided with source, but needs to be adapted to 32bit world.
http://atterer.org/riscos

aaaaa

aaaa

aaaa

aaaa

Why are you looking in newsgroups when the sources are right in front of you? ;-)
https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/Programmer/Squash/

The docs within Squash say:

The algorithm used by this module is 12-bit LZW, as used by the Unix
'compress' command (with -b 12 specified). If future versions of the module
use different algorithms, they will still be able to decompress existing
compressed data.

But compress doesn’t use lzw 20 bits as far as i know it’s supposed to use variable length from 9 to 12 bits.

Next message down, he corrects that to say 12 bits.

aaaa