English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 29 March 2013, 17:19   #221
CFOU!
Moderator
CFOU!'s Avatar
 
Join Date: Sep 2004
Location: France
Age: 45
Posts: 2,292
Quote:
Originally Posted by Toni Wilen View Post
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



CFOU! is offline  
Old 29 March 2013, 17:21   #222
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 677
whdload change wasn't correct. it's like Toni told $A9F000 is not marked readable. I will provide updated whdload soon.
Wepl is offline  
Old 29 March 2013, 18:55   #223
CFOU!
Moderator
CFOU!'s Avatar
 
Join Date: Sep 2004
Location: France
Age: 45
Posts: 2,292
Quote:
Originally Posted by Wepl View Post
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
CFOU! is offline  
Old 29 March 2013, 19:20   #224
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 677
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
Wepl is offline  
Old 29 March 2013, 20:10   #225
CFOU!
Moderator
CFOU!'s Avatar
 
Join Date: Sep 2004
Location: France
Age: 45
Posts: 2,292
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,
CFOU! is offline  
Old 30 March 2013, 00:06   #226
Neil79
Registered User
Neil79's Avatar
 
Join Date: Jul 2012
Location: Kent
Age: 39
Posts: 2,609
Will we see a new WHDload any time soon? Would you like me to feature the WHDLOAD beta on our site?
Neil79 is offline  
Old 12 September 2014, 03:15   #227
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 677
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
Wepl is offline  
Old 12 September 2014, 18:20   #228
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by Wepl View Post
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:

Quote:
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.

Quote:
- 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.

Quote:
- 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

Quote:
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..

Quote:
- 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?)
Toni Wilen is offline  
Old 13 September 2014, 00:52   #229
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 677
Quote:
Originally Posted by Toni Wilen View Post
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.
Quote:
Originally Posted by Toni Wilen View Post
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.
Quote:
Originally Posted by Toni Wilen View Post
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.
Wepl is offline  
Old 14 September 2014, 13:33   #230
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by Wepl View Post
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..)

Quote:
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)
Toni Wilen is offline  
Old 14 September 2014, 23:02   #231
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 677
Quote:
Originally Posted by Toni Wilen View Post
Enforcer has some extra code for 68040 MOVEM handling too. Perhaps it helps? (It looked really confusing..)
Will take a look...
Quote:
Originally Posted by Toni Wilen View Post
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
Quote:
Originally Posted by Toni Wilen View Post
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.
Wepl is offline  
Old 18 October 2018, 09:48   #232
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
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
Toni Wilen is offline  
Old 18 October 2018, 14:41   #233
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 677
Quote:
Originally Posted by Toni Wilen View Post
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).
Quote:
Originally Posted by Toni Wilen View Post
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...
Wepl is offline  
Old 18 October 2018, 16:39   #234
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by Wepl View Post
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.

Quote:
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.
Toni Wilen is offline  
Old 18 October 2018, 16:52   #235
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
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.
plasmab is offline  
Old 18 October 2018, 17:02   #236
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by plasmab View Post
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.
Toni Wilen is offline  
Old 18 October 2018, 21:38   #237
jotd
Cat freak
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 47
Posts: 2,682
don't you love those overkill features. "they don't make CPUs like those anymore"
jotd is offline  
Old 19 October 2018, 16:03   #238
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 677
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.
Attached Files
File Type: zip register.zip (1.5 KB, 11 views)
Wepl is offline  
Old 19 October 2018, 17:28   #239
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by Wepl View Post
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.
Toni Wilen is offline  
Old 19 October 2018, 17:49   #240
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 677
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?
Wepl is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
68040 vs 68060 tesla support.Hardware 10 20 April 2013 20:13
68040 MMU jsr/bsr Toni Wilen Coders. General 5 28 April 2010 21:57
68060 fpu not available mmu not active amigarlz support.Hardware 6 18 March 2010 07:35
WTB: 68030 or 68040 accelerator for A2000 Shadowfire MarketPlace 2 19 September 2009 18:52
68030/mmu Support in WinUAE dkovacs request.UAE Wishlist 19 22 August 2005 15:42

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 23:50.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.17240 seconds with 16 queries