@tonyw
Howcome that REDDebugger worked with AOS4.1upd4 ?
What has changed ?
Or other way around, how can I sort of "downgrade" my X1000 to upd4 in order to keep on developing/using REDDebugger ? (Dualboot wouldn't be a problem for me)
Thanx for infos
Amiblitz 3.5 Debugger doesn't work since Update 5
Re: Amiblitz 3.5 Debugger doesn't work since Update 5
Have you tried using Sys:Kickstart/Kernel from Update 4?
Re: Amiblitz 3.5 Debugger doesn't work since Update 5
No, I did not try kernel from upd4. I'll do, and report back
Edit:
However, as I haven't a X1000 related upd4 kernel, I can only use SAM440 kernel, on my X1000. This probably won't work, won't it ? The kernel is machine depended, isn't it ? But I give it a try, probably screwing it up... but isn't it great we can then just boot from CD
Edit:
However, as I haven't a X1000 related upd4 kernel, I can only use SAM440 kernel, on my X1000. This probably won't work, won't it ? The kernel is machine depended, isn't it ? But I give it a try, probably screwing it up... but isn't it great we can then just boot from CD
Re: Amiblitz 3.5 Debugger doesn't work since Update 5
Don't try it, the kernels are machine dependent.
Re: Amiblitz 3.5 Debugger doesn't work since Update 5
I believe this due to an old bug in the OS4 68K exception handler code. I've done experiments and found some exceptions work whereas other don't. For example ILLEGAL is broken which is needed for debugging.
It also only works as it should when disabling JIT. The following E program demonnstrates a few execptions based on the classic Abacus example. A division by zero is accepted, as is an odd long word read and a TRAP #0. ILLEGAL breaks it. Without JIT I found the execption is executed and an exeption number returned. I think the odd read is ignored. With JIT it's almost like the exceptions are ignored as the number returned is always 0. Except ILLEGAL results in an 8000007 guru with an out of range stack pointer.
MODULE 'exec/tasks'
PROC main()
DEF task:PTR TO tc,code,div,digit1,digit2,odd:PTR TO LONG,long
task:=FindTask(NIL)
code:=task.trapcode
task.trapcode:={trap}
task.trapdata:=0
PrintF('Div by 0: \n')
digit1:=10
digit2:=0
div:=digit1/digit2
PrintF('We made it! \d\n\n',task.trapdata)
task.trapdata:=0
PrintF('Odd read: \n')
odd:={odd}+1
long:=odd[]
PrintF('We made it! \d\n\n',task.trapdata)
task.trapdata:=0
PrintF('Trap #0\n')
TRAP #0
PrintF('We made it! \d\n\n',task.trapdata))
task.trapdata:=0
PrintF('Illegal\n')
ILLEGAL
PrintF('We made it! \d\n\n',task.trapdata)
task.trapcode:=code
RETURN
trap:
MOVE.L A0,-(A7)
MOVE.L 4,A0
MOVE.L 276(A0),A0
MOVE.L 4(A7),46(A0)
MOVE.L (A7)+,A0
ADDQ.L #4,A7
RTE
ENDPROC
It also only works as it should when disabling JIT. The following E program demonnstrates a few execptions based on the classic Abacus example. A division by zero is accepted, as is an odd long word read and a TRAP #0. ILLEGAL breaks it. Without JIT I found the execption is executed and an exeption number returned. I think the odd read is ignored. With JIT it's almost like the exceptions are ignored as the number returned is always 0. Except ILLEGAL results in an 8000007 guru with an out of range stack pointer.
MODULE 'exec/tasks'
PROC main()
DEF task:PTR TO tc,code,div,digit1,digit2,odd:PTR TO LONG,long
task:=FindTask(NIL)
code:=task.trapcode
task.trapcode:={trap}
task.trapdata:=0
PrintF('Div by 0: \n')
digit1:=10
digit2:=0
div:=digit1/digit2
PrintF('We made it! \d\n\n',task.trapdata)
task.trapdata:=0
PrintF('Odd read: \n')
odd:={odd}+1
long:=odd[]
PrintF('We made it! \d\n\n',task.trapdata)
task.trapdata:=0
PrintF('Trap #0\n')
TRAP #0
PrintF('We made it! \d\n\n',task.trapdata))
task.trapdata:=0
PrintF('Illegal\n')
ILLEGAL
PrintF('We made it! \d\n\n',task.trapdata)
task.trapcode:=code
RETURN
trap:
MOVE.L A0,-(A7)
MOVE.L 4,A0
MOVE.L 276(A0),A0
MOVE.L 4(A7),46(A0)
MOVE.L (A7)+,A0
ADDQ.L #4,A7
RTE
ENDPROC
Last edited by Hypex on Sat Jul 22, 2017 1:38 pm, edited 1 time in total.
Re: Amiblitz 3.5 Debugger doesn't work since Update 5
@Hypex
well, from what I understand you try to say, is something similar to what had been brought forward/reposted from AmiBlitz Devs:
http://forum.hyperion-entertainment.biz ... 193#p15116
However, AmiBlitz and Debugger ran fine on SAM OS4.1 upd 4... something must have been changed, or it is some sort of HW related. Not beeing able to keep on going with my iBatch Project http://www.geobiz.de/ibatch.html really hecks me off. It is sad...
well, from what I understand you try to say, is something similar to what had been brought forward/reposted from AmiBlitz Devs:
http://forum.hyperion-entertainment.biz ... 193#p15116
However, AmiBlitz and Debugger ran fine on SAM OS4.1 upd 4... something must have been changed, or it is some sort of HW related. Not beeing able to keep on going with my iBatch Project http://www.geobiz.de/ibatch.html really hecks me off. It is sad...
Re: Amiblitz 3.5 Debugger doesn't work since Update 5
I just tested my program on the X1000. By itself it crashes at the "TRAP #0" instruction. Though first from trying to load into a register and another after that in a trap. However, I tried disabling JIT and it worked! Well it got past the "TRAP #0" at least.
So I suggest locating that program that is crashing listed in the crashlog and put it on the blacklist in Compatibility. You may need to also blacklist parent programs such as AmiBlitz itself it it loads it up the debugger itself.
If knew TRAPs were supported I wouldn't have gone to the trouble of emulating a trap code interrupt when patching the AmigaE compiler and debugger to work on OS4! I modified it to put three NOPs in so I could patch it to a JSR in the debugger to emulate an ILLEGAL trap code exception. I could have just changed an ILLEGAL to a TRAP and have it work! Doh! Well in theory at least.
So I suggest locating that program that is crashing listed in the crashlog and put it on the blacklist in Compatibility. You may need to also blacklist parent programs such as AmiBlitz itself it it loads it up the debugger itself.
If knew TRAPs were supported I wouldn't have gone to the trouble of emulating a trap code interrupt when patching the AmigaE compiler and debugger to work on OS4! I modified it to put three NOPs in so I could patch it to a JSR in the debugger to emulate an ILLEGAL trap code exception. I could have just changed an ILLEGAL to a TRAP and have it work! Doh! Well in theory at least.
Re: Amiblitz 3.5 Debugger doesn't work since Update 5
@Hypex
I don't really understand everything you are talking about, as I am not that much into Amiga programming Interface/68k System Architecture. But I put both programs AmiBlitz and REDDebugger on Blacklist already. I'll retry. Once I have got some time, I will get a SAM440 and update it with upd5, in order to check wether it is a upd5 problem or a X1000+upd5 problem.
regards Gero
EDIT:
All Amiblitz related programs including Amiblitz itself and REDDebugger are on the Blacklist, still same problem.
I don't really understand everything you are talking about, as I am not that much into Amiga programming Interface/68k System Architecture. But I put both programs AmiBlitz and REDDebugger on Blacklist already. I'll retry. Once I have got some time, I will get a SAM440 and update it with upd5, in order to check wether it is a upd5 problem or a X1000+upd5 problem.
regards Gero
EDIT:
All Amiblitz related programs including Amiblitz itself and REDDebugger are on the Blacklist, still same problem.
Re: Amiblitz 3.5 Debugger doesn't work since Update 5
Possibly it could be something to do with the X1000's CPU? I think OS4's Exec has different code for each type of CPU, and so I can imagine that a hairy work-around that works on one CPU might not work on another type of CPU. Just a guess.
Re: Amiblitz 3.5 Debugger doesn't work since Update 5
Sorry gerograph just getting a bit technical there.
I don't know what has stopped it from working. I did a test, I disabled petunia in Kickstart to kill off JIT, but the result was the same. How many OS4 installs do you have? Perhaps disable it in your Kicklayouts and see if it makes any difference.
Blacklisting the debugger is hard as it spawns a child process and it may not inherit the JIT status of its parent. So a system wide JIT disable is the only sure way of doing it.
I don't know what has stopped it from working. I did a test, I disabled petunia in Kickstart to kill off JIT, but the result was the same. How many OS4 installs do you have? Perhaps disable it in your Kicklayouts and see if it makes any difference.
Blacklisting the debugger is hard as it spawns a child process and it may not inherit the JIT status of its parent. So a system wide JIT disable is the only sure way of doing it.