From Newsgroup: comp.sys.acorn.programmer

I could use some advice on obtaining and using temporary extra memory
from within a program. I do recall that at one time there was a way
to claim some temp memory but I also recall that the method changed
for some reason. I can't remember how/why to be honest.

I need probably no more than 2M byte, a few 100k more the normal.
I'm using OS5.31 but only have a set of RO3 PRMs.

Essentially, I need to move a few blocks of data up or down within
the file. Read blocks of bytes using OS_GBPB 3 and write them back
either higher or lower with OS_GBPB 1. The size of the ram buffer
determines if I have to do this in chunks or all in one go.

Thanks for any advice.


Background.
I'm writing a FLAC (music file) tag editor for doing mass changes
across a large library. Flac files have several blocks of data before
the music in the file. Two of those blocks are the tagging area and
the padding area. The padding area is there to give spare bytes
within a fixed size file that you can use if you need them for
tagging changes but you need to move the data between them to do that.

Cheers,

Bob.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5ce8bbe2c2bob@sick-of-spam.invalid>,
Bob Latham <bob@sick-of-spam.invalid> wrote:

I could use some advice on obtaining and using temporary extra
memory from within a program. I do recall that at one time there
was a way to claim some temp memory but I also recall that the
method changed for some reason. I can't remember how/why to be
honest.

I need probably no more than 2M byte, a few 100k more the normal.
I'm using OS5.31 but only have a set of RO3 PRMs.

Essentially, I need to move a few blocks of data up or down within
the file. Read blocks of bytes using OS_GBPB 3 and write them back
either higher or lower with OS_GBPB 1. The size of the ram buffer
determines if I have to do this in chunks or all in one go.

Thanks for any advice.

Background. I'm writing a FLAC (music file) tag editor for doing
mass changes across a large library. Flac files have several blocks
of data before the music in the file. Two of those blocks are the
tagging area and the padding area. The padding area is there to
give spare bytes within a fixed size file that you can use if you
need them for tagging changes but you need to move the data between
them to do that.

What language are you using?

You could...

- allocate a large enough slotsize when your app starts.
- change slotsize dynamically using SWI Wimp_SlotSize.
- set up a Dynamic Area and use that.
- claim some RMA, but probably not a good idea these days.
- and no doubt other solutions are available!
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5ce8c3e7b9News04@avisoft.f9.co.uk>,
Martin <News04@avisoft.f9.co.uk> wrote:

What language are you using?

Basic assembler, I somehow feel I should apologise for that.

You could...

I'm looking for memory that I can "claim?" (2MB-ish) and release
again with ease and has easy direct addressable space.


My feelings about these options are based on poor knowledge I'll
admit but

- allocate a large enough slotsize when your app starts.

This particular job is one of many my application performs. It will
not be used often and so a big claim at the start does not seem ideal
to me.

- change slotsize dynamically using SWI Wimp_SlotSize.

I *think* that limit has got much higher with OS5 and it may do the
job but I'm sure I've played with extending a app space in the past
and I didn't enjoy the experience. :-)

- set up a Dynamic Area and use that.

I may have done that many years ago but can't remember what's
involved but it does have the most appeal with my shallow knowledge.

Is it hard to do?

I've just found some info in PRM5a, I'm reading and understanding
some of it. :-)

- claim some RMA, but probably not a good idea these days.

I didn't realize or forgotten that was different from Dynamic Area.

Thanks for your help.


Bob.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5ce8cb00a3bob@sick-of-spam.invalid>,
Bob Latham <bob@sick-of-spam.invalid> wrote:

In article <5ce8c3e7b9News04@avisoft.f9.co.uk>,
Martin <News04@avisoft.f9.co.uk> wrote:

What language are you using?

Basic assembler, I somehow feel I should apologise for that.

Not if you are up for the increased development and maintenance times.
And incompatibility with 64-bits!

You could...

I'm looking for memory that I can "claim?" (2MB-ish) and release
again with ease and has easy direct addressable space.
My feelings about these options are based on poor knowledge I'll
admit but

- allocate a large enough slotsize when your app starts.

This particular job is one of many my application performs. It will
not be used often and so a big claim at the start does not seem
ideal to me.

Is the 'job' a single-tasking program, or a Wimp task?
Claiming a large area at the start of an infrequently used job is
fine ... unless perhaps it runs for a very long time.
But 2MB is not large. This is virtual memory, not real stuff!

- change slotsize dynamically using SWI Wimp_SlotSize.

I *think* that limit has got much higher with OS5 and it may do the
job but I'm sure I've played with extending a app space in the past
and I didn't enjoy the experience. :-)

The limit was 28MB even before RO5, now even higher.
I frequently use 10's megabytes!

Just a matter of keeping track of the start and end addresses of your
extra space, and ensuring you do not write outside those limits!

- set up a Dynamic Area and use that.

I may have done that many years ago but can't remember what's
involved but it does have the most appeal with my shallow knowledge.
Is it hard to do?

No - use OS_DynamicArea to create (and remove) an area.

I've just found some info in PRM5a, I'm reading and understanding
some of it. :-)

- claim some RMA, but probably not a good idea these days.

I didn't realize or forgotten that was different from Dynamic Area.

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5ce8cdeaf6News04@avisoft.f9.co.uk>,
Martin <News04@avisoft.f9.co.uk> wrote:

In article <5ce8cb00a3bob@sick-of-spam.invalid>,
Bob Latham <bob@sick-of-spam.invalid> wrote:

In article <5ce8c3e7b9News04@avisoft.f9.co.uk>,
Martin <News04@avisoft.f9.co.uk> wrote:

[Snip]

Is the 'job' a single-tasking program, or a Wimp task?

Wimp multitasking.

Claiming a large area at the start of an infrequently used job is
fine ... unless perhaps it runs for a very long time.
But 2MB is not large. This is virtual memory, not real stuff!

Yes, but tag changing is a once in a blue moon event compared to
other functions used every few days.

[Snip]

- set up a Dynamic Area and use that.

I may have done that many years ago but can't remember what's
involved but it does have the most appeal with my shallow
knowledge. Is it hard to do?

No - use OS_DynamicArea to create (and remove) an area.

Reading .....


Thanks.

Bob.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <5ce8d6dc20bob@sick-of-spam.invalid>,
Bob Latham <bob@sick-of-spam.invalid> wrote:

No - use OS_DynamicArea to create (and remove) an area.

Reading .....

It is just a block of memory with a base start address and a length.
Can be read by
LDR[B] {baseregister,offfsetregister}
in some form or other, and written using STR[B].
Using LDM/STM for multiple words at a time if it suits your use will
probably be faster.

Lots of opportunity to read and even write to the wrong place!
Can be nasty.
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
--- Synchronet 3.22a-Linux NewsLink 1.2