Posts by darkvision

Quote from GoDot

Das wär doch mit GEOS auch kein Problem?

Nö, Text an einen Drucker zu senden ist bei CENTRONICS oder Serial kein Problem. Aber wenn der Drucker EPS nicht kennt hilft das ja nichts.

Quote from Markus64

ich habe keinen TheC64 und wenn ich mir das "Project Caroussel USB" im verlinkten Forum anschaue, schreckt es mich auch eher ab, als es mich anfixt. Schon der erste Beitrag ist so bunt und lang, dass ich schnell wieder weg bin.

Das stimmt schon... vielleicht kann FrankyByte im ersten Post die paar Schritte für die einfache "Installation" der FUGS Version für die deutschsprachigen User ergänzen.

Ich hab mir die verlinkte Seite auch nicht durchgelesen, sondern nur überflogen um den Download-Link zu finden. Der geht schon etwas im Text unter... Aber ich kenne das von mir selbst wenn ich Anleitungen schreibe. Für mich ist das alles klar strukturiert... aber alle anderen sehen das anders

Ich denke aber das die ganzen Detail-Einstellungen oder Optionen dort schon richtig aufgehoben sind, denn er kann da evtl. Fehler schnell ausbügeln. Dafür sollte man sich dann auch mit den PCU beschäftigen.

Aber ein QuickGuide würde sicherlich nicht schaden.

Quote from Retro-Rentner

Achsooooo! Das erklärt dann die Größe!

Wobei das bei mir FUGS 460Mb gepackt und knapp 800Mb entpackt sind. Also nicht ganz so schlimm wie die BGS-Version. Wobei mich der von FrankyByte erwähnte X-Windows-Mod auch interessieren würde. Kommt auch mal auf die ToDO-Test-Liste...

Quote from Freddy

Tadaa

Ein Freiwilliger

Quote from tilobyte

Ok, das sollte keine Kritik an Geos oder den Programmierern sein.

So hatte ich das auch nicht aufgefasst...

Quote from tilobyte

Ich kenne mich da ja noch nicht so aus und hatte bisher gedacht, das in den 90ern doch andere Programmierer neue Druckertreiber für die Geosprogramme geschrieben hatten, aber dann kamen leider keine mehr.

Ich hatte auch mal einen eigenen für GEOS geschrieben, das senden von Text an einen seriell angeschlossenen Drucker ist aber einfach, im Vergleich zum Anschluss einen *NEUEN* Druckers an einen C64 ohne USB/Netzwerk. Später kam dann noch ein UserPort-Anschluss dazu, ging auch noch relativ einfach.

Quote from tilobyte

Also ist es so, das die Treiber eigentlich alle noch älter und hauptsächlich Bestandteil der kommerziellen Geosprogamme waren?

Sagen wir mal so, die meisten ja. Und nicht mal der Programme an sich, sondern vom GEOS-Betriebssystem der ersten Stunde bzw. GEOS V2 von M&T.

Es gab dann zwar einige weniger neue, es gab dann noch ein paar Disks mit neuen Druckern, und dann so Sachen wie GEOS-LQ aber das waren ja alles Peanuts, weil fast alle Drucker ähnlich angesteuert wurden. wweicht weis da vielleicht mehr, aber ich glaube nicht das es viele andere Druckertreiber nachträglich für Laser gab.

ESC/P2 war ein sehr einfaches Protokoll. Früher waren die Steuercodes sogar noch in einem Handbuch abgedruckt. Viele Druckertreiber brauchten auch nur eine kleine Korrektur, oder eine andere Schnittstelle über den UserPort. Aber die Treiber liesen sich fast immer in den 2K Speicher unterbringen.

Ähnlich wie der DruckerSpooler unter MP3 könnte ein Druckertreiber heute aber auch über auf die REU zugreifen und z.B. erstmal alle Druckdaten abgreifen und speichern. Am Ende des Druckvorgangs startet man dann ein Programm was die Daten für Laser umrechnet und ausgibt.

Warten wir mal ab was Freddy hinbekommt ansonsten glaube ich wird da nicht mehr viel kommen. Evtl. wäre der Weg wie GoDot ihn mit dem EPS-Drucker beschrieben hat eine Alternative. Direkt drucken würde man das dann aber auch nicht. Ich würde mal behaupten es braucht dann mind. 3x64Kb an Speicher für die Umwandlung. Und dann muss das Ergebnis gespeichert werden. Dann muss es zum PC und dann dort drucken. Da kann ich das Bild gleich mit GoDot nach PCX/GIF wandeln und am PC bzw. in ein PDF wandeln.

Quote from Freddy

Es gab kaum 'kommerzielle' Programme.

Naja... selbst wenn Software auf einer Heftdisk angeboten wurde wäre das für mich kommerziell, man musste ja das Heft kaufen um an die Daten zu kommen. Ich glaub da gab es schon das eine oder andere GEOS-Sonderheft auf dem neuen Druckertreiber dabei waren.

Quote from Freddy

Auf dem amerikanischen Markt sah es möglicherweise anders aus.

Naja... wenn in US einer einen kommerziellen Laser-Treiber entwickelt hätte, dann hätte man da sicherlich auch in DE von gehört.

Wie gesagt, ich war lange Jahre raus und hab vieles nicht mitbekommen, aber Ende der 90er hab ich kaum neue Druckertreiber gefunden. Warum auch, die meisten damaligen Drucker hatten ja mit irgendeinem bekannten Treiber funktioniert. Ich für mich hab zum Schluss nur noch Text gedruckt, also in NLQ, nicht im Grafikmodus.

Quote from tilobyte

Ich finde es schade, das gerade Geos/ Wheels/ MP3, was doch irgendwie darauf ausgelegt ist, Sachen (auch schön) auszudrucken, bei Treibern und unterstützten Druckern auf dem Stand der 90er Jahre stehen geblieben ist.

Nein... GEOS/Wheels/MP3 sind nicht darauf ausgelegt, Dinge schön auszudrucken. Drucken tun geoWrite und geoPaint. Und die sind noch auf dem Stand von vor 30Jahren.

Die Schnittstelle waren dann Druckertreiber aus den 80ern, die funktionieren theoretisch auch heute noch. Es müsste sich nur ein Programmierer finden der sich mit den neuen Druckern auskennt, der weiß wie die Daten an die Geräte geschickt werden können und der Lust hat sich mit der Materie bzw. dem PS-Protokoll auseinanderzusetzen.

Mit GEOS/Wheels/MP3 hat das eigentlich nur in sofern etwas zu tun, als das die neue Anwendung eben damit kompatibel sein muss. GEOS-LQ war ja auch nicht Teil von GEOS. Das geoLaser und Druckertreiber damals bei GEOS 2.x mit auf Disk waren ist logisch: Ohne das hätte man schon damals nichts drucken können.

Leider gibt es von den ganzen GEOS-Programmen den Original SourceCode nicht. Und das per Reverse Engineering zu machen ist auch kein Spaß. Sonst könnte man geoLaser analysieren und ggf. anpassen.

Das Problem ist als weniger GEOS/Wheels/MP3 als vielmehr die geringe Anzahl an Programmierern die das können und wollen... und die Hardware dazu haben. Und nein, Laser kommt mir nicht ins Haus.

Quote from Retro-Rentner

1,8 GIGAbyte? Ich dachte, das sei eine Oberfläche, um C64-Spiele am C64 Mini auszuwählen.

Wozu benötigt eine Menü-Oberfläche 1,8 Gigabyte?

Wenn es nur eine "Oberfläche" wäre um Spiele zu starten, warum dann überhaupt das Projekt? TheC64 hat bereits eine Oberfläche.

Nein, da sind viele, viele Spiele (623++) inkl. Carousel-Icon mit enthalten, sonst wäre das ja Witzlos...

Quote from Retro-Rentner

Ich muss nichts wagen? Weil´s risikolos ist?

Ja... TheC64 abschalten, Stick raus, Einschalten... TheC64 startet wie vor dem Test mit PCU...

Quote from Retro-Rentner

Wenn man das mit einem fast halbstündigen Video erklären muss, kann´s nicht wirklich "easy" sein.

Ich kann Dir eine Stunde lang erklären wie man einen WebBrowser am PC unter Windows startet. Der kann aber so viel mehr das man da schon auch etwas mehr dazu sagen kann. Fakt ist aber: Du brauchst Dir das Video nicht ankucken wenn Du nicht willst... aber evtl. entgehen Dir dann ein paar der zusätzlichen Funktionen. Gestartet bekommt man das auch ohne Video... wenn man die Update-Funktion kennt...

Quote from Retro-Rentner

Ich habe mal versucht, mit einem Raspberry & LibreElec & KODI ein Mediencenter zu "basteln".

Das ist Äpfel mit Birnen vergleichen... weil...

Quote from Retro-Rentner

Ich vermute/befürchte, das C64-Carousel fällt in die gleiche Kategorie wie die obigen Sachen.

Jemand hat sich damit richtig viel Mühe gegeben und sich da reingefuchst.

Für ihn ist das alles kinderleicht und logisch.

Für Neueinsteiger wie mich aber nicht und mit viel Arbeit verbunden.

...

aber ich fürchte, bis es soweit ist, gehen etliche Stunden Arbeit drauf.

Display More

Völlig Falsch... ich würde mich nicht trauen sowas zu schreiben wenn ich es selbst nicht mal getestet habe. Das verleitet andere dazu zu denken das Ding sei Müll...

- Neuen USB-Stick gekauft (brauchte ich eh später für was anderes)

- Den Inhalt des ZIP in das Hauptverzeichnis des Stick entpackt

- Den Stick in den TheC64 gesteckt

- TheC64 eingeschaltet

- Konfiguration (Der Schraubenschlüssel) ausgewählt

- Systeminformationen

- "Update 9_9_90 gefunden... aktualisieren?"

- Aktualisieren angeklickt...

- PCU startet und ich hab die Favouriten-Spiele zur Auswahl....

War das jetzt so kompliziert? Das entpacken hat noch am längsten gedauert. Es gibt nur einen typischen Fehler den einige gerne machen -> Das Zip in einen Unterordner entpacken. Das ist dann der Fall wenn im obersten Verzeichnis keine Datei "theC64-9_9_90.bin" vorhanden ist. Dann einfach alles aus dem Unterordner in das Hauptverzeichnis verschieben:

Das muss im Hauptverzeichnis zu sehen sein.

Die nächste Liste zu laden ist jetzt auch nicht schwer:

- Konfiguration (Der Schraubenschlüssel) ausgewählt

- "Nächste Spieleliste laden"

- "Öffnen" angeklickt...

Jetzt hat man A-G zur Auswahl... für die nächsten Spielelisten einfach wiederholen.

Ich hab dann mal auf S-Z weitergeblättert und "TestDrive" gestartet. Geht alles wie am Schnürchen.

Und ich hab das Video jetzt nicht angeschaut, aber hab einige andere Threads zu dem Thema mitverfolgt, und daher war mir das mit dem Update klar. Da das Update aber nur temporär ist, ist das ganze wieder umkehrbar. Ich hab jedenfalls den TheC64 abgeschaltet, Stick gezogen, wieder eingeschaltet und die Original-Games waren wieder da.

FUGS oder BGS hört sich jetzt komplex an, aber ich habe FUGS gewählt, das mit dem Systemupdate funktioniert ja. Bei BGS muss man wohl ein paar der JoyStick-Tasten programmieren, damit man damit die Gamelist wechseln kann. Ist Optional, FUGS ist völlig OK.

Quote from Retro-Rentner

2.) Warum muss ich mich noch in einem anderen Forum registrieren?

Hätte man die Dateien nicht hier anhängen/verlinken können?

Muss man nicht, ich habe FUGS auch so herunterladen können. Und 1,8Gb kann man hier nicht anhängen. Und ich finde auch besser wenn man den Link zum Entwickler bereitstellt, der aktualisiert das ja regelmäßig. Und ich finde das darf man durchaus auch erwarten, das jemand einem Link folgen kann.

Ich hab das Video nicht gesehen (hole ich ggf. mal nach), hab nicht Stunden an Arbeit investiert, nicht einmal 5min (exklusive Aufbau des TheC64), hab mir keine TruBlue-Stick gekauft... ich finde das PCU-Projekt wirklich Easy.

Quote from FrankyByte

C64-Emulator mit der Option, die Joystick-Ports (Port 1 oder Port 2 bei laufendem THEC64) zu ändern die RESTORE Taste drücken

Danke für den Tipp.

Ich hab da mal in die start.sh-Datei geschaut, man kann da wohl auch JiffyDOS aktivieren. Wenn ich mal wieder Lust habe den TheC64 auszupacken, dann teste ich das mal. Dort hab ich auch den Hinweis auf die RESTORE-Taste gefunden.

Aber so funktioniert das mit FUGS bei mir "Out-of-the-Box"...

Bin kein Gamer, trotzdem

Quote from Juergen Johannes

Wenn ich demnächst mal dazu komme, würde ich die Konfiguration GEOS MP3-64/C64/SCPU64/TC64V1 gesteckt in C64 (darf man das überhaupt zusammen mit SCPU64) und anderen LW, mal gerne austesten.

Also ich würde nie auf die Idee kommen das zu testen. Beides zusammen wird die Geschwindigkeit nicht verdoppeln und die SCPU verändert im aktiven Modus schon einiges am C64 das hier das TC64 sicherlich nicht mehr mitkommt.

Ich empfehle Dir DRINGEND das TC64 Handbuch zu lesen:

Quote

ACHTUNG: Außerdem funktioniert das Chameleon nicht an Modul-(Expansionsport-)Expandern – weder als einziges Modul, noch in Verbindung mit anderen. Es funktioniert nur, wenn es direkt am C64 angeschossen wird. Probieren Sie nicht, dass Chameleon mit anderen Modulen zu 'mischen'! Es kann nicht funktionieren und Sie laufen Gefahr, Ihre wertvollen Geräte zu beschädigen. Sie verlieren zusätzlich Ihren Garantieanspruch.

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.

Quote from uwe1972

-Die DNPs wurden mit GeoDos erstellt und zeigten Keinerlei Fehler,

beim Überprüfen, weder unter Gdos noch Geodesk,

auch das Ordnen von Dateien klappt (auch jetzt noch) problemlos unter Geodesk,

nur das ich Nix kopieren kann, wender von noch auf ein DNP/D81

-Jetzt habe ich wieder 4x 1581, damit klappt alles Problemlos.

Display More

Hast Du eine andere GEOS/MP3-BootDisk? Wenn 1581 funktioniert und DNP nicht könnte ein Laufwerkstreiber (und die Datei GEOS64.Disk) beschädigt sein.

Quote from 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).

Quote from 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:

Quote from 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

Display More

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:

Quote from FXXS

Konnte ich...

Danke!

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

Das sind eigentlich GEOS-Standardfehler... müssten eigentlich auch mal in einem GEOS-Handbuch abgedruckt gewesen sein. Das ist die einfache Tabelle aus dem Programmierer-Handbuch, siehe Anhang.

Die Programme können natürlich auch eigene Fehler-Codes verwenden, aber die Codes hier waren quasi "Standards", ich glaube einige passen sogar zu den Commodore-Fehler-Codes.

Quote from uwe1972

"Kopieren/Verschieben fehlgeschlagen! Fehlercode $05"

Wenn es der GEOS-Fehlercode ist, dann wäre $05 = "Datei nicht gefunden".

Mit welchem Desktop? Andere DeskTops (TopDesk, dualTop) getestet? Oder mit GeoDOS mal gegengetestet?

Quote from 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

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

Quote from wweicht

und mit dem neuen MegaAssembler (von Di Abend) wird auch GeoDesk64 wieder korrekt assembliert.

Danke fürs testen, hab das gleich in die README mit aufgenommen. Heißt dann aber auch das jeder der längere Versionsnummern will auch die V4.1 zum assemblieren verwenden muss.

Jetzt muss ich nur nochmal prüfen warum da ein Absturz passiert, aber vermutlich sucht GeoDesk64 dann auf anderen Laufwerken nach einer Kopie weil es GeoDesk64 auf dem StartLaufwerk mit der richtigen GEOS-Klasse nicht findet und das führt dann zum Absturz, wenn es nicht die 100%ig gleiche Version ist.

P.S. Nö... schon gefunden... TippFehler und dann Copy&Paste sorgt dafür das die "GeoDesk64 nicht gefunden" DialogBox nicht angezeigt wird, was dann zum Absturz führt. Pusti64 Danke fürs testen. Damit MegaAss 4.1 wiederentdeckt und einen Fehler in GeoDesk64 gefunden...

Quote from wweicht

Um kompatibel mit anderen Sachen (z.B. Bachmänner (4 Laufwerksflag bzw. Farbe)) zu bleiben, will ich nur ein Byte mehr: 12 Zeichen "Klasse" + 5 Zeichen Version: Vx.xx. Das funktioniert problemlos.

Es sind jetzt in v4.1 zwei Bytes mehr:

Klasse = 12Z.

V = 1Z

1.xyz = 5Z

=18 + abschließendes NULL Byte.

dualTop/TopDesk zeigt die Klasse damit auch korrekt an. Und GeoDesk64 müsste das auch schon können. Ich hab das jetzt ein halbes Jahr getestet Hier scheint es zu funktionieren.

Aaaaah!!!!! Mir fällt gerade ein das ich am MegaAss ja jwas geändert hab, damit überhaupt längere Versionsnummern ( wweicht erinnert sich vielleicht an die Diskussion) funktionieren.

Ich hab hier die Version V4.1, da wird dann die "1.02" erzeugt (oder auch "1.234"). Die MegaAss-Version V4.0 kann das glaub ich noch nicht, da wird dann "1.02" zu "1.0".

Werde ich wohl mal das Update hochladen müssen

Quote from Pusti64

So, Sources erneut runtergeladen und wie oben beschrieben assembliert.

GeoDesk64 startet aber leider immer noch nicht durch bzw. bleibt hängen

Was auffällig ist: Bei Dir wird als Version in der GEOS-Klasse von GeoDesk64d "1.0" angezeigt, im SourceCode steht aber 1.02. D.h. Irgendwo hatte MegaAss dann noch eine ältere -SYS.CLASS.h-Datei gefunden. Die Klasse innerhalb von GeoDesk64 scheint korrekt zu sein.

Absturz lässt sich mit Deiner Version reproduzieren. Ändere ich die Klasse auf 1.02, dann startet das Programm ganz normal. Also bitte mal prüfen ob da auf einem anderen Laufwerk Dateien mit obigen Namen liegen...

P.S. Auf dem Linker-Laufwerk liegt nicht noch eine ältere Version von GeoDesk64d? Wenn da nur die Module ausgetauscht werden und beim linken nicht "Löschen" gewählt wird, dann bleibt die alte GEOS-Klasse auch erhalten.

Wie hattest Du du die Laufwerke im MegaAss konfiguriert?