15 June 2021, 18:21 | #1 |
Registered User
Join Date: May 2015
Location: newcastle-under-lyme
Posts: 87
|
68040 MMU use when JIT on
Anyone able to explain what going on here? I was messing with my WinUAE emulated 3.1.4.1 and 3.2 systems and noticed that in sysinfo 4.4 it was showing the MMU was working in my 3.1.4.1 environment - which is strange as WinUAE says MMU is incompatible with JIT .. so is off and greyed out, yet showing as in use in Sysinfo? So I checked my 3.2 environment and thats working as expected.. i.e. sysinfo show MMU not in use and in WinUAE it showing greyed out and not selected.
So I wondered if it the 68040.library was different and somehow causing MMU to show in use the the 3.1.4.1 env.. Sure enough.. it an older lib 37.3..... and the one in 3.2 is ver 46.3... so I thought I would upgrade the 68040 lib... since it supposed to be generic..but when I put it in my 3.1.4.1 env I got a soft/recoverable Guru telling me I needed a 68040 lib? which was a surprise... So anyone know why sysinfo showing the MMU in use when it turned off in WinUAE? And anyone know why the 46.3 generic 68040 lib (that comes with 3.2) blows up a 3.1.4.1 install? Thanks for any insight |
15 June 2021, 18:28 | #2 |
Registered User
Join Date: May 2015
Location: newcastle-under-lyme
Posts: 87
|
OK.. quick update.. looks like sysinfo is wrong... although it says it on in sysinfo, when I use the shell "Cpu mmutype" command it comes back with "none"... so I guess we should trust the OS.
But still interested if the newer 68040 lib issue is a surprise? |
15 June 2021, 18:46 | #3 |
WinUAE 4000/40, V4SA
Join Date: Apr 2020
Location: East of Oshawa
Posts: 538
|
Yeah, you'd be better off checking those kinds of details out with Scout.
|
15 June 2021, 18:56 | #4 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
MMU is faked. All registers and instructions work but they do nothing.
You selected CPU model that is supposed to have MMU -> MMU gets faked if it can't be emulated fully. It also makes it more compatible with old MMU library versions that don't like no-MMU CPU models. MMU setup isn't really needed under emulation anyway in normal use (excluding debugging where it can be very useful). Later MMU library version probably checks that MMU address translation works. |
15 June 2021, 20:34 | #5 |
Registered User
Join Date: May 2015
Location: newcastle-under-lyme
Posts: 87
|
Thanks,
Yes, I appreciate its all faked.. CPU/FPU/MMU/Chip sets.. everything. My understanding was that to emulate the MMU slows everything down in a modern emulation environment - which is why it is forcefully set off when you set JIT. But it is strange (to a noob like me) that the newer libs would cause problems. TBH I cant recall where I got the old 37.3 libs from, perhaps from somewhere when building my real A4000/40 machine build... but I did not expect a 3.2 generic 68040 lib to cause problems with what is in effect a very basic 3.1.4.1 OS build.. If as you say, it may check to see if MMU address translation works.. you would not expect it to blow up if it does not find it? after all... some 68040 genuine chips dont have the MMU? (EC versions?) Cheers |
19 June 2021, 17:01 | #6 |
Registered User
Join Date: May 2015
Location: newcastle-under-lyme
Posts: 87
|
OK.. someone else said the lib with blow up with JIT enabled.. which sounded strange... but I thought I would do some more test
I think I closer to understanding now... When 3.1.4.1 and JIT and 68040.library 37.3 the CPU command reports as "68040 68882" (with some cache info).... When 3.2 and JIT and 68040.library 46.3 the CPU command reports as "68040 68882" (with some cache info) When 3.1.4.1 and JIT and 68040.library 46.3 the CPU command reports as "68040 68040/060-FPU" (with some cache info) Disabling JIT and then having MMU on or off, makes no difference in that last scenario.. with the 46.3 library.. the 3.1.4.1 environment always blows up. So the 46.3 lib reports CPU differently depending on workbench version number.. and thats what is triggering the issue. Slightly strange that it does report it as a 68040 present in all test scenarios.. but the scripting does not like the response, as it reports a "CPU failed returncode 30" I dont know the details of if it differences in the CPU command between 3.1.4 and 3.2 or library.. or interaction between both. |
19 June 2021, 19:33 | #7 |
Registered User
Join Date: May 2015
Location: newcastle-under-lyme
Posts: 87
|
Yet another update... on advice ... looks like I was wrong to think I could just change the 68040.library. going through the official "install" process included with the mmulibs.lha pack, it worked its magic and the 3.1.4.1 install works fine and is using the 46.3 68040.library.
If I run with JIT on - it works (knowing no MMU is avail) and if I turn off JIT and turn on MMU, it identified mmu avail and uses it just fine. So looks like I need RTFM () to understand whats going on but after install.. the CPU command is back to reporting "68040 68882 No Fastrom" (and some cache info) |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
68030, 68040 and 68060 MMU support (really!) | Toni Wilen | support.WinUAE | 262 | 19 February 2019 12:36 |
JIT mode for 68040 available? | pixelsmack | support.FS-UAE | 4 | 17 July 2014 00:00 |
WinUAE crashes when switching from MMU to JIT | jotd | support.WinUAE | 1 | 19 November 2010 21:34 |
68040 MMU jsr/bsr | Toni Wilen | Coders. General | 5 | 28 April 2010 20:57 |
MMU/JIT toggle on native mode | jotd | request.UAE Wishlist | 3 | 18 September 2009 20:36 |
|
|