Internal error at line 99999 (?!?) on OpenPandora RO 5.20, not on RPI RO5.21

Hello all

I am facing a problem that drives me nuts.
THis is again related to the Brownian Motion simulation application I am currently writing.
I store the data of the currently running simulation into a data block defined as followed:

DIM data% 255
REM ?data% 	: simulation activity flag (0 - no simulation is running; 1 - a simulation is running)
REM data%?1  	: simulation id
REM data%!2  	: current iteration
REM data%!6	: total number of iterations
REM |(data%+10)	: lower bound at gate 1
REM |(data%+18) : upper bound at gate 1
REM |(data%+26) : time at gate 1
REM |(data%+34)	: lower bound at gate 2
REM |(data%+42) : upper bound at gate 2
REM |(data%+50) : time at gate 1
REM data%!58	: number of paths passing through gate 1
REM data%!62	: number of paths passing through gates 1 AND 2
REM |(data%+66)	: sum of terminal values of paths passing through gates 1
REM |(data%+74)	: sum of terminal values of paths passing through gates 1 AND 2
REM |(data%+82)	: sum of increments over time interval [t1,t2]

As you can guess, I am running the application under BASIC64 to have floating point precision of 64 bits.

The first step is to populate the data block with the simulation parameters entered by the user in the appropriate dialog box.
To do so, I defined the following routines (found in the Martyn Fox’s book : A Beginner’s Guide to Wimp Programming)

DEFFNget_str(ind%)
LOCAL n%
  n%=0
  WHILE ind%?n%>31
    n%+=1
  ENDWHILE
  ind%?n%=13
=$ind%

And I use it as follow:

LOCAL ind%
...
REM Total number of iterations (icon handle 0)
ind%=!(b%+4+88+32*0+20)
data%!6=VAL(FNget_str(ind%))
REM Lower bound at gate 1 (icon handle 6)
ind%=!(b%+4+88+32*6+20)
|(data%+10)=VAL(FNget_str(ind%))
...

On raspberrypi RO 5.21, I encounter no error. The application seems to run smoothly.
But on my OpenPandora RO5.20, I get the following error: “Internal error: short on data transfer at &FC1F1D90 at line 99999”.
After investigation, I think that the problem occured when BASIC64 tries to evaluate the VAL command (which might explain this crazy line number of 99999 reporting in the error message).

If, in my !Run file, I switch to BASIC (not 64), then the error does not occur!

I have no idea how to fix this.

Thank you for your help.

François

I expierenced an error with the same unique line number (at least I think it was 99999 and not 9999) on a friend’s BeagleBoard when he tried to play a game I knocked together. But that was (most likely) under the regular BASIC. I was blindy blaming my hand-made sprite plotter at that time. Didn’t investigated further as some rewrite is due anyway to make it Raspberry-friendly. To make it more confusing, the game runs happily on my own BeagleBoard.

data%!6=VAL)

If data% is word-aligned then data%!6 won’t be which is not allowed on ARMv7 (I’m guessing that’s what the OpenPandora is running). The RPi is probably set to ARMv5 compatibility mode where unaligned accesses are allowed. If you set the RPi to ARMv7 mode you’re likely to get the same error.

To get rid of the error you’ll need to rearrange things such that the data is located on a word boundary, or do two byte size reads.

When I read that structure definition my thoughts went straight to the many unaligned locations. Fred suggests that the compatibility mode will be important, but even without that, BASIC VI itself requires floats to be word-aligned. Try storing and reloading a float from an unaligned location and you will not get back what you expect. ;-)

I thought I would quote a reference to this, but I could not find one, and I have not even metioned it in my StrongHelp BASIC manual. I must have assumed that it was ‘obvious’. ;-(

A little experiment shows that a two-word float is actually stored at the aligned word below the location specified. In that case, some of your data is overwriting other data, in particular the word at data%!6.

In BASIC V, the floats are 5 bytes and expected to be byte-aligned, so that will work without problems.

Thank you for your help… I am pretty sure this is the problem.
Indeed, in a previous and simpler version of the application, the data block was word aligned… and it was working. Yesterday, I “added”, amongst other major refactoring, the two first bytes. I wasn’t even aware that could make a difference.

I will therefore “word align” my data blocks!

Regards

François

I think I can explain some of what François and Holger are seeing, but not the aborts!

Before Basic v1.54 there was a significant problem when external code was called from Basic using CALL, USR, SYS, or a *command (either directly or using OSCLI), and that code Aborted with Data Transfer, Undefined Instruction or Instruction Fetch. The Error Line (ERL) then given by Basic was often the last line of the program, rather than the Basic line containing the CALL, USR, SYS or *command.

This was (1) useless, (2) misleading, and (3) generally frustrating!

Basic v1.54 (released about 6 months ago) included some changes to try and return the correct ERL after an abort, and to call the Basic error handler. As part of these changes the ERL was set to -1 if the Basic program address was below the Basic program, or 99999 if above. I could not really see how this would ever happen, so could not improve it!

It seems that it is possible to cause it to happen!

So, some of the differences you have seen may be because of different versions of Basic. v1.54 was in RO5.19 from sometime in March.

I would be very interested to have a copy of a problem program, so I can investigate if there is any way to change 99999 in to a more useful ERL. Please email to my first name at avisoft dot f9 dot co dot uk

For further details see the change logs for Basic here

Hello
I would like to confirm my problem is now fixed. This was indeed due to my block being not word aligned. so, thank you very much for your help.

@Martin
I will send you this week-end the application, after I reintroduced the bug :)

Regards.