| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Dreamload question
Hi!
Does anyone know how to 'convert' ide64 fixed games to dreamload?
I saw that there exists an ide64 version of 'Rick Dangerous 2'. How do I add the new loader?
It should run with the MMC64... |
|
... 35 posts hidden. Click here to view all posts....
|
| |
Ninja
Registered: Jan 2002
Posts: 406 |
I meant "will store". This was for a possible KERNAL-thigie. Dreamload can use RR, but does not need it, as WVL said. |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
How many new & old demos will be fixed with dreamload?
I doubt people will use it as their standard loader.
However, it would be quite cool if every new demo would run from mmc64. 8-)
edit: kernal support would solve alot problems, but if a RR is required... :-l |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
I'd appreciate the jewel crackers taking Dreamload into account much more than demos. Retrofixing games like Ultima or all those multidisk RPG games to work from MMC64 would be a blast! :-) |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Well you still can't save on MMC64 (and for saving in general, you need to detach the loader and be prepared to run the $1000 byte init routine again)
Furthermore, I guess pride of using in-house loader can never be underestimated :) |
| |
Krill
Registered: Apr 2002
Posts: 2853 |
Indeed. Also nothing speaks against making other loaders more compatible. And Dreamload still has the big disadvantage of only allowing one device on the bus. (So does my loader, but that will change)
As for me, the initial idea was to make the _fastest_ irq loader for demos, and that's still the primary goal. That means best performance on Commodore 64 + 1541, other configurations are of less interest. Many demo producers have the same primary goals, and that's why some of them prefer my loader.
Recently, i added a kernal fallback that works with exotic hardware as long as they work with the plain iec protocol or if there is a kernal patch supporting them.
I will add more compatibility (1581/FD/HD without kernal fallback) later, but primary aim still is to max out the speed on a 1541. |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Quoting cadaverWell you still can't save on MMC64
Says who? ;) There are at least three people who have managed to write FAT16 files onto MMC64, but AFAIK only Oliver has released it in public (D64 reader).
Bad news is that because of lack of RAM in MMC64 kernal patch compatibility will always suffer badly unless you have RR or some other extra memory. Read-only support from file container like DFI can't be done in much less than 512 bytes (without any buffering, bleuch!), real FAT16 file system support takes about twice that much and we are still taking about read-only files. Even if routines are put into MMC64 BIOS each open file needs several bytes for housekeeping, and couple more bytes are needed to redirect kernal calls. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Ah sorry, I meant saving with Dreamload-MMC64 onto its special images (which the heavy RPGs suggested would require) |
| |
Ninja
Registered: Jan 2002
Posts: 406 |
Well, Doc Bacardi is usually in contact with crackers. NosDos contains code derived from DreamLoad, for example. But I don't think discussions about MMC have been made yet. It is still a completely different issue.
Krill: We also had an idea to have more than 1 drive on the bus. But as we wanted to support 2Mhz-drives sending data a lot faster than the 1541, it got spoiled :( |
| |
MagerValp
Registered: Dec 2001
Posts: 1059 |
Saving to a fixed size save file should be easy with the MMC64. You just find out which sector(s) the file is using when the program starts, then write data straight to the sector when saving.
|
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Yes, that it easy, but when you need to do everything associated with creating new file you get plenty of additional code. PETSCII->ASCII conversion, checking for exisiting file/dir with same name, deleting (or overwriting + adjusting size of) old file if found, creating new directory entry with long file names... In the end finding free clusters and allocating them is the easiest part.
Things get a bit easier if you use file container with fixed size, especially with D64 - lots of code from 1541 ROM available :) |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
