CBM 3032 Programm aus Basic laden

    Ich möchte ein Programm, welches mittels TIM im Speicherbereich hex0280 bis hex6800 auf SD-Karte (petsd+) abgespeichert wurde, von einem Basic-Loader aus laden.

    Dieser Loader sieht prinzipiel wie folgt aus:

    10 load "beispiel",8

    Nach Ausführen des Loaders wird das Programm nur unvollständig geladen und läuft nicht.

    Workaround ist, den Loader unter TIM auch im Speicherbereich hex0280 bis hex6800 abzuspeichern.

    Gibt es eine andere Lösung? Einstellen bestimmter Pointer?

    Ich vermute mal das ist wie beim C64, Daten oder Maschinensprachprogramme lädt man mit LOAD"BEISPIEL",8,1 dann sollte es auch an die Adresse $0280 landen.
    Mit LOAD"BESPIEL",8 lädt man an die BASIC Startadresse $0401.

    Es wäre ganz gut zu wissen was du genau vor hast.
    Welches BASIC hast du? 3.0 oder 4.0

    Soll das ein selbst startendes Programm werden? Wozu dann der Loader?

    Nein, das Problem liegt nicht dort. Die Bereiche unterhalb hex0400 werden einwandfrei geladen (Kontrolle mittels Disassembler) , bei bestimmten Pointer-Einstellungen auch das gesamte Programm. Es lässt sich dann einwandfrei bis zur letzten Zeile listen, aber nicht starten. Fehler wie "out of memeory error" treten auf. Irgend etwas mit den Pointern auf das Basic-Ende etc. stimmt nicht!

    Mittels TIM (ein CBM-Tool, existiert nicht für C64?) kann man ein Programm mit gewählter Start- und Endadresse abspeichern. Beispiel:

    sys 4

    . s "beispiel",08,0400,6800

    der Speicherbereich wird unter dem Namen "beispiel" von hex0400 bis hex6800 auf Laufwerk 8 abgespeichert.

    Du überschreibst mit dem Programm System Bereiche unter anderem die beiden Tapebuffer.
    Die übrigens bei $027A anfangen, bei $0280 liegt der zweite Buchstabe des Dateinamens.
    Durch diese alternative Ladeadresse setzt du die Automatic die bei BASIC Programmen die Pointer automatisch korrekt setzt außer Kraft, daher die Frage was soll das?
    Schonmal daran gedacht den Maschinensprach Code zuerst zu laden und dann das BASIC Programm? und nicht das ganze als Block.

    Dort liegt nicht das Problem! Das Problem taucht immer auf, wenn man von einem kleinen Basic-Loader-Programm ein größeres auch reines Basic-Programm lädt. Alle Adressen des Loader-Programms bleiben irgendwie erhalten, so dass das nachgeladene Programm nicht läuft!

    Definitiv kein Problem des Maschinecodes unterhalb 0400!! Vergiss den!

    Das Problem ist, das BASIC LOAD nur im Direktmodus korrekt unterstützt zumindest wenn du versuchst etwas größeres als das zuerst geladene Programm zuladen.

    Falls du BASIC 4.0 hast versuch es mal mit DLOAD, das müsste eigentlich im Gegensatz zu LOAD auch als Teil eines Programms funktionieren.

    Der C64 Trick müsste angepasst auch auf dem CBM mit BASIC 2/3 funktionieren:

    Quote

    Im Emu hat das nur 1 mal geklappt.

    Hier ist ein Artikel dazu:
    https://web.archive.org/web/2022111301…978_oct_nov.pdf

    Seite 11

    Zu Beitrag #2 der CBM kennt die Sekundäradresse nicht mit der Funktion Unterscheidung an Basicstart laden ohne und mit ,1 an die original Adresse. Der CBM lädt immer and die Adresse die bei Speichern genutzt wurde.

    Mad gibt es einen Trick wie man die Zeilennummern beim Codeblock abschalten kann?

    Woher weißt du den das vom BASIC definierte Ende vom größeren Programm? Und den Anfang der Variablen.

    Leider antwortest du ja nicht auf Fragen.

    Wenn das Zweite ein BASIC Programm ist kannst du die korrekten Werte ja einfach auslesen.
    Wenn du statt mit einem Loader versuchst alles zu laden vom großen BASIC Programm (angenommen es ist ein) die ML Routine im Tapebuffer nach lädst sollte es keine Probleme geben. (bin ich mir aber nicht sicher)
    Hier noch ein Beitrag zu der Problematik: https://www.atarimagazines.com/compute/issue6…am_Chaining.php

    Quote from natas

    Mad gibt es einen Trick wie man die Zeilennummern beim Codeblock abschalten kann?

    keine Ahnung, aber ich noch nichts mit gemacht und auch noch nicht rausbekommen wie man die weg bekommt .

    Eine ADMIN schläft nicht er ROOT

    Mein Inventar :-)

    mehrere C64, Dolphin Dos 2, SD2IEC, MMC2IEC, IECATA V2, XS-1541, XU-1541-SD, SwinSID X2, 1541U+ eth, Easyflash 1+3, DIAG-BLACK II, Chameleon 64 mit RR-Net, TuningBoard64, Modular64, 64Micro, KFC, WIC64 :thumbup:

    Welche Antworten schulde ich dir denn?

    Der C64-Ansatz ist interessant, in diese Richtung hatte ich auch schon gedacht und getestet. Leider funktioniert er beim CBM3032 nicht, möglicherweise wegen der Adressen 624, 625 und 158. Habe versucht, entsprechende Zero-Page Adressen des CBM hier einzusetzen, bisher ohne Erfolg.

    100 QO$ = CHR$ (34) : REM DEFINE QUOTE FOR PRINTING
    110 REM PRINT ENTRIES TO THE SCREEN IN PROPER SPOTS
    120 PRINT" {CLEAR} {03 DOWN} LOAD"; QO$; "INVISIBLE WEDGE"; QO$; ",8"
    130 PRINT"{04 DOWN} RUN"
    140 PRINT"{DOWN} LOAD"; QO$; "PRINTER"; QO$;",8"
    150 PRINT"{04 DOWN}RUN"
    160 PRINT "{02 DOWN}LOAD"; QO$; "WORD PROC"; QO$;", 8"
    170 PRINT"{04 DOWN}RUN{HOME}"
    180 REM POKE SIX RETURNS INTO KEYBOARD BUFFER
    190 REM POKE # OF RETURNS INTO LOC. 158
    200 FORI = 1TO6 : POKE622 + I, 13 : NEXT : POKE158, 6

    Bootmaker For VIC, PET and 64

    Hab es endlich gefunden.

    Du hast mir mal wieder auf die Sprünge geholfen. Der Artikel aus dem Atarimagazin war sehr hilfreich!

    Meine Lösung ist:

    1. Größtes der Programme laden, um Pointer zu ermitteln, dann
    print peek(42),print peek(43)
    Beispiel:
    peek(42)=216 (LO byte)
    peek(43)=103 (HI byte)


    2. Ladevorgang Beispiel:
    10 poke42,216:poke43,104 <= Hi byte + 1 !!
    20 poke44,216:poke45,104
    30 poke46,216:poke47,104
    40 load”wortpro3”,8

    Einfach, aber erfolgreich!

    Bezüglich ROM: leider sind alle Sockel bei mir EPROMs belegt.

    1. Newtim (Assembler und Disassembler)

    2. Basic Expand (Erweiterung um renumber, append, ...)

    3. Multidot (Pixel-Grafik für dem CBM3032)

    Wordpro3 habe ich hier nur als Beispiel eingefügt. Es handelt sich um einen Wortprozessor, mit dem ich seinerzeit meine Dissertation schrieb. Siehe:

    /pub/cbm/pet/utilities/text/

    Wordpro3 ist nicht im ROM-Bereich, sondern auf der SD-Karte. Es ist ein Maschinenprogramm, dem ich seinerzeit Umlaute verpasst hatte (mit Hilfe eines deutschen Character-ROMS).

    Übrigens funktioniert die o.g. Methode für einen Loader nur bei Basic-Programmen . Ich habe einige Tests gemacht.

    Quote from Aguetul

    Wordpro3 ist nicht im ROM-Bereich, sondern auf der SD-Karte. Es ist ein Maschinenprogramm, dem ich seinerzeit Umlaute verpasst hatte (mit Hilfe eines deutschen Character-ROMS).

    Übrigens funktioniert die o.g. Methode für einen Loader nur bei Basic-Programmen . Ich habe einige Tests gemacht.

    BASIC 4 hat da DLOAD damit sollte es klappen.
    Aber warum ist dieser Loader überhaupt notwendig? Ist das irgendwie rekonstruiert? Warum kann man es nicht einfach direkt laden?
    Oder ist das ein verkürztes Menü welches sich in der Mache befindet.

    Ich habe eine kleine Microshell angelehnt an die Linux-Bash in Basic geschrieben. Diese verwende ich, um mich im Filesystem zu bewegen. Befehle wie cd, cp, date, ls, uname, mkdir, rm, rmdir etc. können ausgeführt werden. Auch starte ich damit Programme direkt, wie z.B. wordpro3, dafür benötige ich den Loader.

    Natürlich hätte ich das alles gerne als Maschinenprogramm einem ROM. Dafür fehlt mir aber sowohl das Knowhow als auch der Antrieb.

    Verwendet werden die sd2iec-Kommandos (C64, VC20), die auch unter petsd+ (CBM3032) gleichermaßen existieren.

    Wenn es so weit fertig ist, kann man es kompilieren und dann tatsächlich auch in ein ROM brennen.

    Da bei dir alle Sockel bereits belegt sind müsste man sich etwas überlegen.

    Das Multidot ROM ist vermutlich das ROM welches am seltesten genutzt wird, daher würde es sich anbieten hier einen ROM Umschalter zu verbauen, also einfach ein größeres EPROM und die höheren Adressleitungen werden im einfachsten Fall durch einen Schalter oder einen kleinen Microcontroller der Tastenkombinationen abfängt und umschaltet.

    Beim 3032 ist ja normal keine interne Datasette verbaut, hier würde sich ein C64 Tapecart gut machen die Hardware und die Firmware sollte kompatibel sein nur die Menü-Software müsste angepasst werden.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login