Posts by will

    Wie kann ich ein angeschlossenes SD2IEC identifizieren ohne dass ich dem Laufwerk einen Reset-Befehl schicke? Also mit

    Code
    1. 10 open 1,x,15,"ui"
    2. 20 input#1,ff$,fb$,sp$,se$
    3. 30 close 1

    bekomme ich zwar einen String der das Laufwerk identifiziert, das "UI"-Kommando resetiert aber das Laufwerk (eine 1541er vergisst dabei zum Beispiel ihre geänderte Laufwerksnummer). Wie könnte ich ein angeschlossenes SD2IEC identifizieren ohne "UI" zu verwenden?

    Snoopy, stimme dir absolut zu. Ich entwickle Spiele für den C64 und verwende dazu leistungsstarke PC-Tools wie cc65, ca65, exomizer, multipaint, charpad, spritepad, make, etc. Diese Tools würde man auch auf dem C128 so nicht hinkriegen (allein schon meine Assemblermalrdefinitionen würden den Speicher füllen), darum sind Spieleentwicklungstools heutzutage keine Killeranwendung mehr.

    Bleiben Games...

    Beim Coden für den C128 bin ich immer ambivalent.


    Einerseits gilt: C128 > C64


    Andereseits habe ich immer das Gefühl, ein C128er-Programm muss Features verwenden die am C64 nicht möglich wären. Und dann ist man ziemlich eingeschränkt und plagt sich mit VDC oder Z80 ab. Am besten ist er eigentlich für Anwendungsprogramme geeignet, wäre die optimale Plattform für Zeichenprogramme, Kopierprogramme, Packer, Textverarbeitungen oder Entwicklungsumgebungen die Compiler, Quellcode und Compilat gleichzeitig im Speicher haben. Aber dafür haben wir jetzt Cross-Development-Tools auf Windoof und Linux...

    Anbei das Hypraload mit Autostart und automatischer Nachladefunktion.


    Mit

    Code
    1. LOAD"^*FILENAME",8,1

    (^ steht für Pfeil nach oben) wird Hypraload geladen, gestartet und installiert und dann FILENAME schnell nachgeladen un gestartet.
    Bei einem File mit 116 Blocks war das alles mitgerechnet 4 Mal schneller als ohne Speedloader.

    Das Laden mit dem Pfeil im Filenamen finde ich nicht so schlimm, aber man muss halt auf jeder Diskette das Hypraload draufkopieren, was man sich bei einem HW-Schnelllader spart.

    Coole Sache! Super Performance, grafisch sehr schön gemacht und gute Anwendung für den ECM. Wenn man in den Code reinschaut sieht man aber auch dass das sehr viel Arbeit gewesen ist, wie lange hast du dran gearbeitet?

    Is there a way to jump into a monitor like it can be done with VICE?

    In particular, I would like to view the status of the VIC-IV chip to see at what addresses are currently used for charset, sprites, etc. and to inspect memory areas.

    Diddl: Gute Frage :-) ... Du hast Recht, man sollte konsequent sein. Ich schau mir diese Routine mal an. Aber für mich erklärt sich dann immer noch nicht, weil Du geschrieben hast der Farbwert wäre zufällig, warum es nach Druck auf Return funktioniert. Der Farbwert wird doch beim Einsprung (main) gesetzt.


    Danke Dir

    Am Beginn von Main setzt du den Farbwert in $286. Das beeinflusst (1) alle folgenden Zeichen die über CHROUT ausgegeben werden und (2) den Farbwert der beim Bildschirmlöschen in den Farbspeicher geschrieben wird.


    Da du CHROUT nicht verwendest hat der geschriebene Farbwert keinen Effekt bis du Return drückst, damit löst du die Bildschirmlöschroutine aus und diese setzt die Farbwerte.

    So, dank Eurer Tips habe ich jetzt ein Problem lösen können. Die Zeichen werden nun nacheinander ausgegeben. Bleibt noch die Textfarben Geschichte. Das funktioniert nur, wenn ich einmal Return gedrückt habe, das verstehe ich nicht. Hat da jemand auch noch einen Tip für mich ?? Weiss jemand zufällig welchen Code die CHRIN Routine für Run/Stop zurückgibt ??? Ich dachte gelesen zu haben, das es die 103 ist, deshalb ja auch der (falsche) Vergleich auf #$103 ... seitdem ich aber die (hoffentlich :-) ) dezimale 103 (#103) drinhabe funktioniert es nicht mehr.


    Danke Euch

    Stop key kannst du am besten über die ZP Adresse $91 überprüfen:


    Code
    1. bit $91 ; check STOP key
    2. bpl quit ; if pressed, quit program

    Mike: vielen Dank für den alles berücksichtigenden Beitrag. Ich habe mir jetzt einen Einfiler gebastelt der ein Programm unabhängig von der Lademethode und von der Speicherwerweiterung an Adresse $1000 kopiert und dann startet. Im Falle von ",8,1" muss sich das Programm selbst nochmal mir ",8" laden da ein Teil im Loch zwischen $400 und $fff verlorengeht, ist bei Programmen von maximal 3,5k Länge aber halb so schlimm.


    Der VC20 hat ja, je nachdem welche Speichererweiterung drinsteckt seinen BASIC-Beginn bei 4097, bei 1025 oder bei 4609. D.h., ein Maschinenprogramm mit SYS-Zeile, das für die kleinste Speicherversion geschrieben ist funktioniert nicht mehr wenn es auf einem VC-20 mit Speichererweiterung geladen wird.
    Abgesehen vom SYS-Befehl ist es auch sehr schwierig, ein Maschinenprogramm voll relokatibel zu schreiben.


    Gibt es da einen Trick wie man ohne großen Overhead ein Programm hinkriegt das in Assembler geschrieben ist, mit LOAD und RUN gestartet wird, und unabhängig von der Speichererweiterung läuft?

    So richtig korrigiert ist es ja nicht, es wird einmal anfangs der Fokus drauf gesetzt, und dann gibt es noch ein Script-Teil, dass aufpaßt, dass die Audio-Objekte nicht überlappen bzw. mehrfach angelegt werden. Ich hab das auch nur irgendwo geklaut :)

    Danke, darf ich es von dir klauen übernehmen? Hast du nur am Aufrufscript gebastelt oder auch an x64.js?

    Endurion, verstehe ich richtig dass du den x64s von Rijanek gefixt hast? Wie hast du das mit dem Sound hinbekommen?

    Ich bin, trotz der Verfügbarkeit anderer Webemulatoren sehr an Rijaneks Vice.js interessiert weil der auch den C128 unterstützt, das habe ich bis jetzt noch nirgendwo anders gefunden.

    Bei bisherigen Projekten war der CC65 in Verbindung mit seinem Assembler sehr nützlich für mich. Ich habe auch gelernt dass das Ding extrem viel kann und dementsprechend komplex ist.


    Allerdings bin ich noch nicht draufgekommen, wo sich User mit Fragen dazu austauschen, das scheint ziemlich verteilt zu sein. Es gibt ein paar Threads hier im Forum (die aufgrund der Sprache naturgemäß auf eine Gruppe aus 3 Ländern eingeschränkt ist), bisschen was in der csdb, in lemon64, in NES-Entwicklerforen, auf retrocomputing.stackexchange.com, ...

    Alles ziemlich versprengt...


    Früher gab es eine Mailingliste zu cc65, diese ist aber nicht mehr in Betrieb soweit ich das sehe. Das cc65-Projekt wird hingegen noch immer fleißig weiterentickelt, letztes Update war vor ein paar Tagen.


    Habe ich etwas übersehen oder gibt es wirklich kein zentrales Entwicklerforum für cc65?

    Ich würde gerne ein Assemblerprogramm in ca65 mit Makros in ein Assemblerprogramm mit aufgelösten Makros umwandeln, um beim daraus entstehenden Code ggf. noch händisch oder automatisch Optimierungen vorzunehmen. Danach soll das Assemblerprogramm in ausführbaren Code assembliert werden.


    Ist das möglich und welche Optionen muss ich angeben, um ein aufgelöstes Assemblerprogramm zu erzeugen?


    Im Moment assembliere ich mit folgender Kommandozeile:


    Code
    1. ca65 myprog.s
    2. cl65 myprog.o -C c64-asm.cfg -u __EXEHDR__ -o myprog.prg

    bzw. in einem Schritt mit


    Code
    1. cl65 myprog.s -C c64-asm.cfg -u __EXEHDR__ -o myprog.prg

    Grade getestet, hört sich hervorragend an! Schade dass ich keine SuperCPU in der Originalhardware habe.


    Meine Frage ist aber eigentlich wie man ein Audio am besten bearbeitet, wenn Player und Abspielrate vorgegeben sind.


    Welche Bearbeitungsschritte hast du durchgeführt um das Sample sauber hinzukriegen? Ich nehme an du hast einen Tiefpass vor dem Heruntersamplen verwendet. Wie steil hast du den Tiefpass eingestellt und auf welche Frequenz im Vergleich zur Abspielfrequenz?