English Amiga Board - View Single Post - log write to custom registers with out of bounds addresses

jotd · 02 February 2019, 09:29

Toni, first my example is bad because this register isn't a pointer, but I meant: "log writes to custom chip address where a pointer to chip is required but a fastmem/illegal address is supplied instead".

The test is fairly easy: 0 < ptr < chipsize is ok, others aren't. Of course, you can overtake chipmem by writing an address close to chip max and a big length too. That would be the icing on the cake.

Currently whdload has those features but need MMU and sometimes there are corner cases (Self-modifying code + JIT : no MMU).

It would be cool even if the debugger stopped on those writes, like memory watches.

Why am I asking this?

Well I've done some "chipmem only" => "fastmem" hacks for some games:

- Chaos Engine CD32
- Ultimate Body Blows
- Beneath a steel sky

Those hacks allow to relocate code in fastmem for programs which lazily used one big MEMF_CHIP segment (CD32 versions...). If you ignore this chip flag, since the game relies on that, you potentially get gfx & sfx buffers in fast memory now.

I remember relocating all data pointers back to chipmem (using disassembly and a script) but you can miss some. And it's easy when you have executable (with reloc information) but not when the code isn't really relocatable (like Red Zone for instance, that I'm planning to move to fastmem for a while, a 3D game running only on chipmem, whaaaaaat???)

02 February 2019, 09:29	#3
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,197	Toni, first my example is bad because this register isn't a pointer, but I meant: "log writes to custom chip address where a pointer to chip is required but a fastmem/illegal address is supplied instead". The test is fairly easy: 0 < ptr < chipsize is ok, others aren't. Of course, you can overtake chipmem by writing an address close to chip max and a big length too. That would be the icing on the cake. Currently whdload has those features but need MMU and sometimes there are corner cases (Self-modifying code + JIT : no MMU). It would be cool even if the debugger stopped on those writes, like memory watches. Why am I asking this? Well I've done some "chipmem only" => "fastmem" hacks for some games: - Chaos Engine CD32 - Ultimate Body Blows - Beneath a steel sky Those hacks allow to relocate code in fastmem for programs which lazily used one big MEMF_CHIP segment (CD32 versions...). If you ignore this chip flag, since the game relies on that, you potentially get gfx & sfx buffers in fast memory now. I remember relocating all data pointers back to chipmem (using disassembly and a script) but you can miss some. And it's easy when you have executable (with reloc information) but not when the code isn't really relocatable (like Red Zone for instance, that I'm planning to move to fastmem for a while, a 3D game running only on chipmem, whaaaaaat???)