geoConvert

darkvision · 6. Januar 2019

Ich habe geoConvert v4.2 online gestellt.

Die Version v4.0 hatte ein Problem beim erstellen von D81-Images wenn diese anschließend direkt über ein SD2IEC oder VICE geöffnet wurden:
GEOS/MegaPatch verschiebt den Disknamen eine 1581-Diskette an die Stelle wie er auch bei einer 1541/1571-Diskette erwartet wird. Das passiert beim lesen des BAM-Sektors mit dem Disknamen automatisch.
Die Version v4.0 hat den so von GEOS/MegaPatch modifizierten Sektor in das D81-Abbild geschrieben. Damit steht der Diskname an der falschen Stelle innerhalb des D81.

Die Version v4.1 hatte dazu einen "Fix": Dabei wurde beim schreiben/lesen des Sektor von/nach D81 der Name wie in GEOS/MegaPatch zurückgetauscht. Das führt aber bei älteren D81-Abbildern die mit geoConvert-4.0 erstellt wurden dazu das auf dem Ziel-Laufwerk hinterher kein Diskname mehr erscheint.

Die Version v4.2 prüft jetzt vor dem tauschen ob überhaupt ein gültiger Diskname vorliegt. Das sollte bei den meisten Diskimages das Problem beheben.

Allerdings kann das bei GEOS/MegaPatch-RAMLaufwerken bis V3.3r2 noch ein Problem sein, da hier RAM-Laufwerke so formatiert werden das der Diskname ab beiden Stellen steht. Hier wird dann zwar ein gültiger Diskname angezeigt, aber evtl. nicht derjenige der unter BASIC angezeigt wird. Dazu wird es beim finalen Release von MegaPatch V3.3r3 noch eine Anpassung geben.

wweicht · 20. April 2019

Hallo,

leider scheint das aktuelle geoConvert64 noch einen Fehler zu haben.

Ich konvertiere GEOWRITE nach .CVT und benenne dann das .CVT um. Wenn ich jetzt das .CVT wieder mit geoConvert64 nach Geos konvertiere, zeigt mir TopDesk als Dateiname von GEOWRITE folgendes an:

WGW.CVT

interessant . Ich hatte das .CVT ursprünglich nach WWGW.CVT umbenannt.
Aber eigentlich sollte doch geoConvert64 beim konvertieren den originalen Dateinamen (GEOWRITE) wieder aus dem .CVT herstellen .........

Gruß
Werner

darkvision · 20. April 2019

Kann ich hier so nicht nachvollziehen...

Ich hab eine geoWrite-Datei "cbm.Dir" nach CVT konvertiert. Dann in WGW.CVT umbenannt (alle Buchstaben über die Tastatur neu eingegeben) und mit geoConvert V4 wieder zurückgewandelt. Ergebnis war wieder eine "cbm.Dir"-geoWrite-Datei.

Kannst Du das .CVT mal hier anhängen das hier mal testen kann?

wweicht · 22. April 2019

Zitat von darkvision

Kann ich hier so nicht nachvollziehen...

Ich hier leider immer und immer wieder....

Also mal etwas konkreter:

letztes MP3-64 mit letztem TD von Pusti64

Konfiguration: A: SD2IEC (Native-Mode, 25 Tracks)
B: C=REU Native 191 Tracks
C: 1571
D: CMD FD (1581)

Arbeitslaufwerk ist B:. Auf B: befinden sich: geoDirSelect, Druckertreiber, Topdesk, Topdesk.win, ResetKeys und Tastatur.std (für PC-Tastatur), GEOWRITE, geoConvert64.DE (V4.2), PadColorPref.
Ich starte geoConvert64.DE und dann auf "Datei" - "GEOS => CBM.cvt", wähle GEOWRITE und verlasse nach Abschluss geoConvert. Im TopDesk dann das GEOWRITE.CVT umbenannt in "WWGW.CVT". Jetzt geoConvert neu gestartet und mit "CBM.cvt => GEOS" ins Geos-Format konvertieren. Geowrite wird konvertiert, hat jetzt aber den Dateinamen "WGW.CVT"

Eventuell ein Problem mit NativeMode? Ist ja schon seltsam, dass der Dateiname sich bei der Konvertierung von CVT nach GEOS von WWGW.CVT nach WGW.CVT ändert....

Im Anhang ein D64, dass das originale CVT von Geowrite aus dem ersten Schritt, das von mir umbenannte CVT und das Ergebnis (GEOWRITE mit falschem Dateinamen) enthält.

Gruß
Werner

darkvision · 22. April 2019

Also das gut Vorab:
Mit dem WWGW.CVT kann ich den Fehler nachstellen... aber... geoConvert macht was es soll. Hier mal ein ScreenShot von vbindiff wo ich GEOWRITE.CVT und WWGW.CVT verglichen habe:

Das rote sind die einzigen Änderungen in beiden Dateien. Und warum auch immer: in WWGW.CVT steht "WGW.CVT" als Dateiname für die konvertierte Datei. Keine Ahnung wie der Name dort hinkommt. Aber den Namen übernimmt dann geoConvert und erzeugt daraus die GEOS-Datei.

Nehme ich die GEOWRITE.CVT und konvertiere die nach GEOS und danach wieder zurück nach CVT, dann steht da der richtige Name. Umbenennen nach WWGW.CVT und zurück nach GEOS funktioniert auch.

Die Frage ist also jetzt wie kommt der falsche Name in die umbenannte CVT-Datei?

wweicht · 22. April 2019

Zitat von darkvision

Die Frage ist also jetzt wie kommt der falsche Name in die umbenannte CVT-Datei?

Dann könnte/dürfte es die Umbenennen-Funktion von TD64 sein...... Die darf an der Stelle nichts ändern!!!!

......

Sieht fast so aus... Habe gerade mal mit geoDOS umbenannt. Alles so wie es sein soll. Im CVT steht dann da immer noch GEOWRITE, wie es sein soll.

Gruß
Werner

darkvision · 22. April 2019

Kannst Du mir die TD-Version die Du verwendet hast hier mal als D64 anhängen? Hab das hier mit dem TD versucht, aber konnte das nicht nachstellen.
Wäre ja ein "Hidden"-Feature wenn der da was umbenennen würde...

wweicht · 22. April 2019

Zitat von darkvision

Kannst Du mir die TD-Version die Du verwendet hast hier mal als D64 anhängen?

Yupp. Ist die letzte Version vom 04.01.2019

Gruß
Werner

darkvision · 22. April 2019

Hah!!!

Danke! Damit kann ich das 1:1 nachstellen... warum zum Teufel macht der TopDesk das?
Ich schau mir das mal genauer an. Denn auch wenn hier die Datei nicht geändert werden sollte schreibt TopDesk die Daten auch noch an die falsche Stelle.

wweicht · 22. April 2019

Zitat von darkvision

warum zum Teufel macht der TopDesk das?

Naja, da hat @Pusti64 wohl einen Fehler reingebaut ( @Pusti64 : ist nicht böse gemeint ). Ist ja nicht der einzige, siehe TD64-Thema

Auch wenn es wohl länger dauert, kommt Zeit, kommt Rat .

Gruß
Werner

darkvision · 22. April 2019

Da wird der Hund in der Pfanne verrückt

In der TopDesk-Version wird direkt nach GEOS/RenameFile der GEOS-Dateityp auf $00 getestet und dann der erste Datenblock eingelesen und der Name nach Byte $04 geschrieben. Was ist denn das für ein Müll???

Ich hab eben mal eine echte BASIC-Datei umbenannt und da landet der neue Dame auch im Datenfile!

Ich schreib dazu mal was im TopDesk-Thread zusammen mit den Infos die ich da gefunden hab. Evtl. kann Pusti64 das irgendwann mal beheben. Wären wieder ein paar Bytes freier Speicher für sonstiges

DJ SID · 25. März 2022

Ist mir heute aufgefallen. Die D64 Dateien, welche unter GEOS erzeugt werden, scheinen an Größe zuzunehmen. Erst 172 kb, nun inzwischen 174 Kb. Woran liegt das?

darkvision · 25. März 2022

Zitat von DJ SID

Ist mir heute aufgefallen. Die D64 Dateien, welche unter GEOS erzeugt werden, scheinen an Größe zuzunehmen. Erst 172 kb, nun inzwischen 174 Kb. Woran liegt das?

Auf welchem Laufwerk werden denn die D64 erstellt? Kopiere doch zwei D64 (1x172Kb und 1x174Kb) von der gleichen Disk auf ein D81 oder hänge die betroffenen D64 hier an. Ich bräuchte aber Vergleichsdateien...

Oder ist das ggf. nur die Anzeige im Dateimanager? Nicht jedes Programm zeigt die gleiche Größe an (Auf/Abrunden von Bytes nach KByte usw...)

wweicht · 25. März 2022

Zitat von DJ SID

Erst 172 kb, nun inzwischen 174 Kb

...

und es gibt da noch D64, die einen Error-Info-Block haben. Die sind etwas größer als "normale" D64 ....

Gruß

Werner

DJ SID · 25. März 2022

Sind "Normale" D64 Files nicht bloß 170 Kb groß? @ Darkvision: WiC64-Demo für GEOS64

Da ist es mir aufgefallen.

wweicht · 25. März 2022

Schau bitte mal, was in den Eigenschaften bei der Größe in kB steht. Bei einem normalen (ohne Error-Block) hat ein D64 genau 174.848 Bytes. Dann ist alles in Ordnung.

Habe das von Dir verlinkte D64 2x heruntergeladen: 174.848 Bytes

Also alles i.O.

Gruß

Werner

muffi · 25. März 2022

Zitat von wweicht

und es gibt da noch D64, die einen Error-Info-Block haben. Die sind etwas größer als "normale" D64 ....

Heißen die dann nicht G64?

-trb- · 25. März 2022

Zitat von muffi

Heißen die dann nicht G64?

Nein, G64-Dateien enthalten GCR-Daten (im Gegensatz zu D64-Files). Eine zusätzliche Errorinfo in einer D64-Datei sagt m.W. auch nur, welcher Fehler auf welchem Track/Sektor aufgetreten ist.

wweicht · 25. März 2022

... nur der Vollständigkeit halber:

Ein "normales" D64 mit Error-Block hat 175531 Bytes.

Es gibt aber auch noch 40 Tracks-D64. Diese haben eine Größe von: 196608 bzw. 197376 Bytes.

Alle haben die Endung D64.

Gruß

Werner

markusC64 · 25. März 2022

Zitat von darkvision

In der TopDesk-Version wird direkt nach GEOS/RenameFile der GEOS-Dateityp auf $00 getestet und dann der erste Datenblock eingelesen und der Name nach Byte $04 geschrieben. Was ist denn das für ein Müll???

Ich hab eben mal eine echte BASIC-Datei umbenannt und da landet der neue Dame auch im Datenfile!

Oh weia - das ist ja ein ziemlich ernster Bug.

geoConvert

Ähnliche Themen

GEOS MegaPatch V3 Release 2018

MegaAssembler V3.7 im Quelltext verfügbar

Screenshots zu GeoDOS Desktop v3

GEOS 2.0 gekauft - es fehlen GEOWRITE 2.1 und GEOPAINT

Bitte Hilfe bei GEOS2.0 Convert 2.5

DT64 Native-Copy Test für MP64

Geos und SD2IES bzw D64..D81,...

GEOS MegaPatch 64/128 als SourceCode verfügbar!

Tags