Hello, Guest the thread was called30k times and contains 209 replays

last post from ZEUS at the

A600 Vampire II

  • @katarakt Musste ich eben mal selbst nachsehen - es ist die Black Series :D
    Die Karte sieht sehr gut verarbeitet aus, hat auf Anhieb gepasst und läuft soweit auch schon :)


    Ich werde die Tage mal etwas mehr berichten, hab jetzt nur eine Standard OS3.9 Installation genommen und die Treiber installiert um zu sehen ob das Ding überhaupt funzt.

    <C64 I +MixSID +Keyman64 +Reprom +TC64 +RRNET +WiModem...Ultimate64 +SX64 Style Case +Rear Admiral Thunderdrive +Nunchuk64 ...MorphOS PowerBook G4...Acorn A3000 +4MB +IDE RiscPC700 +StrongARM +5x86 AlephOne PC Card>
    <Icebird: Acorn Demogroup - Mini Mag Diskmag - TRT The Retro Team aus Oldenburg>

    <Retrospieleabend@Attraktor e.V. Hamburg>

    <Retrokompott Podcast Stammtisch http://www.retrokompott.de>

  • Aber dann hast du weniger als 298 für die Karte bezahlt. Sonst kommt deine Rechnung inkl. Versand und Einfuhrumsatzsteuer nicht hin.

    Die Karte hat inkl. Versand $306 USD gekostet (Wechselkurs €265,16) , die Option "Black" sollte erst später bezahlt werden, da der Core noch nicht fertig geschrieben und getestet war.
    Nun hat Brian die "Black" Karte ohne Zusatzkosten verschickt, da er die Option nicht komplett testen kann.
    Hier der Originaltext dazu von seiner Webseite:
    "27th Nov ...*** Batch 1 is completed and they are boxed ready for labels. For those who wanted a black version, i cannot guarantee that a final x13 core will work as of yet so i will not ask for any extra payment from those who have requested a black (Batch 1 group). I will however send them a board that i have tested and believe are black capable. If they do turn out to be black capable then feel free to make a donation to my paypal, if not then so be it."


    O.O Wann hast du denn die V600 bestellt bzw bezahlt? Ist die schon aus dem neuen "je 100er"-Batch? Ich frage, weil ich auch schon bezahlt habe und auf die bestätigte, geprüfte BE warte...

    20.9. bestellt, am 23.9 kam die Rechnung mit der Zahlungsaufforderung, die ich gleich per Paypal bezahlt hab.
    Ich denke mal das die Karte aus dem neuen Batch ist, da Brian am 3.10. mitteilte das nun genug Leute in Vorkasse gegangen sind um die Produktion in Auftrag zu geben.
    Am 7.11. kam die Nachricht das die Karten nun bei ihm angekommen sind und getestet werden, danach erfolgte der Versand am 1.12.

    <C64 I +MixSID +Keyman64 +Reprom +TC64 +RRNET +WiModem...Ultimate64 +SX64 Style Case +Rear Admiral Thunderdrive +Nunchuk64 ...MorphOS PowerBook G4...Acorn A3000 +4MB +IDE RiscPC700 +StrongARM +5x86 AlephOne PC Card>
    <Icebird: Acorn Demogroup - Mini Mag Diskmag - TRT The Retro Team aus Oldenburg>

    <Retrospieleabend@Attraktor e.V. Hamburg>

    <Retrokompott Podcast Stammtisch http://www.retrokompott.de>

  • Kurzes Zwischenfazit:
    Die Karte ist richtig geil - die Workbench in 800x600 bei Truecolor fliegt nur so. Leider habe ich noch keine höheren Modi an den Start bekommen, denke das liegt an meinem Monitor. Ich muss mich da in die Picasso Konfiguration nochmals etwas genauer einlesen. Falls da einer Tipps von Euch hat, gerne her damit ;) Ich nutze einen Samsung LT24E390.
    Gleiches gilt für SysInfo, trotz no cpu Patch semmelt das Teil beim berechnen der CPU Speed komplett ab (Neustart), man konnte aber kurz sehen das 110 Mips angezeigt werden. Meine B1260er im A1200 schafft "nur" 39,29 Mips. Vielleicht bin ich ja aber auch nur blöde zum (s)patchen - kann mir einer von Euch Vampire V2 Usern eine gefixte Version zukommen lassen?


    ADoom und ScummVM RTG laufen beide hervorragend, das macht richtig Lust auf mehr. Muss mir mal ansehen was es da noch so für RTG Titel/Ports gibt.


    Auch der ShapeShifter läuft auch sehr gut, ich bin nur noch nicht so ganz mit der Festplattenperformance zufrieden. Irgendwie kommt es mir so vor als wäre das Starten etwas langsam, oder ich hab das von meinen 1200er einfach nur falsch in Erinnerung.

    <C64 I +MixSID +Keyman64 +Reprom +TC64 +RRNET +WiModem...Ultimate64 +SX64 Style Case +Rear Admiral Thunderdrive +Nunchuk64 ...MorphOS PowerBook G4...Acorn A3000 +4MB +IDE RiscPC700 +StrongARM +5x86 AlephOne PC Card>
    <Icebird: Acorn Demogroup - Mini Mag Diskmag - TRT The Retro Team aus Oldenburg>

    <Retrospieleabend@Attraktor e.V. Hamburg>

    <Retrokompott Podcast Stammtisch http://www.retrokompott.de>

  • Ich finde die Vampire/Apollo-Geschichte das spannendste Hardwareprojekt der letzten 10 Jahre, mindestens. Ich warte schon darauf, dass die Vampire 1200 lieferbar ist. Und auch das Projekt "Phoenix", also ein Standalone Amiga/ST mit dem Apollo-Core und der erweiterten Grafik usw. finde ich klasse.


    Auch die Aussicht darauf, dass die Vampire Karten in Ataris laufen sollen, finde ich klasse und habe Kontakt zu Gunnar von Boehm, einer vom Apollo Team, aufgenommen. Ich habe Gunnar einiges an Dokumenten und Erfahrungen zu den ATari-Systemen zukommen lassen, soweit ich es eben kann. Und ich habe dafür versucht zu sorgen, dass das Apollo Team auch Unterstützung von Atari Hardware und Software Leuten bekommt, immerhin haben die Apollo-Leute nach Unterstützung gefragt, weil sie selbst vom Atari wenig Ahnung haben. Aber es ist zum Mäuse melken! gngngngng... Bei vielen Atari Leuten herrscht totale Skepsis, Misstrauen, was von Amiga Seite kommt, kann nicht gut sein. Lieber Vampire totschweigen... Und überhaupt, der Prozessor-Core ist ja nicht Open-Source, ja verdammt, ja, nicht, aber der originale Motorola 680x0 doch auch nicht!!! Und dann müsste der Apollo-Core Zyklus-Exakt sein, damit die alten Szenedemos mit ihren Timing-Tricks drauf laufen... gehts noch, der Apollo ist hundert mal schneller als der 68000, maximal 1 Takt pro Befehl, teils sogar 2 Befehle pro Takt, diese Demos laufen da drauf sowieso nicht... Aber auf den Themen wird rumgeritten, wie im Tal der Ahnungslosen!


    Jedenfalls ist von denen die ich direkt kenne, kaum jemand bereit, das Apollo-Team zu unterstützen. Das ist sehr schade. Es wären da einige gewesen, die durchaus sehr viel helfen könnten. Statt dessen wird über den x-ten 68020-Beschleuniger nachgedacht. Damit jeder mal einen selber entwickelt hat. (Argh!)


    Ich bin aber dennoch zuversichtlich, dass das Apllo-Team die Vampire im ST zum Laufen bekommen wird, mit SuperVidel-Grafikkern und allem was gebraucht wird, um aus einem ST was zu machen, was nicht mal Firebee ist. Auf einem Amiga mit Vampire läuft bereits EmuTOS. Das ist schonmal ein Anfang, die Benchmarkwerte sind ... beeindruckend ... , und angeblich hatte das Apollo-Team sogar schonmal TOS 2.06 bis zum Desktop gebootet, aber ohne dass TOS auf irgendwelche Laufwerke zugreifen konnte, und dann hagelte es Bomben Immerhin, dafür dass TOS 2.06 nicht mal 68030 tauglich ist, ist das doch schon was. (Dazu bräuchte man TOS 3.06, das bekommt man in einem normalen ST mangels TT Hardware aber nicht ohne wilde Patcherei zum Laufen) Aber wir haben ja die Opensource-Alternative EmuTOS...


    Außerdem arbeitet doch schon ein anderes Team an einem weiteren Atari kompatiblen System auf Basis des Apollo Cores, die Leute sind schon über ein halbes Jahr dran, bei der Komplexität des Vorhabens wird das aber noch dauern, bis es so weit ist. Aber da diese Leute bereits sehr begehrte Turbo-Karten für den Falcon gebaut haben (ct60/63) und soweit ich das sehe mitten in der EmuTOS und MiNT Entwicklung drin stecken, bin ich auch hier zuversichtlich, dass da trotz der Skepsis in den Foren etwas mit Hand und Fuß raus kommt. EmuTOS erkennt den Apollo-Prozessor schon, das ist die Basis. Vom Falcon ist bereits - bis auf den DSP - alles in VHDL modelliert, und der Falcon Grafikchip Videl ist auch modelliert, heißt SuperVidel, ist in der Lage FullHD darzustellen, und kommt da rein. Prinzipiell muss man das alles nur mit dem Apollo-Kern zusammen tun, das will aber nicht unterschätzt werden! Geduld ist angesagt.


    Das einzige Problem, was derzeit existiert, ist dass das Apollo Team noch keine Notwendigkeit sieht, dem Aolllo Core eine 68030/40/60 kompatible (P)MMU (Memory Management Unit für Memory Protection) zu geben. Ein vernünftiger, moderner ST mit solch einer Performance und Grafikfähigkeit muss unter MiNT (Linux-artiger Kernel, TOS-kompatibel, multitaskingfähiges GEM mit nVDI, nAES usw, welches hohe Grafikauflösungen und Farbteifen unterstützt, die ganzen GNU-Utilities und ein X-Window System sind an Bord) laufen, und da ist Speicherschutz wichtig, damit nicht das ganze System absemmelt wenn ein Task quer schießt. Auf dem Amiga scheint eine (P)MMU nicht so wichtig zu sein, man kennt es ja was apssiert wenn ein Programm absemmelt... Das Amiga-OS hat dafür (soweit ich weiß) jedenfalls keinen Support für eine MMU drin, aber im Apollo-Forum finden sich auch mindestens 2 Leute, die sich das auch für den Amiga wünschen würden, es gibt offensichtlich auch auf dem Amiga Software, die davon profitieren würde - und wenns "nur" Debian Linux oder NetBSD für 68K Systeme ist... Ich hoffe, dass das Apollo-Team diesem Wunsch nachgibt, eine Basis für eine vollständige PMMU scheint mit der MCU (Memory Control Unit) schon vorhanden zu sein, aber leider noch nicht kompatibel zu einer echten Motorola PMMU. Mal sehen... Wer da seine Meinung noch im Apollo-Forum abladen will, bitte, vielleicht hilft es, die Dringlichkeit des Bedarfs einer PMMU im Entwicklerteam zu erhöhen.


    Ich sehe dennoch schon den Tag kommen, wo vor mir ein TOS/GEM-Rechner mit Apollo-Kern stehen wird, der mit Aniplayer mit AMMX-Support MPEG-Videos abspielen wird. :thumbup: Das Ding wird in ein paar Jahren da sein, technisch auf einer Höhe, an der ATARI mit PCs und Macs nicht mehr mithalten konnte.


    Ps: Falls es jemand einwenden sollte: Der Apollo hat eine 68881/82 FPU integriert, genauer gesagt, zu der FPU im 68040 kompatibel. Denn auch die fehlende FPU wird in einschlägigen Kreisen immer wieder kritisiert. Zum x-ten Mal: Es ist eine FPU drin. Ihr fehlen nur ein paar exotische trogonometrische Funktiionen (Arctan und sowas), weil das in Software schneller zu realisieren ist, als auf der FPU - in einem 68040 z.B. braucht der arctan über 400 Takte, in Software bei gleicher Genauigkeit sind es weniger als 300.

  • Ich habe am 7.11. die letzte Email erhalten mit einer Aufforderung, die Bestellung zu bestätigen (habe mich für die Std entschieden) und meinen PayPal Account an Kipper2k zu senden.
    Gesagt, getan.
    Seitdem Funkstille, also schon 2 Monate.
    Normal?

  • 1ST1:
    Ich finde deine Meinung und Einstellung und dein Engagement klasse! Ich finde auch im Amiga-Bereich die x-te 020er oder 030er-Turbokarte ehrlich gesagt langweilig. Das einzig gute ist der sinkende Preisdruck....aber ansonsten: laaangweilig.


    Glaub mir, diejenigen die heute skeptisch sind, werden irgendwann die größten Schreier und Verfechter sein und "ich habs schon immer gesagt: tolles Teil" erzählen. Normale Verlogenheit....business as usual (leider!).


    Soweit ich es mitbekommen habe, nutzen im Amiga-Bereich tatsächlich nur sehr wenige wissenschaftliche Programme eine MMU - normale Anwendungen und Spiele gar nicht. Daher die niedrige Priorität. Aber ich sehe das zu kurz gesehen: die Vampire bringt das Potential in Zukunft neue Programmierung, neue Software anzustoßen. Und da wäre eien breitere Untersützung durchaus interessant.


    Momentan strotzt das Apollo-Team vor Selbstbewusstsein - und ist mächtig am "posen" - dafpr ist natürlich AMMX besonders gut geeignet. Ich hoffe, man läßt sich auch für den "nervigen Kleinkram" die nötige Zeit (wie eben MMU) und auch für die eigentlich essentielle SD-Karte...
    Naja...warten wir mal...



    Goethe:
    Ich hab zu dieser Zeit auch bezahlt. Hatte schon von zahlreichen Leuten gehört, dass sie später bezahlt haben und dann aber ihre Karte schon hatten. Dann habe ich einfach an Brian/kipper2k eine Mail geschickt. Wenige Tage später hatte ich den Tracking-Code. Jetzt müsste ich jeden Tag meine V600 erhalten. Momentan liegt sie wohl beim Zoll und ich warte auf die Benachrichtigung....


  • Das einzige Problem, was derzeit existiert, ist dass das Apollo Team noch keine Notwendigkeit sieht, dem Aolllo Core eine 68030/40/60 kompatible (P)MMU (Memory Management Unit für Memory Protection) zu geben. Ein vernünftiger, moderner ST mit solch einer Performance und Grafikfähigkeit muss unter MiNT (Linux-artiger Kernel, TOS-kompatibel, multitaskingfähiges GEM mit nVDI, nAES usw, welches hohe Grafikauflösungen und Farbteifen unterstützt, die ganzen GNU-Utilities und ein X-Window System sind an Bord) laufen, und da ist Speicherschutz wichtig, damit nicht das ganze System absemmelt wenn ein Task quer schießt. Auf dem Amiga scheint eine (P)MMU nicht so wichtig zu sein, man kennt es ja was apssiert wenn ein Programm absemmelt... Das Amiga-OS hat dafür (soweit ich weiß) jedenfalls keinen Support für eine MMU drin, aber im Apollo-Forum finden sich auch mindestens 2 Leute, die sich das auch für den Amiga wünschen würden, es gibt offensichtlich auch auf dem Amiga Software, die davon profitieren würde - und wenns "nur" Debian Linux oder NetBSD für 68K Systeme ist... Ich hoffe, dass das Apollo-Team diesem Wunsch nachgibt, eine Basis für eine vollständige PMMU scheint mit der MCU (Memory Control Unit) schon vorhanden zu sein, aber leider noch nicht kompatibel zu einer echten Motorola PMMU. Mal sehen... Wer da seine Meinung noch im Apollo-Forum abladen will, bitte, vielleicht hilft es, die Dringlichkeit des Bedarfs einer PMMU im Entwicklerteam zu erhöhen.

    Es gibt schon eine Unterstützung im AmigaOS für die MMU. Sei es von Phase5 als externe Lib oder sei es aus dem Aminet mit dem MMU-Libs von Thorfdbg (die deutlich mehr können, als die von Phase5 und anderen Anbietern). Vor allem bei der Softwareentwicklung und Bugreports ist eine MMU und die richtige Lib dazu sehr viel Wert.
    Jedoch ist das Interesse vom Apollo Team recht gering die MMU nach außen verfügbar zu machen (laut aussagen vom Team ist eine MMU bereits implementiert, aber sie sei zu nichts kompatibel). Sie vertrösten auf später, jedoch bin ich mir unsicher ob das noch kommen wird, da diese Implementierung viel Zeit und Mühe kosten wird. Aber wir werden sehen, was in 3 Jahren fertig sein wird.

  • MMU bremst einfach das ganze System!

    Ich verstehe nicht, wo eine MMU bremsen soll? Es ist lediglich ein Speicherschutz (Speichermaskierung), dass eine Anwendung nur den Speicher zu sehen bekommt, den sie braucht. Ich behaupte mal, am Ende ist man mit einem MMU basierten System sogar schneller, wenn man mehrere Sachen parallel macht, weil man alles - bis auf einen quer geschossenen Task - nicht nochmal machen muss. Außerdem ermöglicht eine MMU virtuellen Speicher, der auf Platte ausgelagert werden kann. Für den TT/Falconn gibts die Software "Outside", die genau das macht. Und letztlich, jeder PC ab einem 386er - bis heute - hat eine MMU, ohne die wäre WIndows und Linux in der Form wie wir das heute kennen, nicht existent.


    @eStorm, danke für deine selischmoralische Unterstützung, die Diskussion im deutschen und englischen Forum war echt zum heulen und davon rennen. wir Atari ST Nutzer müssen ein seltsammes Völkchen sein, ich vermisse da irgendwie die Aufbruchstimmung wie im Amiga-Lager.

  • Ich verstehe nicht, wo eine MMU bremsen soll? Es ist lediglich ein Speicherschutz (Speichermaskierung), dass eine Anwendung nur den Speicher zu sehen bekommt, den sie braucht. Ich behaupte mal, am Ende ist man mit einem MMU basierten System sogar schneller, wenn man mehrere Sachen parallel macht, weil man alles - bis auf einen quer geschossenen Task - nicht nochmal machen muss. Außerdem ermöglicht eine MMU virtuellen Speicher, der auf Platte ausgelagert werden kann.

    Hää, überleg doch mal logisch. Wie kann eine zusätzliche Überprüfung schneller sein?