Hallo Besucher, der Thread wurde 14k mal aufgerufen und enthält 56 Antworten

letzter Beitrag von C=Mac am

Quelltext für MegaPatch64/128 als Dokumentation verfügbar!

    Zitat von Pusti64

    Wenn darkvision nichts findet, dann könnte ich Dir zumindest meinen privat erstellten TD128-Quellcode anbieten.

    Nein, erstmal nicht nötig ;-) . Trotzdem Danke für das Angebot. Mindestens seit Januar 2000 war der Topdesk ja direkt in den je 6 Installationsdateien enthalten und wurde automatisch mit installiert.


    Ich habe nur gefragt, weil ich auf "Area6510" von Markus nichts der gleichen gefunden habe. Und wo die Fehler (bei TD64 RAM-Topdesk deaktiviern funktioniert in einem von 4 Fällen nicht (da ist ein Byte falsch (Tippfehler ???) / bei TD128 zusätzlich Laufwerkstausch im TD funktioniert nicht) weiss ich auch so ;-) .


    Gruß
    Werner

    An dieser Stelle ein kleiner Hinweis:
    Der Quelltext zu MegaPatch umfasst *NUR* MegaPatch selbst. TopDesk war nie Teil von MegaPatch (ich mochte das Design noch nie und hab den so gut wie nie selbst genutzt). Wolfgang hat TopDesk nur zusammen mit MP3 vermarktet.


    Das was derzeit bei mir hier in der Warteschlange hängt ist also nur das reine GEOS-Update. Als DeskTop kann jeder nutzen was er will, auch TopDesk. Aber TopDesk selbst hab ich hier (bis jetzt) auf keinen Disketten gefunden und daher wird es dazu auch keinen QuellText geben.


    Das nur am Rande.

    Zitat von darkvision

    TopDesk war nie Teil von MegaPatch (ich mochte das Design noch nie und hab den so gut wie nie selbst genutzt). Wolfgang hat TopDesk nur zusammen mit MP3 vermarktet.

    Sehr interessant, bin immer davon ausgegangen das TopDesk integraler Bestandteil von MP3 ist.
    Tja so kann man sich irren.



    Zitat von darkvision

    Als DeskTop kann jeder nutzen was er will, auch TopDesk.

    Was würde es den für Alternativen geben, welche alle Funktionen/Unterstützung bietet?


    Mir selber würde nur grade GeoDos einfallen, auf einem C64 O.K.
    Auf dem C128, sorry nein.


    Gruss C=Mac.

    Zitat von C=Mac

    Was würde es den für Alternativen geben, welche alle Funktionen/Unterstützung bietet?

    Der TopDesk aus dem offiziellen Release kann doch weiter verwendet werden, nur halt mit den gleichen Fehlern wie bisher. Einen weiteren, echt nervigen hab ich eben gefunden wenn man mehr als ~250 Dateien im Verzeichnis hat (z.B. RAMNative-Laufwerk). Bei jedem blättern im Verzeichnis kommt die Meldung "Zu viele Dateien"... immerhin zeigt TopDesk mehr Dateien an als dualTop (nur 144).


    Die gute Nachricht; Auch MegaPatch128 lässt sich jetzt mit dem AutoAssembler in 2 Stufen übersetzen. Und der Symbolspeicher ist nicht kleiner geworden da die Änderungen gar nicht den Assembler-Code berühren, die Änderungen haben nur die Haupt-Menü-Routine betroffen. Daher: Alles Super! Bis auf den Umstand das der MegaAssembler im Hauptmenü auch nicht mehr als ~250 Dateien anzeigt.


    Wieder einen kleinen Schritt weiter...

    wweicht:

    Zitat von wweicht

    - die Routine xFollowChain in G3_F_F_Chain.s arbeitet nicht korrekt.

    Zitat von wweicht

    - die Routine xGetBorderBlock in D3_GetBorderB.s arbeitet nicht korrekt.

    Wo liegt denn das Problem in den beiden Routinen? Dann würde ich bei meinen nächsten Testbuilds das mal versuchen zu beheben.


    Das mit dem ScreenSaver hab ich glaube ich schon gefunden und behoben. Das Problem war nicht das die Option nicht gespeichert wurde sondern beim Laden eines eingestellten Bildschirmschoners dieser grundsätzlich aktiviert wurde. Gleiches galt für die Verzögerung.

    wweicht:
    Das mit FollowChain hab ich Deinem Patch entnommen. Hab mir den jetzt zwar nur im Speicher unter VICE angeschaut, aber wenn ich das richtig sehe erzeugt MP3 erst gar keine gültige Tabelle wenn die Spurnummer in r1L zu Beginn bereits 0 ist. Das führt dann zu einer undefinierten Tabelle in r3. Ich werde das beim nächsten Build mal testen...

    Zitat von wweicht

    schwerwiegend (in meinen Augen) aber noch ohne Lösungsansatz meinerseits - MP3-64 und MP3-128


    - sind bei der Installation des Laufwerks-Treibers "C=1541 (Cache)" nicht genug freie RAM-Bänke verfügbar, überschreibt er schon belegte RAM-Blöcke und installiert sich einfach. Folge: Absturz.

    Haken dran :thumbup: Fehler lag nicht beim einrichten des Shadow-Laufwerkes, sondern bei der Deinstallation: Hier hatte ich die Anzahl der freizugebenden Bänke im falschen Register übergeben (ldx #$03 statt ldy #$03) was dazu führt das zumindest bei meinem Test sogar GEOS-reservierter Speicher freigegeben wurde was dann zum Absturz führte.


    Bleibt noch GetBorderBlock und das y/z-Tastenproblem.

    Sorry, ich komme momentan zu fast garnichts mehr, so dass Antworten länger dauern können ....


    Zitat von darkvision

    Das mit FollowChain hab ich Deinem Patch entnommen.

    Gut. Aber ich erinnere daran, dass mein Patch nicht wirklich Geos-konform ist ;-) . (siehe Quelltext für MegaPatch64/128 als Dokumentaion verfügbar! ).


    Übrigens: FollowChain scheint von kaum einem Programm wirklich benutzt zu werden...
    Mir ist das damals aufgefallen (muss irgendwann 2000-2005 gewesen sein), als ich das Programm geoZIP für Wheels an MP3 angepasst habe. Ich wollte die Funktion des Programms (Autor des Programms für Wheels: Todd Elliott; PKZIP V2.0-Archive unter Wheels packen und entpacken) einfach auch in MP3 haben. Das Programm funktioniert nur mit SCPU (auch in xscpu64). Übrigens: geoZIP für MP3 ist wohl das erste und wohl auch einzige Programm, welches RAM-Bänke oberhalb der 4 MB-Grenze von MP3 nutzen kann ;-) .
    Also zunächst den vorhandenen Quelltext (geoAssembler-Format) nach MegaAss V2-Format übertragen und dann für MP3 angepasst. Die fertigen Programme liegen auch auf der F64-Wolke unter Software\Geos\Apps+Tools\MegaPatchV3\ .
    Dieses Programm benutzt FollowChain und da ist mir das Problem aufgefallen. Mit meiner Änderung funktionierte FollowChain hier. Also kann geoZIP für MP3 wohl zum Testen benutzt werden....



    Bei dem Problem mit den Laufwerkstreibern habe ich bisher nicht viel konkretes herausfinden können (ist einfach schon zu lange her)
    In jedem Laufwerkstreiber (außer die für MSDOS) gibt es die Routine GetOPDPtr ($9036). Die sieht folgendermassen aus:


    jsr GetDirHead
    txa
    bne ...
    jsr ...
    jsr ChkDkGeos
    beq yy


    Dieses beq habe ich in meinem Update der Treiberdatei jeweils in bcc geändert....


    Soviel erstmal für heute.


    Gruß
    Werner

    Zitat von wweicht

    Sorry, ich komme momentan zu fast garnichts mehr, so dass Antworten länger dauern können ....

    Kein Problem, ich hab gerade nur etwas Zeit und sitze deshalb so intensiv am Code, ändert sich nächste Woche auch wieder.


    Zitat von wweicht

    Gut. Aber ich erinnere daran, dass mein Patch nicht wirklich Geos-konform ist

    In wie fern? Das einzige war ja das r3H nicht gesichert wurde. Ich hab das eine fehlende Byte aber woanders entnommen, so das jetzt die Routine wie bei Dir funktioniert ohne das r3H verändert wird.

    Das ist meiner Meinung nach falsch, denn ChkDkGEOS wird mit Akku=$ff=GEOS-Disk oder AKKU=$00=KeineGEOS-Disk beendet. Falls es eine GEOS-Disk ist wird mittels TYA der Akku mit $ff gefüllt und der LDA #$00 Befehl mittels BIT übersprungen. Meines Erachtens wird das Carry-Flag nur beim CMP-Befehl beeinflusst. Das aber als Rückmeldung GEOS/NichtGEOS heranzuziehen würde ja vom Vergleich abhängen und der kann sowohl positiv als auch negativ ausfallen. Der BIT-Befehl beeinflusst aber das ZERO-Flag je nachdem was in der Adresse $00a9 gespeichert ist.
    Ich würde ChkDkGEOS eher so abändern das hier das ZERO-Flag korrekt gesetzt wird und der Vergleich mit BEQ funktioniert.


    Damit bleibt nur noch das y/z-Problem. Das schiebe ich aber erstmal auf, das will ich nochmal am C64 testen.


    Danke erstmal für die Bug-Reports. Ich mache jetzt noch ein paar Aufräumarbeiten am Code, dann gibt es die erste Testversion (als Quelltext...).

    Zitat von darkvision

    denn ChkDkGEOS wird mit Akku=$ff=GEOS-Disk oder AKKU=$00=KeineGEOS-Disk beendet. Falls es eine GEOS-Disk ist wird mittels TYA der Akku mit $ff gefüllt und der LDA #$00 Befehl mittels BIT übersprungen.

    Bitte nochmal prüfen ;-) .


    Es geht hier um die Routine GetOPDPtr ($9036). Laut Beschreibung der Bachmann-Brüder (MegaAss-Fehler und Korrekturen, auch in der Readme zum MegaAss auf Area6510 vorhanden) muss da folgendes rauskommen:


    Code
    1. T-B.12.1.11 GetOPDPtr ($9036)
    4. Diese Routine überprüft den GEOS-Rand. Intern wird GetDirHead aufgerufen.
    5. Übergeben wird: x-Fehlernummer, wenn y=$ff-kein Borderblock, wenn
    6. y=$00, dann r1L-Track & r1H-Sektor des Borderblocks
    7. Verändert wird: r1, r5, Akku, y

    Das ist doch genau anders herum .....??


    Gruß
    Werner


    PS:

    Zitat von darkvision

    Damit bleibt nur noch das y/z-Problem. Das schiebe ich aber erstmal auf,

    Ich habe das damals erst sehr spät gemerkt. Da ich damals und auch heute noch geoKeys (PC-Tastatur am C64/C128 unter Geos & Co) benutze, habe ich das Problem eigentlich nicht (eigener Tastaturtreiber von geoKeys). Wenn ich mich recht erinnere hattest Du mir damals geantwortet, das bleibt jetzt erstmal so und Du selbst würdest das so bevorzugen ;-) .....

    Zitat von wweicht

    Es geht hier um die Routine GetOPDPtr ($9036).

    Warum die Bachmänner die Routine so benannt haben und ich "GetBorderBlock" lassen wir mal dahingestellt. Fakt ist das der Einsprung bei 9036 bei mir auf die Routine "GetBorderBlock" zeigt. Das kann man hier nachzählen, denn die Sprungtabelle beginnt ab $9000.


    Hier findet sich ab Zeile5 auch der von Dir zitierte Code. Die Routine nach der Du dann BEQ durch BCC ersetzt hast ist bei mir xChkDkGEOS:

    Hier wird auf den Format-String geprüft und wenn der passt wird $FF nach :isGEOS geschrieben, wenn es nicht passt (keine GEOS-Disk) dann $00. Das deckt sich auch mit der Angabe im MegaAssembler-Handbuch S.186.


    Und das Problem ist ab Zeile 12: Wenn es eine GEOS-Diskette ist dann wird der LDA #$00-Befehl durch den BIT-Befehl übersprungen. Dieser kann aber das ZERO-Flag verändern (siehe hier). Daher kann ein direkter BEQ-Befehl nach ChkDskGEOS dazu führen das eine GEOS-Diskette fälschlicherweise als NichtGEOS erkannt wird, abhängig davon was im Register $00a9 (wegen b $2c, LDA #$00 -> BIT $00A9) abgelegt ist.


    Prüft man nach ChkDkGEOS mittels BCC auf die GEOS-Diskette dann kann das ebenfalls zu einem Fehler führen:


    Wenn es keine GEOS-Diskette ist, aber die Byte-Werte ab curDirHead+$ad kleiner sind als die Byte-Werte ab FormatText dann wird der CMP-Befehl mit gelöschtem Carry-Flag beendet. Soweit wäre das OK.


    Sind aber die Byte-Werte ab curDirHead+$ad größer als die Byte-Werte ab FormatText dann wird der CMP-Befehl mit gesetztem Carry-Flag beendet. Und damit würde eine NichtGEOS-Diskette als GEOS-Diskette erkannt.


    Ich hab jetzt ChkDkGEOS wie folgt geändert:


    Durch das verschieben des TYA-Befehls wird jetzt das ZERO-Flag korrekt gesetzt, Und damit dürfte die Routine GetBorderBlock (oder nach den Bachmännern GetOPDPtr) korrekt funktionieren.



    Zitat von wweicht

    Wenn ich mich recht erinnere hattest Du mir damals geantwortet, das bleibt jetzt erstmal so und Du selbst würdest das so bevorzugen .....

    Sowas dachte ich mir auch und deshalb wollte ich das nochmals am C64 testen. Aber ich kann das ja dann im Code so anpassen das es der Mehrheit entspricht und ich kann es für mich selbst ja jederzeit wieder richtigstellen. :D

    Zitat von darkvision

    Aber ich kann das ja dann im Code so anpassen das es der Mehrheit entspricht und ich kann es für mich selbst ja jederzeit wieder richtigstellen.

    Ergänzung: Ich hab mir den Code gerade angeschaut. Beim 64er ist zumindest in dem mir vorliegenden Code (ab Zeile 524, am Anfang der Datei findet sich die Übersetzungsmatrix) nur für die BETA-Version die Y-Taste auch auf der Y-Taste (wie bei der englischen Version). Bei der Vollversion ist Y mit Z vertauscht. Kann also sein das Wolfgang beim Release noch eine alte Version der Tastaturmatrix verwendet hat.


    Damit dürfte auch dieser "Bug" bereits behoben sein.

    Zitat von darkvision

    Einen weiteren, echt nervigen hab ich eben gefunden wenn man mehr als ~250 Dateien im Verzeichnis hat (z.B. RAMNative-Laufwerk)

    Das ist aber wohl normal ;-) .


    Laut "GEOS - MegaPatch64 - Technische Dokumentation im HTML-Format für Programmierer" von Ende 1998 (leider derzeit nicht online verfügbar, da W. Grimms WEB-Seite zumindest derzeit nicht erreichbar ist) kann MP3 maximal 255 Dateien......
    Sollte am C64/128 liegen (8 Bit). ;-)


    Gruß
    Werner

    Zitat von wweicht

    Das ist aber wohl normal .

    Man muss da unterscheiden zwischen MP und TopDesk....

    Zitat von wweicht

    Laut "GEOS - MegaPatch64 - Technische Dokumentation im HTML-Format für Programmierer" von Ende 1998 (leider derzeit nicht online verfügbar, da W. Grimms WEB-Seite zumindest derzeit nicht erreichbar ist) kann MP3 maximal 255 Dateien......

    Ich hab den Original-Ausdruck von 1998 hier in den Händen :D (und evtl. noch irgendwo auf einer Disk... mal bei Gelegenheit suchen, dürfte aber kein geoWrite-Dokument sein, sieht eher nach StarOffice aus).
    Da hab ich auf S.19 unter GetFiles geschrieben das die Auswahlbox nur 255 Dateien unterstützt. Das liegt daran das nur für 255 Dateien Platz ist. ($1200Bytes). Aber die Auswahlbox zeigt da keine nervige Fehlermeldung an. Und wenn man gaaaaanz viel Zeit hat könnte man über eine Art "Blättern" wie im MegaAssembler-Dateimenü nachdenken. Da werden dann halt die nächsten 255 Dateien in der Auswahlbox angezeigt.

    Zitat von wweicht

    Sollte am C64/128 liegen (8 Bit).

    Naja, nicht wirklich. Obwohl GetFiles intern einen 1Byte-Zähler hat könnte man (wenn mehr Platz da wäre) auch mehr als 255 Dateien einlesen wenn man einen 2-Byte-Zeiger nutzt. Letzteren könnte man aber mit dem Blättern-Modus trotzdem einsetzen. Und dann wäre es theoretisch möglich bis 65535 Dateien anzuzeigen (na, wenn das dann nicht reicht...) Das müssen ja nicht mal CMD-Laufwerke sein, selbst die 1581 unterstützt schon 288 Dateien..


    Beim TopDesk bin ich mir aber fast sicher das es daran liegt (wahrscheinlich wird beim einlesen der Dateien zur Anzeige ein Zähler von 255 auf 0 überlaufen -> Fehlermeldung). Man kann ja nicht mal Blättern wenn das Verzeichnis bereits geöffnet ist ohne das die Meldung erscheint. Es wäre ja OK wenn die Meldung beim öffnen des Laufwerks angezeigt wird aber eben nur 1x. Daher sehe ich das eher als "Bug" während es bei MP eine technische Grenze ist (die man ggf. umgehen kann und evtl. einen Hinweis einblenden könnte). Beim TopDesk könnte man das mit den 255 Dateien sicherlich auch umgehen...


    Wie gesagt schlägt sich TopDesk zumindest im Vergleich zu DualTop besser, der kann nur 144, nervt dafür aber nicht wenn man ständig neue Dateien in das "volle" Verzeichnis kopiert).


    Ich bin jetzt aber schon beim anpassen des Setups für MP3, da passte in meiner Version so einiges nicht am C128 (UI-mäßig). Wenn das dann mal rum ist muss ich zu testwecken nicht immer wieder von neuem alle Dateien auf das RAMLaufwerk schaufeln. Ist also sowieso nur ein temporäres Problem.


    Markus

    Zitat von darkvision

    Bei der Vollversion ist Y mit Z vertauscht. Kann also sein das Wolfgang beim Release noch eine alte Version der Tastaturmatrix verwendet hat.

    Cool wäre es, wenn es einstellbar gemacht werden würde - im Editor. Dann kann jeder wie er möchte.


    Zitat von darkvision

    Letzteren könnte man aber mit dem Blättern-Modus trotzdem einsetzen. Und dann wäre es theoretisch möglich bis 65535 Dateien anzuzeigen (na, wenn das dann nicht reicht...)

    Jaa, so eine Blättern-Funktion hat was. :-D



    Oliver W.

    Zitat von darkvision

    Letzteren könnte man aber mit dem Blättern-Modus trotzdem einsetzen. Und dann wäre es theoretisch möglich bis 65535 Dateien anzuzeigen (na, wenn das dann nicht reicht...)

    Ist a wäng knapp, gelle.


    In mei SID-Archiv hots 175.952 'Objekte' mit oaner gsammtgröß' vo 1,1 GB ;)

    Zitat von Freddy

    Ist a wäng knapp, gelle.


    In mei SID-Archiv hots 175.952 'Objekte' mit oaner gsammtgröß' vo 1,1 GB

    Mit welchem Laufwerkstreiber unter GEOS kann man solche Verzeichnisse anzeigen bzw Dateien kopieren? Das hat nichts mehr mit NativeMode zu tun (> 256*256Blocks). Und selbst wenn, wer will den schon 500 Seiten in einer Dateiauswahlbox oder Dateimanager blättern um die richtige Datei zu finden.
    Selbst unter BASIC dürfte ein 'LOAD"$",8' sämtliche Speichergrenzen des C64 sprengen.

    Zitat von OliverW.

    Cool wäre es, wenn es einstellbar gemacht werden würde - im Editor. Dann kann jeder wie er möchte.

    Ich hebe mir das mal als FeatureRequest auf... mit dem Quelltext bin ich aktuell durch und mache jetzt noch einige Buildtests, wenn es keine Probleme gibt dann schiebe ich den Code auf die Area6510 zum Download+Compile…


    Das mit dem Z/Y wäre sicherlich kein großer Aufwand für den Editor, aber man müsste es ja auch so programmieren das beim Neustart die Einstellung übernommen wird.


    Derzeit finde ich es einfacher einen weiteren Build zu erstellen (Englisch y/z, Deutsch z/y und Optional Deutsch y/z und das ganze nochmal für den C128). Das wäre (fast) ohne Änderungen möglich... Aber fürs erste gibt eh nur den SourceCode. Da kann ja denn eh jeder einstellen was er will ;)

    Zitat von darkvision

    Mit welchem Laufwerkstreiber unter GEOS kann man solche Verzeichnisse anzeigen bzw Dateien kopieren? Das hat nichts mehr mit NativeMode zu tun (> 256*256Blocks). Und selbst wenn, wer will den schon 500 Seiten in einer Dateiauswahlbox oder Dateimanager blättern um die richtige Datei zu finden.Selbst unter BASIC dürfte ein 'LOAD"$",8' sämtliche Speichergrenzen des C64 sprengen.

    War nur Spaß, oder hast du dem Smiley nicht gesehen?

    Zitat von Freddy

    War nur Spaß, oder hast du dem Smiley nicht gesehen?

    Hätte ja sein können das es in den letzten 20Jahren, seit ich den C64 eingemottet hab, einen Fortschritt bei den Laufwerken gab und man jetzt mehr als NativeMode-Partitionen nutzen kann ;)
    Unter VICE kann man ja ein Dateisystem-Verzeichnis als Laufwerk definieren. Müsste man mal mit 175.000 Dateien testen :D Da wäre auch ein GEOS-Treiber interessant. Dann könnte man unter GEOS direkt auf Dateien auf dem PC zugreifen wenn man VICE nutzt... nur so eine Idee... :rolleyes: