1st1 wrote:But that does not prove that it does not exist for classic 68K Amiga OS.
1st1 wrote:joska wrote:If I'm not mistaken the Amiga's floppy controller does not do the MFM encoding/decoding but leaves that to the CPU.
No. Paula (the sound chip) does it.
BlankVector wrote:1st1 wrote:joska wrote:If I'm not mistaken the Amiga's floppy controller does not do the MFM encoding/decoding but leaves that to the CPU.
No. Paula (the sound chip) does it.
In that case, I reinvented the wheel by manually decoding MFM in the EmuTOS floppy driver for Amiga:
https://github.com/emutos/emutos/blob/m ... ga.c#L1385
And AROS drivers, where I took inspiration, made the same thing.
joska wrote:1st1 wrote:But that does not prove that it does not exist for classic 68K Amiga OS.
You get this the wrong way around. You say memory protection exist for 68k. The fact that the opposite can't be proved (can you prove that something does *not* exist?) does not mean you're right Prove that it exists, this should be very easy if this is something that exists and actually works.
Look at the internals of 68k AmigaOS/Workbench. I'm a novice myself in that field but you don't have to know it very well to understand that memory protection - as we know it - can not be implemented.
Take a look at the Apollo forum. When Gunnar is talking about the purpose of the MMU he's talking about it as a debugging tool. Not for memory protection.
1st1 wrote:Ok, I found something, Ok it's Amiga OS 4, which I think is for PPC platform but...
Should I continue to search? When it's available there, why not in OS 3.9? Why not something for 3.1? Should I continue to search? This was just found in a bunch of minutes...
Should I continue to search? This was just found in a bunch of minutes...
Requires: OS2.0, MMU.
Enforcer V37 - For 68020/68851, 68030, 68040, & 68060 CPUs
It requires V37 of the OS or better and does not have *any*
exceptions in it for specific software. Nothing should be causing
Requires an MMU. On 68EC030 systems, it may think it is working
even if it is not due to the fact that the missing MMU is very
hard to detect. Use LawBreaker to check.
This Enforcer has also been highly optimized to be as fast as
Enforcer can now also be used with CPU or SetCPU FASTROM or most
any other MMU-Kickstart-Mapping tool. This means that you do not
have to give up your speed in order to use Enforcer. (Major win
on A2000 and A500 systems)
Make sure you read the documentation before using these programs.
Debugging on the Amiga
CyberGuard / Enforcer / MuForce / Mungwall / Wipeout
Due to lack of memory protection under AmigaOS, a number of tools exists that use MMUs to offer partial protection for debugging purposes during development.
MorphOS has built-in CyberGuard. It guards non-allocated memory and writes to zero page. It can be configured to guard reads from zero page but it is not enabled by default because many Amiga software would fail.
MorphOS SDK includes Wipeout. It is Mungwall replacement originally written by Olaf Barthel and then ported to MorphOS.
Short: MMU protect free memory. Source included.
1st1 wrote:The magic thing's names are:
Purpose and goal of this library:
The mmu.library is a basis for MMU (memory management) related functions the
MC68K family can perform. Up to now certain hacks are available that program
the MMU themselves (Enforcer,CyberGuard,GuardianAngle,SetCPU,Shapeshifter,
It's therefore not unexpected that these tools conflict with each other.
There's up to now no Os support for the MMU at all - the gap this mmu.library
The goal is to provide a basis of functions to address and program the MMU in
a hardware independent, Os friendly fashion. Hence, the new version of the
Enforcer, called MuForce, will work together with virtual memory, and others.
The mmu.library is also the basis for the virtual memory project, the
memory.library. Even though the mmu.library does not provide virtual memory
itself, it builds the basics to allow an easy implementation and to avoid the
hacks required by other implementations so far.
The memory.library is now complete and can be found in this archive.
VMM implements a virtual memory manager for Amigas with a MMU. A
localized user interface to enter all parameters and to disable
certain tasks and load files from using virtual memory is also
provided. For the user interface MUI 2.3 is needed.
This is only a very small update. It now contains a german
documentation as people kept asking me for one. Apart from this only
new locales and an updated version of the BGUI interface written by
Emmanuel Doguet is included.
mikro wrote:PeP, doesn't matter it isn't the truth, it could have been!
1st1 wrote:So we continue on MMU use on Amiga?
1st1 wrote:Or is this an ATARI forum and we better ought to discuss what is possible with Apollo MCU in MiNT?
joska wrote:1st1 wrote:So are the Apollo MMU features settled? I haven't been paying too much attention to the Apollo forum but the last I saw was that the MMU design was far from finished. I believe it will be possible to use the Apollo MMU in MiNT, but it depends on atleast one feature that was not clear the last time I checked (page size). Without it the Vampire is of no interest to me.
exxos wrote:I personally think any upgrade should be backwards compatible with legacy software from the ST range.
exxos wrote:Sure it would be great to have higher resolutions.
exxos wrote:Problem is as I have said before, Someone may have the fastest ST about, write games for it, which nobody else can play unless they have the hardware. OTOH, People might not care for legacy support and just want to multitask with huge desktop and RAM.
exxos wrote:Why bother with a apollo core anyway ? Plenty of PC CPU's about cheap, bang that on the bus and have huge caches and huge CPU quad core power, plenty of PC graphics chipsets about for peanuts. All it needs is some special libs to make use of the PC's instructions and away ya go.
exxos wrote:I personally go for compatibility with fastest speed possible. While the CPU can access fast-ram pushing 32MHz speeds now, all it would take would be for someone to re-design the ST's MMU to work at 32MHz speeds with SRAM instead of DRAM, run ST-RAM then at 32MHz with the CPU and the ST would get a serious kick in CPU power. Pretty much all legacy software would run and run faster. Then would come other options maybe like extra resolutions, but nobody gives a stuff about doing a replacement MMU. I'm sure there are capable people to do it easily as well.
1st1 wrote:It's not only CPU, MMU, GLUE (very important for the clockings) and shifter work very close and syncronous together. If you simply speed up, you speed up everything, including Shifter's video timimng. If you would run the MMU and GLUE at 32 Mhz, you would force shifter to make video at higher refresh rates, higher pixel clock, but there is still it's intenal counter for 640x400 which has to be tricked out like Autoswitch Overscan does it to really get higher resolutions. Or you need to produce new clock sync signals for shifter to get back the original timing.
All of this is decribed in principal for the 12 Mhz patch, like here: http://www.stcarchiv.de/stc1992/09_gehtdoch.php
exxos wrote:Its ok in theory to have a "stock mode" but physical space inside the case is a problem,
exxos wrote:It would be difficult to have in effect 2 systems operating independently and still fit within the physical constraints.
exxos wrote:My V2 booster only just fits in the STFM case, and adding more stuff like IDE and alt-ram is going to be hard, and no chance of it fitting in those various oddball revisions.
exxos wrote:Even so, if the CPU gets replaced, faster ram, better video, LAN, USB and all the rest, then I think it would be a little pointless as that is what MiST is all about isn't it ?
exxos wrote:Though its back to likely being a super clocked 030 based system.
Users browsing this forum: lp and 4 guests