Beginner programming enthusiast, want to learn BASIC/write programs for RISC OS

Hello,

I’m pretty new to programming. I at least have a grasp of basic programming concepts (variables, arrays, loops, mathematical operators, etc) but I still don’t know much. I want to learn to program on RISC OS.
Can you recommends books/online resources/etc that would be good for a beginner?
And any other advice on how to learn would be appreciated as well.

I’m very fond of Acorn computers and RISC OS. My family had an A3010 when I was young (around 6 years old), and it was the only computer we had for about 4 years until we got a PC in ’98. I always wanted to get into programming but it never really happened.

I recently got a Raspberry Pi and RISC OS on an SD card, and I’m excited about RISC OS again. I’ve already bought three books:
“Raspberry Pi RISC OS System Programming Revealed”, “Raspberry Pi Assembly Language RISC OS Beginners (Hands On Guide)”, and “Basic V for the Acorn Archimedes”.
These seem like good books, but they also seem like they’re not exactly meant for beginners.

My current level of programming experience/ability is writing simple bash/shell scripts for Linux. I can post an example of something I’ve written if anyone wants.

There are a couple of guides on the Pi SD card in the Documents.Books directory. “First Steps in Programming RISC OS Computers” is probably the most useful.

http://www.riscos.fr/decouvrez.html
This web page is in French, but there are links to many books in English.

There are also more resources for BBC Basic on http://www.bbcbasic.co.uk/bbcbasic.html

to programming for the wimp in ARM Assembly.

Use C if you want more speed than BASIC offers. It is useful to have a knowledge of assembly to write your own veneers to things to use from C, but writing an entire wimp application in assembler is madness.
That we have fully 32 bit compatible versions of Ovation and OvationPro, but still no properly 32 bit version of Impression is all you need to know about that argument…

Indeed; the Style Guide says something to the effect of “we strongly recommend that you use C; the resulting apps will be far easier to maintain than ones written in assembler”.

If I had unlimited time then I’d write some C Wimp tutorials based on what I’ve learned so far. I could even do a “C# to RISC OS C” guide, since that’s the path that I’ve ended up taking!

I have to say, references to other languages, whilst in your opinions may be better, BBC BASIC was specified, and such comments are very unhelpful… I do understand that people have preferences, however if I ask for a question stating I am using BASIC, and someone points me to python, C, Java, or anything else, I am unable to progress.

The overheads of having to diagnose faults in programming is overwhelming in C, and I know loads who have simply given up as they were told that “C is better”.

If you are looking at programming in BBC BASIC, I would like to recommend the Strong help manuals for use after reading tutorials, Reporter to aid with debugging (Essential!), and Basalt and it’s Manual for when limitations of BASIC creep in (Dynamic Arrays, Strings longer than 256 chars, Object Oriented Programming, Simple WIMP Control through Toolbox).

After that I would suggest assembler, and then C.

I still program in BASIC because, for the most part, it’s fun for me.

That we have fully 32 bit compatible versions of Ovation and OvationPro, but still no properly 32 bit version of Impression is all you need to know about that argument…

Sadly there is more to it than ‘just 32 bitting’ Impression. A lot of restoration work is sadly needed to even get back to the point it was! (Point for another thread I feel :) )

One thing I would say, is there is a lot of help if you are polite enough for any language! :)

The overheads of having to diagnose faults in programming is overwhelming in C,

C, at least, offers a syntaxically valid program after a compile. It may still contain a thousand bugs but that is true of any language.
BASIC? You might not encounter the problem until you hit the offending line.

as they were told that “C is better”.

Depends what they want to do. For things that involve a lot of number crunching (image editor, for example), C will win every time.
For simpler applications that spend most of the time waiting for the user to click something, BASIC is fine.

I have to say, references to other languages, whilst in your opinions may be better, BBC BASIC was specified, and such comments are very unhelpful…

If someone is asking for help getting into programming on RISC OS, it’s not unreasonable to point out that there might be other – perhaps better – options than BASIC.

The overheads of having to diagnose faults in programming is overwhelming in C

How so? Quite aside from the point Rick makes about a C compiler performing a full compilation on your code before anything gets executed, how is debugging C on RISC OS any worse than debugging BASIC?

After that I would suggest assembler […]

Just… No.

If someone is asking for help getting into programming on RISC OS, it’s not unreasonable to point out that there might be other – perhaps better – options than BASIC.

Whilst I agree with everything else you say learning BBC BASIC on RISC OS is never wasted even if you switch to another language later. So it’s a good place to start if you know nothing else. Assessing which language to use when you first start is impossible.

If you want BASIC with WIMP then I recommend DR Wimp

http://www.rayfavre.me.uk/drwimp.html

I’ve been tinkering with BBC BASIC for nearly 30 years!

(There’s really not many of us left, though…)

BBC BASIC was specified

I must’ve been getting sleepy; I thought I’d seen BASIC specified, and did a quick skim through the original post before making my comments, but didn’t see it mentioned (other than “basic programming concepts”, which is the generic term rather than the language). Apparently I didn’t look in the subject line :)

If you want BASIC with WIMP then I recommend DR Wimp.

I’m not familiar with Dr Wimp¹ but I’d echo that recommendation. The alternative, and something we of a certain age did a lot of back in the earlier days, was to write our own Wimp code. This basically involves setting up a load of obscure values in memory blocks and throwing them at various Wimp SWIs.
That was how we rolled in 1992, and even magazine listings gave huge swathes of block%!this = block%!that.
It ain’t the nineties no more. Do yourself a favour. Use a library. This one comes recommended by many.
http://www.rayfavre.me.uk/drwimp.html

¹ I have my own library based upon the one in “WimpEd”, built up over many years of writing rubbish. ;-)

not that obscure. Just set up the window structure in a buffer, and use "SYS “CreateWindow,…”, etc, similar for menus, etc.

The most convoluted part is the poll loop, and that is still fairly simple to deal with (and is what allows for cooperative multitasking).

Superficially true, but there are a lot of subtle things that a good library will quietly do to make your code more robust which are a lot of work to implement if you roll your own each time. Sanity checking of icon flags before manipulating indirected data and bounds checking of buffers are two that spring to mind immediately.

Old software is often riddled with such ‘features’ – try loading a file with a name longer than 10 characters into Ovation and watch it trash its window templates, for example. I’d expect modern code to verify that target icons were actually indirected text, then truncate the supplied string to fit the stated buffer size before any attempt to write the data took place.

As has been said already, this is 2016 and not 1987. :-)

BASIC? You might not encounter the problem until you hit the offending line.

You could always test it using the RISCBasic compiler. Although StrongARM aware, it is 26 bit so would need Aemulor or VRPC. It is syntactically identical to the BASIC Interpreter so does a useful syntax check and has good error reporting.

Assuming one has RISCBasic…

try loading a file with a name longer than 10 characters into Ovation and watch it trash its window templates,

Um… guys? You know my email address for bug reports. ;-)

not that obscure. Just set up the window structure in a buffer

…

I did a self contained BASIC program as an academic exercise. Without comments, the window creation code would be incomprehensible gibberish.
http://www.heyrick.co.uk/blog/index.php?diary=20151226
It’s about halfway down the page. You can’t miss it.

Without comments, the window creation code would be incomprehensible gibberish.

You chose to write it that way – you didn’t have to. You can write jibberish with any language/library

Whilst agreeing with the insanity of defining windows that way, I see you are perpetrating some poor BASIC methods that have nothing to do with the point you are trying to make. As this topic is for a beginner I want to quash them. ;-)

HIMEM = ((32+23) * 1024) : REM Set Himem to 32K (base) plus 23K
SYS "Wimp_SlotSize", (24 * 1024), -1 : REM Set slot to 24K

Let BASIC do this with END=(32+24) * 1024 unless you are thinking of setting up a heap above HIMEM.

DIM wimp% 400 does not reserve 400 bytes, but 404. Use DIM wimp% 399

There is no need to set up and use Wimp_ReportError to get an error window, just:

ERROR EXT ERR,STR$(ERR)+" "+REPORT$+" at line "+STR$(ERL)

Nor do you need Wimp_CloseDown in BASIC, although it makes a good pair with Wimp_Initialise.

Sorry.

Assuming one has RISCBasic…

If I recall correctly RISCBasic has limitations so I presume you would also have to assume that you were not utilising some feature of BASIC that is not supported by RISCBasic.

Nothing is perfect.

Colin:

You chose to write it that way – you didn’t have to.

What would you suggest? While you can do something akin to named constants in BASIC, they will appear as “just another variable” and as such will take space. Standard BASIC does not do structures. So ultimately you are going to end up poking values into memory locations. The question is, how nicely do you want it to be done?

ELSE
  wimp%!64=sprflag%
  icons%=wimp%!84
  IF icons%>0 THEN
    ic%=wimp%+((L%-1)*32)+88
    ind%=((ic%!16)>>8) AND 1
    spr%=((ic%!16)>>1) AND 1
    txt%=(ic%!16) AND 1
    IF ind%=1 AND spr%=1 AND txt%=0 THEN
      IF (ic%!28)<>0 ic%!24=sprflag%
    ENDIF
  NEXT L%
ENDIF

That’s from DrWimp. A random location in the DrWimp library (I just dragged the scrollbar and stopped in an arbitrary place). Reading it as I was typing in out on the PC, I’m guessing it is to do with loading templates and working out indirected stuff for icons? At any rate, it amply demonstrates the issue of “peeking and poking obscure stuff in memory blocks”.

Steve:

Let BASIC do this with END=(32+24) * 1024 unless you are thinking of setting up a heap above HIMEM.

Thanks. I realised END could do it in one go just after I published it to my blog. It isn’t a big deal, the “desktop app” version that followed the next day threw this away and uses WimpSlot in the !Run file to do the memory reservation.

DIM wimp% 400 does not reserve 400 bytes, but 404. Use DIM wimp% 399

Noted and corrected on the following day’s program. :-)

There is no need to set up and use Wimp_ReportError to get an error window, just:
ERROR EXT ERR,STR$(ERR)+" "+REPORT$+" at line "+STR$(ERL)

It is good practice to use the proper SWI because…

*BASIC
ARM BBC BASIC V (C) Acorn 1989

Starting with 4190460 bytes free

>ERROR EXT 123,"Bye bye!"
Bye bye!
*

Note the *. BASIC has reported the error and then quit. Little tricks like that may come in handy at times when they are needed, but should not be explained to newbies too early. What if the person wanted to report the error and then tidy up, close files, etc etc – only to find out that the error is reported but stuff isn’t being tidied up?
[this is described in more detail in the BASIC user guide – p172 in the copy I’m looking at; the online help makes no mention of the fact that BASIC would quit]

Nor do you need Wimp_CloseDown in BASIC,

Ugh. That is just poor practice. You are relying on the fact that the Wimp will notice your task calling OS_Exit to quit, and will implicitly call Wimp_CloseDown for you. Multitasking programs, irrespective of their language, should shut themselves down correctly.

References:

• No mention of Wimp_CloseDown in the BBC BASIC manual (PDF).
• The tiny example program on page 6 of PRM3, written in BASIC, calls Wimp_CloseDown.
• The first bullet point item in the description of Service_WimpCloseDown in PRM3.
• “This call must be made immediately before the task terminates by calling OS_Exit.” in the description of the Wimp_CloseDown SWI in PRM3. No mention of “except for programs written in BASIC” or the like…
• “If a program ‘accidentally’ calls OS_Exit before calling Wimp_CloseDown, the Wimp will perform the latter action for it” in the description of Message_TaskCloseDown in PRM3. Note the sarcastic single quotes around the word accidentally.

You are correct in that you do not need to Wimp_CloseDown. But you should.

Without comments, the window creation code would be incomprehensible gibberish.

Why on earth create a window that way?

a) You’re trying to give BASIC a bad name that it doesn’t deserve.

b) You’re insane.

c) … Any more suggestions?

Use a template editor.

What would you suggest? While you can do something akin to named constants in BASIC, they will appear as “just another variable” and as such will take space.

So what? You/DrWimp made a choice to make the code unreadable. You could have given the numbers meaningful names using the tools available in basic (variables) but you couldn’t bear the thought that it may a) use space or b) slow the program down. As you have discovered going through DrWimp there is a price to pay for making your code unreadable ie it’s difficult to maintain/understand. You don’t use meaningful names in compiled language because their use is free you use them to make your code understandable and just because an interpreted language has an overhead for readability it isn’t a reason to make it unreadable.

Note the *. BASIC has reported the error and then quit.

The context was a wimp program, or it could have been any program run from a file, not in the command line. Who could write a wimp program at the command line? ;-)

What if the person wanted to report the error and then tidy up, close files, etc

The error line I quoted was to be a substitute for the calling of Wimp_ReportError within your error procedure, not on its own.

You are correct in that you do not need to Wimp_CloseDown. But you should.

I thought I implied that. However, a BASIC program does not have to call OS_Exit itself, so the ‘accidental’ action happens. It is documented and reliable.