Help me debug my shitty code?

[h0ffman]

I've got a bit of an issue with my music disk. It's nearly finished now and I've done all the work on the boot sector and graphical intro while the first tune is loading. However, it seems somewhere between me adding the intro and writting it to track loader, its now incompatible with the 68000!.

Using the basic A600 config, it gets to the point where its about to fire up the music engine and crashes. If I change the CPU to a 68020, it works fine.

If anyone fancys giving me a hand, I can send you the ADF.

Cheers

[Don_Adan]

Originally Posted by h0ffman

I've got a bit of an issue with my music disk. It's nearly finished now and I've done all the work on the boot sector and graphical intro while the first tune is loading. However, it seems somewhere between me adding the intro and writting it to track loader, its now incompatible with the 68000!.

Using the basic A600 config, it gets to the point where its about to fire up the music engine and crashes. If I change the CPU to a 68020, it works fine.

If anyone fancys giving me a hand, I can send you the ADF.

Cheers

Perhaps you using 68020+ commands or odd address error occured, check the guru number for info.

[h0ffman]

Error: 8000 0003 <-???
Task: 000fff6a

Ahhh, googling states that 3 means odd address... hmmm... thought I fixed all them!

Any idea how to trap this before it happens with the WunUAE debugger?

[pmc]

Hey h0ffman - as always mate, I can try and help out.

Feel free to send it over to the usual place

Are you assembling with Devpac...? Do you use an rsreset structure...?

If you have something at an odd address in that kind of structure Devpac will assemble code that'll run OK but will crash with odd address errors when run as a pc relative binary trackloaded from an .adf. I had the same thing myself once... I can only assume Devpac corrects the problem in the background but doesn't announce it's done so == bad in my opinion.

EDIT: also, obviously check for using 'even' (or cnop 0,2 ) statements after any .b data to keep everything word aligned...

[StingRay]

Originally Posted by h0ffman

Any idea how to trap this before it happens with the WunUAE debugger?

You could patch the address error exception vector ($C) and check the stack once it's triggered.

[pmc]

Originally Posted by StingRay

You could patch the address error exception vector ($C) and check the stack once it's triggered.

Ah, cool.

I'm gonna try doing that type of thing next time something of mine crashes, will be interesting.

Back to the original question: Just dropped you a reply h0ffman - depending on the emulated setup I use I either get a crash with no guru or a freeze with no crash. Both happen in different places though...

[h0ffman]

Right, trapped that... what on earth is on the stack at that point and how to I find out where it was???

[StingRay]

Originally Posted by h0ffman

Right, trapped that... what on earth is on the stack at that point and how to I find out where it was???

Exception stack frame on 68000:

dc.w status register
dc.l PC

Thus it's easy to find out where the offending instruction is (move.l 2(a7),a0 -> a0 points to next instruction).

See Section 6 in the 68000 manual for more info.

[h0ffman]

Problem solved, i think.. me being a retard forgot to set the stack pointer! Just ran some tests and all appears to be cool now. That will explain why there was garbage on the stack when it crashed rather than a pointer.

[StingRay]

Originally Posted by h0ffman

Problem solved, i think.. me being a retard forgot to set the stack pointer!

Doesn't explain why it worked on 68020.

Originally Posted by h0ffman

That will explain why there was garbage on the stack when it crashed rather than a pointer.

I don't think so.

[h0ffman]

my 68020 setup has 8 meg fast ram, thus keeping the stack well out of reach. Either way, its working, with NEW bugs!

[h0ffman]

Right think I finally crack the issue, and funilly enough it wasn't in my code!

Whats wrong with this picture....

CIA_AddCIAInt	move.l	d0,CIA_CIASeed
		move.l	a0,CIA_VBR
		lea.l	$dff000,a6
		move.w	#$a000,$9a(a6)		; Enable CIA interrupt (Level6)

		move.l	CIA_CIASeed,d0
		divu.w	#125,D0 		; Defaults to 125 BPM

		move.b	d0,CIA_TimerLo
		lsr.w	#8,d0
		move.b	d0,CIA_TimerHi
	
		move.l	CIA_VBR,a0
		move.l	CIA_CIAVector(a0),CIA_OldIntCode
		move.l	#CIA_IntCode,CIA_CIAVector(a0); Set interrupt vector

4th line down! Activating the interrupt before setting the pointer!!!!!

I'm guessing on the 020, the instructions are in the cache, so it speeds through them before the CIA gets activated. When ran from system environment, even if the old CIA gets executed, the system is still there, thus it doesn't crap out.

So, we are onward bound again.....

[StingRay]

A few minutes ago I checked your code and found exactly that problem too, lev6 still contains the OS interrupt at this point which is of course not a good idea. Also proves that I was right with my assumption that it wasn't stack related.

[h0ffman]

Yep, stack issue only affected A500+ because its as low as $2000 when its running through the boot block. I was decrunching my data over the top of it!!