Important software compatibility notice

I’ll see what can be done :)

Work has already begun on ABC

Excellent news.
In the past, I’ve encountered some very peculiar bugs in ABC.
If you’re interested, Id love to post them to you.

Jon: as a short-term bodge, can’t ADFFS just refuse to do the 26/32-bit magic if VProtect is present? As previously said, VProtect is fairly pointless on 32-bit platforms.

The majority of game Modules aren’t scanned as a consequence, as any Module inserted/loaded via SWI aren’t scanned.

!!!!! Wow, that’s a pretty big omission.

In the past, I’ve encountered some very peculiar bugs in ABC.

Care to share? Always fun to look at the differences.

In the past, I’ve encountered some very peculiar bugs in ABC.

Some of the bugs are actually intended behaviour. ABC does not have LOCAL variables only PRIVATE variables (they are in scope statically for the function or procedure not via the stack as they revert to their global equivalents when the procedure or function in which they are defined calls another function or procedure. Most confusing.

The alternative can be just as confusing. When I used to use ABC for quite a lot of applications I made a point of always passing ‘LOCAL’ variables into other PROCs/FNs as parameters. Saved a lot of heartache.

Yes, I agree. I had cheated and had certain global variables that were exactly that except for a brief interval – when the program was doing a specific thing – so I called a particular procedure to do that thing, made these variables LOCAL while it was doing it. The problem was that that procedure called lots of other procedures and functins that referenced these global variables – the ones that were temporarily LOCAL to the calling procedure. Too many to add them to the parameter list. All perfectly legal in BASIC, correct structured programming, worked perfectly in the other compiler RiscBASIC (which was vastly superior to ABC).

Just didn’t work when I tried to get the programme to work under ABC (RISCBasic not developed beyond StrongARM and the Iyonix had now appeared) due to this horrendous bug (sorry feature, as it was documented). Also it won’t provide line number references for any run time error message so I had to interleave alternate lines ‘line%=23455’ and add an error handler to announce the ‘line number’.

In the past, I’ve encountered some very peculiar bugs in ABC.

Care to share? Always fun to look at the differences.

In BASIC, VAL("1A") will produce the value 1, thus ignoring the subsequent character.
The compiled statement returns the value 1 as well.
However, some subsequent characters appear to cause other values, after compiling.

Here’s the list that I found:

VAL("1:") gives 13
VAL("1;") gives 14
VAL("1<") gives 15
VAL("1=") gives 16
VAL("1>") gives 17
VAL("1?") gives 18
VAL("1@") gives 19

Doesn’t this look like a real bug?

If the compiler is now being worked on could this ‘LOCAL’ feature/bug be removed or might it stop some programs from working?

Another request for the new ABC compiler:

variable()=0

The current version of ABC doesn’t accept this. You’re supposed to write:

FOR i% = 1 TO maxvalue% : variable(i%) = 0 : NEXT

Not really an issue, perhaps, but still extra work, especially with multi dimensional variables.

For the time being, I think the priority is to make sure the current version works as it always has, but on modern hardware and OS versions (eg. ZPP etc). New or altered functionality will likely come later. Usual problem – not enough time for a small number of people to do a lot of work!

For the time being, I think the priority is to make sure the current version works as it always has,

That is sensible – get what exists working everywhere before changing things.

However…

[…] the source to Vprotect, and also ABC compiler etc has been recovered […] I believe the plan is to update them and release into the ROOL tree.

By “release into the ROOL tree”, would this be the open or the closed part? If ABC is released into the open part, then some of the work in fixing niggles (re. Paul’s oddities) and supporting some of the later BBC BASIC additions could be crowdsourced. In other words, us. ;-)

ABC is currently part of the ROOL dev CD, I think. This may have some bearing on how it is handled. At this stage I don’t know any more.

Since installing zpain I find that the frequency with which startup freezes (while the desktop background is being rendered) has increased. Using RO 5.21 on Rpi2. I am also getting “undefined instruction at &FC38775C” from Messenger Pro (7.08) occasionally.

It’s nice to see (from discussion on archive-on-line) that the Zero Pain debate has progressed beyond the denial stage of a change project and into the resistance phase – see Project Steps – so we should soon be in the cooperation or rebuilding phase where the overall effect starts getting positive.

the resistance phase

I could go a bit Borg and say resistance is futile but those wishing to resist can step sideways and backwards into the alternate universe of RO6.
Admittedly it is a closed and stagnating universe but…

One thing of note is that (sticking with the universe analogy) the leakage from this universe to that in the form of fixed code/programs will benefit that other universe.

the leakage from this universe to that in the form of fixed code/programs will benefit that other universe.

Not necessarily – if anything RISC OS 5 specific is to be used¹, it makes software as incompatible with 4/6 as software written with that in mind was with RISC OS 3.7 back in the day.

¹ Leading to the age-old question of whether we should use facilities present in RISC OS 5, or eschew them in favour of older facilities in order to remain compatible with a stagnant (abandoned?) version? Obviously it is a harder call if one is writing commercial software as the balance of supported systems can directly affect potential users (and thus cash flow), however over the years a lot has been added to RISC OS 5, and – emulation aside – the alternative runs on increasingly ancient hardware. Surely there comes a point when it makes sense to use what’s right here instead of being tied to the past? There’s enough of this already in our fair lands…

Fixing ZeroPain problems is stopping programs accessing memory they should not be accessing.
Regardless of which version of RISC OS they are running on.

Fixing ZeroPain problems is stopping programs accessing memory they should not be accessing.
Regardless of which version of RISC OS they are running on.

Which was the point I was making, and I think is the point of Zeropain. Fixing the faults doesn’t make the code incompatible with any version of OS.

Have any of the core Apps / Modules been updated in the HD image for ZeroPain?

I’m just wondering if I should be reporting two ZeroPain I’ve seen for NetSurf and Menu, or if I should be updating my !Boot with the latest.

I’ve just spent the day recompiling todays TungstenDev distribution over and over again before realising the data aborts I was getting are caused by not running zeropain – I think the person who decided to do this has a sadistic streak.

Anyway I was disappointed to find that amu from dde25 is affected. Presumably it’s now been fixed? The zeropain entry below was caused when !Builder was run after installing todays rom.

Time: Fri Oct  9 15:44:06 2015
Location: Application space
Current Wimp task: Unknown
Last app to start: <Tools$Dir>.Acorn.amu -f <Build$Dir>.Env.Makefile FIXED=yes find-amu-version

R0  = 00013ef8 R1  = 00013f00 R2  = 00000000 R3  = 000181c0
R4  = 00013ef8 R5  = 00013ef8 R6  = 00000000 R7  = 00000000
R8  = 00000000 R9  = 00017e1c R10 = 000154e4 R11 = 00016158
R12 = 0001615c R13 = 0001614c R14 = 0000d3ec R15 = 0000cf9c
DFAR = 00000008  Mode USR32  Flags nzCv if   PSR = 20000010

0000cf54 : e51f183c : LDR     R1,&0000C720
0000cf58 : e590200c : LDR     R2,[R0,#12]
0000cf5c : e5b13008 : LDR     R3,[R1,#8]!
0000cf60 : e3520000 : CMP     R2,#0
0000cf64 : 1a000007 : BNE     &0000CF88
0000cf68 : e5932008 : LDR     R2,[R3,#8]
0000cf6c : e580200c : STR     R2,[R0,#12]
0000cf70 : e5922008 : LDR     R2,[R2,#8]
0000cf74 : e5a32018 : STR     R2,[R3,#24]!
0000cf78 : e5b0200c : LDR     R2,[R0,#12]!
0000cf7c : e3520000 : CMP     R2,#0
0000cf80 : 191ba800 : LDMNEDB R11,{R11,R13,PC}
0000cf84 : ea000008 : B       &0000CFAC
0000cf88 : e5922000 : LDR     R2,[R2,#0]
0000cf8c : e5a32008 : STR     R2,[R3,#8]!
0000cf90 : e580200c : STR     R2,[R0,#12]
0000cf94 * e5b21008 * LDR     R1,[R2,#8]!
0000cf98 : e5902008 : LDR     R2,[R0,#8]
0000cf9c : e5a21018 : STR     R1,[R2,#24]!
0000cfa0 : e590000c : LDR     R0,[R0,#12]
0000cfa4 : e3500000 : CMP     R0,#0
0000cfa8 : 191ba800 : LDMNEDB R11,{R11,R13,PC}
0000cfac : ebffffcf : BL      &0000CEF0
0000cfb0 : eaffffe1 : B       &0000CF3C
0000cfb4 : e1a0c00d : MOV     R12,R13
0000cfb8 : e92dd800 : STMDB   R13!,{R11,R12,R14,PC}
0000cfbc : e24cb004 : SUB     R11,R12,#4
0000cfc0 : e15d000a : CMP     R13,R10
0000cfc4 : 4b001988 : BLMI    &000135EC
0000cfc8 : e51f18b0 : LDR     R1,&0000C720
0000cfcc : e3500001 : CMP     R0,#1
0000cfd0 : 03a00004 : MOVEQ   R0,#4

--------------------------------------------------------------------------------

Is there a way to turn off the output from zeropain? I don’t need the 1MB output from a rom compilation accumulating.

I’m just wondering if I should be reporting two ZeroPain I’ve seen for NetSurf

Always. Every malfunction you see.

I hope to submit a patch to Netsurf tonight to prevent a few null dereferences.

Anyway I was disappointed to find that amu from dde25 is affected. Presumably it’s now been fixed?

ROOL are aware that the DDE has issues, but I’m not sure if it’s actually been fixed yet.

I don’t need the 1MB output from a rom compilation accumulating.

Edit the file Boot.Choices.Boot.PreDesk.Run to point the log file to a RAMDISK sized just big enough to hold the output then you lose the content on a reboot.

Although I suppose if you made the location it sent data to be null: then the output should be blackholed