D64 mounter plugin

Es gibt 60 Antworten in diesem Thema, welches 17.477 mal aufgerufen wurde. Der letzte Beitrag (28. August 2006 um 21:09) ist von humppa.

  • :bia

    Ultima III loads intro sequence! It takes way too long to load and crashes afterwards, but this proves that direct access is possible.

  • Zitat

    Originally posted by tnt
    Ultima III loads intro sequence!


    It took until 2 AM to fix, but now U3 loads until it asks for scenario disk. Multidisk support is needed :)

  • Infocom adventures work too, and Printmaster, Racing Destruction Set needs one-byte patch and it works (until it asks for second disk)...

    I think the next job is to add multidisk support, but as plugins are limited to single file that requires joining several D64 files together.

  • Multidisk support is in, limited to two disk sides until I move some code around :)

  • Zitat

    Original von Ebster
    das plugin mit dem namen D71PLGIN.BIN muß natürlich vorhanden sein.

    Woher bekommt man das?? ?(
    In der C64-wiki ist nix eingetragen!

    Oliver W.

    10 GOTO Lesezeichen im Profil
    20 READ Lesezeichen im Profil
    30 PRINT Lesezeichen aus Profil
    40 POKE 198,0: WAIT 198,1

  • Zitat

    Originally posted by tnt
    Multidisk support is in, limited to two disk sides until I move some code around :)

    This is nice, how does it work? Does the game have to be patched, to send a sort of disk change command to the drive? I ask because there are probably many ways to do it, on IDE64, CMD-HD and 1571.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Zitat

    Originally posted by OliverW.
    Woher bekommt man das?? ?(
    In der C64-wiki ist nix eingetragen!


    Release of V0.5/0.6 is near. I think all fatal bugs are gone now (it crashed if it couldn't find file to load, for example :rotwerd: ). I need to write some docs for it. I hope to have quiet day at work today ;)

  • Zitat

    Originally posted by x1541
    This is nice, how does it work?


    Swapping works as follows:

    • you get "insert disk [whatever]" prompt
    • press freeze button, keep it down
    • press key to contine from prompt
    • still keeping freeze button down press key from "1" to "0"
    • release freeze button


    As BIOS doesn't tell plugins which directory selected file belongs in, you need to join D64 images to create one bigger file. Currently this is limited to two disk sides because of code size constraints. Stupid me put directory routines into same 8 KB bank with buffers, now I'm out of space there. (Buffering a whole track and cluster chain doesn't help, add CRC16 table and cross-bank copying code and you have less than 1.5 KB for code for memory card access and other things. I need to move "other things" to make room for write routines.) Overall memory usage isn't problem, I still have 16 KB unused :)

  • Zitat

    Original von tnt
    As BIOS doesn't tell plugins which directory selected file belongs in,


    Umm...I haven't tested it yet, but what about $cf8d + $cf8e?
    This should contain current directory cluster. Or does it only point do SYSTEM64?

    CU
    Kratznagel

  • Zitat

    Originally posted by Kratznagel
    Umm...I haven't tested it yet, but what about $cf8d + $cf8e?


    If they are same as $66/$67 then yes, but I'm not too keen to use variables which can move around when BIOS is updated. I will ask Oliver if I can trust them being there in the future.

  • If I got it right from Oliver, $CF80 - $CF97 should alway be there, no matter what BIOS version is in use. Because this is the "offical" parameter block which plugins have to use.

    CU
    Kratznagel

  • Zitat

    Originally posted by Kratznagel
    If I got it right from Oliver, $CF80 - $CF97 should alway be there, no matter what BIOS version is in use. Because this is the "offical" parameter block which plugins have to use.


    I got confirmation from Oliver, so I'm adding some code to find all similarly named files in same directory. I didn't ask Oliver if root dir base is always at $CF95-$CF97, but I'm using it anyway. Its first_data_cluster-#$20 anyway.

    One 8 KB bank has room for cluster chains of 11 D64 images in the worst case (32MB or smaller card = 512 byte clusters) which fits nicely with the idea of ten supported disks. With 64 MB or bigger cards those disks can be D71 as well.

  • Zitat

    Original von tnt
    I didn't ask Oliver if root dir base is always at $CF95-$CF97, but I'm using it anyway.


    Because this is also a part of the parameter block, I bet on that it will always be there, too. :)
    Otherwise many developers may get very angry. :D

    CU
    Kratznagel

  • Problem is that this parameter block isn't publicly defined except for the first 13 bytes. While it's possible to find out most of zeropage/$cf80 variables by either disassembly or experiment, it's not wise to use something which disappears in a cloud of smoke with BIOS update. I've now added the defines into my include file tho.

    I was hoping to release public version of plugin this weekend, but that might be impossible as today is mostly spent outside building a garage and I'm adding new code to multidisk support. My routine finds all similarly named files in a directory (max. 2 chars may differ), sorts them and allows further reordering/removal by user. Semi-intelligent matching isn't perfect, as it ties together names like "Zork1.d64" and "Zork2.d64", but people can always remove unnecessary images on entry screen or put games in separate dirs. File selected in BIOS browser will always be one which is mounted first by default, so additional images don't really matter anyway.

  • I got the informations about $CF80 - $CF97 directly from Oliver, no disassembly was required. :D
    Besides that, I wonder why he didn't made it public in his offical reference docs.

    BTW: I finally was able to test your plugin. It's working very fine so far. Keep on updating :bia

    CU
    Kratznagel

  • I managed to get directory scanner from browser working, now it finds all similarly named files (max. 2 different chars) and allows reordering them before mounting. Next I will write bubble sort (no need for anything more complex as there are max ten entries, so bubble sort is fast enough) to do the initial sorting. Then it's time to move some routines around to fit new disk swapping system in.

  • New multidisk code is nearly there now. Completely unrelated fix was done as a result of Nata asking for MMC64 compatible SidPlay in CSDb forums. Now IDE64 fixed SidPlay0.4 works :)
    I'm not uploading any versions for beta testers yet, as current version is ugly hybrid of old and new multidisk system. Everything on-screen suggests the new code is in, while in reality old limited routines are used. Very confusing :)

  • New version is now uploaded, testers may want to download it again. It now supports up to ten separate disk images, so no more joining disk images together to get multidisk programs working. All serial debug info gone for a while, I wanted to see how it affects speed. Directory display in entry screen is disabled until I have time to fix it. Docs included.

    See you next week :)

  • tnt hat sein eigenes game pack im rr-forum online gestellt...

    DOWNLOAD:
    Bitte melde dich an, um diesen Link zu sehen.

    mfg!