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

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

Obtaining BBC BASIC with updated ARM assembler.

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

Contents

  Obtaining BBC BASIC with updated ARM assembler. Gazza <usenet@garethlock.com> - 2012-08-10 06:53 -0700
    Re: Obtaining BBC BASIC with updated ARM assembler. Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-08-10 15:09 +0100
      Re: Obtaining BBC BASIC with updated ARM assembler. Gazza <usenet@garethlock.com> - 2012-08-10 07:36 -0700
        Re: Obtaining BBC BASIC with updated ARM assembler. "John Williams (News)" <UCEbin@tiscali.co.uk> - 2012-08-10 17:48 +0200
        Re: Obtaining BBC BASIC with updated ARM assembler. Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-08-10 17:27 +0100
          Re: Obtaining BBC BASIC with updated ARM assembler. Bob Latham <bob@sick-of-spam.invalid> - 2012-08-10 18:29 +0100
            Re: Obtaining BBC BASIC with updated ARM assembler. Gavin Wraith <gavin@wra1th.plus.com> - 2012-08-11 16:31 +0100
              Re: Obtaining BBC BASIC with updated ARM assembler. Jochen Lueg <jochenlueg@roevalley.com> - 2012-08-12 10:43 +0000
                Re: Obtaining BBC BASIC with updated ARM assembler. Bob Latham <bob@sick-of-spam.invalid> - 2012-08-12 12:29 +0100
          Re: Obtaining BBC BASIC with updated ARM assembler. druck <news@druck.org.uk> - 2012-08-12 09:23 +0100
        Re: Obtaining BBC BASIC with updated ARM assembler. Brian Jordan <brian.jordan9@btinternet.com> - 2012-08-10 19:01 +0100
        Re: Obtaining BBC BASIC with updated ARM assembler. xltardy@gmail.com - 2012-08-14 10:33 -0700
    Re: Obtaining BBC BASIC with updated ARM assembler. Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-08-10 17:04 +0100
    Re: Obtaining BBC BASIC with updated ARM assembler. jgh@arcade.demon.co.uk - 2012-08-10 15:42 -0700
      Re: Obtaining BBC BASIC with updated ARM assembler. Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-08-11 00:51 +0100
        Re: Obtaining BBC BASIC with updated ARM assembler. jgh@arcade.demon.co.uk - 2012-08-11 16:46 -0700
          Re: Obtaining BBC BASIC with updated ARM assembler. cferris@freeRemoveuk.com.invalid - 2012-08-12 09:44 +0100
          Re: Obtaining BBC BASIC with updated ARM assembler. Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-08-12 13:39 +0100
          Re: Obtaining BBC BASIC with updated ARM assembler. Steve Drain <steve@kappa.me.uk> - 2012-08-12 13:44 +0100
            Re: Obtaining BBC BASIC with updated ARM assembler. Gazza <usenet@garethlock.com> - 2012-08-14 05:07 -0700
              Re: Obtaining BBC BASIC with updated ARM assembler. Steve Drain <steve@kappa.me.uk> - 2012-08-15 19:47 +0100
                Re: Obtaining BBC BASIC with updated ARM assembler. Gazza <usenet@garethlock.com> - 2012-08-15 17:08 -0700
                  Re: Obtaining BBC BASIC with updated ARM assembler. Steve Drain <steve@kappa.me.uk> - 2012-08-16 11:21 +0100
                    Re: Obtaining BBC BASIC with updated ARM assembler. Gazza <usenet@garethlock.com> - 2012-08-17 04:10 -0700
                      Re: Obtaining BBC BASIC with updated ARM assembler. Gazza <usenet@garethlock.com> - 2012-08-17 04:16 -0700
                        Re: Obtaining BBC BASIC with updated ARM assembler. Gazza <usenet@garethlock.com> - 2012-08-21 08:30 -0700
                          Re: Obtaining BBC BASIC with updated ARM assembler. druck <news@druck.org.uk> - 2012-08-21 18:21 +0100
                            Re: Obtaining BBC BASIC with updated ARM assembler. Gazza <usenet@garethlock.com> - 2012-08-21 14:12 -0700
                          Re: Obtaining BBC BASIC with updated ARM assembler. Steve Drain <steve@kappa.me.uk> - 2012-08-21 19:20 +0100
                            Re: Obtaining BBC BASIC with updated ARM assembler. druck <news@druck.org.uk> - 2012-08-22 23:22 +0100
                          Re: Obtaining BBC BASIC with updated ARM assembler. Dave Higton <dave@davehigton.me.uk> - 2012-08-21 22:50 +0100
                            Re: Obtaining BBC BASIC with updated ARM assembler. Gazza <usenet@garethlock.com> - 2012-08-22 00:06 -0700
                              Re: Obtaining BBC BASIC with updated ARM assembler. Steve Drain <steve@kappa.me.uk> - 2012-08-22 11:25 +0100
                              Re: Obtaining BBC BASIC with updated ARM assembler. Dave Higton <dave@davehigton.me.uk> - 2012-08-22 14:00 +0100

Page 2 of 2 — ← Prev page 1 [2]

#2085

Gazza wrote:
> Had a try with your RFSFiles module on the target machine (A7000+ OS
> v3.71) First tried with a cooked up app with the module, a !Run script
> and the files to install, did this from !Boot.Choices.PreDesk (Thought
> this might be the safest way of getting it all in early enough not to
> brick anything that might come later.)
>
> Script consists of...
>
> RMEnsure RFSFiles 0.95 RMLoad <Obey$Dir>.RFSFiles
> RMEnsure RFSFiles 0.95 Error 0 RFSFiles not found or too old!
>
> RFSAdd Resources.BASIC.Messages <Obey$Dir>.Res.Messages -i
> RFSAdd Resources.BASIC.VFPData <Obey$Dir>.Res.VFPData -i
>
> RMEnsure BASIC 1.52 RMLoad <Obey$Dir>.Res.Basic152
> RMEnsure BASIC 1.52 Error 0 BBC BASIC v1.52 not installed!
>
> OK... So maybe it's an issue with loading it from PreDesk. So tried it
> from a desktop environment and still no joy.

What exactly is going wrong? Is there an error or is it that the file 
does not appear in ResourceFS? Or is it that the new BASIC fails to do 
what you expect?

There does not appear to be anything awry with the RFS commands above, 
except that you should not need the -i switch. This is to enable the 
file to be used without further processing with MessageTrans in your own 
program and was probably a bit enthusiastic of me when I wrote it, a 
long while back. ;-) Anyway, VFPData should be a Data file.

 > In the documentation it
 > says that one of the limitations is that it can't replace files that
 > IT hasn't put there in the first place...

RFSFiles cannot /remove/ such files; it can replace them, because 
ResourceFS uses the latest file registered.

Steve

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

#2087

On Aug 15, 7:47 pm, Steve Drain <st...@kappa.me.uk> wrote:
> Gazza wrote:
> > Had a try with your RFSFiles module on the target machine (A7000+ OS
> > v3.71) First tried with a cooked up app with the module, a !Run script
> > and the files to install, did this from !Boot.Choices.PreDesk (Thought
> > this might be the safest way of getting it all in early enough not to
> > brick anything that might come later.)
>
> > Script consists of...
>
> > RMEnsure RFSFiles 0.95 RMLoad <Obey$Dir>.RFSFiles
> > RMEnsure RFSFiles 0.95 Error 0 RFSFiles not found or too old!
>
> > RFSAdd Resources.BASIC.Messages <Obey$Dir>.Res.Messages -i
> > RFSAdd Resources.BASIC.VFPData <Obey$Dir>.Res.VFPData -i
>
> > RMEnsure BASIC 1.52 RMLoad <Obey$Dir>.Res.Basic152
> > RMEnsure BASIC 1.52 Error 0 BBC BASIC v1.52 not installed!
>
> > OK... So maybe it's an issue with loading it from PreDesk. So tried it
> > from a desktop environment and still no joy.
>
> What exactly is going wrong? Is there an error or is it that the file
> does not appear in ResourceFS? Or is it that the new BASIC fails to do
> what you expect?
>
> There does not appear to be anything awry with the RFS commands above,
> except that you should not need the -i switch. This is to enable the
> file to be used without further processing with MessageTrans in your own
> program and was probably a bit enthusiastic of me when I wrote it, a
> long while back. ;-) Anyway, VFPData should be a Data file.
>
>  > In the documentation it
>  > says that one of the limitations is that it can't replace files that
>  > IT hasn't put there in the first place...
>
> RFSFiles cannot /remove/ such files; it can replace them, because
> ResourceFS uses the latest file registered.
>
> Steve- Hide quoted text -
>
> - Show quoted text -

When stuck in PreDesk, the machine in question booted to a 16 colour
640*480 desktop with an error dialogue window saying that VFPData
could not be found (IIRC). When run as an application, it came back
clean. hopped to the CLI with F12 and attempted to start BASIC in the
normal way (*bas.) and it just threw up a similar error. Checked in
Resources.BASIC and VFPData hadn't copied over. There was a Messages
file present, but I'm assuming that this was the file pre-existing in
the ROM, though I didn't do any comparisons.

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

#2088

Gazza wrote:
>>> RFSAdd Resources.BASIC.Messages <Obey$Dir>.Res.Messages -i
>>> RFSAdd Resources.BASIC.VFPData <Obey$Dir>.Res.VFPData -i
> When stuck in PreDesk, the machine in question booted to a 16 colour
> 640*480 desktop with an error dialogue window saying that VFPData
> could not be found (IIRC). When run as an application, it came back
> clean. hopped to the CLI with F12 and attempted to start BASIC in the
> normal way (*bas.) and it just threw up a similar error. Checked in
> Resources.BASIC and VFPData hadn't copied over. There was a Messages
> file present, but I'm assuming that this was the file pre-existing in
> the ROM, though I didn't do any comparisons.

The new version of BASIC cannot start because it cannot find its 
resources. Because many other things in the Boot sequence rely on BASIC, 
this will be terminal when you try to do the replacement in PreDesk.

Note that RFSAdd does not generate an error if the source file is not 
found, although the underlying SWI does. I suspect that the path to the 
file that you have used is incorrect and needs double-checking.

Steve

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

#2089

On Aug 16, 11:21 am, Steve Drain <st...@kappa.me.uk> wrote:
>
> Note that RFSAdd does not generate an error if the source file is not
> found, although the underlying SWI does. I suspect that the path to the
> file that you have used is incorrect and needs double-checking.
>
> Steve

I'd always assumed that when putting a directory inside PreDesk, if a !
Run file was discovered, then that would be executed. Assuming that
this !Run file is of type obey, then <Obey$Dir> would be set to the
location of the file, just as in a regular application. That is
therefore what I'm using to gather everything else in. If I'm assuming
too much here, then please inform me. However, I will re-check what
I'm doing.

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

#2090

Scratch that!!! Me being a bit dippy... I'd copy-pasted the two RFSAdd
commands and forgotten to change the left half of the second command,
so it was registering the VFPData over the Messages...

DOH!!

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

#2096

Another quick question...

Is there an easy way to tell if BASIC is already RAM resident (as
opposed to the version in the ROM). Preferably not from within BASIC,
as I'm going to use the code in the installer I've cooked up to kill
BASIC before re-loading the new version into RAM. IIRC trying to do
this to a RAM resident BASIC will brick the machine.

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

#2098

On 21/08/2012 16:30, Gazza wrote:
> Another quick question...
>
> Is there an easy way to tell if BASIC is already RAM resident (as
> opposed to the version in the ROM). Preferably not from within BASIC,
> as I'm going to use the code in the installer I've cooked up to kill
> BASIC before re-loading the new version into RAM. IIRC trying to do
> this to a RAM resident BASIC will brick the machine.
>
You do realise that would kill every BASIC using task running?

---druck

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

#2100

On Aug 21, 6:21 pm, druck <n...@druck.org.uk> wrote:
> On 21/08/2012 16:30, Gazza wrote:> Another quick question...
>
> > Is there an easy way to tell if BASIC is already RAM resident (as
> > opposed to the version in the ROM). Preferably not from within BASIC,
> > as I'm going to use the code in the installer I've cooked up to kill
> > BASIC before re-loading the new version into RAM. IIRC trying to do
> > this to a RAM resident BASIC will brick the machine.
>
> You do realise that would kill every BASIC using task running?
>
> ---druck

OK... Maybe not quite like that, but the idea is that I prevent the
installer taking any action if BASIC is already RAM resident. What
sequence I take to get it RAM resident falls on the script
conditionally run after this detection code, maybe just RMLoad ing it
over the top might be a better solution.

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

#2099

On 21/08/2012 16:30, Gazza wrote:
> Another quick question...
>
> Is there an easy way to tell if BASIC is already RAM resident (as
> opposed to the version in the ROM). Preferably not from within BASIC,
> as I'm going to use the code in the installer I've cooked up to kill
> BASIC before re-loading the new version into RAM. IIRC trying to do
> this to a RAM resident BASIC will brick the machine.

I am not quite sure what you want to achieve. If it is to replace the 
current BASIC module you need do no more than RMLoad the new one. If it 
were in ROM then applications that were using it will still carry on. If 
it were in RAM then the old version will be killed before the new one 
loads, but as you say, this will not be without consequences.

AFAICS you should only ever want or need to RMLoad BASIC once after the 
machine has been reset.

To try to answer your question directly:

  you could use OS_Module to find the address of the module and see if 
that is in the RMA, but the RMA is not in the same place in all machines.

  sneakily, you might try writing to an address in the module and see if 
the contents change

  you might find the address of the ROM BASIC before any new version is 
RMLoaded and then check this against the current address

  etc

But, honestly, I cannot see why.

Steve

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

#2111

On 21/08/2012 19:20, Steve Drain wrote:
> On 21/08/2012 16:30, Gazza wrote:
>> Another quick question...
>>
>> Is there an easy way to tell if BASIC is already RAM resident (as
>> opposed to the version in the ROM). Preferably not from within BASIC,
>> as I'm going to use the code in the installer I've cooked up to kill
>> BASIC before re-loading the new version into RAM. IIRC trying to do
>> this to a RAM resident BASIC will brick the machine.
>
> I am not quite sure what you want to achieve.

This is Gazza's main problem when asking questions here. Instead of 
saying what he is trying to achieve and asking how to do it, he has come 
up with some infeasible method and asks how to make it work.

---druck

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

#2101

In message
<6491a0eb-8381-4390-b302-c895e45379b3@v12g2000vbc.googlegroups.com>
          Gazza <usenet@garethlock.com> wrote:

> Another quick question...
> 
> Is there an easy way to tell if BASIC is already RAM resident (as opposed
> to the version in the ROM). Preferably not from within BASIC, as I'm going
> to use the code in the installer I've cooked up to kill BASIC before
> re-loading the new version into RAM. IIRC trying to do this to a RAM
> resident BASIC will brick the machine.

What on earth are you trying to achieve?  Why on earth do you care
whether BASIC is RAM resident or ROM resident?

Dave

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

#2103

On Aug 21, 10:50 pm, Dave Higton <d...@davehigton.me.uk> wrote:
> In message
> <6491a0eb-8381-4390-b302-c895e4537...@v12g2000vbc.googlegroups.com>
>           Gazza <use...@garethlock.com> wrote:
>
> > Another quick question...
>
> > Is there an easy way to tell if BASIC is already RAM resident (as opposed
> > to the version in the ROM). Preferably not from within BASIC, as I'm going
> > to use the code in the installer I've cooked up to kill BASIC before
> > re-loading the new version into RAM. IIRC trying to do this to a RAM
> > resident BASIC will brick the machine.
>
> What on earth are you trying to achieve?  Why on earth do you care
> whether BASIC is RAM resident or ROM resident?
>
> Dave

I suppose it wouldn't matter too much if it were dumped in PreDesk,
but just as a failsafe in case some idiot tries to run it from the
desktop. By that time of course, nasty things could happen if BASIC
was RAM resident.

After further experimentation, I've corrected a few more typos and got
it running of sorts. We have garbled messages though and other strange
things are happening. I'm thinking it could be down to BASICTrans, but
not sure. Can anyone shed some light on this?

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

#2106

Gazza wrote:
> Dave Higton wrote:
>> What on earth are you trying to achieve?
> I suppose it wouldn't matter too much if it were dumped in PreDesk,
> but just as a failsafe in case some idiot tries to run it from the
> desktop. By that time of course, nasty things could happen if BASIC
> was RAM resident.
>
> After further experimentation, I've corrected a few more typos and got
> it running of sorts. We have garbled messages though and other strange
> things are happening. I'm thinking it could be down to BASICTrans, but
> not sure. Can anyone shed some light on this?

Trying to set up the RO 5.19 BASIC to run on an early machine does seem 
to be likely to throw up problems. I would not attempt it.

AFAICT you want to run a version of BASIC with more assembler 
instructions than the one on your machine, which is an A7000+ running RO 
3.71. Please correct me if this is not correct.

In that case, you have a number of options. The simplest is a library of 
FNs that you can insert in your code to emulate instructions, and this 
requires nothing extra. Then there are assembler enhancers. I have 
personally been using Extended BASIC Assembler for years and I think it 
would fit the bill. If you cannot find it, I can send you a copy. I 
wrote my own StrongHelp manual for it, and you could download that to 
see if it will do what you want:

  http://kappa.me.uk/StrongHelp/shExtBASasm010.zip

I just run the installer app when I start programming; I do not faff 
around with !Boot and PreDesk. KISS

Steve

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

#2108

In message <45f97cd4-0f28-4f69-a829-79ba8c459d68@s2g2000vbj.googlegroups.com>
          Gazza <usenet@garethlock.com> wrote:

> On Aug 21, 10:50 pm, Dave Higton <d...@davehigton.me.uk> wrote:
> > In message
> > <6491a0eb-8381-4390-b302-c895e4537...@v12g2000vbc.googlegroups.com>      
> >     Gazza <use...@garethlock.com> wrote:
> > 
> > > Another quick question...
> > 
> > > Is there an easy way to tell if BASIC is already RAM resident (as
> > > opposed to the version in the ROM). Preferably not from within BASIC,
> > > as I'm going to use the code in the installer I've cooked up to kill
> > > BASIC before re-loading the new version into RAM. IIRC trying to do
> > > this to a RAM resident BASIC will brick the machine.
> > 
> > What on earth are you trying to achieve?  Why on earth do you care
> > whether BASIC is RAM resident or ROM resident?
> > 
> > Dave
> 
> I suppose it wouldn't matter too much if it were dumped in PreDesk, but
> just as a failsafe in case some idiot tries to run it from the desktop. By
> that time of course, nasty things could happen if BASIC was RAM resident.

Why?  What nasty things?

Dave

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web