retrohackers.org :: View topic - File-izing (removing 1541 dependence) software

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?

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.

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.

VBR wrote:

IDE64 patching guide tells you to do that yourself.

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.

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

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.

Do not extract the disk images! The game uses them as is, and saves the game
state into these images too. If you want to continue playing on 1541, then
just write them out

IDEDOS 0.9x or higher from 2005 or later required because of image file
handling!

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

Quote:

Do not extract the disk images! The game uses them as is, and saves the game
state into these images too. If you want to continue playing on 1541, then
just write them out

IDEDOS 0.9x or higher from 2005 or later required because of image file
handling!

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

VBR wrote:

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

Author:	VBR [ Tue May 01, 2007 9:26 am ]
Post subject:	File-izing (removing 1541 dependence) software
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.

Author:	paulm [ Tue May 01, 2007 1:18 pm ]
Post subject:	what about ide64
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

Author:	VBR [ Thu May 03, 2007 3:54 pm ]
Post subject:
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?

Author:	tnt/beyond force [ Fri May 04, 2007 7:51 am ]
Post subject:
VBR wrote: 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...

Author:	VBR [ Sat May 05, 2007 3:14 am ]
Post subject:
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.

retrohackers.org https://www.retrohackers.org/

File-izing (removing 1541 dependence) software https://www.retrohackers.org/viewtopic.php?f=4&t=256	Page 1 of 2

Author:	MagerValp [ Sun May 06, 2007 11:57 am ]
Post subject:
VBR wrote: 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...

Author:	VBR [ Mon May 07, 2007 4:22 am ]
Post subject:
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.

Author:	tnt/beyond force [ Mon May 07, 2007 11:20 am ]
Post subject:
VBR wrote: 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.

Author:	VBR [ Mon May 07, 2007 12:42 pm ]
Post subject:
tnt/beyond force wrote: VBR wrote: 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.

Author:	VBR [ Tue May 08, 2007 2:00 am ]
Post subject:
tnt/beyond force wrote: 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). 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. tnt/beyond force wrote: IDE64 behaviour isn't IEC-compatible anyway, as it doesn't forcibly re-enable interrupts at exit. This breaks some programs I've tgried. 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?

Author:	Stinky [ Wed May 09, 2007 12:10 pm ]
Post subject:
MagerValp wrote: I have an IFFL crack of U3 that I should finish some day... Pretty please!

Author:	VBR [ Wed May 09, 2007 2:02 pm ]
Post subject:
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.

Author:	hollowman [ Wed May 09, 2007 2:27 pm ]
Post subject:
VBR wrote: 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. From the info for maniac mansion ide64 fix Quote: Do not extract the disk images! The game uses them as is, and saves the game state into these images too. If you want to continue playing on 1541, then just write them out IDEDOS 0.9x or higher from 2005 or later required because of image file handling! 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 VBR wrote: 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. The solutions so far which replace the kernal routines, the dreamload plugin and the D64/D71 mounter plugin by tnt both require retro replay

Author:	VBR [ Wed May 09, 2007 3:26 pm ]
Post subject:
hollowman wrote: From the info for maniac mansion ide64 fix Quote: Do not extract the disk images! The game uses them as is, and saves the game state into these images too. If you want to continue playing on 1541, then just write them out IDEDOS 0.9x or higher from 2005 or later required because of image file handling! 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 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. hollowman wrote: VBR wrote: 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. The solutions so far which replace the kernal routines, the dreamload plugin and the D64/D71 mounter plugin by tnt both require retro replay Thanks. So MMC64 should be viewed more as an add-on to Retro Replay than as a stand-alone thing.

Page 1 of 2	All times are UTC [ DST ]
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/