Jump to content

Photo

Atari EST Prototype


15 replies to this topic

#1 Curt Vendel OFFLINE  

Curt Vendel

    River Patroller

  • 4,497 posts
  • Location:Carmel, New York

Posted Fri Feb 8, 2008 4:41 PM

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.

#2 opcode OFFLINE  

opcode

    River Patroller

  • 4,116 posts
  • Bringing new life to your ColecoVision!
  • Location:MA, USA

Posted Thu Apr 27, 2017 4:44 PM

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...



#3 zzip OFFLINE  

zzip

    Stargunner

  • 1,326 posts

Posted Fri Apr 28, 2017 8:01 AM

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.

#4 Tillek OFFLINE  

Tillek

    Dragonstomper

  • 609 posts
  • Location:NE Ohio, USA

Posted Fri Apr 28, 2017 6:21 PM

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!



#5 calimero OFFLINE  

calimero

    Chopper Commander

  • 150 posts

Posted Sat Jun 10, 2017 2:30 AM

Here you will find more on history of TT (and EST): http://www.atari-for...tart=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...technology.html

Rou Good come to Atari in Jan. 1987

Shiraz Shivji left Atari in Feb 1989. - Roy takeover development



#6 calimero OFFLINE  

calimero

    Chopper Commander

  • 150 posts

Posted Tue Jul 11, 2017 2:18 AM

sorry for bad link in previous post:

http://st-news.com/i...-shiraz-shivji/

 

and I misspelled Roy J. Good name.



#7 landondyer OFFLINE  

landondyer

    Star Raider

  • 50 posts
  • Location:Seattle Area

Posted Fri Jul 14, 2017 11:40 PM

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).



#8 Sauron OFFLINE  

Sauron

    Quadrunner

  • 5,223 posts
  • In the land of Mordor.
  • Location:North of the Black Sea

Posted Sat Jul 15, 2017 9:03 AM

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?



#9 calimero OFFLINE  

calimero

    Chopper Commander

  • 150 posts

Posted Sun Jul 16, 2017 2:40 AM

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 :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/i...h-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 



#10 exxosuk OFFLINE  

exxosuk

    Dragonstomper

  • 550 posts
  • Location:UK

Posted Sun Jul 16, 2017 5:56 AM

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. 



#11 leech ONLINE  

leech

    Dragonstomper

  • 674 posts

Posted Sun Jul 16, 2017 12:34 PM

Didn't MultiTOS eventually use the MMU? 



#12 landondyer OFFLINE  

landondyer

    Star Raider

  • 50 posts
  • Location:Seattle Area

Posted Mon Jul 17, 2017 11:02 PM

 

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.



#13 exxosuk OFFLINE  

exxosuk

    Dragonstomper

  • 550 posts
  • Location:UK

Posted Tue Jul 18, 2017 8:27 AM

 

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 ?  



#14 Lynxpro OFFLINE  

Lynxpro

    River Patroller

  • 3,300 posts
  • Location:Sacramento, CA

Posted Sat Aug 5, 2017 3:16 PM

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 by Lynxpro, Sat Aug 5, 2017 3:17 PM.


#15 tschak909 OFFLINE  

tschak909

    Stargunner

  • 1,831 posts
  • Location:USA

Posted Sat Aug 5, 2017 3:33 PM

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



#16 tschak909 OFFLINE  

tschak909

    Stargunner

  • 1,831 posts
  • Location:USA

Posted Sat Aug 5, 2017 11:33 PM

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


  • jhd likes this




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users