Zero Pain Maestro

Does anyone else get a ZeroPain entry when a Maestro music file is double-clicked or dragged to the iconbar when the app is already running? I seem to do so consistently here, whether using the old version or the new one I added some sprites to recently.

The offending bit of code seems to be calling SYS "Wimp_SendMessage" to issue a DataLoadAck message after the file is loaded, but after staring at the relevant code for some time I can’t see where the problem is. I wonder if the issue is being caused elsewhere, and this code is merely triggering it?

I’m not clever enough to decode the ZeroPain log, but here’s the top end of it in case someone else is. Can anyone help decipher what’s going on?

Location: Application space
Current Wimp task: StrongED
Last app to start: BASIC -quit "SDFS::PiBoot.$.Programming.RISCOS.Maestro.!Maestro.!RunImage" 

R0  = 00000bff R1  = ffffffff R2  = 0000000c R3  = 00000004
R4  = 000003d6 R5  = 00000000 R6  = 00000af1 R7  = ffffed34
R8  = 00000736 R9  = 00640002 R10 = ffffffff R11 = 000454b0
R12 = 000451c4 R13 = 00047fec R14 = 0003f794 R15 = 0003eeb4
DFAR = 0000013f  Mode USR32  Flags nzcv if   PSR = 00000110

0003ee6c : e3e00000 : MVN     R0,#0
0003ee70 : e58c014c : STR     R0,[R12,#332]
0003ee74 : e58c0170 : STR     R0,[R12,#368]
0003ee78 : e58c0140 : STR     R0,[R12,#320]
0003ee7c : e58c0144 : STR     R0,[R12,#324]
0003ee80 : e58c0148 : STR     R0,[R12,#328]
0003ee84 : e1a00008 : MOV     R0,R8
0003ee88 : eafffe62 : B       &0003E818
0003ee8c : e92d4000 : STMDB   R13!,{R14}
0003ee90 : e58ca14c : STR     R10,[R12,#332]
0003ee94 : e59ae140 : LDR     R14,[R10,#320]
0003ee98 : e24ee004 : SUB     R14,R14,#4
0003ee9c : e58ce170 : STR     R14,[R12,#368]
0003eea0 : e8bd8000 : LDMIA   R13!,{PC}
0003eea4 : e92d4000 : STMDB   R13!,{R14}
0003eea8 : e58ca118 : STR     R10,[R12,#280]
0003eeac * e59ae140 * LDR     R14,[R10,#320]
0003eeb0 : e24ee004 : SUB     R14,R14,#4
0003eeb4 : e58ce13c : STR     R14,[R12,#316]
0003eeb8 : e8bd8000 : LDMIA   R13!,{PC}
0003eebc : e92d5fff : STMDB   R13!,{R0-R12,R14}
0003eec0 : e59ae140 : LDR     R14,[R10,#320]
0003eec4 : e24ee004 : SUB     R14,R14,#4
0003eec8 : e58ca118 : STR     R10,[R12,#280]
0003eecc : e58ce13c : STR     R14,[R12,#316]
0003eed0 : e51ce134 : LDR     R14,[R12,#-308]
0003eed4 : e35e0041 : CMP     R14,#&41           ; ="A"
0003eed8 : 03a00000 : MOVEQ   R0,#0
0003eedc : 13a00002 : MOVNE   R0,#2
0003eee0 : 159a1140 : LDRNE   R1,[R10,#320]
0003eee4 : 159a2144 : LDRNE   R2,[R10,#324]
0003eee8 : 051c1330 : LDREQ   R1,[R12,#-816]

R15 = 0003eeb4 = +36eb4 in application memory
R14_usr = 0003f794 = +37794 in application memory
          Function call to 0003eea4 = +36ea4 in application memory

but after staring at the relevant code for some time I can’t see where the problem is.

I have an old copy of the source (from patching in MIDI support before my module was written). While it shouldn’t be causing any weird problems, I do wonder why the DataLoadAck function is setting the length of message to 20?

The question I would raise is what is this block of memory? The dump clearly shows executable code at this address (&3EEB4), yet Maestro is written in BASIC. Were you saving a file from StrongEd or something, as that is indicated as the current task.

Yes – that’s a fault being raised in StrongEd. My copy (v4.69b5) has that exact same code a few instructions earlier.

The issue as indicated by the ZeroPain log is that this instruction is faulting:

LDR     R14,[R10,#320]

What this means is to load a word of data into R14 from the address pointed to by R10 plus 320. Most likely some sort of array offset, that. The problem is that R10 is &FFFFFFFF (or -1).

We’ll likely need to kick this one over to Fred Graute to match up that bit of code to what StrongEd is actually doing at that point. The question for you in the meantime is how are StrongEd and Maestro related? Were you only dragging files from the filer?

Hmm. That’s interesting. It does seem to be an interaction with StrongED (which is pretty much always on my iconbar). If it’s not present, then the ZeroPain log isn’t created. However, I’m simply double-clicking a music file from the Documents directory while Maestro is loaded – StrongED’s just sitting there doing nothing.

This is the code that seems to trigger the log:

DEF PROCDataLoadAck(ref%)
LOCAL block
block=Window%
block!0 = 20
block!12 = ref%
block!16 = 4 :REM DataLoadAck
SYS SendMessage,17,block :REM acknowledge message
IF doing_scrap_load% THEN doing_scrap_load% = FALSE
ENDPROC

Window% is a pointer to a buffer that should be plenty big enough for the message block.

This is the code that seems to trigger the log:

There a few mistakes in Maestro’s PROCDataLoadAck.

The message is supposed to contain a copy of the DataLoad message received.

The message length should reflect the amount of data in the block, as Rick has already pointed out.

The SWI call doesn’t specify which task to send the DataLoadAck to, so it becomes a broadcast. StrongED gets the broadcast too, it fails because it didn’t send a DataLoad to Maestro. (I need to figure out why StrongED doesn’t ignore the message because it has an unknown reference number.)

I managed to fix the issue by changing PROCDataLoadAck to:

DEF PROCDataLoadAck(ref%)
LOCAL block
  block=Window%
  block!0 = 256
  block!12 = ref%
  block!16 = 4 :REM DataLoadAck
  SYS "Wimp_SendMessage",17,block,task% :REM acknowledge message
  REM                            ^^^^^^
  IF doing_scrap_load% THEN doing_scrap_load% = FALSE
ENDPROC

There a few mistakes in Maestro’s PROCDataLoadAck.

Fred – thanks, that’s marvellous. I had tried updating the buffer size, but I missed the task reference. I’m making some more changes to Maestro at the moment, so I’ll make these fixes and submit to ROOL.

The SWI call doesn’t specify which task to send the DataLoadAck to, so it becomes a broadcast.

<facepalm>

I knew there was something wrong there. I spent some time looking in the PRMs to see if it was supposed to be an Ack’d message (19 vs 17). The PRMs don’t seem to specify.
Then I had to go out.

I never imagined that Maestro would be so dumb as to broadcast its reply. :-/

Nice to see “task%” being used as a LOCAL to hold the task handle of the message sender, when “task%” is also a global holding the value “TASK” (as used in Wimp_Initialise and Wimp_CloseDown). Great programming style…

Nice to see “task%” being used as a LOCAL to hold the task handle of the message sender, when “task%” is also a global holding the value “TASK” (as used in Wimp_Initialise and Wimp_CloseDown). Great programming style…

Heh :) The source code is pretty hair-raising in places. What’s interesting is that it seems (to me) to have been written while RISC OS was still being worked on – there’s a few bits where they’ve clearly commented about how to do x or y, and REMed out older alternatives. The code for loading the templates, for instance, is incredibly convoluted, making me think they were still working out how to do it.

What’s interesting is that it seems (to me) to have been written while RISC OS was still being worked on

I don’t find this surprising at all. I’m more used to the problem of documenting things while they’re still be worked on, but the same considerations apply: if you don’t start work until something else is finished, your final release will be delayed, and you can’t afford that.

The source code is pretty hair-raising in places. What’s interesting is that it seems (to me) to have been written while RISC OS was still being worked on

You don’t know how right you are…

Would have replied an hour ago, but I wasted time hacking ArchiEmu to get it to load floppy discs, until I gave up and reverted to the RC14 image. Some change in the memory management is upsetting ArchiEmu…

At any rate, Maestro predates RISC OS! Those of us with a certain amount of grey hair would know about things like that. :-)

Some of us have white hair, never mind a certain amount of grey…I’d forgotten Maestro was on Arthur though. I bought a suite of Archimedeses for the Technical and Vocational Education Initiative in Stornoway when they first came out. Fantastic machines for the time.

The source code is pretty hair-raising in places.

Absolutely. It appeared that Window% doesn’t point at the start of the memory block but at the second word. To get the start of the block you have to do Window%+handle% where handle% = -4. Took me a while to figure this out.

That said, with Maestro being as old as it is, it’s a mazing that it’s still working on modern day hardware.