| |
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... |
|
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Simply replace the load routines in the game with Dreamload. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11148 |
"simply" ..... o_O |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Hmmm, ... and how? |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Using your favourite machine code monitor.
Of course this is not a trivial task, especially if you don't have any cracking experience.
But as long as there is no general loader interface that everyone sticks to, there is no simple way to update or exchange loaders or add new devices. |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Unfortunately i have no cracking-experience :_( |
| |
Scout
Registered: Dec 2002
Posts: 1568 |
Quote: Unfortunately i have no cracking-experience :_(
Start learning then...
Better do it yourself instead of waiting for others to do it for you :)
---
Commodore 64 Scenemusic Podcast
http://8bitmayhem.blogspot.com/ |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
But this is a good point to start thinking about some generic loader interface for easy loader swapping. Something most similar to the kernal open/chrin/close API and the vectors in low memory, and stdclib's filestream API (we need a seek() command).
Most problems, however, will occur concerning free memory and relocation.
I'll put the whole issue to my loader to-do list. |
| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
@Krill:
Ullrich v. Bassewitz would be very pleased for a seek command
for his cc65 compiler.
;)
|
| |
Ninja
Registered: Jan 2002
Posts: 407 |
Baccy has thought about doing an easy OPEN/CHRIN/CLOSE interface for the MMC. It might work then for games which got fixed for IDE64. Still, it would be a hack and won't work for all games of this kind. Oh, and it might take a century till a release ;) |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
I'll wrap my head around it, but we should work out a solution together. |
| |
enthusi
Registered: May 2004
Posts: 675 |
forgive my ignorance but isnt IDE-fix == use kernal-loader again?
(if not, why not? That would have been clever :) |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Hmm, :-l |
| |
cadaver
Registered: Feb 2002
Posts: 1154 |
Quote: forgive my ignorance but isnt IDE-fix == use kernal-loader again?
(if not, why not? That would have been clever :)
Yes, and especially not using serial bus related calls (ACPTR/TALK/LISTEN and such) |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
... And who has enough knowledge for this feature? |
| |
cadaver
Registered: Feb 2002
Posts: 1154 |
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.. |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
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: 407 |
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: 1154 |
Yeah, for DFI. |
| |
WVL
Registered: Mar 2002
Posts: 886 |
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: 407 |
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: 11148 |
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: 5028 |
what groepaz said |
| |
soci
Registered: Sep 2003
Posts: 474 |
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: 2854 |
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. |
| |
soci
Registered: Sep 2003
Posts: 474 |
Seeking should be no problem with IDEDOS 0.90. Actually DFI support is implemented with seeks...
|
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Yes, whateverDOS. Cool. And if i don't have/want it? :D |
| |
Ninja
Registered: Jan 2002
Posts: 407 |
Aaaargh, once I forget to copy my typed text to an editor and whooosh, it got thrown away :((((( Fuck!
Okay, to sum it up:
- Dreamload started as a 1541-loader for our demos
- we added everything else to see if it is possible
- it is still a loader for (our) demos
- so, we won't throw away the track/sector thing
- it is not really suited for games, KERNAL is better there.
- sorry to all, which hoped for lots of MMC-games now
- we wanted to add IDE64-DFI later, soci was faster
- (toolchain? just dreamass is really needed...)
And finally: it's all about the fun doing it... |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Then, we have to wait for real mmc-kernal support and forget dreamload? ;) |
| |
Krill
Registered: Apr 2002
Posts: 2854 |
Or just define a generic loader interface that goes without Kernal patches and then swap loaders if needed. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11148 |
much easier to create a kernel patch for a new device than adding support for a new device to <insert insanely large number> games.
demos, yes, those are a completely different story. |
| |
cadaver
Registered: Feb 2002
Posts: 1154 |
How much RAM the kernal patch would approximately need? I guess it would need to be relocatible to be useful.. |
| |
Ninja
Registered: Jan 2002
Posts: 407 |
Well, at least you won't need a buffer there. But some mem to store MMC-configs? Dunno, maybe Baccy stores everything in RR-Ram or something :D But as I said, KERNAL-thingie is just an idea at the moment and Baccy is busy as hell... |
| |
Bamu®
Account closed
Registered: May 2005
Posts: 1332 |
Hmmmm, RR-RAM?
Dont have a retro replay :-l |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: Hmmmm, RR-RAM?
Dont have a retro replay :-l
dreamload on mmc also works without the RR, i think it only uses RR as a possible buffer. |
| |
Ninja
Registered: Jan 2002
Posts: 407 |
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: 1154 |
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: 2854 |
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: 1154 |
Ah sorry, I meant saving with Dreamload-MMC64 onto its special images (which the heavy RPGs suggested would require) |
| |
Ninja
Registered: Jan 2002
Posts: 407 |
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: 1060 |
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 :) |
