| |
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....
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Still a generic loader interface not relying on the KERNAL API would be quite feasible. You exchange a loader file on the disk/image and it would make stuff more compatible/faster/whatever. |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Quote: ... And who has enough knowledge for this feature?
Many people have that. None of them has time. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Krill: In deed, this would be extremly cool. I'm afraid this should have been there 20 years earlier ;)
cadaver: obscure? :D Because of DFI-files, or why? |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Yeah, for DFI. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: Just my personal opinion, as long as MMC64 doesn't support the standard kernal calls it's not worth it hacking support into games especially for it. Don't get me wrong, Dreamload is a cool loader and MMC64 loading on it seems like a cool (if a bit hackish and obscure) feature, but its memory footprint isn't especially the smallest..
erh.. how much memory DO you need for the MMC compatible dreamload? |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Dreamload needs 2 pages for loadercode and 1 page as a buffer. This has always been the case and was not extended because of MMC (but MMC is closest to the limit). When installing approx. $1000 byte are needed. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
what exactly is the problem with relying on the kernel api? inventing something new here just makes things worse imho. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
what groepaz said |
| |
soci
Registered: Sep 2003
Posts: 480 |
I've just fixed dreamload to load from DFI files on IDE64. Just because that was the only thing it couldn't load from, which was a shame ;) Now it passes all tests, except on SCPU, but that can't be fixed to be possible with memory configuration 5.
Actually I do not like the dreamload design. It's just too much based on the on disk layout. If one wants to load from files I think it's much simpler to call the KERNAL load routine, which is also much faster than loading from DFI.
The really fine toolchain prevented me for a long time to add IDE64 support, I've always got fed up with it and throw away the idea. That's probably because my style is too much different. But finally it couldn't stop me ;)
Dreamload should throw away the track/sector interface and only keep the filename based one. Then I'll fix it to use LOAD on IDE64 ;)
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quote: what exactly is the problem with relying on the kernel api? inventing something new here just makes things worse imho.
As i said, we (or at least i) want a seek command. And then there still is and always will be hardware that does not come with a kernal patch. Also, imagine having several devices with concurring kernal patches etc. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
