Running !Squeak and !Scratch

Hi,

After a lot of head scratching I’ve managed to get the latest versions of !Squeak and !Scratch running on a Raspberry Pi but only by running High Vector versions of the ROM.

RC14 and RC15 both give abort errors pointing to an offset in the Utlity module, according to the Where command.

I’m assuming that the abort handler and zero page handling in the HV ROMS is doing a better job of covering up memory issues than the Low Vector ones in this case as I think it is the first time I have had to have a HV ROM running to get something to work!

The reason I’m trying to get the two programmes working is to use them as part of the RISCOS coding workshop at Recursion 18 so if anyone has any other way of getting them working then I’d like to know as if not I’ll have to put some notes out about updating the RISCOS Roms to the beta ones as part of the coding workshop.

Try removing the ZPP support modules that are only needed for the high vector rom?

Chris,

Yes done that and get the same error with LV ROMS.

So it seems at this stage running HV ROMS and Zeropain are actually helping unless there is a fix post RC15 that has been introduced that is the real reason they work.

I suppose I could try a home brew LV ROM build from the latest sources if I can remember how to do it and get some time to do so!

I suppose I could try a home brew LV ROM build

Um, doesn’t it sound to you like something is broken in the application, not the OS? Is there any ZeroPain logfile that might indicate what is going on? At a random guess, I’d wonder if it isn’t passing a NULL pointer to some OS SWI, which under HV/ZPP may be a true zero if read, but on an LV system is one of the processor vectors, so will look like some big number (remember the oflaoflaofla errors!).

Rick

You may be right but I was just trying to eliminate other things with out being in pointy finger mode at the application or support modules as it is too easy to assume things.

!Scratch and !Squeak run on an Iyonix 5.22 LV so it may be Pi specific.

Attached is a sample of the Zeropain log from a Pi running the latest Beta HV ROM.

I have sent the logs to Tim Rowledge but he does not have a Pi or access to a newer DDE.

Time: Tue Nov 28 13:24:31 2017
Location: Application space
Current Wimp task: Scratch
Last app to start: <Scratch$Dir>.!RunImage -memory:30m -taskname:Scratch -windowlabel:Scratch <Scratch$Dir>.ScratchFixedup/image

R0 = 0004d194 R1 = 4b735000 R2 = 00000000 R3 = 00000000
R4 = 0002fc28 R5 = 0004d194 R6 = 0004d194 R7 = 0004d1c0
R8 = 0002c59c R9 = 0002c59c R10 = 0004a228 R11 = 0004ad98
R12 = 0004ad9c R13 = 0004ad68 R14 = 00026230 R15 = 000258d4
DFAR = 00000028 Mode USR32 Flags nzCv if PSR = 20000110

0002588c : 75746553 : LDRVCB R6,[R4,#-1363]!
00025890 : 78695070 : STMVCDA R9!,{R4-R6,R12,R14}^ ; * ! and ^
00025894 : 72546c65 : SUBVCS R6,R4,#&6500
00025898 : 6c736e61 : LDCVSL CP14,C6,[R3],#-388
0002589c : 6f697461 : SWIVS &697461
000258a0 : 6261546e : RSBVS R5,R1,#&6E000000
000258a4 : 0000656c : ANDEQ R6,R0,R12,ROR #10
000258a8 : ff00001c : Undefined instruction
000258ac : e1a0c00d : MOV R12,R13
000258b0 : e92ddbe1 : STMDB R13!,{R0,R5-R9,R11,R12,R14,PC}
000258b4 : e24cb004 : SUB R11,R12,#4
000258b8 : e15d000a : CMP R13,R10
000258bc : 4b000c65 : BLMI &00028A58
000258c0 : e5902028 : LDR R2,[R0,#40]
000258c4 : e1a05000 : MOV R5,R0
000258c8 : e24dd00c : SUB R13,R13,#&0C ; =12
000258cc * e5920028 * LDR R0,[R2,#40]
000258d0 : e1a0300d : MOV R3,R13
000258d4 : e28d2004 : ADD R2,R13,#4
000258d8 : e3a01009 : MOV R1,#9
000258dc : eb0009a9 : BL &00027F88
000258e0 : e3500000 : CMP R0,#0
000258e4 : 0a000001 : BEQ &000258F0
000258e8 : ebff8a7b : BL &000082DC
000258ec : e91babe0 : LDMDB R11,{R5-R9,R11,R13,PC}
000258f0 : e59d0004 : LDR R0,[R13,#4]
000258f4 : e3500003 : CMP R0,#3
000258f8 : ca000033 : BGT &000259CC
000258fc : e24dd004 : SUB R13,R13,#4
00025900 : e59500d4 : LDR R0,[R5,#212]
00025904 : e3a01b01 : MOV R1,#&0400 ; =1024
00025908 : eb000c93 : BL &00028B5C

R15 = 000258d4 = +1d8d4 in application memory = SetupPixelTranslationTable +28
R14_usr = 00026230 = +1e230 in application memory = CreateSprite +e8
Function call to 000258ac = +1d8ac in application memory = SetupPixelTranslationTable +0

USR stack:
0004ad68 : 00000000 :
0004ad6c : 00000000 :
0004ad70 : 00000000 :
0004ad74 : 0004d194 : – R0
0004ad78 : 302d0169 : | R5
0004ad7c : 0004d194 : | R6
0004ad80 : 0004d1c0 : | R7
0004ad84 : 0002c59c : | R8
0004ad88 : 0002c59c : | R9
0004ad8c : 0004adbc : | R11
0004ad90 : 0004ad9c : | R12
0004ad94 : 00026230 : | R14: 00026230
: : | = +1e230 in application memory
: : | = CreateSprite +e8
0004ad98 : 000258b8 : | APCS function: 000258b0
: : | = +1d8b0 in application memory
: : | = SetupPixelTranslationTable +4
0004ad9c : 0004d194 : | R0
0004ada0 : 0004d194 : | R5
0004ada4 : 002ff02c : | R6
0004ada8 : 000002ff : | R7
0004adac : 00000000 : | R8
0004adb0 : 0004ade8 : | R11
0004adb4 : 0004adc0 : | R12
0004adb8 : 00026648 : | R14: 00026648
: : | = +1e648 in application memory
: : | = CreateDisplayBitmap +10c
0004adbc : 00026154 : | APCS function: 0002614c
: : | = +1e14c in application memory
: : | = CreateSprite +4
0004adc0 : 0004d194 : | R0
0004adc4 : 00000400 : | R1
0004adc8 : 000002ff : | R2
0004adcc : 00000020 : | R3
0004add0 : 0004d194 : | R5
0004add4 : 00000000 : | R6
0004add8 : 00000400 : | R9
0004addc : 0004ae0c : | R11
0004ade0 : 0004adec : | R12
0004ade4 : 00026890 : | R14: 00026890
: : | = +1e890 in application memory
: : | = ioShowDisplayOnWindow +bc
0004ade8 : 00026548 : | APCS function: 00026540
: : | = +1e540 in application memory
: : | = CreateDisplayBitmap +4
0004adec : 00000400 : | R5
0004adf0 : 000002ff : | R6
0004adf4 : 00000020 : | R7
0004adf8 : 000002ff : | R8
0004adfc : 00000000 : | R9
0004ae00 : 0004ae4c : | R11
0004ae04 : 0004ae20 : | R12
0004ae08 : 00026e70 : | R14: 00026e70
: : | = +1ee70 in application memory
: : | = ioShowDisplay +68
0004ae0c : 000267e4 : | APCS function: 000267dc
: : | = +1e7dc in application memory
: : | = ioShowDisplayOnWindow +8
0004ae10 : 005b83c8 : |
0004ae14 : 00000400 : |
0004ae18 : 000002ff : |
0004ae1c : 00000020 : |
0004ae20 : 00000000 : |
0004ae24 : 00000400 : |
0004ae28 : 00000000 : |
0004ae2c : 000002ff : |
0004ae30 : 00000001 : |
0004ae34 : 00000000 : | R5
0004ae38 : 00000400 : | R6
0004ae3c : 00000400 : | R7
0004ae40 : 0004ae9c : | R11
0004ae44 : 0004ae60 : | R12
0004ae48 : 0000ddd0 : | R14: 0000ddd0
: : | = +5dd0 in application memory
: : | = displayBitsOfLeftTopRightBottom +1c4
0004ae4c : 00026e18 : | APCS function: 00026e10
: : | = +1ee10 in application memory
: : | = ioShowDisplay +8
0004ae50 : 005b83c8 : |
0004ae54 : 00000400 : |
0004ae58 : 000002ff : |
0004ae5c : 00000020 : |
0004ae60 : 00000000 : |
0004ae64 : 00000400 : |
0004ae68 : 00000000 : |
0004ae6c : 000002ff : |
0004ae70 : 005b83c4 : |
0004ae74 : 00000020 : |
0004ae78 : 000002ff : |
0004ae7c : 0013bb1a : | R5
0004ae80 : 009d9274 : | R6
0004ae84 : 00000001 : | R7
0004ae88 : 009d92a4 : | R8
0004ae8c : 00000083 : | R9
0004ae90 : 0004aec0 : | R11
0004ae94 : 0004aeb0 : | R12
0004ae98 : 0001c9c0 : | R14: 0001c9c0
: : | = +149c0 in application memory
: : | = primitiveShowDisplayRect +9c
0004ae9c : 0000dc1c : | APCS function: 0000dc14
: : | = +5c14 in application memory
: : | = displayBitsOfLeftTopRightBottom +8
0004aea0 : 0013be8c : |
0004aea4 : 00000000 : |
0004aea8 : 00000000 : |
0004aeac : 00000400 : |
0004aeb0 : 000002ff : |
0004aeb4 : 0004aeec : | R11
0004aeb8 : 0004aec4 : | R12
0004aebc : 000116a0 : | R14: 000116a0
: : | = +96a0 in application memory
0004aec0 : 0001c930 : | APCS function: 0001c928
: : | = +14928 in application memory
: : | = primitiveShowDisplayRect +4
0004aec4 : 000005ff : |
0004aec8 : 00000002 : |
0004aecc : 0004952c : | R5
0004aed0 : 0002d6f4 : | R6
0004aed4 : 00029b5c : | R7
0004aed8 : 00049740 : | R8
0004aedc : 0002d2f4 : | R9
0004aee0 : 0004af18 : | R11
0004aee4 : 0004aef0 : | R12
0004aee8 : 000090a4 : | R14: 000090a4
: : | = +10a4 in application memory
: : | = main +f4
0004aeec : 0000fe38 : | APCS function: 0000fe30
: : | = +7e30 in application memory
: : | = interpret +4
0004aef0 : 00000005 : | R0
0004aef4 : 0004b4c4 : | R1
0004aef8 : ffffffff : | R5
0004aefc : 00000000 : | R6
0004af00 : 00000000 : | R7
0004af04 : 00049740 : | R8
0004af08 : 00049970 : | R9
0004af0c : 0004af74 : | R11
0004af10 : 0004af1c : | R12
0004af14 : fc16e3ac : | R14: fc16e3ac
: : | = SharedCLibrary +407c
: : | = _main +3f8
0004af18 : 00008fbc : | APCS function: 00008fb4
: : | = +fb4 in application memory
: : | = main +4
0004af1c : 00420000 : |
0004af20 : ffffffff : |
0004af24 : 00000005 : |
0004af28 : 00000000 : |
0004af2c : 00000000 : |
0004af30 : 00000000 : |
0004af34 : 0000006e : |
0004af38 : 0004af54 : |
0004af3c : 000494b4 : |
0004af40 : 00049504 : |
0004af44 : 03eabf9c : |
0004af48 : 0004af88 : | R0
0004af4c : 00008fb0 : | R1
0004af50 : 00027a34 : | R4 – Return to 00027a34?
: : | | = +1fa34 in application memory
: : | | = readFPStatus +48
0004af54 : 00029b5c : | R5
0004af58 : 00029b5c : | R6
0004af5c : 00000028 : | R7
0004af60 : 0004929c : | R8
0004af64 : 00049194 : | R9
0004af68 : 0004af84 : | R11
0004af6c : 0004af78 : | R12
0004af70 : 00027a4c : | R14: 00027a4c
: : | = +1fa4c in application memory
: : | = readFPStatus +60
0004af74 : fc16dfc0 : | APCS function: fc16dfb8
: : | = SharedCLibrary +3c88
: : | = _main +4
0004af78 : 00000000 : | R11
0004af7c : 0004af88 : | R12
0004af80 : fc19b024 : | R14: fc19b024
: : | = SharedCLibrary +30cf4
: : | = _kernel_CallInitProcs +48
0004af84 : 00027a40 : | APCS function: 00027a38
: : | = +1fa38 in application memory
: : | = readFPStatus +4c
0004af88 : 7263533c :
0004af8c : 68637461 :
0004af90 : 72694424 :
0004af94 : 52212e3e :
0004af98 : 6d496e75 :
0004af9c : 20656761 :
0004afa0 : 6d656d2d :
0004afa4 : 3a79726f :
0004afa8 : 206d3033 :
0004afac : 61742d20 :
0004afb0 : 616e6b73 :
0004afb4 : 533a656d :
0004afb8 : 74617263 :
0004afbc : 2d206863 :
0004afc0 : 646e6977 :
0004afc4 : 616c776f :
0004afc8 : 3a6c6562 :
0004afcc : 61726353 :
0004afd0 : 20686374 :
0004afd4 : 7263533c :
0004afd8 : 68637461 :
0004afdc : 72694424 :
0004afe0 : 63532e3e :
0004afe4 : 63746172 :
0004afe8 : 78694668 :
0004afec : 70756465 :
0004aff0 : 616d692f :
0004aff4 : 00006567 :
0004aff8 : 0004aff8 :
0004affc : 19193a19 :
0004b000 : 00000000 :
0004b004 : 0000027c :
0004b008 : 19191919 :
0004b00c : 03eabf9c :
0004b010 : 00000000 :
0004b014 : 19191929 :
0004b018 : 3a291919 :
0004b01c : 19192919 :
0004b020 : 192c1919 :
0004b024 : 2c19192c :
0004b028 : 29192919 :
0004b02c : 40291919 :
0004b030 : 45224545 :
0004b034 : 45454545 :
0004b038 : 40454545 :
0004b03c : 29192919 :
0004b040 : 19192919 :
0004b044 : 192c191b :
0004b048 : 2c191b19 :
0004b04c : 29292919 :
0004b050 : 45403a29 :
0004b054 : 45454540 :
0004b058 : 19454545 :
0004b05c : 192c1929 :
0004b060 : 40192929 :
0004b064 : 45404042 :
0004b068 : 45454042 :
0004b06c : 45404545 :
0004b070 : 40454045 :
0004b074 : 40454045 :
0004b078 : 45192919 :
0004b07c : 40453a45 :
0004b080 : 292c293a :
0004b084 : 40454019 :
0004b088 : 2c194045 :
0004b08c : 402c2c2c :
0004b090 : 40224540 :
0004b094 : 3a404045 :
0004b098 : 40191919 :
0004b09c : 45404045 :
0004b0a0 : 40224540 :
0004b0a4 : 40454045 :
0004b0a8 : 2c294245 :
0004b0ac : 2c292c29 :
0004b0b0 : 2c2c292c :
0004b0b4 : 292c2c2c :
0004b0b8 : 3c4a7d2c :
0004b0bc : 4a3c4a4a :
0004b0c0 : 4a4a3c3c :
0004b0c4 : 3c4a4a4a :
0004b0c8 : 4522514a :
0004b0cc : 2c2c2c3a :
0004b0d0 : 2c2c2c29 :
0004b0d4 : 1b2c2c2c :
0004b0d8 : 2c2c2c2c :
0004b0dc : 2c2c2c2c :
0004b0e0 : 652c2c10 :
0004b0e4 : 2c2c2c2c :
0004b0e8 : 2c2c102c :
0004b0ec : 2c2c2c29 :
0004b0f0 : 2c2c2c2c :
0004b0f4 : 192c102c :
0004b0f8 : 4a6b4a6b :
0004b0fc : 2c264a4a :
0004b100 : 2c2c602c :
0004b104 : 2c2c2c60 :
0004b108 : 602c2c65 :
0004b10c : 2c2c602c :
0004b110 : 4a5e2c2c :
0004b114 : 4a4a4a6b :
0004b118 : 6b4a4a4a :
0004b11c : 60407d4a :
0004b120 : 602c602c :
0004b124 : 602c6065 :
0004b128 : 652c602c :
0004b12c : 602c602c :
0004b130 : 602c602c :
0004b134 : 602c652c :
0004b138 : 602c602c :
0004b13c : 601b652c :
0004b140 : 60602c60 :
0004b144 : 602c6060 :
0004b148 : 6065602c :
0004b14c : 2c606060 :
0004b150 : 2c601060 :
0004b154 : 65602c60 :
0004b158 : 2c602c60 :
0004b15c : 2c602c60 :
0004b160 : 7d606560 :
0004b164 : 60602c51 :

Hi,

Finally found some source for these functions at http://www.squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/RiscOS/vm/sqRPCWindows.c?revision=2700&view=markup but I must confess, I’m worried that the code was last modified “4 years, 8 months ago”. I gave up working out how to download an archive of the files to attempt to build it, but then it would probably expect GCC and not Norcroft. ;-)

As far as this particular problem goes, it is totally a null pointer bug in Squeak.

[…snip…]
R0 = 0004d194 R1 = 4b735000 R2 = 00000000 R3 = 00000000
R4 = 0002fc28 R5 = 0004d194 R6 = 0004d194 R7 = 0004d1c0
R8 = 0002c59c R9 = 0002c59c R10 = 0004a228 R11 = 0004ad98
R12 = 0004ad9c R13 = 0004ad68 R14 = 00026230 R15 = 000258d4
DFAR = 00000028 Mode USR32 Flags nzCv if PSR = 20000110

[…snip…]
000258c0 : e5902028 : LDR R2,[R0,#40]
000258c4 : e1a05000 : MOV R5,R0
000258c8 : e24dd00c : SUB R13,R13,#&0C ; =12
000258cc * e5920028 * LDR R0,[R2,#40]
000258d0 : e1a0300d : MOV R3,R13
000258d4 : e28d2004 : ADD R2,R13,#4
[…snip all the rest…]

Without a debugger or trace instructions (I note plenty of PRINTFs in the source), I can’t tell exactly where this is failing, but the code shown above is loading R2 from the address in R0, plus 40. R0 is then stuffed into R5. The stack is then fiddled with. And now for our faulty instruction. It is loading a word into R0 from the address in R2 plus 40. Unfortunately R2 is zero, so we are trying to load a word from address &28.

Now the faulty function is SetupPixelTranslationTable. The BPP of the Pi in 16M colours is 5, so the second block of code is executed (not the “fudge the pixel table” part).
Here is where it gets interesting. It calls xcolourtrans_generate_table( thisWindow->displaySprite->mode, currPal, os_CURRENT_MODE, colourtrans_CURRENT_PALETTE, NULL, colourtrans_RETURN_WIDE_ENTRIES, NULL, NULL, &tableSize) to get the size of the translation table. Now since it is quite likely that the display is created to be the same dimensions as the current screen (not entirely confirmed – I unwound as far as ioShowDisplayOnWindow – and trying to look at /trunk/src/vm/interp.c handed me a ~5MB or so web page which NetSurf failed to render (popping up an error that said “BoxConvert”!)).
Now ColourTrans_GenerateTable is the same as ColourTrans_SelectTable except the flags must be correct.
So…

REM Create sprite area
DIM sa% 16384
sa%!0 = 16384
sa%!8 = 16
SYS "OS_SpriteOp", (256 + 9), sa%

REM Create sprite, 32x32 @32bpp, similar method to Squeak
SYS "OS_SpriteOp", (256 + 15), sa%, "sq12345", 0, 32, 32, (6<<27)+(180<<14)+(180<<1)+1

REM Work out translation table size
SYS "ColourTrans_GenerateTable", sa%, "sq12345", -1, -1, 0, %10000 TO ,,,,ts%
REM                              |     |          |   |  |  '- generate large table
REM                              |     |          |   |  '---- 0 to return buffer length
REM                              |     |          |   '------- current palette of...
REM                              |     |          '----------- ...current mode
REM                              |     '---------------------- source sprite
REM                              '---------------------------- source sprite area

REM Result?
PRINT ts%

The result is… zero! ColourTrans is telling us we do not need a translation table if the source and destination are the same.
Now, I cannot guarantee that this is the case, however the code then reallocs the array pointed to by thiswindow->pixelTranslationTable to be the specified table size, writing the result back to that array pointer, and then it tries to generate the translation table to that pointer without ever checking if the requested table size is zero, or if realloc failed – stdlib in the DDE headers says that if the size given is zero, the object referenced is freed; and since there is now nothing to point to, realloc will be returning a null pointer… [ confirmed: Lib.RISC_OSLib.c.alloc; if size is zero, “newb” is unset (defaults to NULL) and after calling _primitive_dealloc() it returns newb (i.e. NULL) ]

Just guesswork, mostly, but that’s where I’d be looking. It’s definitely a null pointer problem and the code I’ve located does appear to suffer the potential to create a null pointer situation; though I guess it may behave differently on other machines or else it’d be crashy on everything…?

I have sent the logs to Tim Rowledge but he does not have a Pi or access to a newer DDE.

If it builds with the DDE (and not GCC), I’ll be happy to try building it on a Pi if somebody can get me an archive of the sources.

displayBitsOfLeftTopRightBottom

Oh, I like that! ☺

HI Rick

Excellent stuff.

I’ve emailed Tim and said you would be willing to recomplile if we can get a archive of the sources and pointed him here.

OK, Hi guys. I’m a bit limited by lack of a recent RISC OS and DDE, so this may be a bit more complicated than we’d like.

FIrst off, Rick can breath easier since I don’t use gcc on RISC OS. I don’t even like it on linux… but that’s another issue.

The last time I did any development work on the RISC OS Squeak vm was at the beginning of 2013 when I started the RPF work to improve Scratch. The fact that the sqRPCWindows.c file hasn’t been touched since forever is a good sign because it means nothing appeared to be broken. Evidently something isn’t quite right though, so let’s see what we can winkle out of the debug trace.

These days the VM sources are available on github (yes, I hate it too) at https://github.com/OpenSmalltalk/opensmalltalk-vm – so the relevant file is https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/RiscOS/vm/sqRPCWindows.c – and I see some kind person added a new api in 2016 to keep it up to date. No idea who krono is. We’re looking at line 712 & 725.

I see what Rick means about the tableSize thing; it never occured to me that you’d get a 0 back for that. I was naive enough to think that one might get sometihng like, y’know, an actual error in case of strangeness. Silly me! Not to mention I have trouble imagining how the following call to actually generate the table doesn’t error out.

So, questions -
a) if we are using a display pixel depth that matches the actual display and thus don’t need a translation table, would I set ‘thisWindow→pixelTranslationTable’ to 0?
b) does anyone know if the ‘fudge’ section above (ll.675-702) is still needed?
c) If I manage to download RISC OS for one of my Pi ⅔ can somebody point me to a download of the latest DDE? I’ll happily spend some time to try to fix this but I can’t spend any money on it.

If I manage to download RISC OS for one of my Pi ⅔ can somebody point me to a download of the latest DDE? I’ll happily spend some time to try to fix this but I can’t spend any money on it.

Impossible to fulfill both of those mutually exclusive requests.
We can point you at the sales page for the DDE or you could get Rick to compile test builds.

Just guesswork, mostly, but that’s where I’d be looking.

If assuming makes an ass out of you and me, what does guessing do?

R15 = 000258d4 = +1d8d4 in application memory = SetupPixelTranslationTable +28

The crash occurred at an offset of &28 into SetupPixelTranslationTable. Sometimes compilers can rearrange things and make offsets like this meaningless, but if you look at the disassembly (* and you know what to look for) it’s clear that the crash has occurred very early on. Far too early for it to have called ColourTrans, called realloc, and then called ColourTrans again (and if the crash was in ColourTrans or the C library then the callstack would have been quite different).

0002588c : 75746553 : LDRVCB R6,[R4,#-1363]!              ; This bit's the embedded function name, you can ignore that
00025890 : 78695070 : STMVCDA R9!,{R4-R6,R12,R14}^        ;
00025894 : 72546c65 : SUBVCS R6,R4,#&6500                 ;
00025898 : 6c736e61 : LDCVSL CP14,C6,[R3],#-388           ;
0002589c : 6f697461 : SWIVS &697461                       ;
000258a0 : 6261546e : RSBVS R5,R1,#&6E000000              ;
000258a4 : 0000656c : ANDEQ R6,R0,R12,ROR #10             ;
000258a8 : ff00001c : Undefined instruction               ;
000258ac : e1a0c00d : MOV R12,R13                            ; APCS function prologue. Push stack frame, check if stack extension is needed.
000258b0 : e92ddbe1 : STMDB R13!,{R0,R5-R9,R11,R12,R14,PC}   ;
000258b4 : e24cb004 : SUB R11,R12,#4                         ;
000258b8 : e15d000a : CMP R13,R10                            ;
000258bc : 4b000c65 : BLMI &00028A58                         ;
000258c0 : e5902028 : LDR R2,[R0,#40]        ; Function body starts here
000258c4 : e1a05000 : MOV R5,R0              ;
000258c8 : e24dd00c : SUB R13,R13,#&0C       ;
000258cc * e5920028 * LDR R0,[R2,#40]        ;
000258d0 : e1a0300d : MOV R3,R13             ;
000258d4 : e28d2004 : ADD R2,R13,#4          ;
000258d8 : e3a01009 : MOV R1,#9              ;

You’ll note that it crashes on the second load instruction of the function.

The very first line of code in SetupPixelTranslationTable is this:

if ( ( e = xos_read_mode_variable( thisWindow->displaySprite->mode, os_MODEVAR_LOG2_BPP, &log2bpp, &junk)) != NULL) {

Load thisWindow→displaySprite (LDR R2,[R0,#40]), load displaySprite→mode (LDR R0,[R2,#40]). Except the register dump shows R2 as zero, ergo thisWindow→displaySprite is NULL.

I was naive enough to think that one might get sometihng like, y’know, an actual error in case of strangeness.

Returning R4=0 is ColourTrans’ way of telling you that you don’t need a table. “ColourTrans, how much memory do I need to allocate for a translation table?” “Zero.”

a) if we are using a display pixel depth that matches the actual display and thus don’t need a translation table, would I set ‘thisWindow→pixelTranslationTable’ to 0?

Yes; if you don’t need a translation table then you should just pass a null pointer into OS_SpriteOp. (But just because the colour depths or pixel formats match doesn’t meant that you don’t need a table – e.g. 8bpp)

b) does anyone know if the ‘fudge’ section above (ll.675-702) is still needed?

I don’t know – what problem is it working around? The way you’re using ColourTrans looks a bit unusual to me, but I don’t think there’s anything wrong with it.

Possibly the funny behaviour you saw was a result of the null pointer.

Blech. If thisWindow→displaySprite is 0 then at some point the creation of the Sprite or possibly the selection of it with xosspriteop_select_sprite() failed…. or wait a minute…
In CreateSprite() the code is setting the sprite name and mode, then creating a sprite with xosspriteop_create_sprite(), thne trying to do SetupPixelTranslationTable() BUT it isn’t until UpdateDisplaySpritePtrs() on the next line that the damn pointer to the sprite is actually set in the windowDescriptorBlock struct.

If that is actually the sequence (and I haven’t had to do anything with this code since about 2004 so it’s a while since I thought about it) then it could only ever work properly on the second and subsequent times the sprite gets (re)created. Which would be so damn wrong…

As for the fudge and some problem with generate table, your guess may be as good as mine. It dates back to at least 2004 and probably something read on one or other of the contemporary net resources for RISC OS. Google is not my friend on this.

If assuming makes an ass out of you and me, what does guessing do?

Makes an ass out of just me?

It’s not bad. Together we’ve identified two sources of potential null pointer problems. ;-)

perhaps the smart start is for Rick to send a skype request to me – timrowledge – and we’ll see if we can work out how to get a compile going

perhaps the smart start is for Rick to send a skype request to me

…uh… I’ve not touched Skype since Microsoft embraced it and subsequently broke it.

Never used it much anyway. Logging into Arcade BBS and sending me a message (I’m user #427) is more my speed. ;-)

Guys, you’re not exactly making it easy for me to try to help here.

I persuaded my ancient Pi 1 with broken SD card holder and old SD with RISC OS to boot. So in theory I might be able to build a new VM with the old whatevers are on the original NutPi/DDE stuff.

I have a Pi going if you need it but sending it from Aus will cost more than buying a new one is there any one in the uk that can borrow/give you a Pi so that you can do the work??
Don’t all shout at once.

So in theory I might be able to build a new VM with the old whatevers are on the original NutPi/DDE stuff.

Ah, so your DDE copy is relatively new. I was thinking it was a pre-Pi revision.

In general I see no major obstacle to you doing a recompile. Just a suggestion, but perhaps you could put up a copy of the source in a zip at the same location as the zip archives with the binaries as I think Ricks main issue was pulling a full source copy. Bear in mind he has RO machines and an elderly XP machine only.

Rob, that’s a very kind offer but rest assured that I have many, many, Pis. I do only have a single original Pi 1 that still works though, and that is what is needed since all my RISC OS work is on a full size SD card.

Steve, yes I guess that might be part of a path for Rick. The bigger part of the job is making sure I remember everything needed to be able to build; OSLib, rink, various modules, the path setup etc. The last build I see on my machine is March 2013, so anything that has changed since then that could affect the process will be an issue to work around.

So, at last I have a Pi 2 running ROS and connected to my net. I have no idea why it would connect at first, nor second, nor third etc but something unknown made it suddenly decide to do the dhcp dance.

I transferred everything I could from the old Pi1. Trying to compile anything results in a whine about ’this program can only be run on a raspberry Pi. It is on a Raspberry Pi.
What next?

Trying to compile anything results in a whine about ’this program can only be run on a raspberry Pi. It is on a Raspberry Pi. What next?

NutPi is tied to the Pi hardware, and IIRC there was an upgrade (or second edition) which recognised the Pi 2. It might be a choice of update your version, or stick to the Pi 1.

I can’t stick to the Pi 1 because it is becoming unreliable – a combination of a broken card holder and a dying SD card.

Hi Tim

Thanks for sticking with this.

Firstly how did you set up the NutPi DDE on your new Pi2/SDCard. Did you use the !PiCopy utlility found in the DDE24 zip file on the NutPi SD or just copy some things over as the routines does set things up.

Secondly someone on here posted that the DDE on the origonally NutPi did load on a Pi2 but that may have may been the origonal Pi2 with the older processor.

Finally one of the ROOL news announcements mentioned that those who had a NutPi DDE could upgrade it for a small fee so it may that is an option as per below:

“NutPi users, If you have a copy of DDE as found on the NutPi product, this can be upgraded for just £12.50 (inc VAT) by sending your NutPi serial number, found by running the !PiSerial application, to the store email address. The NutPi version is almost identical to the full version, except that the tools only run on a Raspberry Pi – however the code they generate is suitable for any RISC OS computer.”

If not come back to us and we will see what other help we can give.

Tim

Another thought did you do the following once you copied over the DDE contents?

Once copied, you should install the Developer !System components by running
(double-clicking) the file: “$.AcornC/C++.Developer.!SysMerge”

Sadly, it made no differnce

Ok, sounds like you have a Pi2 B v1.2 with the new processor which is a A57 variant.

The DDE must check it is running on a Pi by looking at the system and hence the older NutPi version can’t run as it does not have the newer v1.2 processor/system it it’s code.

You could try updating the DDE as per the news arcticle I quoted or see if you have a older v1.1 Pi2 B with a BCM2836 SOC or better still a Pi1 B+ which has a Micro Sd slot in your collection.