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: 44
Posts: 2,289
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  
AdSense AdSense  
Old 29 March 2013, 17:21   #222
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 639
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: 44
Posts: 2,289
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: 639
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: 44
Posts: 2,289
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: 38
Posts: 2,501
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: 639
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: 42
Posts: 19,793
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 online now  
Old 13 September 2014, 00:52   #229
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 639
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: 42
Posts: 19,793
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 online now  
Old 14 September 2014, 23:02   #231
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 639
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  
AdSense AdSense  
 


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 18:46.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.19519 seconds with 12 queries