Beiträge von Metallic

    You are welcome. =) Actually its easy, just call $DF02 at the right point.

    I guess you used equal char packer because it's depacker size is less than a decruncher. Finding enough free memory to add code can be really difficult in some games.

    Sorry, but I have a bug report for Strike Fleet: After resetting the C64, when you press SPACE key while playing music on the Strike Fleet picture, the game hangs.

    EDIT: It happens if a 1541 is connected to the C64. It would be okay if we turned the C64 off and on instead of resetting it though.

    Presumably pride64 is trying to finish these games at the moment to see if there is any problem. =) While playing these difficult games without a trainer, be sure to check out Reinhard's professional gameplay: Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Stephan Scheuer
    It's cool to see both games on a single .d64 :D
    I've tried to convert with latest D2EF but unfortunately on Vice doesn't work (and i think on a real c64 too)
    This version also have the QTE levels bugged (Missing Dirk, glitches and slowdowns).
    I'm not good with assembly stuff and programming, maybe Metallic can take a look to your work :whistling: :emojiSmiley-28:

    Sorry, I don't want to annoy Stephan. =) Regarding to the missing Dirk, may be he marked a part of the code belonging to Dirk as a comment in the source code he prepared and forgot it. If he fixes it, Dirk may show up. =)

    Disk2EasyFlash 0.9.3-r2

    ----------------------------------

    - Changed IRQ control at the handler exit of D2EF. There was a CLI previously, now the status of the interrupt disable flag at the time of the Kernal call is being preserved by PHP and PLP couple. With this change, some almost-running games reported by CommFor became working. Some also became working stable.

    So where was the problem?

    This is something interesting and difficult to explain. The problem is being caused by the on-the-fly depacker used in the games. I noticed that some games crash when a key is pressed on the keyboard while loading a level. When I search the reason, I found that the content of the address used as a variable by the depacker was changed by Kernal IRQ handler at the time of the key press. This is not Kernal IRQ handler's fault of course, the depacker is using an address used by Kernal IRQ handler. I spotted some depackers that are this way:

    Unknown depacker

    uses zero page address $F6 (high byte of the vector: keyboard decode table)

    has several variations

    example games:

    Alien Syndrom / Remember Bitte melde dich an, um diesen Link zu sehen.

    Dark Fusion / The Sharks - IDEFIX by Arcane Bitte melde dich an, um diesen Link zu sehen.

    Darkman / X-Rated - IDEFIX by Arcane Bitte melde dich an, um diesen Link zu sehen.

    Karateka / Remember Bitte melde dich an, um diesen Link zu sehen.

    Super Cycle / Remember Bitte melde dich an, um diesen Link zu sehen.

    Sword of Honour / Alphaflight - IDEFIX by Arcane Bitte melde dich an, um diesen Link zu sehen.

    Katakis / Hokuto Force Bitte melde dich an, um diesen Link zu sehen.

    Even if a key is not pressed in these games while a level loading is being done, a problem may occur. For example, when you convert the Darkman above to Bitte melde dich an, um diesen Link zu sehen. with D2EF 0.9.3-r1 and run it, if you press the RETURN key on the "start game" selection in the trainer menu, but not release the key fast enough, the game will not run after the level loading. This problem was solved with the new revision. Bitte melde dich an, um diesen Link zu sehen. is the same Darkman converted with D2EF 0.9.3-r2.

    Stephan Scheuer

    Yes, cartridge protection would be important for EF, but D2EF versions of Dragon's Lair are not working on CommFor's EF3 only. =) I looked at the Wicked Slime release (Dynamic Duo + Eagle Soft) that we converted with D2EF, I couldn't see the protection. I guess it's removed.

    0xdeadbeef

    You are right, these games actually have real EF versions. I tried to understand why D2EF versions do not work on some people.

    Here i am :)
    WBML on my ultimate II works, but only if i enable the drive on "8". Without floppy drive emulation enable (only with cartridge functionality) doesn't load, waiting for drive 8 with blu/light blu flashing screen. It's a strange thing =O

    Oops, I have never tried without a floppy drive connected to C64. You caught the clue, thanks. :) Nostalgia's N0SDOS is checking the floppy drive via the command channel, but the command channel is not supported in D2EF. Sorry about that.

    Plotting and Wonderboy in ML doesn't load after cracktro (The nostalgia release of WBML has already a really good working .crt version)

    Plotting actually needs to be adapted to D2EF, because it takes bytes from the file using the $EE13 routine. The funny thing is that even though it can't load the levels, it seems to be working. =) I've converted Wonderboy with the new revision of D2EF, could you try to see if it works?

    CommFor & Fepo

    I've converted pride64's first Dragon's Lair with the new revision, is there still a problem?

    Here is an excerpt from my adapted exmizer on-the-fly level decruncher. :)

    I had used this very often at my 1581 adaptations.

    table 1 with jump to program function over vectors.

    table 2 without jump to program function over vectors.

    I wish you called the routines over the Kernal jump table, your D81 games would work directly when converting them to CRTs with D2EF. :( :)

    I will repeat once more, all games from post Bitte melde dich an, um diesen Link zu sehen..020 to Bitte melde dich an, um diesen Link zu sehen..034 have slow loading time comparable to floppy reading.

    The slow loadings you mentioned are due to the on-the-fly depackers that have been used in the games. The size of the packed file also increases the loading time. I optimized the get-byte function's code, so I don't think its slow. Here are some comparisons made on VICE:

    A: C64 + EasyFlash (D2EF image)

    B: C64 (Dolphin-DOS2 Kernal) + 1541-II (Dolphin-DOS2 ROM, D64 image) + parallel cable

    Strider/HF level2 loading time - A: 3.78s , B: 5.22s

    Mercs/HF level2 loading time - A: 3.95s , B: 5.27s

    Shinobi/HF level2 loading time - A: 4.01s , B: 5.44s

    To make instant loadings, the packed files must be depacked and then loaded using normal LOAD. But doing that is a time consuming and tedious task.

    And thanks a lot for all of your hard work in this thread. =)

    The update to manage on-the-fly decrunchers was a great job. Thank to Metallic.:)

    if you have time, you could add your support for fd-2000 images. Then it is possible to customize games with more than 296 files.:)

    Thanks. =) It's necessary to dive into PC-side source codes of D2EF to provide FD-2000 support. Unfortunately I'm not familiar with C.


    pride64_getting_old

    I'm adding Dynamite Dux below. Have fun. =)