m68ki_read_opcode_16 is both a different access path for instructions
(meaning we can decode addresses with certain assumptions), and also can be
implemented faster (always an aligned 16b read).
For some projects, runtime selection of CPU type isn't required,
and burns both time and space. This config option allows a build-
time selection of CPU model.
The static decode jump table is built via m68kmake, and with a project
config can be used by the main runloop.
Add M68K_CYCLE_COUNTING to enable per-instruction cycle counts
versus accumulating a dummy (constant) cost per instruction.
Move the cycle-counting to a macro -- for now, CYCLE_COUNTING is only
supported when using DYNAMIC_INSTR_TABLES (as no static table gen
is provided yet).
Static jumptable saves 256K of RAM, and avoiding cycle counting
saves 320K!
- BCD packed decimal now supported, including k-factor
- Improved FSAVE/FRESTORE including FPU reset when restoring a NULL frame
- FREM instruction supported
- Better disassembly of FPU instructions
- Rewritten to use SoftFloat instead of unportable native FP math
- Support added for Motorola 96-bit extended floats
- More addressing modes and conditions supported
The taitojc games function identically to the old implementation (I stepped
through the main matrix multiply in dendeg and the registers never diverged)
and speed on Core 2 Duo is a wash - sometimes softfloat's faster, sometimes
not, but the difference on -str 90 never exceeded 1%.
m68kmmu.h uses functions from m68kfpu.c which are static, so m68kfpu.c
can't be compiled alone anymore if we want to keep some basic
compatibility... I know, it's not super clean, but it's not my
choice...!
Also pmmu_translate_addr can't be inline anymore because of this (there
are quite a few functions from m68kcpu.h using it, and it can be
included only in m68kcpu.c !)
- Reworked PMMU/core interface so PMMU now sees all cop 0 instructions
- Improved disassembly of PMMU instructions
- Preliminary 68LC040 support
- Fixed disassembly for EC/LC variants of '030/'040
- Added working PMMU address translation (not feature complete, but sufficient
to boot several 68030 Macs in MESS)
- Fixed up disassembly of some PMMU instructions
- Added "68020 with 68851" CPU type
Beefed up the warnings and cleared them up.
m68kfpu.c is no longer included by m68kcpu.c.
Removed a bunch of internal function forward declarations, except for those used by macros.
Converted CRLF line endings to LF.
This means that multiple changes without any execution will be seen as atomic. It also means that PULSE_LINE no longer works for signalling IRQs.
Added checks in the debug build to catch people who try to use
PULSE_LINE for non-NMI and non-RESET input lines on CPUs that no
longer support direct interrupt generation. Over time expect this
list to increase.
Before this patch a:
cpunum_set_input_line(5, ASSERT_LINE);
cpunum_set_input_line(3, ASSERT_LINE);
cpunum_set_input_line(3, CLEAR_LINE);
loses the state of line 5. This patch fixes it by adding an explicit
but optional "virtual irq line" support to the 68k interface.
Fix m68k interrupt handling by some drivers.
Clearing the NMI line to clear all the IRQ lines worked, but it just
doesn't make sense. Now that the irq lines are really independant,
the handling can be simplified.
Changed slapstic management to always install an opbase handler to more
aggressively catch code executing in the slapstic region. Updated all
drivers to separate the slapstic region of ROM into a different ROM
section from the fixed ROM.
As trap#n exceptions are called from within a normal instruction handler
(as opposed to the address error handler that are called via a longjmp),
control will eventually return to the execution loop where the
instructions cycles will be deducted.
This fix adds the cycles for the instructions back to the available
cycles, or we will pay both the cost of the exception, and of the
instruction.
As trap exceptions are called from within a normal instruction handler
(as opposed to the address error handler that are called via a longjmp),
control will eventually return to the execution loop where the
instructions cycles will be deducted.
This fix adds the cycles for the instructions back to the available
cycles, or we will pay both the cost of the exception, and of the
instruction.
If an address error depletes all remaining cycles, control will no
longer re-enter the execution loop. This prevents consuming more cycles
when there are none remaining, and will in such situations no longer
execute at least one instruction from the address error exception
handler.
The address error handler is called after a longjmp that does not pass
the part of the excecute loop that deducts instruction cycles. This
means we should not try to undo the instruction's cycles here, as other
exception handlers do, because this will incorrectly reduce the cost of
the exception by the number of cycles for the current instruction.
For costly instructions like MUL and DIV, this will in effect result in
a net increase of available cycles.
