search

keirf / amiga-stuff

The Unlicense
259 stars 26 forks source link

ATK rounds up upper range of non standard memory range #39

Closed yulquen-74 closed 3 years ago

yulquen-74 commented 3 years ago

Using V1.16 on my A500+ with custom made 68000 accelerator, one of the fast-ram slices starts at 0x200000 and ends at 0xbfcfff (done to exploit as much memory as possible, added using addmem) but ATK says its upper range is 0xbfffff. If I do nothing, the program freezes when it tries to test past 0xbfcfff, but if I manually change the upper to correct value, everything is ok. Other non-standard ranges tests ok, but they have 64KB granularity. No big deal at all, but I thought I could mention it, as other test-software (like analyzer) detects and tests this memory range correctly.

keirf commented 3 years ago

I believe the issue is I detect memory via the Exec memory list, but sometimes these regions are cropped (perhaps to hide metadata regions) and so I expand out to 64kB granularity as I assumed nothing would have finer granularity than that. I suppose the problem here is it collides with CIA space. Actually I'm surprised you can go as far as BFD000 as usually CIA aliases from BF0000 iirc, but I suppose you intercept these memory accesses in the accelerator. I could put in a check not to pad in the BFxxxx range? A pretty direct fix!

yulquen-74 commented 3 years ago

Yes you are correct, the accelerator hides accesses below BFD000 from the mainboard, also when accessed from an external busmaster like the A590. Your suggestion would solve this particular issue and would be very nice! Thanks for quick feedback anyway!

keirf commented 3 years ago

No problem! Please can you test the artifact that will be spat out from this workflow run in about one hour: https://github.com/keirf/Amiga-Stuff/actions/runs/463124839

(slow run because the toolchain cache is empty and being rebuilt)

yulquen-74 commented 3 years ago

It works perfect!

yulquen74 commented 3 years ago

Could you do the same for an additional range if its an easy fix?

I have enabled fast-ram in the 0xdc1000 - 0xdfefff range, which is cropped by ATK to 0xdc0000 - 0xdfffff, effectively overwriting both the RTC 4K (bottom) area, but also the custom chips 4K (top) area (using V1.17). As before, with manual adjusted range it works fine, and also, Analyzer does it correctly.

keirf commented 3 years ago

Can you test the following automated build: https://github.com/keirf/Amiga-Stuff/actions/runs/996126380

yulquen74 commented 3 years ago

Now the range is detected as 0xdc1020 - 0xdfefff, and memory test is successful, very nice!

keirf commented 3 years ago

Great, this will end up in next release.