| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
|
|
|
| |
* osdcomm.h: Move definition of EQUIVALENT_ARRAY to coretmpl.h
* sharc.cpp, gt64xxx.cpp, ym2413.cpp, gb_lcd.cpp, snes_ppu.cpp: Use STRUCT_MEMBER for save state registration
* gio/newport.cpp, megadrive/svp.cpp, nes_ctrl/bcbattle.cpp, arm7.cpp, tms9995.cpp, pckeybrd.cpp, sa1110.cpp, sa1111.cpp, jangou_blitter.cpp, vic4567.cpp: Use std::fill(_n) instead of memset
* emucore.h: Remove obsolete typedef
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
All of these variables are either:
1. Already initialized in the constructor or start/reset; or
2. Guarded against read-before-write by program logic; or
3. Documented as being in an undefined state at device power-up.
Regarding the last point, my view is that if the documentation states the value is unpredictable/undefined at power up, I'd rather not initialize it to an arbitrary value. The absence of initialization in the code counts as documenting this behaviour, or conversely, initializing it to an arbitrary zero documents something which is not factual. While there is an argument for consistency in emulation, I'd rather expose and address any such undocumented hardware behaviour.
I believe the only required and missing initialization here is for integer register zero, which was indeed a bug. If there are any other test cases which fail after this reversion, please let me know and I'll investigate and address them.
|
| | |
|
| | |
|
| |
|
|
| |
This fixes a bug causing IRIX to crash on 4D/20. Specifically, IRIX doesn't handle the case where the pc is pointing to an unmapped address when an interrupt occurs; presumably on real hardware this doesn't happen because the instruction fetch happens before interrupts are tested (or the pc isn't updated until after), and the fetch exception is prioritised over the incoming interrupt.
|
| | |
|
| |
|
|
|
|
| |
Some fixes identified by MIPS Rx3230 diagnostics:
* assert/clear irq based on fpu exception state
* mask entryhi/lo reserved bits
|
| | |
|
| |
|
|
|
|
|
| |
While this behaviour is undefined according to the MIPS R4000 Microprocessor User's Manual, various factors point toward it most likely being correct, including:
1. The fact MIPS-I exposes 16x64-bit floating-point registers, but internally implements them as pairs of 32-bit registers (with only the even-numbered pairs being valid for arithmetic operations), making it somewhat likely MOV.S, like LWC1 and SWC1, can access either half.
2. Explicit mention in IDT documentation and "See MIPS Run", i.e. "The odd-numbered registers can be accessed by move and load/store instructions", and other commentary.
3. The presence of paired-single operations in later MIPS32/64 specifications, which operate on independent single-precision values stored in each of the lower and upper halves of a single floating-point register.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This effectively reverts b380514764cf857469bae61c11143a19f79a74c5 and
c24473ddff715ecec2e258a6eb38960cf8c8e98e, restoring the state at
598cd5227223c3b04ca31f0dbc1981256d9ea3ff.
Before pushing, please check that what you're about to push is sane.
Check your local commit log and ensure there isn't anything out-of-place
before pushing to mainline. When things like this happen, it wastes
everyone's time. I really don't need this in a week when real work™ is
busting my balls and I'm behind where I want to be with preparing for
MAME release.
|
| |
|
|
|
| |
This reverts commit c24473ddff715ecec2e258a6eb38960cf8c8e98e, reversing
changes made to 009cba4fb8102102168ef32870892438327f3705.
|
| |
|
|
| |
BCzF/BCzT can be used (by reading input lines) when coprocessor 2 or 3 are enabled, even when there's no real coprocessor hardware.
|
| |
|
|
|
|
|
|
| |
Code refactoring makes the changes hard to isolate, but the main improvements are:
* implemented fpu instructions and exceptions
* corrected swl/swr implementation
* tlb mru lookup optimization
* interrupt and privilege debugger breakpoints
|
| | |
|
| | |
|
| |
|
|
|
|
| |
* set the coprocessor error number in the cause register
* corrected side-effect handling in address translation
* added logging for RISC/os system calls
|
| | |
|
| |
|
|
|
|
| |
* corrected cop0 context register encoding
* corrected invalid tlb entry exception vector
* improved logging
|
| |
|
|
| |
Make sure the exception target address isn't incremented.
|
| |
|
|
| |
I introduced this error when adding tlb support and modifying the exception code previously. This resolves the error, cleans up delayed branch handling and fixes a panic in the mips rx2030 and rx3230 driver.
|
| |
|
|
| |
template parameters, etc.)
|
| | |
|
| | |
|
| |
|