-
-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to pretend being a 68EC030? #730
Comments
After comparing specs, I though my 68020 should be recognized as a 68EC030 if the I've also tried WhichAmiga.exe.zip which is capable to distinguish between the 68030 and the 68EC030. However, it also reports a 020: Bottom line: Pretending to be a xx030 is not as easy as originally thought. |
Thanks for trying! |
Seems it has something to do with CACRF_WriteAllocate and CACRB_WriteAllocate flags and the cache.
From the 68030 doc, I can read this : EDIT : Looks like whichamiga deducts it's an EC if the AttnFlags says it's a 030 AND testing the MMU (by testing access to 'MMU only regs' and catching illegal instructions by setting a custom Illegal Instruction vector) behaves like there's no MMU. So : the presence of additional flags in CACR AND absence of MMU registers make a 68030 an EC030. |
KS3.1 CPU detection code at $00f80c36 (KS3.1 40.68):
I.e. it tries to set some 030 only cache bits in CACR and the check if they stick (they read as 0 on a 020). So I think you should be able to fool the system into thinking you're an 030 by allowing the relevant CACR bits to be set (See MC68020UM §4.2 and MC68030UM §6.3). BTW I don't know if there's any (evil) software that require accurate emulation of caches, but be aware that the expansion for ROM the HD controller (and debug board) probably won't work if you start emulating that (without some minor changes). |
Ok, I see. CACR does the trick. Here is the relevant code in Musashi:
I'll port this over... |
Excellent! This is really appreciated. I actually can't think of any software other that Settlers that requires a 68030 to allow full options... A 68020 with boosted clock should run everything... So we are only doing this for Settlers, thanks a lot! :) |
You mean because a write to one of the special registers won't be recognized any more because it's routed to the cache, right? |
I was more concerned about the code patching (e.g. modifying the target of library vectors), but looking at it again it's probably not really a concern with 020/030 cache sizes (probably not even 040/060). Data caches could be an issue, but I think you should be able to handle that by just treating those areas specially (but that's a long term worry). |
🤩 Wonderful. Can’t wait to leave office space and merge this hot new stuff into the uat version of vAmigaWeb this evening… |
Great!! |
Good work! On a pedantic note the implementation is slightly wrong. Bits 2&3 are write only in CACR on a 020 and always read as zero (probably similar issues for 030 but I can't verify on real HW). I.e. on a real EC020 (tested on my A1200 w/ accelerator disabled):
|
merged it into uat version of vAmigaWeb (that one is only meant for testing) results with selected results with selected is that maybe because of the slightly wrong implementation which @mras0 mentioned? |
Whatever the problem is, it doesn't show up in Settlers, which correctly reports 68030, and max map size of 8 :) |
Looks like it. Exception B (11) is Line F (FPU/MMU instruction). In this case it's a PMOVE ($F010). Found this post by Toni on EAB (a different, but related issue):
Probably not worth emulating if it's only for SysInfo, but if it also causes issues for WHDLoad it might be worth looking more into. EDIT: As hack adding |
Exciting stuff. I had a brief look at the MC68851 users manual. It seems like the following opcodes correspond to MMU instructions:
I think it's best to map all of them to |
According to my previous post, I'm afraid that could cause whichamiga to no longer detect it as an EC030. |
Sorry, I missed the edit in your post. So it looks like |
Overview of current reporting Running Moira 68020 Running Moira 68030 both programs report exactly the opposite (EC vs. non-EC) for each cpu. Cool ! Probably sysinfo likes to play something with MMU on non-EC CPUs and crashes … I would say this is a good test case for pretending a MMU ... but it would be safer still to make both programs think that there is a EC version for all cpus, no? |
Maybe this could help:
I don't know how sysinfo checks the MMU, but maybe, if it sees the MMU is disabled by checking this bit, that could be enough for not making it crash. |
From the whichamiga source : it differentiates EC and non-EC by checking the address bus width. 32 bits = 68020, 24 bits = 68EC020. |
Looking at the whichamiga source code (specially the
Reporting an incorrect result might be OK (it's certainly the easiest), but otherwise having a few special cases might be worth it. |
I agree with that, the point of this particular thread is 'pretend being an EC030' after all :-) Faking an MMU with NOPs will not do that. |
It's this code, isn't it?
If I understand it correctly, accessing an address that does not fit into 24 bits causes a bus error? |
Yes, it's this code. And from the specs, the 24-bit bus is indeed a difference between a EC020 and a 020. |
What I don't understand is why the code is so complex. Isn't it sufficient to simply read from (or write to) to a real 32-bit address and to check if a bus fault occurs? I also checked my hardware. I've upgraded one of my machines with a Terrible Fire board a while ago. Originally I thought it contained a 68EC020, but it does contain a real 68030. Hence, I think I won't get bus errors if I address above the 24-bit range on this machine. |
The 1200 has a EC020. Probably some people here own a 1200 and could do the test (I could, but last fall I had some flood damage at home and had to pack my amigas).
When I saw this code, I was thinking the same thing : why a such complex code 'just' to check that ? There is surely a reason. I did not take the time to fully analyse this. EDIT : contrary to the 68EC020, the 68EC030 has the full 32 bits address bus. |
On an 68EC020 the 8 most significant bits of the address are just ignored (except when it comes to the instruction cache) like on a 68000. I.e. I can read execbase just fine from $ff000004 (verified on my a1200). It makes sense that an 68EC030 would have all 32 address lines since it's just a 030 with no (or faulty) MMU.
Found another EAB thread that discusses EC030 identification. My take away from that thread is that it's not in general possible to distinguish a normal 030 from an EC030 purely in software (a mistake that MC corrected with the 040). Arguably it would be correct to just use NOPs (probably taking the effective addressing mode into account) for MMU instructions on EC030, or even halt the CPU if such a instruction was used! Of course that would not be very useful, and vAmiga users are probably more concerned about existing software working than the emulator being technically correct but useless :) My suggestion, which I think would work for existing software, would be to properly decode MMU instructions (so something like
|
Thanks for checking this! Overall, it might be easiest to solve the issues by moving a step forward. Musashi has some kind of MMU support which can be ported over without too much effort I think (I haven't looked into the details yet, just browsed the code). After this, we'll have a "real" 68030 which will render the current 68EC030 mode obsolete. I'll do this after finishing my current cputester work (I'm at letter |
No problem, just @'me if you need something checked on my a1260 (accelerator can be switched off for EC020 stuff but then I can only run checks w/ the basic config i.e. without fast ram).
Cool! Though maybe you want to consider adding basic support for 040/060 while you're at it? Very few instructions were added after 020/030 (mostly it was removing features/integrating MMU/FPU). To be honest I haven't used MMU features much directly, but if MC68851 is very different from 040/60 integrated MMUs I think supporting the latter (and ignoring 030 for now) would be better long term. Good luck with the CPU tester effort. I saw your EAB post regarding it, but I can't get it to work with the latest version of the WinuUAE source code (got it compiling, but doesn't work), so it's probably best to stick with version you're using. |
I was the first one to push for 020 and 030 support, reason being software support:
But now we are talking 040/060 emulation (or fake emulation) with MMU support. Might be interesting for the intellectual challenge, but is there any practical interest from a compatibility point of view? I can't think of any game or even software that will give you more features with a 040/060 than with a 030 (other than the clock speed which is not an issue in emulation) , even the 030 is kind of weird for Settlers, a 020 should be enough... As for the MMU, I can't think of a usage for that, apart from running Linux on a emulated Amiga, which sounds completely useless and geeky to me... Plus I understand ready Toni earlier threads that MMU emulation is slow and complex, for almost no benefit at all... I'm happy with good 68020 (maybe full rather than 68EC020, it might be useful someday to have more than 16MB of RAM and add Z3 memory) and fake 68EC030 emulation (I understand emulating the MMU and data cache has no practical value) and I would rather focus on doing this right than trying to do too many things with no practical value. What do you think? |
Currently, I am using this toolchain:
Unfortunately, I've never managed to compile UAE in my VM. |
I understand your point, but I am pursuing a different goal. Musashi (which is one of the mostly used m68k emulation cores) somehow seems to have come to a dead end. There are a couple of pending pull requests in the main repo as well as a lot of unresponded bug reports. Unfortunately, I don’t know of any other m68k core that is as easy to use as Musashi. The UAE core seems to be tightly integrated in UAE which makes it difficult to use in other projects. I think Moira can step in here, especially because it’s not only faster than Musashi, but also more accurate. There is a big difference though: Musashi covers a whole range of processors (68000, 68010, 68EC020, 68020, 68EC030, 68030, 68EC040 an 68040) whereas Moira is restricted to the 68000. Hence, even if 68040 support in Moira doesn’t make that much sense from an Amiga emulation perspective, other communities could benefit from it. There is another important difference though: Musashi uses a MIT-like license whereas Moira is licensed under the GPL. Since I don’t really care about the copyleft principle here, I am thinking about switching from a GPL license to a MIT license in the future. |
Thanks for the exanation, very interesting! I got your point. |
Quick note : the EC030 with additional CACR flags and no MMU (which is correctly recognized in whichamiga) does not cause problem with the AmigaOS 3.2.1 showconfig neither. |
Very nice to hear regarding the future of Moira. It already seemed to be going in that direction (hence my comments about considering what 040/060 does), but good to see spelled out. You're doing great work, but obviously there's a bit of way to go for 020+. Maybe it would make sense to create new issues (perhaps in the Moira repo?) to track progress on different fronts (longword memory access, FPU, MMU, cache emulation, 040+, etc). Looked more into the topic at hand (EC030), and the 030 (MC68851) MMU really takes the kitchen sink approach. They support a lot of stuff that was abandoned for 040+. Implementing the approach I mentioned earlier (MMU op = nop with EA decoding, execption for PMOVE.L tc,EA => EA=0) works for sysinfo and whichamiga as expected. WHDload doesn't work, but then again it also fails w/ 020 so probably not a MMU issue. |
Yes, definitely. The Moira repo would be the proper location. Until now, I haven't opened many issues there, because it's kind of a lonely place at the moment. |
I took a closer look at the MMU architecture. Main observations:
Bottom line: In a longer term, the following CPU models are worth to be supported in my opinion: 68000, 68010, 68020, 68030, 68040, 68EC020, 68EC030, 68EC040, 68LC040. |
Closed as the 030/040 project is put on hold. For reference: Commit 115f803 ist the last commit containing MMU code. |
I understand that the only differences between the 020 and 030 are not in the instruction set but in the MMU which is not useful in emulation, and data cache + burst mode which probably add nothing much in performance either in emulation, so could it be possible to have a 030 setting that would be identical to the 020 emulation save for the identification bits? So that Settlers can have map size to 8...
Originally posted by @Vweber73 in #728 (comment)
The text was updated successfully, but these errors were encountered: