Atari EST Prototype

[Curt Vendel]

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.

[opcode]

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

[zzip]

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.

[Tillek]

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!

[calimero]

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

[calimero]

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.

[landondyer]

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

[+Sauron]

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?

[calimero]

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

[exxosuk]

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.

[leech]

Didn't MultiTOS eventually use the MMU?

[landondyer]

 

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.

[exxosuk]

 

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 ?

[Lynxpro]

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

[tschak909]

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

[tschak909]

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