68030, 68040 and 68060 MMU support (really!)

[CFou!]

Originally Posted by Toni Wilen

Keeps repeating.

My guess is that A90000-A9FFFF is mapped as invalid. (Built-in HRTMon starts from A10000 and requires full 512k)

Bert had just modifyed whdload to valid this adress

here copy of Bert's email when i send to me new beta version:

Hi Bertrand,

I checked the hrtmon sources: $A9F000 is where the saved custom
registers can be read. I changed whdload to mark this as readable
memory too. attached - please try

[Wepl]

whdload change wasn't correct. it's like Toni told $A9F000 is not marked readable. I will provide updated whdload soon.

[CFou!]

Originally Posted by Wepl

whdload change wasn't correct. it's like Toni told $A9F000 is not marked readable. I will provide updated whdload soon.

happy to read you here

wonderfull, i'll test your update with many pleasure

[Wepl]

new beta is available http://whdload.de/whdload/whd172.lha

readable memory has been increased to $90000 bytes ($a10000..$aa0000)
is also clears hrtmon's config_IDE to avoid access faults to the ide hardware now

would be nice to have an option in WinUAE to make hrtmon also visible without entering him the first time via Shift-F12

[CFou!]

I'am just finishing to test compatibility between new whdload & winuae using MMU

Thank you very much Bert, now it works perfectly, I can win an amazing time to patch!

I should tell you about long ago the problem was quickly solved

I lost a lot of time to make the trainers and removes protections manual silmarils games without mmu!

thank you again,

Sincerely,

[Neil79]

Will we see a new WHDload any time soon? Would you like me to feature the WHDLOAD beta on our site?

[Wepl]

After (hopefully) have been completed the adaptions on WHDLoad to fully support the 68040 for the special MMU-features I have checked all MMU stuff also on WinUAE 2.8.1. With the following results:

68030:
- on write/rwm faults WinUAE throws the exception at the instruction which causes the fault (2,a7) instead of the next instruction which is reported on a real 68030, this is only a difference to the real hw, WHDLoad has not a problem with that because it doesn't use the reported pc for anything (check #3202-3, wrong message)

68040:
- ptestw seems to doesn't work correctly, after a movem misaligned write fault because invalid page descriptor, and executing ptestw on the effective address of the fault ptestw returns in the mmusr $71, bit #0 telling there would be a valid descriptor or transparent translation which is wrong, bit #0 must be cleared (check #3007-8, loops forever)
- move16 fault does not set correctly ssw, it report long access instead of line, bits #5-6 = 00 instead of 11 (check #3030, wrong message)
- in general bit #7 of the ssw, documented by motorola as undefined, is set by WinUAE always 0, on real 68040 it is sometimes 1, seems to have read/write dependency, does not cause any problems with WHDLoad only did notify this

68060:
- fault on tas instruction is incorrectly reported as read in the flsw instead of rwm, bits #23-24 '10' instead of '11', (check #4040, wrong message)
- on 'bftst (an),{1:1}' real 68060 reports long read, WinUAE reports byte read, this seems to be an implementation difference (check #4101, wrong message)
- on 'bfclr (an),{1:1}' real 68060 reports long rwm, WinUAE reports byte rwm, this seems to be an implementation difference (check #4103, wrong message)

The issues can be reproduced using config and hd from http://whdload.de/whdload/Harddisk-WHDLoad-Test.zip by running the test xxxx using command 't xxxx', 't xxxx req' allows to display registers for quick investigation.
Just wanted to report these results to help to improve the MMU emulation.

Thanks a lot for the MMU-support in WinUAE

[Toni Wilen]

Originally Posted by Wepl

68040:
- ptestw seems to doesn't work correctly, after a movem misaligned write fault because invalid page descriptor, and executing ptestw on the effective address of the fault ptestw returns in the mmusr $71, bit #0 telling there would be a valid descriptor or transparent translation which is wrong, bit #0 must be cleared (check #3007-8, loops forever)

My crystall ball says PTEST works fine but fault address is wrong.

Possibly related to this:

CM—Continuation of MOVEM Instruction Execution Pending

CM is set if a data access encounters a bus error for a MOVEM. Since the MOVEM operation can write over the memory location or registers used to calculate the effective address, the M68040 internally saves the effective address after calculation. When MOVEM encounters a bus error, a stack frame is created with CM set, and the effective address field contains the calculated effective address for the instruction. When RTE is executed, MOVEM restarts using the effective address on the stack (instead of repeating the effective address calculate operation) if the address mode is PC relative (mode = 111, register = 010 or 011) or indirect with index (mode = 110).

Could you test which MOVEM variants set CM bit? Above explanation imho is not that good.

- move16 fault does not set correctly ssw, it report long access instead of line, bits #5-6 = 00 instead of 11 (check #3030, wrong message)

Fixed. MOVE16 special case was already handled but I wasn't sure if 68040 MOVE16 uses line or long.

- in general bit #7 of the ssw, documented by motorola as undefined, is set by WinUAE always 0, on real 68040 it is sometimes 1, seems to have read/write dependency, does not cause any problems with WHDLoad only did notify this

I don't emulate undocumented features unless they are at least 90% confirmed. "Sometimes" is not good enough

68060:
- fault on tas instruction is incorrectly reported as read in the flsw instead of rwm, bits #23-24 '10' instead of '11', (check #4040, wrong message)

Fixed. Wrong constant used..

- on 'bftst (an),{1:1}' real 68060 reports long read, WinUAE reports byte read, this seems to be an implementation difference (check #4101, wrong message)
- on 'bfclr (an),{1:1}' real 68060 reports long rwm, WinUAE reports byte rwm, this seems to be an implementation difference (check #4103, wrong message)

Does it depend on An alignment? (Points to odd address, even but not long aligned? long aligned?)

[Wepl]

Originally Posted by Toni Wilen

My crystall ball says PTEST works fine but fault address is wrong.

Yes, it seems. Fault address is $ffe and invalid page starts at $1000. So ptestw result is correct.

Originally Posted by Toni Wilen

Could you test which MOVEM variants set CM bit? Above explanation imho is not that good.

In my tests CM is always set on movem faults. Also if only one register is in the register list and also on other addressing modes (e.g. (d16,an)). This also matches the mot docs. But CM is of course not set on writes if the movem operation was completed. That means that all the writes were propagated already to the write back buffers. So this can probably only happen with a max of two registers in the register list (except when crossing a page boundary then with any count).
This is also the reason my test worked on real 68040 but doesn't on WinUAE. On the real 68040 the movem write were going to the write back and the following instruction faulted (without CM). In difference on WinUAE already the movem faults.
Have to think how to change the WHDLoad AF-handler for this.
So WinUAE is fine.

Originally Posted by Toni Wilen

Does it depend on An alignment? (Points to odd address, even but not long aligned? long aligned?)

It's independent from the An alignment. It always reports size=%00 in the FSLW. Maybe it's a bug in the CPU and it really performs a byte read, only sets it wrong in the FSLW. It looks like that because there is no difference between a 'bftst ($1000){0:32}' and a 'bftst ($1001){0:1}'. The other idea would be that it always reads a long aligned and shifts it then.

[Toni Wilen]

Originally Posted by Wepl

Have to think how to change the WHDLoad AF-handler for this.
So WinUAE is fine.

Enforcer has some extra code for 68040 MOVEM handling too. Perhaps it helps? (It looked really confusing..)

It's independent from the An alignment. It always reports size=%00 in the FSLW. Maybe it's a bug in the CPU and it really performs a byte read, only sets it wrong in the FSLW. It looks like that because there is no difference between a 'bftst ($1000){0:32}' and a 'bftst ($1001){0:1}'. The other idea would be that it always reads a long aligned and shifts it then.

Does all bitfield instructions have same "problem"?

If you do "bftst ($fff){0:1}", does it fault if $fff is valid but $1000 is invalid? If not, does it only fault when offset is 8 or larger? (Data at $1000 is "really" needed)

[Wepl]

Originally Posted by Toni Wilen

Enforcer has some extra code for 68040 MOVEM handling too. Perhaps it helps? (It looked really confusing..)

Will take a look...

Originally Posted by Toni Wilen

Does all bitfield instructions have same "problem"?

All bitfield instructions reports long accesses, also if the operation could be satisfied with a byte or word access, e.g. bfclr $1000{0:16}
mode is either read (bftst/extu/exts/ffo) or rmw (bfins/chg/clr/set), never write

Originally Posted by Toni Wilen

If you do "bftst ($fff){0:1}", does it fault if $fff is valid but $1000 is invalid? If not, does it only fault when offset is 8 or larger? (Data at $1000 is "really" needed)

In this case it doesn't fault. Faults only if offset is >=8.
Maybe the FSLW doesn't match the real bus accesses performed with the bitfield instructions.

[Toni Wilen]

Old thread but new 68030 semi-undocumented feature was found by Hatari developers.

Bus error exception handler can modify access exception Special Status Word FC bits and if DF bit is left set, MMU will retry the faulted data access using modified SSW FC bits!

Atari ST debugging program uses it to access supervisor-only address space in user mode. If fault happens in user mode, SSW bit 2 is set and access is retried.

This is now (hopefully correctly) emulated but I'd like to have some test cases. Is it possible to make whdload test slaves that create this situation? Have memory space which is supervisor-only, read or write access it in user space, when it faults, set SSW bit 2 and retry it (don't clear DF bit). It should succeed now and program execution should continue normally in user mode.

It would be also interesting to see if it is also possible to modify SSW RW and SIZE bits to change retried access to use different size or to confuse everyone by making read access write access and vice versa

[Wepl]

Originally Posted by Toni Wilen

Bus error exception handler can modify access exception Special Status Word FC bits and if DF bit is left set, MMU will retry the faulted data access using modified SSW FC bits!

This is no surprise I think. RTE will just read the stackframe and performs what is requested. The stackframe contains all info to complete an interrupted instruction. To my understanding there is no internal state influencing this (maybe there are unknown side effects).

Originally Posted by Toni Wilen

This is now (hopefully correctly) emulated but I'd like to have some test cases. Is it possible to make whdload test slaves that create this situation? Have memory space which is supervisor-only, read or write access it in user space, when it faults, set SSW bit 2 and retry it (don't clear DF bit). It should succeed now and program execution should continue normally in user mode.

It would be also interesting to see if it is also possible to modify SSW RW and SIZE bits to change retried access to use different size or to confuse everyone by making read access write access and vice versa

I will try to build a test.slave...

[Toni Wilen]

Originally Posted by Wepl

This is no surprise I think. RTE will just read the stackframe and performs what is requested. The stackframe contains all info to complete an interrupted instruction. To my understanding there is no internal state influencing this (maybe there are unknown side effects).

Yeah but there is huge amount of undefined fields in stack frame which may have also included actual "in use" FC value.

I will try to build a test.slave...

Thanks. FC test is the most important. The rest are just extra (but interesting!), I don't see much use for changing size or rw except perhaps for obfuscating code, if it even works.

[plasmab]

Doesn’t RTE switch you back from supervisor mode back to whatever mode was running when the CPU was interrupted? (Genuine question... I don’t know the answer) If so where does that state get stored.

[Toni Wilen]

Originally Posted by plasmab

Doesn’t RTE switch you back from supervisor mode back to whatever mode was running when the CPU was interrupted? (Genuine question... I don’t know the answer) If so where does that state get stored.

68030 MMU bus error exception is something very different than any other exception... Just check the MMU/exception handling part of manual and compare it to 68040+

68030 MMU stores complete state of CPU in stack frame (which is large, 92 bytes and most state fields are not documented) when MMU (or external) bus error exception starts, and when exception handler ends it with RTE, complete instruction state is restored and instruction execution resumes mid instruction where it was left before exception (=data access that caused the bus error is retried and this access uses SSW FC, not the original FC if it was modified). It is also possible for exception handler to emulate the access, in this case CPU state is again restored but faulted access is not retried.

68030 MMU is extremely different than 68040/060. 68030 MMU is based on 68851 with some even more complex features removed.. 68040/060 can only restart whole instruction. Only 68030 (and 68851) can continue instruction after bus error exception.

[jotd]

don't you love those overkill features. "they don't make CPUs like those anymore"

[Wepl]

It seems WinUAE 4.0.1 is signaling wrong fault size in the SSW?
ssw=$315 -> size=%01 would mean byte transfer, but was long.

[Toni Wilen]

Originally Posted by Wepl

It seems WinUAE 4.0.1 is signaling wrong fault size in the SSW?
ssw=$315 -> size=%01 would mean byte transfer, but was long.

I think some more context would be helpful.. Do you mean after you have modified SSW? 4.0.1 of course won't support it. Only winuae.7z in usual URL has it implemented.

[Wepl]

No, without modification of the ssw.
I made some general tests and saw that the qa-suite mostly not works on winuae-68030.
I thought that has worked already once.
I've updated the suite at http://whdload.de/whdload/Harddisk-WHDLoad-Test.zip
It seems winuae reports wrong size in the ssw.
Did you change there something since 2014?