Android application to manipulate sd image from the site

aaaa

aaaa

The Makefiles are different, and though the norcroft has a filetype for a Makefile

ROOL in their latest DDE release deprecate the use of !Make. For a long time I have used amu directly, and the makefile is a simple text file (filetype text) which I produce manually. I actually have a skeleton default makefile which I modify as necessary for different projects. The makefile can be made compatible with both AMU and the GCC Make utility, although the reverse is not necessarily true – you can do a lot more in GCC Make.

aaaa

aaaa

aaaa

aaaa

aaaaa

Compressing to sqar and it looks OK, but decompressing the sqar and I get
‘directory sequence doesn’t match 112 207’
Sometimes 0 and a number.

why -lz?

I compiled and run on linux machine. A couple of warnings

strings.c: In function ‘copy_adfs_to_string’:
strings.c:151:4: warning: case label value exceeds maximum value for type [enabled by default]
strings.c: In function ‘compare_adfs_with_string’:
strings.c:175:4: warning: case label value exceeds maximum value for type [enabled by default]

aaaa

aaaa

I see, On one occasion I got an output for the top directory that looked the right number of characters but wrong values.
I was expecting ‘$.!Pluto’ but got
$
directory sequence doesn’t match 0 51
$.3¯üÿP_*
Does almost look like a character conversion problem, but I’ll leave it up to you.

ADFS doesn’t mandate an encoding scheme, so the OS will interpret the filename strings using whatever alphabet is set for the system. Most of the time that’s going to be Latin1, in which 0xA0 is defined as a non-breaking space. You will need to assume 8 bit “characters”, not 7 bit, definitely. If you want to convert to UTF-8, it’s a simple conversion from Latin1 to UTF-8.

aaaa

aaaa

aaaa

If that say what i think it says, it means there should be virtually no difference between making an swi call, and a C calls,

The C library sets up a big jump table in order to avoid the overheads in taking a SWI call. Don’t pay to much attention to the quoted time given, that was probably correct for an ARM2 ;-) Just know that it is the difference between a SWI exception (a lot of code) and a BL (to jump table) followed by a B (into CLib).

I have compiled both stdc and ro versions with

SHELL = /bin/sh
TARGET = squach
CC = gcc
CFLAGS = -static
LIBS =
CMN_OBJS = adfs_time.o blocks.o strings.o squach.o tar.o lzw.o sqar.o
RO_OBJS = filesystem_ro.o sqar_ro.o
STDC_OBJS = filesystem_stdc.o sqar_stdc.o
$(TARGET):	$(CMN_OBJS) $(RO_OBJS) $(STDC_OBJS)
	$(CC) $(CFLAGS) $(CMN_OBJS) $(RO_OBJS) -o $(TARGET)_ro
	$(CC) $(CFLAGS) $(CMN_OBJS) $(STDC_OBJS) -o $(TARGET)_stdc
clean:
	rm -f $(CMN_OBJS) $(RO_OBJS) $(STDC_OBJS) $(TARGET)_ro $(TARGET)_stdc

In your gcc makefile

$(RENAME) h/filesystem.h h/filesystem

aaaaa

aaaaa

But well yes in the absolute, the goal is to have a single source tree for visual studio and gcc/linux and riscos.

I think it would be better to leave the makefile alone and make a script for each platform to convert norcroft to plain.A RISC OS obey file with

Repeat 'Rename %0 %0.c' c
Repeat 'Rename %0 %0.h' h

Which directory/archive did you use for time difference testing?

aaaa

I use the riscos source tree archive from this site for testing :)

OK compressing the BCM2835Dev on Iyonix
STDC
tar compresssed 8412 files in 54272696 bytes, 562 secs
2073 directories starting at 54273024
added 1181184 bytes of directory entry in 2307 blocks, tar done .
RO
tar compresssed 8412 files in 57346744 bytes, 195 secs
2073 directories starting at 57347072
added 1181184 bytes of directory entry, tar done .

Edit: with the -O2 switch no improvement for STDC, but RO now compresses in 168 secs.

aaaa

So linking module code statically inside of the app and making regular C call would still make a difference over calling the code from another module via an swi ?

Using CLib (as a module) sets up the jump table. It doesn’t issue SWIs for each call.
So you’re going to be calling functions via two branches.

The alternative is calling SWIs. Let’s see… The processor takes the SWI vector. The OS needs to load the instruction (as data, polluting data cache) to read the SWI number. The OS then needs to go through all the logic of working out what module to actually call. Then the module will interpret the SWI number via its own jump table. Then the function you wanted can be executed. Phew!