Work on the Minimig core?

[vebxenon]

Today I've tested Amiga OS 3.1.4

Did you use the ROM for the A1200 (68020) or which version did you buy?

1200, yes

[slingshot]

My own kickstarts seem to be ok with just 0.5 MB of slow ram. I have no idea what could cause such behaviour, and that it works for others just makes it weirder

Try this if it works without slow RAM:

minimig_mist.zip

And review the last commits:
https://github.com/mist-devel/minimig-mist/commits/dev

[Lroby74]

My own kickstarts seem to be ok with just 0.5 MB of slow ram. I have no idea what could cause such behaviour, and that it works for others just makes it weirder

Try this if it works without slow RAM:
minimig_mist.zip

And review the last commits:
https://github.com/mist-devel/minimig-mist/commits/dev

It's perfect!
I've used an original A500 KS1.2 OCS 512KB Chip ram, no slow and no fastram, only internal DF0: drive configuration and played with Zak McKraken perfectly!

[kolla]

My own kickstarts seem to be ok with just 0.5 MB of slow ram. I have no idea what could cause such behaviour, and that it works for others just makes it weirder

Try this if it works without slow RAM:
minimig_mist.zip

Nah, same problems as before, still needs slow ram.

On the other hand - now it doesn't matter how much slow ram I configure, it always ends up as 1.5MB according to showconfig, sysinfo etc. Is that just me??

[vebxenon]

I don't have any problem since last stable release...

[slingshot]

On the other hand - now it doesn't matter how much slow ram I configure, it always ends up as 1.5MB according to showconfig, sysinfo etc. Is that just me??

If I set 0.5MB Slow RAM, then 0.5MB will shown in Sysinfo/Memory info. Did you try to remove MINIMIG{1..4}.CFG from your SD-Card?

[MasterOfGizmo]

@retrofan and @slingshot
I hope this one didn't fly under the radar?
http://atari-forum.com/viewtopic.php?f= ... 25#p383381

I have just started to look at that. This also happens in the ghdl simulation. I'll see what i can do ... whenever I touch something in tg68k i am afraid to break something else. tg68k is a VHDL version of a house of cards.

[slingshot]

@retrofan and @slingshot
I hope this one didn't fly under the radar?
http://atari-forum.com/viewtopic.php?f= ... 25#p383381

I have just started to look at that. This also happens in the ghdl simulation. I'll see what i can do ... whenever I touch something in tg68k i am afraid to break something else. tg68k is a VHDL version of a house of cards.

At least there's a CPU tester now to test regressions (ok, it runs only in Amiga-Minimig, but still better than nothing).
Btw, not just the MUL, but the DIV instructions also have problems.

[kolla]

On the other hand - now it doesn't matter how much slow ram I configure, it always ends up as 1.5MB according to showconfig, sysinfo etc. Is that just me??

If I set 0.5MB Slow RAM, then 0.5MB will shown in Sysinfo/Memory info. Did you try to remove MINIMIG{1..4}.CFG from your SD-Card?

Great tip!

Not only did this fix the problem with amount of Slow RAM, it fixed the problem with weird crashes when Slow RAM was disabled!
So I can now happy camper again!

PS: I attach the corrupting config file, in case there is academic interest.

[kolla]

@retrofan and @slingshot
I have just started to look at that. This also happens in the ghdl simulation. I'll see what i can do ... whenever I touch something in tg68k i am afraid to break something else. tg68k is a VHDL version of a house of cards.

That's good, hope you manage.
In the meantime, the IBrowse author reworked the keyfile validator for release 2.5.1, it now recognises my keyfile regardless of the MULU-problem. I keep 2.5 around as test case

[MasterOfGizmo]

Btw, not just the MUL, but the DIV instructions also have problems.

After a few hours of hunting the problem I ended up at this line:

https://github.com/mist-devel/minimig-m ... .vhd#L3246

Commenting that line fixes the problem for me. But of course that may introduce new problems and needs to be investigated a little further. But the real odd thing is the comment '''--???'''. I wonder who put it there. It's been there for at least 7 years and it seems someone tried to fix the same problem. I wonder why he kept that line.

[MasterOfGizmo]

And it seems the 32x32->64 bit version does not work at all:

Code: Select all

mulu.l  d0,d1:d2

This just sets d1 and d2 to zero ...

[slingshot]

Commenting that line fixes the problem for me. But of course that may introduce new problems and needs to be investigated a little further. But the real odd thing is the comment '''--???'''. I wonder who put it there. It's been there for at least 7 years and it seems someone tried to fix the same problem. I wonder why he kept that line.

I can run the CPU tester with commenting that out later on.

[MasterOfGizmo]

And it seems the 32x32->64 bit version does not work at all:

Ok, it _does_ work if one gets the order of the two target registers correct. Looking forward to the CPU test results for MULU.L ....

[slingshot]

And it seems the 32x32->64 bit version does not work at all:

Ok, it _does_ work if one gets the order of the two target registers correct. Looking forward to the CPU test results for MULU.L ....

It's better with the commented out line. Now the next failure:
d4=ffff0000
mulu.l d4,d2:d4

should be (ffff0000*ffff0000=fffe0001 00000000)
d2=fffe0001
d4=000000
sr: 0400

result
d2=7ffe0001
d4=0000000
sr: 0408

Upd.: seems the first line-deleting fix has a real-world implication: saving from UFO AGA (WHDLoad) works.

[kolla]

You have a test build? I have a few more real world cases that I suspect may be related, aside from IBrowse 2.5 keyfile validator

[MasterOfGizmo]

result
d2=7ffe0001

Are you sure? I get d2 = 7ffe8001 in simulation (which of course is even worse ...)

[slingshot]

result
d2=7ffe0001

Are you sure? I get d2 = 7ffe8001 in simulation (which of course is even worse ...)

Yes, you're right. Failed copy/paste by eyes
Seems that last bit is slipped by 16 positions (or just two totally different causes for two bits are inverted).

[MasterOfGizmo]

Yes, you're right. Failed copy/paste by eyes
Seems that last bit is slipped by 16 positions (or just two totally different causes for two bits are inverted).

Try replacing line:
https://github.com/mist-devel/minimig-m ... U.vhd#L849
by

Code: Select all

elsif micro_state /= idle or exe_opcode(15) = '1' or sndOPC(10) = '0' then -- 32 Bit, don't run in idle for MULU.L 64

The problem is that the MULU state machine runs all the time and in the MULU.L case with 64 bit target it might still shift/add while the result is already being processed.

Edit: I am updating the current work in https://github.com/mist-devel/mist-boar ... ests/tg68k. A simple "make clean; make vtest; make view" will currently run the MULU tests and open a window with the traces. Currently all tests in https://github.com/mist-devel/mist-boar ... sts/mulu.s succeed.

[slingshot]

Try replacing line:
https://github.com/mist-devel/minimig-m ... U.vhd#L849
by

Code: Select all

elsif micro_state /= idle or exe_opcode(15) = '1' or sndOPC(10) = '0' then -- 32 Bit, don't run in idle for MULU.L 64

The problem is that the MULU state machine runs all the time and in the MULU.L case with 64 bit target it might still shift/add while the result is already being processed.

It works! Mull.l now fully passes. There's a minor problem with the patch, it introduces a clock because result_mulu doesn't get a value in every case. What would be a good default value (value in 64 bit mode)?

[MasterOfGizmo]

It works! Mull.l now fully passes. There's a minor problem with the patch, it introduces a clock because result_mulu doesn't get a value in every case. What would be a good default value (value in 64 bit mode)?

Exactly that is what's supposed to happen: result_mulu should not change at all in that case. It should stay stable so the 64 bit result can be processed over several steps. Would something like

Code: Select all

else
  result_mulu <= result_mulu;

be helpful? The simulation doesn't have a problem with that.

[slingshot]

It works! Mull.l now fully passes. There's a minor problem with the patch, it introduces a clock because result_mulu doesn't get a value in every case. What would be a good default value (value in 64 bit mode)?

Exactly that is what's supposed to happen: result_mulu should not change at all in that case. It should stay stable so the 64 bit result can be processed over several steps. Would something like

Code: Select all

result_mulu <= result_mulu 

be helpful?

Well, that's the definition of a latch - which we should avoid (this block is purely combinatorial). But the "old" value should come from some previous result, right? Then some register should already contain the data.

[MasterOfGizmo]

Well, that's the definition of a latch - which we should avoid (this block is purely combinatorial).

Ok. The thing is that the input of this block changes, in this case "faktorB" which in turn comes from op2out which is generated somewhere else ... tricky ...

The issue really is that we're writing a partial 32 bit result to the same register that has impact on the computation and thus affects the writing of the second 32 bit. When the first 32 bit register is written then the original source of the faktorB does not exist anymore and we cannot keep the combinatorics stable. The clean solution would be that the final result gets written to mulu_reg and is being read from there.

[slingshot]

Then I tried with brute force:

Code: Select all

	else
		result_mulu <= result_mulu_last;
	.
	.
	.
	if rising_edge(clk) then
		result_mulu_last <= result_mulu

This simulates the latch (with one clock delay, but seems doesn't matter). I agree, the cleanest solution would be to use mulu_reg.

[MasterOfGizmo]

Ok ...

try

Code: Select all

else
   result_mulu <= mulu_reg;

and replace
https://github.com/mist-devel/minimig-m ... U.vhd#L886
by a simple

Code: Select all

  else

Then the mulu_reg always gets updated from result_mulu and thus can be used as a source in the idle state.