68030, 68040 and 68060 MMU support (really!)

[Toni Wilen]

Which test number? (I never do any extra work when there is no need..)

EDIT: Try winuae.7z because I yesterday found one bug that used wrong size but oddly enough no unix-like OS cared..

[plasmab]

Originally Posted by Toni Wilen

Which test number? (I never do any extra work when there is no need..)

maximise work not done

[Wepl]

winuae.7z works

[Toni Wilen]

Great. I am still wondering how anything could have ever worked with that bug..

Could you also test MOVES? Does SSW FC bits also modify MOVES's retried access?

It probably does but MOVES is a special kind of instruction (only one that can do memory accesses using different FC mode) so there could be differences.

[Wepl]

Originally Posted by Toni Wilen

Great. I am still wondering how anything could have ever worked with that bug..

for virtual memory the operand size is not relevant I think

Originally Posted by Toni Wilen

Could you also test MOVES? Does SSW FC bits also modify MOVES's retried access?

It probably does but MOVES is a special kind of instruction (only one that can do memory accesses using different FC mode) so there could be differences.

If the test works, extending it to moves will be simple.
It's a bit difficult to test this under whdload because of the exception handler in whdload. It makes some things invisible. Still trying.

[Wepl]

I have added 4 tests to check supervisor protection.

4105 move from user mode, faults
4106 as above but with fix in af which replaces fc in ssw and retries
4107 moves with sfc=1 mode, faults
4108 as above but with fix in af which replaces fc in ssw and retries

First 3 tests succeed with latest WinUAE beta. Last hangs.
Not yet tried on real hw.

see http://whdload.de/whdload/Harddisk-WHDLoad-Test.zip

[Toni Wilen]

Thanks!

It seems to work correctly except MOVES which didn't expect to get retried this way and always uses original FC.

Next step is to test it using real hardware (I have 68030 boards but first I need to transfer the test which is always boring ) because if MOVES does not support FC modification, I don't need to fix it but simply skip MOVES special retry and generate bus error again.

[Toni Wilen]

Tested on real hardware. 4105-4107 works identically.

Originally Posted by Wepl

4108 as above but with fix in af which replaces fc in ssw and retries

This returns:

34108 -> FAILED expected OK got EXCEPTION
Exception "Illegal Instruction" ($10)
at $20200 occured.

Weird..

EDIT: I added MOVES SSW FC modification support and now I get same illegal instruction exception (bug in this test?). So I guess this confirms MOVES is also affected

[Wepl]

Yes this was bad test code ("jmp (a0)" instead rts).
If you want updated please let me know.

[Toni Wilen]

That fix isn't important but could you do some more tests:

Fill the target address with some pattern
Supervisor protect it.
Write long in user mode (with different data pattern than already in memory)
In access fault handler change SSW FC to supervisor and ALSO change SSW size to byte and then retry it.
Check target memory by comparing written data with original data. Did it write long or only byte?

If only byte was written: same test using read. If you use someting like move.l (a0),d0 prefill d0 with some pattern, then change SSW FC and size again. Did D0 change completely or did only byte part change?

[Wepl]

I've added both tests:
4109 write
4110 read
Not tested on real hw yet. I'm unsure if 4109 is correct because adjustment of data because size change l->b.
In WinUAE 4109 fails and 4110 succeeds.
You only need to exchange the qa.asm (see lines 3000ff). Full zip is nevertheless updated too.

[Toni Wilen]

Originally Posted by Wepl

I've added both tests:
4109 write
4110 read
Not tested on real hw yet. I'm unsure if 4109 is correct because adjustment of data because size change l->b.
In WinUAE 4109 fails and 4110 succeeds.
You only need to exchange the qa.asm (see lines 3000ff). Full zip is nevertheless updated too.

Is it possible to see what data was actually written or read? To confirm what real hardware does.

(I'd like to do some simple test program but creating full valid MMU table for 68030 is too painful..)

[Wepl]

Yes. Use command tr instead t (tr 4109).
This will show whdload requester. Then click on Show Regs.
preinit memory value is $12345678
4109 written was $aabbccdd, d2=value afterwards
4110 d1 cleared, d1=value afterwards

[Toni Wilen]

Originally Posted by Wepl

4110 read

This seems to work identically on real hardware.

Originally Posted by Wepl

4109 write

I changed SFC to DFC. Now it does something but register dump shows D1 = $20592034 and D2 = $d2d22e0e which does not make any sense.. D1 was supposed to be original value ($aabbccdd) and D2 returned value. D0 = 1 which seems to be correct (value written to DFC). Does _failmsg change registers?

(btw, please, add leading zeros to register dump)

[Wepl]

4109:
after correction sfc to dfc and changing the expected result to d2=aa345678 this works on my hardware
4110:
looks a bit strange, d1 contains 2078 after the read, I would expect 78 instead, either I have overseen something or the cpu is doing word transfer and leading 20 is some relict

Originally Posted by Toni Wilen

Does _failmsg change registers?

no

Originally Posted by Toni Wilen

(btw, please, add leading zeros to register dump)

why should I do?

[Toni Wilen]

Originally Posted by Wepl

4109:
after correction sfc to dfc and changing the expected result to d2=aa345678 this works on my hardware
4110:
looks a bit strange, d1 contains 2078 after the read, I would expect 78 instead, either I have overseen something or the cpu is doing word transfer and leading 20 is some relict

I'll try to make my own mini test program some day.. This is no important feature.

why should I do?

Without leading zeros they look like decimal numbers and I always read hex numbers from left to right, can instantly see the magnitude of number by looking for first non-zero number

[Wepl]

Originally Posted by Toni Wilen

Without leading zeros they look like decimal numbers and I always read hex numbers from left to right, can instantly see the magnitude of number by looking for first non-zero number

Ok I prefer it the current way.

[Tomislav]

Or at least put $ (dollar) sign as prefix. It's ok if you write something for yourself your way, but when you write for others it's good to mark somehow that it is not decimal.

[Toni Wilen]

(from old post)

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)

I did some real 68030 testing with enforcer and it seems (most?) instructions that end in write to memory have bus error stack frame PC pointing to following instruction. Even MOVEM to memory does it.

I'll probably emulate this after 4.1.0 is out.

[Toni Wilen]

Originally Posted by Toni Wilen

I did some real 68030 testing with enforcer and it seems (most?) instructions that end in write to memory have bus error stack frame PC pointing to following instruction. Even MOVEM to memory does it.

I'll probably emulate this after 4.1.0 is out.

Implemented now.