GEOS MegaPatch 64/128 als SourceCode verfügbar!

Forum64_Wolke\Software\Geos\System\Deutsch\GEOS64_V2.0_M&T_DE_uninstalliert.7z sowie GEOS128_V2.0_M&T_DE_uninstalliert.7z. Ist jeweils in der Zusatzdiskette enthalten, die nicht zum originalen Lieferumfang gehört, sondern von Werner stammt.

Zitat von darkvision

MakeBoot wird gesucht. Aber der Bildschirm bleibt weiß, d.h. das Programm wird gar nicht erst gestartet?

Ja, so sieht es aus.

Zitat von darkvision

Wenn GEOS.MP3 gestartet wird und die Abfrage mit dem Mauszeiger kommt, dann wird auch die RAMGröße angezeigt und danach die Startadresse/Blockgröße. Kannst Du mir sagen was da angezeigt wird?

Kann ich nicht ganz genau sagen, aber auf jeden Fall stand da:

GEORAM, 2048Kb, $00:0000

Zitat von darkvision

Wenn Du ein anderes MP3 startest, kannst Du dann auf der Disk mal GEOS.MP3 ausführen? Die Dateien müssten ja alle auf der Disk sein. Funktioniert dann das "Upgrade" ?

Ups, falsch gelesen . Habe jetzt auf der Disk "nur" Geos128.MakeBoot nochmal per Hand gestartet. Dann läuft es.

MountBBGRam ist im MSPI-Geos (M&T) auf der Wolke enthalten. Man kann damit nur M&T-Disketten für GeoRAM und kompatible anpassen. Umgekehrt gibt es meines Wissens nichts. Da ist auch das "richtige" MountBBGRam drauf. Die originale Version davon setzt Geos auf US....

Zitat von darkvision

Als Bestätigung wäre es aber gut zu wissen ob das mit der Ultimate und 2Mb GEORAM funktioniert.

Da komme ich leider frühestens morgen Abend zu ......

Gruß
Werner

Zitat von darkvision

Als Bestätigung wäre es aber gut zu wissen ob das mit der Ultimate und 2Mb GEORAM funktioniert.

So, habe das jetzt mit der geoRAM der1541 UII+ durchprobiert...

Zitat von darkvision

Kein Problem... ich kann das jetzt hier zuverlässig reproduzieren.

GeoRAM auf 2 MB gestellt:
Während der Installation wird mir angezeigt: DACC-Speicher Georam 2048 kB $00 :0000/$10
Installation läuft durch. Kein Problem

GeoRam auf 4 MB gestellt:
Während der Installation wird mir angezeigt: DACC-Speicher Georam 2048 kB $00 :0000/$10
Installation läuft durch. Kein Problem

GeoRam auf 8 MB gestellt:
Während der Installation wird mir angezeigt: DACC-Speicher Georam 2048 kB $00 :0000/$20
Installation hängt, wie bei 16 MB beschrieben...
Hoffe, das hilft ein wenig weiter.

Gruß
Werner

Zitat von darkvision

Für wie viel MB war denn MountBBGRAM ausgelegt?

MountBBGRam stammt von Performance Peripherals. Es (AutoExec) dient eigentlich nur dazu, bei laufendem Geos (BerkeleySoftworks, M&T und MSPI) statt die Hardware CBM-REU die Hardware GeoRAM (und kompatible) zu erkennen. Größe zunächst egal ;-). Natürlich benötigt man auch das entsprechende Konfigurieren für die GeoRAM. Damit das läuft, muss "MountBBGRam" als erstes AutoExec noch vor dem Konfigurieren gespsichert sein.
Es macht quasi aus einer Geos-Bootdisk von Berkeley/M&T/MSPI (original oder CMDs GeoMakeBoot) eine Bootdisk für GeoRAM. Dabei wird aber (bis auf Konfigurieren) nichts auf der Boot-Disk geändert.

Zitat von darkvision

MP3 installiert die Speicherbereiche im erweiterten RAM während dem Update mit den alten GEOS-StashRAM-Routinen da der neue Kernal noch nicht im System installiert ist

Zitat von darkvision

Eigentlich dürfte man GEOS128-2.0r nur mit soviel RAM starten wie von der GEOS-Version unterstützt wird. In meinem Fall nur 512Kb. Aber da bis 4Mb die Bankgröße gleich ist spielt das bis 4Mb keine Rolle.

Und das funktioniert mit CBM-REU nur, weil die Blockgröße sich nicht ändert?
Wenn ich aus dem normalen Geos V2 für CBM-REU (Berkeley Softworks/M&T/MSPI) heraus installiere habe ich doch auch nur 2 MB maximal.....

Gruß
Werner

Zitat von wweicht

Größe zunächst egal ;-). Natürlich benötigt man auch das entsprechende Konfigurieren für die GeoRAM.

Soweit ich weiß, hat noch niemand mit MountBBGRAM von einem GeoRAM mehr als 4 MB benutzt. Daher wäre der einzige mögliche Beleg ein Disassembly des GeoRam-Zugriffs im MountBBGRan.
Nachtrag: Oder halt damit auf mindestens 8 MB fehlerfrei zugreifen.

Freiwillige vor .

Hier die originale und eine gepatchte Disk mit MountBBGRam. Das original hat das Länderflag des deutschen Geos geändert......

Gruß
Werner

Hm ja. Falls meine Idee klappt, ist das nicht schwer: Breakpoint im Vice auf die GeoRAM-I/O-Adressen und den Bereich, wo man dann landet, im VICE ansehen.

Zitat von darkvision

Links eine 4Mb GEORAM und wie GEOS2.0r hier die 16Kb-Bänke organisiert. Der rechte Block zeigt wie GEOS2.0r die Daten in einer 16Mb-GEORAM organisieren müsste. Wenn man Bank#0 anspricht kopiert GEOS2.0r hier trotzdem nur 16Kb Daten rein. Das die Bank 64Kb groß ist, davon weiß GEOS2.0r nichts. Die restlichen 48Kb bleiben unberücksichtigt.

Dieses fehlerträchtige Block/Bank-Gedöns wird gedanklich viel handlicher, wenn man die beiden Zugriffsregister einfach als "Track" und "Sector" bezeichnet. In der Minimalgröße von 512 KiB sind die Registerbreiten so gewählt (6 Bits und 5 Bits), dass eine 1541-Disk ohne jede Umrechnung abgebildet werden kann. Man könnte fast meinen, die Entwickler hätten sich was dabei gedacht...

Falls Du allerdings im GeoRAM-Treiber noch einige Bytes (ich kann nicht sagen, wie viele genau) frei hast, ließe sich da was machen. Ähnliches habe ich bei der 1541 U2(+) nämlich auch gemacht, damit man Images einladen kann für die wichtigen Fälle 4 MB und kleiner (größere GeoRAM Images hatte zu den Zeitpunkt eh keiner, weil es ein solches GeoRAM vorher schlicht noch nicht gab).

Edit: In den nachgfolgenden Details ist der Wurm drin, die Idee passt, aber die Details nicht:

Statt zzxxxxxx yyvvvvvvvv nach $DFFF $DFFE zu schreibenm sortiert man die Bits etwas um: yyxxxxxx zzvvvvvvvv.

Wenn man jetzt "nur" höchstens 4 MB nutzt, so ist zz=00 und somit findet vor und nach der Umsortierung, dass ein Zugriff auf RAM <= 4 MB dort landet, wo Geos 2.0 ihn auch hin schreiben würde.
Auf der anderen Seite wird aber jede Speicherseite eindeutig wiedergefunden.

Dummerweise darf man diese Umsortierung nur machen, wenn die REU 16 MB groß ist. Bei 8 MB muss man ein Biit weniger vertauschen: zyxxxxxx 0avvvvvvvv -> zaxxxxxx 0yvvvvvvvv. Argumentation ansonsten analog.

Ups, da habe ich mich bei den Vertauschungen irgendwie vertan, wie ich gerade merke, als ich mir Essen machen will... Die Grundidee stimmt, die Details aber nicht.

Ich bin gerade am Nachdenken, ob folgendes passt:

zzyyyyxx wwvvvvuu -> yyyyxxww zzvvvvuu (zz = 0 für ≤ 4 MB)

Edit: Ja, genau das ist die Transformation, die man braucht. Die Inverse davon mache ich nämlich inder U2(+)/U64.

Zitat von darkvision

Ich glaub ich las das erst mal so. Das funktioniert ja nun und ist ja auch plausibel nachzuvollziehen.
Ich wer das aber in die Liste der "KnownIssues" mit aufnehmen. Hinweis kann da nicht schaden.

Sehe ich auch so. Nur wegen der Installation das ganze langsamer zu machen lohnt sich nur sehr bedingt... Bei der U2(+)/U64 ist das was anderes, der FPGA simuliert eine Hardware, die das native ohne Zeitverlust macht (als Hardware kann man sich einfach vorstellen, man vertaucht bei der Verkabelung die Drähte; also geht das in Hardware zeitneutral).

Zitat von C=Mac

HD Parallel 2.6 sec.
HD Serial 6.4 sec.
SD2IEC 6.4 sec.
RamLink 1.4 sec.

Mir liegt ein nicht eigenes Testergebnis vor, welches besagt: ARM2IEC Parallel (Dolphin DOS): Etwas über 2 sec.

Womit sich bestätigt, dass der IEC Bus der Flaschenhals ist.

Wie auch immer: Kein signifikanter Unterschied zwischen SD2IEC/ARM2IEC und CMD HD.

Könntest du in einer der nächsten Versionen die LW-Icons für TD mit anpassen??
(wenigstens ein N ins Symbol)
das einzige was bis jetzt stimmt ist das Symbol der Ram.........

Zitat von darkvision

Die Icons kommen nicht von MegaPatch sondern vom TopDesk. Ich fürchte da kann ich nix machen. Liegt daran das TopDesk die neuen Laufwerkstypen nicht kennt und dann eben das 81-Symbol verwendet.

Wie heißen die denn?

Pusti64