Overview Features Coding Performance Forum Downloads Products OrderV4 Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.

All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Information about the Apollo CPU and FPU.

"APOLLO SHIELD" Memory Protectionpage  1 2 3 

Peter Slegg

Posts 22
27 Sep 2021 16:43

Where does this sit with a 68060 mmu implementation ?

DiscreetFX Studios

Posts 130
19 Dec 2021 03:53

I always knew AmigaOS had a superior pizza delivery service. On a serious note thanx for developing Apollo-Shield. It looks like a great tool for developers. I’ve been a Linux Application Support Engineer for many years in the FinTech space but I still prefer AmigaOS and ApolloOS for my part time DiscreetFX development work at home. They are my favorite and just seem more exciting and fun. Linux is for work. That’s just my opinion and others maybe feel differently.

Leszek Antyborzec

Posts 1
21 Dec 2021 11:22

It would be very useful to me.
Will it also be available in V2?

Peter Persson

Posts 11
16 May 2022 13:34

This is highly interesting in the context of Atari virtualisation/emulation of key hw registers, and possibly also memory protection for the FreeMiNT kernel (which unlike doesn't require address translation; all that's needed is a way to change the list of "forbidden" memory when switching contexts).

There are also other uses for it. The 030 pmmu was used for other stuff such as keeping track of writes to memory locations without having to go through an exception, for example. This could be highly useful if supported too (doesn't Shapeshifter use this feature for screen emulation?).

Gsteemso Del Canuckistan

Posts 8
08 Jun 2022 04:17

I've been following this discussion of the new Apollo Shield with great interest!

Please correct me if I have missed any details, but as I understand its principles of operation, the Apollo Shield seems to be wholly implemented by two newly-added features:

Feature #1 allows ranges of memory to be “tagged” with permission flags for reading, for writing, and/or for code execution.

--> Questions raised by this summary of feature #1:

(1a) Are those permissions more-or-less independently managed (which would imply eight possible Shield configurations in any given area of memory), or is there some assumption of permissions “accumulating” so that only a handful of options are even possible?  As an example, I can easily envision a concept like “code execution is permitted here” being a superset of “reading data from here is permitted”; it might even be simpler to implement - but if I know in advance that my code is or is not supposed to be self-modifying, I might like to be able to shield against write accesses independently of whether I want code execution to be allowed.

(1b) Are the tagged memory-ranges completely, or near-completely, arbitrary?  Or do they need to be aligned on, for example, specific multiples of 16-bit 680x0 word accesses?  As useful as the first possibility seems, I can well imagine the second method being vastly less complex to implement.

Feature #2 allows admirably detailed reporting on any operation that attempts unsanctioned access to a memory-area tagged with these permissions active.

Have I described all of that information correctly?  And, in either case, are there any other functions of the Shield that have not yet been discussed in this thread?

posts 45page  1 2 3