0 Members and 3 Guests are viewing this topic.
You'll have to wait for z80's work before anyone can write screen stuff. Speaking of Z80, I came upon some evidence that the OS naturally runs in 58 MHz mode. It's either that or the program crashed before writing to FRQCR or the OS switches to normal speed every time it exits the application, both of which I think are unlikely. Yes, I was trying to overclock my Prizm
00007000: MOV.L @($0B*4+PC),R15 = #B40000A000007002: MOV.L @($0D*4+PC),R14 = #0000777700007004: MOV $-1, R1300007006: MOV.L @($0D*4+PC),R12 = #0000FFFF00007008: NOP0000700A: NOP0000700C: MOV.W R14,@-R150000700E: MOV.W R14,@-R1500007010: MOV.W R14,@-R1500007012: MOV.W R14,@-R1500007014: MOV.W R14,@-R1500007016: MOV.W R14,@-R1500007018: MOV.W R14,@-R150000701A: MOV.W R14,@-R150000701C: MOV.W R14,@-R150000701E: MOV.W R14,@-R1500007020: ADD R12,R1500007022: DT R1300007024: BF $700C00007026: DT R1500007028: BF $70260000702A: RTS0000702C: 0000 ?0000702E: 0000 ?00007030: .data b40000a0 dword ref:700000007034: 0000 ?00007036: 0000 ?00007038: .data 00007777 dword ref:70020000703C: .data 0000ffff dword ref:7006
I'm just finishing up the screen program right now. If all goes well it shouls draw a couple of blue lines on the screen. Also I would agree the OS runs at 58 MHz. When I ran a looping program I expected it to take about 30 seconds, but instead it finised in 15. @Qwerty, The program that I ran didn't cause a ram reset, but it still sent me to the select language menu. Is that what happened to you.Edit: Finished my display program. Programming in SH3 hex is hard Anyway I did not get blue lines on the screen. This program tested from B4000000 to B5000000. I could test other ranges, but I need ideas.
Hmm, there are a couple of errors you made in your thinking though. DT is not a branch instruction, and conditional branches only execute the following instruction if the BF/S or BT/S variants are used. You are correct about needing something after the RTS, though.
It isn't NOP stands for no operation. When the branches are delayed, the next instruction in the pipeline is executed to avoid as many pipeline errors as possible. The NOP simply doesn't do anything. You could use any instruction in that slot except for another branch or PC dependent instruction and the results would be the same.
It'd be similar to looking for a needle in a pile of needles.
Remember that we don't have access to the physical memory and the call's code is probably located with the rest of the OS functions in physical memory.