It is currently Wed Sep 26, 2018 3:16 am

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue May 01, 2007 10:26 am 
Offline

Joined: Tue May 01, 2007 9:31 am
Posts: 12
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.


Top
 Profile  
Reply with quote  
 Post subject: what about ide64
PostPosted: Tue May 01, 2007 2:18 pm 
Offline

Joined: Mon May 15, 2006 9:41 am
Posts: 62
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu May 03, 2007 4:54 pm 
Offline

Joined: Tue May 01, 2007 9:31 am
Posts: 12
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?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri May 04, 2007 8:51 am 
Offline

Joined: Thu Jan 12, 2006 10:10 am
Posts: 177
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...


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat May 05, 2007 4:14 am 
Offline

Joined: Tue May 01, 2007 9:31 am
Posts: 12
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun May 06, 2007 12:57 pm 
Offline

Joined: Sat Oct 14, 2006 9:30 am
Posts: 140
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...


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon May 07, 2007 5:22 am 
Offline

Joined: Tue May 01, 2007 9:31 am
Posts: 12
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon May 07, 2007 12:20 pm 
Offline

Joined: Thu Jan 12, 2006 10:10 am
Posts: 177
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon May 07, 2007 1:42 pm 
Offline

Joined: Tue May 01, 2007 9:31 am
Posts: 12
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon May 07, 2007 3:20 pm 
Offline

Joined: Thu Jan 12, 2006 10:10 am
Posts: 177
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue May 08, 2007 3:00 am 
Offline

Joined: Tue May 01, 2007 9:31 am
Posts: 12
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?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed May 09, 2007 1:10 pm 
Offline

Joined: Fri Jan 13, 2006 2:10 pm
Posts: 43
MagerValp wrote:
I have an IFFL crack of U3 that I should finish some day...


Pretty please! :D


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed May 09, 2007 3:02 pm 
Offline

Joined: Tue May 01, 2007 9:31 am
Posts: 12
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed May 09, 2007 3:27 pm 
Offline
User avatar

Joined: Thu May 18, 2006 2:17 pm
Posts: 76
Location: Kungsör, Sweden
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed May 09, 2007 4:26 pm 
Offline

Joined: Tue May 01, 2007 9:31 am
Posts: 12
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group