Hello, Guest the thread was viewed2.4k times and contains 12 replies

last post from InsertDisk2 at the

Verständnisfrage: Laden eines PRG aus dem Netz ohne Kernal

    Moin,


    btw. wäre eine Rubrik für Entwicklungsfragen nicht schlecht, oder habe ich die wieder nur nicht gesehen?


    Ich versuche mich gerade daran, ein PRG aus meinem Repository zu laden, ohne den Kernal zu verwenden, also unter Verwendung der WiC Universal Routinen.

    Der folgende Code wirft schon mal keinen Fehler, aber dass nichts passiert ist denke ich klar.


    Display Spoiler

    Ich habe die Adresse für A aus dem Beispiel für die IP hergenommen, was natürlich für ein Spiel Blödsinn ist, denn das muss ich i.d.R. ja in den Basic-Speicher laden.

    Darin befindet sich aber ja mein Programm, was in dem Fall überschrieben werden würde.


    Mein nächster Gedanke ist es, das Spiel an eine höhere Speicherstelle zu laden und dann mit einer Assembler-Routine die Daten an den Basicspeicher kopieren. Die Länge der Daten könnte ich ja über $A9 und $AA auslesen, sofern mein Vorhaben überhaupt Sinn ergibt. :P

    Warum per Assembler-Routine? Das soll am Ende eh in Assembler umgeschrieben werden, daher bspw. auch SYS 49152+6 und nicht SYS 49152+12.


    Frage: Ist der Weg komplett falsch oder besteht Hoffnung?

    ^^

    Quote from DP64

    Mein nächster Gedanke ist es, das Spiel an eine höhere Speicherstelle zu laden und dann mit einer Assembler-Routine die Daten an den Basicspeicher kopieren.

    Also wenn Du selbst Assembler kannst, dann würde ich nicht eine Kopierroutine nehmen, sondern direkt in den Speicher laden wo es hin gehört. Geht dann doppelt so schnell.


    Anbei mal ein Vorschlag in Assembler - Laderoutine ist bei $CF08 = SYS 53000 - Da darf der Dateiname aber auch nicht viel länger werden, sonst gerätst Du in den RAM-Bereich vom VIC. Alternativ nach $0400 schieben - Da hast du viel Platz ;-)

    Quote from KiWi

    Also wenn Du selbst Assembler kannst, dann würde ich nicht eine Kopierroutine nehmen, sondern direkt in den Speicher laden wo es hin gehört. Geht dann doppelt so schnell.

    Soll auf jeden Fall später in Assembler umgesetzt werden, danke für den Hinweis.


    Quote from KiWi

    Anbei mal ein Vorschlag in Assembler

    Danke schön. :thumbup:

    Schaue ich mir heute Abend mal an, bin aktuell auch mit den Test Tools beschäftigt.

    Quote from SkulleateR

    Könnte man den Namen (httpname) auch von einem Basic Loader aus übergeben (über einen String oder eine bestimmte Speicherstelle) und dann über SYS53000 das PRG starten ?

    Von Basic aus nimmst Du dann lieber die Universalroutine von YPS - Die ist genau für so etwas gedacht ! -> http://www.wic64.de/downloads/

    Quote from KiWi
    Quote from SkulleateR

    Könnte man den Namen (httpname) auch von einem Basic Loader aus übergeben (über einen String oder eine bestimmte Speicherstelle) und dann über SYS53000 das PRG starten ?

    Von Basic aus nimmst Du dann lieber die Universalroutine von YPS - Die ist genau für so etwas gedacht ! -> http://www.wic64.de/downloads/

    Uhm, die Universal Routine ersetzt doch aber nicht die TAPE LOAD Routine ? Wie kann ich denn damit ein PRG laden von Basic aus :gruebel ?

    Mir der Routine wird der Code ja an die Ladeadresse des Files (ersten beiden Bytes) geladen. Wenn ich jetzt z.b. ein SID Tune damit laden will und die Adresse wo ich es denn gerne hin haben möchte mit zwei vorangestellten Ladebytes angebe, woher weiss dann mein Programm, nach dem Laden, wo das Programm/SID im Speicher steht?

    Steht die auch in $a7ae? Oder muss ich einen anderen Ansatz wählen?

    Quote from InsertDisk2

    Wenn ich jetzt z.b. ein SID Tune damit laden will und die Adresse wo ich es denn gerne hin haben möchte mit zwei vorangestellten Ladebytes angebe

    Ein SID enthält ja auch die Abspielroutine - und die ist ja nich mal so "eben" relocatable - Also Speicherbereich "aussuchen" und dann da hin laden wo man will und Abspielen geht so nicht - Da musst Du Dir die ASM Routine von mir umschreiben und lädst dann die Daten da hin wo Du willst - vorher aber die Abspielroutine anpassen.

    Ganau, also folgendes Szenario.

    Ich suche aus meiner DB ein SID aus und weiß dadurch, dass es z.b. an $1000 (ohne Header) geladen werden muss. Ich setze vor das SID (ohne Header) $00 $10 und er lädt das dann auch sauber an $1000. Im Monitor den Code verglichen, passt. Alles wird geladen.

    Ich hab mich jetzt ein wenig mit deinem prgloader.asm auseinandergesetzt und weiß jetzt, dass die Ladeadresse dann in $fc $fd steht? Für was sind $fa $fb? Das habe ich noch nicht durchblickt.

    Quote from InsertDisk2

    Für was sind $fa $fb?

    Code
    1. jsr read_byte
    2. sta $fa
    3. jsr read_byte
    4. sta $fb ; Länge der Datenübertragung Byte 1 und 2

    Da steht die Anzahl der nun folgenden Bytes drin - diese Anzahl der Bytes wird dann gelesen und in den Speicher geschrieben wird.


    Sind für dein Vorhaben eigentlich Irrelevant.

    Ah ok, wenn ein Fehler vorliegt, wurde der Fehler Code übermittelt anstelle der Datengröße, der dann unter Loaderrorcheck geprüft wird?

    Soweit so gut, ich habe jetzt folgende Änderung vorgenommen. Am Ende von cleanup: habe ich

    Code
    1. ; jsr $a659 ; clr
    2. ; jmp $a7ae ; run
    3.      rts

    auskommentiert und ein einfaches rts eingefügt, er soll nach dem Laden einfach wieder zurück zu Basic. Jedoch scheint er in einer Endlosschleife zu stecken.

    Auch ein ändern der Rahmenfarbe vor cleanup: und danach vor rts zeigt keine Änderung in der Rahmenfarbe. Er scheint in den Bereich nicht zu kommen.

    Quote from InsertDisk2

    Jedoch scheint er in einer Endlosschleife zu stecken.

    Ja, der Loader ist für PRG und nicht für RAW Data an eine bestimmte Adresse. Du musst von der Länge in $FA $FB zwei Bytes abziehen.


    Probier es mal mit dem Sidloader im Anhang. Das SID darf natürlich den PSID Header nicht haben - den müsstest Du Dir abschneiden bzw. Auswerten.


    Hier wäre der Init SYS32768 ($8000) und der IRQ müsste SYS32768+18 ($8012) aufrufen. In Basic:

    Code
    1.  10 SYS 53000
    3. 20 SYS 32768
    5. 30 SYS 32678+18
    7. 40 GOTO 30


    Works - but very awful !

    Ha, man, ich dachte noch wieso kopiert er 2 Bytes mehr.

    Nachdem ich die beiden Bytes abgezogen habe funktioniert es wie es soll!


    Top! 1000 Dank für die Hilfe!