Line 1111 Emulator exception mishandled (WinUAE 5.0.0, 60EC030)

[saimo]

Hi Toni,

I have stumbled upon at least one case where the exception mentioned in the title is mishandled: when it triggers, the stack pointer gets decreased by 16 instead of 8 (which is what is needed by the format $0 4-word stack frame generated by the exception).
In the first picture attached here you can see the pc pointing to pmove (8,a5),srp (which is not valid on 68EC030). Trying to execute the instruction causes the exception, but, as shown in the second picture, the sp went from $2300 to $22f0, instead of $22f8.
For your convenience, I have attached a little program that triggers the fault (I was testing other stuff with it, but it turned out to be useful also for this).

[Toni Wilen]

It is MMU configuration exception you got (writing invalid descriptor to SRP) but because it was not checked that this instruction can also internally generate exception (Exception 56), it also generated F-line on top of it.. Fixed.

Motorola no-MMU models don't change MMU instruction decoding, most MMU registers can be accessed normally but either TC enable bit can't be set (68EC040/060) or CPU hangs or works strangely if MMU is enabled (At least some 68EC030s)

UAE simply prevents TC enable bit to be set if EC model.

FPU instruction do generate F-line if FPU is missing but missing MMU does not work that way for some reason. (Except 68851 but thats not worth the trouble to emulate..)

[saimo]

Originally Posted by Toni Wilen

It is MMU configuration exception you got (writing invalid descriptor to SRP) but because it was not checked that this instruction can also internally generate exception (Exception 56), it also generated F-line on top of it.. Fixed.

Thanks for the prompt fix
(Indeed I had noticed that there were two stack frames, but I was too sick to analyze that as well.)

CPU hangs or works strangely if MMU is enabled (At least some 68EC030s)

What happens if on a CPU that behaves like that ac0 and ac1 map transparently the whole address space, thus making tc irrelevant? Does the CPU work correctly?

UAE simply prevents TC enable bit to be set if EC model.

Sounds like a good solution.

FPU instruction do generate F-line if FPU is missing but missing MMU does not work that way for some reason. (Except 68851 but thats not worth the trouble to emulate..)

Wait, do you mean that in the real world the 68EC030 throws a MMU configuration exception? According to the M68000PM and MC68030UM, it should be the F-line one, because the bit pattern 010 after $f02d is unknown to the 68EC030 (which only knows 000 and 011), so it's an unimplemented instruction, whereas an MMU exception is about writing invalid data to a register, but here the point is that the srp doesn't exist at all.

[Toni Wilen]

What happens if on a CPU that behaves like that ac0 and ac1 map transparently the whole address space, thus making tc irrelevant? Does the CPU work correctly?

ACx always work (which are renamed TTRs).
This is the only difference in EC vs MMU emulation. EC = less heavy MMU emulation, only transparent translation emulated. MMU = full MMU. No MMU = MMU instructions are emulated but all the translation/bus error stuff is ignored.

Originally Posted by saimo

Wait, do you mean that in the real world the 68EC030 throws a MMU configuration exception? According to the M68000PM and MC68030UM, it should be the F-line one, because the bit pattern 010 after $f02d is unknown to the 68EC030 (which only knows 000 and 011), so it's an unimplemented instruction, whereas an MMU exception is about writing invalid data to a register, but here the point is that the srp doesn't exist at all.

Documentation only lists which instructions/addressing modes 68EC030 officially supports. It can still "support" all MMU commands.

It is possible most (or even all) 68EC030s are full 68030s with working or non-working MMU. I had one (don't have any 68EC030 anymore) back in the day. It was labeled 68EC030, Enforcer did work and reported errors correctly. Most other programs that use MMU hung immediately.

Which is the reason it is not possible to detect 68EC030 from 68030 in software.

[saimo]

Originally Posted by Toni Wilen

ACx always work (which are renamed TTRs).

What I mean is: in the real 68EC030s which "works strangely if MMU is enabled", is the abnormal behaviour such that the ACx settings are erroneously overruled?

Documentation only lists which instructions/addressing modes 68EC030 officially supports. It can still "support" all MMU commands.

It is possible most (or even all) 68EC030s are full 68030s with working or non-working MMU. I had one (don't have any 68EC030 anymore) back in the day. It was labeled 68EC030, Enforcer did work and reported errors correctly. Most other programs that use MMU hung immediately.

Which is the reason it is not possible to detect 68EC030 from 68030 in software.

Thanks for the information.
So the F-line exception should never happen, whereas the MMU configuration exception might still happen because the data is actually invalid (normal behaviour) or maybe because of the malfunctioning of the control register - and thus, I guess, this is the exception that WinUAE emulates.
Do I get it right?

[Toni Wilen]

Originally Posted by saimo

What I mean is: in the real 68EC030s which "works strangely if MMU is enabled", is the abnormal behaviour such that the ACx settings are erroneously overruled?

Transparent translation should always work. 68EC030 has MMU that only supports transparent translation, the rest of MMU may or may not work. TC bit 31 (enable full MMU) should not be set if 68EC030.

Note that AC0, AC1, ACUSR are simply renamed TT0, TT1 and MMUSR. Instruction opcodes are identical. There is no 68EC030 only instructions even if documentation tries mislead.

For example ACUSR has bits marked as "x" because they can still contain normal MMU status bits but they can't be trusted. If 68EC030 would be "real" EC030, those bits would have been documented as always zero.

So the F-line exception should never happen, whereas the MMU configuration exception might still happen because the data is actually invalid (normal behaviour) or maybe because of the malfunctioning of the control register - and thus, I guess, this is the exception that WinUAE emulates.
Do I get it right?

Yes and no

Technically 68EC030 can do anything when executing this instruction because it is not documented as supported, even if most CPUs do handle it fine. Most likely f-line never happens and instruction works perfectly but CPU also might hang if that part of MMU is broken.

UAE simply behaves like "proper" 68030 would work (except TC) because that is how 68EC030 I had in 1990s behaved.

Unfortunately I don't have any 68EC030 for testing.

[saimo]

Originally Posted by Toni Wilen

Transparent translation should always work. 68EC030 has MMU that only supports transparent translation,

That was a given to me, but after what you said I wondered if the broken part might affect also the working one if fiddled with (e.g. writing to TC).

Note that AC0, AC1, ACUSR are simply renamed TT0, TT1 and MMUSR. Instruction opcodes are identical.

Yep, my code relies on that. It basically configures the MMU normally and assumes that on an 68EC030 tc, srp and crp just won't work - and to make sure that no undesired effects happen, uses tt0 and tt1 to map the whole address space. And that's why I wondered if the broken part would break the rest, too (as said above and below).

There is no 68EC030 only instructions even if documentation tries mislead.

Even Motorala themselves admitted the unfortunate naming - from M68000PM, 1.3.6: "For embedded controllers, such as 68EC030 and 68EC040, the access control registers (AC) are similar in function to the TT registers but just named differently". One has to wonder why they thought that using different names was a good thing in first place

Technically 68EC030 can do anything when executing this instruction because it is not documented as supported, even if most CPUs do handle it fine. Most likely f-line never happens and instruction works perfectly but CPU also might hang if that part of MMU is broken.

Understandable, although, as far as I know, Motorola never bothered giving a warning (unlike it did with pflusha for 68EC040 and 68EC060) - so I had assumed that accessing the unexisting registers would throw and F-line exception.

UAE simply behaves like "proper" 68030 would work (except TC) because that is how 68EC030 I had in 1990s behaved.

Unfortunately I don't have any 68EC030 for testing.

And, even if you had one, it would be just one and not cover all the possible cases...
The solution you went for is fine already
And, software-wise, I guess the only option is slapping a notice in the readme that says: DO YOU HAVE A 68EC030? THIS THING MIGHT NOT WORK!

[Thomas Richter]

There is unfortunately no reliable way how to detect an EC model. Motorola produced the ECs from the same mask set, and either sold those chips as EC whose MMU did not work reliable or could not work up to the specs, or simply sold totally fine CPUs as EC models because there was more demand.

The mmu.library performs a "MMU dry run" by changing the MMU mapping, remapping parts of the kickstart ROM to some other place and then checks whether that operation was successful - but as said, this test may even pass on ECs and the EC CPU may just react strangely later on - for example if some timing constraints cannot be met, the system may hang or crash without giving software a chance to detect the situation reliably.

[saimo]

Originally Posted by Thomas Richter

There is unfortunately no reliable way how to detect an EC model. Motorola produced the ECs from the same mask set, and either sold those chips as EC whose MMU did not work reliable or could not work up to the specs, or simply sold totally fine CPUs as EC models because there was more demand.

Lucky those who got a full 68030 for a lower price

The mmu.library performs a "MMU dry run" by changing the MMU mapping, remapping parts of the kickstart ROM to some other place and then checks whether that operation was successful - but as said, this test may even pass on ECs and the EC CPU may just react strangely later on - for example if some timing constraints cannot be met, the system may hang or crash without giving software a chance to detect the situation reliably.

I feel the pain.