Music-X 2.0 (the rare'st thing ever it seems!)

[Thomas Richter]

More information on this. After debugging for a couple of hours, the issue is clear. This is a bug in Music-X. The details are involved.

The program seems to be written in C with some small subroutines optimized in assembler. One of the assembler functions is used for rendering data on the screen. The assembler function incorrectly assumes that the graphics.library call FillRect() preserves register a1, the pointer to the rastport. This is of course nowhere documented and probably just an overview.

By sheer coincidence, a1 contains upon return a pointer to a data structure whose first pointer points to the exec soft interrupt list. Thus, if this (now invalid) pointer is passed into RectFill() again, then this structure is mis-interpreted as rastport. The first pointer of this (faulty) data structure is a pointer to the layer (or should be) and then the LockLayersRom() in P96 trashes the soft interrupt list. The soft interrupt handler within exec then jumps into the wild by handling the incorrect data as struct interrupt, which is is not. It then jumps into the wild, trashing the system.

Thus, bad software. Just with more details this time.

[SyX]

Originally Posted by Thomas Richter

Thus, bad software. Just with more details this time.

Sure, but thanks to your great information, I found the problematic function:

draw_routine
                movea.l (gfxbase).l,a6
                movem.l d0-d3/a0,-(sp)
                jsr     Move(a6)
                addq.w  #1,d0
                subq.w  #1,d2
                move.w  d1,-(sp)
                move.w  d2,-(sp)
                move.w  d3,-(sp)
                move.w  d2,-(sp)
                move.w  d3,-(sp)
                move.w  d0,-(sp)
                move.w  d1,-(sp)
                move.w  d0,-(sp)
                subq.w  #1,d0
                addq.w  #1,d2
                move.w  d1,-(sp)
                move.w  d2,-(sp)
                move.w  d3,-(sp)
                move.w  d2,-(sp)
                move.w  d3,-(sp)
                move.w  d0,-(sp)
                movea.l sp,a0
                moveq   #7,d0
                jsr     PolyDraw(a6)
                adda.w  #$1C,sp
                tst.w   d4
                bmi.s   .exit_draw_routine
                move.l  d4,d0
                jsr     SetAPen(a6)
                movem.l (sp),d0-d3/a0
                addq.w  #2,d0
                addq.w  #1,d1
                subq.w  #2,d2
                subq.w  #1,d3
                jsr     RectFill(a6)

.exit_draw_routine
                movem.l (sp)+,d0-d3/a0
                rts

Then I usually prefer to think that it was only a typing error from the original developers. And if this is the only bug (and this is a big if, because at contrary than you, I haven't wasted more than 5 minutes with the debugger and only by the curiosity for your information), then it can be fixed by adding the register A1 to the first and last movem instruction.


But what I am trying to say, it is that Thomas, a guy that has not interest in this software, has wasted hours of his time for finding the bug and given a lot of information that can help to fix this program. Then somebody with enough interest by running Music-X in those modern configuration could try to fix it and be grateful to all the hard work that people like Thomas is doing for the platform.

[gerul]

Well thanks a lot for taking your time to investigate.
Unfortunately I am not a programmer so I am unable to help.

[Honitos]

Maybe a little Patch would be enough that patches the opcodes of the movem-instructions to save and restore address register a1 as well.

[Don_Adan]

Originally Posted by gerul

Well thanks a lot for taking your time to investigate.
Unfortunately I am not a programmer so I am unable to help.

Then you can ask ross, only 2 bytes must be changed to apply this fix. Because i dont have access to my Amigas, i cant fix this.

[ross]

Here I am, can someone put the executable in the zone for me?
I think that the patch, thanks to those who have already worked on it, is really a matter of a few minutes.

EDIT: ok, I downloaded the ADF from TOSEC collection.
I simply applied the patch SyX suggested, thanks to Thomas' previous work, so pretty much nothing on my end
Fully untested.

EDIT2: removed as it is not working.

[gerul]

It didn't work. Sorry.

[ross]

Originally Posted by gerul

It didn't work. Sorry.

Ok, then the "movem +A1" fix is not enough

Sorry but right now I don't really have the possibility of a proper debugging for a working fix (of course I remain available if others want to look at the code and suggest a patch which I will then apply).

[Don_Adan]

Originally Posted by ross

Ok, then the "movem +A1" fix is not enough

Sorry but right now I don't really have the possibility of a proper debugging for a working fix (of course I remain available if others want to look at the code and suggest a patch which I will then apply).

Do You think that changing also:

from

movem.l (sp),d0-d3/a0

to

movem.l (sp),d0-d3/a0/a1

Can solve crash problem?

[ross]

Originally Posted by Don_Adan

Do You think that changing also:

from

movem.l (sp),d0-d3/a0

to

movem.l (sp),d0-d3/a0/a1

Can solve crash problem?

I'll try this (later this evening)

EDIT: hmm, the problem here is that PolyDraw destroys A1 for SetAPen as well, so the routine should be written a little differently
And also the first Move() could destroy D0 and D1...

[Thomas Richter]

There is more than a single Draw() and a single PolyDraw() that needs to be fixed. Essentially, the whole assembler function needs to be redone. Maybe there are even more assembler functions like this. As said, this program has quite some "issues" by making assumptions that some graphic calls preserve particular registers.

[ross]

Originally Posted by Thomas Richter

There is more than a single Draw() and a single PolyDraw() that needs to be fixed. Essentially, the whole assembler function needs to be redone. Maybe there are even more assembler functions like this. As said, this program has quite some "issues" by making assumptions that some graphic calls preserve particular registers.

Ah, thanks.
Then it's not trivial, it's certainly not about changing a couple of bytes like I did initially...

Well, I go back to the initial consideration: if someone wants to look for every routine that has the registers problem and report it, otherwise I just can't spend the time on it now, sorry.

[gerul]

I've contacted the author and he said that Music-X sources are still copyrighted, so impossible to publish...
I think that leaves a choice: either give up Music-X or give up P96...

[hooverphonique]

Originally Posted by gerul

I've contacted the author and he said that Music-X sources are still copyrighted, so impossible to publish...
I think that leaves a choice: either give up Music-X or give up P96...

Except that given the issues described above, it might as well crash using native graphics, depending on the OS/kickstart version.

[Thomas Richter]

Originally Posted by gerul

I've contacted the author and he said that Music-X sources are still copyrighted, so impossible to publish...
I think that leaves a choice: either give up Music-X or give up P96...

Software only runs out of copyright some 25 years after the death of its author, so that is nothing new. However, as you could reach its author, have you tried the obvious, namely asking for a fix of the (rather obvious) problem?

[gerul]

Originally Posted by Thomas Richter

Software only runs out of copyright some 25 years after the death of its author, so that is nothing new. However, as you could reach its author, have you tried the obvious, namely asking for a fix of the (rather obvious) problem?

Yes I did.
Quote:"Also, the Music-X source code is really bad. I was a young programmer then and very inexperienced and made a lot of mistakes."
He is using a modern tools for his projects now so his interest in reviving Music-X is pretty low. Plus and he doesn't feel very much as a "retro guy"..

But you can try motivate him by yourself
https://soundcloud.com/music-by-talin

[gerul]

Wow, in the latest version of P96 problem was SOLVED !!!