Soft reset (a real one)

[GoogleCodeExporter]

Implementation of a soft-reset feature, one that doesn't just 'close and
reload' the rom.

To know this is working you would see the fade out effects in Super Mario 64.

This is a highly requested feature...

Original issue reported on code.google.com by sgorman07@gmail.com on 18 Apr 2008 at 4:33

[GoogleCodeExporter]

what is this used for? Who's requesting the feature?

Original comment by ebenbl...@gmail.com on 18 Apr 2008 at 5:07

[GoogleCodeExporter]

Used for reseting the ROM, and the WHOLE TAS community... plus me

Original comment by sgorman07@gmail.com on 18 Apr 2008 at 5:29

[GoogleCodeExporter]

(05:53:10 PM) sgorman07@hotmail.com: <DeHackEd> so we just set REGS.STATUS |= 
1<<20;
and cause an interrupt?
(05:54:14 PM) nicholas: have a look how a MI interrupt is generated
(05:54:25 PM) nicholas: that I think form meory is hardware interrupt 0
(05:54:36 PM) sgorman07@hotmail.com: from memory*
(05:54:37 PM) nicholas: reset is probaly like hardware interrupt 1
(05:54:40 PM) sgorman07@hotmail.com: o
(05:54:40 PM) sgorman07@hotmail.com: k
(05:54:49 PM) nicholas: from memory = my memory
(05:58:38 PM) sgorman07@hotmail.com: can i just post this convo
(05:58:41 PM) sgorman07@hotmail.com: in the issue tracker
(06:01:10 PM) nicholas: work out what you need from it .. but I could be wrong 
it
needs to be tested

Original comment by sgorman07@gmail.com on 19 Apr 2008 at 12:45

[GoogleCodeExporter]

I agree, this is a good feature. Its probably necessary for any automated 
testing 
of video plugins.

Sometimes after I start emulation, then end, then restart I get odd effects 
from 
some portion of the emulator state not being cleaned properly. A good one is 
try to 
load Nameco Museum and disable audio sync (to test the bug or any potential 
fix) 
then enable it and try to get the ROM working. I need to close mupen and reopen 
it 
to get things clean. 

I sort of wish the forum was up as I found a few items of discussion for 
automated 
testing and savestate previews while poking around in Rice.

Original comment by sknau...@wesleyan.edu on 19 Apr 2008 at 4:34

[GoogleCodeExporter]

We're using the Google Group (mupen64plus) for technical discussions, at least 
while
emutalk is down.  You can set it up as a mailing list or check it online.

I don't think that this feature is necessary or helpful for automated video 
plugin
testing; I'm going to add a couple of other small features for that.

Original comment by richard...@gmail.com on 19 Apr 2008 at 4:49

[GoogleCodeExporter]

This feature will have to tested against all four r4300 emulators (interp, pure
interp, x86 dynarec, and 64-bit dynarec).  It will require stopping the core,
modifying it's state, and then restarting it.  The R4k manual which okaygo 
uploaded
gives the following information in section 4.6.2:

A soft reset exception occurs when the SI_Reset signal is asserted to the 
processor.
This exception is not maskable. When a soft reset exception occurs, the 
processor
performs a subset of the full reset initialization. Although a soft reset 
exception
does not unnecessarily change the state of the processor, it may be forced to 
do so
in order to place the processor in a state in which it can execute instructions 
from
uncached, unmapped address space. Since bus, cache, or other operations may be
interrupted, portions of the cache, memory, or other processor state may be
inconsistent. In addition to any hardware initialization required, the following
state is established on a soft reset exception:

• The BEV, TS, SR, NMI, and ERL fields of the Status register are initialized 
to a
specified state.
• The ErrorEPC register is loaded with PC-4 if the state of the processor 
indicates
that it was executing an instruction in the delay slot of a branch. Otherwise, 
the
ErrorEPC register is loaded with PC. Note that this value may or may not be 
predictable.
• PC is loaded with 0xBFC0_0000.

Cause Register ExcCode Value: None
Additional State Saved: None
Entry Vector Used: Reset (0xBFC0_0000)
Operation:
StatusBEV <- 1
StatusTS <- 0
StatusSR <- 1
StatusNMI <- 0
StatusERL <- 1
if InstructionInBranchDelaySlot then
ErrorEPC <- PC - 4
else
ErrorEPC <- PC
endif
PC <- 0xBFC0_0000

Original comment by richard...@gmail.com on 19 Apr 2008 at 4:59

[GoogleCodeExporter]

The problem is I am still learning how all this stuff works, Richard, are you 
saying
you understand how to implement this? This feature is something NO other 
emulator
does correctly.

Original comment by sgorman07@gmail.com on 19 Apr 2008 at 8:09

[GoogleCodeExporter]

Yeah I understand how to implement this.  I thought about it this morning and
realized that you wouldn't have to actually shut down and restart the core.  
There's
an interrupt checking function which is called almost every cycle, even from the
dynarec.  This function just needs to correctly handle resetting the virtual 
CPU's
state according to the specs given in that manual.  The only potential problem 
is if
the custom VR4300 cpu used in the N64 actually does this reset handling 
differently
from what's described in that r4k manual, but I think this is unlikely.

Original comment by richard...@gmail.com on 19 Apr 2008 at 12:45

[GoogleCodeExporter]

Original comment by richard...@gmail.com on 19 Apr 2008 at 3:34

[GoogleCodeExporter]

This is a new feature.  High priority should be used for important bug fixes or 
new
features which are in the critical path (other features/fixes depend upon them).

Original comment by richard...@gmail.com on 19 Apr 2008 at 4:30

• Added labels: Priority-Medium
• Removed labels: Priority-High

[GoogleCodeExporter]

This is great news then! You have become a hero to many.

Original comment by sgorman07@gmail.com on 19 Apr 2008 at 5:05

[GoogleCodeExporter]

Richard, how is this coming along?

Original comment by sgorman07@gmail.com on 22 Apr 2008 at 5:02

[GoogleCodeExporter]

I just had a thought.  Right now resetting the hardware state, loading the rom, 
and
beginning execution all happens in go().  Due to work on the debugger, I would 
like
the ability to load the rom, setup the hardware state (registers, memory, etc) 
and
then actually start emulating via a separate call.

maybe splitting go() into reset_hardware() and begin_emulation()  could meet 
the need
here?

Original comment by jezte...@gmail.com on 23 Apr 2008 at 6:41

[GoogleCodeExporter]

I don't have any problem with that; I'll split it and clean it up when I work 
on this
feature.

Original comment by richard...@gmail.com on 24 Apr 2008 at 12:28

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

feature added in rev 793.

Original comment by richard...@gmail.com on 21 Jul 2008 at 12:24

• Changed state: Fixed