Jump to content
Jagware
Sign in to follow this  
SebRmv

Software reset?

Recommended Posts

SebRmv    2

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...

 

Share this post


Link to post
Share on other sites
Zerosquare    10

Lazy guy :D

 

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 B)

Share this post


Link to post
Share on other sites
SebRmv    2

Ok then :)

 

Finally did it another way

Share this post


Link to post
Share on other sites
SCPCD    0

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

Share this post


Link to post
Share on other sites
Zerosquare    10

SCPCD : remember, you're supposed not to stop the GPU and the DSP from 68k code, but only from GPU/DSP code :P

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 ;))

Share this post


Link to post
Share on other sites
SCPCD    0
SCPCD : remember, you're supposed not to stop the GPU and the DSP from 68k code, but only from GPU/DSP code :P

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.

Share this post


Link to post
Share on other sites
SebRmv    2

Thanks SCPCD. This is instructive, even if I won't use this finally, at least for AW.

 

Share this post


Link to post
Share on other sites
ggn    0

Just out of curiosity I had a quick peek at the 68000UM and found the following ways to reset the machine:

 

  1. Double bus error (bus error when the corresponding vector will also cause a bus error)
  2. move.l 0.w,sp
    move.l 4.w,-(sp)
    rts

    (registers must be zeroed I guess)

  3. 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)

  4. Errr I dunno, I got bored searching around :P. Run a ppera patch - it should sort itself out :D

Share this post


Link to post
Share on other sites
Zerosquare    10

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 :lol:

Share this post


Link to post
Share on other sites
Tursi    0

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. ;)

 

Share this post


Link to post
Share on other sites
Zerosquare    10
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 :D

Share this post


Link to post
Share on other sites
Zerosquare    10
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.

Share this post


Link to post
Share on other sites
Zerosquare    10

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).

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×