Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!jb10320 From: jb10320@uxa.cso.uiuc.edu (Desdinova) Newsgroups: comp.sys.apple2 Subject: Call for Discussion: GS Virtual Memory (longish) Summary: I want ideas! Post your Ideas! Apple II Forever! Message-ID: <1990Oct16.024343.3260@ux1.cso.uiuc.edu> Date: 16 Oct 90 02:43:43 GMT References: <1990Oct16.021155.29035@ux1.cso.uiuc.edu> Sender: news@ux1.cso.uiuc.edu (News) Organization: University of Illinois at Urbana Lines: 86 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!