SebRmv Posted December 22, 2012 Report Share Posted December 22, 2012 Hi guys, I don't know whether this topic has already been addressed on the forum. Is there a clean way to make a software reset on the Jaguar? I would like to implement the * + # combination like this... Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted December 22, 2012 Report Share Posted December 22, 2012 Lazy guy I don't think there's a way to do a true hardware reset through software. It wouldn't look very good anyways, because it would rerun the whole boot sequence (logos and delays included). So I'll think you'll have to write your own "reset" code Quote Link to comment Share on other sites More sharing options...
SebRmv Posted December 23, 2012 Author Report Share Posted December 23, 2012 Ok then Finally did it another way Quote Link to comment Share on other sites More sharing options...
SCPCD Posted December 23, 2012 Report Share Posted December 23, 2012 to soft reset the jag, you need to do something like that : wait_blitter: move.l B_CMD, d0 ; Wait end last blitter cmd btst #0, d0 beq.s .wait_blitter move.w #$2700, sr ; movea.l #$4000, sp move.w #$FF00, INT1 ; disable all 68k jaguar interrupts move.w #$FFFF, INT2 ; 68k leave interrupts move.w #$FFFF, VI ; no vbl interrupts move.l #0, G_CTRL ; Stop GPU move.l #$00070007, G_END ; Big Endian move.l #%100011111000000000, G_FLAGS ; Clear Flags and interrupts move.l #0, D_CTRL ; Stop DSP move.l #$00070007, D_END ; Big Endian move.l #%100011111000000000, D_FLAGS ; Clear Flags and interrupts move.l #0, $1000 ; STOP Obj High move.l #4, $1004 ; STOP Obj Low move.l #$1000, d0 swap d0 move.l d0, OLP ; OLP pointer move.w #0, PIT0 ; disable timer move.w #0, PIT1 ; disable timer move.w #0, JPIT2_W ; disable timer move.w #0, JPIT1_W ; disable timer move.w #$3F00, JINT ; disable Jerry interrupts move.l #0, SMODE ; disable audio move.w #0, ASICTRL ; disable juart move.w #0, ASIDATA ; dummy read to clear fifo ;;;;=> reinit blitter regs move.l #$00000000,A1_BASE ; move.l #$00000000,A1_FLAGS ; move.l #$00000000,A1_CLIP ; move.l #$00000000,A1_PIXEL ; move.l #$00000000,A1_STEP ; move.l #$00000000,A1_FSTEP ; move.l #$00000000,A1_FPIXEL ; move.l #$00000000,A1_INC ; move.l #$00000000,A1_FINC ; move.l #$00000000,A2_BASE ; move.l #$00000000,A2_FLAGS ; move.l #$00000000,A2_MASK ; move.l #$00000000,A2_PIXEL ; move.l #$00000000,A2_STEP ; move.l #$00000000,B_COUNT ; move.l #$00000000,B_SRCD ; move.l #$00000000,B_DSTD ; move.l #$00000000,B_DSTZ ; move.l #$00000000,B_SRCZ1 ; move.l #$00000000,B_SRCZ2 ; move.l #$00000000,B_PATD ; move.l #$00000000,B_IINC ; move.l #$00000000,B_ZINC ; move.l #$00000002,B_STOP ; move.l #$00000000,B_I3 ; move.l #$00000000,B_I2 ; move.l #$00000000,B_I1 ; move.l #$00000000,B_I0 ; move.l #$00000000,B_Z3 ; move.l #$00000000,B_Z2 ; move.l #$00000000,B_Z1 ; move.l #$00000000,B_Z0 ; ;;;;<= and go back to your startup code Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted December 23, 2012 Report Share Posted December 23, 2012 SCPCD : remember, you're supposed not to stop the GPU and the DSP from 68k code, but only from GPU/DSP code Same thing for the object list pointer, I'm not sure it's safe to write it outside of the VBL (or even from 68k code at all, even if we all do this ) Quote Link to comment Share on other sites More sharing options...
SCPCD Posted December 23, 2012 Report Share Posted December 23, 2012 SCPCD : remember, you're supposed not to stop the GPU and the DSP from 68k code, but only from GPU/DSP code it's not safe only if you would like to restart it from the last instruction or if you would like to know the last instruction executed by reading the PC register. If you don't care about both, you can kill it this way. Same thing for the object list pointer, I'm not sure it's safe to write it outside of the VBL (or even from 68k code at all, even if we all do this ) The object processor is forced to restart each line at OLP addr, so it's not a problem. Quote Link to comment Share on other sites More sharing options...
SebRmv Posted December 23, 2012 Author Report Share Posted December 23, 2012 Thanks SCPCD. This is instructive, even if I won't use this finally, at least for AW. Quote Link to comment Share on other sites More sharing options...
ggn Posted December 23, 2012 Report Share Posted December 23, 2012 Just out of curiosity I had a quick peek at the 68000UM and found the following ways to reset the machine: Double bus error (bus error when the corresponding vector will also cause a bus error) move.l 0.w,sp move.l 4.w,-(sp) rts (registers must be zeroed I guess) Issue a RESET instruction The RESET instruction does not cause a reset exception; it asserts the RESET signal to reset external devices, which allows the software to reset the system to a known state and continue processing with the next instruction. (possible in conjunction with the above) Errr I dunno, I got bored searching around . Run a ppera patch - it should sort itself out Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted December 24, 2012 Report Share Posted December 24, 2012 If I understand the Jaguar schematic correctly, solutions 1, 2 and 3 won't work as expected, because the reset chain is like this (arrows connect outputs to inputs, signals are not bidirectional) : +-------------+ +-------+ +-----+ | Power-on | | | | | | reset pulse |--->| Jerry |--+-->| Tom | | generator | | | | | | +-------------+ +-------+ | +-----+ | | +-----+ | | | +-->| 68k | | | +-----+ So solutions 1 and 2 should only restart the 68k itself, and solution 3 should have no effect at all. As for solution 4... anything can happen Quote Link to comment Share on other sites More sharing options...
Tursi Posted December 24, 2012 Report Share Posted December 24, 2012 I was actually looking at this problem myself while playing with the GDB stub. At any rate, 2 won't even work for the 68k, because after MEMCON1 is written, there's no ROM at address 0 so no vector available (and it's unclear to me whether you can read the BIOS ROM again without changing MEMCON1 even if you get the right address...? It didn't look like it in the debugger (because it's 8 bits wide).) Solution 1 is curious, didn't know that one. (Of course as Zero mentioned, not useful here anyway.) Also worth noting that 3 doesn't reset the 68k, only the hardware attached to the 68k's reset line. Regarding the risk of writing the OPL from the 68k... I found the OP could lock up in some bad address cases, but I never had it happen just writing from the 68k, so I'm not sure if it only happens if it's allowed to scribble through memory for a longer time or if it's just really, really rare. Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted December 25, 2012 Report Share Posted December 25, 2012 Regarding the risk of writing the OPL from the 68k... I found the OP could lock up in some bad address cases, but I never had it happen just writing from the 68k, so I'm not sure if it only happens if it's allowed to scribble through memory for a longer time or if it's just really, really rare. I suspect it can fail if the OP accesses the OPL register just between the two 16-bit parts of the 68k's 32-bit write access. That's the only reason I can think of that would explain why Atari's code example uses the GPU (which will write the 32 bits in a single bus cycle) to set OPL, while everything else is done with the 68k. Anyways, if it happens, it must be pretty rare. Or maybe the bus arbitration logic don't allow splitting 68k 32-bit accesses at all, and they were just paranoid. Who knows Quote Link to comment Share on other sites More sharing options...
Cyrano Jones Posted January 2, 2013 Report Share Posted January 2, 2013 JMP $802000 Let's be honest here, your cart init code should reset everything and set it all back up again anyway Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted January 3, 2013 Report Share Posted January 3, 2013 True enough Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted January 27, 2013 Report Share Posted January 27, 2013 Regarding the risk of writing the OPL from the 68k... I found the OP could lock up in some bad address cases, but I never had it happen just writing from the 68k, so I'm not sure if it only happens if it's allowed to scribble through memory for a longer time or if it's just really, really rare. I just found something today while rereading the docs : Because the Object Processor could interrupt the 68000 in the middle of a write to this register, the 68000 should never be used to change OLP. Use the GPU instead. This part is in bold, and only appears in the scanned copy Tyrant uploaded some years ago, not in the "Technical Reference Revision 8" PDF file that was released by John Matthieson in 2001. Quote Link to comment Share on other sites More sharing options...
Orion_ Posted January 28, 2013 Report Share Posted January 28, 2013 oops, I think most of the homebrew game does it using 68k Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted January 28, 2013 Report Share Posted January 28, 2013 Yes, I think we've been all guilty of this Quote Link to comment Share on other sites More sharing options...
Cyrano Jones Posted January 31, 2013 Report Share Posted January 31, 2013 If you do it after a VSYNC you should be ok, as (in theory) you have the time from the VBI to the top of the screen being drawn before the OLP will change the register. Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted January 31, 2013 Report Share Posted January 31, 2013 I think there's a possible read/write race collision too : when the OP starts rendering a line, it reads the value of this register, so if it happens while you're updating it, the OP can try to process an object list at a wrong address. Additionally, the documentation instructs you to set VDE to $FFFF so that the OP is always enabled, even outside the visible display area (that's why the two conditional branches at the start of the object list are needed). Nevertheless, the problem doesn't seem to happen in practice (if you access OLP at the start of the VBL, the timing is pretty much fixed anyways). Quote Link to comment Share on other sites More sharing options...
Recommended Posts