Hello,
ich muss gestehen, dass ich in den letzten Monaten fast nur noch mit GDos gewerkelt habe. Meistens mit WinVice. Wenn es nur ein Anzeigefehler ist, hat das Update doch noch Zeit.
Meine Meinung.![]()
Liebe Grüße,
Jojo
Es gibt 1.222 Antworten in diesem Thema, welches 218.464 mal aufgerufen wurde. Der letzte Beitrag (
Hello,
ich muss gestehen, dass ich in den letzten Monaten fast nur noch mit GDos gewerkelt habe. Meistens mit WinVice. Wenn es nur ein Anzeigefehler ist, hat das Update doch noch Zeit.
Meine Meinung.![]()
Liebe Grüße,
Jojo
Wenn es nur ein Anzeigefehler ist, hat das Update doch noch Zeit.
Das Problem ist das ich das dann wahrscheinlich irgendwann gar nicht mehr aktualisiere weil ich die Änderung dann schon wieder vergessen hab ![]()
Ich hab jetzt den ganzen Tag damit verbracht die Builds für den SnapShot und das Testing-Release neu zu erstellen und alle Versionen unter VICE neu zu installieren und die Korrekturen zu testen. Die 64er-Versionen hab ich auch an realer Hardware installiert und mit CMD-FD/HD getestet. Scheint alles wie gewohnt zu funktionieren.
Mir ist dabei noch ein Fehler in MP128 aufgefallen, die Version verschluckt an einer Stelle eine führende 0 bei der Ausgabe von Datumsangaben. Auf dem Screenshot unten (Version 30.05.23) müsste das Datum 06.01... heißen, angezeigt wird unter MP128 aber nur 6.01. Unter MP3-64 ist das kein Problem. Da scheint also noch ein Unterschied in der Routine SmallPutChar zwischen 64 und 128 zu bestehen, denn der Fehler tritt unter MP128 auch im 40Z-Modus auf.
Bitte melde dich an, um diesen Anhang zu sehen.
Mit einer kleinen Ändereung funktioniert es jetzt unter VICE/MP128.
Download von 3.3r10-231020 Bitte melde dich an, um diesen Link zu sehen.. (Achtung! Die Version mit "-kdrv" im Dateinamen ist die Testversion mit den Kernal-Treibern ohne das GEOS/TurboDOS... die Version will im Normalfall keiner nutzen
)
Download von 3.3r10-231020 hier.
Nachdem ich am echten C128 DCR alle Test-Installationen vom neuen MP3-Snapshot (64 + 128) und unter WinVICE einige aktualisiert habe, kann ich berichten: Bisher keinerlei Probleme entdeckt. Klasse! Danke.
Etwas anderes: Wäre es möglich, auf "bitbucket" wieder so etwas wie ein ChangeLog einzurichten? OK, bisher gibt es solche Informationen hier im Forum. Aber es soll auch Leute von außerhalb geben, die hier eben nicht hier lesen. Nur so als Vorschlag
...
Gruß
Werner
Hat hier schonmal jemand unter MP128 die RAMLink (am echten C128) mit einer DACC-Partition als GEOS-DACC verwendet? Also ohne REU/GeoRAM?
Ich hab heute mit RAMLink128 unter einem aktuellen VICE getestet und ich vermute das stürzt bei realer Hardware genauso ab wie unter VICE. Es könnte aber auch an VICE liegen, leider startet bei mir VICE nicht mit REU+RAMLink damit ich zum Vergleich die REU als DACC hernehmen könnte.
Am C64 geht das Problemlos, da liegt ab $C000-$CFFF ja nur RAM wenn man das Kernal-ROM für den Speichertransfer einschaltet. Beim C128 wird aber wohl ab $C000 der Screen-Editor aus dem ROM eingeblendet. Da hier aber auch die Speicherroutinen liegen wird vermutl. nach dem umschalten mit lda $4e/sta $ff00 das ROM eingeblendet -> Absturz.
Da müsste ich einiges an der Speicheraufteilung ändern falls das am realen C128 auch nicht funktioniert.
Beim C128 wird aber wohl ab $C000 der Screen-Editor aus dem ROM eingeblendet.
Gerade im gedruckten Originalhandbuch des C128 nachgeschaut: Die MMU kann tatsächlich den Bereich $C000-$FFFF nur als Ganzes Mappen, also entweder ROM, RAM1, RAM2, Cartridge.
Ausnahme: I/O Bereich - der kann entweder dem Rest des $C000-$FFFF Bereiches folgen oder I/O beinhalten. Wenn man ROM, aber keinen I/O einblendet, bekommt man im I/O Bereich das Zeichensatzrom.
Hallo Markus,
Hat hier schonmal jemand unter MP128 die RAMLink (am echten C128) mit einer DACC-Partition als GEOS-DACC verwendet? Also ohne REU/GeoRAM?
Habe ich am realen System noch nie probiert. Ramlink 16MB und REU habe ich schon immer zusammen genutzt. Die RL mit dem Programm "rl/rd geos setup/512k dacc + 1581partitioniert. Danach die weiteren Partitionen mit Ramtools angelegt. Habe inmer vermutet, dass die REU512KB intern in das DACC gleicher Größe integriert wird und das DACC+REU als je 512KB von MP3 Geos128 angezeigt wird, aber deshalb nur die Auswahl REU512KB zum Starten funktioniert.
Wie gesagt, reine Vermutung, aber habe ich mir einfach so zusammengereimt.![]()
Ich hab heute mit RAMLink128 unter einem aktuellen VICE getestet und ich vermute das stürzt bei realer Hardware genauso ab wie unter VICE. Es könnte aber auch an VICE liegen, leider startet bei mir VICE nicht mit REU+RAMLink damit ich zum Vergleich die REU als DACC hernehmen könnte.
Bei mir läuft im WinVice128 64bit x128 r44603 mit Ramlink128 + REU512KB mit folgenden Einstellungen zusammen (Bilder). Andere habe ich noch nicht probiert, da ich ja versuche mein Realsystem hier abzubilden. Mit der Starteinstellung REU512KB lässt sich MP3 Geos128 starten.
Liebe Grüße,
Jojo
Ich hab eben MegaPatch v3.3r11 Bitte melde dich an, um diesen Link zu sehen.. (Hinweis: 3.3r11-dev-kdv ist die Testversion mit den langsamen KernalMode-Treibern...)
Wer das am realen System oder unter VICE auf CMD-RAMLink installieren will, der sollte zuerst mit REU oder GeoRAM installieren, danach kann man auch auf einer CMD-RAMLink mit RAMLink-Partition als GEOS-DACC installieren. Grund für den Umweg ist der Fehler in 3.3r10 (siehe Bitte melde dich an, um diesen Link zu sehen..084).
Ich hab alle 8 Versionen (de/en, 64/128 und std/kdv) unter VICE installiert und zusätzlich VICE nochmals auf 3.8 aktualisiert und die Installation auf der RAMLink (mit Partition als GEOS-DACC) eingerichtet, so dass man von der RAMLink booten kann. Alle Installationen liefen problemlos durch... Der Fehler steckt aber oft im Detail ![]()
Unter MP64 wurde eigentlich nur ein Fehler in der Dateiauswahlbox beseitigt (Anzeige freie Blocks auch wenn keine Diskette im Laufwerk). Gleiches gilt für MP128 mit dem zusätzlichen Fix für DoBOp und dem RAMLink-Treiber.
Muss ich gleich mal updaten. Und vorher am PC die von der SD-Karte Imagedatei sichern.
3.3r11-dev-kdv ist die Testversion mit den langsamen KernalMode-Treibern...
Die Version bekommt seit ein paar Tagen bei mir gesteigertes Interesse. Ich weiß nicht, ob sich die Nachricht schon verbreitet hat, aber ich arbeite derzeit an einem POC, der das IEC Laufwerk der Ultimate kompatibler machen soll... Wohlbemerkt nur POC, damit man anschließend aus Erfahrung weiß, worauf es ankommt. Wenn ich eine D81 als Root setze, so sollte das Device sich etwas 1581 ähnlich verhalten (sprich: U1 und U2 funktioneiren wie bei einer 1581). Analoges gilt für D64, D71 und DNP.
Tja, was liegt mit den Treibern näher, als der Versuch, MP3 mal von dem Laufwerk zu booten. Geht aber nur zum Teil. Klappt auch zum nicht vernachlässigbaren Teil. Er kommt immerhin über das geladene Hintergrundbild hinaus an die Stelle, wo er sich über fehlerhafte Devicekonfiguration beschwert. Die Prüfung, ob das Gerät wirklich eine 1581 ist, bekommt er nicht durch... ist ja auch klar, ist ja auch keine 1581.
Wozu ist die Version mit Kernaltreibern genau da? Ich dachte bisher immer, die wäre für Geräte, die sich zwar ähnlich einer normalen Floppy verhalten, aber eben nicht so gleich, dass die beschleunigten Treiber es nicht tun... Jetzt haben wir ein Gerät, was sich ähnlich verhält, aber es nicht mit Kernaltreibern so ganz tut.
Ich habe folgende Kommandos geloggt, die ich für die Geräteidentifikation verantwortlich mache:
0000: 4D 2D 52 A0 FE 20 M-R ~
0000: 4D 2D 52 80 E5 20 M-R.e
0000: 4D 2D 52 A0 E5 20 M-R e
0000: 4D 2D 52 C0 E5 20 M-R@e
0000: 4D 2D 52 E0 E5 20 M-R`e
0000: 4D 2D 52 00 E6 20 M-R.f
0000: 4D 2D 52 20 E6 20 M-R f
0000: 4D 2D 52 40 E6 20 M-R@f
0000: 4D 2D 52 60 E6 20 M-R`f
0000: 4D 2D 52 C0 A6 20 M-R@&
0000: 4D 2D 52 E0 A6 20 M-R`&
0000: 4D 2D 52 00 A7 20 M-R.'
0000: 4D 2D 52 20 A7 20 M-R '
0000: 4D 2D 52 40 A7 20 M-R@'
0000: 4D 2D 52 60 A7 20 M-R`'
0000: 4D 2D 52 80 A7 20 M-R.'
0000: 4D 2D 52 A0 A7 20 M-R '
0000: 4D 2D 52 00 FE 20 M-R.~
Natürlich, eine nicht besonders nützliche Spielerei... anderseits aber auch eine gute Möglichkeit, die Kompatibilität des IEC Devices der Ultimate zu testen.
PS: Ich kann wunderbar im Log sehen, wie MP3 Dateien geladen hat, viele Befehle der Form
0000: 55 31 20 35 20 30 20 30 32 39 20 30 30 35 U1 5 0 029 005
natürlich mit wechselnden Track- und Sektornummern. Also im Prinzip geht diese Kombination.
Edit: Im Hyperspeedkernal/Hyperspeedfirmwarecode ist noch ein unbekannter Bug drin. Wenn der mal beseitige ist und die Befehle nicht mehr über den IEC Bus müssen, weil eben der Hyperspeedkernal greift, dann könnte das sogar brauchbar schnell sein. ![]()
Wozu ist die Version mit Kernaltreibern genau da?
Es gab mal Berichte über ein exotisches SD2IEC das zwar D81 laden konnte, aber das GEOS-TurboDOS nicht unterstützt hat. Ist Jahre her, wurde wohl nie auf dem SD2IEC getestet bzw. ich hab da keine Rückmeldung dazu erhalten. Die Treiber nutzen kein TurboDOS, nur Standard-Floppy-Befehle. Heute ist das eher Proof-of-Concept, ein SD2IEC das kein TurboDOS unterstützt ist aus meiner Sicht fehlerhaft. Hab heute DE/EN/64/128 mit den Treibern installiert... ohne Probleme, langsam, aber es geht.
Jetzt haben wir ein Gerät, was sich ähnlich verhält, aber es nicht mit Kernaltreibern so ganz tut.
Nunja... ähnlich ist nicht gleich... MP3 testet die Laufwerke, mit ROM-Codes... das sind Deine geloggten Kommandos oben ... kein ROM-Code erkannt... unbekanntes Laufwerk. Ausnahme SD2IEC.
Die Treiber nutzen kein TurboDOS, nur Standard-Floppy-Befehle.
Eben drum, deswegen sollten die mit einem anderen Gerät ganz brauchbar wollen... Sehe aber ein, dass
ähnlich ist nicht gleich
Stimmt, aber ein SD2IEC verhält sich auch nicht gleich zu einer 1581. Kann zum Beispiel kein Code in der FLoppy ausführen, außer ein paar vorher bestimmte Codes, die erkannt werden.
Hab heute DE/EN/64/128 mit den Treibern installiert... ohne Probleme, langsam, aber es geht.
Stimmt, von emulierter 1581 kann ich jene zweitneuste Version auch auf der Ultimate starten... Klar, ich könnte jetzt mit einer ROM Emulation nachhelfen versuchen, aber das lohnt sich eher für eine CMD HD Erkennung. Dann könnte man nämlich direkt mehrere Partitionen nutzen und hätte somit fast alles, was man braucht... Auch nur als POC, aber immerhin. Obwohl, Gideon plant mit bis zu 254 Partitionen, damit sollte man mehr machen können als mit den klassischen Geräten (SD2IEC, 1581, 1571, 1541).
Stimmt, aber ein SD2IEC verhält sich auch nicht gleich zu einer 1581. Kann zum Beispiel kein Code in der FLoppy ausführen, außer ein paar vorher bestimmte Codes, die erkannt werden.
Daher wird auch auf ein SD2IEC getestet... nachdem alle ROM-Codes abgefragt wurden. Dazu wird eine Rückmeldung ausgewertet und wenn korrekt -> SD2IEC, sonst eben kein Laufwerk. Daher funktioniert das zwischenzeitlich auch ohne M-R-Emulation (bis da ggf. was an der Firmware verändert wird).
Daher funktioniert das zwischenzeitlich auch ohne M-R-Emulation (bis da ggf. was an der Firmware verändert wird).
Wenn da so was gemacht wird an der Firmware, muss man ja nicht mitgehen. Das beträfe dann ja relativ wahrscheinlich auch die Version mit Turbodos.
Na gut, SD2IEC kann ich nicht faken - dann müsste ich ja per "CD" ins Image wechseln und per "CD←" rauswechseln implementieren. Was nicht zum gewählten Ansatz passt, sich eher wie eine CMD HD zu verhalten. Aber ohne Codeausfühtung, weil es eben keine CMD HD ist.
Macht nichts, da er bis zu der kritischen Stelle kommt, kann man den Test bzgl. Kompatibilität auch als bestanden werten... Und echt mal prüfen, ob eine Erkennung als CMD HD Sinn macht... Die hat ja Partitionen für die wichtigen Imagetypen.
Daher wird auch auf ein SD2IEC getestet...
In der Tat, der letzte M-R sieht für einen Insider danach aus.
In der Tat, der letzte M-R sieht für einen Insider danach aus.
Insider? Muss man dazu nicht sein, steht ja im Klartext im SourceCode und der ist öffentlich. Aber ja, der letzte MR ist der SD2IEC Test...
Macht nichts, da er bis zu der kritischen Stelle kommt, kann man den Test bzgl. Kompatibilität auch als bestanden werten...
Ja, denn der Boot-Treiber ist da ja schon aktiv und lädt Dateien...
Ich hab eben MegaPatch v3.3r11 hochgeladen.
kurze Frage bitte:
wenn ich vorher noch nie ein MegaPatch installiert habe, kann ich dann gleich diese letzte Version nehmen oder muß das Schritt für Schritt gemacht werden?
Danke.
kann ich dann gleich diese letzte Version nehmen
kurze Antwort: Ja ![]()
Etwas längere Antwort:
Geos starten, die 6 Installationsdateien in RAM kopieren, eine leere Disk als neue MP3-Bootdisk erstellen, Installation starten und Ausgaben beachten! Wenn Installation fertig einen DESKTOP auf die neue Bootdisk kopieren und dann Rechner neu starten und MP3-Booten.
Hinweis1: die MP3-Bootdisk sollte mindestens 1571 oder größer sein und dann komplette Installation wählen. Ist erstmal einfacher.
Hinweis2: Während der Installation niemals auf Abbruch klicken, immer OK oder Weiter. Am Ende gibt es nur ein OK als Ausstieg.
Gruß
Werner
Ja, kannst du.
Alles was du brauchst ist
-ein Funktionierendes Geos, 2.x
-wenigstens 2 Laufwerke, am besten 1581 (SD2iec funktioniert Super damit) und, ganz wichtig Vorraussetzung ist eine Ram/Reu ab 512KB
(mehr ist besser).............ohne Ram/Reu gehts NICHT !!!
und schon kanns Losgehen..........
Geos booten, und dann MP3 installieren
(Achtung, leere Disk verwenden !!)
Am besten, das Setup auf die Ram/Reu kopieren und dann starten.................
Werner war schneller...............
danke für die schnelle Antwort ....
Ich hab eben MegaPatch v3.3r11 Bitte melde dich an, um diesen Link zu sehen.. (Hinweis: 3.3r11-dev-kdv ist die Testversion mit den langsamen KernalMode-Treibern...)
Wer das am realen System oder unter VICE auf CMD-RAMLink installieren will, der sollte zuerst mit REU oder GeoRAM installieren, danach kann man auch auf einer CMD-RAMLink mit RAMLink-Partition als GEOS-DACC installieren. Grund für den Umweg ist der Fehler in 3.3r10 (siehe Bitte melde dich an, um diesen Link zu sehen..084).
Ich hab alle 8 Versionen (de/en, 64/128 und std/kdv) unter VICE installiert und zusätzlich VICE nochmals auf 3.8 aktualisiert und die Installation auf der RAMLink (mit Partition als GEOS-DACC) eingerichtet, so dass man von der RAMLink booten kann. Alle Installationen liefen problemlos durch... Der Fehler steckt aber oft im Detail
Unter MP64 wurde eigentlich nur ein Fehler in der Dateiauswahlbox beseitigt (Anzeige freie Blocks auch wenn keine Diskette im Laufwerk). Gleiches gilt für MP128 mit dem zusätzlichen Fix für DoBOp und dem RAMLink-Treiber.
Guten Morgen! Am 24.01. wurde eine neue Version des Mega-Patches hochgeladen. Bitte ist irgendwo changelog verfügbar? (Z. B. Fehler in der Dateiauswahlbox ist jetzt behoben?) Danke ![]()
Guten Morgen! Am 24.01. wurde eine neue Version des Mega-Patches hochgeladen. Bitte ist irgendwo changelog verfügbar? (Z. B. Fehler in der Dateiauswahlbox ist jetzt behoben?) Danke
Schonmal das README auf der SETUP-Diskette gelesen? ![]()
-> BEHOBENE PROBLEME IN DEN TESTVERSIONEN 2018-2024
Zitat- MegaPatch128 zeigt beim Startvorgang bei der Auswahl einer RAMLink-Partition für den GEOS-DACC ein fehlerhaftes Menü an, wenn mehrere DACC-Partitionen verfügbar sind.
( Ich hoffe mal ich hab das README auf allen Disketten aktualisiert
)
Guten Abend,
MP3 64 v. 26.01.24
WinVice 3.8/32+64bit xscpu64-r44967
LW 08=CMDHD 1581er (jeweils MP3 64 Start HD)
LW 09=CMDRL 1581er (jeweils MP3 64 Start HD)
LW 10=CMDFD2 1581er (MP3 64 Updater)
MP3 128 mit x128 gleiche Prozedur........
Auch im Realsystem fast gleiche Konfiguration.
Ausnahme: LW10 = Real SD2IEC statt FD2
Installation hat überall wunderbar geklappt. SUPER.......![]()
Liebe Grüße,
Jojo