Hallo Besucher, der Thread wurde 36k mal aufgerufen und enthält 195 Antworten

letzter Beitrag von C=Mac am

MP3 Patch und Laufwerksverwaltung

    Zitat von wweicht

    Ich will "nur" den Aufruf von TD-Com in TopDesk integrieren. Dazu wird wohl der Menüpunkt "Speziell" -"Hilfe aufrufen" geopfert. Man muss dann das Programm "TD-Com" auf einem der bis zu 4 möglichen Laufwerke verfügbar haben (ähnlich wie bei der Hilfe) und es wird dann gestartet. Das ist relativ einfach.


    Aber das gehe ich erst an, wenn TD-Com das kann, was ich eigentlich will. Ist also Zukunftsmusik. Keine Ahnung wann ich dazu komme .... .

    Was da gibt es eine "Hilfe"-Funktion, hab ich noch nie beachtet ^^


    Sicherlich wäre es schöner, wenn das Erstellen von Verzeichnisse ein eigener Menüpunkt wäre, ähnlich den TD-Ordner.
    Aber der Programmieraufwand wäre sicherlich unverhältnismässig.


    Auf die Art und Weise ist es immer noch wesentlich besser als zu erst GeoDos zu starten um schnell ein Native-Verzeichnisse zu erzeugen.
    Wäre es möglich die TD-Com so zu gestallten das sie beim booten mit in die REU kopieren wird, gleich wie der RAM-TopDesk?


    Aber wie Du gesagt hast, ist alles Zukunftsmusik ;)



    Zitat von wweicht

    Meine Routine, die beim "Validate" im Topdesk unter MP3 den Boot-Sektor prüft, werde ich entsprechend anpassen.

    Wirst Du die Routine auch für den TopDesk 64 anpassen?
    Dort tritt der gleiche Effekt wie bei der 128-Version auf.



    Zitat von Pusti64

    Könnte mich mal jemand über Td-Com aufklären. Ich glaube da habe ich was verpasst?

    Mit dem Programm TD-Com 64/128 ist es möglich Native-Mode-Verzeichnisse zu erstellen.
    MP3 kann dies nicht selber, es sind nur TopDesk-Ordner möglich.


    Gruss C=Mac.

    Hallo C=Mac und Pusti64,

    Zitat von C=Mac

    Sicherlich wäre es schöner, wenn das Erstellen von Verzeichnisse ein eigener Menüpunkt wäre, ähnlich den TD-Ordner.

    Ja sicher, aber das stellt mich vor größere Probleme ;-) .
    TD-Com soll ja noch die eine oder andere weitere Funktion bekommen. Es wird also definitiv noch Größer. Für diese Funktionen müßte dann auch ein neuer Menü-Punkt her. Irgendwann wird der Topdesk zu groß und er passt nicht mehr in den Speicher des Rechners. Deshalb ein externes Programm, das alle Funktionen anbietet und nur über einen Menüpunkt des Topdesk gestartet wird. Im wesentlichen werden das Funktionen für CMD-Native-Mode-Laufwerke sein. Es könnte also sein, dass ich das Programm auch nochmal umbenenne ....


    Zitat von C=Mac

    Wäre es möglich die TD-Com so zu gestallten das sie beim booten mit in die REU kopieren wird, gleich wie der RAM-TopDesk

    RAM-Topdesk ist eine Funktion des TopDesk. Hier wird eine RAM-Bank benutzt, ihn zu speichern. Auch das Kernel von MP3 muss darüber bescheid wissen und entscheiden können: lade ich den Topdesk von einem Laufwerk oder aus einer bestimmten RAM-Bank. Der Aufwand wäre zu groß, das für andere Programme zu realisieren.


    Aber es gibt eine Lösung, zu der man "nur" ein RAM-Laufwerk benötigt. Ich benutze die seit Jahrzehnten: BootTrans .
    Das Programm ist in der GUC-Geothek (auf der F64-Wolke zu finden; einer der beiden "The Best of GUSS"-Disketten) vorhanden.


    Damit wird beim Booten automatisch eine Liste von Programmen in das RAM-Laufwerk kopiert. Man kann auch während des Bootens eine bestimmte Liste auswählen. Das Ganze funktioniert auch von einem anderen Laufwerk als das Boot-Laufwerk. Ich z.B. boote normalerweise von A: (CMD-FD). Während des Bootens wähle ich dann ein bestimmtes D81 auf meinem uIEC (SD2IEC) aus und das Programm kopiert dann die Dateien von D: (uIEC, früher 64NET) nach B: (RAM-Disk).


    Wenn das Booten abgeschlossen ist, kann ich gleich loslegen....



    Zitat von C=Mac

    Wirst Du die Routine auch für den TopDesk 64 anpassen?
    Dort tritt der gleiche Effekt wie bei der 128-Version auf.

    Ja, ich weiß. Das offizielle Topdesk-Patch für MP3 habe ich 2010 erstellt. Danals habe ich mir gedacht, baue die Bootsektor-Prüfung auch bei er 64er Version ein, es könnte ja jemand eine 128er Bootdiskette unter MP3-64 validieren wollen....


    Eigentlich Schwachsinn ;-) . Aber man weiss ja nie .........


    Jetzt überlege ich, ob ich das wieder rausnehme oder doch drin lasse und anpasse wie bei der 128er Version. Ändern muß ich das TD-64-Patch auf jeden Fall, damit da auch die Datum-Änderung rein kommt.
    Das mache ich, sobald die 128er Version fertig ist und funktioniert.




    Zitat von Pusti64

    Könnte mich mal jemand über Td-Com aufklären. Ich glaube da habe ich was verpasst?

    TD-Com ist von mir. Ich schraube da schon längere Zeit dran rum und überlege was es können soll. Momentan kann es nur Native-Mode Unterverzeichnisse erstellen und löschen. Geplant ist z.B. das Validate des CMD-DOS auf Native-Laufwerken möglich zu machen (dürfte schneller sein als das von Topdesk)
    und eine Art "SystemDirectory" wie in Wheels auf Native-Laufwerken in abgespeckter Form (max. 8 Dateien).



    Zitat von Pusti64

    In welchem Datensatz und Adresse von 128Desktop ist denn der Fehler zu finden?

    Der Fehler tritt nur mit dem Topdesk-Patch von mir aus 2010 auf. Da habe ich die Validate-Funktion von geoDOS übernommen und zusätzlich eine Routine eingefügt, die eventuell vorhandene Boot-Sektoren nach dem Validate in der BAM wieder als belegt kennzeichnet. Diese Routine baut Mist, wenn der Boot-Sektor trotz vorherigen Validate immer noch in der BAM als belegt gekennzeichnet ist.


    Es ist der 2. Datensatz am Ende ;-)


    Gruß
    Werner


    PS: TD-Com soll Topdesk-Komandos bedeuten. ;-)

    @wweicht


    Besten Dank für Deine Erklärungen.



    Zitat von wweicht

    Der Aufwand wäre zu groß, das für andere Programme zu realisieren.

    Immer diese Leute, die denken:
    Ach das geht ganz einfach, so schnell schnell nebenbei ;)


    Man sieht als Anwender halt nicht, welcher Aufwand im Hintergrund getrieben werden muss, um nur eine "kleine" Änderung zu realisieren.







    Zitat von wweicht

    es könnte ja jemand eine 128er Bootdiskette unter MP3-64 validieren wollen....


    Eigentlich Schwachsinn . Aber man weiss ja nie .........

    Es könnt ja einer wie ich auftauchen :rolleyes:
    Hab das aber nur aus reiner Neugier getestet, da ja wirklich sinnlos.







    Zitat von wweicht

    PS: TD-Com soll Topdesk-Komandos bedeuten.

    Somit wäre das auch geklärt :thumbup:




    Und wieder was neues aus der Abteilung "Sinnloses Ausprobieren".


    Beim meinem C64-System hab ich die Möglichkeit verschiedener DACC-Partition.
    Einerseits die RamCard der SCPU64 und andererseits eine DACC-Partition auf der RamLink.


    Boote ich MP3 64 von der HD und wähle die RamCard aus, hängt sich MP3 auf (wird nur bis zum Hintergrundbild gebootet).
    Wenn ich die RamLink auswähle, gibt es keine Probleme.


    Boote ich von der RamLink oder FD ist es egal, es funktioniert mit beiden.


    Hab noch nicht rausgefunden woran dies liegt. Ist auch nicht wirklich relevant.


    Gruss C=Mac.

    Zitat von Pusti64

    an welche Adresse muss ich diesen 2.Datensatz disassemblieren?

    Kann ich Dir echt nicht sagen. Ich habe das Ganze ausgehend von dem "alten" Patch-Programm von 2010 analysiert. Dissassembliere den TD einfach an irgendeine Adresse. Gehe dann auf die letzte Seite und lies rückwärts (das ganze läuft ohne hin- und herspringerei irgendwo hin ab). Die Problem-Routine beginnt mit:


    2047C2 jsr GetDirHead
    A901 lda #1
    8504 sta r1L
    A900 lda #0
    8505 sta r1H
    A900 lda #0


    ....


    und endet mit:



    D0B2 bne ...
    4C4AC2 jmp PutDirHead



    Ist ca. 1 GeoWrite-Seite und gilt nur für Topdesk 128 für MP3 vom November 2003, der mit meinem Topdesk-Patch von 2010 gepatchtt wurde.


    Gruß
    Werner


    PS. Die Lösung kenne ich schon ;-)

    Hallo C=Mac,

    Zitat von C=Mac

    Validate läuft Kommentarlos durch, egal ob die Disk einen Boot-Sektor hat oder nicht.

    ich habe jetzt den Topdesk 128 für MP3-128 nochmal (mit einem Diskmonitor) geändert. Jetzt sollte die Validate-Funktion in allen Fällen (auch diese seltsamen 1581-Subpartitionen) funktionieren. Hänge ich hier mal als D64 an.


    Zitat von C=Mac

    Beim meinem C64-System hab ich die Möglichkeit verschiedener DACC-Partition.
    Einerseits die RamCard der SCPU64 und andererseits eine DACC-Partition auf der RamLink.

    Hier kann ich leider nicht helfen :-( . Habe keine RamLink.
    Laut Anleitung zu MP3 soll man beide DACC-Partitionen auch zusammen nutzen können ....


    Da müssen Leute ran, die sich mit RAMLink auskennen ....


    Gruß
    Werner

    Zitat von wweicht

    ich habe jetzt den Topdesk 128 für MP3-128 nochmal (mit einem Diskmonitor) geändert. Jetzt sollte die Validate-Funktion in allen Fällen (auch diese seltsamen 1581-Subpartitionen) funktionieren. Hänge ich hier mal als D64 an.

    Danke für Deine Bemühungen. :thumbup:
    Hab zwar noch nie eine 1581-Subpartition verwendet, aber man weiss ja nie. ;)



    Zitat von wweicht

    Hier kann ich leider nicht helfen . Habe keine RamLink.
    Laut Anleitung zu MP3 soll man beide DACC-Partitionen auch zusammen nutzen können ....

    Es ging auch eher darum, dass wenn ich MP3 64 von der CMD-HD boote und eine RamCard (SCPU) als DACC auswähle, MP3 sich aufhängt.
    Während es mit der RL-DACC keine Probleme gibt.


    Wie gesagt nicht weiter tragisch, ich weiss es ja jetzt ;)


    Gruss C=Mac.

    Zitat von C=Mac

    Hab zwar noch nie eine 1581-Subpartition verwendet, aber man weiss ja nie.

    Ich bis die Tage auch nicht ;-) , da ich wusste, sie werden von Geos nicht unterstützt.


    Sie bringen auch nichts, da sie nur Speicherplatz belegen, der unter Geos auf der Diskette nicht zur Verfügung steht. Hier sind jetzt Partitionen gemeint, die groß genug sind, um Dateien aufnehmen zu können (siehe meine Vor-Postings dazu hier im Thema).


    Einzige "sinnvolle" Anwendung (für Geos128/MP3-128/Wheels 128): Eine Partition mit Größe von 1-2 Blöcken ab Track 1 Sektor 0. Und da anschließend den Boot-Sektor erstellen. So ist der Boot-Sektor sicher geschützt. Aber Wheels bringt dann beim "Aufräumen" eine Fehlermeldung ....
    Und nein, spezielle Patches für Wheels mache ich nicht! :bgdev


    Gruß
    Werner

    Zitat von wweicht

    Das tangiert mich erstmal überhaupt nicht ;-)

    Oh doch. :D
    Tut mir leid dass ich erst jetzt antworte, aber ich bin erst heute zum Testen gekommen (wollte mich nicht aufs Gedächtnis verlassen).

    Zitat von wweicht

    Die Routine, die die BAM des Boot-Sektors (Track 1 Sektor 0) manipuliert, wird automatisch immer nur nach einem Validate ausgeführt. Damit ist sichergestellt, dass ein eventuell vorhandener Boot-Sektor definitiv in der BAM als frei gekennzeichnet ist.
    Laut dem Büchern: "Die Floppy 1570/1571" und "Die Floppy 1541" von Karsten Schramm (Ausgabe von Spiro Trikaliotis, 26. April 2006; als PDF) tritt das Problem nur auf, wenn der Bootsektor als belegt in der BAM gekennzeichnet ist ....

    Gerade getestet:
    1. Man nehme eine frisch geplättete Disk mit 664 freien Blöcken.
    2. Einmal OPEN 1, 8, 15, "B-A 0 1 0":CLOSE 1 eingeben, um T1S0 zu belegen.
    3. Verzeichnis laden, man sieht 663 freie Blöcke. Ok, schön.
    Aber:
    4. Einmal die Disk aus dem Laufwerk nehmen und wieder einlegen, dann:
    5. Verzeichnis laden, nun sieht man 643 freie Blöcke. Die BAM im Drive-RAM war also korrekt, aber die auf der Disk ist falsch. Alle 21 Blöcke von Spur 1 wurden belegt.


    Hat man einen "#"-Kanal offen, passiert das nicht (beim Schließen dieses Kanals wird die BAM gespeichert). Der Fehler ist auch in der 1571 vorhanden und tritt auch bei Verwendung von JiffyDOS noch auf!
    Es gab mal eine Erklärung in comp.sys.cbm, wonach das gar kein Bug ist, denn ohne offenen "#"-Kanal wäre es eher ein Benutzerfehler, aber da das nicht explizit im Handbuch steht, sehe ich das anders... ;)


    EDIT: Das sollte für Deinen Algorithmus aber kein Problem sein, denn zum Erkennen eines Bootsektors wirst Du ja vermutlich einen "#"-Kanal und den "U1"-Befehl benutzen. Du musst nur darauf achten, erst den "B-A"-Befehl abzusetzen und dann den "#"-Kanal zu schließen und nicht anders herum.

    Zitat von C=Mac

    Warum denn nicht? Dies ist doch eminent wichtig. :D
    Ne, Quatsch.

    Das hat Gründe. Ich mochte Wheels noch nie so richtig. Irgendwie sieht die Oberfläche "altbacken" aus. Ich kann die Laufwerksfenster frei verschieben und wohl 16 Fenster öffnen. Wer braucht das? Und wer hat da dann noch die Übersicht, was in welchem Fenster gerade geöffnet ist?
    Ich habe das hier schonmal irgendwo geschrieben, ich besitze das originale Wheels 128 nur, weil damals ein amerikanischer Geos-Klub bei mir angefragt hatte, wie sie denn die Shareware-Gebühr für einige meiner Disketten/Programme begleichen könnten (ja, ich habe damals mehr Dollar bekommen als DM) . Ich bot ihnen an, sie bestellen und bezahlen bei M. Randall eine Diskette "Wheels 128" und lassen sie an meine Adresse schicken. Im Gegenzug sind alle Shareware-Gebühren auch in der Zukunft für alle meine "Machwerke" für alle ihre Klub-Mitglieder beglichen. Ein paar Wochen später trudelte hier Wheels 128 von M. Ranall ein. Ohne diesen Umstand hätte ich Wheels nie besessen....


    Und ein Umstand hat mich besonders geärgert: Wheels läßt keine externen Treiber zu. Ich hatte damals schon fast alles als D64/D71/D81 auf PC liegen und über 64NETV1 Zugriff darauf unter Geos und MP3. Nur Wheels wollte 64NET nicht unterstützen. Nachzulesen ist das hier: http://geos-printarchiv.de/arc…einer-etwas-anderen-sicht


    Danach habe ich mir vorgenommen, speziell für Wheels wird nicht programmiert. Das habe ich bis heute bis auf eine kleine Ausnahme (der Programmierer von geoZIP für Wheels bat mich mal eine kleine Änderung in seinem Code vorzunehmen und eine neue Version für Wheels zu bauen, er käme nicht dazu). Da er aber die Lösung gleich mitgeliefert hat, zählt das nicht ;-) .


    Gruß
    Werner

    Zitat von Mac Bacon

    Oh doch.
    Tut mir leid dass ich erst jetzt antworte, aber ich bin erst heute zum Testen gekommen (wollte mich nicht aufs Gedächtnis verlassen).

    Auch bei mir wird die Antwort wohl etwas dauern. Muss nochmal etwas dazu nachlesen und dann auch mal auf meinem C128DB mit 1571 die Sache ausprobieren.


    Gruß
    Werner

    @wweicht
    Danke für die Erklärungen.


    MP3 und Wheels sind schon recht unterschiedlich, beide haben ihre Vor-/Nachteile (nicht nur in der Optik) und fehlerfrei ist leider keins.


    Danke für den Link, hab ein paar Interessante Sachen gefunden :thumbup:


    Unteranderem dieses:


    Zitat von W. Weicht

    Abschließend möchte ich noch darauf hinweisen, daß bereits an einer Übersetzung des Wheels-Handbuches ins Deutsche gearbeitet wird. Es soll voraussichtlich im Herbst fertig werden. Wenn diese Übersetzung verfügbar ist, werde ich natürlich darüber berichten.

    Wurde das jemals beendet?


    Ne deutsche Anleitung wäre schon noch was.




    Andere Frage:


    Ich überleg mir, neben der U2+, noch ein SD2IEC zu zulegen.


    Für das SD2IEC gibt es ja Treiber von Dir, welche unter MP3 laufen.


    Meine Frage:
    Ist auch das Booten von MP3 64/128 vom SD2IEC möglich?
    Oder wird das SD2IEC einfach als Arbeits-/Speicherlaufwerk eingebunden? (Es wäre immerhin die D64-Limitierung der U2+ weg).


    Gruss C=Mac.

    Hallo C=Mac,

    Zitat von C=Mac

    Wurde das jemals beendet?

    Ja. Es gab da aber ein Problem:
    Der Übersetzer (Spitzname: DonAlt, er war einfacher GEOS, MP3, Wheels Anwender) wollte vor einer offiziellen Veröffentlichung die Erlaubnis von M.Randall haben das einfach so verbreiten zu dürfen. Er schickte sogar ein Exemplar direkt an M. Randall. Da kam soweit ich weiß aber nie eine Antwort. Das war so Ende 1999 Anfang 2000.


    Die deutsche Anleitung gab es nur in gedruckter Form. Es waren keine Kopieen, sie wurde jedesmal neu gedruckt. Gedruckt wurde mit ESC/P2-Druckertreiber und PrintText (von Ro(nn)y Bachmann) aus Geowrite 128 heraus in Farbe (ja auch das war/ist möglich, hatten wir noch garnicht im Thema "PC-Drucker" hier; PrintText ist z.B. in der F64-Wolke und hier im Thema "originale GEOS-Applikationen jungfräulich" vorhanden) gedruckt. Sieht sehr gut aus, Top Qualität! Außerdem war jeder Ausdruck personalisiert. Man mußte bei einer Bestellung seine Wheels-Seriennummer angeben und diese wurde auf jeder Seite mit ausgedruckt. Damit sollte Copyright-Problemen aus dem Wege gegangen werden. Wenn doppelte Seriennummern auftraten, wußte der Ersteller, das da was nicht stimmen kann.


    Es sind etwa 50 doppelseitig bedruckte A4-Seiten, die in einem recht stabilen Hefter (Plastik) mit Titelbild abgeheftet sind.


    Die Übersetung ist manchmal etwas holprig, aber völlig OK (meine Meinung).



    Das wäre nochmal was zum Scannen. Werde aber dazu bestimmt in den nächsten Wochen und wahrscheinlich einigen Monaten nicht kommen....
    Aus der Hand gebe ich die vorerst nicht, meine Wheels-Seriennummer interessiert niemanden außer mir ;-) .



    Zitat von C=Mac

    Ich überleg mir, neben der U2+, noch ein SD2IEC zu zulegen.

    ohje, da komme ich ja demnächst zu gar nichts mehr... :lol27:

    Zitat von C=Mac

    Für das SD2IEC gibt es ja Treiber von Dir, welche unter MP3 laufen.

    Nein. Das SD2IEC unterstützt von sich aus Geos, Wheels und MP3, ist alles Geos ;-) . Man muss nur ein paar Dinge beachten, die in der readne zur offiziellen Firmware (von "unseen"; leider in englisch) haarklein beschrieben sind (wollte das hier mal nicht jemand übersetzen????).


    Mein uIEC (eine SD2IEC-Variante aus USA; Anbieter: Jim Brain, http://store.go4retro.com/ ) habe ich Ende 2011 gekauft. In der Form gibt es das wohl nicht mehr. Ich habe das uIEC mit einen Tochterboard, das direkt mit einem uIEC verbunden ist. Genau das wollte ich damals und reicht mir auch völlig. Heute hat das Tochterboard wohl 3 Steckplätze für 3 uIECs. Nun, wer es braucht ....


    Außerdem sollte nur eine Version gekauft werden, die mit der originalen Firmware von "unseen" funktioniert. Hier liest man immer wieder von Problemen mit neuer Firmware für Varianten, die auf eigene Firmware setzen. Es dauert ewig, bis die Neuheiten in deren Firmware übernommen wird. Wenn ich das richtig mitbekommen habe, hat in letzter Zeit ein User hier aus dem Forum versucht diese Änderungen auch in diese Firmware zu integrieren.



    Ich habe lediglich eine Software geschrieben, mit der man komfortabel unter Geos, MP3 und Wheels 64 und 128 zwischen den einzelnen Dxx-Images wechseln kann (uIEC-Manager). Der ist bewußt nur mit Geos-Befehlen programmiert, damit er eben überall läuft.


    Das uIEC/SD2IEC unterstützt:


    • unter Geos: D64, D71, D81 Images (ob hier mit GateWay auch DNP möglich ist weiß ich nicht)


    • unter MP3: D64, D71 und D81 (MP3 weigert sich ein DNP als HD zu erkennen, ist ja auch keine CMD-HD, hier wird es in ferner Zukunft möglicherweise einen externen Treiber geben)


    • unter Wheels: D64, D71, D81 und DNP (Wheels ist es anscheinend egal, was da dran hängt).


    Zitat von C=Mac

    Ist auch das Booten von MP3 64/128 vom SD2IEC möglich?

    Ja, problemlos. Man muss nur etwas beachten (siehe oben). Wheels habe ich jetzt nicht probiert, Geos kann von CMDs GeoMakeBoot-Startdisketten und auch von simplen Kopiien (D64) der originalen aber installierten Bootdisketten gestartet werden. Die Firmware regelt das. Auf einer echten 1541 würde das nicht funktionieren....


    Dann schaun wir mal, was da demnächst für Fragen kommen zum SD2IEC... :juhu:


    Gruß
    Werner

    Zitat von wweicht

    unter MP3: D64, D71 und D81 (MP3 weigert sich ein DNP als HD zu erkennen, ist ja auch keine CMD-HD, hier wird es in ferner Zukunft möglicherweise einen externen Treiber geben)

    Wie erkennt MP3 denn eine CMD-HD?


    Zitat

    unter Wheels: D64, D71, D81 und DNP (Wheels ist es anscheinend egal, was da dran hängt).

    Egal ist es nicht, aber die Erkennung ist leicht auszutricksen (ROM-File, um die richten Bytes bei M-R zurückzuliefern) und der Rest ist nur eine "Fastloader"-Erkennung die eine weitere Variante des im Prinzip immer ähnlichen Protokolls spricht.

    Hallo C=Mac,

    Zitat von wweicht

    Dann schaun wir mal, was da demnächst für Fragen kommen zum SD2IEC...

    Und das wichtigste habe ich gestern natürlich vergessen ;-) (naja, wurde spät ....)


    Die aktuelle readme kannst Du hier lesen: https://www.sd2iec.de/gitweb/?…t;a=blob;f=README;hb=HEAD


    die aktuelle Firmware und einiges mehr findest Du hier: https://www.sd2iec.de/


    Gruß
    Werner

    Hallo Unseen,

    Zitat von Unseen

    Wie erkennt MP3 denn eine CMD-HD?

    Wenn ich das genauer wüßte, wäre ich schon weiter.... ^^ . Ich habe keine HD und RamLink.


    Das Problem tritt auch mit FD und wohl auch RamLink (habe ich aber nicht probiert) auf. 1581-Partitionen funktionieren, Native nicht. Am ROM kann es eigentlich nicht liegen. Habe das Fake-ROM und je ein ROM-Dump von FD2000 und FD4000 (nicht das was mal bei VICE dabei war, ein originales) probiert. Da beide (Fake und Original) den String "FD" an genau der gleichen Stelle haben und exakt gleich groß sind (32.768 Bytes), gehe ich davon aus, dass das Original auch richtig gepeichert ist...


    Da wird irgendwas anderes abgefragt ....


    Seltsam ist, in VICE (x64sc) geht es mit FD. Da kann ich sogar von FD4000 Native MP3 64 booten. Moment mal, manchmal sieht man den Wald vor lauter Bäumen nicht :wand
    Eigentlich müßte man doch nur mal bei VICE schauen, wie das da gemacht wird. Ich habe zwar keine Ahnung von C++ irgendwas , aber vielleicht findet man da einen Ansatzpunkt...


    Gruß
    Werner