Problem verstanden
und um zum Thema geoDOS zurückzukommen, der neueste Snapshot startet jetzt auch keine 80-Zeichen-Programme mehr unter MP3-64. Also Problem gelöst.
Gruß
Werner
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von wweicht am
Problem verstanden
und um zum Thema geoDOS zurückzukommen, der neueste Snapshot startet jetzt auch keine 80-Zeichen-Programme mehr unter MP3-64. Also Problem gelöst.
Gruß
Werner
der neueste Snapshot startet jetzt auch keine 80-Zeichen-Programme mehr unter MP3-64. Also Problem gelöst.
Oh man...
Ich hab hier einen TOPDESK128, den starte ich unter DualTop oder GeoDOS unter GEOS64... Crash. Der hat $40 als Flag. Problem nicht gelöst... ich klinke mich jetzt aber aus, denn das Problem ist nicht zu lösen wenn der Anwender nicht mitdenkt bzw. der Programmierer das Flag falsch setzt. GeoDOS/geoDirSelect starten Programme mit dem 40/80-Flag=$40 weil es theoretisch ein Programm für GEOS64 oder GEOS128 sein kann. Die Alternative wäre nur noch $00 und $80 zuzulassen. Dann lässt sich geoCham64RTC+ (das für TC64 und U2+) nicht mehr unter GEOS64 starten... Ich glaube fast es ist einfacher den ganzen Müll mit 40/80Z rauszuwerfen und dem Anwender das Problem zu überlassen...
Ich hab hier einen TOPDESK128, den starte ich unter DualTop oder GeoDOS unter GEOS64... Crash. Der hat $40 als Flag.
Also zumindest TD 128 V3 und V4 ist eigentlich 80-Zeichen only. Da dürfte das $40 als Flag gar nicht auftauchen..... Ich checke das mal hier durch, habe ja kürzlich TD128 V3.5 in die Wolke hochgeladen.....
Gruß
Werner
Also zumindest TD 128 V3 und V4 ist eigentlich 80-Zeichen only
Veraltet, OK... aber es geht um das Prinzip:
Wie gesagt... bin ich jetzt raus... sollte jemand trotzdem der Meinung sein einen Fehler melden zu müssen, dann schmeiß ich den Code komplett raus. Dann crasht GeoDOS+geoDirSelect wieder wie zuvor beim Versuch auch reine 80Z-Apps zu starten aber ich hab ein Problem weniger...
Generell sollten also Programme nur für Geos 128 nicht in einem 64er-System gestartet werden, da muss der Anwender auch mal etwas mitdenken. Nicht alles kann vom System abgefangen werden....
Wie, was?
Aber das geht doch nicht, in der heutigen vollumsorgten und betreuten Welt; da soll man noch selber denken?
@darkvision
Mach Dir keinen Kopf darüber.
Wenn es nicht erkennbar ist - für welches System das Programm ist, ist es nicht erkennbar.
Es wäre die Aufgabe des jeweilige Programmierers, die Flag's richtig zusetzen bzw. ein Start unter dem falschem System zu verhindern.
Und sonst, es gibt ja noch das Forum64, da kann man nachfragen.
Müsste mal probieren, was passiert wenn man ein Wheels-Programm unter MP3 startet bzw. umgekehrt.
Gruss C=Mac.
Ich glaube fast es ist einfacher den ganzen Müll mit 40/80Z rauszuwerfen und dem Anwender das Problem zu überlassen...
Ich würde vorschlagen, lass das Ganze bitte jetzt so, wie es ist Punkt.
Zum 40/80-Zeichem-Flag:
Ja, TD 128 hat hier (mindestens seit V3.11, ältere Versionen habe ich jetzt nicht mehr gesucht) auch $40 für 40- und 80 Zeichen-Modus. Das scheint etwas seltsam, aber TD 128 (eigentlich 80-Zeichen only) hat auch mindestens eine Stelle, an der auf 40-Zeichen umgestellt werden kann: Menü "geos" - "Hilfsprogramme".
Ob das nun die Kennzeichnung des Programms als 40- und 80-Zeichen rechtfertigt, sei mal dahingestellt. Der Rest von TD 128 ist 80-Zeichen only.
Kleiner Seitenhieb am Rande :
selbst geoDOS (die Version von Ende 1999/Anfang 2000 steht auf 40- und 80- Zeichen
Und ganz nebenbei (für die, die wissen was sie tun ), man kann an der gezeigten Stelle in geoDOS (siehe Bilder weiter vorne) die Einstellungen auch ändern und speichern...
Müsste mal probieren, was passiert wenn man ein Wheels-Programm unter MP3 startet bzw. umgekehrt.
Keine gute Idee. Das gibt bestimmt schöne Abstürze. Das Laufwerks-Handling und besonders das RAM Handling sind komplett unterschiedlich. Und da gibt es auch keine Möglichkeit, vor dem Starten zu prüfen, ob das Programm nun für Wheels oder MP3 oder Geos programmiert wurde. Das sieht man nur, wenn man das Programm startet und hoffentlich eine Prüfung enthalten ist, unter welchem System (Geos/Wheels/MP3) es gestartet werden darf.
Gruß
Werner
Geodos Test vom Wochenende 17.03.19:
LW08 CMD HD 1581
LW09 RAMLINK 1581 (Startpartition) -> erst MP3 128 3r5 dann MP3 64 3r5 ->06.03.19 ::: + GD64 15.03.19 auf anderer 1581 Partition.
LW10 SD2IEC Native Treiber eingestellt (Start DNP), zum testen mit SD2IEC jeweils richtig eingestellt.
LW11 1571
Habe alles mögliche hin und her geschaltet. Bin in die jeweiligen Reiter gegangen und habe hier geklickt und dort kopiert, gelöscht, validiert, umbenannt usw.. Super, alles ok.
Dabei habe ich auch verstärkt mit dem SD2IEC probiert. In MP3 128, LW10, die jeweiligen Modis eingestellt und mit Geodos durchgetestet, wie oben. bis jetzt keine Fehler.
Wie immer, "Klasse Leistung".
Gruß Jojo
Hallo,
habe ich gerade im aktuellen geoDOS einen Fehler entdeckt?
Es geht um das Validate (Aufräumen) eines 255 Track-DNP. Es handelt sich um ein DNP im Geos-Format (mit Border-Block) und enthält 39 Dateien (Boot-Disk MP3-64 + ein paar Programme + 1 UV). Das UV enthält die 6 geoDOS-Prg-Dateien. TD zeigt mir an: 63055 Blocks frei und 2161 Blocks belegt.
Ich starte geoDOS aus der RAM (CBM-REU Native) und lasse dann das DNP validieren. Dabei sind alle Optionen eingeschaltet. Nach dem Validate habe ich (wieder im TD) 1 Block mehr frei und 1 Block weniger belegt .
Ich vermute, dass da der Border-Block freigegeben wurde (habe es jetzt nicht geprüft).
Aber: ein sofortiges "Validate" im TD stellt die ursprüngliche Belegung wieder her.
Problem: Wenn geoDOS den Border-Block in der BAM frei gibt, sollte es eigentlich auch den Eintrag im Header des DNP:
Track/Sektor des Border-Blocks + Text: "GEOS format V1.0" (Bytes $ab - $bc)
löschen. Der ist immer noch da. Denn: wenn ich jetzt nach dem Validate in geoDOS etwas auf das DNP kopiere, könnte der Sektor des Borderblocks davon überschrieben werden. Will sagen: der Header des DNP sagt: dieser Track enthält den Border-Block, in Wirklichkeit gehört er aber zu irgend einer andern Datei. Keine Ahnung ob das bei "ChkDkGEOS" oder bei einigen Programmen zu Problemen führen kann...
Gruß
Werner
Danke... ich schau's mir mal an... Gerade beim BorderBlock gab es ja zuletzt ein paar Änderungen. Evtl. hab ich da was übersehen...
Hallo, guten Tag.
Wie wird das Geos hier bitte mit VICE gestartet oder dem TC64 v2 und SD2IEC ?
Laufwerk beim VICE ist d81
Danke.
Gruss
Wie wird das Geos hier bitte mit VICE gestartet oder dem TC64 v2 und SD2IEC ?
Auch wen das hier das falsche Thema ist... GEOS startet man mit einem G64-DiskImage. Man benötigt also eine Kopie der Original GEOS-Boot-Disketten. Diese dann am SD2IEC oder TC64 mounten. Danach "LOAD 'GEOS' ,8,1".
Installiert man MegaPatch geht das auch auf einem D81 am SD2IEC. Ist hier bei mir "Standard".
Ich hab hier ein HowTo geschrieben wie man auf dem TC64 MegaPatch/GEOS installiert... weil nur mit einem Laufwerk ohne SD2IEC etwas komplizierter, aber es geht.
Wie wird das Geos hier bitte mit VICE gestartet
GeoDOS, darum geht es hier, ist eine Anwendung für Geos/MP3 und kann einfach mit Doppelkick auf GeoDOS gestartet werden. Zusätzlich kann geoDOS auch asl DESKTOP benutzt werden.
Für MP3 gehe hier hin https://gitlab.com/mkslack/Are…gapatch64_128/current/doc und lies
und
englische Doks gibt es da auch und das ist auch alles auf der Install-Disk (D81) als Geowrite drauf. Wenn es dann noch Probleme gibt, kannst Du ja nochmal nachfragen. Lesen musst Du schon selber ....
Grundsätzlich: für die Installation von MP3 wird ein lauffähiges Geos oder ein älteres MP3 benötigt. Für Geos unter VICE ist eine mit CMDs geoMakeBoot erstellte Geos-Bootdiskette (D64/D71/D81) nötig.
Gruß
Werner
Danke für die Info.
Dann habe ich wieder falsch gelesen.
Ich dachte jetzt, das es ein lauffähiges GEOS ist.
Danke.
Gruss
Ich dachte jetzt, das es ein lauffähiges GEOS ist.
Das Problem ist das die Rechte an GEOS nicht bei mir liegen... daher ist MegaPatch auch nur ein "Patch" für ein vorhandenes GEOS-System. D.h. man muss schon GEOS-User sein um MegaPatch verwenden zu können.
Falls Du Probleme hast GEOS oder MegaPatch zu installieren, dann kannst Du gerne entweder einen neuen Thread oder eine Konversation starten. Da Du TC64 und SD2IEC hast kann ich das hier alles nachstellen. Auch VICE ist kein Thema. Einfach beschreiben wo genau das Problem liegt.
Danke für die Info.
Gruss
Alles anzeigenEs geht um das Validate (Aufräumen) eines 255 Track-DNP. Es handelt sich um ein DNP im Geos-Format (mit Border-Block) und enthält 39 Dateien (Boot-Disk MP3-64 + ein paar Programme + 1 UV). Das UV enthält die 6 geoDOS-Prg-Dateien. TD zeigt mir an: 63055 Blocks frei und 2161 Blocks belegt.
Ich starte geoDOS aus der RAM (CBM-REU Native) und lasse dann das DNP validieren. Dabei sind alle Optionen eingeschaltet. Nach dem Validate habe ich (wieder im TD) 1 Block mehr frei und 1 Block weniger belegt .
Ich vermute, dass da der Border-Block freigegeben wurde (habe es jetzt nicht geprüft).
Aber: ein sofortiges "Validate" im TD stellt die ursprüngliche Belegung wieder her.
Problem: Wenn geoDOS den Border-Block in der BAM frei gibt, sollte es eigentlich auch den Eintrag im Header des DNP:
Track/Sektor des Border-Blocks + Text: "GEOS format V1.0" (Bytes $ab - $bc)
löschen.
Ich bin gerade dabei einige Funktionen aus GeoDesk in GeoDOS zurückzuführen und hab mir auch mal den Punkt angeschaut.
Es gibt m.M.n. nur wenige Möglichkeiten warum GeoDOS den BorderBlock nicht belegt: z.B. Es ist keine GEOS-Diskette weil der Format-String nicht passt.
GeoDOS ruft dazu "isGEOS" auf. Die Kernal-Routine prüft ob die Diskette den Format-String beinhaltet. Falls nein, dann wird der BorderBlock nicht geprüft und auch nicht reserviert. Wenn Topdesk z.B. nicht isGEOS testet sondern nur prüft oder Wert für TrackS/ektor <>0, dann würde der den Block wieder reservieren.
Daher wäre es interessant zu wissen ob der Format-String auf deinem DNP stimmt... die Größe des DNP sollte keine Rolle spielen.
Ich hab eben mal ein RAMNative eingerichtet und dort SetGEOSDisk aufgerufen. Die BAM enthält jetzt den GEOS-Format-String und die Angabe zu einem Borderblock. validate unter GeoDOS oder TopDesk64 ändern nichts an der Zahl der freien Blocks. Hier scheint es zu funktionieren. Auch wenn ich zuvor in einem Unterverzeichnis bin.
Es kann natürlich auch noch sein das isGEOS nicht vom Hauptverzeichnis ausgeht. Dazu ruft die aktuelle GeoDOS-Version aber vorher das Hauptverzeichnis auf, daher sollte das nicht passieren. Wenn Du aber eine ältere GeoDOS-Version verwendest, dann wird bei nicht CMD-Hardware nicht automatisch das Hauptverzeichnis geöffnet und Validate findet beim Test mit isGEOS den falschen BAM-Sektor vor und dann würde ein BorderBlock auch nicht reserviert.
Also:
A) Kannst du den GEOS-Format-String auf dem DNP mal prüfen ob der stimmt?
B) Hast Du ein GeoDOS neuer als 8.10.2018? Falls nein, bitte updaten...
Ansonsten fällt mir da so spontan nichts mehr ein.
Daher wäre es interessant zu wissen ob der Format-String auf deinem DNP stimmt... die Größe des DNP sollte keine Rolle spielen.
Definitiv, es ist nach der Erstellung des DNP mit TD formatiert wurden. Der erzeugt immer Geos-Disks. Natürlich auch überprüft mit Disk-Monitor .
geoDOS neueste Version
Aber ich glaube, ich habe die Ursache gefunden:
Zunächst: Hier aktuelles MP3-128 mit aktuellem TD128 V5.0.
Über das Ganze haben wir schon mal vor einiger Zeit diskutiert
Mein Versuchsfeld jetzt:
DNP 191 Tracks (MP3-128 BootDisk) unter Topdesk 128 aufgeräumt: 46691 Blocks free 2141 belegt
DNP 191 Tracks (MP3-128 BootDisk) unter GeoDOS aufgeräumt: 46692 Blocks free 2140 Blocks belegt
und ich habe mir dann auch mal die BAM (Track 1 Sektor 2 ab Byte $20) angeschaut und das lies mich erst mal stutzen:
TD-128 : $00, $00, $00, $00, $00, $ff, $ff, $ff, $80, ......
geoDOS: $00, $00, $00, $00, $3b, $ff, $ff, $ff, $c0, ......
Dann habe ich mir ein leeres DNP (191 Tracks, Geos-Formatiert) vorgenommen:
TD-128 : $00, $00, $00, $00, $1f, $ff, $ff, $ff, $bf, ... TD zeigt mir dann 48831 Blöcke frei 1 belegt
geoDOS: $00, $00, $00, $00, $3f, $ff, $ff, $ff, $ff, ... TD zeigt mir dann 48832 Blöcke frei 0 belegt, geoDOS : 1 belegt 48831 frei
Was das Ganze auszulösen scheint: Laut CMD-Handbüchern (und mit FD-Native Disk geprüft) müsste die BAM auf einer leeren Disk so beginnen:
$00, $00, $00, $00, $1f, ........
Wenn gebraucht, kann ich die 2 DNPs (gepackt) hier mal anhängen. Wird aber heute nichts mehr....
Gruß
Werner
Dann waren wir da auf der völlig falschen Fährte mit dem Borderblock.
Ich glaub ich sehe den Fehler jetzt:
Ich reserviere die Sektoren 0-33 für die BAM, soweit so gut. Ergibt $00 $00 $00 $00 $3F.
Dann hole ich den ersten Verzeichnis-Block... und folge dann der Kette und belege alle weiteren Verzeichnis-Sektoren in der BAM. Aber nicht den ersten Sektor selbst... Und ein Sektor muss ja immer belegt sein, daher wäre dann $00 $00 $00 $00 $1F der Unterschied von einem Sektor.
Scheint so als ob das aber kein Problem ist da die Suche nach freien Datensektoren ab $01/$40 beginnt. D.h. der fälschlicherweise nicht reservierte Verzeichnis-Sektor wird nicht überschrieben...
Ich schau mir das aber nochmal an... scheint aber die Ursache für das Problem zu sein.
Zu früh gefreut... das ist es nicht. GeoDOS reserviert auch den ersten Verzeichnis-Sektor.
Ich hab das eben auch unter GEOS128 mal getestet... da ist das 5Byte immer $1F. Ich kann das mit dem $3F hier nicht nachvollziehen.
GeoDOS unterscheidet auch nicht zwischen Native auf RAM oder SD2IEC oder CMD-HD. Es wird nur noch auf eine GateWay-RAMDisk getestet weil da die BAM kleiner ist.
Wenn ich in GeoDOS auf Verzeichnis-anzeigen gehe, dann auf Speicher, dann sehe ich nach einem validate mit GeoDOS nur zwei Blocks belegt (weil eine Datei mit 2 Blocks drauf ist). Lösche ich die Datei werden 0 Blocks belegt angezeigt.
Ich hab das eben auch unter GEOS128 mal getestet... da ist das 5Byte immer $1F. Ich kann das mit dem $3F hier nicht nachvollziehen.
Das Ganze tritt auf, wenn in geoDOS zum "Validieren" alle Optionen unter "Optionen" im Aufräumen-Fenster aktiviert sind.
Da wo $1f stehen müsste (5. Bytes), steht nach dem Validate (mit Diskmonitor geprüft) $3f . Zu beachten ist auch das neunte Byte der BAM. Bei TD128 steht da $bf, da der Border-Block auf Track 1 Sektor $41 liegt. Nachdem geoDOS das validiert hat, steht im 9. Byte in der BAM $ff, also alles frei. Aber im Header (Track 1 Sektor 1 steht nach wie vor der korrekte Borderblock-Eintrag.
Hat also doch irgendwas mit Border-Block zu tun .....
Gruß
Werner