GEOS MegaPatch V3 Release 2018

  • petSD+ replied with 00,OK,00,00; but I found the information, that the only turboloader it supports is JiffyDOS - it's CPU is clocked twice as fast as SD2IEC (needed for IEEE-488 support), so the code supporting each protocol has to be adapted; so it's probably normal that GEOS does not work.


    Yes, disk IDs were the same - as I simply moved the SD card from one device to another, I also set the same drive number (old unit was disconnected).

  • petSD+ replied with 00,OK,00,00; but I found the information, that the only turboloader it supports is JiffyDOS - it's CPU is clocked twice as fast as SD2IEC (needed for IEEE-488 support), so the code supporting each protocol has to be adapted; so it's probably normal that GEOS does not work.

    In this case, without lots of extra work to rewrite the disk drivers, the petSD+ will not work with GEOS or MegaPatch at all. It is not impossible, but new drivers for petSD+ are required that do access the data on the disk using generic disk commands instead of using the GEOS TurboDOS.

  • Google search revealed, that this is probably at least partially done - see here, First look on GEOS running on MEGA65 in C64 mode. In order to make this work, I had to strip any turbo code from the 1581 driver that normally would run off the 1581 drive, Unfortunately, code does not seem to be public.

    This is exactly what i have mentioned above. You need to use generic disk commands instead of the TurboDOS. That is really not very difficult to do but it needs some time to be done. You can do that even in pure BASIC (read data sectors from disk).

    Also memory will not be an issue since this code will be much smaller (and also slower for real disks, but maybe faster for SD-Devices).

    Also you need to create additional drivers, you cannot modify the original 1541/71/81 drivers or real devices will getting slower. I do not see a real problem here.


    I'm going to order a MEGA65 when it is available, so that modification will be done, just not now. Too much other things to do. Maybe i'll have a look after GeoDesk64 is ready... but right now i need a better DeskTop (most code is done, just some nasty bugs and a few missing features left).


    P.S. There is a newer video available... see MEGA65-section in this forum...

  • But with JiffyDOS or DolphinDOS such a drive would just fly, maybe even IDE64 could work this way (imagine that speed...).

    But I agree, new desktop is badly needed... I hope the English version will also be available some day, testing German one is not easy for me :)

    The generic disk commands like B-R/B-W will not benefit from JiffyDOS or DolphinDOS... but i may be wrong. Let's do some benchmarks when the code is done ;)


    About the english version, yes... will be done. Just like for GeoDOS or MegaPatch. Please be patient ;)

  • I have done some testing with a small *GEOS* test utility.


    Reading 200 Blocks on a C64 with JiffyDOS and SD2IEC using ROM-routines is taking about 14seconds. Using GEOS TurboDOS it will take about 6seconds.


    This is the same as for reading data from a CMD FD2000 and 3,5" floppy disk.


    Without JiffyDOS reading 200 Blocks using ROM-routines takes about 20seconds.


    That means SD2IEC drivers not using the GEOS TurboDOS will be about 50% slower. Without JiffyDOS about 75% slower.


    Maybe the original driver can be optimized but i think the drivers will be slower then the GEOS-TurboDOS-drivers but should work on any device supporting the generic U1/U2-floppy commands.



    Der Vollständigkeit halber:

    Ich habe einige Tests mit einem kleinen *GEOS* Testprogramm durchgeführt.


    Das Lesen von 200 Blöcken auf einem C64 mit JiffyDOS und SD2IEC mit ROM-Routinen dauert ca. 14 Sekunden. Mit GEOS TurboDOS dauert es ca. 6 Sekunden.


    Dies ist das gleiche wie beim Lesen von Daten von einer CMD FD2000 und 3,5" Diskette.


    Ohne JiffyDOS dauert das Lesen von 200 Blöcken mit ROM-Routinen etwa 20 Sekunden.


    Das bedeutet, dass SD2IEC-Treiber, die nicht das GEOS TurboDOS verwenden, etwa 50% langsamer sind. Ohne JiffyDOS etwa 75% langsamer.


    Vielleicht kann der ursprüngliche Treiber optimiert werden, aber ich denke, die Treiber werden langsamer sein als die GEOS-TurboDOS-Treiber, sollten aber auf jedem Gerät funktionieren, das die allgemeinen U1/U2-Diskettenbefehle unterstützt.

  • My guess is that JiffyDOS accelerated ACPTR does some handshaking every time it is called (for every byte), while GEOS turbo is probably optimized to transfer the whole block... On a real 1541/1571 DolphinDOS might have a chance vs GEOS turbo, as it has additional RAM for storing whole track and uses parallel port for transfer - but it is limited to 1541/1571 only.

  • I don't know how the other FastLoaders work, but TurboDOS works with 4Bit during the transfer.


    To do this, the TurboDOS routine is installed in the drive, which then divides the individual bytes into two nibbles of 4 bits. These 4Bit are then sent/received all at once.


    There are no special routines that read the data faster from disk or write it to disk like a disk cache. Except for the 1541shadow driver which keeps the data in the GEOS ram expansion.


    This is the reason why your petSD+ does not work, as the firmware does not emulate the communication between GEOS and the code running in the drive. The SD2IEC does not run a copy of TurboDOS, but processes the sent/received data just like GEOS TurboDOS would. If your firmware does not support that, then GEOS will hang first time it tries to communicate with the device because it is waiting for a reply.


    Anyway... my test application has already all code required to read a block from disk using the ROM-code, that means about 25% of the work is already done.

  • Irgendwo im Forum hab ich mal einen Test zwischen TurboDOS vs JiffyDOS gemacht.

    Traue keinem Test den Du nicht selbst gefälscht hast :P


    Nein, ich bin mir sicher mein Test ist ein anderer als Deiner. Ich hab ja unter GEOS mit den entsprechenden GEOS-Routinen Daten über Jiffy in den Speicher geladen. Der Code entspricht schon fast dem einlesen über den Laufwerkstreiber. Ich bin mir sogar sicher das ich hier den optimalen Fall getestet hab und das es beim echten Treiber noch langsamer wird.


    Abgesehen davon:

    Das Thema SD2IEC-Treiber für 1541/71/81 hatten wir hier schon einmal, da bin ich mir sicher. Ich hatte schon damals erwähnt das es kaum noch Möglichkeiten für neue Laufwerks-Modi gibt. Wenn ich mich weiter damit beschäftige muss ich prüfen ob es zusätzliche Treiber werden, oder ob die Generic-Treiber die TurboDOS-Treiber ersetzen. Evtl. auch als "Option", evtl. wie bei den HD-PP-Treibern.

  • Traue keinem Test den Du nicht selbst gefälscht hast :P

    Sag ich ja auch immer. ;)



    Nein, ich bin mir sicher mein Test ist ein anderer als Deiner.

    Ging glaub um Dateien kopieren.


    Unterschiedlicher Test, gleiches Ergebnis -> TurboDOS ist schneller.



    Das Thema SD2IEC-Treiber für 1541/71/81 hatten wir hier schon einmal, da bin ich mir sicher.

    Ja da war mal was. :saint:

    Läuft aber mit dem aktuellen MP3 ohne Probleme.

    Egal ob Commodore-LfW, CMD-LfW oder das SD2IEC in allen Modi. :thumbup:


    Gruss C=Mac.

  • Das Thema SD2IEC-Treiber für 1541/71/81 hatten wir hier schon einmal, da bin ich mir sicher.

    Ja ;-) . Ergebnis war damals so ungefähr: Brauchen wir nicht, da die Geos-/MP3-Treiber (41/71/81) problemlos und schnell mit dem SD2IEC (unseen-Firmware) funktionieren.


    prüfen ob es zusätzliche Treiber werden, oder ob die Generic-Treiber die TurboDOS-Treiber ersetzen.

    Ich wäre für zusätzlich bzw. optional. Auch wenn ich momentan am SD2IEC nur noch mit DNP arbeite, habe ich keine Lust (falls sich das mal wieder ändert) durch die Generic-Treiber ausgebremst zu werden ;-) .


    Vielleicht kann man mit dem Programmierer der petSD+-Firmware diskutieren, dass bei IEC-Anschluss eben nur unseen-Code verwendet wird und für IEEE was auch immer. Keine Ahnung, ob sich das per Firmware realisieren läßt.


    Läuft aber mit dem aktuellen MP3 ohne Probleme.

    Egal ob Commodore-LfW, CMD-LfW oder das SD2IEC in allen Modi.

    Ja. Hier geht es aber speziell um das petSD+, das sich mal wieder anders verhält ......


    Gruß

    Werner

  • Ich wäre für zusätzlich bzw. optional. Auch wenn ich momentan am SD2IEC nur noch mit DNP arbeite, habe ich keine Lust (falls sich das mal wieder ändert) durch die Generic-Treiber ausgebremst zu werden ;-) .

    Das kann auch nur Optional sein, da ich auch keine Lust habe alles neu zu machen ;)

    Ich stelle mir da eine eigene Anwendung vor die es erlaubt bei Bedarf die Standardtreiber in GEOS.Disk gegen die Generic-Treiber auszutauschen. Dann muss ich an MP3 auch nichts ändern.


    Da ein direktes Booten von GEOS v2.x am petSD+ auch nicht möglich sein dürfte, kann man MP3 eh nicht am petSD+ installieren. Bevor man dann das Image auf das petSD+ kopiert muss man dann die Treiber wechseln. Dann sollte das DiskImage auch von petSD+ booten können. So zumindest die Theorie.

  • Da ein direktes Booten von GEOS v2.x am petSD+ auch nicht möglich sein dürfte

    Gute Frage, ob das geht - davon habe ich ganz ehrlich im Thread noch nichts gelesen. Der MP3-Treiber für den SD2IEC benutzt ja nur ein prüfsummengleiches Teil, um Turbodos zu aktivieren. Eine andere Prüfsummenroutine, und schon würde Geos gehen und MP3 IEC nicht.

  • Meiner Meinung nach geht das am Kern der Frage vorbei: Das petSD+ kann ja mit ganz anderen Prüfsummenroutinen arbeiten, so dass original TurboDOS und der nachgemachte (auf dem SD2IEC prüfsummengleiche) Teil nicht als gleich erkannt werden.

  • so dass original TurboDOS und der nachgemachte (auf dem SD2IEC prüfsummengleiche) Teil nicht als gleich erkannt werden.

    Glaube ich nicht so richtig dran ;-) . So wie ich das sehe, ist das 1:1 von der unseen-Firmware übernommen (siehe: http://petsd.net/ ). Da gibt es auch den Source-Code und Binarys der aktuellen Firmware. Laut der Beschreibung dort und auf github (dort verlinkt) müßte zumindest Geos booten.

    Unter Umständen tritt das Problem nur auf, da FeralChild gerade DNP benutzt hat und der Code von MP3 wird eventuell von der petSD+-Firmware nicht bzw. nicht richtig unterstützt.....:

    I boot it from DNP image.

    Gruß

    Werner

  • FeralChild Can you please try running MegaPatch using a 1581-BootDisk without DNP? If that is working then it really might be a problem with the NativeMode driver which does some tricks to init the TurboDOS.


    If it's really only NativeMode that doesn't work, then I can save the effort of new drivers, or just adapt the NativeMode driver.


    The NativeMode driver must patch TurboDOS to handle 16Mb DiskImages. Therefore the checksum does not match the TurboDOS of the 1581 anymore.


    If you omit the patch, take the IECBus-NativeMode driver (not SD2IEC-Native) and replace TurboDOS with the 1581 version, the checksum doesn't matter anymore. But then you don't have 16Mb NativeMode support (max 127 Tracks = 8Mb).


    The code for the IECBus native driver is still present in the MegaPatch code and is easy to assemble (if the size for the driver hasn't changed since then, the driver has not been tested in a while). Then I could create a modified GEOS.disk file for testing.


    P.S.: While I think about it and while I take a look at the code.... the TurboDOS patch was needed for the CMD-HD. On SD2IEC and IECNM this should not be necessary. IECNM can then use the 1581-TurboDOS which has the limit of 127 tracks = 8mb.


    P.S.2: The SD2IEC driver does some more tricks to make use of 255 tracks. That could also cause the trouble.