Beiträge von Mr Crayfish

    Das sind mit an Sicherheit grenzender Wahrscheinlichkeit Präzisionssockelleisten und keine IC-Sockel.

    Wusste nicht, dass es die auch einzeln, Reihe für Reihe, gibt, denn ich kannte diese Präzisonssockel auch (= ebenfalls) nur mit Stegen. Deswegen meine Theorie, dass er diese Stege erstmal hat wegknipsen müssen.
    Aber ja, die gibt's tatsächlich wohl auch einzeln ("Reihe ohne alles"), nachdem ich mir eben google Bilder angesehen habe, zum variablen Einsatz.

    Beitrag editieren kann man im Forum seit einiger Zeit nun gar nicht mehr ?

    Wäre aber natürlich interessant zu sehen, ob die, z.B. Ram Sockel, ggf. doch schon ab Werk so drin waren oder nicht. Sprich, ob man auf der Platinenrückseite erkennen kann, ob es noch original ist oder schonmal neu gelötet wurde.

    Sockel konnten nunmal auch andere Farben haben als nur schwarz. Unser erster Cevi erhielt auch einmal einen hellblauen Sockel (nach einer Reparatur).

    Da der Löter in deinem Fall wohl keine passenden Breiten auf Lager hatte, hat er die Mittelstege der Sockel schlicht weggeknipst od. gleich fertige Reihen genommen und einfach Reihe für Reihe
    separat eingesetzt/-lötet.

    Gibt es eigentlich einen Modulatorersatz, wo das normale Videosignal nicht verhunzt wird?

    Das liegt in der Natur der Sache (sollte so langsam jeder 'mal mitbekommen haben), CVBS streut immer. Selbst am U64.

    [Macnmal, wie beim U64, sogar anders suboptimal(er) als beim Original - weil das das umleigende Weiß nicht mehr glatt weiß erscheinen lässt u. solche neuen Effekte die beim Origianl zmindest in dem Aspekt nicht sichtbar sind.]


    Wenn man nicht gerade einen Matschbildmodulator wie die meisten (aber nicht alle) von dem Typ in der Assy 250407 (ab 250425 ist eine andere/bessere Bauart drin) hat, kann man sich einen Tausch mMn eh schenken.

    Da die originalen Modulatoren gut genug sind u. sich grundsätzlich nicht mehr wirklich viel, v.a. nix angenehmer anguckbares, herausholbar ist.

    Irgendwas bei den Filtern macht die SID Emulation in VICE mMn schon immer falsch bzw. ungenießbar. (Sollen die Macher die Filter meientwegen ruhig vereinfachen, dafür wären sie dann wenigstens geneißbar/anhörbar.)

    Jede Musik mit Filterbenutzung klingt von dieser Emulation wie ausgek****/sehr rau. Stört mich v.a. bei YT Videos zu Demos, da dadurch die SID Tracks schlechter dastehen als sie es eigentlich sind.


    Man muss sich nur 'mal die beiliegenden SID Tracks beim 1-Rater-Tracker auf dem PC in der VICE Emulation anhöhren, wie die Interpretation des Lightforce (Spiel) SID Tunes.

    Das klingt in VICE am PC einfach nur nach Müll und sonst gar nichts, ungenießbar schlecht. Man kann gar nicht heraushören, dass es Musik sein soll, so schlimm ist das.

    Am echten C64 dagegen klingen sie glatt, bzw. sind sie da annähernd komplett "geglättet" u. damit genießbar.

    Die Spalten sind bei mir genau bis 40 abgezählt, daran liegt's nicht. ;) Das würde ich dann an der (dann anhand einer kaputten) Formatierung sehen, sobald da auch nur in einer Zeile ein Zeichen +-40drüber oder drunter wäre.

    Sonst mache ich das auch anders, händiascher. Aber das war mit einem von mir abgetippzen "Screencopy" Programm aus einem alten Data Becker Buch gemacht worden, der o.g. mehrseitige Infotext. Dieser daraus ausgespuckte Code

    nutzt vom ersten " zum letzten " mit Semikolon alle 40 Zeichen aus. Am Ende wenn nötig also mit Leerzeichen bis genau 40 stets (je Spalte, bis auf die letzte Spalte natürl.).


    Lange Rede, kurzer Sinn: Denn ich werde mir das am Ende nochmal genauer, Schritt für Schritt, angucken, die Printfolge in dem einen bestimmten Screen... .* Sobald ich mit dem weitaus komplizierteren Rest fertig und zufrieden bin

    (wie dem Einbinden von Musik an einer anderer Stelle, aber das Init etc. fuscht in der Zeropage o.ä. herum, so dass die Formatierung von Textausgaben für einen ms Moment nach Beenden der Wiedergabe zerstört wird - solche z.T.

    üblichen Unwägbarkeiten halt.. :) ).

    *Da scheint sowieso 'was nicht zu stimmen, selbst bei nurmehr 24 Zeilen. Es hat nämlich wieder gescrollt, obwohl es der 24 Zeilen Screen, so korrekt darstellend = getestet abgesaved, eigentlich eben nicht tat.

    Ja, sorry, das hätte ich wohl ausführlich schreiben sollen :)

    POKE 2023,xx und POKE 56295,xx war gemeint.

    Jetzt habe ich doch noch (immer) ein Problem.

    In jedem Blindtest, den ich mit einem neu geschriebenen Basic-Bsp.-Programm aufsetze, funktioniert das von mir in #12 geschriebene.

    Jedoch in meinem Spieleprogramm lustigerweise nicht, obwohl in der Passage eines längeren Infotexts (Seite pro Seite) technisch echt & wirklich gar nichts anders ist. Dort scrollt der Bildschrim bei allen Versuchen also nun noch immer

    eine Zeile nach oben bzw. unten. :) - Ist jetzt aber auch nicht soo wichtig, wäre nur nice gewesen auf einer bestimmten Seite des Texts in der letzten Zeile noch auf etwas [ein weiteres bzw. zwei Easteregg(s)] aufmerksam zu machen.

    Ich mache das immer mit einem Semikolon.

    Semikolon [ print"..."; ] benutze ich nach jeder ge-print-eten Zeile sogar auch schon. Für die allerletzte Zeile hilft das dann aber scheinbar nicht mehr.

    Später am Tag probiere ich mit der Thematik noch 'mal herum (zuletzt war's gestern).

    Ohne den Rest ab hier, ab meinem letzten Post, gelesen zu haben, sei noch demselben nun noch angefügt:

    Die Semikolon-Methode geht doch. Man darf eben nur bis zur 39. Spalte (von 40) etwas mit print ausgeben. Bis dahin scrollt dann auch nichts noch oben / bzw. rückt nichts eine Zeile weiter vor.

    Den letzten Buchstaben oder Zeichen kann man dann ja in den Bildschrimspeicher poken (Poke 2023,41 für Klammer zu, als Bsp.), sofern man die ganze Zeile Nr.25 bzw. inkl. dem 40. Zeichen darstellen u. befüllen will.


    So hat das Endurion wohl anfags schon gemeint gehabt.

    (Mir dämmerte auch sowas, nach dem Lesen davon, von anno 20 Jahre ago, aber man wird "alt".. .)

    Wenn man mit dem Print Befehl etwas in die letzte (25.) Zeile schreibt, springt das Bild bekanntlich immer um eine Zeile hoch. So als ob man Return drücken würde.

    Kann man das Verhalten irgendwie simpel umgehen und dennoch das Print weiterverwenden ?


    Hab' schon versucht, es mit einem Cursorreset, Print"S" (invertiertes "S"), zu umgehen. Es half aber nicht.

    Die Cursorposition zu poken, habe ich dagegen noch nicht probiert. -- Hat ggf. eh nichts damit zu tun, das Verhalten.

    Eine U2+ Cartridge ist nun auch nicht viel weiter vom C64 entfernt, das nimmt sich ja wohl nix.

    Für mich schon, der speaker"schall" kommt vergleichsweise offen durch die U1541II+ dafür gemachten Gehäuseschlitze hindurch, so dass das schon recht eindeutig für das Ohr zu orten ist (dass es genau dort her kommt,

    spätestens sobald man sich dessen bewusst ist).

    Zumindest, wenn sie laut eingestellt sind wie bei mir neulich. :)

    Aus (großen) Lautsprechern wirkt das Lesekopf Geschrubbe eher fremdartiger(..)

    Das verstehe ich. So gesehen sind kleine speaker, die nur und einzig knackig Laufwerksgeräusche von sich geben und sonst nix, besser.

    Mir wäre und ist Drivesound auch über die (TV- etc.)Lautsprecher recht. Sehe da keinen Unterschied, oder warum das unbedingt vom U64 kommen müsste. Ein org. C64 hat ja auch keine LW-Geräusche, die aus dem Brotkasten stammen.. .

    Finde daher eher doof, wenn sie aus dem C64 Gehäuse des U64 her kämen. ;)


    Beim U1541II+ (einer Steck-Cartridge) ist das dann wiederum 'was anderes, denn da und dann kommen die LW-Geräusche ja auch per speaker vom realen Verursacher. :)

    Da aber schon nach der Intitialisierung per "z.B." Sys 4096 sich nichts mehr normal verhält (Cursor springt hin und her, kein Ausfüjren von Programmen mehr möglich, etc.) ist dass dann dennoch

    nicht sehr geeingnet, um das in seine Programme einzubauen. Denn die sollen danach ja schliesslich auch noch laufen.. . :) .

    Korrektur: Wenn man es im Programm selbst ausführt, z.B. (für einen "1-Raster-Tracker" Tune, relocated ab $c200)...


    10 sys $c200 : rem player initzialisieren

    20 for t=1to4000

    20 sys $c203 : rem abspielen

    30 for i=1to7 : next i : rem Warteschleife, da sonst mehrere Ausrufe von Zeile 20 pro Frame = Absturz / muss mindestens 7 betragen ; höhere Werte machen den tune langsamer

    40 next t : print"Nun ist Ende" : end


    ...geht das wohl doch (weiter). Nachdem der Zähler mit Variable t durch ist, wird nämlich normal das "Nun ist Ende" samt dem end dargestellt und ausgeführt.


    Sich mit diesen Trackern vertraut zu machen, um einen eigenen Tune zu schreiben, steht dann aber wieder auf einem eigenen Blatt... .

    Ganz so simpel wie mit dem Fasttracker 2 am PC (Dos) ist das dann nämlich doch nicht. Bei dem ganzen abstrakt wirkenden Zahlenwerten für Instrumenterstellung und weiteres... .

    Müsste man halt das jeweilige Manual vorher und währenddessen gut studieren. :)

    Habe' 'mal mit dem "1-Raster-Tracker" herumprobiert. Die Tunes kann man dort ja einfach relocaten, wie man es braucht, und auch selbst über einen Basic Vieerzeiler wiedergeben.

    Da aber schon nach der Intitialisierung per "z.B." Sys 4096 sich nichts mehr normal verhält (Cursor springt hin und her, kein Ausfüjren von Programmen mehr möglich, etc.) ist dass dann dennoch

    nicht sehr geeingnet, um das in seine Programme einzubauen. Denn die sollen danach ja schliesslich auch noch laufen.. . :).


    Der o.g. "Musikprofessor" ist btw. eine Public Domain (PD) Software. Kennt daher sicherlich keiner. Wenn man sie einmal braucht, findet man sie nicht wieder. Auch auf csdb nicht, da gibt's scheinbar prinzipiell gar nichts an PD Disks.

    Aber damit konnte man jedes Tune einfach per Sys 49152, wie beim Hülsbeck Musiceditor aus der 64er in '86 samt seinen tunes, aufrufen und danach beliebig weitermachen / es einfach im Hintwergrund im IRQ spielen lassen.

    So etwas bräuchte man doch, aber zusätzlich mit einer Routine zum Abschalten des tunes und des IRQ Inhalts - so dass wieder alles gesäubert wäre. Das heisst, das eigentliche Programm danach wieder im Originalspeed läuft.


    Egal, mein Programm bleibt jetzt eh erstmal so wie es ist (unverbastelt).

    Für das Kabel muss der Monitor natürlich hinten per Druckkonpof auf S-Video stehen. Das 'mal prüfen = testweise auch 'mal daran herumswitchen.

    Am Monitor selbst kann natürlich u.U. auch immer 'was defekt sein bzw. zufällig die letzte Zeit seit der DoReCo defekt gegengen sein, also bloß die Umschaltung / der Druckknopf z.B. .

    (Mein C= Monitor konnte von einem auf dem anderen Moment kein CVBS von jedweder Quelle mehr -also gegenteiliges-, S-Video und auch RGB ging und geht aber wie immer.)

    ---

    Dass das Bild nach dem Einschalten des U64 aufeinmal schwarz-weiß war, das hatte ich übrigens auch schon 'mal. Aber nur 2-3x in mehreren Jahren. Nach einem erneuten Aus- und Einschalten war's dann wieder in Farbe.

    Das wunderte mich auch und befürchtete schon einen Defekt am U64. Ist jetzt aber schon ca. 3 Jahre nicht mehr aufgetreten.

    Kennst du, oder auch jmd. anderes, einen guten und simplen music tracker für C64, den man auch wieder beliebig per Sys Aufruf im Spiel abschalten könnte, so dass er bei Nichtwiedergabe gar keine Rasterzeit mehr klauen würde ?

    Nur für den Titelbildschirm und dann wieder abschalten, alles wieder in den Ursprungszusatand, damit es (die Playroutine) das Spiel selbst nicht verlangsamt.


    Bisher habe ich da noch fast gar nichts getestet, bis auf den sogenannten "Musikprofessor" vor 20 Jahren ;).

    Weiß also nur, dass es da eine init und eine play adresse gibt oder bestenfalls geben sollte, u. was das bedeutet weiß ich auch.


    Eigentlich soll das Spiel ruhig bewusst so "basic" bleiben, aber ein wenig experimentieren kann man ja 'mal. Der Track würde dann genauso basic sein, er soll das Spiel ja nicht vom Intellekt her überlagern, sondern soll dazu passen / nur das

    Spielethema an sich im Titel untermalen.

    Ok, danke für den Tipp, werde ich dann und wann 'mal ausprobieren / mich mit beschäftigen.

    Die jetztige Rate von 74,64% ;) , die exomizer erreicht, so dass gar en Programm knapp unter 15KB herausspringt, ist aber auch schon erstaunlich u. mir gut genug.

    Da erinnere ich mich an einen Satz von einem RGCD-ler, sinngemäß: "Man wundert sich / würde nicht unterschätzen, was eoxomizer alles so klein bekommt."


    Wenn ich ein paar mehr KB einsparen hätte wollen, dann würde ich a) all die ungenutzten Sprites weglassen. Die waren 'mal für eine Abbaler "2Pl-Duel" Version des Spiels + einen 1-Player Mode gedacht. So gibt's für den Anwender mehr

    zu gucken und erforschen, wer er 'mal den Spriteeditor einer Freezercartridge ala NordicPower, etc., bemüht, um sich die Sprites anzusehen. Deshalb habe ich die drin gelassen (und vorgestern nur noch in die exakte Mitte des

    jeweiligen Spriteausschnitts verschoben).

    Und b) würde es ein halber statt ein gesamter Zeichensatz mit Groß- UND Kleinschrift bis auf ein Gimmick-Detail am Ende des infotexts rein theoretisch auch tun. Bzw. andere Methode: Ein echter Bytehunter/-saver-Mensch würde den

    Zeichensatz vom Programmcode vom Rom ins Ram nach in meinem Fall $E000 kopieren, und würde sich dann damit die gesamten 17 Blocks eines kompletten Zeichensatzes einsparen.

    Gut, seine Daten für die ganzen Zeichen-Neudefinitionen müsste man davon noch abziehen, welche er ja dann natürlich immernoch irgendwo in seinem Code unterbringen muss.



    Habe jetzt noch im Titlescreen das "utilies" in "utilities" korrigiert, hatte ich zuletzt vergessen aber sets vorgehabt.

    Die Vokabel vor mehr als 20 Jahren 'mal als "utilies" im Kopf abgespeichert, aber das Wort tut's ja so nicht geben (wie ich vor ein paar Jahren feststellte).

    Ausserdem 2x ein "/" Zeichen mit einem "," Zeichen ersetzt. Ich musste vorher das "/" als Kommazeichenersatz nehmen, weil ich das Komma im Zeichensatz mit meinem Eigenzeichen eines nach unten zeigenden Pfeils überschrieben habe.

    Vorhin habe ich aber das originale Komma nachgezeichnet und im Zeichensatz unter dem Kleeblattzeichen (das unter Shift + X), also jenes überschreibend, wieder hergestellt. Habe es somit endlich wieder zur Verfügung.. . :)


    Das macht Spaß, "all" diese selbstgeschriebenen* Basic ZS-Änderungsprogramme von vor 20 Jahren wiederzubenutzen. Oldskool Do-It-Yourself-Method wie in '82/'83, anstatt jetzt irgendeinen ZS Editor Tool aus dem Net zu bemühen.

    Zeichnen tue ich die einfach immer im Spriteeditor eines Nordic Power Moduls in einem umrahmten 8x8 Feld, um sie mir optisch in Originalgröße u. ggf. Passgenauigkeit zueinander genauer anzusehen.

    Die Data Werte je Zeile (8 Werte pro Zeichen) errechne ich dann selbst und schreibe sie mir auf, um sie danach iin die Datazeile des o.g. Vierzeiler ZS-Änderungsprogramms, mit dem man jeden hereingeladenen ZS abändern kann

    (Änderung der darin per Poke bemühten Anfangsadresse des jeweligen ZS vorrausgesetzt), einzufügen / zu übertragen. Dann kann man immer so schön live zugucken, wie ein Zeichen geändert/überschrieben wird, wenn man es

    vorher im Bild eingegeben hat :). *Ok, das könnte genaugenommen noch auf dem Grafikkbuch von Data Becker herrühren, die kl. Grundformel dazu.

    Ja, danke ! :) Das wäre bereits so wie gewünscht. Eben im neuesten VICE getestet.

    (Der Micro64 gibt für den 2. Spieler Dauergas nach links-oben. Hat aber mit dem Emu zu tun, ganz sicher.)


    Ist $081c die direkte Startadresse zum Ausführen eines jeden Blitz! Compilats ? Bin ich da richtig mit dieser Annahme ?


    Morgen versuche ich die exomizer-outputdatei von dir zu reproduzieren. Erstmal Feierabend für heute.. .



    P.S.: Im .d64 zum Spiel, welches ich später noch hier oder woanders veröffentliche, steht dann noch mehr drin: Und zwar zwei Bildschirme eines kleinen one screen noters (4 Blocks je Bildschirm und Datei)

    miit mehr "techn." und "future plans" Info'gesülz' zum Spielchen. (Der längere Infotext im Spiel selbst ist ja schliesslich noch nicht genug.. . ;))