Posts by the_cky

    Also ich habe diverse Programmierer, nutze i.d.R. aber meist AVR Dragon und USBasp.

    Mit dem USBasp hatte ich auch Probleme und zwar mit der 5V Spannungsversorgung. Daher versorge ich den Chip immer mit externen 5V (dabei muss die Masse des ext. Netzteil mit der Masse des USBasp Pins verbunden werden).

    Für die Programmierung selber nehme ich avrdude her, allerdings auch von einem Linuxsystem aus.

    Code
    1. avrdude -c usbasp -p t4313 -P usb -U flash:w:/path/to/hexfile

    In dem Beispiel wird ein Attiny 4313 programmiert (-p t4313). Eine Liste der unterstützten Typen solltest Du mit "avrdude -p ?" bekommen.

    Um welchen Atmel handelt es sich denn und stammt der evtl. schon aus einer Schaltung, wo z.B. die Fuses schon geändert wurden, damit der mit einer anderen Taktfrequenz läuft? (In diesem Fall müsste der Atmel auch zum programmieren mit der Frequenz betrieben werden).


    Und wie vorher schon geschrieben, Fehlermeldungen und Codezeilen wären gut :)

    Ich habe Dir mal eine Version gebastelt, bei der Laufwerk #9 eingestellt ist - ist aber nicht änderbar.


    Gruß

    Thomas

    Files

    • TASS.d64

      (174.85 kB, downloaded 7 times, last: )

    Wenn Du die X-Reg für $FFBA änderst, wird schon von Device 9 geladen bzw. gespeichert, aber der Diskstatus, bzw. Directory geht noch auf Device 8.

    Mal sehen, wenn ich Lust und Zeit habe schaue ich mir das einmal an.

    Ich meine das damals in meine Version auch mit eingebaut zu haben - ist aber verdammt lange her und ich habe keine Ahnung wo die Version abgeblieben ist.

    Beim TurboAss muss ein bisschen mehr machen, wie nur ein X-Reg zu ändern - und je nach Version wo man aufsetzt, gibt es jede Menge HuckePackCode :D

    Im obigen Code nach LDX Level einfuegen:

    TXA

    ASL

    TAX

    Ja, Du hast recht - da war ich wohl nicht ganz bei der Sache :)

    Ich würde mir sogar das TXA noch sparen und den Level direkt in den Akku laden.

    Zu beachten ist, dass bei 0 angefangen wird zu zählen.

    Moin,


    für die Low-/Highbytes musst Du einfach die # weglassen und nur < oder > nutzen.

    Hier einmal der Code angepasst (mit Low nach $03 und High nach $04):


    Ich würde das aber über ein "word" lösen, es sei Du willst über 128 Scrolltext verwenden ;-)

    Das würde dann so aussehen:



    Durch was "word" wird das im Speicher gleich im Format: Low, High , Low, High abgelegt.


    Gruß

    Thomas

    Naja, eventuell nicht die schnellste und eleganteste Lösung, aber du könntest das theoretisch mit 2 Durchläufen machen.

    Im ersten lässt Du einfach die Anzahl der Ziffern bestimmen und im 2 Pass machst Du dann den Output und positionierst vorher den Cursor.


    Mit dem ersten Pass meine ich, das Du einfach den Anteil $bdcd durchläufst, ohne einen Output zu machen, z.B.:

    Dann hättest Du in X die Länge des Strings.

    Das müsstest Du dann erst einmal zwischensprichern und für alle Outputs einmal durchlaufen lassen.


    Dann kannst Du Dir quasi den Offset ausrechnen und entsprechend alles ausgeben.

    Ist halt etwas aufwändiger ;)

    Ja, die Liste ist Monsterhaft - ich weiß. Da besteht noch Optimierungsbedarf und wahrscheinlich gibt es auch Abhängigkeiten die schon irgendwo inkludiert sind.

    Ich wollte das Paket aber erst einmal im AUR haben und die Feinheiten kann ich dann noch nachziehen.


    Zum Thema "Slash", ja das mag sein - alle Beispiele und Anleitungen für die Archpakete haben die aber drin.

    Und damit ggf. ein // sollte nicht zum Fehler führen, ein fehlender Slash könnte aber zum Fehler führen (je nach Makefile). Anführungszeichen finde ich persönlich auch nicht schadhaft bei der Übergabe von Daten :)


    Ja, mit post-remove hast Du recht. Man sollte nicht immer alles am Abend machen :D

    Probier mal die folgenden aus und gib mal bitte ein kurzes Feedback.

    Hmmm irgendwie ist bei mir noch der Wurm drinnen.
    Wenn ich eine bereits erstellte .D64 Datei öffnen will beendet sich der V1541commander.

    Hattest Du das Problem auch ?

    Hi, bei mir funktioniert das alles.

    Ich habe aber keine parallel Installation gehabt - sprich ich hatte vorher die manuelle Version vom System entfernt und dann die Pakete installiert.

    Fulgore : ich muss noch etwas mit dem Mimetypen fixen und dann hochladen.

    Die abhängige lib1541img ist schon paketiert (aber noch nicht im AUR).

    Ja cool - dann gib mal bitte Bescheid wenns im AUR ist. Dann ziehe ich mir das auch mal auf meine Kisten.

    Danke :thumbsup:

    Ja, Bescheid.

    Probier mal die folgenden aus und gib mal bitte ein kurzes Feedback.


    https://aur.archlinux.org/packages/lib1541img

    https://aur.archlinux.org/packages/v1541commander-nonstatic

    Ich muss mir Dein Buildsystem nur noch einmal anschauen (es sei Du kannst gleich adHoc die Antwort geben), damit der Anteil "update-mime-database" nicht ausgeführt wird vom "strip" target.

    Kann ich, update-mime-database wird NUR ausgeführt, wenn es kein PORTABLE build ist UND DESTDIR nicht gesetzt ist. DESTDIR sollte man beim Paketieren ja eigentlich immer setzen :)


    edit: "strip" führt das sowieso nie aus, das tun nur die "install" targets -- aber wie gesagt nicht, wenn man mit DESTDIR installiert.

    Okay, danke. Bei diesem fehlte in der Tat das DESTDIR noch :rolleyes:

    ich muss noch etwas mit dem Mimetypen fixen

    Hi, kannst du mir erklären, was da "gefixt" werden muss? Gerne auch per PM ... nur für den Fall, dass ich da upstream was falsch gemacht habe?

    "Fixen" ist wohl übertrieben und ich glaube auch nicht das im Upstream was falsch ist ;-)

    Ich muss mir Dein Buildsystem nur noch einmal anschauen (es sei Du kannst gleich adHoc die Antwort geben), damit der Anteil "update-mime-database" nicht ausgeführt wird vom "strip" target.


    Die Database Aktualisierung muss ich im Post-Install machen. Auf die Schnelle habe ich das jetzt mit einem sed gelöst, bevor der Package-Build startet.

    Ich denke es wird da aber noch eine etwas saubere Lösung für geben (irgend ein Flag o.ä. dem Make übergeben).

    Btw. Ich habe mir Dein Buildsystem noch nicht genauer angeschaut, aber auf dem ersten Blick scheint es immer in das jeweilige Projekt miteingebunden werden zu müssen?

    Ich dachte kurzeitig darüber nach, dass Buildsystem als eigenes Paket zu machen (würde ich dann aber erst in späteren Versionen machen).

    Ne, das ist darauf ausgelegt, als git submodule eingebunden zu werden, eigenes Paket wäre also recht sinnlos. Das ist leider tatsächlich ein bisschen blöd beim Paketieren, weil Github keine Funktion hat, einen tarball mit submodules rauszugeben :( -- ist mir auch beim Port für FreeBSD aufgefallen. Ich hab das da mit einer kleinen custom rule nach dem Entpacken gelöst:

    Dachte ich mir so schon :) Ist aber für das Arch-Paket kein Problem.


    Quote

    Na DEN Aufwand könnte ich auch selbst betreiben ;) Meine Hoffnung war, dass das einfach jemand macht, der sowieso so ein System nutzt :)

    Naja, ich habe schon Systeme mit Debian, aber das sind meine Server und da werde ich das Paket nicht bauen :)

    Ich muss mir aber eh für andere Zwecke noch eine Maschine aufsetzen - daher wäre es nicht so dramatisch; ist halt nur nicht zeitnah ;-)

    Moin,

    Da bin ich leider nicht der richtige für so etwas. Ich bin kein Fachmann der programmieren kann, sondern nur normaler Linux-Nutzer.

    Schade ;) Ich hoffe es finden sich mal ein paar Linux-User, die Pakete bauen :)

    Ich bin gerade dabei erst einmal für Arch ein "Paket" zu bauen. Die sollen dann auch im AUR landen.

    Bin aber erst einmal dabei das für die lib1541img zu schnüren - mir sind da ein paar Fallstricke aufgefallen, die ich beim Package berücksichtigen muss - und dann kommt das GUI Tool.


    Ein *.deb muss ich mal schauen - das war auch nicht so schwer, allerdings muss ich mir dazu erst einmal auf einer Maschine oder VM etwas Debian-basierendes installieren.


    Btw. Ich habe mir Dein Buildsystem noch nicht genauer angeschaut, aber auf dem ersten Blick scheint es immer in das jeweilige Projekt miteingebunden werden zu müssen?

    Ich dachte kurzeitig darüber nach, dass Buildsystem als eigenes Paket zu machen (würde ich dann aber erst in späteren Versionen machen).

    Travis-CI ist eigentlich ganz gut, gerade wenn Du viel merge oder push Aktionen hast.

    Dann wird Travis einfach getriggert, der Code durchläuft einmal den Buildprozess und Du weißt sofort ob die Codeänderung Dein Projekt zerschießt oder nicht.


    Travis sollte Linux (iirc Ubuntu-Basis), macos und eine Windows Buildenvironment bieten.

    ich antworte Dir mal auf Deinen "run-crash-fehler" dennoch hier, hoffe das ist okay :-)


    In deiner "run.asm" hast Du folgenden Code, der bei einem run ohne Zeilennummer ausgeführt wird:

    Code
    1. _END_RUN nop
    2. ;jsr CLR_KEYBUF
    3. ;WICHTIG! Zeiger auf Programm Ende setzen
    4. lda $ae ;low
    5. sta $2d
    6. lda $af ;high
    7. sta $2e

    In $2d/$2e ist der Zeiger auf das Basic-Programmende und in $ae/$af ist das Programmende für load/save.

    $ae/$af ist aber so auf #$00 gesetzt und somit überschreibst Du den Zeiger auf das Programmende.


    Nach dem obigen Code kommen noch folgende Befehle:

    Code
    1. ;Programm als BASIC Programm starten
    2. JSR $A68E ;CHRGET-Zeiger auf Programmstart
    3. jsr $A533 ; Link-Pointer (evtl.) korrigieren
    4. jsr $A659 ; CLR, TXTPTR zurücksetzen
    5. jmp $A7AE ; und ab in die Interpreterschleife


    Und in $a659 werden die dann noch ein paar weitere Basic-Zeiger überschreiben, so dass beim anschließendem ändern der Zeilen, dein Baisc-Speicher etwas zerwürfelt wird (da Zeiger falsch) und so nimmt das alles seinen Lauf.


    Ohne jetzt weiter in den Code zu schauen, behaupte ich mal Du müsstest das Label "_END_RUN" etwas anpassen.