Minimig Review completed!

[riftcon]

Piru wrote:
Missing sprites and such glitches are due to chipset implementation and should be possible to fix easily.

68ec000/68sec000 only causes trouble with games/demos/apps that use "move from sr" in user mode, or call GetCC() [as long as GetCC is not patched].

I'd estimate most trouble are from the chipset emulation issues, rather than "move from sr".

This is really weird. I've just had a friend try out a CPU checker I wrote, his MiniMig executes "move sr,d1" just fine in user mode.

In fact, when I read the sec000 documents, they say it's object code compatible with the ec000, and in ec000um.pdf, move from sr is NOT marked as being supervisor only.

What the *** is going on here? Which document says it's supervisor only? Has anyone confirmed it is in fact privileged? I'm not going to offer my checker for anyone to try, it would be better with another separately developed program, I'm not ruling out any bugs in my code just yet

[riftcon]

TobiFlex wrote:

riftcon wrote:

Which document says it's supervisor only?

M68000PRM.pdf Page 6-17

Interesting. 1-15 in EC000UM.pdf says it isn't.

I'm fairly certain my code is correct, as it correctly detects '000 to '060, the instruction is used as the very first check. If the code didn't work, '010 detection would be broken. Very odd.

[riftcon]

TobiFlex wrote:
The EC000UM.pdf describe the SCM68000. This is a freescale core processor. With other words: this is the 68K IP Core from freescale and this is not a document about the 68EC000.

Fair enough. I don't know what the 68SEC000 is based on, but I'm now 100% certain that user mode move from sr works on the MiniMig. I've tried out a real simple program that reads sr and prints it to the console (the result here is 0004 which is what I would expect), it doesn't try to be clever and detect the CPU.

There's a bootable ADF containing the program AND its source here, for people to try out (it's neither fast, pretty or clever). If move from sr doesn't work in user mode, it will crash. If it does, you should see the sr register's contents (after which the cpu detect program is run and detects it as a 68000). If the first program crashes, the DetectCPU program should print 68SEC000, although you will have to edit the startup-sequence to not run PrintSR so it actually gets that far.

[riftcon]

TobiFlex wrote:
Perhaps is "Move from SR" privileged on the 68EC000 and not privileged on the 68SEC000
Very intresting!

What about "Move from CCR"? It is illegal on the 68000.
What is happend on the 68ec000 and 68sec000?

I just don't know. I'm kinda thinking that they've fixed the hardware in the documentation - perhaps they've simply documented the instruction as being privileged to stop people from using it in user mode to ensure compatibility with other later chips, while still being 100% compatible with old 68000 code?

Regarding kickstart 2.0 on the MiniMig... these are not the droids we're looking for :-D

EDIT: And yes - this is extremely interesting. I wonder if there's another way to detect the SEC.

[riftcon]

Update: Had my friend try out a program with the "move from ccr" instruction on the MiniMig. This crashes, so the SEC looks like it's a standard 68000 so far...