CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Information and news about the 68SEC000 64MHz booster.
ijor
Posts: 439
Joined: Fri Nov 30, 2018 8:45 pm

Re: CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Post by ijor »

exxos wrote: Tue Mar 22, 2022 8:40 pm 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.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
czietz
Posts: 553
Joined: Sun Jan 14, 2018 1:02 pm

Re: CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Post by czietz »

ijor wrote: Tue Mar 22, 2022 11:19 pm 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
MOVEfromSR.PNG (22.96 KiB) Viewed 2754 times

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.
User avatar
agranlund
Posts: 873
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Post by agranlund »

czietz wrote: Wed Mar 23, 2022 7:35 am 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
Posts: 439
Joined: Fri Nov 30, 2018 8:45 pm

Re: CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Post by ijor »

czietz wrote: Wed Mar 23, 2022 7:35 am 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.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
ijor
Posts: 439
Joined: Fri Nov 30, 2018 8:45 pm

Re: CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Post by ijor »

agranlund wrote: Wed Mar 23, 2022 8:34 am 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.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
User avatar
agranlund
Posts: 873
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Post by agranlund »

ijor wrote: Wed Mar 23, 2022 2:41 pm 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
Posts: 553
Joined: Sun Jan 14, 2018 1:02 pm

Re: CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Post by czietz »

agranlund wrote: Thu Mar 24, 2022 10:56 pm 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?
User avatar
exxos
Site Admin
Site Admin
Posts: 24083
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Post by exxos »

czietz wrote: Fri Mar 25, 2022 7:38 am 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.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
czietz
Posts: 553
Joined: Sun Jan 14, 2018 1:02 pm

Re: CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Post by czietz »

exxos wrote: Wed Apr 13, 2022 10:20 am 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.
Attachments
privtest.zip
(752 Bytes) Downloaded 91 times
User avatar
exxos
Site Admin
Site Admin
Posts: 24083
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Post by 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
Capture (1).JPG (124.43 KiB) Viewed 2483 times
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Post Reply

Return to “SEC 64MHZ BOOSTER”