Posts by StefR

    Ich habe das mit dem 250425 aufgegeben und habe ein auf den 8580 angepasstes 250407 ins Gehäuse ohne jegliche Regler, dafür mit fünf in Reihe geschalteten 1N4148 geworfen (vier hätten auch gereicht) ,aber das war mehr oder minder sinnlos, denn auch der 8580 scheint tatsächlich im Eimer zu sein, mittlerweile auch im 250469. Eine ganze Note kann er halten, bei einer Halbnote fällt die Frequenz auf die ganze Note nach kurzer Zeit ab.


    Was ich allerdings sagen kann: Diese Buck-Converter taugen in Kombination als direkter Ersatz bspw für den 7805 bei Weiterverwendung des originalen Netzteils und vorgeschaltetem Gleichrichter überhaupt nicht. Je nach eingestellter Spannung (4.5 - 5.0 Volt) tanzt das Bild wie eine indische Kobra unter Alkoholeinfluss bis hin zu einem völlig vergrisseltem Bild bei 5 Volt.


    Ich würde ja gerne für mich selbst einen schnellen 8051 als SID-Ersatz programmieren, die ein oder anderen Experimente mit mehrstimmigen Synthesizern inklusive ADSR-Generatoren und einfachem Filter auf einem Chip existieren schon, auch das Abfangen des Daten und Adressbus, wie auch R/W wird noch per Interrupt an CS zu lösen sein, aber bei den gegebenen Filtertypen, die der SID vorgibt, ist im Bezug auf die Kenntnisse bezüglich Fillter, vor allem unter Assembler, der Ofen völlig aus.

    Stimmt, 22nf vs 470 pf, danke für den Hinweis - ich hab das glatt "überdacht". Aber ob das was am Verhalten ansich ändert, das effektiv der/ die DCO(s) abdrehen bzw busseitig so ein Kruscht rauskommt? Weiß es nicht.


    Heut aber nemmer. Tausche ich morgen.


    Ich würde ja gerne wieder einen 6581 einsetzen, aber ich kann keinen kaufen (Inflation, Geld knapp) und zum anderen will ich das schlachten von Rechnern, mehr oder minder nur der SIDs wegen, nicht auch noch unterstützen. Ich hab auch noch ein paar andere 250425 mit je einem guten 6581er, aber die will ich möglichst dort lassen, wo sie sind; schnell ist man mal unachtsam und es ist vorbei. Gerade in so einem "Experimentierrechner" will ich das möglichst unterlassen. Nee, der 6581, der vorher drin war, hat schon vor dem Umbau den Geist aufgegeben (hat den ganzen Rechner "blockiert").


    Ob dem 250469 wiederum der SID fehlt, ist mir im Grunde genommen "Banane". Das Board steht insgesamt nicht wirklich auf meinem Schirm.


    Danke soweit !

    Edit: Gerade mal mit meinem Oszi und einem Testprogramm probiert, das den SID dauerhaft in wählbarer Notenhöhe befeuert. Obwohl Phi2 lt meinem Fluke-Messi stabil ist, schaltet in manchen ausgegebenen Tonhöhen die Ausgabefrequenz um einige Dutzend (hörbare) Hertz, dann bricht die Frequenz völlig auf den Minimalwert und es liegt am (SID)-Datenbus nach kurzer Zeit nicht mehr das an, was vorher durchgängig geliefert wurde (zumindest ist der veränderte Wert deutlich sichtbar). Davor natürlich RAM, ROM mit dem Programm getestet, keine Fehler.


    Naja, heute nicht mehr damit beschäftigen. Ist genug.

    Muss mir das mal genauer ansehen. Schnelle, wechselnde Zugriffe auf den SID führen zum Stimmenausfall. Er selbst ist es nicht, gerade nochmal im 250469 getestet, von woraus er ursprünglich kommt. Ich schätze, wenn die DC-DC-Wandler tatsächlich so stark einstreuen würden, dann würde die halbe bis ganze Elektronik nicht arbeiten.

    Ich habe Schnellader wie Hypra & Co bislang noch nicht ausprobiert, nur SJLoad.


    Ich muss ohnehin wohl einiges wieder rückbauen. Zwar läuft die Kiste mit den DC-DC-Wandlern, aber der SID scheint nicht unbedingt damit einverstanden zu sein. Ich habe zwar stimmenseitig "Output", aber sehr abgehakt. Wahrscheinlich die Schaltfrequenz der Wandler, die Ärger macht.

    So habe ich mir 100%ig auch meine alte 1 GB-Karte geschrottet (lässt sich nicht mehr partitionieren und spuckt I/O-Errors aus). Die hatte zwar eh keinen großen Wert mehr, ist aber trotzdem ärgerlich. Wer rechnet auch mit so etwas. Wären die Adapter nicht so alt, würde ich sie dem Händler gerade wieder an den Kopf schmeißen.


    Gott sei Dank verwende ich seit einiger Zeit nur noch die neuen Adapter mit Levelshifter, denn das wäre extrem ärgerlich, von diesen die "fehlerhaften" Adapter wieder zu entfernen bzw den Pegel an den Pins runterzuziehen. Die alten Adapter waren in Projekten in Einsatz, die ich eh nicht mehr verwende oder weiter verfolge. Jener im C64 war der einzige, der noch aktiv Einsatz fand.


    Klar, man muss ihn deswegen jetzt nicht wegwerfen, aber den Streß mit Pegelwandlung muss man sich nicht geben.


    Ich kann mich für den Hinweis echt nur noch 1000 mal bedanken, denn ich hätte mir, nicht nur in dem Falle, weiterhin meine Karten über kurz oder lang geschrottet. Und das ist nicht lustig, weil das neben potentiellem Datenverlust natürlich auch ins Geld gehen kann.

    Das wird auch hier behandelt:

    https://www.eevblog.com/forum/…-please-explain-this-one/

    Und gerade der Punkt:

    "

    A lot of 3.3V CMOS processes have 4.6V absolute maximum ratings. That's within -10% of 5V that, given a below-spec 5V supply and natural process variation, the device may be able to survive for some time at that voltage, but it's definitely not recommended and many will die.

    (Unfortunately, the specifics of device reliability vs. supply voltage for a given process is notoriously difficult to find. Manufacturers seem to like leaving such things unsaid.)"

    Das müsste man "Mingos" eigentlich mitteilen, das hier ein potentieller Fehler vorliegt - falls er hier nicht mitliest. Ich hätte ihn auf seiner Webseite angeschrieben, aber die Kontaktfunktion ist nicht aktiv und ich habe keinen Twitter-Account.

    Du hast vollkommen recht, es sind Pullups auf 3.3 Volt und die Signale landen direkt an der Karte. Ein maximaler Fehler auf meiner Seite. Verwunderlich, das es bislang überhaupt so funktioniert hat. Danke für diesen extrem wichtigen Hinweis! Ich hab mich drauf verlassen, das wenigstens eine Pegelwandlung darauf statt findet - (edit: hierfür habe ich die Widerstände auch angesehen).


    Der Slot fliegt raus und wird durch den Micro-Slot ersetzt !


    DA

    Ja, den Kartenadapter, wie er in seinem Design verwendet, habe ich ebenfalls.


    Also, ich kenne die Beschaltung des Adapters nicht, ich habe auch gerade keinen externen mehr zur Hand, aber es muss ja zumindest auch eine Signal-Pegelwandlung darauf statt finden, anderenfalls würde mir die Karten reihenweise abrauchen. Ich sehe nur in dem Design, das er die Widerstände zwischen CS, MOSI und SCLK wohl dazu verwendet, um auf den 3.3 Volt Signalpegel zu kommen - das muss man bei dem gegebenen Adapter ja nicht.


    Es wäre natürlich etwas anderes, wenn ich eine SD-Karte direkt ohne irgendwas drumherum mit dem SPI-Interface verbinden würde. Dann wäre es klar, das ich so vorgehen müsste.


    In jedem Falle verwende ich den Adapter so, wie er ist, auch klaglos in meinen eigenen Designs um 5V herum.

    Echt? Hab hab das nach den Layout (ohne Taster) aufgebaut.


    https://mingos-commodorepage.c…Bau%20dir%20dein%20SD2IEC!


    Ein guter Hinweis, so werde ich tun.


    Edit. Ich bin gerade extrem verunsichert, was mein Wissen bzgl AVR und SD Karte angeht. Eigentlich kenne ich das nicht anders, als MOSI/MISO/SCLK ggf, falls nötig, mit Pullups zu versehen. Ich weiß zwar, das man im AVR die internen -Pullups- "deaktivieren" und externe Pullups verwenden kann, aber ich komme gerade nicht damit klar, wo und wie ein externer Pulldown Einfluss findet.

    Capstan: Hehe, ich kann vermuten, worauf du hinauswillst- ja der 8580 in dem 250425 klingt gut, weil er mit 9V von einem Spannungsregler versorgt wird :-) Der wurde dort reingeimpft, weil der vorhandene 6581R4AR den Geist aufgab.

    Aufgrund Mangel an den üblichen Commodore-Fußwärmern - und da ich noch ein paar andere 64er habe, die versorgt werden wollen - hab ich diese Kiste probehalber auf Single-12V und drei DC-DC-Wandlern umgebaut. Ich muss allerdings noch die 50 Hz generieren und ein bischen nach Integration von den fetten Kondensatoren schauen, die zzT nicht wirklich eine arg große Rolle spielen.

    CapFuture1975: Ja, richtig, ich hab keine Pullups direkt auf dem Board, nutze dafür die auf dem Slot. Die Konstruktion ist die absolute Sparvariante, selbst ohne externem Crystal, da ich davon ausgehe, das der Drift des internen Oszi ist mMn nicht so hoch, als das es da großartig Schwierigkeiten geben würde. Besser wäre es, aber ich muss mit den Teilen haushalten, die ich habe. Selbst der 1284 ist schon ziemlich runtergenudelt, wie man sieht, aber die sind teuer. Gerade heute.

    Gute Idee und danke für den Tip, ich hab allerdings beide GND-Leitungen auf der jeweils gegenüberliegenden Seite verwendet. Das ist noch die Ausführung mit dem dicken Slot, jene, die man heute vornehmlich bekommt, ist für Micro-SD gedacht, die hat nur noch eine GND-Versorgung.


    Ich glaube, ich bau das Ding einfach nochmal auf, falls sich die andere Karte auch stur stellen sollte.


    Was ich mir auch überlege, ist, vielleicht eine Variante mit einem 8051 zusammenzuklöppeln; das braucht allerdings einige Zeit, bis ich das funktionsfähig hätte. Ein bissel Kenntnisse im Umgang mit dem IEC-Protokoll und Kommunikation zwischen 8051 und einer 1570 habe ich schon (habe mal einen Diskettenreader zusammengebaut, der über den 8051 und eigenen Floppyroutinen in der 1570 Daten über den seriellen Port zum PC schiebt) , FAT32-Librarys hab ich auch schon zusammengetackert, ist halt alles Assembler.


    Der 8051 hätte halt den Vorteil, das seine Ports von Grund auf bidirektional sind, nachteilig ist, das meine 8051-Varianten leider nur ca 1KB internen SRAM haben und ich mir für so eine Konstruktion externes SRAM eigentlich gerne sparen würde. 1KB ist ein -bissel- arg wenig, wenn man bedenkt, das man schon einen 2*512 Byte großen Transferbuffer vorhalten müsste/sollte/muss. Plus der Umgang mit Speedern & Co händeln. Ich habe zwar auch eine 6510-Emulation für AVR und 8051 zur Hand (auch mal selbstgeschrieben, war als Drop-In-Replacement gedacht), mit der ich vielleicht eine halbe Floppy emulieren könnte, aber parallel dazu die SD-Karte händeln und verständlich für die Emulation übersetzen wird wohl äußerst kompliziert. Für einen äußerst "dummen und lahmen C64" mit S/W-TV-Ausgabe und sehr beschänktem RAM, "ohne alles", hat die Emulation mal gereicht.


    Und obs insgesamt bei all den gegebenen Floppyemulationsvarianten noch Sinn macht, weiß ich auch nicht.


    Das wäre wohl eher eine "just for fun"-Beschäftigung, über mindestens Ostern hinweg.

    Ich weiß nicht - ich bin beim Messen schlussendlich wiederum zum gleichen Resultat gekommen.


    Habe noch eine 32GB-Karte in "Reserve", leider zzT verliehen, aber die werde ich mir krallen und es damit weiter versuchen.

    Hat sich bislang erledigt - bei erneuter Überprüfung der Signalverbindungen habe ich vor lauter Tran die Steckverbindung zwischen AVR und Adapter um einen Pin versetzt wieder aufgesteckt, so das letztlich 5V auf dem 3.3V Anschluss des Adapters landeten, dabei die dazugehörige Masse vom AVR I/O gezogen und die Karte gegrillt wurde - heiße Angelegenheit, die Fingerkuppe dankt.


    Merke: Steckverbindungen nur mit Wannenstecker.....

    Ich hatte bislang auch keine Probleme - bis ich halt auf eine andere Karte ausweichen musste. Der Slot selbst liegt auf einer üblichen Adapterplatine und klemmt über ein Verbindungskabel am AVR. Da ich die Verbindungen ab Slot bis hin zum AVR und Spannungsversorgung bereits zu Beginn der Problematik durchgemessen habe, kann ich elektrische Probleme auch ausschließen.


    Höchstens, die Kontaktpins -im- Slot haben Probleme, aber das wäre nach vielleicht 30 mal einschieben einer Karte der Hammer, wenn die jetzt schon Probleme machen würden.

    Dankeschön für den Tip - werde ich mal ausprobieren. Stimmt, das kann durchaus sein, das ich mir hier Probleme eingebrockt habe.


    Mein einziger PC-SD-Slot wird von Linux bedient, dort habe ich die Fat32-Partitionstabelle halt mit GParted erstellt und formatiert. Vorher hielt die Karte für das 8051-Projekt ein von mir zusammenkonstruiertes RAW-"Image", das mit dd draufgeschoben wurde. Vielleicht fehlen so trotz Neupartitionierung bestimmte Sektorinformationen.


    Ich habe vor langer Zeit mal eine Fat32-Library für den AVR und 8051 unter Assembler geschrieben und meine mich dunkel daran entsinnen, das es im Sektor 0/1 irgendwo auf Offset 0x1c6 herum einen Verweis auf den Virtual Boot Record gibt - wenn der fehlt oder falsche Infos enthält, kanns durchaus sein, das man letztenendes keinen Zugriff aufs Dateisystem erhält.

    Moinmoin,


    vor einiger Zeit habe ich mir das SD2IEC auf Basis des Larsp-Designs um einen 1284P aufgebaut und im Rechner verwurstelt. Bis zu dem Zeitpunkt, als meine olle 1GB-SD-Karte den Geist aufgab, hat das ganze auch prächtig funktioniert.


    Nun, das ganze lag jetzt ein paar Monate auf der Seite, eine 16GB Sandisk-Karte kam in den Zeitraum hinzu, aber leider kann mein C64 mit der Karte nichts anfangen; ich lande immer auf dem EEPROM-FS. Auch 'Load "$=P",8 ' zeigt mir keine Karte an. Vorbereitende Maßnahmen wie Fat32 und Co ist so weit klar.


    Die Version meiner Firmware lautet lt. C64 "v 1.0.0atenrdead0-20".


    Da ich im laufe meiner Programmiertätigkeit am 6502, 8051, AVR und Cortex auch meine Erfahrung bezüglich SD-Karten sammeln konnte, weiß ich, das manche Karten sehr pingelig sind, was die Initialisierung angeht - und das SDHC/XC-Karten im Gegensatz zu normalen SD-Karten natürlich auch eine völlig verschiedene Addressierung (Blockaddressierung vs Byteaddressierung) und teils zusätzliche Kommandos in der Initialisierung verwenden (teils sogar müssen). Daher meine Frage: Ist es bekannt, ob in der LarsP-Firmware eine solche Unterscheidung zwischen SD und SDHC implementiert ist und wenn ja, kann mir jemand sagen, wie die Initialisierungsroutine dieser Firmware für diese Karten aussieht?


    Die betreffende Karte selbst habe ich in einem anderen Projekt mit einem 8051 schon erfolgreich verwenden können, aber natürlich nur unter einer viel weitläufigeren Initialisierung, als es bei byteaddressierten Karten der Fall ist.



    Ich möchte bei der Fehlersuche ausschließen, das man sich seitens der AVR-Firmware darauf verlässt, das die SD-Karte, wenn HC, irgendwie in einen Fallbackmodus aufgrund von Standard-Initialisierungs-Kommandos fällt und dann mit der alten Adressierung gearbeitet wird, was manche Karten eventuell "nicht mitmachen".


    "Leider" bin ich nur purer Assemblerprogrammierer und kann C/C++ zwar bis zu einem gewissen Grad interpretieren, aber doch nicht alles :-(


    Edit: Bevor es zu Mißverständnissen kommt - die Frage dient nur zur Klärung des Sachverhaltes und stellt keinen "Vorwurf" an den/die Ersteller der Firmware dar - würde mir im Traum nicht einfallen.



    Viele Grüsse

    Stef

    Habe mich mal derweil auf einem engllischsprachigen Atariforum unterhalten und weiter analysiert - scheint der GLUE-Baustein zu sein, der eine Macke hat. Produziert ab und an Fehler bei der Adressdekodierung und somit ROM-Ansteuerung bzw zieht/setzt Leitungen, wo er nicht soll, zieht dabei das ganze System in den Abgrund. Die Fehler scheinen von einem Punkt zum anderen zu wandern. Aber keine Garantie, das er und auch wiklich nur er es ist. Ich habe die Vermutung, das da noch einiges mehr im argen ist.

    Falls jemand einen GLUE-Stein zu einem vernünftigen Preis anbieten könnte, wäre ich sehr happy.