!Munchy A clone of a classic maze game

Removed DIM LOCAL as earlier versions of BASIC do not support it.

Surely the onus is on the end user to be running the latest (or at least a reasonably recent) stable version of RISC OS (which would be 5.something), rather than you and other developers having to accommodate those who, for some (perhaps unfathomable) reason, insist on using a decades-old version of RISC OS & BASIC?

DIM LOCAL is very nice and useful, and I’ve made use of it in my latest project unapologetically and without hesitation. That it won’t work on ancient versions of ARM BBC BASIC is just too bad, isn’t it?

in the same size environment

If you’re implying that they had to kick Sassoon out of ROM because they needed the space…

…one itty bitty flaw with that. It’s not a ROM font. It’s in !Boot.Resources.!Fonts, where it’s been since the dawn of time (and still is).

So do I change all the fonts used to Trinity or can I include the Sassoon font in my zip file? and then people could install if needed?.

Neither. You write your font handling properly – you can ONLY rely upon the presence of Trinity, Homerton, and Corpus (the three ROM fonts). Other fonts should be supplied with the machine (Sassoon, WimpSymbol, Selwyn…) but as appears to be the case, this isn’t guaranteed.

So what you need to do is design your game’s screens to look correct for Sassoon, as it ought to be available and you felt that it was the best look. Don’t bastardise your vision for a version of the OS that decided to do something different.

I’ve not looked at your code, but I’m guessing the bit that’s crashing is something like:

SYS "Font_FindFont",, "Sassoon.Primary", size%, size%, 0, 0 TO handle%

Change this to:

SYS "XFont_FindFont",, "Sassoon.Primary", size%, size%, 0, 0 TO handle% ; f%
IF (f% AND 1) THEN
  SYS "XFont_FindFont",, "Trinity.Medium", size%, size%, 0, 0 TO handle% ; f%
  IF (f% AND 1) THEN ERROR 17, "Oh FFS!" : REM Or a message a little more helpful ;-)
ENDIF

If this case, if Sassoon cannot be found, it will fall back to Trinity. If Trinity can’t be found…it probably isn’t a real RISC OS machine!

Set up your layout for Sassoon, use Sassoon. If it looks rubbish on Trinity, that’s their problem, not everybody else’s…

The golden rule for OS calls in BASIC is to call the X form of SWIs and handle errors as they get reported back from the OS. BASIC’s centralised ON ERROR (LOCAL) handling is useful for when in the BASIC realm (OPENIN, BPUT#, etc etc) but if you’re using OS calls (OS_Find, OS_GBPB, etc etc) then you can trap errors more finely without skipping a beat.

Until later versions are generally used, developers will be restricted,

Which needs the impetus of people adding the following into their !Run files:

RMEnsure BASIC 1.81 Error Sorry, the version of BASIC on this machine is too old. Please update to at least version 1.81.

But, as has been noted before, numerous times (especially in “justification” for continued use of StubsG), there is resistance to expecting users of quarter century old machines to update anything.

Surely the onus is on the end user […] rather than you and other developers having to accommodate those who […] insist on using a decades-old version of RISC OS & BASIC?

You’d have thought, wouldn’t you?

It’s not as if newer versions of the core modules are not available and they’re stuck with their ancient versions.

Latest version runs nicely on my Risc PC, OS 4.39 BASIC V 1.29. Intro is a bit clumpy compared to the BB -xM but the play is smooth. Sassoon already installed but being in a separate font dir, I must have added that.

Hmm. Having added the same fonts to my newer machines, I must have two copies of some if the likes of Sassoon are now standard. Time for a tidy up.

Just Sassoon & Porterhouse duplicated.

It’s not as if newer versions of the core modules are not available and they’re stuck with their ancient versions.

But that destroys the Purity Of the OS. ;)

Reasons for people on the Castle fork utilising, mostly, the Castle supplied bits = known to work on 32bit systems¹.
Reasons for not using the Castle supplied bits on the other fork = unknown, but I jokingly label it as “Purity”

Set up your layout for Sassoon, use Sassoon. If it looks rubbish on Trinity, that’s their problem, not everybody else’s…

In a serious vein (there’s a first for the day) perhaps there’s a similar font that replaces Sassoon in 4.3x

¹ Sadly, as we’ve all seen, Gerph wasn’t responsible for everything “over there” and some of it was done in a bit of a half-assed way

@Rick

Thanks for the information I have made the program default to trinity if it cant find Sassoon font.

Should have stuck with single tasking :-)

Should have stuck with single tasking :-)

Which… makes a font magically appear? Cool! ;-)

;-) no but you can just create your own bitmap fonts and use those.
Oh well as they say I’m learning all the time, this was supposed to be a distraction from real work.
It did show up some differences that I have never come across before so some good has come out of it.

However, I do not think it is freely available, and it is not listed in the ROOL Store except as part of the DDE.

That’s wrong.

DDE30 → Documents → Manuals → ABC, Asm, C/C++, DesktopTools, Index, PRM1-PRM5a, Style, Toolbox (all PDF).
(DDE28 and DDE29 have the same list of files)

No BASIC reference.

My BBC BASIC manual…looks like it came from the corn field. It’s a scan of issue 1 from October 1992. Recent in RISC OS terms, I know, but still!

Edit: I don’t see any mention of it in the DDE page. Are you possibly mixing it up with ABC?

Re DDE30 & BASIC manual – you are correct, and my memory faulty. It is not in the DDE.

I do have paper copies of the original BBC BASIC Guide, and the recent BBC BASIC Reference Manual Issue 2 (of which I do have late pdf draft, as I helped proofread it). It is a shame that currently it does not seem to be available in any form.

Surely the onus is on the end user to be running the latest (or at least a reasonably recent) stable version of RISC OS

RISC OS 4.39 (28-Apr-2004) comes with BASIC 1.29 (8-Jan-2004) and it is very stable – nothing has changed since 16 years ago. It is the latest version of Virtual Risc PC Adjust.

RISC OS 4.39 (28-Apr-2004) comes with BASIC 1.29 (8-Jan-2004) and it is very stable

The problem here is that BASIC 1.29 doesn’t contain the constructs in the more recent BASICs on RISC OS 5, and if those are what programmers need, then it won’t be of any use.

The lack of DIM LOCAL is a particular problem, because the ability to claim and free memory off the stack solves a lot of issues when doing things like Wimp programming. Yes, there are work-arounds – but they’re a lot less pleasant for anyone who is familiar with DIM LOCAL-like functionality in other languages.

As Rick Suggested I don’t think it’s unreasonable to include this in future programs

RMEnsure BASIC 1.81 Error Sorry, the version of BASIC on this machine is too old. Please update to at least version 1.81.

Especially as Martin suggested that a newer version of BASIC can be loaded at boot time
then if someone wants to run an older version of RISCOS then they can but at least the BASIC
can be at a known level?.

As Steve says the lack of DIM LOCAL is a big loss when using BASIC.

I can see that in the future there might be system calls that only
exists in RO5 that any language might use, keeping track of these is not going to be easy.

Something like RiscPCB which is written in C because its a much bigger application and it makes sense to
use C in this case. If I come across a system call that only exists in RO5 but does something really useful
I am probably going to use it.

I understand the need for backwards compatibility and fully support it as much as possible but at some point
we have to go forward.

I realise that money is tight for some people but with things like the PI400 which I purchased for testing
and was about £60 it allows a cheaper way into more modern hardware than ever before.

Things that do not evolve die!

RISCOS has few developers and I would expect most of those to be using RO5
its not my intention to start a war just my personal opinion :-)

RISC OS 4.39 (28-Apr-2004) comes with BASIC 1.29 (8-Jan-2004) and it is very stable – nothing has changed since 16 years ago.

Well Windows XP is a stable release as is 3.11 and so is Arthur as well :-)

I realise it is a fine balancing act but you have to give some incentive for people to upgrade both software and hardware.

Where a component has improvement/advantages and is available to use then why not make that a pre-requisite and offer links on where to get it.

It helps developers who have to maintain their code and it helps the remaining base to see the benefits as well.

Anyway as Terry says lets not go over the past again.

It is a shame that currently [the BBC BASIC Manual] does not seem to be available in any form.

On the dark side:

BBC BASIC Reference Manual online

;-)

As Steve says the lack of DIM LOCAL is a big loss when using BASIC.

That surprises me. Despite having written a substitute I only ever use DIM stack% LOCAL -1 to get the stack pointer.

There are lots of other ways to use a block of memory temporarily, but for a local block you could try:

This trick can be implemented in BASIC only, but it is a bit complicated.

`=END+8:DIM`(0):REM first create pointer to dummy array
PROCtest_local
END
DEFPROCtest_local
 LOCAL block%,`():REM make block pointer and dummy array local
 DIM `(29/5):REM create local array of sufficient size
 block%=!`+12:REM point to memory after array header
ENDPROC

On the dark side:

But be very aware that seems to refer to BASIC v1.05 which is from RO3.10 days – much older even than the v1.29 in RO4.39. Also few/none of the links within a page seem to work. I would class that documentation to be so old it is dangerous – especially to newcomers!

or a local block you could try:

I could, but I prefer my code to be more easily readable – DIM block% LOCAL len is obvious.

Removed DIM LOCAL as earlier versions of BASIC do not support it

Instead of using DIM LOCAL, use:

DEF PROCneeds_local_array
LOCAL myarray$(), myblock%
DIM myarray$(5)
DIM myblock% 4096
ENDPROC

This trick can be implemented in BASIC only, but it is a bit complicated.

Not sure I can agree with using hacks and side effects in order to support those who don’t wish to upgrade to an available version of BASIC that can do it properly…

so is Arthur as well :-)

Only so long as you turned it on and didn’t actually do anything. :-)
[it’s remarkably easy to get the desktop demo to crash out]

but you have to give some incentive for people to upgrade both software and hardware.

I don’t see it as incentive so much as necessity. It’s remarkably easy (and cheap) to upgrade to a Pi based system, especially if you do what I’ve done and use salvaged hardware (monitor, mouse…). It would probably pay for itself in a year due to the difference in power consumption compared to a big box.

Thus, those who don’t wish to upgrade to something newer, including installing more recent available modules on their existing system, clearly have other reasons. Perhaps, as Steve suggests, “purity”?
That’s fine, it’s their choice.
But this should not be a noose around the necks of programmers developing software today. It’s not a case of “you don’t deserve our software” (as Andrew tried to put it in the StubsG topic), it’s quite simply “your system is too damn old”.
Companies writing software for other platforms aren’t held back supporting prehistoric hardware. Some stuff still works on XP, but that’s more luck than design these days. A lot of things don’t support Vista, never mind XP. And that was arguably the world’s most popular operating system at one time.

If I come across a system call that only exists in RO5 but does something really useful I am probably going to use it.

Exactly. I don’t go out of my way to not support pre-RO5 machines, but then again I am not going out of my way to support them.

but at some point we have to go forward.

The thing is, the Iyonix was released in October 2002. That means that RISC OS 5 has been around for nearly twenty years. It’s not some “new fangled rubbish”. The Pi itself is nearly nine years old. The last release of the other version of RISC OS was something like eleven years ago.

Those timescales are contemporary with Windows 7, a few years after the end of mainstream support for XP, and just before the end of mainstream support of Vista.

“At the end of the day” “when all is said and done” and something about a singing overweight chick… it is a decision for each developer, which may be influenced by who the target market is.

But, I have just one question. If we’re expected to continue actively supporting decades old machines and their operating systems… then exactly what’s the point in bothering to further develop the current versions?

People are, generally, quite happy to consign RISC OS 3.1x and the ARM2/ARM2 era to history.
It’s about time we do the same for the RiscPC era (which is only about three years younger than the A5000!).

Instead of using DIM LOCAL, use:

Sorry, but I think that does NOT free the block of storage when the PROC ends. It is still allocated in the variable space, even though the myblock% variable itself is LOCAL. If you have my Reporter, just add a *ReportMem before and after the PROC call and it becomes obvious.

It’s about time we do the same for the RiscPC era (which is only about three years younger than the A5000!).

Not before we will have a complete, fast and stable RPC emulator for RISC OS 5.

Of course my system is not old – it is a recent shuttle PC from R-Comp with VRPC with a current fast processor. The only emulation for a PC is VRPC. I don’t know if there is an updated BASIC for RISC OS 4.39. I think not.

The only emulation for a PC is VRPC

I think you might be a little inaccurate with that statement – there’s this site that offers an emulation of a RISC PC for starters. It even has pre-built bundles, one of those bundles is based on the RO Direct build which as you know has a modern version of BASIC.

I don’t know if there is an updated BASIC for RISC OS 4.39. I think not.

Please can you read my post

I have used BASIC v1.81 to run Organizer on RO4.39 on VRPC – and that is a pretty large BASIC program!

On VRPC,s Windows side there is a Directory where you can put RO modules – which get added to RO on startup.

ie newest CLib.

I presume the Latest version of the BASIC module could be added.

I have been running RO 5.24 VRPC for sometime – double boots like the Iyonix and a real RPC.
Using StubsG modded loader has the advantage of not needing 32bit CLib to be loaded.

On VRPC,s Windows side there is a Directory where you can put RO modules

Why bother Windows when there is a perfectly good and official place to do it in RISC OS?