jb10320@uxa.cso.uiuc.edu (Desdinova) (10/16/90)
It's time to stop bitching and start developing. The Apple II is in
*OUR* hands now, not Macintosh Corp's. If it dies, it dies becuase
we let it.
Also, attention Todd Bakal- if you could, please forward this discussion
to ASIC- the hack which I'm working out is of course just that- a hack.
But, it could be implemented an order of magnitude more easily within
a VLSI chip (where it belongs). ASIC should contemplate supporting
virtual memory functions after we get a functional multitasking OS up
and running.
I've posted a number of messages in the past couple weeks relating to
this project. I've worked out the basic low-level hardware needed to
implement the following:
Base Register
Bounds Register
Abort of process accessing memory outside its allotted range.
User/System flag
Basically, it works like this. The processor loads the base register
with an offset. This offset will be added to each and every memory
access address. Each time the processor spits out an address, it is
also compared to the Bounds register, to be sure it's not out of range.
To be sure, this is a primitive system, but it's the only hack that's
guaranteed to work in an accelerator (more on that later).
Any time an illegal memory access is detected, the Abort pin on the '816
is activated to cancel the current instruction without modifying either
registers or memory. The OS handles the abort interrupt by killing the
offending process. Not exactly an elegant solution, but one which many
architectures use.
Also, upon any interrupt (software or hardware), the VMEM is switched
into System mode-i.e., no address translation or checking is performed.
It's assumed the OS knows what it's doing.
The physical parts needed to implement the registers, translation and
checking are the easy part.
The hard part is developing a protocol for the '816 to talk to the VMEM
control circuit. My preliminary idea is as follows:
------------------------------------------------------------------------
To make a system call (i.e. switch from User mode to System mode via
software), use the COP instruction. It's perfect for this sort of thing.
Since the '816 has no I/O ports, all interaction between the '816 and
other devices must occur through memory mapping. OR, through outside
interception of instructions. I believe the transwarp already has to do
this in certain cases (I may be wrong), so the technique is valid.
Basically, the VMEM must watch the data bus for a COP instruction. The
'816 has signals for when it's fetching an opcode, so when COP and this
signal (VPA) is true, switch to System mode. The '816 will continue the
software interrupt as usual, in the Physical Address Space.
The OS will do its thing, then need to return. To accomplish this,
an RTI instruction should be executed. But it must be executed inside
the calling processes VMEM space. So some flag will need to be set to
say, "On the next RTI instruction, switch back to User mode".
The same thing will happen during a hardware interrupt (IRQ, NMI, Abort)
except that the VMEM will switch to User mode on one of these external
signals.
Communication with the flag and registers can be accomplished through
any convenient memory mapping (perhaps in the bank 80 area?)
------------------------------------------------------------------------
In an attempt at clarity, I will end this description here. Hopefully,
a bite-sized piece such as this (well, a big bite) will be easier to
"digest".
Please, if you have any comments or suggestions, or see any obvious flaws,
or just feel repulsed by the hackish nature of it all, let your opinion/
design be known. But POST it. It can only encourage real discussion
to occur once more on csa2.
p.s. If you're wondering why I'm going to all this trouble, drop me a
note. I'd be glad to enlighten programmers to the amazing benefits of
this simple VMEM.
--
Jawaid Bazyar | Blondes in big black cars look better wearing
Senior/Computer Engineering | their dark sunglasses at night. (unk. wierdo)
jb10320@uxa.cso.uiuc.edu | The gin, the gin, glows in the Dark!
| (B O'Cult)
Apple II Users Unite! Storm the New Product Announcement and Demand Justice!mrapple@quack.sac.ca.us (Nick Sayer) (10/17/90)
I used to own a Momentum Hawk-32. An old System 7 unix box. It had a 68000 and just about an exact copy of the VM scheme you describe. It ran unix. I see no fundamental reason why a GS with such a scheme could not also run unix, given it had an el-huge-o hard drive, an accelerator (optional, but required for processing within human lifetimes), and a few grand for the unix source. And get this: The hawk had LESS memory installed than my GS!!! I have a Sun 2 running SunOS 4.0 now, and I'm feeling much better. -- Nick Sayer | "Disclaimer? I don't think so! mrapple@quack.sac.ca.us | Homey don't play dat." N6QQQ [44.2.1.17] | 209-952-5347 (Telebit) | -- Homey the Clown
MQUINN@UTCVM.BITNET (10/18/90)
On Tue, 16 Oct 90 02:43:43 GMT <info-apple-request@APPLE.COM> said: >It's time to stop bitching and start developing. The Apple II is in >*OUR* hands now, not Macintosh Corp's. If it dies, it dies becuase >we let it. No. If it dies, it dies because APPLE did it. We've been doing just about everything WE can to keep it alive. "WE" can't give ourselves hardware upgrades. We can, of course, buy the extra hardware that already exists, but what about increasing the GS's graphics capabillities (don't tell me to get the overlay card. That's hardly a solution), having the abillity to choose between a large variety of software and know we can expect updates on most of them for the current GS and NEW hardware that would have existed? I'm not flaming you. I'm just trying to point out that it's not our fault if it dies. > >-- >Jawaid Bazyar | Blondes in big black cars look better wearing >Senior/Computer Engineering | their dark sunglasses at night. (unk. wierdo) >jb10320@uxa.cso.uiuc.edu | The gin, the gin, glows in the Dark! > | (B O'Cult) >Apple II Users Unite! Storm the New Product Announcement and Demand Justice! I like the last line in your sig! ____________________________________________________________________ | | | | This is your brain... | BITNET-- mquinn@utcvm | | This is your brain on drugs... | pro-line: | | This is your brain on whole wheat.| mquinn@pro-gsplus.cts.com | |____________________________________|_______________________________|