GeoDesk64 intern

Zitat von 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

Zitat von Pusti64

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...

Zitat von 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

Zitat von darkvision

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

Konnte ich...

Obige Postigns stammten ursprunglich aus: Screenshots zu GeoDOS Desktop v3

sl FXXS

Zitat von FXXS

Konnte ich...

Danke!

Zitat von Pusti64

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.

Zitat von Pusti64

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:

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:

Zitat von C128_Programmers_Reference

12. $FF68 SETBNK ;set bank for I/O operations

PREPARATION:
Registers: .A = BA, memory bank (0-15)
.X = FNBANK, filename bank
Memory: system map
Flags: none
Calls: SETNAM

RESULTS:
Registers: none
Memory: BA, FNBANK updated
Flags: none

EXAMPLE:
See OPEN

SETBNK is a prerequisite for any memory I/O operations, and must be used
along with SETLFS and SETNAM prior to OPENing files, etc. BA ($C6) sets the
current 64KB memory bank for LOAD/SAVE/VERIFY operations. FNBANK ($C7)
indicates the bank in which the filename string is found. The Kernal routine
GETCFG is used to translate the given logical bank numbers (0-15). SETBNK is
often used along with SETNAM and SETLFS calls prior to OPEN's. See the Kernal
OPEN, LOAD and SAVE calls for examples

Alles anzeigen

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

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:

Zitat von Pusti64

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

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...

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.

Frohe Weihnachten Pusti64! Wie siehts bei dir aus mit Geodesk 128?

Sehr schade. Edit: Woran lag es denn?