Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Getting extra memory

24 views
Skip to first unread message

Martin

unread,
Nov 4, 2020, 8:17:58 AM11/4/20
to
In article <58ca21...@sick-of-spam.invalid>,
Bob Latham <b...@sick-of-spam.invalid> wrote:
> I've never really understood memory allocation and no matter how
> much reading I do, the picture doesn't clear. I'm obviously doing
> something stupid as a result.

> I'm trying to load a largish file up to 7M in size into memory,
> make some changes to it and save it out again. I've succeeded, sort
> of, it does what I want but I get an error on the file load and
> don't understand why.

> I'm doing this in basic asembler not multitasking. Cut to the bones
> it errors with this..

[Snip]
> ADR R2,workspace
[Snip]

> error on the file load: Abort on data transfer at &FC1AD8E8.

Not sure what, if or how you have set workspace.

I am not sure why you are resorting to assembler, when you could do it
in BASIC quite easily. This code should provide a basis...

SYS "OS_File",17,file$ TO obj%,,,,len%
IF obj%<>1 THEN ERROR 1,"Not found"
DIM file% len%
SYS "OS_File",16,file$,file%
>>code to change data<<
SYS "OS_File",10,file$+"N",filetype%,,file%,file%+len%

You would need to check the Next slot was set larger than 7MB
initially, or before the DIM use something like:
END = HIMEM + len%

Or have I missed something?

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

Martin

unread,
Nov 4, 2020, 12:23:27 PM11/4/20
to
In article <58ca26...@sick-of-spam.invalid>,
Bob Latham <b...@sick-of-spam.invalid> wrote:
> In article <58ca23d0...@avisoft.f9.co.uk>,
> Martin <New...@avisoft.f9.co.uk> wrote:
> > In article <58ca21...@sick-of-spam.invalid>,
> > Bob Latham <b...@sick-of-spam.invalid> wrote:

> > Not sure what, if or how you have set workspace.
> It starts out as just the "next" slot 640K.

So how is the expression 'workspace' set to &8000+next ?

> > I am not sure why you are resorting to assembler, when you could
> > do it in BASIC quite easily.

> 1. For the speed.

The time will be largely spent in OS_File for load and save, which is
the same in Basic & assembler.

> 2. This is for pleasure, I like assembler. Always my first choice
> unless I need chunky maths then I'm forced into Basic.

Aaah! It was not clear you are a masochist :-))

[snip simple BASIC]

> Thanks for that. I can see that may well be the sensible way but I
> do want to understand why my assembler code errors.

Have you looked at the output from the *Showregs command?
And checked what code the abort is in (eg with *Where)
It in BASICVFP in this 5.28 ROM, but yours is probably different.

Steve Drain

unread,
Nov 4, 2020, 12:39:09 PM11/4/20
to
On 04/11/2020 12:47, Bob Latham wrote:
> I'm trying to load a largish file up to 7M in size into memory, make
> some changes to it and save it out again.
>
> MOV R0,#16
> ADR R1,Fname1
> ADR R2,workspace
> MOV R3,#0
> SWI "OS_File"; load file
>
> error on the file load: Abort on data transfer at &FC1AD8E8.
> But the file does load and save.

I am puzzled, probably from a shortage of information. Where is 'workspace'?

If you are calling this code from BASIC I would assume you are loading
the file above HIMEM. Therefore there would have to be code to find
that. Then you must account for the fact that HIMEM is an absolute
address but Wimp_SlotSize is for the memory in the application slot
above &8000. Is that any help?

Perhaps you could claim a dynamic area more simply. ;-)

druck

unread,
Nov 4, 2020, 1:06:46 PM11/4/20
to
On 04/11/2020 13:48, Bob Latham wrote:
> In article <58ca23d0...@avisoft.f9.co.uk>,
> Martin <New...@avisoft.f9.co.uk> wrote:
>> In article <58ca21...@sick-of-spam.invalid>,
>> Bob Latham <b...@sick-of-spam.invalid> wrote:
>
>
>> Not sure what, if or how you have set workspace.
>
> It starts out as just the "next" slot 640K.
>
>> I am not sure why you are resorting to assembler, when you could do
>> it in BASIC quite easily.
>
> 1. For the speed.
>
> 2. This is for pleasure, I like assembler. Always my first choice
> unless I need chunky maths then I'm forced into Basic.

That's the wrong way around! By all means use assembler for speed
critical things - such as chunky maths.

But for mundane things such as memory allocation and loading a file,
take advantage of a high level language to do the donkey work of getting
the OS to shift memory about, and read the data from the filing system.

---druck

Martin

unread,
Nov 4, 2020, 1:45:03 PM11/4/20
to
In article <58ca3e...@sick-of-spam.invalid>,
Bob Latham <b...@sick-of-spam.invalid> wrote:
> In article <58ca3a4a...@avisoft.f9.co.uk>,
> Martin <New...@avisoft.f9.co.uk> wrote:
> > In article <58ca26...@sick-of-spam.invalid>,
> > Bob Latham <b...@sick-of-spam.invalid> wrote:

> > > > Not sure what, if or how you have set workspace.
> > > It starts out as just the "next" slot 640K.

> > So how is the expression 'workspace' set to &8000+next ?

> A perfectly reasonable question when eventually I understood it. For
> some reason it didn't dawn at first.

> There is a label in the assembler right at the end.
> .workspace

> It should then sit right above the assembled code.

> So you'll now want to know O% and P% I presume?

> P%=&40000:O%=&40000

Are you saving the assembled code, then running the saved file?
Or calling the code from within the BASIC?

If the latter, then if your next slot is 640K, then &40000 is below
that. When the code is executed, if a 7MB file is loaded at the end
of the code, it will overwrite the end of the BASIC memory (as just
below &80000+640k) and so the BASIC stack will be overwritten. This
would cause problems when the called assembled code returns back to
the BASIC program - hence the abort in the BASIC module. The assembled
code will have saved the file ok.
0 new messages