NAME: Meine Vision von einem Amiga Next Generation
AUTOR: Martin Steigerwald
Email: stud@uni-frankfurt.de
FIDO: 2:244/1529.4 (noch)
VERSION: 0.8 9.10.95
0.85 15.10.95 Vorschläge von Stefan Rosewig integriert
ARexx als Systemsprache
0.90 16.11.95 Vorschläge von Tibor Pausz, Sacha Danesi,
Karl Lockhoff, Christian Tauscher, Theodor
Isporidi integriert
Teil "Software - Lieferumfang" angefangen
Teil "Kontaktadressen" angefangen
Teil "Danksagung" angefangen
DATUM: 16.11.95
MEINE VISION VON EINEM AMIGA NEXT GENERATION
============================================
Dies hier ist meine Vision, wie ein Amiga der Zukunft aussehen koennte,
dies hier sind meine _Maximalforderungen_. Ich sage später noch, wo ich zu
Kompromissen bereit wäre.
ALLGEMEINE ANMERKUNGEN
======================
In diesen Text sind viele Ideen von vor allem FIDO-Usern eingegangen! Es
ist längst nicht mehr nur meine Vision. Es ist die Vision vieler
Amigauser.
Nicht immer habe ich die Vorschläge anderer namentlich gekennzeichnet.
Dieser Text ist Public Domain, öffentliches Eigentum.
HARDWARE
========
- Prozessorkarte
- RISC: PowerPC, HP-PA-Risc, DEC Alpha, ARM, oder die neue
Koproduktion von DEC und Arm
- Boot-, Kickstart-ROM als Flash-ROM, damit einfaches Updaten möglich wird
- RAM
- schnelles DMA-fähiges RAM, leicht aufrüstbar
- konfigurierbares DMA
Ein DMA-RAM-Bereich für die Grafikkarte und jeweils für jede andere
Highspeedkarte, damit nicht das ganze RAM durch sie ausgebremst
wird.
- DSP- und/oder Blitter zur Beschleunigung von Audio und Gfx
- schneller DSP und Blittersystem mit Zugriff auf das gesamte RAM
(nicht nur, wie bisher der Blitter, der nur Zugriff auf das Chip-
RAM hatte, Chip-RAM macht imho nur Sinn für Highspeedchips mit
notwendigerweise ständigem Zugriff. Denise, Grakas. Und Blitter und
DSPs kann man auch für andere Dinge als Grafik und Sound verwenden)
- IO
- Keyboard-, Maus-, Joystickanschluesse
- serieller, paralleler Port
- SCSI-Controller
- Diskettenlaufwerkscontroller
Obwohl hier ein Ersatz mit höherer Kapazität wünschenswert ist.
Zudem wäre es gut, daß Diskettenlaufwerk, wenn man eins braucht,
gleich an den SCSI-Controller zu hängen
- Ethernetanschluß (Tibor Pausz)
- Grafik, evtl. als Customchips auf dem Motherboard realisiert oder
als Grafikkarte
- Copperfähigkeiten
- Hardware-Sprites - hardware scroll
- hardwaremäßiges Bildschirmziehen, hardwaremäßige Screens
Meinung dazu: Nicht mehr erforderlich. (Karl Lockhoff)
Ich fänds aber stark. Der Copper ist IMHO ein wichtiger und ziem-
lich einzigartiger Bestandteil der bisherigen Amigas.
- eigenes RAM oder DMA-Zugriff auf einen RAM-Bereich des sonstigen
RAMs, je nachdem, was besser zu realisieren ist.
mir gefällt die Idee mit den DMA-Bereichen besser
Kommentar dazu:
Ich wuerde (falls technisch irgendwie machbar) den gesamten Bereich
des RAMs nach Moeglichkeit fuer die Graka erreichbar machen. Das
gaebe natuerlich enorme Aufloesungs- und Farbtiefenmoeglichkeit.
Nicht nur das, die Karte koennte sich auch fuer Spezialfunktionen
(z.B. Z-Buffer) zusaetzlichen Speicher reservieren. Das
Betriebssystem muss halt im Auge behalten welchen Speicher es der
Graka zugewiesen hat und dann halt auf diese Bereiche den Zugriff
auf dieses RAM mit der CPU abstimmen. Natuerlich (ist sogar um
etliches sinnvoller) kann das auch ein eigener Baustein tun, dem
halt vom BS die Adressen uebergeben werden. (Theodor Isporidi)
- kein eigener Blitter, sondern Zugriff der DSP-, Blitterkarte
auf das Grafik-RAM
- genlock-, videofähig, weil das eine der größten Stärken des Amiga
ist
- Sound, evtl. als Customchips oder als Soundkarte
- Stereosound in CD-Qualitaet, 16 Bit, 8 Kanaele, mindestens 50 KHz
Samplingrate
oder 18 Bit, die 2 Bits mehr lehnen an professionelle Studioeffekt-
geräte an, 16 Bit ergeben nach einigen math. Operationen Rundungs-
fehler (Sacha Danesi)
16 Kanäle (Karl Lockhoff)
- integrierter Digitizer (Stefan Rosewig)
Dabei stellt sich für jedes Subsystem die Frage, inwieweit es als
Steckkarte realisiert werden sollte. Verschiedene Meinungen dazu.
Soweit sinnvoll:
Die Modularität sollte von der Hardwareseite so weit gehen, daß es
möglich ist, den Amiga zu einem Mehrplatzkomputer auszubauen, durch
Hinzufügen von einer weiteren Grafikkarte und einer weiteren IO-Karte
und evtl. noch einer weiteren Soundkarte.
^^^^^ Warum nur eine? Wie waere es mit beliebig vielen (je nach
Steckplatzangebot)? Dann koennte man eine schoene grosse Videowand
aufbauen. (Christian Tauscher)
Problem: Die maximale Übertragungslänge für die Monitorsignale beträgt
nur ein paar Meter. (Stefan Rosewig)
Andere Meinung dazu:
Absolut aus der Mode gekommen. Mittlerweile gibts billige
Arbeitsplatzrechner die an einem Server hängen und sonst nichts mehr.
(Tibor Pausz)
Oder:
Mehrplatzfähigkeit hängt mehr von der Software, als von der Hardware ab.
Sinnvoller ist für eine weitere Arbeitsstation ein abgespecktes System mit
ähnlicher Hardware. (Karl Lockhoff)
Oder:
Voooorsicht ! Da kann man leicht ins offene Messer rennen !
Ich bin zwar auch fuer eine offenere Architektur als sie momentan zu haben
ist, allerdings je modularer man die Sache aufbaut, desto hoeher die
Wahrscheinlichkeiten das wir dann zu Zustaenden kommen wie am PC, wo eine
Karte troubles mit ner anderen macht !
All zu sehr bin ich mit Hardware nicht vertraut, deshalb ueberlasse ich
die Details in den Implementierungen lieber den Fachleuten... (Theodor
Isporidi)
- Bussystem: PCI für Highspeed-, Zorro-II für Lowspeedkarten oder
funktional gleich- oder höherwertige Systeme
Zorro-III vielleicht am Anfang noch wegen der Kompatibilität
Kommentar: PCI momentan noch zu teuer (Karl Lockhoff)
ZorroII auf dauer und ZIII nur am Anfang wegen der Kom. Waere es nicht
anders herum sinvoller, da ZIII auch ZII frisst? (Christian Tauscher)
Z-III ist aufwendiger und kostspieliger. Sollte es durch PCI voellig
ersetzt werden koennen mit besserer Funktionalitaet, sehe ich nicht,
wozu es noch noetig waere, ausser fuer alte Karten in einer
Uebergangsperiode.
Evtl: Ein Masterbussystem, daß über Adapterplatinen andere Bussysteme
aufnehmen kann, soweit sich dies als praktibel herausstellt. Somit wäre
man zu eventuellen zukünftigen Bussystemen eventuell kompatibel
Aber nur, wenn das mit sinnvoller Performance möglich ist. Und die
Möglichkeiten für ein solches Masterbussystem sind auch begrenzt, weil
man die Entwicklung nicht allzuweit voraussehen kann.
- volles Autoconfig siehe OpenBoot
Gehäuse:
- Wahlfrei Mini-, Midi-, Big-Tower oder Desktop, evtl.
Buserweiterungsplatinen für die Tower.
- hübsches eigenständiges Design, also bitte keinen PC oder Mac-
Look mehr (Karl Lockhoff)
Mindestkonfiguration:
- RISC-CPU mit 80MHz, z.B 601/80 mit 256KB L2-Cache (Tibor Pausz)
- 16 MB RAM als DIMMs (Tibor Pausz)
- IO-Karte(n) mit 2x ser min. 115200baud, 2x par bidirektional, 1x
Ethernet, 1x SCSI, 2x Maus/Joystick,1x Keyboard
- 24 Bit Grafik, 800x600 in 24 Bit mit 70-80 Hz, ansonsten min.
1280 x 1024, 2MB VRAM aufrüstbar
- Sound mit 8 Kanälen, 16 Bit, 50 KHz Samplingrate
- DSP- und/oder Blitter
(koennte bei kleinen System evtl. auch aufs CPU-Board integriert
werden.)
- 540MB oder 1 GB Festplatte
- CD-ROM (Tibor Pausz)
- Diskettenlaufwerk 1.44MB (Tibor Pausz)
Preis: Anfangs unter 4000DM, dann sehr schnell unter 3000DM
Andere Vorstellung: Anfangs unter 3000DM, dann sehr schnell unter 2000DM
(Karl Lockhoff)
siehe PowerMac 7500, Motorolas Preps, IBM Preps, oder allgemein:
HRP-Rechner (Tibor Pausz)
BeBox
Optionale Zusaetze: - Gfx-Digitizer
- Wechselmedienlaufwerk
ZIP, Syquest, MO, je nachdem was sich etabliert,
was sinnvoll ist
- Modem(karte), ISDN-Modem(karte)
SOFTWARE
========
- RISC AmigaOS
- mit Ressourcetracking
- mit Speicherschutz \ Beides aber abschaltbar, sofern das Ab-
- mit virtuellem Speicher / schalten selbst Performancegewinn bringt
- mit Netzwerkfähigkeiten (Internet-Zugang)
TCP/IP mit Telnet, FTP, Gopher, SMTP, NNTP, POPMAIL, WWW
- mit Multi User Fähigkeiten
- mindestens auf FileSystem-Basis
- besser jedoch komplett in Hinblick auf Vernetzung (Internet) und
Mehrplatzkomputersystem
Wäre gut, könnte aber auch erst später kommen. Hat nicht die höchste
Priorität (Theodor Isporidi)
- RTG: Retargetable Graphics siehe Cybergraphics, EGS
- RTS: Retargetable Sound siehe Cybersound, Delitracker
- RTIO: Retargetable IO, betrifft vor allem serielle und parallele Ports
siehe Software von diversen IO-Karten
siehe oder: OpenBoot, Hardware Abstraction Layer (HAL)
- ebenfalls völlig modular
- objektorientiert
- Ausbau des Datatypes Konzeptes:
- Viewtypes, Edittypes, Showtypes, Printtypes, Loadtypes,
Savetypes, Operatortypes (Datenverarbeitung, z.B.: Bild-
bearbeitungsfunktionen), Configurators
- Ausbau des Gadget-Konzeptes:
- Konfiguratorgadgets, die von den System-Voreinstellern
und von Applikationen aufgerufen werden können.
(configurators)
- Ausbau des Classes-Konzeptes
- Verschachtelung von Datatypes
- IFF Files mit mehreren Datentypen
- Guide Files mit Inline-Grafiken, -Animationen, -Sounds
oder HTML als Standardformat für Dokumentationen (Theodor
Isporidi) möglicherweise mit der Option mehrere HTML-Dateien,
in ein großes IFF-File zu packen, damit nicht jede Programm-
dokumentation aus 100 und mehr Files besteht.
Evtl. den HTML-Standard um amigatypische Features erweitern
(Theodor Isporidi)
Das sollte zur
- Modularisierung von Applikationen in folgende Teile:
- Initialisierung (initializers, Startupcode)
- Konfigurierung (configurators)
- Eingabe
- GUI (gadgets)
- Laderoutinen (Loadtypes)
- Datenverarbeitung
- Operators
- Ausgabe
- Bildschirm/GUI (Viewtypes)
- Drucker (Printtypes)
- Speicherroutinen (Savetypes)
führen.
Vorteil bei konsequenter Durchführung anhand von Beispielen:
Ein Textverarbeitungsprogramm kann ein Malprogramm als Bildobjekt
in einen Text einbinden! Der Text ist direkt aus dem Fenster, das
den Text anzeigt, editierbar.
Eine Tabellenkalkulation kann ein Textprogramm einbinden, der Text
wird in einer Zelle dargestellt, und ist voll editierbar. Dieser
Text könnte ein Bild enthalten, daß über ein Malprogramm wiederum
voll editierbar wäre, das alles vom Fenster der Tabellenkalkulation
aus.
Ein Textprogramm kann die Druckereinstellungen als Gadget einbinden,
und somit ohne wesentlichen Mehraufwand lokale Druckereinstellungen
bieten. Die Workbench kann ein Malprogramm als Iconeditor nehmen.
Ein Textprogramm kann zur Anpassung eines Bildes Bildverarbeitungs-
routinesn von ADPro z.B. direkt verwenden. (operators)
Ein Shellbefehl könnte einen configurator bekommen, mit dem man
die Defaultoptionen einstellen kann.
Usw. usf.
Kommentar dazu: Ich glaube nicht, daß die Softwareindustrie hier
mitspielt (Karl Lockhoff)
In der Tat ein Problem, doch die Vorteile liegen auf der Hand.
siehe PPaint, Wordworth, PPaint, ADPro, SuperView und andere haben
solche Ansätze zur Modularisierung schon (Loaders, Savers,
Operators), sie nutzen jedoch alle andere Implementationen, hier
sollte das OS einen standardisierten Ansatz bieten, der noch
weiter geht.
siehe Hotlinks (Theodor Isporidi)
- IFF EXEC-Format für neue Programme, nimmt alles auf, was nur für
das spezifische Programm gebraucht wird
- Binaries für mehrere CPUs (siehe Portabilität)
- Editor für diesen Format, Module, Binaries rausnehmen,
einfügen
Z.B. ein speziell neu kompiliertes Modul einfügen. Ein Programm
updaten, in dem nur die entsprechenden Module getauscht werden.
- Trennung von residentfähigem, zu nicht residentfähigen Code/Daten
Bei Mehrfachstarts wird nur der nicht residentfähige Teil nochmal
geladen
- Startupcode, der erstmal geladen und gestartet wird, dieser liest
Aufruf-Parameter ein und entscheidet danach, was zu tun ist.
Vorteil: Ein Programm muss nicht komplett geladen werden, wenn
die Aufrufparameter falsch sind. Ein Textprogramm kann nach-
schauen, ob der zu editierende Text schon vorhanden ist, und wo-
anders editiert wird, und den Benutzer darauf hinweisen, ohne
daß es komplett geladen wird.
- externe Module, Libraries, Datatypes, Devices für alles, was
programm-, applikationsübergreifend ist
- Vereinheitlichung aller verschiedenen Modultypen
- ARexx zur Prozeßkommunikation verbessern und mit GUI sowohl für
die Programmentwicklung als auch für die ARexx-Skripts selber aus-
statten
- ARexx als Systemsprache implementieren in der Art, daß jede Aktion
vom Benutzer in ARexx abgebildet werden kann.
- Es können Logfiles erzeugt werden, die dann wieder abgespielt
werden können. Simuliert oder echt. Damit könnte man ne ganze
Menge zusätzlich automatisieren.
- Nach dem Internetlogin öffnen sich alle gewünschten Programme,
das FTP Program startet, loggt ins AmiNet ein, sucht automatisch
nach gewissen Programmen und transferiert diese, gleichzeitig
startet IRC und loggt in #amigager und #amiga ein.
- Wichtig dabei ist, daß es eine Möglichkeit des
ARexx-Makro-Recordings gibt, damit auch unerfahrene User die
Möglichkeiten von ARexx wenigstens zum Teil nutzen können.
siehe AppleScript, Rexx
- besserer Softwareinstaller
- flexibler
Kommentar:
Also, den finde ich gar nicht so schlecht, aber manche Installskripts
sind echt einfach nur ... schlecht! ... Etwas mehr Geschick bei den
Installskripts seitens der Applicationsprogrammierer ist da viel
wichtiger ! (Theodor Isporidi)
- GUI
- endlich volle font- und fenstergroessensensitivität für _alle_
neuen Programme und alle Systemprogramme
- objektorientiert
- voll konfigurierbar
- für jedes Program einzeln
- mit Voreinstellerprogramm (configurator)
- asynchron, wo sinnvoll
siehe MUI, BGUI, TritonGUI
- Voreinstellungen
- globale, global-benutzerspezifische, lokale
(applikationsspezifische), lokal-benutzerspezifische
- Abruf der Einstellungen in dieser Reihenfolge, sofern definiert.
D.h. wenn nur gloable Einstellungen definiert sind, dann werden
diese verwendet.
- global-benutzersüpezifische, lokale und lokal-benutzer-
spezifische nur da wo sinnvoll
- Vereinheitlichung durch configurators
- weiterhin die Optionen Benutzen und Speichern
- zwei unterschiedliche Verzeichnisse, die auch beide auf der Fest-
platte liegen können
siehe HDEnv
Kommentar: Man kann sich zu Tode konfigurieren. (Karl Lockhoff)
Hmm, ja man kann, aber man muß nicht, auch nicht mit diesem
Konfigurationssystem. Der Anwender bestimmt und _kann_, wo er es
braucht, alles ganz genau einstellen. Ansonsten werden die Vor-
gaben der jeweilig höhreren Ebene verwendet.
- bessere Workbench
- multi-threaded, asynchrones Design
- pro Fenster mehrere Tasks, je nach Bedarf für:
- Lesen neuer Information
- Darstellungen von Informationen
- Benutzereingaben auswerten
- je ein Task für jede vom Benutzer gestartete längere
Kopier-, Verschiebe-Aktion
- besseres Iconformat als Datatype implementieren
- bessere Textdarstellung
- Buttonbanks, Toolmanagerfertigkeiten
- voll konfigurierbaere Menues
siehe DOpus 5.11, Toolmanager
- Filesystem
- multiuserfähig
- stabiler
- ohne Notwendigkeit zum Validieren
- schneller
- sparsamere Nutzung des Platzes für Verwaltungsinformationen
- Defragmentierer siehe ReOrg
- evtl. einen Defragmentierer, der im Hintergrund arbeiten kann
(so etwas wird gerade für AFS entwickelt)
- Diskettenretter siehe DiskSalv
- optional PC-kompatibel für Wechselmedien entweder durch ein 2.
Filesystem (siehe CrossDOS) oder eine bessere Konfigurierbarkeit
des FileSystems.
siehe AFS
- Emulation des alten Systems in einer Virtual Machine bzw. über
Emulationslibraries, gemeinsamer Speicherbereich für alte Software
oder je altem Programm eine Virtual Machine, einstellbar
- UNIX mit X-Windows
- Lieferumfang
- Software auf CD liefern. Vorteile:
- schnelle Installation
- viel Platz für FD-Ware und Softwarebundles
- man hat immer ne Sicherheitskopie von der Soft :-)
- Zu jedem wichtigen Anwendungsbereich ein Programm entweder aus dem
kommerziellen oder dem FD-Ware-Bereich
siehe Amiga Magic Softwarepack :-)))
- verschiedene Alternativen, z.B.:
Textprogramm siehe Wordworth, Final Writer
Grafikprogramm siehe PPaint, Photogenics
Datenverwaltung siehe Datastore, Twist, Final Data
Tabellenkalkulation siehe TurboCalc (oehm, mehr faellt mir nicht ein)
Spiele siehe Auswahl aus einigen guten aktuellen Spielen
- Internet Software
- mit Oberfläche für den Einsteiger und leichterer Konfigurierbar-
keit (Einbettung in das configurator-Konzept)
Wer noch Ideen dazu hat, bitte melden!
- FD-Programme
- alle bisher programmierten Datatypes
- einen guten Editor siehe GoldED, ProgED
- ein gutes Terminalprogramm siehe Term (was denn auch sonst?:-)
- ganz allgemein: Einfach ne Portion FD-Soft draufpacken, damit der
User auch gleich auf die an sich sehr gute FD-Szene rund um den
Amiga aufmerksam wird.
Wenn ein FD-Ware (PD, Freeware, Shareware) geschrieben hat oder kennt,
daß er hier sehen will, melde sich bitte. Eine CD-Rom ist groß.
Und wenn dann Soft auf der CD ist, die von Usern vorgeschlagen wurde,
dann ist auch Soft drauf, die User interessiert :-)
KONTAKTADRESSEN
===============
User, die Vorschläge machten:
Hier trage ich erstmal keine Adressen ein. Wer eingetragen werden will und
Vorschläge gemacht hat, melde sich bitte und gebe mir die Erlaubnis seine
Netzadresse hier reinzunehmen.
Coder, Programmierer:
Wird noch erstellt. Wer selbst Programmierer ist und glaubt auch von
Betriebssystemen Ahnung zu haben, bzw. Software entwickelt hat, die sich
auch gut fürs Betriebssystem eignen würde, und auch Lust hat, bei Bedarf
was zur Entwicklung des OS beizutragen, melde sich bitte bei mir.
Hardware-Freaks:
Analog wie oben. Bitte melden!
DANKSAGUNG
==========
Allen Leuten, die so fleißig Ideen und Anmerkungen produzier(t)en, daß ich
mit der Erweiterung des Textes kaum noch nachkomme. :-)
Siehe Versionsgeschichte :-) (jaja, ich mach das nochmal fertig,
irgendwann)
Dietmar Eillert, für seinen hervorragenden GoldED, und vor allem dessen
Formatier- und Zentrierfunktionen :-))
Amiga - dem besten Komputer aller Zeiten :-)
Amiga Technologies GmbH und all die anderen Firmen, die sich für den
Amiga engagieren. Man merkt wieder, es bewegt sich was, seit langem.
to be continued and enhanced. :-)))
|
Diese Webseiten entstanden komplett auf einem Amiga-Komputer!
Überarbeitet und teilweise an XHTML angepasst unter Debian Linux. |
|
Hinweis: Dies ist meine alte Webseite. Ich pflege Inhalte meiner alten Webseite nicht mehr. Zur neuen Webseite.
Note: This is my old homepage. I do not update its contents anymore. Visit my new webpage.
| |