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

Dave:

Why on earth create a window that way?

I’m guessing you looked at the code and didn’t bother reading the article itself?

It was referring to a friend’s comment about a single self-contained program written in BBC micro style (INPUT, GET, PRINT, etc) and how such a thing could be translated into a RISC OS application.
It is an academic exercise to demonstrate how a single completely self-contained BASIC program can exist, and also to demonstrate quite clearly why this is a really bad idea – the article continually states that this is not how programs should be written. The very following day, the program is modified into the familiar RISC OS application style, and gleefully demonstrates replacing all of that rubbish with a couple of SWI calls to open the template, load the window, then close the template.
This is a case of “learn not to from experience”.

I’ll give you point b though. I’ve never argued that. ;-)

Colin:

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

Basically because while there are fast processors and lots of memory available today, anybody who wrote code back in the days of a mere megabyte on an 8MHz processor would have not wanted to make their programs larger and slower than they had to be.

Plus, because BASIC does not have structures so you can’t give offsets meaningful names unless you want to have a bunch of additional variables. Even then, it isn’t quite the same as what C and Pascal programmers would understand a structure to look like.

https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Apps/Alarm/bas/Main?rev=1.6#l683
https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Apps/Chars/bas/!RunImage?rev=1.2#l271

Here’s one that does, creating some three dozen variables to make things easier to read:
https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Apps/Maestro/bas/!RunImage?rev=1.5#l3226
and you can see that used here, for example:
https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Apps/Maestro/bas/!RunImage?rev=1.5#l526

Whether or not DrWimp is hard to read is irrelevant. The point of using a library is so we don’t have to read such stuff. We just call the routines for the things we want done.

Steve:

However, a BASIC program does not have to call OS_Exit itself,

Of course not. END does that for you¹, in much the same sense that WAIT means you don’t have to call OS_Byte 19, and GET means you don’t have to call OS_ReadC, etc etc.

¹ You don’t have to call OS_Exit in a C program either. The runtime does that following tidy-up after you exit() or return #; (# = a number to pass on to Sys$ReturnCode) from the main() function.

I personally feel that at some point a person should learn to do windows the hard way, so that they can make modifications as needed after loading a template, though before calling ‘Wimp_CreateWindow’.

Yes I do exactly that. Load a template that was based on one of the original apps back in 1988 and then tweak it in BASIC (adding various pokes to add icons or whatever so that I know where they are and can give them a variable name) for each window I want. I simply found that easier than trying to use the template editor.

Load a template that was based on one of the original apps back in 1988 and then tweak it in BASIC (adding various pokes to add icons or whatever so that I know where they are and can give them a variable name) for each window I want. I simply found that easier than trying to use the template editor.

I suspect that we probably don’t want to be telling newcomers that this is the way things are done on RISC OS, however. It would be good if some of them stuck around long enough to actually develop some software before we scare them off…

It would be good if some of them stuck around long enough to actually develop some software before we scare them off…

Aren’t they supposed to run screaming when we say “POSIX? Wassat?”? ;-)

END does that for you

That prompts a query.

There are several ways a BASIC program can finish: END, QUIT, STOP, the end of the last statement, an untrappable error zero. Can anyone think of others?

I was simplifying when I said END does it. It is BASIC quitting that does it, and END does that when run as -quit as it would be for a task.

Though for normal programming it is usually better and easier to use a template. It is to bad that there are no Menu templates, thankfully the menu block is super simple.

Agreed. On the topic of code for wimp programs being readable, I would be grateful for comments about the examples given here . Is it clear from the code what these three trivial examples do?

It is to bad that there are no Menu templates, thankfully the menu block is super simple.

I suspect many people have rolled their own versions, however.

All of my software uses a simple data file which is loaded into memory with OS_File 16 (or equivalent) and then has the submenus and dialogue boxes within it linked together. Rather like Templates, the file contains sections for the menu definitions, indirected text data and validation strings. The menus are defined in a text file, which is handy for revision control, and get turned into the binary data files by a command-line tool called MenuGen.

Had I realised when I wrote it that Template files were extensible, I might have looked into adding the data to those instead (although in the days of Acorn, I doubt there would have been interest).

If anyone’s interested, you can find a version of the software amongst the build tools on my website. The file format has evolved over the years, and there’s an unreleased version that has support for embedding menu names into the file to avoid the need to locate menu handles via their position in the definition file. Unfortunately the load routines in my BASIC library don’t handle named menus or dialogue boxes; the ones in my published C library do handle named dialogue boxes but, as with MenuGen, the updates to extract menu handles by name haven’t been published yet either.

If I recall correctly RISCBasic has limitations

It does have some limitations but they are few: EVAL cannot be compiled, var%+=2 needs var% defined to (zero) beforehand (as would an undefined variable as a procedure parameter, including with a RETURN prefix), !mem% requires mem% word aligned, DATA statements cannot include variables. Not many really.

ABC has a colossal list of exceptions, syntax differences and limitations.

ABC has a colossal list of exceptions, syntax differences and limitations.

Absolutely :)

Hi again,
Thanks for the replies and suggestions, I appreciate it.

I’ve been reading the “First Steps” guide, testing and trying things out. I’ve encountered a situation where something doesn’t work and I’ve got no idea what’s wrong with it.

   10ON ERROR REPORT:PRINT " line ";ERL:END
   20
   30DIM pitch%(64)
   40FOR z%=1 TO 64: READ pitch%(z%):NEXT
   50
   60DEF PROCzplay(px%,tx%)
   70SOUND 1,-15,pitch%(px%),10,tx%
   80ENDPROC
   90
  100BEATS 100
  110REPEAT UNTIL BEAT=0
  120
  130
  140
  150PROCzplay(14,0)
  160PROCzplay(16,10)
  170PROCzplay(18,20)
  180PROCzplay(19,30)
  190PROCzplay(21,40)
  200PROCzplay(23,50)
  210PROCzplay(25,60)
  220PROCzplay(26,70)
  230
  240DATA 001,005,009,013,017,021,025,029,033,037,041,045,049,053,057
  250DATA 061,065,069,073,077,081,085,089,093,097,101,105,109,113,117
  260DATA 121,125,129,133,137,141,145,149,153,157,161,165,169,173,177
  270DATA 181,185,189,193,197,201,205,209,213,217,221,225,229,233,237
  280DATA 241,245,249,253
  290
  300

This fails with error “unknown or missing variable at line 70”. I’ve checked it over and I can’t seem to understand why it doesn’t work, so I thought I’d ask everyone here, what’s the problem here?

Edit: seems like this forum doesn’t have code tags,

You mean like < pre > < /pre> ?

Or < code > < / code >

When you’re logged in and replying there’s a nice helpful “Textile reference here” link at the bottom…

Ok, thanks. I didn’t notice that somehow.

what’s the problem here?

Well one problem is that you have a procedure definition before the END statement -
because there appears to be no END statement. I think that may be what has thrown the BASIC interpreter. Try inserting “310END” and renumbering lines 60,70,80 to 360,370,380.

@Gavin
Thanks, now it seems to work.
So then, procedure definitions must always come after the END statement, right?

The END statement, it is true, is not always required.

PRINT "ok"

DEF PROCA
ENDPROC

So then, procedure definitions must always come after the END statement, right?

That is by far the wisest policy, because it prevents your program running through into the definitions, but it is not strictly true.

As DavidS points out, you can GOTO around a definition, although we generally frown on GOTO, don’t we? ;-)

Another case is a definition that fits on a single line. BASIC ignores lines starting with DEF in normal execution.

you might find this of interest.

An interesting comparison.

There are a few mistakes about BASIC, mostly minor, but a couple more important. This might give Lua a more rosy outlook. ;-)

a few mistakes about BASIC

Let me know. I will be glad to correct them. Most readers will be more familiar with BASIC than Lua, and I wanted to teaze out those bits where the apparent similarities concealed hidden dangers.

Thanks again for the help, everyone. I’ve been reading through the ‘first steps in programming risc os computers’ book the past weeks, and I’ve just finished writing a program. (there’s a few bugs to fix, but I think it’s pretty much finished)
It’s a simple music editor/player which plays tunes using the SOUND command.
I thought I’d post it here just in case anyone would find it interesting.

Zip archive:
http://dusthillguy.ddns.net/folder/funmusic.zip

A suggestion: please use the ZIP format to archive anything RISC OS. It is more compact than Arc, it is supported by the nice read-only SparkFS, and you can create it with freely available tools like ZipEE. And it is cross-platform, so can be unarchived/looked-at on other plattforms (although extracting it loses the filetypes, it is still useful to have a peek at the ReadMe or other docs).

Another suggestion, rename the “ReadMe” file to !Help so it appears in the menu under “Help” :)

Thanks for the suggestions. I used arcfs because that’s all I had, now I know about ZipEE I’ll use that from now on, and I’ve now replaced the arcfs link with a zip one.
It’s good to know about the Help menu option thing too, I wasn’t aware of that.

how is debugging C on RISC OS any worse than debugging BASIC?

If you have reached the debugging stage writing C, then you have also learned the hardest part, the C compiler. It is learning the toolchain required to write C that makes interpreted languages, like Basic, better for the budding enthusiast. The four thousand pages of instruction included with RiscOS is the real treasure but, wading through it can be daunting.

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.

Very True. Despite some minor text errors, this could be your best START.

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.

I believe you’ll progress most quickly with Basic. It is after all the Beginners All purpose Symbolic Instructional Code.

BBC Basic is so flexible that you may never outgrow it. Once you reach the level of programming professionally, come back to this post and glean the value of the other suggested avenues.

By and By, Python is another interpretted language that is new comer friendly. Not the fastest but, well documented and current.

I would never recommend C on RISC OS unti would never recommend C on RISC OS until you have a firm foot in writing ARM assembly for RISC OS.

As someone who learned C programming on a Risc PC, I have to say that I disagree with this. By all means, do acquire a knowledge of ARM assembly, but – in my opinion – you don’t have to worry about it being a prerequisite to starting C. That said, BASIC is more BASIC than C, and is probably easier to get started with.