forums.ps2dev.org

[bobsbigboy]

I was hoping there was a simple way to disable the reset button, but I guess I wasn't so lucky!

I'm trying to find an easy way to debug code flow of elf's I'm making, and was wondering if there was a simple instruction or couple instructions I could edit into the assembly code to lock-up the PS2 (ie even disable reset)....???

I know I can do simple loops that loop on themselves, but without being able to see anything on the screen, I have no way of knowing whether I'm in the loop I created, or stuck in another loop somewhere.....

It's easy to track down a bug If I put a "lock-up" condition somewhere, and then run...after the run If I cannot even reset, I know I hit my lock-up, If I can still reset, I know I hit the bug/loop first...

I had found by luck when playing with other programs, that doing a 0x00 syscall from the IOP would reset it (I think), and lock-up the console, so I couldn't even use the reset to shut it down..(only power off/on to clear it)...

doing the same reset (0x01) syscall from the EE side doesn't lock it up in the same manner, I can still reset the unit....Could I use another EE syscall, like the Int2IOP, or something, to tie up the IOP and prevent a reset.....or loop on a syscall call...would that do it??

thanks again for everyone's help!

[Foodekatron]

I would look for a good book on it if your programming in it's own assembly code. Since I don't recognize the functions you are using I don't know what compiler you are using and probably can't help so well, as I am a newby with the PS2. However, 8051 assembly was my hobby for about a year. 8051 loads the PROGRAM COUNTER with 0000x AFTER reset. In a typical real time app I would LJMP to code in the next line. What goes in between the reset and the beginning of the program would be the ISRs, or interupt handlers. I found a nice illustration in a book I have so I'll type it here:
NO INTERRUPTS:
>>__________MAIN__________________________________________>>

INTERRUPTS ALLOWED:

>>MAIN>>--ISR-------->>MAIN__>>--ISR-------->>MAIN_____________>>

I guess the Emotion Engine is like the one above more or less and the IO Processor is more dedicated to interrupts like the second, logically. An interrupt is the response to asynchronous events, like the button taps, and hence the name 'IO'. I felt like this might have something to do with your question, and often times when the logic is taken simply, step by step, it becomes clear. You could disable interrupts in developing phase, the program will follow through where it left off when it returns from interrupt if you decide not to. I hope I have turned you on to some type of hint.

[Foodekatron]

An interrupt would be those "asynchronous events", such as a button tap.
Oops

[Guest]

Interrupts...great idea.

Use "DI" to lockup the EE. It means "disable interrupts".

Can't think of an easier one-instruction way to lock someting up...

Assuming I ain't forgetting something :) (like entering kernel mode first...unless some flag in COP0 is set that lets user mode throw DI yada yada...)