rbannon@mira.acs.calpoly.edu (Roy Bannon) (02/18/91)
Hi folks, guess you all figured that I had sorta faded away into the ether. Not so, just got real busy with classes and my job, (which is where am I know, so don't tell my boss :-) ). Anyway, heres my latest thoughts. The idea had been to implement a mmu on the GS using a motorola 68851 pmmu chip. I finally got the data book on the thing a couple of weeks ago. I think there is a big problem with using it on the gs. The 68000 series uses address strobe and dack to get data from memory. The pmmu takes the as from the 68000 does a lookup and the issues a as to memory with a new address. The problem I see is that the 65816 wants to see data on the up edge of the clock. Even using the fastest version of the pmmu, it would delay the time when the address becomes valid til it was too late for the memory to respond in time for the rising edge. Also, the glue logic would have to convert all the 65816 signals to 68000 like signals and the convert the 68000 back to 65816. This is because the pmmu stores most of its translation tables in RAM. So when it tries to look up an address that isn't in its cache, it finds it in RAM itself by becoming bus master. This would drive the cost of this thing way up. Secondly most of the pmmu features relate to address translations for virtual memory. This means we wouldn't be using all the features of the chip we bought. So, As I see it, what we need is a more simple implementation of memory protection. So, here goes. Break the memory up into 256 byte pages (the pmmu does this too). Then make put 64k x 8 of static ram on the new daughter board. This will hold an eight bit code for each page. When the 65816 asserts an address, the ram will give the current code of that page. A state machine will check that code against the type of cycle. For example maybe 1 bit for whether the page is writeable, and 7 bits for who owns it. Or depending on the cost of the ram, make it 64k x 16 bits and encode more stuff. I would like to hear from all of you out there about this. The state machine would then keep track of which process was currently runing and check its access rights against the code. Since the machine isn't doing any address translation, the address can be presented to main memory as usual. If the state machine determines a page fault, it will assert abort for one clock cycle so that the data coming back from RAM will be ignored. This 64kx8 could be mapped into the highest ram bank ($7F) and accessible only by the memory manager. A couple of control locations need to be mapped somewhere else (like bank $80) so that you can tell the state machine to switch process and maybe some other locations so when a page fault occurs you can tell why. This should cost a lot less than using the 68851 pmmu, with the drawback of virtual memory support. Anyway, lets here the flames people. Now that that's done, we can get back tothe Mac Lc vs GS comparison (oh boy!). Roy rbannon@cosmos.acs.calpoly.edu
bazyar@ernie (Jawaid Bazyar) (02/18/91)
In article <27bef335.4e12@petunia.CalPoly.EDU> rbannon@mira.acs.calpoly.edu (Roy Bannon) writes: >The idea had been to implement a mmu on the GS using a motorola 68851 pmmu >chip. I finally got the data book on the thing a couple of weeks ago. I think >there is a big problem with using it on the gs. The 68000 series uses address >strobe and dack to get data from memory. The pmmu takes the as from the 68000 >does a lookup and the issues a as to memory with a new address. The problem I >see is that the 65816 wants to see data on the up edge of the clock. Even >using the fastest version of the pmmu, it would delay the time when the address >becomes valid til it was too late for the memory to respond in time for the >rising edge. The AS could be simulated, or just tied to one of the clocks and VPA/VDA (to be sure that a valid address is on the bus) I talked to some WDC engineers about the second thing. They said that by pulling the RDY line on the '816, you could effect a wait state, which would end before the next rising edge of the clock. >Also, the glue logic would have to convert all the 65816 signals >to 68000 like signals and the convert the 68000 back to 65816. This is because >the pmmu stores most of its translation tables in RAM. So when it tries to >look up an address that isn't in its cache, it finds it in RAM itself by >becoming bus master. This would drive the cost of this thing way up. I didn't see this problem- set it up so that the PMMU is ALWAYS the bus master- even in regular non-protected mode the '816. Also, the '816 has a bus enable (BE) so that it can easily be taken off the bus. >Secondly most of the pmmu features relate to address translations for virtual >memory. This means we wouldn't be using all the features of the chip we >bought. >So, As I see it, what we need is a more simple implementation of memory >protection. > >So, here goes. > >Break the memory up into 256 byte pages (the pmmu does this too). Then [...] This basically looks good, except that I would recommend a 32Kx16 setup. That allows for 8 megabytes of memory under 'protection'. Plus- and this is important- it would allow assigning an entire Memory Manager UserID per 256 bytes. If we assume that a process has the right to do whatever, whenever to its memory, then we don't need an access flag (it's implied). Your new plan also has another benefit, being that the modifications to the Toolbox/GSOS would be minimal, almost trivial. It simplifies things such as programs going straight to screen memory, etc. I just looked at my Toolbox ref, and actually only 11 bits of a UserID are necessary to unambiguously identify a process under GS/OS, so that leaves you 5 bits for whatever. About how to handle page faults- in the case of a fault, writes must be prevented from happening. Checking the hardware ref, we have 'round 250 ns to detect a fault and make sure R/W stays high (i.e. make sure write is turned off). >This should cost a lot less than using the 68851 pmmu, with the drawback of >virtual memory support. Anyway, lets here the flames people. True- I'm pushing for VM support because it would in the future allow for pre-emptive multitasking and clean up the '816s architecture software- wise (e.g. have as much stack space as needed). -- Jawaid Bazyar |"I'm sure K&R have never heard of Mike." Senior/Computer Engineering | bazyar@cs.uiuc.edu |"That's okay. I'm sure Mike's never heard of K&R". Apple II Forever! | (discussion about Orca/C)
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (02/18/91)
The only problem with this technique is that you don't have any way of
preventing the CPU from writing data to memory until it is too late.
--------------------
Jeffrey Hutzelman America Online: JeffreyH11
Internet: jh4o+@andrew.cmu.edu BITNET: JHUTZ@DRYCAS
>> Apple // Forever!!! <<spi@pro-grouch.cts.com (John Wilson) (02/18/91)
In-Reply-To: message from bazyar@ernie This is a proline coverup story. READ, its important for all to know about this scam from Morgan Davis. Anonymous Concerned Proline Sysop --------- --------- ------- ----- Date: 14 Feb 91 13:00:50 PST From: mdavis@pro-sol.cts.com (Morgan Davis) Subject: The Whole Story (part 1 of 2) Newsgroups: pro.team Okay, okay. I think it is time to speak up about this protocol thing, lest it get totally out of hand. I'll cover the past and future (ZMODEM). All the cards on the table, shall we? As you know, I've been working on a protocol solution for ProLine for some time. The intracacies of squeezing new technology into your Apple II boxes is not a trivial task. I think most of you can appreciate this when you look at all the other things I've managed to figure out. If you think I have some sort of fear or reluctance to add new protocols, you're dead wrong. I laid down the specifications for 4K XMODEM and successfully implemented it (and other XMODEM variations) into MouseTalk over two years ago. I was hired by Beagle Bros in 1989 to work on a complete communications module for an integrated Macintosh product that never got off the ground (very much). Anyway, I want to put to rest all those feelings you may have that I've somehow made promises I can't keep, or cheated you. This, I just had to say, in case any of you can relate to Kevin Black (and God help you if you do). Now, here's the whole story. BTW, this is being sent to pro.team beacuse I DON'T WANT ANY OF THIS TO LEAVE THE CONFINES OF OUR SYSOP-ONLY DISCUSSION AREAS. About three years ago, I got serious about adding 1K XMODEM to ProLine. ZMODEM wasn't even popular then, recall. I began writing the code to add to ModemWorks and its existing 128-byte XMODEM. It suddenly occurred to me that this new XMODEM chunk of code would be sitting around in memory all the time, wasting space that could be better used. After all, if you had to figure out the percentage of occassions when XMODEM is used, it would probably be less than 5%. What a waste. After all that coding, I scrapped the idea. Obviously, the architecture of ModemWorks (at the time) didn't readily lend itself to this. Plus, what happens down the road when a new protocol comes out that the sysops are clamoring for? It became clear that I'd have to pretty much rewrite ModemWorks -- a prospect not very desirable. After all, it had taken four years of hacking to get it where it was. Meanwhile, the facts of daily life became all too much a reality. Rewriting ModemWorks (and spending all that time doing it) was not going to bring in any income while I was doing it for four, six, eight or however many straight months of doing it (and nothing else) was going to take. I got jobs working for other people, which took time away for this sort of project. The time was not right. Actually, the time will never be right, but... Last year around May, I began to think about the remaking of ModemWorks again. This time, I'd start with a clean slate and address all the problems that we've faced over the years: o New protocols o Real world terminal emulation (this means VT100/ANSI) o Support for all high-end modems o ...and a way to make ModemWorks upwardly compatible with new technology Not a small feat, to be sure. A premise like this required much forethought about the physical nature of ModemWorks at its very foundation. You can't cram every feature at one time into the Apple, so you have to do it in interchangeable chunks, or *modules*. About this time, Beagle Bros let me (and a lot of other good employees) go due to financial trouble. That's when I decided to give the Morgan Davis Group the shot in the arm that it has deserved since I started it. It was always one of those "on the side" businesses. Now it is my sole source of income (which quickly turns into outgo, alas). For once, I felt like I finally had some time to devote to my projects. But, as they would now become my only source of income, I realized that I had a time deficit on my hands. Just the opposite of what I needed. I then laid the foundation by developing the Object Module Manager. The OMM was one of those "developed technologies" that you sell to make money so you can continue to use it to produce larger applications. This didn't take off, though. We've sold only a dozen or so OMM's for $20 a pop. Big deal. After many refinements, the OMM has come together as an excellent platform for all sorts of projects. To test it's abilities in real life, I started working on converting AmperWorks to the OMM format. It was painless. It worked great. So then... ...it was time to start on ModemWorks. With a completely blank slate, I began. First, I created a IIGS serial port module. Then, I wrote a Hayes smartmodem module. The opportunity beckoned to "do it right -- do it smart" this time. My single Hayes module has brains to work with practically any modem that uses the AT command set. In fact, it worked immediately with the Intel 9600EX the very first time I tried it. (The current ModemWorks has trouble dealing with the 9600EX). I had written the smartmodem module last summer, long before the EX was even in beta testing. The very next module was, of course, XMODEM. This one includes both send and receive code for plain 128-byte XMODEM, 1K XMODEM, 4K XMODEM, CRC-16, and the "ProDOS" modes. I still have a text filter and Binary II mode support to finish up. cs>read> Next Date: 14 Feb 91 13:04:51 PST From: mdavis@pro-sol.cts.com (Morgan Davis) Subject: The Whole Story (part 2 of 2) Newsgroups: pro.team In July, 1990, I spoke to Andy Nicholas at the A2-Central Summer Conference in Kansas City. Andy tells me he's working on ZMODEM for the Apple II. He actually got something working and was looking for opportunities to make it available to popular BBS software. After completing the OMM XMODEM module, I knew the time was right to discuss a ZMODEM possibility with Andy. I provided all the specifications (and then some) for Andy's version of ZMODEM for the module-based ModemWorks. He had it completed and working in short order (and commented that getting it to work with ModemWorks was a far sight easier and saner than with GBBS). In the meantime, we had been working out the legalities involved in MDG's *purchasing* the distribution rights to Andy's code. I contacted our own online attorney, Blake Farenthold, who gladly accepted the challenge of drafting up the contract. To this I owe Blake much thanks -- he did a great job, as this is not really his expertise. The contract is the best I've seen, and handled with all the professionalism I would have expected if I had to pay for his services. I think Blake realized that getting ZMODEM for ProLine would end up saving him a lot of money in the long run. It was mutually beneficial to all of us (and that includes you folks, too). Andy and I are still in the process of the legal negotiation. It is slow due to the both of us being super busy with other projects (he's working on the IIGS Finder now at Apple). Note that I said, *purchasing* the distribution rights. Rather than sell ZMODEM ability to each individual site as an option, it is being purchased outright for a one-time fee by the Morgan Davis Group. We can then incorporate it into all of our products. This lessens the burden on all of you, even though MDG will be paying an undisclosed amount. Throughout all this time, you'll no doubt remember, we've had a number of software updates. Pretty major ones (the incoming Patriot included). So you can see why it has taken so long to get where we are. But it wasn't by accident, I assure you. The timing is better than ever. A few years ago, although we needed the software then, the time was NOT right. You just can't rush this sort of thing, not if you intend to do it properly. Alas, here we are. The current situation is that I've developed the OMM, and have created some preliminary (far from finished) modules for testing. Behind all of this is a TON of coding, with at least as much left to go. Here's a tentative To-Do list: 1. Complete XMODEM module 2. Complete Hayes modem modules with true support for v.32 and v.42 3. Complete IIGS port module 4. Create and complete a Super Serial Card version of the serial module 5. Create and complete an Apple-Cat module (this may or may not be so). 6. Do the Console module 7. Do the terminal emulation modules (note: that's plural!) 8. Do the I/O portions of the ModemWorks module (massive job) 9. Integrate all this new stuff into ProLine (easier said than done). 10. Lots of beta testing! 11. Finish the new ModemWorks diskette with new samples, etc. 12. Documentation! (ugh!!!!) So, you can clearly see that great inroads have been made, but we're only about half of the way there. Significant portions are done, but gaping holes exist that make real-world usage a distant reality. The only thing that can help speed all this along is my time and financial status. I'm already forced to do more contract work with other companies to keep food on our table. I hope you folks realize that MDG is not some kind of factory that just turns out code 24 hours a day, consistently. I'm always forced to break away from what I really want to do in order to make a living. Life's a bitch, eh? Your support helps out. I appreciate it. It makes it easier to justify doing things like ProLine updates (which, for the most part, I do in order to *retain* and earn your support!). Anyway, now you know why it has taken this long. Now you know the story about ZMODEM and new protocols. You know they are about 99% reality (they work and exist, but aren't 100% done yet since there is so much left to do in other areas that may effect them). You probably have a good idea of what the next couple of months looks like. You also know that all the whining and ranting about new protocols in the past did ABSOLUTELY NO GOOD at all. In fact, it really put me out about it. I also don't cotton to any more "ETA" message. "When do you think you'll have the protocols done, Morgan? Huh? Huh?" Now you know. Please, leave me alone for a while. P.S. Many of you were just the opposite with respect to pestering me. I got a lot of good support. I thank you for hanging in there and believing in me. cs>read> Next Date: 14 Feb 91 13:25:44 PST From: mdavis@pro-sol.cts.com (Morgan Davis) Subject: Ramifications of Knowledge Newsgroups: pro.team Now that you know a lot more than what I initially wanted you to know, there comes with this knowledge some possibility of risk for MDG. If the general public realizes that ProLine will have improved protocols in the future, most people will put off their purchase until the final "New and Improved" product is released -- because you never know what may come out of a different company in the meantime. This is is one reason why it is very important that we do not discuss improved protocols in an open forum. If this happens on a large scale, the fallout will effect you. In fact, the product may not even be completed. If I can't afford to stop my current projects and finish the new ModemWorks because sales have declined significantly, I'll have to work on other immediate forms of income: contract jobs, short-term development projects, TYPESETTING NEW MANUALS for special marketing, etc. In the same vein, it is important to appease those customers who are unaware of the future of ProLine so that they will invest in it now. This is one reason why I've always maintained that work has always been in progress on new advancements for ProLine. It's not a lie. It's true. It sustains the business I need to continue to develop the product. So please jump in when you can to help defend ProLine against those who lambaste it for missing key features. Your messages that sarcastically harm the protocols issue in the eyes of potential sysops is self-defeating. Your "call to arms" messages (if we all just send lots of money to Morgan, maybe he'll do the work), all have negative effects on the consumer out there who is contemplating a $200 software purchase. Your attempts are admirable, but not helpful. I won't mention any names, but these sort of harmful messages have come from sites like pro-truckstop, pro-pac, pro-party, and others. Also, let's talk about how YOU are to come into possession of all of this new technology... I can PROMISE you that such a MAJOR update to ProLine demands an update fee. Not only is it ZMODEM, or 1K XMODEM, you'll be getting, but you'll be getting all the work that went into making this happen on ProLine: the OMM, the new MOdemWorks with new *everything*, rewrites of programs on ProLine that use XMODEM now (DL, CS, bin/xmodem, MDSS, you name it!). Because a new ModemWorks in involved, I don't pretend that there will be only minor modifications to other areas of ProLine -- there will be lots of surgery all across the board. We will be timing this update with a price increase on ProLine, too. Since you can now buy ProLine for less than $100 through mail order houses, we're not making enough profit to keep the retail price at $195.50. I don't know what the final price will be, but I can assure you it will be fairly significant. For you guys, that's good news -- your purchase has INCREASED in value! For newcomers, they'll pay more for the difference in price between what you spent initially plus your upgrade fee. You'll make out well in the end. Better than new customers. This is another reason to try recruiting your friends and associates to get onto the ProLine bandwagon NOW. Though you won't be able to give them any specific details. DO NOT mention the price increase. This will come in an official press release when the product is announced. Just persuade them for other positive reasons for buying ProLine, not because it will be more expensive in the future. Thanks for taking the time to read every word in these last couple of messages. It is all too important for you to breeze over it. --Morgan cs>read> Next ---- ProLine: spi@pro-grouch Internet: spi@pro-grouch.cts.com UUCP: crash!pro-grouch!spi ARPA: crash!pro-grouch!spi@nosc.mil
rbannon@mira.acs.calpoly.edu (Roy Bannon) (02/19/91)
> This basically looks good, except that I would recommend a 32Kx16 setup. >That allows for 8 megabytes of memory under 'protection'. Plus- and this >is important- it would allow assigning an entire Memory Manager UserID >per 256 bytes. If we assume that a process has the right to do whatever, >whenever to its memory, then we don't need an access flag (it's implied). >Your new plan also has another benefit, being that the modifications to >the Toolbox/GSOS would be minimal, almost trivial. It simplifies things >such as programs going straight to screen memory, etc. > I just looked at my Toolbox ref, and actually only 11 bits of a UserID >are necessary to unambiguously identify a process under GS/OS, so that leaves >you 5 bits for whatever. > About how to handle page faults- in the case of a fault, writes must >be prevented from happening. Checking the hardware ref, we have 'round >250 ns to detect a fault and make sure R/W stays high (i.e. make sure >write is turned off). > >>This should cost a lot less than using the 68851 pmmu, with the drawback of >>virtual memory support. Anyway, lets here the flames people. > True- I'm pushing for VM support because it would in the future allow >for pre-emptive multitasking and clean up the '816s architecture software- >wise (e.g. have as much stack space as needed). > >-- >Jawaid Bazyar |"I'm sure K&R have never heard of Mike." >Senior/Computer Engineering | >bazyar@cs.uiuc.edu |"That's okay. I'm sure Mike's never heard of K&R". > Apple II Forever! | (discussion about Orca/C) Why would my implementation not allow for pre-emptive multi-tasking? You would have only as much memory as you got, but it keeps processes from stomping on each other. If we add a feature that also monitiors opcodes and aborts stuff that changes the global processor status, I think it should work. What does VM have to do with pre-emptive multitasking? Oh well, I'm personally going for the custom hack still as opposed to the 68851, for the reason that my scheme could still work with accelerators. I just did some quick calcs and 15 MHz support should be OK. I think the people that would be really interested in buying this are the same people who already have accelarators andprobably don't want to give up their accelerators for an mmu hack. Roy rbannon@cosmos.acs.calpoly.edu
bazyar@chip (Jawaid Bazyar) (02/19/91)
In article <27c00f84.4155@petunia.CalPoly.EDU> rbannon@mira.acs.calpoly.edu (Roy Bannon) writes: > >Why would my implementation not allow for pre-emptive multi-tasking? Well, I exaggerated the case. Modifying the tools for multitasking would be a lot cleaner with an MMU. > You would >have only as much memory as you got, but it keeps processes from stomping on >each other. If we add a feature that also monitiors opcodes and aborts >stuff that changes the global processor status, I think it should work. What >does VM have to do with pre-emptive multitasking? Oh well, I'm personally >going for the custom hack still as opposed to the 68851, for the reason that >my scheme could still work with accelerators. I just did some quick calcs >and 15 MHz support should be OK. I think the people that would be really >interested in buying this are the same people who already have accelarators >andprobably don't want to give up their accelerators for an mmu hack. One thing that was mentioned by another (as well as myself), is a concern about keeping invalid writes from occurring. Contrary to what I said above, I've not convinced it would work. You can prevent a write, but in the event of a valid access, can you turn it back on again in time for the RAM chip to respond properly? And you're right, your scheme is definitely more attractive for use with accelerators. If you're gung ho about this, send me mail and we can start working out details of implementation (including what to do with tool sets, and checking out the write signal thing). -- Jawaid Bazyar |"I'm sure K&R have never heard of Mike." Senior/Computer Engineering | bazyar@cs.uiuc.edu |"That's okay. I'm sure Mike's never heard of K&R". Apple II Forever! | (discussion about Orca/C)
gwyn@smoke.brl.mil (Doug Gwyn) (02/19/91)
In article <27c00f84.4155@petunia.CalPoly.EDU> rbannon@mira.acs.calpoly.edu (Roy Bannon) writes: >What does VM have to do with pre-emptive multitasking? Absolutely nothing, with the exception that it would introduce a new cause for preemption: "segmentation violation trap". However, that is not needed for multitasking; it would have two main uses: to allow dynamic reallocation of stack and heap when a task expanded its data requirements, and to catch programming errors that result in a sufficiently wild misreferencing of memory locations. Personally I don't think these advantages would justify the cost of the hardware.
dzimmerman@gnh-tff.cts.com (Daniel Zimmerman) (02/21/91)
All of that stuff you posted from Morgan Davis, you consider to be a "scam"?
Where is the "scam"? Sorry, I just don't get it... It also seems sort of, well,
inappropriate for that to have been posted here, though I have no say in that
of course... All I can say is, how would you like it if someone posted some
private messages of yours all over the Internet?
And I don't even OWN Proline (I run an EBBS) - I just think posting that stuff
was a rather low thing to do...
------------------------------------------------------------------------------
Daniel M. Zimmerman InterNet - dzimmerman@gnh-tff.cts.com
TFF Enterprises America Online - Surak TFF CompuServe - 76407,2246
"Learn reason above all. Learn clear thought; learn to know what is from what
seems to be, and what you wish to be. This is the key to everything: the truth
of reality, the reality of truth. What IS will set you free."
- Surak Of Vulcan