I'm not very knowledgable of all the retro development efforts, so this may be a stupid question.

Has there been any effort to patch old games to use file access only (kernel load/save) instead of 1541 commands? I'm thinking particularly about adventure games which often used direct sector access instead of files, e.g. Ultima 3.

The advantage of using only load/save is that you could install on a flash drive or whatever without the need for 1541 emulation.

In the case of true random access, you would need 683 files per disk (one file per sector). Aside from wasting a bit of space due to small files, this seems reasonable. Alternatively, the system could map file names to disk image offsets.

Hi there vbr don't know if you knew about ide64 fix games. These are fixed patched games which you need the retro replay. But like you i have no clue on how they use kernal loads to fix games. The person to ask is doc b and the other cool guys on this forum.

chow
paul

Another approach is partial 1541 emulation: patch the kernel I/O routines and handle the U1, U2, and B-P commands.

Has this already been done?

Partially, yes. U3 runs from MMC64 with D64 mounter but there is no write support. Same goes with Infocom adventures using normal DOS.

Using seekable files with plain kernal is a bit difficult, as there is no Seek() in there...

Well, to amuse myself I went ahead and file-ized Ultima 3. I haven't tested it on an MMC64 (real or emulated), however. Maybe someone wants to try it?

Edit: I started to play with a virtual MMC64 under VICE, but it isn't what I expected. The ROM doesn't patch the load/save vectors - it's just a file browser. Also the ROM doesn't seem to be mirrored at $DExx or $DFxx. The problem with loading add-on software into the 64's memory is that there's no "safe" place to put it.

Ultima 3 doesn't use $e000-$ffff, so you can put a bunch of code there.

I have an IFFL crack of U3 that I should finish some day...

Started to play with IDE64 (under VICE). This works the way I expected MMC64 would (load/save vectors patched, etc). My file-ized Ultima3 loads. And very fast!

Saving almost works. It works sometimes, and sometimes crashes. Maybe I have to disable interrupts or something? Because if the IDE64 is changing the memory configuration without disabling interrupts, then that could cause big problems.

Is there any harm in using a "0:" prefix with IDE64? I want to use it to avoid the @save bug on 1541s.

Edit: Save seems to work reliably with interrupts disabled. This behavior is IMHO a bug. If it is desired to keep interrupts enabled, the RAM interrupt vectors should be intercepted so that the interrupt code can be executed in the correct memory configuration.

IDE64 patching guide tells you to do that yourself.

But why shouldn't the IDE64 code do it? I don't see any reason for this major compatibility problem.

And incidentally, that document is out of date in at least one respect. Current version can save A000-C000.

You'd better ask soci about that, but I'd guess it has something to do with limited ROM space available outside $8000 area ($de60-$deff).

IDE64 behaviour isn't IEC-compatible anyway, as it doesn't forcibly re-enable interrupts at exit. This breaks some programs I've tgried.

Maybe. In that case, I would prefer that it simply do an SEI. That is probably what most fastload carts do.

NMI is still a problem, but that is not used as much.



That's not good either. IDE64 should not be less compatible than a fastloader cart.

By the way, is it just me, or is the singularcrew.hu site down? Has it been down a long time?

Pretty please!

To answer the question I posed at the top of the thread: yes, there is an effort to file-ize software: it's called "IDE64 fixing". IDE64 doesn't currently support D64 images.

I am still confused about how MMC64 works. Is it effectively mandatory to use it in conjunction with Retro Replay? That is, do the necessary "plug ins" rely on RR? That would make sense, since otherwise the plug ins would have no safe place to hide. I've read the MMC64 documentation, but it doesn't explain much.

From the info for maniac mansion ide64 fix

I've never used ide64 and I dont know how this works but the fix uses d64 images of the game, same thing with zak mc cracken



The solutions so far which replace the kernal routines, the dreamload plugin and the D64/D71 mounter plugin by tnt both require retro replay

Ah. That is not direct support of D64s, but rather an IDE64-specific patch which opens D64s and seeks in them using non-standard commands.

But it's good that at least this level of support is already present. The rest should be easy.



Thanks. So MMC64 should be viewed more as an add-on to Retro Replay than as a stand-alone thing.