Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Documentation about the Vampire hardware

Vampire Myth Busting: You Can't Debug On a Vampirepage  1 2 3 

Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
29 Jun 2019 02:18


Renee Cousins wrote:

    I would not try to poke an MMU directly. There's already a clean implementation for AmigaOS that makes programming the MMU quite painless, faster and a lot more stable.
   
    EXTERNAL LINK   

 
  I am no developer, but big thanks for MMULib!
 
  Seems NuForcer EXTERNAL LINK    and its scripts EXTERNAL LINK could work on any m68k 68020/68851+ Amiga as well as Vamps!


Samuel Crow

Posts 424
29 Jun 2019 05:37


Vojin Vidanovic wrote:

Renee Cousins wrote:

    I would not try to poke an MMU directly. There's already a clean implementation for AmigaOS that makes programming the MMU quite painless, faster and a lot more stable.
   
    EXTERNAL LINK   

   
    I am no developer, but big thanks for MMULib!
   
    Seems NuForcer EXTERNAL LINK    and its scripts EXTERNAL LINK could work on any m68k 68020/68851+ Amiga as well as Vamps!

Does MuLib work on the Vampire yet?  I was under the impression that it doesn't.



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
29 Jun 2019 08:10


Regarding the Enforcer question.
 
AMIGA OS has a 4 GB (32bit) address range.
By design AMIGA OS can _NOT_ protect any used memory from getting overwritten. Amiga OS can not prevent crashing.
 
This is a design decision of AMIGA OS.
And because of it, you can not detect access to other programs memory - and you can not prevent them.
 
What you can do, is "detect" access to unused memory
or unused address ranges.
This can also be done on Apollo 68080 CPU.
 
This will NOT help you detect programming errors which write in other programs memory. But it can detect programming errors going into "random" address that are unused.
 
APOLLO 68080 has the HW support for this.
If someone wants then he/she could add support for this into Enforcer.

The well known coder Flype, did develop a small demo tool which enables to see "such hits" on 68080. This tool is IMHO work-in-progress status but it shows that you can see those hits and view the "program /disasm" causing it.
 


A1200 Coder

Posts 74
29 Jun 2019 13:23


Renee Cousins wrote:

A1200 coder wrote:

  A problem with MMU coding on Amiga is that there is hardly any documentation on MMU programming, besides Motorola's technical manuals, which don't give much hints on how to actually handle the mmu on the Amiga.

  I would not try to poke an MMU directly. There's already a clean implementation for AmigaOS that makes programming the MMU quite painless, faster and a lot more stable.
 
  EXTERNAL LINK 

This is unfortunately not possible in some cases, like with democoding/game coding, where you need to shut down OS. In that case, it would be good to have some code that on startup allocates a pagetable for MMU and sets it up according to memory use. I actually found my old code, it's based on this short 68030 mmu code example:

EXTERNAL LINK 
The 68030 has 3-level pagetable, and is setup in this example for 16  MB/512 kB/1kB sizes, where those 16 MB chunks at uppermost level can be terminated early if not used, and where needed, the minimum size is 1 kB for a distinct memory region. This is changeable too, but this is a decent resolution.

Since the MMU is not used by AmigaOS, it's not a problem if you poke it directly, you just turn it off when returning back to OS.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
29 Jun 2019 14:18


A1200 coder wrote:

Since the MMU is not used by AmigaOS, it's not a problem if you poke it directly, you just turn it off when returning back to OS.

I think there is no reason to do this on 68080.
Or do you see any reason for this?


Kamelito Loveless

Posts 260
29 Jun 2019 15:53


True under AmigaOS 3.x but I suppose that it can change if new memory flags are introduced in OS 3.x updates.

AmigaOS 4.x introduced 3 new memory types that add more protections.
From wiki.amigaos.net.

"The functions IExec->AllocMem() and IExec->AllocVec() are replaced by Exec->AllocVecTags() which is more flexible and expandable by using tag lists and provides greater functionality. You select the required memory type through AVT_Type (exec/exectags.h). You need to distinguish between MEMF_PRIVATE (the default) - which will only be visible to your own program and not to other processes, MEMF_SHARED for shared memory and MEMF_EXECUTABLE for running program code in. The latter is protected against changes and causes a GrimReaper hit when written to. Self-modifying code that was occasionally used earlier can't be used any more. The user can be sure that a program can't be damaged from another "rogue" process so easily any more. While AmigaOS 4 comes with rudimentary protection mechanisms, the open concept and shared memory areas can't completely prevent a faulty program from writing into other processes' memory but as far as possible this is avoided."



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
29 Jun 2019 16:45


Kamelito Loveless wrote:

    True under AmigaOS 3.x but I suppose that it can change if new memory flags are introduced in OS 3.x updates.
   

 
This is nonsense.
This can not work on any AMIGA OS.
And can not work with existing AMIGA software
 
The whole AMIGA OS concept is build on the shared memory feature
and that the OS vectors can be patched by programs always.
See MCP, SnoopDos, Scout etc

This will always be the achilles heel which at the end of the day prevents any form of real memory protection.

I know that some "company" puts out claims here.
But those clearly fall into "marketing bullshit" area.


Kamelito Loveless

Posts 260
29 Jun 2019 16:50


I don't get your answer of course it doesn't work under OS3, OS4 bring more protection you can't denied that. I'm not saying that AmigaOS have full memory protection but AmigaOS 4 has some, did you see Brice Nesbitt video? He even spoke about that and says that what I've been done under OS4 was what they wanted to do in AmigaOS 3 before CBM bankruptcy and writting "period!" doesn't change that!


Mr Niding

Posts 459
29 Jun 2019 17:07


.


Kamelito Loveless

Posts 260
29 Jun 2019 17:50


I surely prefer this answer, thanks for expressing your thoughts on the subject. This remind me of a talk I had with Dr Peter Kittel it was after Amiga Technologies creation in a german show. I ask him if they intended to add memory protection under AmigaOS and he told me something like this "...without it developers have to really know what they're doing and it force them to write better code"


A1200 Coder

Posts 74
30 Jun 2019 10:21


"I think there is no reason to do this on 68080.
Or do you see any reason for this?"

Well, debugging with MMU will help to catch faulty mem accesses by the CPU. Either accessing the MMU directly or using some program that can do it. 68080 MMU should be as accessible to the users as 68030/040/060 MMUs. Is there some problem with this requirement?


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
30 Jun 2019 10:42


A1200 coder wrote:

Well, debugging with MMU will help to catch faulty mem accesses

Correct, the 68080 MPU does offer this!

A1200 coder wrote:

Either accessing the MMU directly or using some program that can do it.

Not every programmer wants to write this again on his own.
If a programmer makes a mistake in setting up the MMU he/she will kill the System.
An MMU is not a toy to play around with.

This is the reason why I did question
that each programmer should be able to access and change the MMU.

Programmer should be able to launch debug tools. - YES




Marian Nowicki
(Needs Verification)
Posts 22/ 1
30 Jun 2019 18:32


It is very interesting.
May I get this gdbserver?
It is availble to download?



Marian Nowicki
(Needs Verification)
Posts 22/ 1
30 Jun 2019 18:36



If someone wants then he/she could add support for this into Enforcer.

 
  The problem is descritpion of Vampire MPU is not avaible.
 

The well known coder Flype, did develop a small demo tool which enables to see "such hits" on 68080.

 
  Cool. May We get this?
 
 


Steve Ferrell

Posts 424
30 Jun 2019 20:44


Marian Nowicki wrote:

It is very interesting.
  May I get this gdbserver?
  It is availble to download?
 

EXTERNAL LINK


Thellier Alain

Posts 141
01 Jul 2019 08:29


>> MEMF_PRIVATE [...] MEMF_SHARED [...] MEMF_EXECUTABLE
  > This is nonsense.
  > This can not work on any AMIGA OS.
 
  Those flags currently exists (and certainly are used and works) in OS4.1
  EXTERNAL LINK 
  Yes most of the OS structures are shared but we can imagine that a program got pure private data too so this prog can use MEMF_PRIVATE for those data with no prejudice to OS or others apps
 
  For example if I make a 3D engine it will use OS struct like windows,bitmaps,libraries that are public and may be used (or hacked) from other apps so they will be MEMF_SHARED
  But it will also have data for the 3d mesh with the xyz vertices. As the pointer to this data will be stored in a private structure too then there are no way than a other programs may know the pointer and access it (except random bad pointers or pirat hacking) so making this data MEMF_PRIVATE make sense.
 
 
 
 


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
01 Jul 2019 08:43


thellier alain wrote:

For example if I make a 3D engine it will use OS struct

You miss my points.
The point is NOT that such flag can NOT be used for a new program.
The point is that such flag will NOT make the OS fully safe.

Yes, wearing a helmet is increasing safety.
And wearing a helmet when parachuting will increase safety.
But if you jump out of the plane without any parachute - having a helmet will not make you much safer - will it?



Marian Nowicki
(Needs Verification)
Posts 22/ 1
01 Jul 2019 17:23


binary of gdbserver for 68k, It is availble to download?


Marian Nowicki
(Needs Verification)
Posts 22/ 1
01 Jul 2019 17:27



An MMU is not a toy to play around with.


Programmer should be able to launch debug tools. - YES

But there are not public available debug tools for now.
If You release documentation for MPU maybe someone wrote it.



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
01 Jul 2019 18:06


Marian Nowicki wrote:

  But there are not public available debug tools for now.
  If You release documentation for MPU maybe someone wrote it.

Sure no problem.
If you are interested in polishing the existing tool, please ping me on IRC.

posts 41page  1 2 3