Hallo Besucher, der Thread wurde 1,1k mal aufgerufen und enthält 4 Antworten

letzter Beitrag von Zirias/Excess am

ACME und o65 fileformat vom cc65.

    Hi Leute,


    evtl koennt ihr mir helfen, zZ bin ich dabei fuer ein online hacker spiel, welches noch in der WIP phase ist (link: Hackers-Edge)
    ein paar sachen zu programieren. die server und maschienen in diesem spiel laufen als virtuelle 65C02s programiert in Phyton soweit ich weis,
    man kan code fuer seine maschiene in cc65 oder auch in asm schreiben. da ich nun aber nich so konfirm bin mit cc65 oder aehnlichem
    dachte ich mir muss doch auch mit ACME gehn. geht auch soweit mein BIOS ist fertig. nun moechte ich aber auch noch programme
    laden, dachte mir einfach ein programm ans bios anheangen und gut. das ist aber nicht so die feine sache wenn man bedenkt
    das das bios nix mit dem eigendlichen programm zu tun hatt.


    also hier meine frage giebt es header die das o65 format in ACME nachbilden oder muesste ich mich durch die fileformat beschreibung durchackern
    und eine eigene schreiben?


    die frage stelle ich da ich den ACME einfach einfach zu benutzen finde und er auch alle meine wuensche erfuellt, von daher moechte ich undgern
    auf eine/n andere assembler oder sprache umsteigen.


    danke fuer eure hilfe
    salute

    Das .o65-Format wird von ACME bisher nicht unterstützt. Wenn ich mich richtig erinnere, war der Hauptvorteil dieses Formats, Positions-unabhängigen Code abbilden zu können. Wirklich sinnvoll ist das erst in Verbindung mit einem entsprechenden Loader auf einem Multitasking-Betriebssystem.
    Ich bin mir nicht sicher, ob das wirklich Deinem Anwendungsfall entspricht.

    .o65 hat (wie object-files auf modernen systemen auch) symboltabellen für relocation und linken (export, import) mit segmenten. Das hat also durchaus seinen sinn auch ohne multitasking: Man kann unabhängige codeteile unabhängig voneinander compilieren oder assemblieren und erst später zusammenlinken. Im code legt man nur fest, was in welches segment gehört (code, data, bss, zeropage oder selbst definierte segmente), der linker weiß dann durch konfiguration welche speicherbereiche dafür zu füllen sind. Das ist sehr flexibel und komfortabel für größere Projekte.


    Ein "endprodukt" im .o65 format ist natürlich nur sinnvoll mit einem entsprechenden system drumherum, das so etwas dynamisch laden kann.


    @Haubitze ein anderer Assembler ist in der Regel keine große Herausforderung. Habe schon viele verwendet -- mein liebster ist zwar der ca65, aber komme trotzdem auch mit anderen klar. Die Unterschiede sind größtenteils Feinheiten (label mit oder ohne doppelpunkt, pseudoops mit ! oder . usw), abgesehen von besonderen features. Probiere doch für DIESES vorhaben einfach mal den ca65, das wird schon klappen ;)

    alles klar, danke leute. dann werd ich mir den ca65 wohl mal anschauen muessen.
    das ganze moechte ich verwenden damit ich zB treiber oder aehnliches einfach nachladen kann.
    das ganze spiel stellt eigendlich nur eine grundmaschiene fuer den spieler zur verfuegung welche man dann
    selber programieren kann. dazugehoeren dann zB netzwerk treiber, blockdevices, cffa cards(apple II glaub),
    demnaechst soll noch eine MMU dazukommen und so weiter.


    daher dachte ich das das o65 format eine gute sache waehre, so das der user einfach nur nachlaed und sich keine
    gedanken machen muss wo das prg im speicher liegt. natuerlich benoetigt man dann einen kernel mit speichermanager den
    man sich ja selberschreiben muesste.


    das ganze finde ich aber trozdem sehr intressant.


    nunja ich schau mir den ca65 mal an.


    salute und danke nochmal :)