- This topic has 1 reply, 2 voices, and was last updated 5 days, 16 hours ago by
.
-
Posts
-
WHDLoad makes it possible to install quite a lot demos and games, which were originally designed to run only from floppy disks, to your harddisk.
Changelog:
*** 20.1 (13.10.2026)
– upd: the chapter about system monitors/freezers now lists all
supported freezers and describes the generic freezer
interface (signature “ACAF”) which can be implemented by any
freezer to get supported by WHDLoad automatically
– chg: if PROGDIR:WHDLoad.VFS is not found try loading it via the
overlay filehandle of WHDLoad, this should fix
aminet:util/misc/whdautoload.lha
– fix: WArc: icon.library version 37 is now sufficient
– chg: restore serial config only if not allocated via misc.resource
(issue #6935)
– chg: WHDLoadArchiveFS was optimized by paraj, lha decompression
around twice as fast, separate 68020 version WHDLoad.VFS.020
added which must be installed manually if desired
– new: added Custom config Type M for multi-bit cycle gadgets on
a bit range within Custom?/N, allows multiple M/X entries
to share a single Custom?/N
– chg: the slave config string is now strictly validated, malformed
strings (unknown type, missing separators, bit number out
of range, too many labels for a Multi bit range etc.) pop
up a requester and the configuration is then ignored
– chg: the auto-close of the splash window is now suspended while
the left mouse button is held down (detected via an
input.device handler), so an open dropdown on a cycle gadget
(CycleToMenu/VisualPrefs) keeps the window open
– fix: prevented crashes when mixing mouse and keyboard input in
the splash window with CycleToMenu 2.1 active, cursor keys
carrying a modifier qualifier are ignored and GADGETUP events
are only processed for gadgets belonging to our own window
(issue #6972)
– fix: the splash window is now opened before the shadow memory is
allocated, so it always gets the chip memory it needs to open
– chg: on the 68060 write accesses to custom/cia registers are now
completed by the access fault handler itself instead of
executing the faulted instruction a second time, this saves
one of the three exceptions required per snooped write
access, instructions which may access the page more than
once (movem, fpu) are still restarted, as a side effect
accesses like “move.l (a7)+,(custom)” performed in
supervisor mode no longer abort with SNOOPSSPMODI, which
was never an issue in user mode and on 68030/68040
– fix: on the 68060 the access fault handler read dmaconr for the
copjmp/blitter check while the custom page was accessible,
which could leave an atc entry for the supervisor address
space behind and so disable the snooping of supervisor mode
accesses until it was replaced, the read is now done with
the function code of the faulted access
– fix: on the 68040 a clearing write to dmacon corrupted the shadow
copy of dmacon, it was masked with the complement of the
callback address instead of the written value, so from the
first clearing write on the copperlist check was either
silently disabled or walked a list although the copper dma
was switched off, which could abort with BADCOP
– chg: the 68060 access fault handler no longer reads the mmu
tables noncachable on every fault, the address of the page
descriptor is cached and the contents of the custom/cia page
descriptors are taken from the global data, the mmu tables
themselves are mapped PDF_NC instead PDF_NCS
– chg: the copperlist scanner of the 68030/68040/68060 access
fault handlers is faster, the registers which need a special
check are marked in the custom flag table instead of being
selected by a chain of compares, and the check for cend no
longer reads the copper instruction a second time
– chg: the access fault handlers of the 68040/68060 address their
trace vector relative to the global data instead of reading
the vbr, which is around 1 to 3% faster, as a consequence one
of the Snoop options together with NoVBRMove/S is rejected
with a requester on the 68040/68060More info and downloads here:
https://whdload.de/
- You must be logged in to reply to this topic.