English Amiga Board

Go Back   English Amiga Board > Support > support.WinUAE

Thread Tools
Old 15 June 2021, 18:21   #1
Registered User

Join Date: May 2015
Location: newcastle-under-lyme
Posts: 85
68040 MMU use when JIT on

Anyone able to explain what going on here? I was messing with my WinUAE emulated and 3.2 systems and noticed that in sysinfo 4.4 it was showing the MMU was working in my 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 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 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 install?
Thanks for any insight
Yoji is offline  
Old 15 June 2021, 18:28   #2
Registered User

Join Date: May 2015
Location: newcastle-under-lyme
Posts: 85
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?
Yoji is offline  
Old 15 June 2021, 18:46   #3
WinUAE 1200/40, V4SA
coldacid's Avatar
Join Date: Apr 2020
Location: Candinavia
Posts: 271
Yeah, you'd be better off checking those kinds of details out with Scout.
coldacid is offline  
Old 15 June 2021, 18:56   #4
Toni Wilen
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,862
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.
Toni Wilen is offline  
Old 15 June 2021, 20:34   #5
Registered User

Join Date: May 2015
Location: newcastle-under-lyme
Posts: 85

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 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?)
Yoji is offline  
Old 19 June 2021, 17:01   #6
Registered User

Join Date: May 2015
Location: newcastle-under-lyme
Posts: 85
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 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 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 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.
Yoji is offline  
Old 19 June 2021, 19:33   #7
Registered User

Join Date: May 2015
Location: newcastle-under-lyme
Posts: 85
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 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)
Yoji 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
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

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 00:37.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.07665 seconds with 13 queries