Tak powinna właśnie wyglądać Amiga jakieś 10 lat temu.
Commodore miało na ten temat inne zdanie, zdaniem Commodore Amiga powinna być jak pecet tylko z innym niż pecet procesorem.
A sprzęt który ani nie ma szansy zagrozić pozycji PCtów, ani nie posiada faktycznej, wstecznej kompatybilności z klasycznymi Amigami, trudno nazywać Amigą, bo właśnie to jest wmawianiem sobie, że czarne jest białe.
Nowe Amigi są zgodne na poziomie systemu z poprzednimi Amigami.
Firma Commodore stwierdziła w 1993 roku że następne Amigi nie bedą
zgodne na poziomie rejestrów.
Materiały z konferencji dla deweloperów DevCon 93 - January 1993.
Strona Dave Haynie:
http://www.thule.no/haynie/research/nyx/docs/AAA.pdf
Zeskanowane
http://www.acc.umu.se/~patrikax/amiga/others/schematics/
Chapter Goals of the AAA Project
Section 2.1 Compatibility
Page 199
AAA is designed to be largely register compatible with the ECS chip set. Most of the
RGA registers from ECS are supported. The ECS “Ultra hires” registers have been eliminated, as
they were never supported in actual practice. Some other display-generation details of ECS are
no longer required or supported in AAA.
The AA registers are not supported in AAA. We believe that the 3.0 OS provides the
necessary control over AA and that no one need program “to the metal” on AA systems.
Additionally, some of the AA features were implemented in a less-than-ideal fashion, in order to
fit in the same RGA address space originally implemented in ECS. All AA-equivalent function
can be done much better by new AAA support than some kind of AA emulation. Some behaviors
can’t be perfectly emulated in AAA. Clearly, the AAA chip set’s architecture will have an
immediate impact on some elements of the ECS emulation apart from register-level compatibility.
For example, on a VRAM system, there’s no way to slow the system down to an equivalent cyclestealing
ECS mode. So a program will often find significantly more blitter, copper, and CPU
access than on an ECS machine. This won’t be a problem if you’re using the OS correctly, but it
could be a problem to take-over-the-system type programs. Such programs may also have some
degree of problem with some AAA screen promotions and copper activity.
We envision AAA as a transitional system. It is highly desirable to eliminate the ECScompatibility,
or for that matter, reliance on any register-level compatibility, for the next
generation of Amiga chips. So there’s an excellent chance that you’re seeing some of this stuff
for the last time in AAA.
Chapter V39 and AA Compatibility
Section Ensuring Compatibility
Page 3
Furthermore, these manipulations should be handled by the system software whenever possible:
Drawing operations - use the graphics library and Intuition library
Blitter operations - if possible, use only use higher level blitter functions from graphics.library such as BltBitMap(), BltRastPort(), etc. If you must wait for a blit to complete, always use the system's WaitBlit() function, never your own. The system knows about and handles problems with the BLITTER_DONE signal that different revisions of the Agnus chip have. If you feel that must use the blitter hardware directly (sacrificing all hope for any RTG compatibility), be sure to properly OwnBlitter, then WaitBlit, then use blitter, then DisownBlitter.
Page 215.
Chapter 4 Future System Concerns
The AAA chips obviously function as just part of a whole Amiga system. It's certainly possible to build a machine, like the Amiga 500, where the Amiga chips essentially are the whole system. Such a system would be composed of the AAA chips, a microprocessor, memory, some CIAs, analog stuff for audio, and one gate array for “glue”. Of course, such a system is rather boring to talk about It's also somewhat unlikely that early AAA systems will be of this flavor.
Taking the high-end route, there's considerably more to an Amiga system than the custom chips. It would, however, be a mistake to base things directly on past high-end systems like the A3000/A4000. The system architecture of those systems, while fine for the time, is lacking in a number of important areas. The most obvious factor is that the A3000 architecture isn't very modular or flexible. It was designed to support our ideas for the A3000, nothing more. Even in the A4000, extra logic was necessary to push this A3000 architecture is a slightly different direction. On the AAA prototype motherboard, there is extensive high-speed PAL logic necessary to implement a servicable but unsophisticated AAA system.
The primary goal of an advanced Amiga system can be summed up in one word: modularity. Such a new system, both logically and physically, is composed of several interchangable subsystems. No one piece has any unnatural dependence on any other; interconnections between the system components have to be based on intentional system standards, not chance implementation details.
4.1 The System Bus
The next generation system should have a processor-independent system bus optimised for chip to chip interconnect. For the most part this replaces the traditional CPU-specific local bus found on previous Amiga systems. This establishes a standard to which several generations of new system and, eventually, Amiga chips can be designed. Since each major system chip hooks into the system bus independently of any other, this finally breaks the interdependence of chips in a chip set, allowing upgrades as necessary to any piece of the system.
4.2 The Motherboard
The motherboard for such a system contains just the basics that will be needed by every system. This will certainly include a number of basic I/O chips for the standard ports on that machine. The CPU, Amiga chips, and various other elements of the system are located on separate modules. These don't necessarily have to be physically located on different cards, but ideally they will be. Not only does this make motherboard upgrade much easier, but it allows several different motherboards to be designed using the same plug-in modules, and it allows Commodore to easily support more options in system and processor makeup.