Quote:
Originally Posted by jotd
Well, simplest thing: if you have one programming error like game writing slightly out of allocated memory block, then you corrupt the system when returning to the OS.
with whdload it can't really happen because even games using the OS are virtualized through kickstart emulation, and some of your productions (Tiny Bobble, Tiny Galaga & Invaders and soon WrongWayDriver so I can play it  ) make a minimal use of the OS so I can trivially patch the calls.
Plus whdload protects memory blocks so nothing can be read or written outside them (exception: blitter going crazy and killing chipmem out of bounds, but that's rare). whdload also has a SNOOP option (with MMU) which checks that custom registers aren't accessed the wrong way (read of write-only register, not waiting for blitter to finish before starting new blit, invalid bits in bplcon...)
Disabling the caches on startup just because someone has a problem is pretty counter-productive. You know how to get/set the VBR and MMU TC so disabling CACR is also easy. Read, write zero, write old value on exit (some 1993-94 ECS 68020-aware games already do that). once again whdload has a NOCACHE option that does exactly that |
Thanks for the information.
I'm aware of these possible issues but wondered if all of my games maybe trigger the same issue because of an oversight (because i re-use my startup/exit code)..