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?

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.

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.)

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.

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.