Topics

SOCKLIB

bb4w@...
 

Hello all
Does anyone have plans to release a version of the SOCKLIB for the
raspberry pi?

Regards
Ian Karley

Richard Russell
 

On Tue, Jul 25, 2017 at 11:31 pm, <bb4w@...> wrote:
Does anyone have plans to release a version of the SOCKLIB for the
raspberry pi?
One unresolved issue is what dependencies it is acceptable for 'BBC BASIC for SDL 2.0' (BBCSDL) to have.  At the moment it depends (of course) on SDL2 itself, and on SDL_ttf for the font handling.  In order to support the SOCKLIB library it would also need to have a dependency on SDL_net.

The downsides of an additional dependency are that the Android and Mac OS versions would get bigger (because of the inclusion of SDL_net in the package) and the Linux and Raspberry Pi versions would be a bit harder to install (because of the necessity to download SDL_net from the appropriate repository).

The release of the next version is imminent (next week) so it's too late to consider the inclusion of SDL_net in that - it's a pity you didn't respond to the 'BBCSDL v0.18 wish list' thread - but we can at least initiate a discussion on its desirability.  I presume you would be in favour, what do other people think?

Richard.

Richard Russell
 

On Wed, Jul 26, 2017 at 01:27 am, Richard Russell wrote:
what do other people think?
So, nobody has any opinion at all?  I would greatly appreciate it if one (or more) of those who are apparently indifferent to the cross-platform version of BBC BASIC could explain why.   Is there really such antipathy towards operating systems and platforms other than Windows?  Even if competitive 'desktop' OSes hold no interest, surely most people these days have some kind of mobile device (smartphone, tablet etc.) on which they might like to run BASIC?

Richard.

Cecil Bayona
 

A little context in the email might be helpful as is I had to go to the groups page to find the original email.

Personally I will be using BBC Basic for Linux and MacOS shortly, eventually I will get to the Raspberry version as currently I have a couple of Raspberries I bought on sale for $10 but they are still in their sealed boxes, currently I have more projects going than what I can handle. A socket library I would think would be particularly useful as IOT applications are quite often used with Raspberries.

If one has to install extra software to make it work then so be it, are there options where extra software is not needed? If not then there is no decision to make.

An yes I can see that a Basic language for Raspberry or Android would be quite useful as the programming options sometimes are too limited.

On 7/29/2017 6:57 AM, Richard Russell wrote:
On Wed, Jul 26, 2017 at 01:27 am, Richard Russell wrote:
what do other people think?
So, nobody has any opinion at all? I would greatly appreciate it if one (or more) of those who are apparently indifferent to the cross-platform version of BBC BASIC could explain why. Is there really such antipathy towards operating systems and platforms other than Windows? Even if competitive 'desktop' OSes hold no interest, surely most people these days have some kind of mobile device (smartphone, tablet etc.) on which they might like to run BASIC?
Richard.
--
Cecil - k5nwa http://thepartsplace.k5nwa.com/

Storer, Darren
 

Hi Richard,

Multi-platform SOCKLIB support, especailly on Android and Raspberry Pi would be a boon; I have a number of remote monitoring projects that could be easily realised with this addition.

Apologies for the slow reply, I've been working away and have only just reviewed my e-mails.

Thanks again for your continued development effort.

Regards

Darren


On 29 July 2017 at 12:57, Richard Russell <news@...> wrote:
On Wed, Jul 26, 2017 at 01:27 am, Richard Russell wrote:
what do other people think?
So, nobody has any opinion at all?  I would greatly appreciate it if one (or more) of those who are apparently indifferent to the cross-platform version of BBC BASIC could explain why.   Is there really such antipathy towards operating systems and platforms other than Windows?  Even if competitive 'desktop' OSes hold no interest, surely most people these days have some kind of mobile device (smartphone, tablet etc.) on which they might like to run BASIC?

Richard.

Richard Russell
 

On Sat, Jul 29, 2017 at 11:36 am, Cecil Bayona wrote:
I have a couple of Raspberries I bought on sale for $10 but they are still in their sealed boxes
If these are older models (RPi 2 or earlier) they may not run BBC BASIC.  BBCSDL has only been tested on the Raspberry Pi 3 with Raspbian Jessie plus the 'experimental' GL Driver.

> are there options where extra software is not needed?

Possibly you could talk directly to the OS.  I couldn't provide any assistance with that (I know nothing about Linux), and of course it would make your program platform-specific which from my perspective is undesirable, but if you want to try it obviously that's up to you.

Richard.

Cecil Bayona
 

Raspberries 3, I bought 2 I should have bought 5 which was the limit.

On 7/29/2017 5:17 PM, Richard Russell wrote:
On Sat, Jul 29, 2017 at 11:36 am, Cecil Bayona wrote:
I have a couple of Raspberries I bought on sale for $10 but they are
still in their sealed boxes
If these are older models (RPi 2 or earlier) they may not run BBC BASIC. BBCSDL has only been tested on the Raspberry Pi 3 with Raspbian Jessie plus the 'experimental' GL Driver.

> are there options where extra software is not needed?
Possibly you could talk directly to the OS. I couldn't provide any assistance with that (I know nothing about Linux), and of course it would make your program platform-specific which from my perspective is undesirable, but if you want to try it obviously that's up to you.
Richard.
--
Cecil - k5nwa http://thepartsplace.k5nwa.com/

Richard Russell
 

On Sat, Jul 29, 2017 at 03:29 pm, Cecil Bayona wrote:
Raspberries 3, I bought 2 I should have bought 5 which was the limit.
At $10 each you definitely should!

Dare I reiterate my plea for somebody to help port 'sdldebug.bbc' from x86 to ARM code?  Currently, developing BBC BASIC programs on the RPi is made more difficult by the absence of a debugger (trace + list variables) and profiler.   I am confident that anybody who knows ARM assembly language (which doesn't include me), plus a little familiarity with x86 assembler, would not find the translation difficult.  There must surely be such people here.

Richard.

 

On Sun, 30 Jul 2017, at 10:48, Richard Russell wrote:
Dare I reiterate my plea for somebody to help port 'sdldebug.bbc' from
x86 to ARM code?  Currently, developing BBC BASIC programs on the RPi is
made more difficult by the absence of a debugger (trace + list variables)
and profiler.   I am confident that anybody who knows ARM assembly
language (which doesn't include me), plus a little familiarity with x86
assembler, would not find the translation difficult.  There must surely
be such people here.
I wonder about that. Nearly all the Q&A I see on this mail list has questions
raised by fairly naive programmers. It's hard to guess who else just lurks.

If BBC BASIC has perhaps been seen as a 'simple' language for hobbyists to
use, why do you expect people with much more technical knowledge to be ]
here too?

And... you hope that such people will have the interest and the time to
develop what you want. Inevitably those people will be busy with their
own projects.

The only assembler I'm fluent in (or was) is for the S/370 instruction set.

--
Jeremy Nicoll - my opinions are my own.

Richard Russell
 

On Sun, Jul 30, 2017 at 03:40 am, Jeremy Nicoll wrote:
If BBC BASIC has perhaps been seen as a 'simple' language for hobbyists to
use, why do you expect people with much more technical knowledge to be
here too?
Because the inbuilt assembler has been a crucial feature of BBC BASIC since the very beginning (6502 version on the BBC Micro) and knowledge of assembly language is not uncommon amongst users.  Indeed the 'low level' features of BBC BASIC (not only the assembler but also the indirection operators etc.) make it particularly attractive to a certain kind of "hobbyist" programmer who wants to delve more deeply into the inner workings of the machine.  People who want a 'simple' language are likely to be better served by dialects such as Liberty BASIC and Just BASIC (which I also use and support of course).

> Nearly all the Q&A I see on this mail list has questions raised by fairly naive programmers.

That's stating the obvious, surely?  It's the less knowledgeable users who need to ask the questions; the more experienced ones know the answers already, or at least know where to find them.  I don't necessary expect a large proportion of members to be in the latter category, but I am confident that there are several of them capable of the task in question.

> And... you hope that such people will have the interest and the time to develop what you want. 

What I want?  What a strange thing to say!  I don't have any need for improved debugging capabilities on the Raspberry Pi because I would never use that platform for software development.  I am lucky enough to have a range of different machines running BBCSDL, and I would always choose to use one with an x86 CPU to get the bugs out of a BASIC program.  The only people to suffer because of the lack of an ARM version of 'sdldebug.bbc' are users!  I am asking them to help themselves, not me.

I have said all along that BBCSDL will need to be developed in an entirely different fashion from BB4W.  I do not have the time, inclination or ability to do everything myself; rather development will be a collaborative exercise between me and users.  I do not expect people to be able to modify the interpreter. but I do expect them to help develop the IDE (itself written in BASIC of course), libraries, utilities and documentation.  I would remind you that the first IDE to be made available for BBCSDL was not written by me but by Andy Parkes, and it's still the better of the two in some ways.  He has plans to develop it further.

May I ask what your interest in BBC BASIC is?  Do you actually program in the language, and if so how regularly?  Do you think BBCSDL is a worthwhile development and if so how would you propose that it be carried forward?

Richard.

 

On Sun, 30 Jul 2017, at 12:18, Richard Russell wrote:
On Sun, Jul 30, 2017 at 03:40 am, Jeremy Nicoll wrote:


If BBC BASIC has perhaps been seen as a 'simple' language for hobbyists to

use, why do you expect people with much more technical knowledge to be
here too?
Because the inbuilt assembler has been a crucial feature of BBC BASIC
since the very beginning (6502 version on the BBC Micro) and knowledge of
assembly language is *not* uncommon amongst users. 
Maybe that knowledge isn't sufficent to tackle a whole project in
assembler
though; even I can read snippets of various machines' assemblers and get
a
rough idea of what it does, bit I'm nowhere near competent to originate
any.

Indeed the 'low
level' features of BBC BASIC (not only the assembler but also the
indirection operators etc.) make it particularly attractive to a certain
kind of "hobbyist" programmer who wants to delve more deeply into the
inner workings of the machine. 
I've written BBC BASIC (for the original BBC micro) back in the 1980s,
and also
on RISC OS machines. I fully understood (and needed) indirection
operators,
but at that stage knew no assembler for any platform.


People who want a 'simple' language are
likely to be better served by dialects such as Liberty BASIC and Just
BASIC (which I also use and support of course).
Maybe, but some possibly use your BBC BASIC simply because of the "BBC"
part of its name making it easy to find in the first place.


 Nearly all the Q&A I see on this mail list has questions raised by fairly naive programmers.
That's stating the obvious, surely? 
Fair enough.

It's the less knowledgeable users
who need to ask the questions; the more experienced ones know the answers
already, or at least know where to find them.  I don't necessary expect a
large proportion of members to be in the latter category, but I am
confident that there are several of them capable of the task in question.
Maybe THIS discussion will help to flush them out?


 And... you hope that such people will have the interest and the time to develop what you want. 
What *I* want?  What a strange thing to say! 
Ahem. You said: "Dare I reiterate my plea for somebody to help port..."

It's YOUR plea. You're plea-ding. You want.

I accept that you personally don't need the capability, but arguing that
you don't
in any sense 'want' it is disingenuous.


May I ask what your interest in BBC BASIC is? 
It comes from several points of view. I wrote commercial code in it
back in the 1980s,
so there's some nostalgia. Also more recently the RO stuff. I also
used to tutor students
programming in Waterloo BASIC, and I extended that language a little bit
(with on-the-
fly translation of the extensions back to standard WB).

Programming languages in general interest me. The discussions on this
mail list are
often interesting; for me not so much regarding the language but in what
they teach
me about eg the Windows APIs.

Do you actually program in the language, and if so how regularly?
I wrote a lot of stuff in BASIC on RO machines, mainly for my own use,
and when I first
started to use Windows machines at home (not until about 2006) I
wondered if using
your product would be useful. I lurked for a while on your mail
list(s) then bought it.

But so far I've written nothing that needs any GUI stuff nor access to
Windows APIs; my
CLI tools get written in ooREXX, because I'm much more familiar with
REXX than any
flavour of BASIC. And ooREXX can do all that too, if I invest a lot of
effort finding out
how. I'm not sure though that I wouldn't be better making that effort
in one of the
flavours of C, and then also being able to contribute to FOSS projects.

I don't program much at all these days, because I have significant
health problems of
my own, and far too many demands on my time and energy. The dominant
problem
at the moment is that 'my life' is on hold while all the issues with an
elderly parent get
worked through. I'm hardly ever even in my own house.

Do you think BBCSDL is a worthwhile development
YES. And when I found out a whole back that my ARM-based Android phone
could have
it installed that piqued my interest considerably. But actually trying
it out will need to
wait.

and if so how would you propose that it be carried forward?
I have few ideas. But it does occur to me (and I doubt you'll find this
helpful) that you're
in the situation of a priest preaching to the choir. Maybe the people
you need to engage
are not those here, but programmers elsewhere looking for a new avenue
to explore.

So... maybe describing your project, asking for help, and emailling that
to places like
hacklabs, maker faires, university computing departments etc... would
produce useful
help?

--
Jeremy Nicoll - my opinions are my own.

Richard Russell
 

On Sun, Jul 30, 2017 at 06:09 am, Jeremy Nicoll wrote:
Maybe that knowledge isn't sufficent to tackle a whole project in assembler
though; even I can read snippets of various machines' assemblers and get
a rough idea of what it does, bit I'm nowhere near competent to originate any.
But I'm not asking anybody to "tackle a whole project" or "originate" anything.  There's an existing program 'sdldebug.bbc' which is a mixture of BASIC code and x86 assembler code that does exactly what is required, which needs to be translated to ARM.  It requires no understanding of how the code works (in any detail) nor any change to that functionality, but simply an 'instruction by instruction' translation.  For somebody with a half decent understanding of ARM assembler and "a rough idea" of what the x86 mnemonics mean it should be a 'mechanical' process requiring little thought.

> arguing that you don't in any sense 'want' it is disingenuous.

Of course I'm the one who has to ask (plea, cajole) but "asking" and "wanting" are different.

> I don't program much at all these days, because I have significant health problems of my own

I'm sorry to hear that, but I am in the same position myself (a hospital visit tomorrow in fact).  The rapid deterioration in my mental faculties is one of the main reasons why I am so dependent on help from others.

> maybe describing your project, asking for help, and emailling that
> to places like hacklabs, maker faires, university computing departments
> etc... would produce useful help?

I honestly can't see anybody outside the BBC BASIC 'community' being sufficiently interested.  As I've said before, I do intend to make the C implementation of BBCSDL (but not the assembler one) Open Source at some point, which would give the opportunity for somebody to continue the work after I'm no longer able to, or no longer around at all.

Richard.

Cecil Bayona
 

I wish I could help but unfortunately I have zero experience with ARM assembler. I hope as a future project to learn those skills but I have a lot on my plate right now so it will be a while until I embark on that project.

It's amazing the whole BBC Basic and it's variants projects, a lot of work over many years so thank you for persisting at it. A tool that con work on several OSes without a major rewrite is a very useful tool and is one of the reasons why I recently purchased the software.

I'm retired due to health issues and perfectly understand your position and I don't quite have the skills I used to have specially at learning new things so I am having problems resurrecting some very old projects.

A question is are you using the full ARM instruction set or Thumb2 instructions?

On some of my projects down the line I recently found that the ARM CPUs in question only have the Thumb2 instruction sets so that is what I intend to learn eventually.

On 7/30/2017 4:48 AM, Richard Russell wrote:
On Sat, Jul 29, 2017 at 03:29 pm, Cecil Bayona wrote:
Raspberries 3, I bought 2 I should have bought 5 which was the limit.
At $10 each you definitely should!
Dare I reiterate my plea for somebody to help port 'sdldebug.bbc' from x86 to ARM code? Currently, developing BBC BASIC programs on the RPi is made more difficult by the absence of a debugger (trace + list variables) and profiler. I am confident that anybody who knows ARM assembly language (which doesn't include me), plus a little familiarity with x86 assembler, would not find the translation difficult. There must surely be such people here.
Richard.
--
Cecil - k5nwa http://thepartsplace.k5nwa.com/

Cecil Bayona
 

Is the current ARM projects being developed in a Windows/Linux/MacOS desktop environment or is it being developed on a Raspberry?

I ask because I own a copy of the Rowley Development System for ARM and it develops and debugs software for remote targets such as the Raspberry from a PC.

Is the source for the Raspberry and Linux versions available to civilians or does one need to be part of the Development Team with NDA?

On 7/30/2017 4:48 AM, Richard Russell wrote:
On Sat, Jul 29, 2017 at 03:29 pm, Cecil Bayona wrote:
Raspberries 3, I bought 2 I should have bought 5 which was the limit.
At $10 each you definitely should!
Dare I reiterate my plea for somebody to help port 'sdldebug.bbc' from x86 to ARM code? Currently, developing BBC BASIC programs on the RPi is made more difficult by the absence of a debugger (trace + list variables) and profiler. I am confident that anybody who knows ARM assembly language (which doesn't include me), plus a little familiarity with x86 assembler, would not find the translation difficult. There must surely be such people here.
Richard.
_._,_._,_
--
Cecil - k5nwa http://thepartsplace.k5nwa.com/

Richard Russell
 

On Sun, Jul 30, 2017 at 10:52 am, Cecil Bayona wrote:
A question is are you using the full ARM instruction set or Thumb2 instructions?
The assembler built into BBCSDL generates only 32-bit 'ARM' instructions (and only a subset of those is supported), as does the assembler in the Acorn ARM version of BBC BASIC.  You can call Thumb code using CALL, USR or SYS (indeed the pre-compiled 'binary blob' that is contained within SORTLIB is Thumb code) but you cannot assemble it using the built-in assembler.  That's not to say that the facility couldn't be added at some point: the assembler is coded in C and once I've opened up the source anybody could in principle extend it (or if you don't want to wait until then I'll happily make it available now).

> Is the current ARM projects being developed in a Windows/Linux/MacOS desktop
> environment or is it being developed on a Raspberry?

It depends on what you mean by "developed".  Code changes and testing are carried out on Windows (normally) but each platform-specific edition is built on that platform, so the Raspberry Pi edition of BBCSDL is compiled and linked on an RPi 3.   The exception is the Android edition, which is built on Windows.

Richard.

Paul Marshall
 

On Sun, Jul 30, 2017 at 04:18 am, Richard Russell wrote:
Because the inbuilt assembler has been a crucial feature of BBC BASIC since the very beginning (6502 version on the BBC Micro) and knowledge of assembly language is not uncommon amongst users.
I was one of those programmers for whom the built in assembler was one of the outstanding features. First in Z80 then 6502 on the BBC then ARM on the Arc. I really enjoyed ARM - it was so elegant and consistent it was a joy. But I never did any x86. I'd like to help but my basic knowledge is lacking. I had a look at what is involved and came unstuck almost immediately. Thank goodness for online help.
I started at
        .debug%
        pushad
        sub esp,1024-4
Pushad -  "Pushes the contents of the general-purpose registers onto the stack"  Ok, I can do that.
sub esp  - "To allow for many unknowns in the execution environment, functions are frequently set up with a "stack frame"
I've never heard of this so now I need to study this in some depth!

So while it is reasonably straightforward to write some assembler to achieve something one understands it is another matter to understand some other code first. It would be good to study it and learn it and I feel it is do-able but it would take me far too long.
Sorry Richard, you deserve much better support.
 

Richard Russell
 

On Mon, Jul 31, 2017 at 07:24 am, Paul Marshall wrote:
sub esp  - "To allow for many unknowns in the execution environment, functions are frequently set up with a "stack frame"
I expect I just wanted 1 Kbyte of temporary 'scratch' memory to be available to the code, so allocating it on the stack is a simple approach (reduce the stack pointer by that amount on entry and increase it again on exit).   It's normal for a compiled language like C to allocate space for 'local' variables in that way, so I would have expected there to be a direct equivalent in ARM assembly language.  Google suggests 'sub sp,sp,#1024-4' and the BBCSDL assembler accepts that, but what do I know?

Richard.

Richard Russell
 

On Mon, Jul 31, 2017 at 07:24 am, Paul Marshall wrote:
it is another matter to understand some other code first. It would be good to study it and learn it and I feel it is do-able but it would take me far too long.
Further to my previous reply, could you not - even if it's rather unsatisfying - simply translate the individual instructions without actually understanding what they do in the program?  The end result might not work first time but I'm prepared to tweak your ARM code if necessary; as has been stated in this thread modifying existing code is much easier than writing code from scratch.  Even though I'm not very familiar with the ARM instruction set I reckon the mnemonics are sufficiently self-explanatory that I should be able to make minor changes.

Richard.

 

On Mon, 31 Jul 2017, at 16:52, Richard Russell wrote:
On Mon, Jul 31, 2017 at 07:24 am, Paul Marshall wrote:


it is another matter to understand some other code first. It would be good
to study it and learn it and I feel it is do-able but it would take me far
too long.
Further to my previous reply, could you not - even if it's rather
unsatisfying - simply translate the individual instructions without
actually understanding what they do in the program?x
Isn't one of the problems here that there's fairly few (or was, maybe
that's
not true now) ARM instructions and lots of x86 ones? Also things like
the
ARM ones allowing (IIRC) shifts to be applied to operands, and also
conditional execution of individual instructions in a stream of
instructions
without branching?

And what if eg the available processor flags are different, or work in
different
ways?

Surely whoever does this needs to understand both machine architectures,
memory management, whether stacks are part of that and so on?

Something like 30 years ago I did read an ARM assembler manual, and was
struck by just how different that language was from the one I knew
(S/370
so no surprises there). I also dipped into an x86 one even longer ago,
where
the instructions (in particular modes of addressing) were again very
different.
I suspect the x86 processors have come on a long way since then though.
--
Jeremy Nicoll - my opinions are my own.

Richard Russell
 

On Mon, Jul 31, 2017 at 09:20 am, Jeremy Nicoll wrote:
Isn't one of the problems here that there's fairly few (or was, maybe
that's not true now) ARM instructions and lots of x86 ones?
No it isn't.  It's irrelevant how 'many' different instructions each architecture has, what matters is whether the small subset of x86 instructions used in 'sdldebug.bbc' have direct or close ARM equivalents.  I've no reason to think they don't.

> And what if eg the available processor flags are different, or work in
> different ways?

As I said, I'm not necessarily expecting the code to work perfectly first time.  As you have implied yourself, it is often possible to understand code written in an unfamiliar language even if you would not be able to write it yourself.  I'm perfectly prepared to make the sort of minor tweaks to the ARM code that might end up being necessary as a result of 'second order' effects such as this.

> Surely whoever does this needs to understand both machine architectures,
> memory management, whether stacks are part of that and so on?

Machine architectures?  There are no significant 'architectural' differences between x86 and ARM-based machines.  Memory management?  Not relevant to the code in 'sdldebug.bbc' (and anyway memory management is an OS issue rather than a CPU issue, and the Raspberry Pi runs Linux!) .  Stacks?  They work the same on x86 and ARM CPUs (growing downwards, usually).

Your negative attitude risks putting off anybody who might have been tempted to help (maybe that is your objective).  I'm fed up with it.

Richard.

Previous Topic Next Topic