29 March 2013, 16:19 | #221 | |
Moderator
Join Date: Sep 2004
Location: France
Age: 51
Posts: 4,277
|
Quote:
here copy of Bert's email when i send to me new beta version: Hi Bertrand, |
|
29 March 2013, 16:21 | #222 |
Moderator
Join Date: Nov 2001
Location: Germany
Posts: 876
|
whdload change wasn't correct. it's like Toni told $A9F000 is not marked readable. I will provide updated whdload soon.
|
29 March 2013, 17:55 | #223 |
Moderator
Join Date: Sep 2004
Location: France
Age: 51
Posts: 4,277
|
|
29 March 2013, 18:20 | #224 |
Moderator
Join Date: Nov 2001
Location: Germany
Posts: 876
|
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 |
29 March 2013, 19:10 | #225 |
Moderator
Join Date: Sep 2004
Location: France
Age: 51
Posts: 4,277
|
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, |
29 March 2013, 23:06 | #226 |
Autistic 'n IRN!
Join Date: Jul 2012
Location: -
Posts: 2,988
|
Will we see a new WHDload any time soon? Would you like me to feature the WHDLOAD beta on our site?
|
12 September 2014, 02:15 | #227 |
Moderator
Join Date: Nov 2001
Location: Germany
Posts: 876
|
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 |
12 September 2014, 17:20 | #228 | ||||||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,575
|
Quote:
Possibly related to this: Quote:
Quote:
Quote:
Quote:
Quote:
|
||||||
12 September 2014, 23:52 | #229 | ||
Moderator
Join Date: Nov 2001
Location: Germany
Posts: 876
|
Quote:
Quote:
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. 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. |
||
14 September 2014, 12:33 | #230 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,575
|
Quote:
Quote:
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) |
||
14 September 2014, 22:02 | #231 | ||
Moderator
Join Date: Nov 2001
Location: Germany
Posts: 876
|
Quote:
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:
Maybe the FSLW doesn't match the real bus accesses performed with the bitfield instructions. |
||
18 October 2018, 08:48 | #232 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,575
|
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 |
18 October 2018, 13:41 | #233 | ||
Moderator
Join Date: Nov 2001
Location: Germany
Posts: 876
|
Quote:
Quote:
|
||
18 October 2018, 15:39 | #234 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,575
|
Quote:
Quote:
|
||
18 October 2018, 15:52 | #235 |
Banned
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.
|
18 October 2018, 16:02 | #236 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,575
|
Quote:
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. |
|
18 October 2018, 20:38 | #237 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,388
|
don't you love those overkill features. "they don't make CPUs like those anymore"
|
19 October 2018, 15:03 | #238 |
Moderator
Join Date: Nov 2001
Location: Germany
Posts: 876
|
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. |
19 October 2018, 16:28 | #239 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,575
|
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.
|
19 October 2018, 16:49 | #240 |
Moderator
Join Date: Nov 2001
Location: Germany
Posts: 876
|
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? |
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 19:13 |
68040 MMU jsr/bsr | Toni Wilen | Coders. General | 5 | 28 April 2010 20:57 |
68060 fpu not available mmu not active | amigarlz | support.Hardware | 6 | 18 March 2010 06:35 |
WTB: 68030 or 68040 accelerator for A2000 | Shadowfire | MarketPlace | 2 | 19 September 2009 17:52 |
68030/mmu Support in WinUAE | dkovacs | request.UAE Wishlist | 19 | 22 August 2005 14:42 |
|
|