Danke 1570. Das werde ich mir mal ansehen. 
Posts by Thorsten Kattanek
-
-
Erst einmal ein schönes Projekt.
Ich selber kannte dieses Projekt bis heute noch gar nicht. 
Ich habe mit meinem Projekt auch nur angefangen, weil ich mich momentan viel mit den Pico's (RP2040) beschäftige und in meiner Sammlung ein C64 mit defekten SID vorkommt (Das kennt glaube ich jeder hier). Ich denke auch das es da draußen noch mehr findige Leute gibt, die sich genau mit diesem Thema beschäftigen. Ich für meinen Teil mache das aus reinem Spaß an der Sache. Hier kann ich Hardware basteln und Software schreiben, miteinander vereinen. Und wenn am Ende was für die Community raus kommt, um so besser. Weiterhin viel Spaß und Erfolg bei deinem Projekt Frenetic. -
Tatsächlich habe ich hier noch 6 Platinen im schicken rot. Rev. 1.4.0
-
Hier noch ein paar Bilder:
-
Thorsten Kattanek hatte es ja am nackten C64 mit Rebuild gespielt.
Jo bei mir geht es. Was mir spontan einfällt, sind evtl. die Filenames bei deinen D64 Images zu lang. Wenn ja wird das Ende abgeschnitten und somit auch die File Extension. Somit erkennt die 1541-rebuild im ersten Schritt nicht das Image Format.
Auszug aus der Doku:
-
Hat eigentlich schon jemand versucht, das Game von einem
1541 Rebuild zu spielen ?
Hab es gerade mal angespielt. Läuft auf "nackten" C64 mit 1541-rebuild soweit ohne Probleme. Hab's jetzt aber nicht durchgespielt.
Ansonsten aber ein sehr geiles Spiel, danke an die oder dem Entwickler -
Ahhh eins noch... baut ihr die Platine aus oder kann die auf der Floppyplatine bleiben?
Und Display und SD reader drannlassen oder abstöpseln?
Du kannst das ohne Floppyplatine machen. Wenn der Programmer selber keine 5V ausgibt, einfach die 5V auf den Jumper J5 geben und flashen. An sich muss sich nur der Atmega auf der 1541-rebuild befinden. Es muss kein Display, der SD-Slot oder der Encoder angeschlossen sein.
-
Ich habe den Pullrequest von Fook42 in meinem Repository übernommen (ohne i2c Unterstützung). Somit ist der D64 Schreibsupport auch für die PCB Version 1.4.0 verfügbar. Ich habe die Firmware Version auch auf 1.3.7 angehoben um keine Verwirrung zu erzeugen. Ein Release ist dafür nun verfügbar und ihr könnt die Firmware wie gehabt flashen.
Hier die Version für die PCB Version 1.4.0 -> https://github.com/ThKattanek/…ebuild/releases/tag/1.3.7
Und hier die Version für die PCB Version 1.4.2 -> https://github.com/fook42/1541-rebuild/releases/tag/SW1.3.7
Danke fook42 nochmal für deine Mühe und genauso stelle ich mir OpenSource Entwicklung vor, jeder trägt seinen Teil dazu bei.
Und jetzt schaue ich mir noch mal deine PCB Version an, wo es bei mir irgendwie Probleme gab wenn das OLED angeschlossen war, jedoch nicht mit dem LCD ohne i2C.
Bleibt alle Gesund.
-
Super fook42. Na dann kann ich mich ja um andere Sachen kümmern
. Kannst du einen Pullrequest machen nur mit den Sachen die für das schreiben nötig sind 
Dann kann ich das die Tage mit in meinem Repo hinzufügen. So können die Besitzer der "alten Hardware" das auch gleich testen. Auf alle Fälle Daumen hoch. -
Genau das ist mein Ansatz. Ich will es so machen das die 1541-rebuild Grundsätzlich intern g64 verarbeitet. Wird jedoch ein d64 gemountet wird dieses in eine temporäre g64 gewandelt und entspr. flags im eeprom gesetzt. Wird das Image manuell ausgeworfen wird es sofort zurück gewandelt wenn auch wirklich drauf geschrieben wurde. Sollte die 1541-rebuild einfach ausgeschaltet werden, erkennt man anhand der Flags das eine d64 gemountet war und wird dann wieder zurückgweandelt von g64 nach d64. Werde das in meinem Urlaub umsetzen. Werde auch nichts in meinem Repo an der Anzeige ändern, so das fook42 das dann in seinem fork übernehmen kann. Das dopellt anlegen von d64 + g64 images halte ich für unnötig.
-
Danke fook42 für deine Bemühungen, somit wissen wir, das das live schreiben als D64 so nicht funktioniert. Ja der Ansatz war gut aber für den Atmel doch etwas zu viel. Mein Ansatz geh da einen anderen Weg. Ich habe sogar noch 2 Ideen. Ich habe zwischen Weihnachten und Neujahr Urlaub und werde dort das mal umzusetzen und schauen ob das Erfolg bringend ist. Jetzt vor Weihnachten hat man leider immer viel um die Ohren. Ich halte euch auf den laufenden. Meine Variante mit dem OLED wollte ja auch nicht wirklich, zumindest ging ja dann kein laden vom Image nicht mehr. Hatte leider keine Zeit das weiter zu testen, das mache ich dann auch im Urlaub.
Freue mich schon auf die freie Zeit dann kann ich wieder rum friemeln.
-
Sobald fook42 und ich einen Weg gefunden haben das Projekt (bezüglich der künftigen Firmware Updates) sinnvoll weiterzuführen, sowohl für die "alte Hardware" und die "neue Hardware" wird es dann auch zügig weitergehen.
MfG Thorsten
-
Ich bin Sprachlos, und noch einer der von uns gegangen ist. R.I.P. Seanser. Mein aufrichtiges Beileid und viel Kraft für seine Familie und Angehörigen.
-
Also für meinen Teil werde ich jetzt erstmal bei dem ATMEGA bleiben und sehen was ich da noch raus holen kann, bevor ich dann über einen anderen Controller nachdenke. Einige Ideen habe ich ja, die werde ich erstmal ausprobieren. Schauen wir mal wo die Reise hingeht.
-
Bitte kein STM32
Die sind so schwer zu bekommen und teuer wie Gold
Ok, ich kenne die momentane Lage auf dem Chipmarkt nicht wirklich.
mein Vorschlag: einen PIC32 nehmen... den gibt es (noch) günstig z.B. bei Reichelt und er hätte sowohl genug internes Ram für eine ganze Spur (evtl. sogar noch mehr) und auch genug externe Interrupts (für die Stepsignale und das SOE).
Auf alle Fälle sehr Preiswert und ein 32bitter. Meine PIC Erfahrungen sind schon einiges her. Bevor ich mir da wieder einarbeite, was auch wieder viel Zeit kostet werde ich dann doch erstmal den ATMEGA weiter nutzen und das erstmal umsetzten was noch an Issues im GitHub hängen. Den PIC halte ich aber mal im Auge als evtl. Ersatz falls der ATMEGA es dann am Ende doch nicht packen sollte.
-
woran scheitert denn das Schreiben auf D64 Files?
Grundsätzlich müssen wir doch nur die GCR-Codierung wieder umdrehen und per FAT-bibliothek auf die SDKarte schreiben, oder?
Im Grunde erstmal nur an meinem Zeitmangel.
Und ja im Grunde nur GCR zurück konvertieren und im D64 ablegen. Das Problem ist aber das das ganze immer für eine komplette Spur geschehen muss, und zwar genau in der Zeit für den Spurwechsel und da könnte es schon zu eng werden für den ATMEGA. Eine Lösung wäre evtl. immer G64 zu schreiben und beim auswerfen diese dann komplett zu d64 konvertieren. -
Leider gibt es noch nicht wirklich neues.
Muss mich wirklich mal am Gummi reißen und mich da wieder rein knien. Habe jetzt noch ein privates Projekt was ich fertig machen muss und dann schaue ich mal was da geht.Ich hatte schon Ideen das ganze auf einem STM32 zu Münzen und dann eine Adapterplatine zu machen die anstelle des ATMEGA's kommt. Oder gar eine 1541-rbuild II die gleich auf STM32 aufbaut. Aber wie gesagt, das sind nur Ideen die mir im Kopf rum schwirren. Ein STM32 hat doch mehr bums als ein ATMEGA. Was haltet ihr davon? Im nächsten Leben hätte ich gerne min. 48h Tage.
-
@ Thorsten... konntest du schon an der Firmeware weiterarbeiten?
Noch bin ich nicht dazu gekommen. Ich bin gerade in den letzten zügen eine neue Version vom Emu64 fertig zu stellen. Danach wollte ich mich erstmal wieder um die 1541-rebuild kümmern.
-
Ja...die Doku war falsch. Wurde das nicht korrigiert? Hatten da schonmal über das "andere links" geredet.
Ja hatte ich damals gleich korrigiert. In der Doku steht es richtig drin.
-
Er hatte getauscht und immer noch Klötzchen. Ist der Quarzoszillator wohl doch hin
Ja o.k. dann könnte er hinüber sein. Aber vorher nochmal am Kontrast drehen, der könnte jetzt noch falsch eingestellt sein!
