000
06.04.2011, 21:37 Uhr
jmueller
|
Hallo AC1-Gemeinde,
auf dem diesjährigen KC-Treffen wurde ja der Versuch angefangen,
dem bisherigen Wildwuchs Einhalt zu gebieten
und Standards für die Entwicklung von Hard- und Software
sowie sonstigen Erweiterungen festzulegen.
Es gibt da bisher eine Menge Ideen, aber ich finde,
der Weg zu dieser neuen AC1-Plattform wird noch nicht systematisch
und zielgerichtet gegangen.
Ich spreche hier bewusst von einer neuen AC1-Plattform,
da (zumindest angedachte) Dinge wie GIDE, USB und Netzwerk
deutlich über den klassischen AC1 hinausgehen.
Ich möchte hiermit einen Anfang initiieren,
um für das ganze einen angemessenen organisatorischen Rahmen zu finden.
Also erstmal muss ein Name her für diese neue Plattform,
z.B. "AC1 2.0" oder "AC1-2011" oder was auch immer,
damit man bei zukündtigen Anwendungsprogrammen auch mal sagen kann:
"Dieses Programm erfordert einen AC1 2.0" (oder was auch immer).
Die bisherige Wortwahl a la "das Programm erfordert Monitor V8" usw.
ist in mehrfacher Hinsicht ungeeignet:
Erstens werden diese bisherigen Monitorversionen nicht den neuen
(geplanten) Entwicklungen gerecht (z.B. FDC, GIDE, USB).
Und zweitens gibt es ja evtl. auch noch Hardware-Voraussetzungen,.
die damit nicht genannt werden.
Nach dem Namen muss eine Hardware-Spezifikation her.
Das schließt neben Portadressen für FDC, GIDE, USB, NET und Bankumschaltung
auch Festlegungen ein, wie denn zukünftig größere RAM-
und ROM-Bereiche eingeblendet werden sollen.
Also Gedanken in die Richtung wie z.B. "Über IO-Adresse XY" kann man an
Adresse XYZ eine von 16 16K großen ROM-Bereichen einblenden"
halte ich einfach für zu kurz gedacht.
Flexibler wäre da ein Konzept a la SCCH-ROM-Disk, aber vielleicht
über eine 16 Bit IO-Adresse, um nicht bei der nächsten Erweiterung
gleich schon wieder an Grenzen zu stoßen.
Man kann sich da auch von anderen Computern inspirieren lassen,
z.B. vom Modulkonzept des KC85 oder vom ROM-Switch beim CPC/KCcompact.
Sinnvoll ist wohl auch, eine Taktfrequenzumschaltung und vielleicht auch
eine Grafikumschaltung (z.B. 80x25, Vollgrafik) über eine
IO-Adresse zu spezifizieren, die auch rücklesbar ist
(z.B. ähnlich Z1013 Port 4).
Wichtig ist auch, die Einblendung von größeren RAM-Bereichen vorzusehen,
und zwar kompatibel zu CP/M 3.
Die Belegung der CTC-Ein/Ausgänge ist für mich auch noch offen.
Da kann man auch über System-Timer nachdenken,
in die sich evtl. auch eigene Routinen einklinken können.
Nachdem man sich auf ein zukunftsträchtiges Hardware-Konzept geeinigt hat,
ist die größte Frage die nach der Software-Schnittstelle (Sprungtabelle).
Alle Anwendungsprogramme sollten ausschließlich über Software-Schnittstellen
mit den Systemkomponenten reden!
Gerade dieser Punkt ist bei vielen DDR-Klein- und Sebstbaucomputern allgemein
und beim AC1 im speziellen doch eher stießmütterlich ausgeprägt.
Neben den jetzt schon vorhandenen Funktionen für Konsolen-Ein/Ausgaben
usw. sehe ich vorallem eine Schnittstelle zum Laden und Speichern
von Dateien anhand ihres Namens.
Da man ja nun mit verschiedenen Speichermedien arbeitet bzw. arbeiten will
(RAM-Disk, Diskette, Festplatte, USB-Stick,
zukünftig vielleicht auch mal Netzwerklaufwerk),
ist es ja irrsinning, wenn Anwendungsprogramme die Hardware direkt ansprechen.
Vielmehr muss der Zugriff über eine einheitliche Schnittstelle gehen,
bei dem das Anwendungsprogramm es überhaupt nicht interessiert,
welches physisches Speichermedium da drunter liegt.
Die CP/M-BIOS-Schnittstelle sollte man da wegen ihrer Sektororientiertheit
eher nicht als Vorbild nehmen.
Auch BDOS-FCBs halte ich in ihrer Form für überholt.
Als Konsequenz des ganzen müsste man dann z.B. im
Grafik/Sound-BASIC-Interpreter auch CSAVE/CLOAD duch SAVE/LOAD-Befehle
ersetzen, die dann auf diese Schnittstelle gehen.
Und in dem Zusammenhang spielt dann auch das zu definierende AC1-Dateiformat eine Rolle.
Wenn diese Softwareschnittstelle definiert ist,
kann man dann auch ein Monitorprogramm als Referenzimplementierung
schreiben bzw. anpassen.
Wenn man da dann schon sinnvollerweise die Anbindung von
FDC, GIDE und USB schon drin hat,
müssen wohl zwangsläufig einige andere Funktionen (z.B. Debugger-Kommandos)
herausfallen.
Nach dem ganzen, was eigentlich zu definieren ist,
muss auch der organisatorische Rahmen gefunden werden,
also 1. Einreichung von Vorschlägen, 2. Diskussionsplattform,
und 3. Entscheidungsfindung.
Bei letzerem wird wohl die Wahl eines "AC1-Rates" oder eines
letzten Entscheidungsträgers (so wie in der KC85-Gemeinde) notwendig sein.
Sicherlich, wir leben in einem freien Land und jeder kann in seinem
Hobby basteln, was er will.
Doch wer sich nicht an die so getroffenen Spezifikationen hält,
baut dann eben vielleicht nur einen AC1, abr keinen AC1 2.0.
So, und warum schreibe nun gerade ich diesen langen Beitrag,
der ja selbst gar keinen AC1 hat und auch keinen bauen will?
Es könnte mir ja egal sein, aber aufgrund meines Emulators
wurde in der Vergangenheit schon mehrfach versucht,
von verschiedenen Stellen verschiedene Konzepte in JKCEMU einbringen zu wollen.
Ich möchte schon, dass JKCEMU möglichst viel emulieren kann,
doch gerade bei dem AC1-Wildwuchs ist es wirklich nicht einfach,
das alles irgendwie unter einen Hut zu bekommen.
Und deshalb gibt es für mich auch gewisse "Aufnahmekriterien" für Dinge,
die in den Emulator hineinkommen.
Und das wesentlichste diese "Aufnahmekriterien" ist,
dass die zu emulierende Hardware irgendwo auch mal spezifiziert
und veröffentlicht wurde und sich möglichst nicht mit den
sonst üblichen Spezifikationen beißt.
Deshalb ist meine Wunsch an die AC1-Gemeinde:
Wenn ihr etwas im Emulator haben wollt,
dann spezifiziert es, legt es fest und veröffentlicht es.
Und dafür bedarf es eben auch einer gewissen Organisation,
womit sich der Kreis zum Anfang meines Beitrags schließt.
Ich befürchte, dass ohne Entscheidungsträger alle Vorschläge
in unendlichen Diskussionen nur zerredet werden.
Deshalb möchte ich mal konkret werden:
Ich schlage einen AC1-Rat (oder wenn es moderner klingen soll: "AC1-Board")
mit 3 Mitgliefern vor,
damit bei Abstimmungen immer eine eindeutige Meinung herauskommt.
Im Prinzip finde ich ein einzelnes Oberhaupt zwar besser,
aber ich befürchte, das wird sich kaum im Konsens finden lassen.
Deshalb mein Vorschlag, wer in diesen "AC1-Rat" mitwirken möchte,
soll das hier im Thread kundtun und somit "kandidieren".
Keine Angst, ich bewerbe mich nicht.
Jedes Formsmitglied hat eine Stimme und kann durch einen entsprechenden
kurzen Beitrag seine Stimme einem "Kandidaten" geben.
Und dann haben wir hoffentlich erstmal drei, die den Hut aufhaben
und sich um die weitere Organisation kümmern.
So, ich bin nun sehr konkret geworden.
Andere Vorschläge sind natürlich auch willkommen.
Also dann mal los!
Jens |
.. Kaum ist Jens im Urlaub und schon ist Funkstille. Ich finde das schade.
sondern überall ein bissl kreativ mit