Posts by manfred.moser

    Seit längerer Zeit habe ich heute mal wieder an meinem SX64-BareMetal gearbeitet und eine standesgemäße Mini-Tastatur dafür gebastelt:hammer:


    Kurz zur kuriosen "Historie" des Gerätes:

    Den SX hatte ich Anfang des Jahres als "SX64-Sat" erhalten. War ein EKA-Angebot aus der Nähe und ich konnte das Gerät abholen.

    Jetzt das Kuriose: Jemand hatte alle Innereien bis auf Netzteil und Monitor entfernt und stattdessen ein Sat-Receiver eingebaut.:schreck!:


    Muss wohl irgendwann in den 90er- oder 00-Jahren passiert sein, denn es war ein analoger Sat-Receiver.

    Lt. Vorbesitzer sei man mit dem Gerät damals auf dem Dach unterwegs gewesen um Sat-Schüsseln einzustellen.:nixwiss:


    Wie man auf eine so frevelhafte Idee kommen und dem armen SX64 sowas antun konnte, ist mir heute noch ein Rätsel:cry:


    In der Folge habe ich den Sat-Receiver rausgeschmissen und einen Raspi 3B mit BMC64 eingebaut.

    Damit wurde aus dem "SX64-Sat" ein "SX64-BareMetal", der wieder den SX64-Startbildschirm zeigt :D Siehe auch unter heute so gebastelt


    Leider habe ich keine Tastatur zu dem SX64 erhalten, bzw. nur das leere Tastaturgehäuse, damit man den SX64 verschließen konnte.

    BMC64 konnte ich bisher nur mit diversen kabelgebundenen USB-Tastaturen bedienen, die allesamt zu groß für einen Einbau waren.

    Hab diverse Minitastaturen probiert, aber die hatten alle einen Funkdongle. Leider wurden die alle unter BMC64 nicht erkannt.


    Einen Adapter um eine echte C64-Tastatur (mit 20 pol-Pinleiste) und 2 Joysticks mit DB9-Steckern hatte ich auf Lochraster gebastelt und in den SX64-BareMetal eingebaut.

    Aber eine echte C64-Tastatur passte natürlich ebenfalls nicht in den Tastaturdeckel, so dass eine Lösung bisher ausblieb und ich den SX immer mit einer kabelgebundenen USB-Tastatur bedienen musste.

    Bis heute, denn kürzlich erhielt ich von OliverW. einen Platinensatz für ein C64-Mini-Keyboard.:) Danke nochmal für das Vorabexemplar:thnks:

    Dieses wurde mit den Tastern und einem Pinheader bestückt und an den SX64-Tastaturdeckel angepasst und eingebaut.


    Das Mini-Keyboard wurde mit einem gewinkelten Pinheader versehen. :loet

    Da der etwas zu hoch war wurde der Pinheader tiefergelegt, indem der Kunststoffabstandshalter entfernt wurde.

    Jetzt passte ein gerader weiblicher Pinhader darauf und dort dran wurde über Drähte eine DB25-Buchse angebunden.

    Diese musste etwas angepasst werden, damit sie in das vorhandene Loch für den Tastaturanschluss passte und dort befestigt werden konnte.




    Mit FreeCAD hab ich mir ein paar Abdeckungen konstruiert und ausgedruckt um damit die Öffnungen zu verschließen.

    Ist noch nicht perfekt und braucht noch etwas Feinschliff, aber man sieht wie's werden soll.


    Jetzt musste in den SX64 ebenfalls noch eine DB25-Buchse eingebaut und mit dem Keyboardanschluss per Flachbandkabel und Pinheader verbunden werden.

    Ein 25cm kurzes DB25-Stecker zu DB25-Stecker - Tastaturkabel wurde so angepasst, dass es auf auf die Buchsen passte.

    Die Steckerbelegung ist exakt so wie beim Original. Es würde also auch eine Original-SX-Tastatur daran funktionieren.


    Nachdem dies erledigt war kam der Test, ob die Mini-Tastatur am SX64-BareMetal funktioniert.


    ... und ja, das tut sie :juhu:


    Die rechte Abdeckung drucke ich nochmal neu und dann werden die Tastatur und die Abdeckungen mit Heißkleber fixiert.

    Somit ist eine kostengünstige Ersatztastatur gefunden, bei der alle Tasten dort sind, wo man sie bei einem C64 erwartet.


    Auch der Deckel geht zu, das habe ich ausprobiert, zuvor aber noch ein kleines Spielchen gestartet:D


    Viele Grüße

    Manfred

    Es gibt wohl eine spezielle Version fuer den GD32-Prozessor, kann es daran liegen?

    https://github.com/Sgw32/KungFuFlashGD32


    MfG

    Claus

    Danke für den Hinweis, aber daran liegt es nicht. Die von Dir genannte Firmware ist auf Platinen #3 bis #5 aufgespielt.


    Ich hatte zwei STM32F405RTG6 und drei GD32F405RTG6 (China-Clon) gekauft.

    Platinen #1 und #2 haben den STM32-Prozessor erhalten und die laufen mit der aktuellen Firmware V1.48 von kim_jorgensen


    Die Platinen #3-#5 sollten die GD32-Prozessoren erhalten und die speziell an den GD32-Prozessor angepasste Firmware (basiert auf V1.41).

    Mit Platine #3 läuft die auch gut. Siehe auch unter heute so gebastelt


    Nur die beiden Platinen #4 und #5 wollen nicht.

    Meine drei kürzlich gebastelten KungFuFlash - Platinen in ein Gehäuse eingebaut und ein Label aufgeklebt:hammer:


    Dann noch die Platinen #4 und #5 mit GD32-Prozessor aufgebaut und programmiert.


    Komischerweise laufen #4 und #5 nicht und ich kann den Fehler nicht finden.:honk:


    #4 startet, aber erkennt keine SD-Card.

    Die Verbindungen zur SD-Kartenhalter wurden durchgemessen, waren alle gut. Andere SD-Karte probiert, hat nichts genutzt.

    SD-Kartenhalter wurde ausgelötet und durch einen neuen ersetzt. Alle Pins am GD32-Prozessor geprüft und nachgelötet.

    Hat alles nichts genutzt. Weiterhin wird keine SD-Karte erkannt.


    Bei #5 erhalten ich einen Blackscreen. Die startet gar nicht.

    Alle Pins am Prozessor geprüft und nachgelötet. Eine Seite am Quarz war nicht angelötet. Das nachgeholt, aber weiterhin Blackscreen.

    Auch die Lötstellen an den Widerstandsnetzwerken nochmal genau unterm Mikroskop angeschaut, nachgelötet und druchgemessen.

    Leider weiterhin Blackscreen.


    Beide Platinen wurden testweise auch mal an einem anderen C64 (Brotkasten mit 425er-Assy) angesteckt. Mit demselben Ergebnis.


    Ich vermute die GD32-Prozessoren sind beide defekt.:nixwiss: Hab jetzt STM32 - Prozessoren bestellt. Wenn die neuen da sind löte ich die ein.


    Beim ersten Versuch die GD32-Prozessoren zu programmieren ist mir ein Malheur passiert.

    Ich hatte zunächst GND und SWDIO vertauscht gehabt. Kann mir aber nicht vorstellen, dass die deswegen defekt geworden sind.

    Sobald richtig am ST-Link-Adapter angeschlossen hat die Programmierung mit der speziellen GD32-Firmware dann auch sofort geklappt.

    Aber vielleicht haben die beiden GD32-Prozessoren dabei doch Schaden genommen, oder waren vorher schon defekt?:nixwiss:


    Die Platinen #1 und #2 mit STM32-Prozessor laufen hingegen perfekt und mit aktueller Firmware 1.48.


    Ich kann berichten, dass Platine #3, die mit GD32-Prozessor bestückt ist, ebenfalls perfekt läuft.

    Hab inzwischen damit einige Tests damit gemacht und alle Features bis zur Firmware Version 1.41 laufen. Auch die EasyFlash-CRT-Dateien. Ob USB geht hab ich nicht getestet.

    Einzig neue Features und Bugfixes die seit V1.41 bis V1.48 geändert wurden sind nicht realisiert (z.Bsp. dass man inzwischen auch generische BIN-Dateien starten kann) und funktionierten mit der speziell auf den GD32-Prozessor angepassten Firmware nicht, aber das ist jammern auf sehr hohem Niveau.

    Heute mal drei KungFuFlash aufgebaut:hammer:


    Zuerst die Teile zusammengesucht


    Dann unterm Mikroskop den ersten STM32-Prozessor und die beiden Widerstandsnetzwerke aufgelötet:loet


    Anschließend das Hühnerfutter und die restlichen Teile:)


    Da ich nur zwei STM32F405RTG6 - Prozessoren und drei China-Clone GD32F405RTG6 habe wurden erst mal nur drei Platinen fertiggestellt.

    #1 und #2 erhielten den STM32-Prozessor und #3 einen der GD32-Prozessoren.

    Wer genau hinschaut, wird bemerken, dass die Chinesen es beim GD-Prozessor nicht mal geschafft haben den Pin1 zu kennzeichnen.:nixwiss:

    Aber anhand der Beschriftung hab ich den dann so aufgelötet, wie die STM-Prozessoren und das hat auch gepasst, wie sich später herausgestellt hat.:puhh:


    Bevor ich #4 und #5 bestücke, wollte ich erst mal sehen, wie sich #3 mit dem GD-Prozessor programmieren lässt und wie der so läuft.

    Alle drei Platinen wurden über das ST-LINK Utility mit der Firmware versorgt.

    #1 und #2 mit der aktuellen V1.48 von kim_jorgensen 's GitHub-Seite


    #3 mit dem GD-Prozessor wurde mit der Firmware V1.41 von dieser GitHub-Seite geflasht.

    Der GD-Prozessor wurde lustigerweise seitens ST-Link Utility als STM-Prozessor erkannt undauf Anhieb problemlos geflasht.


    Jetzt war ich natürlich gespannt, ob die drei Kanditaten laufen würden.

    Es stand mal wieder der Firstrun an.

    ... und Hurra... Ja... alle drei liefen auf Anhieb, auch #3 mit dem GD-Prozessor.:juhu:


    Der Nachteil des GD-Prozessors sei nicht verschwiegen. Z.Zt. gibt es nur die speziell auf den GD-Prozessor angepasste Firmware mit Stand V1.41.

    Alle Neuerungen die kim_jorgensen danach eingebaut hat, funktionieren mit dieser Firmware nicht.

    Dafür ist der GD-Prozessor mit knapp über 2 Euro pro Stück sehr günstig. Und Firmware V1.41 kann schon viel. Für Otto-Normal-C64-User wie mich reicht das:D


    Da bis hierhin alles problemlos läuft, sind jetzt dann noch die Platinen #4 und #5 mit GD-Prozessor aufzubauen. Aber morgen ist ja auch noch ein Tag:saint:

    Und natürlich wollen die KungFuFlash-Platinen auch noch ein Gehäuse haben.

    Das erste ist schon (fast) fertig. Die Knöpfe fehlen noch. Aber der 3D-Drucker läuft...


    Viele Grüße

    Manfred

    Hab mir jetzt mal 10 Platinen bei PCBWay bestellt und dabei bei "Shipping" extra drauf geachtet, dass PCBWay gleich die Steuern einbehält und die günstigste Versandart gewählt.

    Hoffe dass dadurch keine weitere Kosten mehr dazu kommen und es beim Zoll keine Schwierigkeiten gibt.


    Die 10 Platinen und noch 10 weitere von einem anderen Projekt haben incl. Steuern und Versandkosten 22,57 Euro gekostet.

    Wenn es dabei bleibt kann man nicht meckern, finde ich.


    Und Frenetic bekommt auch einen kleinen Obulus davon ab. Das hat er sich auch wirklich redlich verdient:thumbsup:


    Frenetic :

    Vielen Dank für das tolle Stück Hard-/Software.:thnks:

    Bin gespannt:D

    Nachdem gestern der nachbestellte STM32F105RBT6 ankam, hab ich heute abend noch schnell die unvollendete FlashFloppy #9 fertiggestellt.:hammer:


    Die konnte wegen eines defekten Prozessors beim letzten FlashFloppy-Batch nicht fertiggestellt werden.

    Die Teile warteten unterdessen in einer Ziptüte.


    Also frisch ans Werk.

    Erst unter dem Mikroskop den Prozessor aufgelötet, diesen dann mit der Firmware versorgt.

    Hat mit einem temporär angeschlossenen Resettaster geklappt.


    Dann die THT-Teile hergerichtet und aufgelötet. :loet


    Anschließend das ganze ins Gehäuse verfrachtet und ein Label aufgeklebt.

    Sieht jetzt so aus.


    Auf dem Tisch wartete der A500, der heute morgen den PiStorm erhalten hatte zum Test.

    Hat auf Anhieb funktioniert.:juhu:Lediglich die LED hatte ich mal wieder falsch rum drin. OK das ist keine große Sache.. die wird noch umgedreht.


    Zur Kontrolle dass alles ordnunggenäß funktioniert noch ein Lese- und ein Schreibtest mit dem ATK durchgeführt.

    Bestanden und voll funktionsfähig:D

    Gestern und heute die erste von den kürzlich von JLCPCB angekommene PiStorm-Platine verbaut:hammer:


    War das erste mal, dass ich zwei Platinen bestückt bestellt hatte.

    Die vier Bustreiber und der CPLD wären nicht leicht von Hand zu löten gewesen:schreck!:

    Was noch gefehlt hatte waren die Pinheader für den 68000er-Sockel und für den Raspi. Sonst war alles drauf, was man braucht.

    Die waren recht schnell ergänzt:loet


    Den Pinheader für den Raspi hab ich noch vor dem Einlöten schräg gefeilt, damit der Raspi nachher unter die Tastatur passt.

    Dann den Raspi Zero 2W mit einem Kühlkörper versehen und aufgesteckt. Anschließend in einen meiner A500 eingebaut.


    Diesmal ist genügend Platz unter der Tastatur geblieben.


    Jetzt musste das PiStorm-System installiert werden.

    Beim letzten mal hab ich das noch alles von Hand gemacht. Siehe auch unter heute so gebastelt.


    Diesmal war ich faul und hab einfach die SD-Karte von meiner ersten Installation mit dem USB-Image-Tool geclont.

    Ging schnell und einfach. Die geclonte SD-Karte hab ich in meiner ersten Installation kurz gecheckt. Ja... hat einwandfrei geklappt.


    Bevor man den PiStorm in Betrieb nehmen konnte musste nun noch der CPLD geflasht werden.

    Das hatte bei meiner ersten Installation nicht geklappt, weil das aktuelle openocd den CPLD nicht erkannte. Beim ersten PiStorm war das aber nicht nötig, weil ich den schon geflasht bekommen hatte.


    Nun aber musste das zwingend durchgeführt werden, weil der CPLD von JLCPCB natürlich noch jungfräulich war.:)

    Dank des Tipps von venice12 (Danke nochmal:bussi:) wurde mittels sudo apt-get install openocd=0.11.0~rc2-1 eine andere Version installiert, die den CPLD erkannte und auf Anhieb erfolgreich geflasht hat.:juhu:


    Leider lief der A500 aber nicht hoch und ich war zuerst etwas ratlos.:gruebel

    Nach endlosen Versuchen hab ich dann irgendwann auf den normalen 68000-Prozessor zurückgerüstet.

    Doch oh Shreck :schreck!:, damit lief der A500 auch nicht mehr. Hatten meine PiStorm-Experimente irgendwas kaputt gemacht?:nixwiss:


    Erst mal hab ich den A500 etwas frustriert zur Seite gestellt...:cry:

    ... gestern abend dann nochmal auf Fehlersuche gegangen. Wollte schon Chips von einem anderen A500 quertauschen, da habe ich gemerkt, dass der Garyadapter für die 2,5MB-PeteAU-Speichererweiterung halb aus dem Sockel gerutscht war.

    Den Garyadapter wieder fest in den Sockel gedrückt und der A500 lief wieder:puhh:


    Heute morgen dann den PiStorm wieder eingebaut und probiert.

    Zuerst hat er nicht funktioniert und der Buptest hat lauter Fehler rausgehauen.

    Dann den PiStorm nochmal fest in den Sockel gedrückt und plötzlich hat der A500 gestartet.:woot:

    Die Workbench 3.2 erschien.:applaus:


    Dann noch etwas mit der WHD-Load-Installation experiementiert.

    Bei meinem ersten PiStorm-A500 hatte das wegen einer Fehlermeldung von RawDIC immer fehlgeschlagen.

    Jetzt mit dem PiStorm#2 hab ich mal auf die Standard-PAL-Auflösung zurückgeschaltet und plötzlich lief die WHD-Installation des Spiels R-Type durch und das Spiel startete:roll2:


    Super. Endlich hab ich meine WHD-Load-Maschine...:)

    Jetzt werden Spiele installiert. HD-Platz, RAM und Speed sind im Überfluss vorhanden :D

    Heute morgen schnell mal zwei Modulator-Ersatzschaltungen aufgebaut :hammer:


    Die Platinen hatte ich mal hier im Marktplatz von einem Forumskollegen erworben. Ist schon etwas länger her.

    Die sind mir kürzlich wieder in die Hände gefallen und da dachte ich, baust die mal auf. Haben ist schließlich immer besser als brauchen.:D


    Das besondere an diesem Modulatorersatz ist der S-Video- und Audioausgang. Wer eine Stereo-SID-Lösung eingebaut hat, kann den rechten Kanal an einem Pinheader einspeisen.

    Optional zur 3,5mm-Audiobuchse kann auch ein Resettaster eingebaut werden. Eine EXROM-Resetschaltung kann optional bestückt werden.

    Wenn die Audiobuchse bestückt ist, kann man den Resettaster auch extern über einen Pinheader anschließen.


    Das Projekt ist vom RetroChannel auf Github zu finden.


    Zuerst die Teile zusammengesucht.

    War alles Standard... Transistoren, Widerstände, Kondensatoren, Dioden. Sollte in jeder gut sortierten Bastelkiste zu finden sein, so auch bei mir.:D


    Dann die beiden Platinen bestückt und zusammengelötet:loet

    Sieht jetzt so aus.


    Hab beide Platinen mit der 3,5mm-Klinkenbuchse für Audio bestückt.

    Den Exrom-Reset hab ich trotzdem bestückt, da kann man ja ggf. mal einen externen Taster anschließen.


    Abweichend wie eigentlich vorgesehen, hab ich einen zusätzlichen internen Resettaster bestückt.

    Falls man am Board mal arbeiten muss ist ein Resettaster praktisch, dachte ich:)


    Wer nur S-Video nutzen will, kann das Compositesignal über einen Jumper komplett abschalten. Der Entwickler verspricht sich davon weniger Störungen.

    Wenn man das Composite einschaltet kann man über einen Trimmerkondensator von 120pF einstellen wieviel Chroma ins Lumasignal eingemischt wird.

    Ich hatte keinen 120pF-Trimmer da, der größte verfügbare war ein 70pF-Exemplar. Deshalt hab ich auf der Unterseite noch ein 56pF-Kondensator parallel geschaltet.

    Somit ist die Einstellspanne zwischen 56pF-126pF.


    Viele Grüße

    Manfred

    Heute meinen A500#1, in den ich kürzlich den PiStorm eingebaut habe, einen reversiblen HDMI-Ausgang eingebaut:hammer:


    Zusätzliche Schwierigkeit war die Bauhöhe des PiStorm mit dem Raspi Zero 2W.

    Das Konstrukt hat nämlich wegen wenigen Millimetern nicht unter die Tastatur gepasst.:wand


    Oder anders gesagt, die Oberschale vom Amige lies sich nicht mehr schließen, weil die Tastatur zu hoch stand und außerdem bestand Kurzschlussgefahr, wenn die Rückseite der Tastatur auf dem Raspi aufliegt.


    Wie gesagt, es haben nur ein paar Millimeter gefehlt.

    Den notwendigen Platz hab ich mir verschafft, indem die Pinheader von Raspi und PiStorm-Platine leicht modifiziert wurden.

    Ein Bild sagt mehr als Tausend Worte:)


    Danach war es zwar immer noch knapp, aber die Oberschale ließ sich nun einwandfrei schließen.


    Nun konnte ich den HDMI-Anschluß einbauen:hammer:

    Dabei kam dieselbe Vorlage zum Einsatz, die ich auch kürzlich für meinen anderen A500#2 mit RGB2HDMI-Platine verwendet hatte.


    Deckel zu - der schließt nun vollstndig - und zugeschraubt...

    ... der PiStorm - Amiga ist nun mit dem HDMI-Anschluß voll einsatzfähig:thumbsup:


    Läuft superflink und bisher problemlos. Bin echt zufrieden mit der Lösung:)

    Dem kürzlich mit einem RGB to HDMI - Adapter ausgerüsteten Amiga A500#2 einen reversiblen HDMI-Ausgang spendiert:hammer:


    Ich wollte für den HDMI-Ausgang kein Loch in das Gehäuse machen, da bin ich kein Freund von...:abgelehnt

    ... deshalb hab ich von Printables dieses Gehäuse gedruckt und mithilfe des kürzlich angekommenen HDMI-Adapters den Ausgang am A500 realisiert.:)




    Dann mal die WB und ein paar Spielchen geladen.... macht schon ein klasse Bild.:thumbsup:

    Den Ton lasse ich halt jetzt über die Stereoanlage laufen, der wird bei dieser Lösung leider nicht mit ins HDMI-Kabel eingespeist.




    Heute den kürzlich angekommenen "C64/VIC20 to PS2 Keyboard-Adapter" zusammengebastelt:hammer:

    Die Platine hat mir 1570 zugeschickt, der das Projekt auch schon nachgebaut hatte. Danke nochmals:thnks:


    Das Projekt ist auf dieser Seite beschrieben.


    Viel musste man nicht löten.

    Zwei 28pin-Sockel (breit und schmal), ein Kondensator, ein Widerstand, eine LED, die PS2-Buchse und den 20poligen Pinheader (von unten auf die Platine):loet


    Lt. Schaltplan kann man ATMegas 48/88/168 oder 328 verwenden.


    Da ich einen lange ungenutzten ATMega48 liegen hatte, dachte ich, kannst Du den endlich mal einer sinnvollen Verwendung zuführen.

    Also flugs die hex-Datei auf o.g. Projektseite in den ATMega48 programmiert und dann in den Sockel gesteckt.


    Jetzt stand mal wieder der Firstrun an.

    Also einen C64-Brotkasten mit 250425er-Board geöffnet und die Tastatur abgesteckt.

    Dann die Platine auf den Keyboard-Pinheader aufgesteckt und probiert.


    Leider war der erste Versuch nicht erfolgreich. :nixwiss:

    Erstens hatte ich eine alte PS2-Tastatur erwischt, die defekt war und es allein schon deshalb nicht funktionieren konnte.

    Dann eine andere PS2-Tastatur von der ich wusste, dass sie in Ordnung war angesteckt....

    .... aber außer dass die blaue LED bei jedem Tastendruck geblinkt hat, tat sich nichts auf dem Bildschirm. :gruebel


    Also gut, dann eben doch einen der guten ATMega328 programmiert und damit probiert.

    Und Hurra:juhu:... jetzt funktionierte es. Die Tastendrücke wurden in Zeichen auf dem Bildschirm umgesetzt, so wie es sein soll.:thumbsup:


    Wenn ich die Projektseite von Anfang an richtig gelesen hätte, wäre mir vielleicht gleich aufgefallen, dass dort von "pre comiled File for atmega328 avr" die Rede war:unschuld::schande:

    Viele Grüße

    Manfred

    Gestern und heute mal meine schon vor einiger Zeit angekommene PiStorm-Platine im A500#1 in Betrieb genommen:hammer:


    Wollte ich schon länger mal machen, aber die Softwarekonfiguration ist doch einigermaßen komplex.

    Und so habe ich fast einen ganzen Tag nur mit Recherche im Netz verbracht, ehe ich einen Raspi Zero 2W mit einem SD-Kärtchen bestückt habe.


    Vor allem die Github- und Wiki-Seite von Captain-Amygdala

    und diese Video von FrankyByte haben mir sehr bei der Installation geholfen.



    Vielen Dank dafür an FrankyByte :thnks: So wie Du es in dem Video gemacht hast, hab ich es nun im wesentlichen auch eingerichtet.:thumbsup:


    Zuerst hab ich mit dem Raspberry Pi Imager eine 16GB - MicroSD-Karte eingerichtet.

    Schön ist, dass man da einige Sachen schon im Imager einstellen kann, bevor der Raspi das erste mal bootet.

    Das betrieft so Einstellungen wie User und Passwort, deutsche Tastaturbelegung, WLAN-SSID und Passwort, und am wichtigsten... den SSH-Zugang aktivieren.


    SD-Karte dann in den Raspi gesetckt und diesen an einem 3A-Netzteil mit Strom versorgt....

    ... nach kurzer Zeit konnte ich vom PC aus mit Putty auf den Raspi zugreifen, mich dort anmelden und die weiteren Intallationen starten.:)

    Hab nicht ein einziges Mal eine Tastatur oder Maus an den Raspi angeschlossen... es ging alles über Putty vom PC aus. Sehr angenehm:)


    Nachdem die ersten Installationen durchgeführt und die per git gezogenen Sourcedateien mit "make" übersetzt waren,

    kam erst mal die Hardware-Installation in meinem Amiga A500#1


    A500 geöffnet, die CPU aus dem Sockel gezogen und die PiStorm-Platine stattdessen in den CPU-Sockel installiert.

    Dann den Raspi mit der vorbereiteten SD-Karte aufgesteckt.


    Jetzt den Amiga eingeschaltet und vom PC aus per Putty openocd instlliert, was auch geklappt hat.

    Lt. Installationsanleitung wäre als nächstes eigentlich ein Update des CPLDs mit "./flash.sh" dran gewesen, aber es kam die Meldung, dass kein CPLD gefunden wurde.:nixwiss:

    Habs mehrfach versucht, aber ohne Erfolg.


    Schon etwas desillusioniert nochmal ein Reboot gemacht.... und was soll ich sagen... der Amiga Kickstart 1.3 Startbildschirm erschien. :woot:

    Hurra... die Installation hat offensichtlich also auch ohne CPLD-Update geklappt.:juhu:


    Jetzt die ATK-Diskette reingeschoben und der ATK-Bildschirm erschien. Von zusätzlichem Fastram war aber nichts zu sehen.

    Nur meine PeteAU-Memoryerweiterung auf 2,5 MB (war vorher schon eingebaut) war zu sehen. Und schnell kam mir die Kiste auch nicht vor.

    Dann mal die WB1.3 Diskette und ein Spiel gebootet... hat auch funktioniert.

     


    Wie sich herausgestellt hat gab es im Verzeichnis Pistorm auf der SD-Karte vom Raspi keine default.cfg in der eigentlich alle Einstellungen gemacht werden.

    Also hab ich mal die dort vorhandene amiga.cfg zu default.cfg kopiert und nochmal probiert.

    Jetzt wurde im ATK schon eine 68020-CPU angezeigt, aber er bootete immer noch mit KS1.3 und ohne Fastram.


    Nach dem o.g. Video von FrankyByte weitergemacht und Autostart und eine myconfig.cfg erzeugt.

    Dort Kickstart 3.2 und zwei virtuelle HDF-Festplatten auf der SD-Karte freigeschaltet.

    Nach einem Reboot fühlte sich der Amiga schon schneller an, was mit SysInfo auch bestätigt wurde.

    Dummerweise hatte ich in dem Zwischenschritt vergessen das KS32.rom ins richtige Verzeichnis zu kopieren, so dass er wieder mit KS1.3 startete.

    Jetzt noch die KS32.rom kopiert und wieder neu gestartet... und hui... der PiStorm mutierte zur Rennmaschine.


    Jetzt wurde AmigaOS 3.2 von einem meiner externen FlashFloppys auf die virtuelle Festplatte installiert. Das ging recht flott...

    Inzwischen war ja auch 128MB Fastram verfügbar und der virtuelle 68020 lief wie am Schnürchen.


    Weiter gings mit der A314 Emulation. Damit kann nun direkt aus dem AmigaOs heraus der Raspi über das neue Kommando "pi" wie von der Kommandozeile aus gesteuert werden.

    Z.Bsp. mit "pi reboot" wird neu gestartet (der rasend schnell geht... in gefühlt 10sec sitzt man wieder vor der neu gestarteten Workbench):)


    Und es konnte nun ein Shared-Laufwerk gemountet werden, wo alle Inhalte, die man vom PC aus über Filezilla per SFTP in ein bestimmtes Shared-Verzeichnis auf dem Raspi schiebt, dann auch von AmigaOS aus zugreifen. Sehr praktisch grade bei der Einrichtung von weiterer Amiga-Software.


    Bis hierhin lief der PiStorm eigentlich schon recht gut, aber die Bildausgabe ging immer noch über die Standard-Denise und DB23-RGB-Ausgang.

    Deshalb kam jetzt die RTG - Installation.

    Damit wird eine virtuelle Grafikkarte installiert, mit der die Ausgabe auch höherer Auflösungen über den HDMI-Anschluss vom Raspi ermöglicht wurde.

    Diese Installation hatte einige Hürden bis ich zufrieden war. Insbesondere fand ich keine zufriedenstellende Auflösung, die unverzerrt und ohne Overscan funktionierte.


    Das Bild mit 1280x720 Punkten war zu groß und sowohl oben und unten, als auch links und rechts wurden Bildteile abgeschnitten.

    Das war auch bei anderen probierten Auflösungen so und mit dem Picasso96-Tool konnte ich auch keine vernünftige Einstellung bekommen.


    Die Lösung für dieses Problem fand ich in einem anderen Video, bei dem in der /boot/config.txt vom Raspi einige Einstellung bezüglich Overscan und Bildrändern angepasst wurden.


    Musste einige Testläufe durchgehen bis ich zufrieden war, aber am Ende kam diese tolle Auflösung zu Stande.:thumbsup:


    Denke so kann man das lassen:D


    Was mich jetzt noch ein bischen stört, ist dass einige Anwendungen und viele Spiele trotzdem in der Standardauflösung am RGB-Ausgang erscheinen.

    Z.Bsp. ATK und SysInfo sind so Kandidaten.

    Weis einer, wie man die als Fenster auf dem hochauflösenden HDMI-Ausgang bekommt? Oder ist das gar nicht möglich?:nixwiss:

    Aber irgendwas ist ja immer:nixwiss:


    Fürs erste bin ich mal zufrieden.

    Der Amiga ist zur Rennmaschine geworden, startet die WB3.2 von der sehr schnellen Festplatte, hat jede Menge Fastram und hat eine tolle Bildausgabe.:thumbsup:


    Nächste Schritte werden sein.

    Das Netzwerk einzurichten, die Tonausgabe über HDMI und dann was ich schon immer mal machen wollte. Games über WHD-Load:D

    Heute passend zu den externen FlashFloppys von gestern nochmal fünf OpenDriveSwitcher und OpenMouseTrigger gebastelt:hammer:


    Zuerst die Teile zusammengesucht... Platinen hatte ich noch vorrätig.

    Die DL074 sind - soweit ich weis - DDR-Nachbauten der 7474-FlipFlops gewesen.

    Davon hab ich noch jede Menge auf Vorrat. Gabs - glaub ich - mal bei Pollin vor vielen Jahren als Restposten zum Spottpreis. Für den MouseTrigger sind die perfekt.


    Dann alles zusammengelötet, die ICs wurden dabeo ohne Sockel direkt eingelötet:loet

    Ist recht easy aufzubauen. Man braucht aber die guten (teuren) vergoldeten runden Pinheader, damit der Originalsockel im Amiga geschont wird.


    ... fast vergessen. Zum Schluß noch gewinkelte Pinheader für den Jumper aufgelötet. Damit wechselt man zwischen Normal und Swap-Betrieb.

    Optinal kann da ein Umschalter angeschlossen werden, oder man macht es Schalterlos über den MouseTrigger.


    Der DriveSwitcher tauscht DF0 (internes Laufwerk) und DF1 (externe Floppy) um.

    Damit wird das externe Laufwerk zu DF0 und das interne Laufwerk wird DF1. Hab ich ausprobiert, funktioniert.

    Der Hauptvorteil ist jedoch, dass man so vom externen Laufwerk booten kann.:)

    Somit die ideale Ergänzung zu meinen externen FlashFloppys.


    Passend dazu gibt es den MouseTrigger, mit dessen Hilfe man kein Schalter für die Umschaltung mehr braucht (das vermeidet unschöne Löcher im Gehäuse:D).

    Bei meinen A500 liegen die am Pin 6 der DB9-Buchse (bzw. an EMI-Filter 415 angelötet) vom Mouseport.

    Wenn man mit gedrückter linker Mousetaste den Amiga einschaltet, werden die Laufwerke getauscht. Das überlebt auch einen Reset mit Amiga-Amiga-Ctrl.

    Erst wenn der Amiga ausgeschaltet wird und ohne gedrückte Mousetaste wieder gestartet wird, sind die Laufwerke wieder im Normalbetrieb.


    Der Mousetrigger bietet noch eine zweite Umschaltmöglichkeit (kann z.Bsp. zum Umschalten des Kickstarts genutzt werden).


    Hier ein Bild vom Einbau in einen meiner A500.

    Wie gesagt, so braucht man kein Loch für einen Umschalter ins Gehäuse zu bohren.:thumbsup:

    Hatte heute auch viel Arbeit bei mir... aber ist ja Hobby und macht auch Spaß:D

    Von 13:00 Uhr angefangen und bis fast 23:00 Uhr gebraucht....


    Nochmal 5 Amiga Flashfloppys als externe Gotek-Laufwerke gebastelt:hammer: ... Na ja fast... denn es sind erst mal nur 4 Stück davon fertig.


    Erst die Teile rausgesucht, hatte noch 5 Platinen übrig.


    Die STM-Prozessoren unterm Mikroskop aufgelötet. Hab inzwischen Übung und das geht eigentlich recht flott.:)


    Danach das Hühnerfutter, das meiste in 0603 und die LS07 und den 3,3V-Regler.

    Das braucht dann doch etwas Zeit, weil alles an den richtigen Platz muss und die kleinen Dinger erst mal sortiert und bereitgelegt werden wollen.

    Wehe wenn mal einer von der Pinzette hüpft... den sieht man meist nie wieder...


    Jetzt die STM-Prozessoren mit der Firmware versorgt.

    #6 und #10 gingen auf Anhieb, waren aber Schreibgeschützt. Mit dem ST-Link Utility kann der aber problemlos aufgehoben werden.

    #7 und #8 wollten sich zuerst nicht Connecten. Ein Resettaster half. Erst Reset drücken und halten, dann auf Connect klicken, dann Reset loslassen.

    Jetzt wurde die Verbindung hergestellt und man sah, dass wohl schon irgend ein Programm im STM-Prozessoer drin war. :nixwiss:

    Egal... mit der FlashFloppy-Firmware 3.41 überschrieben.:)


    Bei #9 gab es Probleme. Mein ST-Link-Stick wurde am USB nicht mehr erkannt, sobald ich Platine #9 angeschlossen hatte. Komisch, was war das:gruebel

    Hab dann mal nachgemessen und gemerkt, dass ein satter Kurzschluß von +3,3V nach GND bestand. Was konnte das sein?

    Als erstes alle Lötstellen penibel auf eventuelle Lötbrücken kontrolliert, konnte aber keinen Lötfehler finden.


    Hatte dann den AMS1117-Regler in Verdacht und ausgelötet. Der Kurzschluß bestand weiter.

    Im Schaltplan geschaut... vielleicht hatte ja einer der vielen Entkoppelkondensatoren einen kurzen? Hatte ich bei SMD zwar noch nie, aber man kann ja nie wissen.

    Also einen nach dem anderen runtergelötet. Hat aber nicht geholfen.

    Als nächstes den LS07 auch noch ausgelötet. Immer noch Kurzschluß.


    Nachdem alle anderen Möglichkeiten ausgeschlossen waren, musste auch noch der STM-Prozessor ausgelötet werden und Bingo, jetzt war der Kurzschluß weg.

    Hab den Kollegen dann unterm Mikroskop mit feinen Prüfspitzen vermessen und tatsächlich... zwischen dem Vss und Vdd - Anschlüssen war der Kurzschluß.

    Somit brauchte ich nicht mehr weitersuchen. Der STM-Prozessor war defekt. Ausgerechnet das teuerste Teil :honk:... aber gut zumindest war der Fehler gefunden.

    Die Platine #9 und die noch nicht bestückten Teile dafür erst mal auf die Seite gelegt. Die muss auf einen neuen STM-Prozessor warten.


    Also mit den Platinen #6-#8 und #10 weitergemacht. Jetzt waren die die THT-Teile dran.

    Widerstandsnetzwerke, DIP-Schalter, USB-Buchse, LED, Pinheader und Rotaryencoder wurden bestückt. Zum Schluß die DB23-Stecker und schließlich das OLED-Display.


    Jetzt waren die zum Firstrun bereit. Einen USB-Stick angeschlossn mit ein paar ADF-Dateien drauf.

    An meinen A500 mit DriveSwitcher angeschlossen, so konnte man auch vom externen Floppy-Anschluß direkt ins ATK booten.

    Einen Readtest und eine Writetest gemacht... was soll ich sagen... alle 4 liefen auf Anhieb perfekt:juhu:


    Jetzt noch in die zwischenzeitlich gedruckten Gehäuse eingebaut und mit einem Label versorgt.

    Fertig sind wieder vier weitere externe FlashFloppys, nachdem die zuletzt gebauten an liebe Forumskollegen abgegeben wurden.


    Nur Platine #9 konnte ich mangels einem heilen STM-Prozessors nicht fertigstellen. Also geht mal wieder eine Bestellung raus:)

    Da alles schon vorbereitet ist, dürfte der dann recht schnell komplettiert werden können.:D

    Heute zwei der neuen XMas-Bäumchen aus der Sammelbestellung von OliverW. gebastelt.:hammer:


    Verwendet wurden für die Logic-ICs 74HC02 und 74HC273 und jeweils ein Amic A29040B - 512kB (4MBit) Flashspeicher.

    Nach der Programmierung mit der 512kB großen XMAS 2023 Collection von CapFuture1975 des Flashbausteins wurden die ICs mit Labeln von Rob64 beklebt.

    Auf der Rückseite, die auch sehr schön ist, wurden die Jumper entsprechend gesetzt.


    #1 wurde mit SMD-LEDs bestückt rot, gelb, grün für die Kerzen und weiße als Sterne in der Mitte des Baums.


    #2 mit langsam blinkenden 3mm-LEDs für die Kerzen und blau, grün, rot für die Sterne.

    Für die rote Nase von Rudolph natürlich eine schneller blinkende rote LED:)

    Anfangs haben alle langsam blinkende LEDs noch dieselbe Farbe, aber mit der Zeit driften die auseinander und er ergeben sich schöne Farbeffekte:D


    Jetzt wurden die beiden Bäumchen im C64 gestestet. Liefen beide auf Anhieb:juhu:



    Zu sehen sind auch drei Bäumchen der 2022er-Version (davon die Rechte ist die Spezialversion für bzw. von axorp)

    Die neuen 2023er-Version ist deutlich größer als die 2022er. Sind aber alle wunderschön geworden.:)

    Vielen lieben Dank an alle beteiligten OliverW. , CapFuture1975 , Rob64 und axorp für die Vorjahresspezialversion :thnks:


    Hier ein kleines Video im Betrieb. Achtet auf die rote Nase von Rudolph und auf das Farbwechselspiel der langsam blinkenden 3mm LEDs:)


    [External Media: https://youtu.be/EraeNnxlIg0]


    Weihnachten kann kommen:weihnachten:

    Ist schon ein paar Wochen her, als ich mit dem A500 8MB IDE-Adapter angefangen habe. Siehe unter heute so gebastelt

    Bin heute einen großen Schritt weitergekommen, aber um es vorweg zu nehmen... bisher läuft der Adapter leider noch nicht:gruebel


    Seither hab ich immer mal wieder versucht den CPLD programmiert zu bekommen.

    Zuerst hab ich versucht den Chip über einen USB-Blaster und ältere Quartus II Software (Version 9.1 SP2 WebEdition) zu programmieren.

    Konnte das Projekt zwar neu übersetzen und eine Programmierdatei mit der Endung .pof erzeugen, leider wurde der Chip im Programmierdialog aber nicht erkannt, da konnte ich machen was ich wollte. Ob der China-Clon des USB-Blaster in Ordnung ist, kann ich auch nicht gesichert sagen.

    Dann dachte ich ein Taktsignal fehle vielleicht und hab einen Quarzoszillator angeschlossen. Hat aber auch nichts genutzt.


    Kürzlich hab ich im GitHub-Projekt die Issue-Seite entdeckt. Und dort äußert sich der Autor Oleg Mishin zur Programmierung.

    Heute hab ich die Zeit gefunden mich mal näher damit auseinanderzusetzen.

    Programmiert wird über OpenOCD und nicht mit der Altera-Software.

    Im letzten Beitrag auf o.g. Issue-Seite empfiehlt ein Anwender über einen FTDI 232H - Adapter zu programmieren statt über USB-Blaster.


    Da sind bei mir Erinnerungen an die Programmierung des ATF1504 bei der FE3 für den VC20 wach geworden. Der wurde auch über OpenOCD programmiert.

    bigby hat in seinem Hackup.net einen äußerst hilfreichen Artikel dazu veröffentlich.


    Mit diesen ganzen Infos hab ich den CPLD nach mehreren Versuchen über den FTDI 232H-Adapter letzlich programmiert bekommen.


    Erschwerend kam hinzu, dass ich nicht den eigentlich vorgesehenen ATF1508AS/ASV (TQFP-100), sondern den optionalen EPM7128STC100/STI100 auf meiner Platine verwendet habe.

    In der SVF-Datei musste ich deswegen ein paar Änderungen bei den TDO-Zeilen vornehmen, bis endlich die Programmierung fehlerfrei durchgelaufen ist.

    Zuerst brach die Programmierung bei erreichen einer TDO-Zeile mit TDO-Check-Error immer ab.


    Error: tdo check error at line 1932

    Error: READ = 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000

    Error: WANT = 0x0083234cb204c13add7f0000000000000000000000000000000000000000000000000000000000003f

    Error: MASK = 0x3fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff


    Hab die TDO-Zeilen in der SVF-Programmierdatei dann einfach gelöscht, dann lief die Programmierung bis zum Ende durch.

    Vermutlich war das keine so gute Idee, aber anders brach die Programmierung immer an derselben Stelle ab.


    Hier der Programmierlog nach Löschung der TDO-Zeilen: Log#5_success.txt


    Nachdem das geschafft war, wurden die fehlenden Pinheader für die IDE-Schnittstelle und die Spezialpins für den Prozessorsockel eingelötet:loet

    Das macht mir deutlich weniger Probleme, als die Software-Sachen. Bin halt mehr der Hardware-Guy:D


    Jetzt war der Test im A500#2 angesagt (der hat kürzlich auch eine HDMI-Schnittstelle erhalten)

    Die 68000-CPU wurde aus dem Sockel genommen und dort stattdessen der Adapter eingebaut. Die CPU kam wieder oben drauf.

    Leider hatte ich beim eindrücken der 64-pinnigen CPU den Pin31 abgedrückt :honk:, die musste deshalb nochmal raus und Pin31 wieder gerichtet werden.

    Hat im zweiten Versuch dann aber geklappt.:)


    Dann noch den CompactFlash-Adapter an die IDE-Schnittstelle angesteckt und die Verbindungen zu den Anschlüssen /INT2 und /OVR durchverbunden


    Die Tastatur passt übrigens weiterhin einwandfrei oben drüber. Da ist zum Glück genug Platz.


    So hab ich einen Firstrun versucht.

    Leider hab ich nur einen Blackscreen erhalten:cry:und ich hatte den Eindruck, dass die CPU relativ schnell ziemlich heiß wird. Deshalb gleich wieder abgeschaltet.

    Das ganze dann nochmal ohne CompactFlash - Adapter probiert. Hat aber auch nicht genutzt.


    Vielleicht stimmt die Programmierung des CPLDs doch nicht. :nixwiss:

    Oder ein Lötfehler. Vielleicht hat auch der RAM-Chip, der aus einem alten PS2-SIMM ausgelötet wurde einen ab?

    Werde nochmal nacharbeiten müssen...


    Immerhin hat der A500 nach Ausbau der Platine wieder ganz normal gestartet.:puhh: