Hello, Guest the thread was called1.4k times and contains 20 replays

last post from Pusti64 at the

GeoDesk64 intern

  • Wollte mir dann doch mal Sourcecode anschauen und ggf. Stück für Stück an den C128 anpassen. Mal schauen wie weit ich komme ;-)


    Pusti64

  • Wollte mir dann doch mal Sourcecode anschauen und ggf. Stück für Stück an den C128 anpassen. Mal schauen wie weit ich komme ;-)

    Viel Spaß :) Ich würde mich freuen wenn es klappt, aber Du musst ja die X-Koordinate an 40/80Z anpassen. Das benötigt extra Speicher... Vielleicht kannst Du den Code ja weiter optimieren:thumbup:

  • Ein paar Hintergrundinfos würden die Arbeit natürlich ungemein erleichtern ;-)


    Pusti64

    Naja... Müsstest Du schon genauer fragen...

    So für den Anfang:

    S.mod* sind die VLIR-Module, da werden dann die einzelnen Quelltexte mit gleicher Nummer eingebunden...

    -101_wm* ist der windowmanager.

    -102_* ist der Kerndesktop der dann Menüs und Fenster öffnet.

    -103_* ließt Dateien, Partitionen usw als Dateieinträge ein. Die Darstellung selbst läuft aber über 102 und 101_wm...

    Die restlichen Module sind selbsterklärend.

    Ich würde aber erstmal den 40Z-Modus testen, denn überall wo auf den C64 Kernal zugegriffen wird müsste ggf. Was an den 128er angepasst werden. Z.b. bei Dateizugriffen mit Dateinamen müsste man die Bank für den Dateinamen setzen...

  • Ja, dass gibt so schonmal einen guten Überblick, wo man was finden kann.

    Muss mich unteranderem auch erstmal an Deinen Programmierstil gewöhnen.

    Mit welchem Sourcecode werden denn z.B. die Datei-Icons ausgegeben?


    Pusti64

  • Mit welchem Sourcecode werden denn z.B. die Datei-Icons ausgegeben?

    Schau Dir vielleicht erstmal 102_WinDataTab an:

    Jedes Fenster besteht aus einer Datentabelle mit Angaben zum Fenster. DeskTop und Arbeitsplatz sind feste Tabellen, die für ein Dateifenster wird in den Fensterpuffer kopiert und dann für das Fenster angepasst.

    In der Datei steht auch drin, welche Routinen für welche Funktionen aufgerufen werden, zumindest übergeordnet.

    Icons werden über 102_DoIcon und übergeordnet mit 102_DoFileEntry ausgegeben.


    Evtl. lädst Du dir die Dokumentation/Text-Dateien von Area6510 herunter. In den Textdateien lässt sich dann leichter suchen.


    Ich vermute Du fragst nach der Routine weil die nicht direkt funktioniert. Das liegt u.A. daran das ich nicht die GEOS-Routine BitmapUp verwende, die ist zu langsam. Ich kann ja eh nur ganze Cards nutzen (wegen den Farben), daher schreibe ich direkt in das GrafikRAM.


    Da das ganze Tech-Gebabbel evtl. nichts für den normalen Anwender ist (und damit hier evtl. Neuerungen zu GeoDesk64 in Code-Gelaber untergehen):

    Evtl. kann ein Mod / FXXS die Beiträge #501,503,507,522,523 und diesen Beitrag selbst in einen neuen Thread "GeoDesk64 intern" auslagern... Danke :)

  • Mal schauen wie weit ich damit komme bzw. verstehe was Du da programmiert hast.

    Ist ja nur ein Versuch bzw. Test und wenn es nichts wird, dann gibt es ja zur "Not" noch den Desktop128 ;-)


    Pusti64

  • Konnte ich... ;)

    Danke! :)


    Mal schauen wie weit ich damit komme bzw. verstehe was Du da programmiert hast.

    Der Code ist ja eigentlich gut kommentiert... ist zwar lästig und manchmal bin ich da auch etwas nachlässig, aber ich tue mein bestes.


    Da wird es aber viele Baustellen geben. Eben passe ich ja das Sortieren an, da schreibe ich auch direkt in das GrafikRAM um die Dateilisten zu verschieben. Das geht beim VDC sicherlich nicht so einfach.


    Egal... jetzt gibt es diesen Thread... da kannst Du Deine Fragen loswerden.

  • An dieser Stelle bräuchte ich z.B. Deine Hilfe.

    Das sind aber genau die 128er spezifischen Fragen wo ich kaum Ahnung von habe, kann Dir nur sagen wie das in MegaPatch z.B. verwendet wird:


    SetBankFile darf man unter GEOS nicht nutzen, da der 128er GEOS-Kernal die Routine nicht bereitstellt. Ist aber kein Problem denn:

    Code
    1. ;Die Routine ist im GEOS128-Kernal nicht verfügbar, siehe src.GEOS_MP3.128 ab $FF81.
    2. ;SETBNK muss nachgebildet werden über: STA $C6 / STX $C7.
    3. :SETBANKFILE = $ff68 ;Nur in BASIC während GEOS.BOOT/RBOOT verwenden!

    Ich meine SETBNK übergibt die Bank im AKKU für den Speicherbereich und im XReg die Bank für den Dateinamen. Ich hab das im C128_Programmers_Reference_OCR.pdf mach nachgeschaut:

    D.h. an allen Stellen wo mittels SETNAM ein Dateiname oder auch ein Disk-Befehl gesendet wird müsste man jetzt die Bank setzen. Nur nicht für SETBANKFILE/SETBNK sondern über

    Code
    1.             lda #1
    2.             sta BA
    3.             sta FNBANK

    Ich glaube unter GEOS laufen die Anwendungen in BANK#1. BA/$C6 und FNBANK/$C7 sind aber bisher in Symboltabellen nicht definiert (WIMRE). Also alle stellen von SETNAM suchen, und wenn dort ein Zeiger auf einen Dateinamen übergeben wird -> SETBNK ergänzen.


    Ich hab mal nachgeschaut und GeoDOS verwendet das auch:

  • Wo wird denn in GeoDesk64 SetBankFile benutzt?

    In GeoDesk gar nicht... warum auch? Es läuft ja eh nur auf dem C64.


    Beim öffnen von Applikationen oder Dokumenten wird das auch nicht gebraucht, nur wenn auf Kernel-Ebene Datenkanäle oder Dateien geöffnet werden müssen.


    SETNAM wird z.B. hier verwendet...


    Also z.B. bei einem

    Code
    1. open 15,8,15,"n0:diskname,id":close15
    2. open 15,8,15,"cd:diskimage.d64":close15

    Der Name ist hier ein Diskbefehl und der wird mit SETNAM festgelegt. Am 128er müsste man hier zusätzlich auch SETBNK verwenden. (SETBANKFILE hatte ich in MegaPatch verwendet bevor ich den richtigen Kernal-Label hatte, meint aber beides die 128er-Routine die man unter GEOS durch die beiden STA/STX-Befehle ersetzen muss).

  • Ich hab mal nachgeschaut: SETNAM wird nur 5x verwendet...

    Code
    1. -103_GetModeSD.s:43: jsr SETNAM
    2. -103_GetModeSD.s:56: jsr SETNAM
    3. -113_FormatDisk.s:128: jsr SETNAM
    4. -119_CreateJob.s:195: jsr SETNAM
    5. -119_CreateJob.s:339: jsr SETNAM

    D.h. das meiste sollte auch ohne SETBNK funktionieren. Die Zahl nach dem ":" gibt die ungefähre Zeilennummer in der Datei an.

    Wenn SETNAM mit AKKU=0 aufgerufen wird, dann wird kein Dateiname gesetzt, dann braucht es auch kein SETBNK.


    Hier wird direkt SCREEN_BASE verwendet, also direkt auf das GrafikRAM des C64 zugegriffen oder adressiert:

    Gleiches für das FarbRAM:

    Ferner speichert GeoDesk64 den Fensterinhalt (auch vom DeskTop) in einer 64K Speicherbank, um das Fenster bei einem Redraw schnell wieder herstellen zu können. Das passiert in -101.WM_SCREEN.


    Und falls Dir der Speicher beim assemblieren ausgeht, kannst Du temporär in TopSym.GD die Variable "MAX_DIR_ENTRIES" von 160 auf einen geringeren Wert setzen, z.B. 64... dann greift der PagingMode zwar schon nach 64 Dateien, aber evtl. kann man später das SpeicherManagement des C128 optimieren und ggf. Code in Bank#0 auslagern. Da scheint einiges an freiem RAM zur Verfügung zu stehen, allerdings hab ich da keine Speichermap. Ich hab nur mal den Speicher von Bank#0 vor dem laden von GEOS mit $BD gefüllt und bei $0c00-$0fff, $2000-$39ff und $8200-$bfff war auch nach dem Start von GEOS noch der Wert $BD enthalten. Letztes bietet genügend Platz für 160++ Dateieinträge. Aber wie man die Daten dort ablegt müsstest Du schon selber prüfen, Bank-Switching war nie wirklich meins.


    Was noch ein Problem sein wird: Wenn ich auf I/O zugreife ohne InitForIO (z.B. Sprite-Pointer setzen, Tastatur abfragen...) müsste man ggf. was an den C128 anpassen. Ich sperre einfach den Interrupt und setze CPU_DATA/$01.

    Das sind jetzt erstmal ein paar Ansatzpunkte.


    Alles was 128er spezifisch ist, da kann ich Dir nicht viel helfen. Wenn ich das ein paar Monate zurückdenke hatte ich mit dem Anpassen von MP128 schon so meine Probleme... das meiste was mit MMU zu tun hat hab ich schon wieder verdrängt.


    Die ganzen SCSI-Tools waren relativ simpel an den 128er anzupassen, da nutze ich aber fast auch nur GEOS-Routinen. Aber GeoDesk64 war nie für den 128er gedacht, daher ist da vieles direkt für den 64er programmiert. Vielleicht war das auch ein Grund warum W.G. damals mit dem WinDesk nicht viel mehr gezeigt hat, da wäre schon damals einiges an Arbeit erforderlich gewesen.