Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #6205 > unrolled thread

Getting extra memory

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Getting extra memory Bob Latham <bob@sick-of-spam.invalid> - 2020-11-04 12:47 +0000
    Re: Getting extra memory Martin <News03@avisoft.f9.co.uk> - 2020-11-04 13:17 +0000
      Re: Getting extra memory Bob Latham <bob@sick-of-spam.invalid> - 2020-11-04 13:48 +0000
        Re: Getting extra memory Martin <News03@avisoft.f9.co.uk> - 2020-11-04 17:23 +0000
          Re: Getting extra memory Bob Latham <bob@sick-of-spam.invalid> - 2020-11-04 18:04 +0000
            Re: Getting extra memory Martin <News03@avisoft.f9.co.uk> - 2020-11-04 18:44 +0000
              Re: Getting extra memory Bob Latham <bob@sick-of-spam.invalid> - 2020-11-04 22:03 +0000
        Re: Getting extra memory druck <news@druck.org.uk> - 2020-11-04 18:06 +0000
          Re: Getting extra memory Bob Latham <bob@sick-of-spam.invalid> - 2020-11-04 18:33 +0000
    Re: Getting extra memory Steve Drain <steve@kappa.me.uk> - 2020-11-04 17:38 +0000
      Re: Getting extra memory Bob Latham <bob@sick-of-spam.invalid> - 2020-11-04 18:11 +0000
        Re: Getting extra memory Bob Latham <bob@sick-of-spam.invalid> - 2020-11-04 18:32 +0000

#6205 — Getting extra memory

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..

           MOV R0,#15
           SWI "Wimp_Extend"
           STR R0,data23+0;   save size in pages

           SWI "OS_ReadMemMapInfo"
           STR R0,page+0;     size of pages



           LDR R0,memsize+4
           MVN R1,#0;  -1
           SWI "Wimp_SlotSize"; change slot size



           MOV R0,#15
           SWI "Wimp_Extend"
           STR R0,data23+4;   save size in pages

           SWI "OS_ReadMemMapInfo"
           STR R0,page+4;     size of pages



           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've been checking that the slot size does change and it does hence
the extra code.


OS 5.27 30 sept 2020.

I'm miles out aren't I?  Anyone care to put me right.

Thanks.


Cheers,

Bob.

-- 
Bob Latham
Stourbridge, West Midlands

[toc] | [next] | [standalone]

#6206

In article <58ca210e71bob@sick-of-spam.invalid>,
   Bob Latham <bob@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. 

[toc] | [prev] | [next] | [standalone]

#6207

In article <58ca23d0f5News03@avisoft.f9.co.uk>,
   Martin <News03@avisoft.f9.co.uk> wrote:
> In article <58ca210e71bob@sick-of-spam.invalid>,
>    Bob Latham <bob@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. 


> 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?

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

Cheers,

Bob.

-- 
Bob Latham
Stourbridge, West Midlands

[toc] | [prev] | [next] | [standalone]

#6208

In article <58ca26a060bob@sick-of-spam.invalid>,
   Bob Latham <bob@sick-of-spam.invalid> wrote:
> In article <58ca23d0f5News03@avisoft.f9.co.uk>,
>    Martin <News03@avisoft.f9.co.uk> wrote:
> > In article <58ca210e71bob@sick-of-spam.invalid>,
> >    Bob Latham <bob@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.

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

[toc] | [prev] | [next] | [standalone]

#6210

In article <58ca3a4a89News03@avisoft.f9.co.uk>,
   Martin <News03@avisoft.f9.co.uk> wrote:
> In article <58ca26a060bob@sick-of-spam.invalid>,
>    Bob Latham <bob@sick-of-spam.invalid> wrote:
> > In article <58ca23d0f5News03@avisoft.f9.co.uk>,
> >    Martin <News03@avisoft.f9.co.uk> wrote:
> > > In article <58ca210e71bob@sick-of-spam.invalid>,
> > >    Bob Latham <bob@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



> > > 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.

Again you're probably right I just like assembler right from the
65C02 days on the BBC.

I recall back in the day, I designed my own crude eprom programmer
using the user port and it was as slow as hell until I coded it
assembler. It managed to read an 8k rom so quickly I didn't think it
was working for ages.

> > 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 :-))

:-)

But you could say that about almost anything people do for pleasure I
suppose. Some folk like lying on their back under some old car.

> [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?

I hadn't because my code works completely, it just gives an error.
Just tried it, to be honest it doesn't tell me anything. 

> And checked what code the abort is in (eg with *Where)

Had forgotten about *where. Mine says Basic too.

> It in BASICVFP in this 5.28 ROM, but yours is probably different.

It's the same.

See I'm not sure I can/should do what I'm doing with this memory
changing. Is it OK to grab some more memory in this way in a non
multi tasking bit of code running in a Basic slot? Is suspect not but
don't know why.


Thanks.

Cheers,

Bob.

-- 
Bob Latham
Stourbridge, West Midlands

[toc] | [prev] | [next] | [standalone]

#6214

In article <58ca3e1574bob@sick-of-spam.invalid>,
   Bob Latham <bob@sick-of-spam.invalid> wrote:
> In article <58ca3a4a89News03@avisoft.f9.co.uk>,
>    Martin <News03@avisoft.f9.co.uk> wrote:
> > In article <58ca26a060bob@sick-of-spam.invalid>,
> >    Bob Latham <bob@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.

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

[toc] | [prev] | [next] | [standalone]

#6216

In article <58ca41c319News03@avisoft.f9.co.uk>,
   Martin <News03@avisoft.f9.co.uk> wrote:
> In article <58ca3e1574bob@sick-of-spam.invalid>,
>    Bob Latham <bob@sick-of-spam.invalid> wrote:
> > In article <58ca3a4a89News03@avisoft.f9.co.uk>,
> >    Martin <News03@avisoft.f9.co.uk> wrote:
> > > In article <58ca26a060bob@sick-of-spam.invalid>,
> > >    Bob Latham <bob@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.

As confessed elsewhere I had forgotten about HIMEM and written across
it. I was thinking that I'd left a good gap from the Basic source to
assembled code and I could then stuff the file I wanted to work on
directly on top of the code. It worked as well, to a fashion.

Anyway it's only a hobby, grateful to everyone who popped in to
advise and everyone was really nice too.

Thanks.

Bob.

-- 
Bob Latham
Stourbridge, West Midlands

[toc] | [prev] | [next] | [standalone]

#6211

On 04/11/2020 13:48, Bob Latham wrote:
> In article <58ca23d0f5News03@avisoft.f9.co.uk>,
>     Martin <News03@avisoft.f9.co.uk> wrote:
>> In article <58ca210e71bob@sick-of-spam.invalid>,
>>     Bob Latham <bob@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

[toc] | [prev] | [next] | [standalone]

#6215

In article <rnuqjl$alc$1@dont-email.me>,
   druck <news@druck.org.uk> wrote:
> On 04/11/2020 13:48, Bob Latham wrote:
> > In article <58ca23d0f5News03@avisoft.f9.co.uk>,
> >     Martin <News03@avisoft.f9.co.uk> wrote:
> >> In article <58ca210e71bob@sick-of-spam.invalid>,
> >>     Bob Latham <bob@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.

I'm certain you're right Dave.

But it doesn't make me like Basic any the more. :-)


Bob.

-- 
Bob Latham
Stourbridge, West Midlands

[toc] | [prev] | [next] | [standalone]

#6209

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. ;-)

[toc] | [prev] | [next] | [standalone]

#6212

In article <rnuovq$107c$1@gioia.aioe.org>,
   Steve Drain <steve@kappa.me.uk> wrote:
> 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. ;-)

I rather suspect you're on the nail Steve.

In the light of those thoughts I need to have a look and think.

Thanks Steve,


Big help and a probably a good clue.


Cheers,

Bob.

-- 
Bob Latham
Stourbridge, West Midlands

[toc] | [prev] | [next] | [standalone]

#6213

In article <58ca3eaab3bob@sick-of-spam.invalid>,
   Bob Latham <bob@sick-of-spam.invalid> wrote:
> In article <rnuovq$107c$1@gioia.aioe.org>,
>    Steve Drain <steve@kappa.me.uk> wrote:
> > 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. ;-)

> I rather suspect you're on the nail Steve.

> In the light of those thoughts I need to have a look and think.

All fixed now. It was HIMEM it just didn't cross my mind. It explains
why it was the Basic module that was moaning.

Thanks Steve.


Cheers,

Bob.

-- 
Bob Latham
Stourbridge, West Midlands

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web