Original PR in WinUAE : https://github.com/tonioni/WinUAE/pull/561
"
In plain C (Hatari, Previous) TRY/CATCH is built on setjmp()/longjmp().
A non-volatile automatic variable that is modified after setjmp() and
read after the longjmp() back has an indeterminate value (C11 7.13.2.1):
the compiler may keep it in a register that longjmp() restores to its
value at setjmp() time.
Add TRY_VOLATILE next to the other TRY/CATCH helpers in mmu_common.h.
It expands to volatile in the C build and to nothing in C++, where
try/catch has no such restriction and code generation stays unchanged.
Use it for the locals that are changed inside a TRY block and read
after an exception:
- f in m68k_run_mmu060/040/030: the pre-instruction CCR snapshot the
CATCH restores for instruction restart.
- first in m68k_run_1_ce, m68k_run_2ce and m68k_run_2p.
- extracycles in m68k_run_3ce.
- descr_num, descr_addr, descr_types, page_addr and cache_inhibit in
mmu030_table_search, which are used after a bus error during the
table walk.
"
Previous commit allows switching memdump from physical to MMU
translated mode, but not back. Fix that.
Also reorganize & document the dumping function a bit.
`m [s|u] [b|w|l] <address>` reads logical addresses through the MMU as
supervisor (s) or user (u) data instead of physical memory, so a
breakpoint script can inspect a kernel stack or a process's memory. The
address space is independent of the item size; items the MMU can't
translate print as "--"; `m` without arguments continues in the same
address space; and s/u fail unless an MMU is translating. Works with the
68030, 68040 and 68060 MMUs.
The translation uses the core's debugger functions
(debug_mmu030_translate / debug_mmu_translate), which don't write the
descriptors' used/modified bits but do flush the ATC, and whose faults
stay out of the trace.
Tested with a hand-built page table on 68030/040/060 (`m u` returns the
mapped physical pages, across a page boundary; an unmapped page prints
"--"), in user processes under Atari System V (030) and m68k Linux
(040/060), and without an MMU.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
An MMU page fault showed in the cpu_exception trace only as a bus error,
without what caused it. Log the faulting address, direction, function
code and PC, with the SSW (68030, 68040) or FSLW (68060). Faults from
the debugger's own translations (mmu_debugger set) are not logged.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Add several AI-assisted STE and Falcon programs recenly announced at
Atari-Forum, which seem both actively developed and tested on real HW.
(They are tested both by developer and users, though STE game
developers might have either STE or MegaSTE, not both.)
Updated also notes for few already listed games.
As the TT uses a 32.215905 MHz master clock divided by 320,640,1280 and 2560 we get
some slightly faster replay frequencies of 50337, 25169, 12584, 6292 Hz on TT
instead of 50066, 25033, 12517, 6258 Hz on STE
Hatari sets _bootdev (0x446) to the boot drive before TOS starts, but a
cold start of TOS 1.04, 1.06, 1.62, 2.06 or 4.04 clears low RAM,
including it, and TOS then sets _bootdev only from its own boot (a
floppy or a hard-disk driver's boot sector), which a GEMDOS HD boot has
neither of. So it stays 0 and programs that build paths from it look on
drive A. TOS 3.06 leaves the variable alone and EmuTOS sets it itself;
with --fast-boot TOS skips the RAM clear and the pre-boot value
survives.
Write it once more from GemDOS_Boot(), after TOS has initialised and
before the AUTO folder runs; later changes (MiNT, drivers) are left
alone.
Measured with a probe in the AUTO folder and on the desktop, booting
from a GEMDOS HD with fast boot off: _bootdev is 2 in both places on all
of these TOS versions. Dgetdrv() in the AUTO folder still returns 0 on
them; that is TOS's own state.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Reading register 7 cleared scsi->irq but left the TT-MFP GPIP7 line
high (the Falcon path already clears its FDC IRQ source), so after the
first interrupt every later one made no edge on the MFP. Atari System V
waits for these interrupts and loops on "SCSI bus timedout, resetting".
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
scsi_emulate_analyze() starts from the previous command's
ScsiBus.data_len, and MODE SELECT had no case of its own, so a MODE
SELECT (6) or (10) with an empty parameter list asked for a DATA OUT
phase of that stale length (18 bytes after a REQUEST SENSE). The bus
then stayed in DATA OUT and the following commands never reached the
target. WinUAE's scsi.cpp has the same two cases.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
MODE SENSE gains the format device page (3): 32 sectors per track, the
block size, hard sectored; it is also in the all-pages reply. Page 4 now
reports the cylinders for the same 128 heads x 32 sectors geometry; it
reported hdSize/128 cylinders, i.e. one sector per track. Page 4's mode
data length is now 27, matching the 28 bytes sent (it said 24).
Co-Authored-By: Claude Fable 5.1 <[email protected]>
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Nicolas Pomarède