MegaAssembler V3.7 im Quelltext verfügbar

HELP WANTED!
Ich versuche gerade MegaPatch auf VICE/x128 zu übersetzen. Dummerweise benötigt der 128er Code zusätzliche MakroTabellen die mir Wolfgang nicht zur Verfügung gestellt hat. Hoffentlich ist das nur eine reduzierte MacTab, falls nicht wird das schwierig. Momentan hole ich eine MakroDef nach der anderen aus der MacTab in die fehlende Datei in der Hoffnung das da nichts an den 128er angepasst wurde.

Außerdem benötigt MP128 mehr Symbolspeicher als die 64er-Version. Alleine beim Kernel bin ich bei 30Bytes Restspeicher!

Daher meine Frage an die 128er-Programmierer:
Beim MegaAss gibt es (hier ab Zeile 3579) eine Routine die Grafik-X-Adressen an 80Z anpasst. Den gleichen (aus meiner Sicht unglücklichen) Code hab ich schon bei geoConvert gefunden und gnadenlos entfernt (weil ich glaube in MegaPatch selbst gibt es so was nicht, d.h. es muss auch anders gehen). Würde man die entsprechenden X-Adressen durch DOUBLE_W usw ersetzen können? Dann müsste man getrennte Versionen für 64 und 128 erstellen müssen, aber jedes Byte Speicher wäre hilfreich. zumal ich vorhabe neue Funktionen zu integrieren.
Die Alternative wäre für mich den Code zu entfernen und den MegaAss nur noch in 40Z anzubieten.

Zitat von wweicht

Sowas braucht man, wenn Programme sowohl mit MP3 64 als auch MP3-128 in beiden Modi laufen sollen. Also bleibt wohl nur 2 Versionen (eine nur 80-Zeichen und eine 40-Zeichen-Variante). Dann kann man auch das DOUBLE_W usw komplett weglassen.

So hatte ich das auch in Erinnerung. Der Vorteil (m.M.n.) ist aber das man keine if c128/endif Abfragen benötigt. Beim 64er wären die Werte halt unititialisiert.
Falls mir der Speicher bei MP3/128 nicht reicht schmeiße ich den Code einfach mal raus und ersetze die X-Adressen mittels DOUBLE_W (links) bzw. DOUBLE_W!ADD1_W (rechts).

geoConvert braucht ja eh niemand mehr UUE-Konvertierung & Co sind heutzutage ja nicht mehr notwendig. Und es gibt sicherlich bessere Tools für CVT/D64. Hab das jetzt mal nur für mich angepasst um D71/D81 zu Backup-zwecken lesen/schreiben zu können. Da reicht m.M.n. auch 40Z. Aber derzeit ist der 80Z-Modus komplett raus.

Zitat von wweicht

na ja, höchstens für das G98-Format ....

Weil Du das Format ansprichst... ich dokumentiere ja gerade geoConvert3.9 (Das wird die beta zu geoConvert v4, die alpha-Version war der Test für den MP3-Code-Transfer von 1581-Flopy auf PC) und da wollte ich auch das CVT/G98-Format nochmals genauer beschreiben weil mir nicht mehr klar war was da eigentlich der Grund für das G98-Format war. Hast Du Dich näher damit beschäftigt?

Wenn ich das richtig sehe kann Convert nur VLIR-Datensätze mit max. 255 Sektoren behandeln. Ich kann mich nicht mehr an den Grund erinnern warum G98 entstanden ist, aber G98 hängt an den ersten CVT-Infoblock einen zweiten Info-Block dran wenn die Länge eines VLIR-Datensatzes 255 Sektoren überschreitet. Momentan erlaubt das doch nach Adam Riese:
127 VLIR-Datensätze a 65535 Sektoren a 254 Bytes = 2.114.028.030 Bytes und nicht wie ich in der Doku schreibe bis 16Mb (sondern eher 2Gb). Die 16Mb können ja nur von der max. Partitionsgröße herrühren (max. 255 Spuren a 256 Sektoren a 254 Bytes ~16Mb). Die 2gb dürfte man also in der Praxis gar nicht ausschöpfen können. (Rein theoretisch könnte man die 2Gb noch etwas aufbohren, denn ich hab noch ein Byte je VLIR-Datensatz frei = max. 500Gb , ich weiß, blanke Theorie)

Oder hab ich da einen Denkfehler? Gibt es denn überhaupt so große GEOS-VLIR-Dateien? Das können ja nur Dokumente mit sehr langen Datensätzen sein. Das G98-Format kann mit geoConvert nicht manuell erstellt werden, sondern (wenn da kein Fehler vorliegt) nur wenn mind. 1 Datensatz min 256Sektoren hat. Dann wird die Datei als G98 erzeugt. Also wenn es keine bekannten Dateien gibt war das sowieso ein Schuss ins Blaue und völlig unnötig

Markus

Zitat von wweicht

Bei den ersten MP3-Versionen bis irgendwann 1999 gab es nur eine Installationsdatei für MP3 die fast 164 kB Größe hatte. Topdesk wurde hier noch extra auf einer weiteren Disk angeboten .

Stimmt... hab da in einer alten Newsgroup die Datei gefunden und analysiert. War eine VLIR-Datei und alle MP3-Daten waren in einem VLIR-Datensatz gepackt. Damit kann der natürlich größer als 64Kb werden, da der Datensatz nicht am Stück eingelesen wird. Sondern vermutlich in einzelne Dateien entpackt wird.

Zitat von wweicht

Wenn ich das jetzt richtig im Kopf habe, geht das .CVT-Format nur bis ca. 32 kB .

Wenn ich das jetzt nicht falsch verstanden hat nutzt Convert nur einen 1-Byte-Sektor-Zähler. Mit 1Byte können daher max. 255 Sektoren verwendet werden. Bei 254 Bytes je Sektor sind das rund 64Kb in *EINEM* VLIR-Datensatz. Die Datei kann sogar 127*255*254= ~8Mb groß sein ohne das geoConvert das g98-Format anwendet. Erst wenn bei einem Datensatz der Sektorzähler >=256 ist, dann wird g98 verwendet. Das trifft auch nicht auf GEOS/Seq.-Dateien zu, denn da wird der Datenstream gar nicht verändert, nur am Anfang der Convert-Header eingefügt. Diese konnten schon immer fast beliebig groß sein. Es geht nur um VLIR-Dateien.

Ob MP3 damals der Grund war, glaub ich nicht. geoConvert hatte ich ja schon länger im Einsatz. Aber das ist jetzt einfach zu lange her. Sei es wie es ist, es gibt Dateien in dem Format, also lasse ich das mal im Programm, aber der 80Z-Code ist raus. Hab eben mal versucht über Double_W!Add1_W die X-Koordinaten anzupassen. Das Hauptmenü wurde auch korrekt angezeigt, aber danach nur ein Absturz... halber Bildschirm links OK, rechts wurde noch der TopDesk angezeigt. Ich glaube da muss man schon noch mehr machen aber da ich das nicht brauche und für andere das Programm fast nutzlos ist... werde ich da auch nicht mehr weiter forschen.

Ich mach da morgen oder Freitag ein Release draus, dann gehts wieder an den MegaAss... der braucht ein Update für MP3

Zitat von Pusti64

Was genau hast Du da geplant?

Nichts dramatisches... Momentan kann der AutoAssembler aber keine Laufwerke wechseln, sondern nur ggf. Partitionen (über die AutoAssembler-Konfiguationsdateien). Mit einer RAMLink oder HD klappt das Prima. Hat man aber 3xRAM1581 oder gar 3x1581 wird das schwierig wenn der Code mehr als 1x1581-Partition belegt. Und da ich keine Lust mehr habe bei MP3 alle Dateien von Hand zu übersetzen will ich dem AutoAssembler beibringen das Quelltext-Laufwerk zu wechseln. Das dürfte nur eine minimale Änderung sein.

Das mit dem SymbTab nur 1x übersetzen hab ich im Hinterkopf, das wird aber schon etwas aufwändiger und daher steht das weiter hinten auf der ToDo-Liste.

Zitat von Pusti64

Ich habe mir am Wochenende Dein geoConvert4-Sourcecode runtergeladen und kompiliert. Ich konnte bisher keine Fehler feststellen und finde, dass Dir das Programm sehr gut gelungen ist.

Danke
Hab das Programm ja nur aktualisiert damit ich die 81er-Partitionen von meiner HD sichern kann, dachte nicht das sich überhaupt jemand die Mühe macht das Programm im SourceCode herunterzuladen und dann auch noch zu kompilieren
Bei der Arbeit an geoConvert4 hab ich aber (so glaube ich) einen Bug im Dateilisten-Menü gefunden der sich evtl. auch auf den MegaAss auswirkt. Unter ganz seltenen Umständen kann evtl. die letzte Datei in einem Verzeichnis im MegaAss nicht als Quelltext ausgewählt werden: Nämlich dann wenn es nur noch eine weitere Datei gibt. Dann zeigt das Menü nämlich nicht mehr ">>Weiter" an sondern "<<Anfang". Damit kommt man nicht mehr zur letzten Datei im Verzeichnis.

In der Version 3.9 hab ich das evtl. behoben. Zusammen mit kleinen Änderungen um den VICE-Support zu verbessern (ein Bug hat mir heute fast den ganzen Tag geraubt!) und um MegaPatch3 wieder automatisch kompilieren zu können. Zumindest auf dem 64er muss ich derzeit nur 2x den MegaAss starten und zwei Jobs ausführen um MP3 zu kompilieren. Hab MegaAss jetzt auch so erweitert das ich verschiedene Setups für MP3 anbieten kann, RamLink, 2xRAMNative oder 2x1581, Mit Hilfe des MegaAss und passenden UserJobs kann der AutoAssembler jetzt auch zum DiskWechsel auffordern. Das funktioniert dann auch unter VICE: Man kann dann einfach das DiskImage wechseln und anschließend weiter kompilieren.

Unter GEOS128 dürfte das wahrscheinlich zum Problem werden, da einige Programmteile ja den Symbolspeicher schon fast komplett ausgereizt haben. Allerdings hab ich jetzt am 64er ein sehr gutes Setup gefunden und ich denke damit kann ich das dann auch am 128er relativ einfach testen. Evtl. lassen sich die fehlenden Bytes ja mit kleinen Korrekturen raus-quetschen. Ansonsten muss halt Plan-B her.

Markus

Zitat von Pusti64

Ich finde es jedenfalls cool und werde es von nun an regelmäßig nutzen

Am 64er oder 128er? Falls 128er: Wie "schlimm" ist es das es nur noch im 40Z Modus läuft?

Markus

P.S. MegaAssembler V3.9 verfügbar. Sofern ich keine weiteren Fehler finde wird dieses Release benötigt um MP3 zu kompilieren... Feedback is welcome...

Zitat

Added MegaAssembler V3.9 to /src and /doc directory. Only a few changes:In AutoAssembler-Mode $f2,<DEVICE> will switch the source drive. If <DEVICE> is NULL then the default source drive from the main menu will be set as new source drive.In some very rare situations the last file in the current directory could not be selected from the 'files' menu.When using VICE selecting a file from the main menu could fail because checking for a mouse button pressed will exit the current compile job. Applied a fix to wait for 'no mouse button pressed' to fix that issue when a source file is selected.

P.S. Dem aktuellen Release hab ich einen Druckertreiber beigefügt den ich damals zum bearbeiten von Quelltext verwendet habe. Der Treiber nutzte damals am EPSON-Drucker einen kleinen NLQ-Font mit ca. 100Zeilen pro Seite. Außerdem zwei Schriftarten: 81´Assembler ist die Schriftart von vor 20Jahren und ähnelt dem C64-Font. Die meisten meiner früheren Quelltexte wudren damit bearbeitet. 82'Assembler ist ein neuer, selbst-erstellter Mono-Font mit dem ich geoConvert4 bearbeitet habe.

Zitat von Pusti64

Hut ab darkvision, so macht kompilieren einfach nur Spaß und wird nicht wie sonst zur zeitraubenden Angelegenheit.

Ist aber purer Eigennutz weil ich nicht selbst vor der Kiste sitzen will um 300 Dateien auf zwei System auf sechs Disketten zu kompilieren. Nene... man hat ja noch anderes zu tun

Zitat von wweicht

Aber vielleicht findet sich jemand, der in der Zwischenzeit (ich komme demnächst sicher nicht dazu) das Ding für 80 Zeichen umprogrammiert (kann ja auch ein eigenes Programm sein).

Im MegaAss gibt es ja eine Routine für das wechseln von 40 nach 80Zeichen. Wenn ich mal dazu komme kann ich mir ja anschauen was dazu notwendig ist. Das eigentliche anpassen mittels DOUBLE_W usw ist ja nicht so aufwändig. Aber wie Du auch komme ich in nächster Zeit nicht dazu