Arndt for Präsident
Hallo Besucher, der Thread wurde 45k mal aufgerufen und enthält 313 Antworten
letzter Beitrag von steril am
-
-
Ja, bisschen Abstand ist gut.
Hauptsache sich nicht runterbringen lassen. -
Ich habe mich in einer ähnlichen Situation endlich mal dazu aufgerafft, mir ein einfaches Unittest-Framework für den Cevi zusammenzustellen. Das war rückblickend glaube ich die beste Idee gleich nach dem Einführen eines Versionskontrollsystems . Ist zwar natürlich auch erst mal Arbeit, aber seit dem ist mein Leben unglaublich viel entspannter geworden. Einfach ein paar fiese Cornercases ausdenken, dann hat man das Problem schon fast in der Tasche.
-
Kann man eigentlich mit ACME aus einem Quell-File heraus mehrere Objekt-Files erzeugen? Mit irgendeinem !to-Parameter? Ich möchte zwei im Speicher getrennte, aber logisch zusammenhängende Segmente in einem Zug getrennt abspeichern.
Arndt
-
Kann man eigentlich mit ACME aus einem Quell-File heraus mehrere Objekt-Files erzeugen?
Nein, derzeit nicht.
Sowas steht aber auf der Todo-Liste: Jemand (Claus?) hatte mal gefragt, ob man ein Hauptprogramm und mehrere Nachlade-Levels so assemblieren könnte, dass sie sich all ihre Symbole teilen. Wenn ich Dich richtig verstehe, würde das auch diesen Fall lösen. -
Selbstbewerb: C64 Studio kann das. Eine Dependency ausgewählt und ein Häkchen bei "Include Symbols" gesetzt. Mehrfach vorkommende Symbole werden dann natürlich angenörgelt.
Das ist für genau so etwas gedacht, wenn man einen Basis-Code für Objekte o.Ä. in diversen nachgeladenen Code-Teilen verwenden will, ohne dass man da eine Liste der Adressen vorher festlegt.Wie man so etwas aber übersichtlich und vernünftig über den Code selbst regelt, habe ich selbst aber auch noch nicht herausgefunden
-
Jemand (Claus?) hatte mal gefragt, ob man ein Hauptprogramm und mehrere Nachlade-Levels so assemblieren könnte, dass sie sich all ihre Symbole teilen.
Jo, das war ich ! Allerdings würde ich mir inzwischen vermutlich noch lieber Support für .o64 Objectfiles wünschen. Dann könnte man den ld65 als Linker verwenden und hätte gleich einen ganzen Haufen an zusätzlicher Funktionalität (einschließlich der geteilten Symbole) for free sozusagen. Der einzige Assembler, der das m.W. kann, ist der CA65. Mit dem lassen sich solche Probleme leicht lösen, weshalb ich mich auch dafür für Zeit der Stille entschieden habe. Das hilft Dir aber wahrscheinlich jetzt nichts mehr, @GoDot, außer Du willst all Deinen Sourcecode anpassen .
-
Wenn ich Dich richtig verstehe, würde das auch diesen Fall lösen.
Exakt. Der Explorer ist am Limit (4K) und ich hab angefangen, Routinen auszulagern (heißt dann "uni.xhelpers"). Da beide Files sich weiterhin aufeinander beziehen, aber an sehr unterschiedlichen Orten liegen, wäre eine Segmentierung äußerst hilfreich...
Arndt
-
So, ich hab jetzt zur Entspannung erstmal was völlig anderes gemacht (um es mal mit Monty Python auszudrücken), nämlich zwei (lang versprochene) GoDot-Tutorien: Umranden und Einfärben. Jetzt geht's weiter mit goDos...
Arndt
-
So, ich hab jetzt zur Entspannung erstmal was völlig anderes gemacht (um es mal mit Monty Python auszudrücken), nämlich zwei (lang versprochene) GoDot-Tutorien: Umranden und Einfärben. Jetzt geht's weiter mit goDos...
Arndt
Juhuuu
-
Naja, schon wieder was dazwischengekommen!
Also OT:
Ich hab einen fast 15 Jahre alten Bug im Lader GeoPaint gefixt, der dazu führte, dass er hin und wieder eindeutige GeoPaint-Bilder mit "No GeoPaint image" abwies. Ich hatte das Verhalten zwar ab und zu mitbekommen, aber nicht ernst genommen, zumal es bei den Testbildern, die ich zur Verfügung hatte, nicht auftrat. Jetzt weiß ich, was da los war: GeoPaint speichert seine Bilder platzsparend ab, wenn lange Bereiche im Bild leer sind, werden sie erst gar nicht gespeichert. Es wird nur festgehalten, dass es diesen Bereich gibt. Tja, ich hatte nicht klar genug auf diesen Umstand getestet: Wenn es *am Anfang* eines Bildes pixelfreie Bereiche gab, hat der Lader fälschlich angenommen, dass das Bild *komplett* leer ist und womöglich deshalb gar kein GeoPaint-Bild ist. Daher die Meldung. Ist jetzt gefixt.Ein zweiter Fehler hat mit dem Ende eines Bildes zu tun: Manche Bilder belegen den *ganzen* Canvas, haben aber schon ab der Canvas-Mitte keinen Inhalt mehr. Das wird von Geos so ähnlich festgehalten wie oben beschrieben, ich hatte auch hier unklar abgefragt (die Höhe eines Bildes wurde dadurch zu Null). Ergebnis: das Bild wurde nicht eingelesen. Ist jetzt ebenfalls gefixt.
Das also zwischendurch...
Arndt
-
Na ist doch auch schön, wenn man so nebenbei noch bugs fixen kann
-
Moin Arndt,
Gibt es eventuell Neuigkeiten?
-
-
Wäre es eine große Programmiersünde, wenn ich die Anzahl der akzeptierten Directory-Einträge auf 256 pro Disk begrenzen würde? (Ich weiß, dass eine 1581 296 haben kann und CMD-Natives bis zu 60000, aber - ehrlich? - mir sind noch nie mehr als 255 über den Weg gelaufen...)
Bin also dabei, die Directory-Routine komplett neu zu machen (und zwar im Wesentlichen so wie in NetCopy, nur goDos/GoDot-konform - hätte ich sowieso wegen des Tagging von vornherein so machen müssen) und hab meinen neuen RasPi mal ein bisschen an die Seite gelegt...
Arndt
-
Warum möchtest Du das auf diese Anzahl begrenzen?
-
Vieleicht sollte man garnicht das ganze Dir im Speicher halten sondern imer so umd die 10 Einträge nachladen und darstellen.
-
Warum möchtest Du das auf diese Anzahl begrenzen?
Der 6502 ist ein Acht-Bitter - klingelt's?
Bei einem eigenen Projekt habe ich die "große" Lösung gebaut, aber ob das wirklich jemand braucht - keine Ahnung. Am Besten erst mal die kleine Lösung programmieren und dann warten, ob sich jemand beschwert. Eine richtige Programmiersünde wäre es nur, sich auch noch die Fehlermeldung bei Erreichen des Limits einzusparen.
-
Eine richtige Programmiersünde wäre es nur, sich auch noch die Fehlermeldung bei Erreichen des Limits einzusparen.
Richtig, zum Beispiel so etwas :
-
Vieleicht sollte man garnicht das ganze Dir im Speicher halten sondern imer so umd die 10 Einträge nachladen und darstellen.
Das ist ja die jetzige Methode. Aus Performance-Gründen brauche ich beim Tagging aber entsprechende Listen, die eben auch ("Tag all") das ganze Directory umfassen können. Da ist es einfacher und (viel) schneller, gleich von vornherein die Listen komplett zu erstellen.
Eine richtige Programmiersünde wäre es nur, sich auch noch die Fehlermeldung bei Erreichen des Limits einzusparen.
Hehe... klar! Und @Claus: Ist die Meldung echt?
Arndt