Sorry, ich war noch nie dabei, würde aber es gerne mal ausprobieren.
Kann ich mich hier anmelden?
Wie es scheint muss man vorbestellen was man haben will?
Posts by Thunderblade
-
-
Für einen C64 Reloaded MK2? Zweifelhaft.
Wieso, hat der C64R MK2 einen eingebauten Lumafix?
-
Der R1 hat nur 5 Helligkeiten, da sieht so manche Grafik merkwürdig aus.
Der R1 wurde in sehr frühen 64ern verbaut, die oft ein ziemlich matschiges Bild liefern - das liegt aber gar nicht an dem VIC sondern am RF Modulator. Dessen Einfluss ist größer als die VIC Revision.
-
Du hast nicht zufällig den Jahrgang 1984 der 64er übrig? Der fehlt mir noch…
Da ich meine Sammlung nach genüsslichem Schmökern etwas verkleinern werde, suche ich aktuell für genau diesen Jahrgang einen zahlungskräftigen
Abnehmer. Die äußerst seltene Erstausgabe 4/84 ist dabei, ebenso eine blaue Original 64'er Sammelbox. Die Ausgaben sind alle in einem guten, unzerfledderten Zustand! Könnte ich zur DoReCo mitbringen. -
Es demotiviert gewaltig wenn bugreports mich teils (viele) JAHRE spaeter erreichen.
Das versteh ich gut, aber als das Ding damals rauskam, dachte ich halt: Wow, spiele ich irgendwann mal. Als ich es Jahre später spielen wollte, habe ich über den Bug hier gelesen und gefragt, ob geplant ist daran was zu machen, erhielt jedoch keine Antwort. Da habe ich Zak qualvoll von Diskette (Image) nochmal gespielt. Nun wird wahrscheinlich wieder etwas Zeit vergehen, bis ich es nochmal spiele.
-
Sehe gerade, dass der Platz 62 frei geworden ist(?). Wenn das stimmt, wuerde ich gerne dort hin wechseln (von 70). Danke.
Cool dann sitzt du bei uns
-
Dort macht es allerdings am wenigsten Sinn, wo die Kiste doch auch C64-Programme kann. Exklusivtitel sind da sicher gefragter.
Würde ich nicht so sehen - wer kauft sich den so einen TheVIC20 - doch sicher Leute die gerade mit DEM eine tolle Nostalgie-Gefühlswelle erleben wollen. Dann plötzlich auch noch Boulder Dash drauf, ein riesen Kult, und eben NICHT die C64-Version, das wäre doch der Hammer! Für mich macht das sogar am allermeisten Sinn!
-
Jammet : reassembliert, C64 spezifischen Code entfernt, VC20 Code eingefügt.
Großes Lob und riesen Respekt, das ist absolut cool! Und in Game Art Beyond schrieb ich noch zu Boulder Dash: "It looked like a VIC-20 game and it sounded like one, too" oder so, und nun gibt es das wirklich für VC-20!!! Das ist echt unglaublich und ich freue mich darauf es zu spielen. Umsetzungen sind für mich seit jeher ein faszinierendes Thema.
Aber noch viel geiler ist doch die Vorstellung, wenn jemand 1985 so Flaschbier spielt und dann sagt: Hey, der Programmierer hat's echt drauf. Ich wette, so in circa. 35 Jahren, so 2020 rum, wird der nochmal Boulder Dash auf den VC-20 umsetzen!
Hammer. -
Erstmal ein großes "Hurra" und ein riesen "Dankeschön!" an die Orga, die alles tut um diese Veranstaltung stattfinden zu lassen.
Ich habe mich bereits über diesen Thread angemeldet, las nun aber dass Anmeldung per E-Mail ein Muss ist - korrekt? D.h. wer sich daran nicht hält gilt nicht als angemeldet und kann nicht rein? Wäre gut darüber hier nochmal kurz Klarheit zu schaffen.
Danke, und nochmals Beide Daumen hoch für euch! -
Danke für die Antworten!
Bei einigen Boards war bei mir Kleber drunter.
Gut, mal angenommen man kriegt den gelöst - wie klebt man's fest? Zwei-Komponenten-Kleber?
-
Bei einem meiner C64er sieht der Expansionsport, d.h. die Kontaktleiste, ziemlich "runtergenudelt" aus, so dass ich überlege ob man den ersetzen kann. Der Port eines Spenderboards sieht noch blendend aus.
Aber: Wie zum Geier ist der Expansionsport befestigt? Der muss ja große Kräfte aushalten beim An/Abstecken von Modulen. Aber angelötet ist er nicht oder? Ich sehe von unten jedenfalls keine Befestigung. Und geklebt wird der nicht sein oder? Kann man diese "Buchse" überhaupt wechseln?
Bin für Gedanken dazu dankbar.
-
Ja, $8000. Bei solchen Fragen hilft: http://www.c64-wiki.de - noch nicht bekannt?
-
-
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...
-
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. -
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.
-
Stellar 7 ggf. noch
-
Wie er mir gerade freundlicherweise mitteilte, wird LightSide dieses Mal nicht dabei sein.
Frei wird also: 17: LightSide - Commdore (Platz 62)
-
DATA (U2) <-> SRQIN = CASS_READ = /FLAG(U1)
Ja, das piept.
Und Kontakt zu Vcc/GND besteht auf der Schiene auch nicht.Wenn alles andere ausgeschlossen wurde, muss das was übrig bleibt, die Wahrheit sein: Jetzt wo die CIAs aus den Sockeln waren, ist mir erst aufgefallen, dass der Sockel von U2 etwas "runtergerockt" aussah. Nach etwas Reinigung und nach innen biegen der Pins des CIAs... ist der Fehler plötzlich verschwunden!
Kaum macht man es richtig, schon funktioniert es. Danke, kinzi , für deine Geduld. Die Sockel hätte ich in der Tat schon früher prüfen müssen, peinlich. Auch den 7406 tauschen hätte ich mir sparen können.
Probleme macht nun noch der VIC. Zwar laufen mit dem eingesetzten 6569R3 (Keramik) nun die Demos sowie Paperboy, während dieselben Programme mit dem 6569R1 in einem anderen Board nun auch laufen (
). Aber: Auch der 6569R3 wird in diesem Board sehr, sehr heiß und es tauchen im IFLI-Part von Eldorado Artefakte auf - während er in einem anderen Board zwar warm, aber nicht glühend heiß wird. Ggf. mache ich dazu einen neuen Thread auf... -
Sorry, du hast recht, ich habe das falsch zitiert, ATN wird auf CLK gebrückt und DATA auf SRQIN.
Ok, wenn ich den Schaltplan richtig lese dann führt CLK zu U2, Pin 8 (PA6). Bei gesteckten Dongles also eine Verbindung von U2, Pin 4 auf U2, Pin 8 - piept.
Was machen wir mit U1, gibt's da eine Verbindung?
ich meinte die gegenständlichee Verbindung von U1 zu U2 über die Dongles, ob die irgendwo auf Vcc oder GND klemmt.
Jetzt hakt mein Interpreter.
Also was tue ich, messen der einzelnen Pins an U2, Userport, Serial Port, und U1 (falls noch relevant) jeweils auf Durchgang zu VCC und GND?Danke schonmal für deine Unterstützung bis jetzt.
