Reading/writing WinUAE Amiga ram areas

[Jobbo]

I'm aware that Soundy has made a WinUAE scanner that can read tagged memory in the WinUAE process.


https://www.pouet.net/prod.php?which=88184


I'd like to do something similar, reading and writing to the WinUAE memory so I can rapidly iterate on data my emulated Amiga is using.


I was wondering if WinUAE has any official way of exposing the right memory area, maybe through shared process memory?


I imagine I can do what Soundy has done after I get familiar with how Win32 lets you do this. But I thought I might as well ask if there is some more official way of doing this?

[Toni Wilen]

No one has asked for it. No, don't just ask, suggest optimal solution too..

[Jobbo]

I don't have anything to propose right now since I don't know much about Win32 shared memory or whatever. But if I get to the point that I'd like some added support inside WinUAE I'll be sure you give you a detailed suggestion.

[Jobbo]

I just wasn't sure if anything close was already covered by the gdb support or something else?

[Jobbo]

I'm actually looking at this now. I've written my own app which will read the WinUAE memory and find some specifically tagged memory string. When I find that I assume that it's my data structure I set up.

This seems to work well enough because I presume WinUAE just has one big allocation for all the memory of the running Amiga.

Well, almost. Knowing one location in Non-chip ram is enough to get to all the other non-chip memory as far as I can tell.

But I can't do the same relative offset trick to get to the chip memory.

I presume this is because WinUAE doesn't actually store one big memory chunk for the entire address space of the Amiga that includes fast and chip and whatever else. My guess is that each region gets it's own alloc.

I'm really just looking for confirmation and then I'll figure out how to tag some part of chip ram so I can get it all to work. I'll have to convert chip addresses relative to that tag and others relative to the other tag.

Anyway maybe that isn't clear, in which case never mind I'll just keep prodding.

[Toni Wilen]

There is no guarantee memory allocations in host side matches Amiga side.

Usually it is big reserved space (that at least allocates full 24 bit address space, usually more) with Amiga memory address spaces allocated with ram and other left unallocated (=access error if accessed) but this only sort of semi-guaranteed in modes where JIT direct can be enabled on the fly.

You need to find some way to query Amiga side to PC side mapping. Anything else will be unreliable and will break in random future versions.

[Jobbo]

I'm really only concerned with stock A500 + 0.5mb expansion at the moment.

I won't be using JIT.

Is it reasonable to assume the 0.5mb of chip is contiguous and separately so is the 0.5mb of expansion ram? I can handle converting for either if that's as good as it gets.

How much of a burden would it be to have WinUAE always manage the first 16mb of Amiga ram as one contiguous buffer, just out of curiosity?

[Jobbo]

Separately, it is eventually going to be problematic that my app is changing WinUAE's Amiga memory under its nose.

Is there any synchronization method already present that I could take advantage of, or is there anything simple you could imagine adding?

I can do some more work to come up with a proposal if not.

[Toni Wilen]

Originally Posted by Jobbo

Is it reasonable to assume the 0.5mb of chip is contiguous and separately so is the 0.5mb of expansion ram? I can handle converting for either if that's as good as it gets.

Single memory "bank" is always contiguous. (but only the non-mirrored part, if for example you have 512k chip ram, only 512k of chip ram in host side is allocated, remaining 3x512k mirrors don't physically exist)

How much of a burden would it be to have WinUAE always manage the first 16mb of Amiga ram as one contiguous buffer, just out of curiosity?

UAE memory bank handling is based on that they can have any host side base address and can be allocated/freed dynamically.

Most likely not going to happen.

Originally Posted by Jobbo

Separately, it is eventually going to be problematic that my app is changing WinUAE's Amiga memory under its nose.

Is there any synchronization method already present that I could take advantage of, or is there anything simple you could imagine adding?

I can do some more work to come up with a proposal if not.

There is no syncronization and won't be because it would make all memory accesses much slower.

It is possible to dynamically redirect memory accesses to another bank by adjusting memory "bank" table access functions (debugger memwatch does that)

But I don't see any need for syncronization because there is no "cache" which would get out of sync. Memory accesses should be always safe and work more or less similar to some DMA HD controller.

Reads or writes won't be atomic but in that case it probably is better to have some way to "stop" emulation temporarily, do memory accesses, restart it.

Probably best way is to use UAE IPC port (named pipe) and implement new commands.

[Jobbo]

Thanks Toni

What I'm doing seems to be working just fine for me for an A500 1meg.

I'm doing some simple synchronization in my Amiga code and the tool code so it'll pause my routine and that does seem good enough.

If I get much further with it and finish up the project I can always share it to see if it's of wider interested and then think of more legit ways to make it work.

For now it's working and it's fun to poke at my Amiga code from somewhere else and see it reacting!