rbannon@batman.elee.CalPoly.EDU (Roy Bannon) (01/11/91)
Newsgroups: comp.sys.apple2 Subject: MMU Project Summary: more thoughts on the IIgs MMU program Expires: Sender: Followup-To: Distribution: world Organization: Cal Poly State University, SLO Keywords: MMU, multitasking GS Hi folks, Okay, after thinking about this some more and actually requesting data books for the 68851 and some samples, I got some more questions for you software jocks out there. I've looked at the 65816 data sheet and the app notes. Don't see an immediate problem with them. The read-modify- write instructions must be aborted before the modify cycle, no problem. Abort can only be a cycle long in order to prevent the abort being aborted. Now my questions, The 68xxx has supervisor mode. How should we fake this on the gs. The gs would have to be in supervisor mode before it could modify the MMU. Some of my thoughts are haveing a memory address which when accessed would switch it to supervisor mode. A second thought is to use a COP $XX instruction which would trigger an abort and put the GS into pseudo supervisor mode. $XX is probably a unique value so things like byteworks shell can still use the rest. This scheme would mean that when a system call was made, the first thing to do would be to execute a cop instruction to set the GS into supervisor mode so that the o/s had supervisor priority. As soon as I get the parts, I'm going to use my old 65816 (replace by the TWGS) on a proto board in the lab to check all this out. My thought now is that basic memory protection would be the first reasonable goal. virtual memory is a ways down the road. Remember, some of you software jocks out there expressed a desire to patch the os and/or the tools to take advantage of this hardware if I get it working, so I'm going to hold you to that :-). Roy rbannon@cosmos.acs.calpoly.edu
AABENSON@MTUS5.BITNET (01/11/91)
Okay, I've heard it said a couple times. Orca uses COP for software interrupts. Why is this? I think BRK would have been a better choice. - Andrew. (aabenson@balance.cs.mtu.edu or aabenson@mtu.edu)
gwyn@smoke.brl.mil (Doug Gwyn) (01/15/91)
In article <91011.085913AABENSON@MTUS5.BITNET> AABENSON@MTUS5.BITNET writes: >Okay, I've heard it said a couple times. Orca uses COP for software >interrupts. Why is this? I think BRK would have been a better choice. Actually COP is used just for debugger traps; that's how the desktop environment is able to move an arrow through the source code as it executes, for example. I don't know why COP rather than BRK. COP does have subcodes, which makes it convenient for the debugger.
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/15/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: >I don't know why COP rather than BRK. COP does have subcodes, which >makes it convenient for the debugger. So does BRK, technically. However, as somebody said BRK is far more common for real crashes and I suspect that Orca doesn't want to exclude GSBug if it is installed. What pisses me off is that Orca's debug code requires the debugger to be present -- a program compiled with it will crash if executed without the debugger around. I tried writing an init to ignore COP's (but to flash the border color as an indicator) but it still crashed -- does anybody know the format of the debug code, i.e. so I can skip over it? I rarely compile in the desktop environment anymore because it is too much of a pain to set the Compile/Link options every time I start Prizm. Todd Whitesel toddpw @ tybalt.caltech.edu
bazyar@ernie (Jawaid Bazyar) (01/15/91)
In article <14857@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >Actually COP is used just for debugger traps; that's how the desktop >environment is able to move an arrow through the source code as it >executes, for example. Too bad I've never seen this done without a system crash close behind... >I don't know why COP rather than BRK. COP does have subcodes, which >makes it convenient for the debugger. But BRK has subcodes too. It was probably an arbitrary choice. Someone should ask Mike if there's a reason in particular. -- Jawaid Bazyar | Being is Mathematics Senior/Computer Engineering | Love is Chemistry bazyar@cs.uiuc.edu | Sex is Physics Apple II Forever! | Babies are engineering
AABENSON@MTUS5.BITNET (01/15/91)
Yeah, but on the IIgs, BRK has an operand, also -- should be able to use that, it would seem. - Andrew. (aabenson@balance.cs.mtu.edu or aabenson@mtu.edu)
rhyde@ucrmath.ucr.edu (randy hyde) (01/15/91)
>>>>>
Okay, I've heard it said a couple times. Orca uses COP for software
interrupts. Why is this? I think BRK would have been a better choice.
<<<<<
Software debuggers use the BRK instruction.
Bill Mensch originally intended the COP instruction to be used for two
purpose-- as a software interrupt (exactly like Byteworks is using it)
and as a mechanism to extend the instruction set. Note that COP is a
two byte instruction with the second byte being an immediately value.
If you read the '816 data sheet closely, you'll note that Mensch reserved
certain opcodes following the COP. This, apparantly, was for opcode
expansion. If someone out there has the specs on the 832 they should post
a message describing if (and how) Bill Mensch put these opcodes to work.
*** Randy Hyderhyde@koufax.ucr.edu (randy hyde) (01/17/91)
>> On the II gs BRK has an operand.
This is an artifact of the disassembler. The "operand" for the
break instruction goes all the way back to the 6502. The original
chip had a bug which pushed the return address of the *next* instruction
(rather than next instruction minus one). BRK handlers on the older
chips always compensated for this. The GS' disassembler simply treated
BRK as a single byte instruction. If you look at all manufacturer's
literature, BRK is always listed as a single byte instruction. It was
Apple who decided it should be a two-byte instruction. COP, OTOH, is
listed in WDC's literature as a two-byte instruction.