Hallo Besucher, der Thread wurde 13k mal aufgerufen und enthält 94 Antworten

letzter Beitrag von gHost am

Flash 8 - Fragen zum unbekannten Wesen

  • Also ich bin ein echter FPGA-Hasser. Die machen alles viel zu teuer und da es SMD ist, nicht selbst lötbar. Der MACH-130-Chip der Flash 8 ist ein 84 Pin-PLCC, dafür gibt es Sockel.

    Sonst sind 9 TTL-Chips drauf (74F74, 74F86, 74HCT393, 74HCT574), ein Eprom, zwei ZIP-RAMs und natürlich noch der DIP-65C816 mit einem Quarzoszillator.

    Es gibt ein 5K-Potentiometer. Das muß man bei der ersten Justage nach ganz rechts drehen, wenn man weiter nach links dreht kommen irgendwann Grafikfehler.

    Also wieder etwas zurückdrehen. Ob diese Justage in irgendeiner Weise notwendig ist, weiß ich nicht. Die Karte läuft ja in jedem Fall stabil.


    Wenn man den MACH130 wieder neu brennen kann, bräuchte man wirklich nur die Leerboards produzieren, dann kann das Ding für ein paar Euro selbst zusammengelötet werden.

    So wie es aussieht, haben neben mir noch zwei Leute im Forum eine. Vielleicht stellt jemand seine zur Verfügung? Meine ist zu verbastelt. Bei der von einem Freund sind aus

    unerfindlichen Gründen die ZIP-RAMs in den Sockeln festgelötet X(


    Es wird sicherlich immer noch genügend Leute geben, die der Flash 8 gegenüber Vorbehalte haben. Aber das ist ganz einfach deshalb, weil niemand das Ding kennt.

    Die Karte ist vor knapp 25 Jahren kurz vor der SuperCPU rausgekommen und es gab ein paar Berichte in Magazinen, die fast nur die negativen Seiten aufgeführt haben.

    Ich habe aber jahrelang damit gearbeitet. GEOS mit CMD HD, zwei RAM 1581 und echter 1581. Mit einem Y-Adapter und einer GEOS-Software kann man die Flash 8 mit

    einer geoRAM, BBGRAM oder neoRAM koppeln und hat so 1,5 oder 3 MB RAM unter GEOS. Keinerlei Abstürze oder sonstige Probleme.


    Ich habe noch ein flackerndes Video, vom 1084 abgefilmt. Menüaufbau, Vorschau-Funktion und Scrolling in geoPaint, jeweils mit 1 und 8 MHz.

    Wenn die Sache besser läuft, werde ich mal sehen, daß ich ein paar richtige Aufnahmen über S-Video machen kann.

  • So wie es aussieht, haben neben mir noch zwei Leute im Forum eine. Vielleicht stellt jemand seine zur Verfügung? Meine ist zu verbastelt. Bei der von einem Freund sind aus

    unerfindlichen Gründen die ZIP-RAMs in den Sockeln festgelötet

    Ich hab auch eine, weiß jetzt aber nicht, ob sie im Bunker oder in meinem Schrank ist.


    Die eingelöteten ZIPs sind ein Reparatur-Versuch von Roßmöller. Meine F8 war dermaßen instabli, dass nichtmal Basic-Programme vernünftig liefen, weshalb ich die auch an Roßmöller zur Reparatur zurückgeschickt habe. Vermutete Ursache laut 64er-Magazin war Hitze an den ZIPs, weshalb ich die dann mit in den Sockeln eingelöteten ZIPs zurückbekommen habe. Gebracht hat es aber nix, die Ursache muss wohl doch woanders gelegen haben.

  • Ja, die ZIPs bei der F8 von meinem Freund werden sehr heiß, heißer als meine.


    Wie gesagt, ich kann nur Gutes über die Flash8 berichten. Sie läuft an der C-Platine und der E-Platine und auch an einem SX-64 problemlos.

    Bei meiner sind die DIP-Schalter zwei und drei aus und der Jumper ganz rechts ist auf der oberen Position. Ich habe ja sogar mal andere

    Quarze getestet, deshalb ist ein normaler 14-Pin-Sockel drunter. Dadurch sitzt der 32 MHz-Quarz etwas wackeliger, habe aber trotzdem nie

    Stabilitätsprobleme im Betrieb gehabt.

  • Ich habe das jetzt mal mit SEP #$30 getestet. In BASIC müßte das ja so aussehen:


    POKE251,226:POKE252,48:POKE253,24:POKE254,251:POKE255,96:SYS251


    Einmal hat es funktioniert und er ist wieder zum BASIC-Prompt zurückgekehrt. Aber danach nicht mehr.

    Immerhin: Der 65C816 ist tatsächlich im 16 bit-Modus, ich habe es mit dem 'Emulation'-Pin überprüft.

    Beim Start im 8 bit-Modus ist es auf High, nach dem Umschalten (inklusive Absturz) ist es Low.

  • Ich finde es immer doof, wenn der eigentliche Rechner nur noch ein Anhängsel der Zusatzhardware ist. Das TC64 ist ja ein komplett eigener Rechner welcher den C64 gar nicht braucht.

    Wie läuft das genau bei Super CPU oder Flash 8, das ist ja eher C64- Unterstützung als Ersatz?

  • Diese Karten ersetzen den 6510 durch den 65C816 in der Beschleunigerkarte. Es gibt also keine illegalen Opcodes mehr.

    Allerdings hat man jetzt den vollen Befehlssatz des 65C816 inklusive 16 MB Adressraum zur Verfügung.


    Der 65C816 ist auch grundsätzlich kompatibler zum 6502. Man hat also keine echten 24bit-Adressen, sondern der Speicher

    ist in 256 Bänke zu 64K aufgeteilt, also ähnlich wie in einer REU. Eine 65C816-Adresse ist also sechsstellig, zwei für die Bank

    und dann die Adresse. Durch Long-Adressing-Befehle kann aber in jeder Bank Code direkt ausgeführt werden.

    Der 65C816 hat insgesamt 24 Adressierungsmodi - 9 mehr als der 6502 - und neue interessante Befehle wie Block-Move.

    Zudem ist der Prozessor statisch aufgebaut, er ist also nicht auf DRAM angewiesen.

  • Ja. Sogar das BASIC und das Charset ist im ROM. Zumindest bei der Flash 8.


    Ich hatte mal was gesehen, daß jemand im Forum ein Plug-In-Replacement für den 8502 basierend auf dem 65C816 vorgestellt hat.

    Das wäre doch gerade jetzt ideal, da das Mainboard des C128neo inzwischen frei im Netz verfügbar ist, im KiCAD-Format.

    Allerdings ist der 8502 sehr schwer erhältlich. Ich kann mich glücklich schätzen, noch acht Stück davon zu haben, auch sonst habe

    ich noch genug C128-Chips da. Mit einem 65C816-basierten Prozessor und einem neu entwickelten freien 16bit-Kernal und BASIC

    wäre das doch ideal. Ich könnte mir vorstellen, daß das was für die Demoszene wäre. Der C64 scheint ja nicht mehr zu reichen,

    es gibt ja immer mehr Sachen, die eine 16 MB-REU benötigen. Ein von Grund auf dem 65C816 basierendes System hätte wesentlich

    mehr Möglichkeiten. Man kann ja alles in den unteren 64K wegschalten und hat so viel Platz frei. Zudem könnte man mit den

    Block-Move-Befehlen des 65C816 Daten durch SID und VIC 'streamen'. Das würde auch ganz neue Möglichkeiten bieten.

    Wenn die ganze Sache ohnehin auf dem C128 basiert, kann man auch die erweiterten Möglichkeiten des VIC-IIe verwenden.

    Und auch die 1541 hat ausgedient, denn für 16bit-Demos wird viel Speicher benötigt, und die kann die 1581 im Burst-Modus liefern.


    Falls jemand am C128neo-Board interessiert ist: Ich würde mir vielleicht eine kleine Charge schwarzer Boards machen lassen, aber

    mir fehlt am Layout noch etwas. Das Board ist ein genaues Abbild des originale 128ers. Allerdings könnten einige Verbesserungen

    dazukommen. Beispielsweise der Modulator-Fix. Da ist nur ein großer silberner Bereich, und gerade der VIC-IIe des C128 hat das

    Problem mit den vertikalen Streifen. Der gerasterte Hintergrund von GEOS ist dort abwechselnd rot/grün. Eine weitere Neuerung

    wäre die Anpassung an einen Umbau. Heutzutage würde ein ATX-Tower genommen werden, man bekommt nie ein Gehäuse mit

    passenden Aussparungen. Es wäre eine gute Idee, wenn alle Ports als 2,54 mm-Raster für Flachbandkabel verfügbar wären.

    Das würde einen Umbau erheblich erleichtern. Der Userport und der VDC können sich eine Serial-Slotblende mit 25poligem und

    9poligen SubD-Anschluß teilen. Für Video und Audio wird die Slotblende einer alten Soundkarte verwendet. Es gibt ja die 3,5 mm-

    Stecker mit vier Pins, die würden sich sowohl für Audio und Composite als auch für S-Video eignen. Auch für eine Buchse mit 2x

    Audio-In vom SID ist noch Platz. Die 15polige Gameport-Buchse teilen sich Cassettenport und Serial. Der Expansionport kann

    dann durch die ATX-Blende gelegt werden, allerdings ist auch da eine Pinleiste sinnvoll, wenn man z.B. intern die SuperCPU oder

    eine RAMLink ohne Gehäuse verbauen möchte. Falls also jemand mit KiCAD umgehen kann und diese Modifikationen einbauen

    kann, das wäre klasse.

  • Retrofan

    Hat den Titel des Themas von „Flash 8 Original EPROM“ zu „Flash 8 - Fragen zum unbekannten Wesen“ geändert.
  • Es wird sicherlich immer noch genügend Leute geben, die der Flash 8 gegenüber Vorbehalte haben. Aber das ist ganz einfach deshalb, weil niemand das Ding kennt.

    Die Karte ist vor knapp 25 Jahren kurz vor der SuperCPU rausgekommen und es gab ein paar Berichte in Magazinen, die fast nur die negativen Seiten aufgeführt haben.

    Ich habe aber jahrelang damit gearbeitet. GEOS mit CMD HD, zwei RAM 1581 und echter 1581. Mit einem Y-Adapter und einer GEOS-Software kann man die Flash 8 mit

    einer geoRAM, BBGRAM oder neoRAM koppeln und hat so 1,5 oder 3 MB RAM unter GEOS. Keinerlei Abstürze oder sonstige Probleme.

    Also ich war auch ein großer Fan der Flash8, bis die SuperCPU kam. Die Vorbehalte gegenüber der Flash8 kommen zumindest bei mir also nicht daher, dass ich sie nicht kenne, sondern WEIL ich sie kenne. :) Für GEOS war die sicherlich super. Darüber hinaus hatte sie allerdings einige gravierende Probleme:


    1) Da der 65816 den Code ausführt und auch das RAM für ihn auf der Karte ist, kann der VIC das nicht lesen. D.h. eine Logik muss bei jedem (!) Schreibzugriff der CPU das zu schreibende Byte fangen und ebenfalls an die richtige Stelle im C64 schreiben. Natürlich für IO aber eben auch, damit die Daten im RAM des C64 selbst landen, damit der VIC diese als Grafik anzeigen kann. Dies verlangsamt natürlich das ganze, da man nur in 1 MHz Zyklen auf das RAM des C64 zugreifen kann. Die Entwickler der Flash8, die bis heute anonym sind (Martin Rossmöller hat die Karte lediglich vertrieben) waren clever und haben diesen Vorgang für Zeropage und Stack ausgelassen - das gab's bei der SuperCPU V1 nicht und deshalb gab es tatsächlich Fälle, wo die Flash8 schneller war als die SuperCPU V1. Aaaaber leider wurde aus irgendeinem Grund dieses Kopieren der Schreibzugriffe in den C64 zusätzlich für bestimmte VIC-Bänke ebenfalls NICHT gemacht. Für viele Programme egal, z.B. alle die Screen-RAM bei $0400 haben usw. Aber es gibt Spiele, die ihren Grafikspeicher in anderen VIC-Bänken haben, und soweit ich mich erinnere gab es 1 oder 2 Bänke wo die Flash8 dann nur Grafikmüll angezeigt hat! Autsch.


    2) Im Auslieferungszustand kam die Flash8 mit dem Rossmöller-Speeder Turbo Trans (glaub so hieß der), d.h. außerhalb GEOS waren alle Laufwerkszugriffe über Kernal schnarchlangsam, wenn man nicht zufällig den Exoten Turbo Trans in der 1541 hatte. Ganz schlimm war es mit 1581, FD-2000 oder gar CMD HD. Diese Laufwerke sind ohne JiffyDOS ja so langsam, dass sie kaum zu gebrauchen sind.


    3) Für Assembler-Programmierer gibt es eine ganz wichtige Funktion, die nennt sich RESET. :) Wenn man was codet, assembliert, testet, und dann gibt's einen Bug, drückt man Reset und springt dann mit einem SYS wieder in seinen Assembler. Leider bricht bei der Flash8 bei Reset sofort der RAM-Refresh zusammen und der ganze Speicherinhalt war weg. Daher vor JEDEM Test des eigenen Programms: Source Code abspeichern! Unglaublich nervig spätestens dann, wenn man das erweiterte RAM der Flash8 mit z.B. Grafikdaten gefüllt hatte - die musste man nach jedem Reset neu laden.


    4) Nebenbei gab es keinen Assembler, der die 65816-Opcodes verstand. Rossmöller lieferte "ASS64", ein Uralt-Produkt, wo mit ein paar Makro-Krücken die neuen Befehle implementiert waren. Das Ding war nicht ernsthaft benutzbar.


    Einige Kumpels und ich waren von der Flash 8 damals so begeistert, dass wir um jeden Preis diese Mankos weghaben wollten. Wg. Punkt 4 wurden wir selbst aktiv: Einer von unserer Clique damals war der Autor des "VisAss" Assemblers (Listing des Monats in einer 64'er) und er fing an, diesen um 65816-Befehle zu erweitern. Das Ergebnis gibt es glaube ich noch irgendwo unter dem Namen "Flash8-Assblaster".


    Wir nahmen Kontakt zu Martin Roßmöller auf, wegen der Punkte 1-3. Nach einigen Telefonaten besuchten wir ihn persönlich in seiner Firma. Er und seine Frau Birgit waren total freundlich und nett, wir tranken Tee und fachsimpelten. Für Punkt 2 konnten wir ihn überzeugen, dass Turbo Trans nicht mehr zeitgemäß war und vor allem wegen der 1581/FD/HD Thematik JiffyDOS ein absolutes MUSS darstellte. Das sah er dann auch so und wenige Tage später lag das EPROM mit JiffyDOS für die Flash8 in der Post. Damit war schonmal ein wichtiges Manko eliminiert. Was wir damals nicht wussten war, dass das JiffyDOS nicht lizenziert war.


    Wegen der Punkte 1 und 3 gerieten wir dann aber leider in Streit. Dass einige existierende Programme wegen der "falschen" VIC-Bank nicht liefen, müsste man eben hinnehmen und an der Reset-Problematik wollte er auch nichts mehr machen. Am Ende rief Martin Roßmöller: "Die Karte ist fertig, basta!". Wir konnten uns das zunächst nicht erklären, vermuteten aber dass er kein weiteres Geld mehr investieren wollte oder konnte - man bedenke, dass die Fa. Roßmöller ja irgendwie pleite war und dann unter dem merkwürdigen Namen "Discount 2000", auf seine Frau registriert, weitermachte.


    Als dann die SuperCPU kam, stürzten wir uns natürlich darauf. Der "Virtual Assembler" mit 65816-Support von Sputnick entstand, Metal Dust - ursprünglich für die Flash 8 begonnen - konnte damit reaktiviert werden. Einem Reset während der Entwicklung stand nichts im Wege und die Grafikprobleme waren ebenfalls gelöst... Ach, was waren das Zeiten. Leider war die SuperCPU für viele zu teuer, so dass auch mein Programmierkurs zum 65816 in der GO64! nicht die erhoffte Resonanz fand.

  • Thunderblade


    Wow, das war ein interessanter Bericht. Ja, früher konnte man einfach noch wo hinfahren und was mit den Leuten besprechen. Aber gut, an so einem Teil später nochmal viel zu ändern ist schwierig.

    Daß JiffyDOS nicht lizensiert war, ist auch nicht verwunderlich. Damals konnte man nicht so schnell eine eMail senden, und ob CMD für eine deutsche Beschledunigerkarte grünes Licht gegeben hätten,

    wo sie doch selbst gerade an der SuperCPU waren... Es gab ja immer einen guten Kontakt mit dem Rick Gaudet in Österreich zu CMD, der hat ja auch die Handbücher übersetzt. Aber irgendwie haben

    die sich dann auch zerstritten. Ein Freund und ich hatten jeweils 100 Mark für die SUperCPU 128 angezahlt, die waren weg.


    Gut, wenn man halt entsprechende Fehler einer Hardware kennt, dann muß man eben sehen, wie man die beim Programmieren umgeht. Beim C64 werden die Fehler der Hardware ja gerade

    ausgenutzt... Den Vorgänger TurboProcess mit 4 MHz hatte ich auch mal da, aber der war wirklich zu instabil.

    Sowohl die Flash 8 als auch die SuperCPU haben ähnliche Probleme gehabt: Zu teuer und zu wenig Unterstützung. Außer GEOS gab es kaum einen sinnvollen Anwendungszweck.

    Zu der Zeit ging es mit GEOS aber auch langsam zu Ende, außerdem hat es sich in viele Teile zersplittert: Normales GEOS, Wheels, MegaPatch3 und GateWay. Oder war das nur ein Desktop-Ersatz?

    Den Metal Dust-Prototyp habe ich damals in Stuttgart auf dem GO64!-Stand noch auf der Flash 8 gesehen. Das Spiel kann man mit den heutigen Programmiertechniken aber auch so hinbekommen.


    Daß der 65C816 nie Einzug im C64 oder C128 fand, ist ziemlich schade. Selbst ohne Beschleunigung könnte man mit den neuen Befehlen des Prozessors und dem großen Speicher

    viel anstellen. Auch neue Hardware wäre möglich, schließlich kann man in einem 24bit-Adressraum mehr einbinden als nur RAM oder ROM.

  • Also mir würde schon reichen, wenn der C64 einfach nur einen Ticken schneller wäre und ein wenig mehr Ram hätte ( Was SCPU und Ram expansion ja im grunde machen). Oder so ähnlich wie der C128 wenn er mal richtig am Markt angekommen wäre und man ihn mal ausgereitzt hätte, was ja leider nicht wirklich passiert ist.

  • Der C128 hat halt das Problem mit dem Bankswitching gehabt, was alles enorm verkompliziert hat. Es gab einige Spiele, die den C128 ausgenutzt haben.

    Von 'The Last V8' und 'The Rocky Horror Picture Show' gab es eigene C128-Versionen. Bei letzterem muß man vorher übrigens auf 'FAST' schalten,

    damit das Spiel schneller läuft. Das geht natürlich im 40-Zeichen-Modus. Uridium soll auch im C64-Modus auf dem C128 wohl mehr Sprites darstellen.


    Der C128 hat halt das Problem gehabt, daß er neun Monate später vom Amiga überholt wurde. Dazu gab es genügend andere Probleme: Er war zwar CP/M-

    tauglich und das CP/M Plus soll wohl nicht schlecht gewesen sein. Ein Freund von mir macht viel mit CP/M. Aber wenn zum Diskzugriff jedes Mal auf 1 MHz

    geschaltet werden muß, ist das bei einem 'Disk Operating System' nicht gerade förderlich. Dann gab es die Geschichte mit der 1570 - ein einseitiges Laufwerk

    unter CP/M ist doch ein Witz.


    Der VDC wurde von BASIC aus überhaupt nicht unterstützt. Was man aus dem Ding alles rausholen kann ist unglaublich, VDC-FLI in 640x480 und enormer

    Farbenpracht. Auch der VIC-IIe hat genügend Funktionen, die nie dokumentiert wurden, man kann ihm eine neue Farbpalette verpassen, es ist volles Overscan

    ohne Sprites möglich, man kann ihn auf 1,3 MHz pushen und er hat einen versteckten Interlace-Modus mit 160x400 und 320x400 Pixeln. Höchstens im Demo

    'Risen from Oblivion' von Crest und Oxyron kann man etwas davon sehen.


    Noch komischer war dann ja der C65, der ja ein noch komplizierteren Speicheraufbau haben sollte als der C128 und den 64er-Modus nur nebenbei drin hatte.

    Zudem war das Ding teilweise dem Amiga 500 überlegen, womit sich Commodore selbst Konkurrenz gemacht hätte. Die Floppy soll auch äußerst langsam

    gewesen sein. Ich hätte Ende der 90er einen C65 für 650 Mark bekommen können, hatte damals leider nicht das Geld *seufz*

    Ein echter C65 wäre noch mal ein Traum, auch wenn es nichts dafür gibt. Vom FPGA-basierten MEGA65 mit VIC-IV und was weiß ich halte ich nicht allzu viel,

    vor allem, wenn er über 1000 Euro kosten soll. Er wird das gleiche Schicksal haben wie die SuperCPU: Zu teuer und es gibt nichts dafür.

  • Von 'The Last V8' und 'The Rocky Horror Picture Show' gab es eigene C128-Versionen. Bei letzterem muß man vorher übrigens auf 'FAST' schalten,

    damit das Spiel schneller läuft. Das geht natürlich im 40-Zeichen-Modus.

    Bitte nicht echte Hardware mit VICE verwechseln, danke.

  • Den Metal Dust-Prototyp habe ich damals in Stuttgart auf dem GO64!-Stand noch auf der Flash 8 gesehen. Das Spiel kann man mit den heutigen Programmiertechniken aber auch so hinbekommen.

    Das höre ich immer wieder, bin mir nicht sicher wie man zu so einer Aussage kommt. Metal Dust unterscheidet sich z.B. von Katakis vor allem darin, dass die Sprites größer sind, vor allem die Endgegner, und das diese teilweise viele Animationsstufen haben - man denke an den drehenden Meteor gleich im ersten Level. Das braucht mehr Speicher, wäre auf einem Standard-C64 nicht zu machen. Zweiter großer Unterschied ist der digitalisierte Soundtrack: Selbst wenn man den auf REU auslagern würde - allein die Interrupt-Last für das Abspielen der Samples würde jeden Standard-C64-Spritemultiplexer doch ziemlich umwerfen. Also: Digis weglassen, riesige Sprites weglassen - und dann hat man ein Standard C64-Shoot'em up, wovon es wie Sand am Meer gibt.


    Wirklich interessant wäre, wenn "die besten der besten" aka Knights of Bytes selbst, sich des Themas annehmen würden. Grafik auf dem Niveau von Sam's Journey, epischer SID-Soundtrack statt Digis - vielleicht ja sogar von c0zmo, dann wäre Welle: Erdball auch wieder beteiligt. :) DANN aber auch nur dann, könnte ein ebenbürtiger Nachfolger geschaffen werden. ;)

  • Kennst du das Demo 'Fantasmolytic'

    Wenn man Demos als Messlatte nimmt, was in Spielen möglich sein müsste, dann wäre sicher auch ein Driller / Dark Side / Total Eclipse in einer Flash8-artigen Geschwindigkeit auf dem Standard-C64 machbar. Warum hat es bloß noch keiner gemacht... ;)