Hallo Besucher, der Thread wurde 233k mal aufgerufen und enthält 841 Antworten

letzter Beitrag von Tastenchef am

ACA-500 plus

    Du kannst Dich auf icomp.de registrieren, dann kannst Du als eingeloggter User ein Häkchen bei jedem Produkt setzen, das Dich interessiert. Da werden Informationen über Verfügbarkeit und/oder Nachfolgeprodukte direkt per eMail verschickt. Eine Warteliste in dem Sinne ist das zwar nicht, aber die Stückzahl wird definitiv nicht so begrenzt sein, dass es eine Knappheit geben sollte. Natürlich haben wir Grenzen in Sachen "Pakete pro Tag" und "getestete/verpackte Einheiten pro Woche", aber das bedeutet dann nur ein paar Tage Verzögerung.


    Die ACA500 war ein hammermäßiger Erfolg, und daran möchte ich natürlich anknüpfen. Dazu gehört natürlich auch, dass die produzierte Stückzahl diesmal höher ausgelegt wird.


    Jens

    Zitat von GordonCTS

    Alle Modelle oder wieder nur bestimmte?

    Alle Modelle werde ich nie unterstützen können, weil einige sich auf 32-Bit Zugriff auf das Chipram verlassen, und wieder Andere erst starten, wenn sie vom 68ec020 des A1200-Mainboardes initialisiert wurden.


    Ob meine eigenen syncron getakteten Karten jetzt funktionieren, habe ich noch nicht ausprobiert - Chancen gibt es, aber ich werde es nicht garantieren.


    Wir hantieren noch ein wenig mit den Blizzard-Karten herum; die B1230IV war ja schon kompatibel, und soll es wieder werden. Ebenso die BPPC, weil die Installation von OS4 auf dem A500 klappen soll (ist Teil meines Lizenz-Deals mit Hyperion). Ich muss noch ein wenig in der Memory Map "umbauen", damit sowohl die Blizzard-Karten, als auch der lokale Expansionsport funktionieren. Leider lassen die Blizzard-Karten keinen Zugriff auf $00f0.0000 und Folgende zu, wo ich eigentlich Flash einblenden wollte. Das müssen wir dann irgendwie mit einem Autoconfig-ROM lösen, was aber wieder Platz in der Logik kostet, den ich eigentlich nicht habe. Also.. "way to go" ;-)


    Jens

    Zitat von Wiesel

    Ob meine eigenen syncron getakteten Karten jetzt funktionieren, habe ich noch nicht ausprobiert - Chancen gibt es, aber ich werde es nicht garantieren.

    Eine Garantie der eigenen Karten hätte aber eventuell einen zusätzlichen Kaufanreiz auf die Turbokarte.

    Zitat von Snatchbit

    Eine Garantie der eigenen Karten hätte aber eventuell einen zusätzlichen Kaufanreiz auf die Turbokarte.

    Die asyncron getakteten Karten sind kein Problem - also alles ab ACA1220 und ACA1232. Einschränkungen gibt es bei der ACA1231 - die ist zwar asyncron, aber aufgrund des Vesalia-Exklusiv-Deals nicht in meiner Support-Verantwortung. Und weitere Einschränkungen gibt es aus technischen Gründen bei der ACA1230 (alle drei Versionen), welche syncron getaktet sind, und deswegen nicht sauber an der ACA500 funktioniert haben.


    Mit dem letzten Softwareupdate der ACA500 haben wir ein Softwareproblem mit den alten Karten (also ACA1230 und ACA1231) gelöst, und es haben auch ein paar Kunden berichtet, dass die Karten jetzt bei ihnen funktionieren. Das ist schön, und das wollte ich auch mit dem Softwareupdate erreichen. Es gibt aber die kleine aber feine Unterscheidung, dass ich nicht *garantiere*, dass diese alten Karten an der ACA500plus funktionieren werden, weil sie aufgrund ihrer Bauart streng auf das Timing des A1200 ausgelegt sind, das ich nicht bis ins Letzte auf der ACA500plus nachbilden kann.


    Ich halte das alles für akademisch, denn weder ACA1230, noch ACA1231 kann man noch kaufen. Wer eine hat, hat sie in einem 1200er installiert und braucht sie nicht am A500. Und wenn erstmal eine ACA500plus an diesem A500 ist, gibt es nur wenig Gründe, auch noch eine 1200er Turbokarte anzuschließen, weil mit der neuen Version deutlich mehr Rechenleistung, mehr Speicher und mehr Flash auf der ACA500plus sind (im Vergleich zur ACA500), die für den Anfang ganz sicher ausreichen.


    Jens

    Zitat von Wiesel

    Die asyncron getakteten Karten sind kein Problem - also alles ab ACA1220 und ACA1232. Einschränkungen gibt es bei der ACA1231 - die ist zwar asyncron, aber aufgrund des Vesalia-Exklusiv-Deals nicht in meiner Support-Verantwortung. Und weitere Einschränkungen gibt es aus technischen Gründen bei der ACA1230 (alle drei Versionen), welche syncron getaktet sind, und deswegen nicht sauber an der ACA500 funktioniert haben.
    Mit dem letzten Softwareupdate der ACA500 haben wir ein Softwareproblem mit den alten Karten (also ACA1230 und ACA1231) gelöst, und es haben auch ein paar Kunden berichtet, dass die Karten jetzt bei ihnen funktionieren. Das ist schön, und das wollte ich auch mit dem Softwareupdate erreichen. Es gibt aber die kleine aber feine Unterscheidung, dass ich nicht *garantiere*, dass diese alten Karten an der ACA500plus funktionieren werden, weil sie aufgrund ihrer Bauart streng auf das Timing des A1200 ausgelegt sind, das ich nicht bis ins Letzte auf der ACA500plus nachbilden kann.


    Ich halte das alles für akademisch, denn weder ACA1230, noch ACA1231 kann man noch kaufen. Wer eine hat, hat sie in einem 1200er installiert und braucht sie nicht am A500. Und wenn erstmal eine ACA500plus an diesem A500 ist, gibt es nur wenig Gründe, auch noch eine 1200er Turbokarte anzuschließen, weil mit der neuen Version deutlich mehr Rechenleistung, mehr Speicher und mehr Flash auf der ACA500plus sind (im Vergleich zur ACA500), die für den Anfang ganz sicher ausreichen.


    Jens

    Frage: Ich lese immer bei Dir was von "asynchron" und "synchron" getakteten Turbokarten. Was bedeutet das? Synchron zu was? Welche Vor- und Nachteile haben die beide Wege? Wie man liest, kommt bei deinen Karten ja beides vor.

    Zitat von eStorm

    Frage: Ich lese immer bei Dir was von "asynchron" und "synchron" getakteten Turbokarten. Was bedeutet das? Synchron zu was? Welche Vor- und Nachteile haben die beide Wege? Wie man liest, kommt bei deinen Karten ja beides vor.

    Das Mainboard des Computers hat einen eigenen Takt: Der A500 läuft mit rund 7MHz, und der A1200 mit rund 14MHz. Wenn ich eine Turbokarte baue, kann ich mich entscheiden, ob die frei getaktet wird, oder ob der Takt aus dem Mainboard des host-Computers gewonnen wird.


    Ein frei laufender Takt kann (="asyncron") beliebig gewählt werden. Man gewinnt Flexibilität und Stabilität im Design, verliert jedoch statistisch bei jedem Zugriff auf das Mainboard einen halben Takt.


    Ein syncroner Takt ist ein ganzzahliges Vielfaches des Computer-Taktes. Damit folgt die gesamte Turbokarte dem Takt des Amiga und verliert daher keine Zeit beim Zugriff auf das Mainboard. Nachteil ist jedoch, dass die Amiga-Takte so schwammig sind, dass die Syncronisation der Takte nie ganz stimmt. In Grenzen kann man das ausgleichen, aber ganz stabil ist es eigentlich nie. Klar wünscht man sich "eigentlich" volle Syncronität, weil dann wirklich das Letzte aus der Turbokarte herauszuholen ist, aber wenn's eben nicht in allen Betriebsmodi stabil ist, macht es keinen Spaß.


    Die AC1230 war syncron, und die ACA500 war auch syncron. Die ACA1230 lief an gut 20% der 1200er nicht sauber. Die ACA500 lief z.B. am NTSC-A500 Rev.5 und an sämtlichen A500 Rev.3 überhaupt nicht.


    Die ACA500plus ist asyncron, wenn sie auf 14MHz oder mehr getaktet ist. Damit ist sie kompatibel mit Rev.3 Motherboards und auch mit dem NTSC-Rev.5 Motherboard. Man kann sie auf 7MHz syncron umschalten (absturzfrei im laufenden Betrieb!), was ich aber an den zwei problematischen Boards noch nicht getestet habe.


    Meine 1200er Turbokarten nach der ACA1230 sind alle asyncron:


    - ACA1231: Die Vesalia-Karte mit 25MHz bis 41,irgendwas MHz
    - ACA1220: Diverse Geschwindigkeiten
    - ACA1232: ebenfalls "diverse Geschwindigkeiten" bis 50MHz, mit 68030 oder 68EC030
    - ACA1233: 68030 mit 40MHz oder 55,55;Hz
    . ACA1221: Vier freuqenzen umschaltbar, alle asyncron
    - ACA1221EC: noch nciht auf dem Markt, aber mindestens zwei Frequenzen umschaltbar
    - ACA1233n: Noch nicht auf dem Markt, ebenfalls asyncron


    Mit jeder Weiterentwicklung habe ich das Interface zum jeweiligen Mainboard verfeinert, damit es weniger Probleme beim Kunden gibt. Es ist ein Tradeoff zwischen Stabilität und Geschwindigkeit, und ich habe mich für "problemloses Produkt" entschieden, das halt hier und da mal einen Wartezyklus einlegen muss, jedoch im Gegenzug maximalen Spaß macht, weil man sich nicht drüber ärgern muss.


    Jens

    Zitat von eStorm

    Frage: Ich lese immer bei Dir was von "asynchron" und "synchron" getakteten Turbokarten. Was bedeutet das? Synchron zu was? Welche Vor- und Nachteile haben die beide Wege? Wie man liest, kommt bei deinen Karten ja beides vor.

    Am Thema vorbei aber eine andere Erklärung zu asynchron und synchron. Der 68000 kann seine Speicherzugriffe in zwei verschiedene Modi ausführen asynchron und synchron. Da einige ICs wie Speicherzellen eingebunden werden gibt es hier ein kleines Beispiel. Da es für den 68000 damals keine passenden Peripherie Bausteine gab hätte man nicht ohne eine zusätzliche Schaltungen in die asynchrone Bussteuerung wechseln können. Daher hat der 68000 auch einen synchronen Busmodus erhalten. Zum Beispiel die CIA 8520 fast Baugleich zur 8-Bit Familie 6526 (den man vom C64 her kennt) funktionieren nur im synchronen Busmodus und wird mit seinen 16 Register wie Speicherzellen eingebunden.
    Daher gibt es Bussteuerleitungen für den asynchronen Modus: AS,R/W,UDS,LDS,DTACK und Bussteuersignale für den synchronen Modus: E,VPA,VMA. Nachzulesen auch im AMIGA INTERN von DATA BECKER. :-)

    Zitat von Wiesel

    Nachteil ist jedoch, dass die Amiga-Takte so schwammig sind, dass die Syncronisation der Takte nie ganz stimmt. In Grenzen kann man das ausgleichen, aber ganz stabil ist es eigentlich nie. Klar wünscht man sich "eigentlich" volle Syncronität, weil dann wirklich das Letzte aus der Turbokarte herauszuholen ist, aber wenn's eben nicht in allen Betriebsmodi stabil ist, macht es keinen Spaß.
    Die AC1230 war syncron, und die ACA500 war auch syncron. Die ACA1230 lief an gut 20% der 1200er nicht sauber. Die ACA500 lief z.B. am NTSC-A500 Rev.5 und an sämtlichen A500 Rev.3 überhaupt nicht.


    Die ACA500plus ist asyncron, wenn sie auf 14MHz oder mehr getaktet ist. Damit ist sie kompatibel mit Rev.3 Motherboards und auch mit dem NTSC-Rev.5 Motherboard. Man kann sie auf 7MHz syncron umschalten (absturzfrei im laufenden Betrieb!), was ich aber an den zwei problematischen Boards noch nicht getestet habe.

    Dass der NTSC Amiga 500 nicht mit der syncronen ACA läuft, war ja eigentlich auch klar oder ? , denn NTSC Rechner laufen auf 7,14 MHZ statt 7,09 MHZ.


    Könnte man nicht einfach immer den Grundtakt des jeweiligen individuellen (Quarze haben ja alle Toleranzen, wie ich neulich am C64 gelernt habe, jedes Board läuft also um Nuancen unterschiedlich schnell) Amiga Boards für die Karte hernehmen (und genau den Takt dann doppeln, verdreifachen, etc.) ohne der Karte einen eigenen Taktgeber zu geben ? Dann wäre der Takt der Karte immer ein exaktes Vielfaches des gerade angestöpselten Amiga Boards, und es gäbe das Problem nicht oder kaum.

    Zitat von CommieSurfer

    Dass der NTSC Amiga 500 nicht mit der syncronen ACA läuft, war ja eigentlich auch klar oder ? , denn NTSC Rechner laufen auf 7,14 MHZ statt 7,09 MHZ.

    Scherzkeks. Und wie erklärst Du Dir, dass die ACA500 an Rev.6 NTSC-Boards problemlos läuft? Nur Rev.5 macht unter NTSC Probleme. Und die Rev.3 egal welchen Agnus man verwendet. Und das ist alles mit der ACA500plus gelöst.

    Zitat von CommieSurfer

    Dann wäre der Takt der Karte immer ein exaktes Vielfaches des gerade angestöpselten Amiga Boards, und es gäbe das Problem nicht oder kaum.

    Ein exaktes Vielfaches zu bilden ist kein Thema. Sich aber an den Drift im Amiga anzupassen, der von Takt zu Takt verschieden ist, *das* ist das Problem. Mit einem derart schwammigen Takt bekommt man im CPLD massig Probleme - das Stichwort hier lautet Metastabilität, denn Du samplest Signale mit "Deinem" Takt, die mit einem fremden Takt generiert wurden. Und wenn die hin und wieder mal auseinander laufen kann's vorkommen, dass sich ein Eingangssignal genau *während* einer Taktflanke ändert, so dass das Ergebnis nicht vorhersagbar ist.


    Es gibt da nen sehr guten Artikel von Xilinx zu, "Crossing the Abyss" war glaub' ich der Titel. Schwere Kost, aber unerlässlich, wenn man zuverlässige Produkte designen möchte.


    Edit: Der Artikel war gar nicht von Xilinx: http://m.eet.com/media/1137372/17561-310388.pdf


    Jens

    Hmm ja ok, ich dachte nur eventuell würde dann auch gar der "Drift" in den versch. Zuständen immer exakt zeitgleich von der Karte mit übernommen werden können, so dass es keine Probleme gäbe. Sofern man für alles den org. Taktpin (der CPU o.ä.) des jeweiligen Boards benutzt.

    Eine "Emu" der FPU wäre mit zwei Szenarien möglich.
    Die erste wäre ein FPGA, der die fehlenden FPU-Befehle bietet. Dies würde eine neue Turbokarte bedeuten. Fällt also damit wohl flach.
    Die alternative wäre eine "fpu.library", die die FPU-Befehle abfängt und damit die ALU füttert und an das Programm zurück gibt. Der Nachteil dieser Variante wäre, dass es sehr sehr lahm wäre. Aber immerhin funktionieren würde. Das dies nicht unmöglich ist, zeigt z.B. andere Betriebssysteme wie MacOS 7.x. Im A1k gab es schon solche Überlegungen diese Lib zu schnitzen, nur hat sich bisher keiner dazu bereit erklärt es anzufangen.

    Danke für die Antwort.


    Weshalb ich dass hier Frage.. Nun ich besitze neben der ACA1221/28 auch noch
    die ACA1232/40, und einige Demos verlangen tatsächlich eine FPU.


    Es sind Demos die wahrscheinlich auf/für eine Blizzard 1230/50+ FPU gemacht
    worden sind. Eigentlich nicht weiter wichtig, nur es wurmt mich ein wenig dass
    eine alte ranzige GVP 1230/40+ FPU diese Demos abspielen kann..
    Ich weiss, es gibt ja auch noch die ACA1233 mit FPU Option... schon klar..


    Es soll bitte keine Kritik sein, nur sollte auch eine FPU in der Amiga- Welt
    mehr Beachtung erhalten... Eine MC68040/MC68060 hat wohl diese schon
    Intern - sehr schön, wird echt Zeit für eine FPGA- Lösung ;)



    MiC