Curt Vendel Posted February 8, 2008 Share Posted February 8, 2008 As many in the ST circles are familiar with the fabled Atari "EST" So far I've only located just the plastic shell for this rather interesting beastie. However, today I've come across documents for the MMU for the EST proto, interesting info: EST MMU April 11, 1986 1 EST Memory Controller Memory Management Operations INTRODUCTION This document outlines the MMU functions implemented in the EST memory controller. It does not fully describe the memory controller or the EST system. A comprehensive docu- ment will follow. The EST MCU is capable of rudimentary MMU functions. Address translation is accomplished by MUXing selected upper address lines from a latch, independent of the state as out- put by the CPU. Address protection is accomplished by inhi- biting RAM accesses when certain address lines are high (for instruction-space accesses) or unequal (for data and stack space accesses). ADDRESS TRANSLATION Translation is only performed for user-mode accesses to log- ical addresses between 0x000000 and 0x7FFFFF (inclusive) when the appropriate protection register nibble is nonzero. Memory between 0x800000 and 0xFFFFFF (inclusive) is not translated. Supervisor mode accesses are never translated. If A23 is 1, the MCU does nothing (some other part of the system would have to respond to the memory access in order to prevent a bus error). Zero to fourteen upper address lines (A9 through A22) may be replaced by corresponding bits from the fourteen bit reloca- tion latches. Program and data space accesses use different latches so that each type of access can be relocated independently. The number of address bits replaced by the latch depends on the protection segment size. Address bits are always replaced starting with A22, extending contigu- ously to lower address bits. Segments of size 2**N may be relocated to any location in memory on a 2**N boundary. The only exception to this is physical RAM from 0x000000 to 0x0007FF (inclusive), which is protected against any user-mode access, therefore full map- ping of a user segment to physical 0x000000 is not possible. This prevents the system from having more than one full 4 megabyte segment. Atari Confidential Copyright 1986 Atari Corp. EST MMU April 11, 1986 2 PROTECTION Address protection is accomplished by conditionally inhibit- ing RAM accesses based on the values of selected upper address bits, before any relocation takes place. A protec- tion exception will generate a bus error. The address pro- tection register (`mmuapr') contains two nibbles; the upper nibble controls instruction space protection and the lower nibble controls data space protection. Protection applies only to user-mode accesses; supervisor- mode accesses are never checked. __________________________________________ | protection protected segment | |___nibble_______lines__________size______| | 0 none all of RAM | | 1 A22 4Mb | | 2 A21-A22 2Mb | | 3 A20-A22 1Mb | | 4 A19-A22 512K | | 5 A18-A22 256K | | 6 A17-A22 128K | | 7 A16-A22 64K | | 8 A15-A22 32K | | 9 A14-A22 16K | | 10 A13-A22 8K | | 11 A12-A22 4K | | 12 A11-A22 2K | | 13 A10-A22 1K | | 14 A9-A22 512 bytes | | 15 N/A (not permitted)| |_________________________________________| If A23 is 0 the MMU checks protection. If A23 is 1 the MMU does nothing; this allows data and program access to the ROM (and other unprotected areas) located between 0x800000 and 0xFFFFFF. The instruction space nibble is loaded with the number of upper address bits that are not permitted to be high. (The same number of address bits are replaced with the contents of the program space relocation latch.) If an instruction fetch is made outside the protected area a bus error will occur. The data space nibble is loaded with the number of upper address bits that must be entirely 0 or entirely 1. (The same number of address bits are replaced with the contents of the data space relocation latch.) This allows dynamic stack and data segment growth. For this scheme, data (and BSS) start at logical location 0x000000, and the stack Atari Confidential Copyright 1986 Atari Corp. EST MMU April 11, 1986 3 starts at logical location 0x800000. Data accesses are made relative to location 0, and stack references are made rela- tive to location 0x800000. TRANSLATED/PROTECTED A23 A22 .... A22-N A22-N-1 ... A0 +-----+----------------+----------------------------+ | 0 | latch contents | unchanged | +-----+----------------+----------------------------+ . . . . +----------------+ | must be all 0 | for data and program access +----------------+ or +----------------+ | must be all 1 | for data access +----------------+ UNTRANSLATED/UNPROTECTED A23 A22 A0 +-----+---------------------------------------------+ | 1 | unchanged | +-----+---------------------------------------------+ Atari Confidential Copyright 1986 Atari Corp. EST MMU April 11, 1986 4 OPERATION User processes are linked to begin at 0x000000 and are assigned a segment size in which they must remain. The seg- ment size determines the values of the protection register. For example, a 32K segment requires 15 address lines, A0 through A14. A15 through A22 must be zero (for instruction and data accesses) or all 1 (for stack accesses). The appropriate nibble in the protection register is loaded with with 1000b; this value is constant for any 32K segment. The segment is located in physical memory by translating the upper portion of the address. For the 32K example A15 through A22 will be zero (or all 1) for valid accesses. If the segment is a data segment and the data relocation regis- ters are loaded with high=0x1A and low=0x00, then a data access to address 0x00003C will actually access physical address 0x1A003C, and a data access to address 0x7FFFFE will actually access 0x1A7FFE. Stack and data may be dynamically grown with appropriate support from the compiler and the operating system. The basic idea is to widely seperate the top of the stack and the bottom of the data in logical address space, and to detect (in software) when the two are about to collide in physical address space. The user stack starts at 0x800000; since the first items pushed onto the stack will be located at addresses that have their upper bits all ones, the stack references will be relocated to the top of the segment. The standard procedure invocation should include a test if the stack has reached a "reasonable" limit. When the stack reaches the limit, an operating system call should be made to increase the segment size. LOGICAL PHYSICAL SPACE SPACE 800000 _________________ 800000 7FFFFF | stack | 2**N - 1 + BASE | || | | \||/ | | \/ | / / / / | /\ | | /||\ | | || | 000000 | data | 0 + BASE FFFFFF ----------------- FFFFFF Atari Confidential Copyright 1986 Atari Corp. EST MMU April 11, 1986 5 In assembler, of course, it is the responsibility of the programmer to provide enough stack for the process. Since addresses from 0x800000 to 0xFFFFFF are not relocated or protected, the OS ROMs may be used to contain common libraries (printf or whatever). SYSTEM RESET A system reset sets all bits in the `mmupro' register to zero. No protection checking (other than 0x000000 through 0x0007FF) is performed. The relocation registers are not initialized and should be loaded before a non-zero value is written to the protection control register. Atari Confidential Copyright 1986 Atari Corp. EST MMU April 11, 1986 6 MMU REGISTERS 7 6 5 4 3 2 1 0 Data Relocation High mmudrh +-----+-----+-----+-----+-----+-----+-----+-----+ FF8003 | 0 | A22 | A21 | A20 | A19 | A18 | A17 | A16 | +-----+-----+-----+-----+-----+-----+-----+-----+ Data Relocation Low mmudrl +-----+-----+-----+-----+-----+-----+-----+-----+ FF8005 | A15 | A14 | A13 | A12 | A11 | A10 | A9 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ Program Relocation High mmuprh +-----+-----+-----+-----+-----+-----+-----+-----+ FF8009 | 0 | A22 | A21 | A20 | A19 | A18 | A17 | A16 | +-----+-----+-----+-----+-----+-----+-----+-----+ Program Relocation Low mmuprl +-----+-----+-----+-----+-----+-----+-----+-----+ FF800B | A15 | A14 | A13 | A12 | A11 | A10 | A9 | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+ Protection Control mmupro +-----+-----+-----+-----+-----+-----+-----+-----+ FF800F | Program space | Data space | +-----+-----+-----+-----+-----+-----+-----+-----+ Atari Confidential Copyright 1986 Atari Corp. 1 Quote Link to comment Share on other sites More sharing options...
opcode Posted April 27, 2017 Share Posted April 27, 2017 You know, this gives me a whole new perspective on Atari Corp. Definitively not the cheap, lazy, penny-pinching company I sometimes think of them, at least not in the hardware department. Can you imagine if they had put this thing out in 1987, same year as the Mac II? Not too mention the EST case was a thing of beauty next to the fugly Mac II. Too bad something was always holding Atari Corp back... Quote Link to comment Share on other sites More sharing options...
zzip Posted April 28, 2017 Share Posted April 28, 2017 Too bad something was always holding Atari Corp back... They always had ideas, just couldn't execute. Ultimate probably lack of resources to market things properly. Quote Link to comment Share on other sites More sharing options...
Tillek Posted April 29, 2017 Share Posted April 29, 2017 Yeah, if ideas were really worth anything by themselves, I'd be a millionaire and able to afford to make my ideas reality. But still, this was great information, thank you! Quote Link to comment Share on other sites More sharing options...
calimero Posted June 10, 2017 Share Posted June 10, 2017 Here you will find more on history of TT (and EST): http://www.atari-forum.com/viewtopic.php?t=23603&start=25#p222128 Roy Good come to Atari Corp. to lead development of 32bit Unix machine. I think that he did not start this project - I think Shiraz Shivji start it since he was talking about 32bit ST before Roy get into Atari Corp.: http://st-news.com/issues/st-news-volume-2-issue-7/features/interview-with-shiraz-shivji/ I think that Shiraz left Atari Corp, than Roy come to finish work on EST that become TT - this would explain such delay in announcement (1986.) and production (1990.) of 32bit ST. Atari Corp timetable: http://mcurrent.name/atarihistory/tramel_technology.html Rou Good come to Atari in Jan. 1987 Shiraz Shivji left Atari in Feb 1989. - Roy takeover development Quote Link to comment Share on other sites More sharing options...
calimero Posted July 11, 2017 Share Posted July 11, 2017 sorry for bad link in previous post: http://st-news.com/issues/st-news-volume-2-issue-7/features/interview-with-shiraz-shivji/ and I misspelled Roy J. Good name. Quote Link to comment Share on other sites More sharing options...
landondyer Posted July 15, 2017 Share Posted July 15, 2017 This is the MMU that I described in my blog. We called it the GMMU, for "Garbage Dump MMU", which is where we thought it up. I mentioned to John Hoenig that it would be great to have an MMU on the ST. John said, "Real MMUs take too many gate delays" and challenged me to come up with a design that could be implemented in minimum gates, with just a gate delay or two in the data (well, address) path. A bunch of walks out to the Sunnyvale settling ponds and beyond, we had it. I think it's kind of neat, though Atari never shipped an OS that took advantage of it. I think the chips started coming back just about the time I'd decided to leave Atari and go to Apple. And Atari never had enough engineers to really follow through (sigh). 3 Quote Link to comment Share on other sites More sharing options...
+Sauron Posted July 15, 2017 Share Posted July 15, 2017 Always nice to see you come around these parts. Why did you decide to leave Atari, if you don't mind me asking? How would you describe the difference between the work environments at both companies? Quote Link to comment Share on other sites More sharing options...
calimero Posted July 16, 2017 Share Posted July 16, 2017 This is the MMU that I described in my blog. We called it the GMMU, for "Garbage Dump MMU", which is where we thought it up. I mentioned to John Hoenig that it would be great to have an MMU on the ST. John said, "Real MMUs take too many gate delays" and challenged me to come up with a design that could be implemented in minimum gates, with just a gate delay or two in the data (well, address) path. A bunch of walks out to the Sunnyvale settling ponds and beyond, we had it. I think it's kind of neat, though Atari never shipped an OS that took advantage of it. I think the chips started coming back just about the time I'd decided to leave Atari and go to Apple. And Atari never had enough engineers to really follow through (sigh). So you destroy Atari :D Just kidding. So you are author of this document that Curt Vendel post in first post? And Atari Corp. made this GMMU into a silicon (real chip)? I second Sauron question (if you have time to replay) and I wonder if this GMMU was part of planed Atari EST that Shiraz Shivji talks about in interview: http://st-news.com/issues/st-news-volume-2-issue-7/features/interview-with-shiraz-shivji Maybe you have idea what is answer to question: how Atari Corp. could put a groundbreaking computer like the ST together so quickly and affordably - in just a matter of months. But then upgrades to the ST/TT/Falcon line were slow coming, often rather expensive, and outdated by the time they released. --- For rest, Landon talks about this post regarding GMMU ("This is the MMU that I described in my blog"): http://www.dadhacker.com/blog/?p=1383 Quote Link to comment Share on other sites More sharing options...
exxosuk Posted July 16, 2017 Share Posted July 16, 2017 This is the MMU that I described in my blog. We called it the GMMU, for "Garbage Dump MMU", which is where we thought it up. I mentioned to John Hoenig that it would be great to have an MMU on the ST. John said, "Real MMUs take too many gate delays" and challenged me to come up with a design that could be implemented in minimum gates, with just a gate delay or two in the data (well, address) path. Did you work on the ST MMU ? Finding information about its internal works is near impossible. Quote Link to comment Share on other sites More sharing options...
leech Posted July 16, 2017 Share Posted July 16, 2017 Didn't MultiTOS eventually use the MMU? Quote Link to comment Share on other sites More sharing options...
landondyer Posted July 18, 2017 Share Posted July 18, 2017 Did you work on the ST MMU ? Finding information about its internal works is near impossible. John Hoenig and I collaborated on this. I wondered out loud at him one day if it were possible to do a cheap MMU, say, base-and-bounds, like mainframes of yore. He was dubious about an adder. "If you can do this in about one gate delay, we can probably implement it," and that was the challenge he gave me. Carry propagation time ruled out doing address translation with an adder, and trap generation with a bounds check, though, and you needed more than one address range to handle the stack the way that Unix wanted. Too many gates. So I thought about it for a while, realized the "all 1s or all 0s in the upper bits" hack while out on a walk, then John and I spent maybe an hour working out some details (it was his idea to map the ROMs in -- I didn't think that was necessary, but it was cheap to do). I think that he kind of snuck it in to the memory controller design; I'm not sure that Shiraz knew it was in there. I really like the design, and it would have been fun to port Unix to the box, but there was never enough time to do that. 2 Quote Link to comment Share on other sites More sharing options...
exxosuk Posted July 18, 2017 Share Posted July 18, 2017 John Hoenig and I collaborated on this. I wondered out loud at him one day if it were possible to do a cheap MMU, say, base-and-bounds, like mainframes of yore. He was dubious about an adder. "If you can do this in about one gate delay, we can probably implement it," and that was the challenge he gave me. Carry propagation time ruled out doing address translation with an adder, and trap generation with a bounds check, though, and you needed more than one address range to handle the stack the way that Unix wanted. Too many gates. So I thought about it for a while, realized the "all 1s or all 0s in the upper bits" hack while out on a walk, then John and I spent maybe an hour working out some details (it was his idea to map the ROMs in -- I didn't think that was necessary, but it was cheap to do). I think that he kind of snuck it in to the memory controller design; I'm not sure that Shiraz knew it was in there. I really like the design, and it would have been fun to port Unix to the box, but there was never enough time to do that. Some lines sound like what I read in your blog I really want to re-create the MMU in a new PLD. Though ditch the DRAM and use SRAM. While I understand basically (like everyone else probably) the "jist" of how it works, there is no real information out there on it. The internal design of the MMU is to unknown to replicate. The ASIC designs seem lost unless by some huge stroke of luck you have them still ? Quote Link to comment Share on other sites More sharing options...
Lynxpro Posted August 5, 2017 Share Posted August 5, 2017 (edited) Didn't Motorola have an MMU they liked to sell with the 68000 at the time? It might've cost too much which is probably why Atari Corp and Commodore didn't use it. I don't think Apple did either. Then again, if memory serves me correctly, the 68040 had an MMU built in. Wait...it had the 68882 FPU integrated. Maybe it had both... So...I wonder... If one installed the Motorola MMU into an ST and had a driver or patch, couldn't the ST go beyond 4MB RAM? Assuming software were written or modded to take advantage of it, of course... Edited August 5, 2017 by Lynxpro Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 5, 2017 Share Posted August 5, 2017 No. There was no MMU for the 68000, any MMUs that were a part of 68000 based machines were very custom jobs, especially to work around the fact that the 68000 couldn't re-establish context from a fault (something you _really_ need to do for both virtual memory and memory protection!), this was a feature that the 68010 added much to the collective sigh of relief from Sun and the other workstation manufacturers, and it was something that Zilog _REALLY_ tried to push as a plus for the Z8000... When the 68020 was released, Motorola finally released _two_ off the shelf MMU's for it: the 68451, which provided a segment table for memory management, and the 68851 for page based memory management (which just about everybody in the workstation space preferred). The 68851 was ultimately moved into the 68030, and the 68451 died a death of obscurity. -Thom 4 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 6, 2017 Share Posted August 6, 2017 As I remember, some of the work-arounds for the 68000 workstations to handle faults were downright bizarre... Apollo's first workstations had TWO 68000s that were synchronized in a one-behind configuration (both 68000s were pointed to the same place, except the slave 68000 was one instruction behind), which is...well...when you're selling workstations for $30,000 a pop, you can afford to do crazy shit like that. -Thom 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.