CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

[ijor]

All I can find is this on wiki.. Whatever it means.

The 68000 does not meet the Popek and Goldberg virtualization requirements for full processor virtualization because it has a single unprivileged instruction, "MOVE from SR", which allows user-mode software read-only access to a small amount of privileged state. The 68EC000 and 68SEC000, which are later derivatives of the 68000, do meet the requirements as the "MOVE from SR" instruction is privileged. The same change was introduced on the 68010 and later CPUs.

Don't believe everything written in Wikipedia. I don't have any personal experience with the SEC, but that Wiki quote doesn't make much sense to me. I mean, it is basically correct. But the changes they mention were introduced in the 68010, certainly not in the 68EC000. I can't be 100% sure about the SEC, but I still highly doubt it. Having said that ...

IIRC the SEC was supposed to be 100% code compatible, but wiki says otherwise

That's what Motorola documentation claims. But don't believe everything the manufacturer claims either :) Again, I don't have personal experience with the SEC, but I understand it has some minor incompatibilities in some undocumented aspects of the 68K. This would affect mostly copy protections, and may be some demos.

Is there a fallback to a "normal" 68K? As long as there is a fallback, then no harm is done. Otherwise, it might still be good enough for some (most) people. As exxos is saying, in the worst case it is still much more compatible than a 020 or 030 CPU.

[czietz]

Don't believe everything written in Wikipedia. I don't have any personal experience with the SEC, but that Wiki quote doesn't make much sense to me. I mean, it is basically correct. But the changes they mention were introduced in the 68010, certainly not in the 68EC000. I can't be 100% sure about the SEC, but I still highly doubt it.

I guess the explanation in Wikipedia is based on the 68000 PRM, which claims that for the 68EC000 (and therefore also for the later 68SEC000) this instruction is privileged:

MOVEfromSR.PNG

I'm inclined to disregard the official documentation as false, though. The easiest way to confirm that would be simply to test this instruction on the 68EC000/68SEC000.

In any case, if the PRM is right, EmuTOS and Atari TOS 2 have an privilege violation exception handler to deal with software that expects "MOVE from SR" to run in user mode. Thus, it would only be an issue if someone insisted on running Atari TOS 1.

[agranlund]

I'm inclined to disregard the official documentation as false, though. The easiest way to confirm that would be simply to test this instruction on the 68EC000/68SEC000.

Yeah seems very odd they would have introduce that change to the SEC version.
For curiosity sake, it would be interesting to test that instruction and see though :)

But there could be some logic behind it though. I might be wrong, but wasn't the SEC version the last and only 68k replacement for a good while?
Maybe they though the misstake on the original 68000 was a big enough flaw or security risk for industrial/communications/automotive applications that they decided to fix it in the only replacement they offered? (not counting those CPU32 compatible MPUs).
Going with a mindset that the 68000 is "broken", at least from a security standpoint, and the 68010 is the bug-fixed version, it would make some sense in a scenario where they were only selling one legacy 68k model.

I always take those backwards compatibility claims with a grain of salt :lol:
It usually comes with the fine print saying it's for user-mode code only and even then, sometimes requiring the operating system to provide a compatibility layer.
Still, it does feel strange if the 68SEC000 wasn't binary compatible in both user- and supervisor mode..

[ijor]

I guess the explanation in Wikipedia is based on the 68000 PRM, which claims that for the 68EC000 (and therefore also for the later 68SEC000) this instruction is privileged:
MOVEfromSR.PNG

That version of the manual has several errors. Even on this very same topic is not consistent. Indeed it does claim that the MOVE from SR instruction is privileged for the 68EC000. But it also claims that the MOVE from CCR instruction doesn't exist for the 68EC000. And this, obviously, can't be true, one unprivileged variant must exist in any processor.

In any case, if the PRM is right, EmuTOS and Atari TOS 2 have an privilege violation exception handler to deal with software that expects "MOVE from SR" to run in user mode.

That would help in most cases, but not in every case. There are programs that install their own exception handlers.

[ijor]

But there could be some logic behind it though. I might be wrong, but wasn't the SEC version the last and only 68k replacement for a good while?
Maybe they though the misstake on the original 68000 was a big enough flaw or security risk for industrial/communications/automotive applications that they decided to fix it in the only replacement they offered? (not counting those CPU32 compatible MPUs). Going with a mindset that the 68000 is "broken", at least from a security standpoint, and the 68010 is the bug-fixed version, it would make some sense in a scenario where they were only selling one legacy 68k model.

This is not really a security issue. There is no risk of privilege escalation. The issue is that it allows a user program to be aware of its current privilege. And this is a problem for virtualization where you want to run at user level, code originally designed to run with supervisor privileges.

But I doubt embedded systems used much of virtualization at all. Also making that instruction privileged doesn't solve all the virtualization limitations of the 68K. The 68010 introduced other relevant changes, such as implementing instruction restart.

[agranlund]

This is not really a security issue. There is no risk of privilege escalation.

Ah, so it's only from SR that behaves that way and to is not?
Yeah then it's not a security issue, just a slightly odd design then :)

[czietz]

Ah, so it's only from SR that behaves that way and to is not?

MOVE to SR is always privileged, even on the original 68000. As ijor mentioned, MOVE from SR not being privileged only means that something like a hypervisor cannot "lie" to programs about the mode they are running in.

But we are discussing this particular instruction for far too long now, imho. There are prototypes of the 68SEC000-based booster. Why not just test and come to a definitive answer?

[exxos]

But we are discussing this particular instruction for far too long now, imho. There are prototypes of the 68SEC000-based booster. Why not just test and come to a definitive answer?

I'm afraid I wouldn't have a clue how to program such a test personally. If someone can code it then next time I have the SEC plugged in I can test it out.

[czietz]

I'm afraid I wouldn't have a clue how to program such a test personally. If someone can code it then next time I have the SEC plugged in I can test it out.

Here you go. Test program runs "MOVE SR,Dx" in user mode and tests whether this is a privileged instruction. It isn't on the 68000 and it should not be on the 68SEC000, either.

[exxos]

As a small update. I designed this new SRAM board for the H5 a few weeks back. I finally found a company to do a small batch of 5. This isn't cheap as the parts are expensive and total about £100 a board basically.

This is my next alt-ram board which buffers and isolates the CPU bus to and from the ST bus. So rather than the CPU trying to drive 250pf per pin, it only has to drive the buffers now which are more like 5pf. So I hope that 20ns delay will reduce to more like 10ns.Otherwise it be a rather costly waste of time :)

I think the CPU will run cooler as well. It doesn't even get hot currently anyway. It will be interesting if I can hit my new 75mhz target :)

Capture (1).JPG