WHDLoadCD32

[MethodGit]

Does anyone know how far one would get if they, say, used WHDLoadCD32 in a self-booting HDF file (as in seperate game HDFs)? Being a WinUAE-only format, most other things like memory limits/limited features shouldn't be a concern, right?

I only ask because I'd like to imagine booting up an HDF and going straight into a game (near) flawlessly, like with JST or an ADF.

[killergorilla]

Well you'd instantly rule out any game that needed more than 2mb of memory.

In fact, just register whdload and stop worrying about this cd32 malarkey.

[MethodGit]

I have registered WHDLoad already.


And surely one-disk games as such wouldn't be affected by the limited memory?

[killergorilla]

If you've registered already why use the whdloadcd32 version then? It's lacking features that the original WHDLoad has.

There are plenty of games which will work but as Whitesnake and other people have found out, it's not an easy task figuring out which ones. Unless you plow through them all.

[MethodGit]

Sorry, I only suggested WHDLoadCD32 as an alternate suggestion for if you're making such self-quick-booting HDFs publically available. Sure, it would only come in handy for certain 'small'-sized games, but I'm sure people would love to be able to go straight into a game thanks to WHDCD32 and the appropriate SplashDelay key setting - would be more like Stein's HDFs of old in a way!

[MethodGit]

Hmmm, what would probably help though, is if there was a good list of RAM requirements for each WHDLoad game. Not all slave readmes mention what amount of RAM is needed minimum, and amount to preload etc.

[killergorilla]

But that can vary depending on whether you've packed the files or not

[MethodGit]

True, but then not all slaves support compressed files, right?

[killergorilla]

You'd be surprised!

[fisken uno]

Well, I'm currently "converting" the CD32-444 compilation to use WHDLoadCD32 instead (and yes I've removed the disguised pirated WHDLoad key). It'll be interesting to see how this affects compatibility. As far as I can tell WHDLoadCD32 ignores all saving requests, which CAN be a problem... I know that you cannot save anything on a standard CD32 (assuming that you cannot manually access the small memory supposed to hold highscore data etc), but previous compilations have solved this by saving to RAM. These saves will be lost upon reboot of course, but may be usable for games that require saving in order to run. Now, WHDLoadCD32 doesn't allow setting a savedir so I guiess it doesn't even allow temporary saving...

Anyway. Once I've converted all script files it'll be easy to compare which games will be affected by compatibility issues

(I also plan to add games from the other compilations in order to make it "the one and only compilation you'll ever need" )

[MethodGit]

It is a bit of a shame that no-one's managed to work out a way of saving any data they want directly to the NVRAM storage of the console. Lack of documentation to blame I'll assume.

[fisken uno]

Originally Posted by MethodGit

It is a bit of a shame that no-one's managed to work out a way of saving any data they want directly to the NVRAM storage of the console. Lack of documentation to blame I'll assume.

Do you know how big this NVRAM storage is? I guess it's not that hard to find on the net but I'm asking in case you know on the top of your head? Guess it can't be very big since it was really only supposed to hold high score data and for a few titles saved games.

[Toni Wilen]

It is only 1 kilobyte (24C08 I2C EEPROM). I2C data and clock pins directly available in Akiko's address space. (=very cheap solution)

[killergorilla]

1KB!?! Bloody hell!

[fisken uno]

Originally Posted by Toni Wilen

It is only 1 kilobyte (24C08 I2C EEPROM). I2C data and clock pins directly available in Akiko's address space. (=very cheap solution)

Thanks for this info. I think I've read it somewhere because I'm not surprised it's that small... I guess there's not much point in trying to access it manually anyway then, as it just wouldn't be big enough.

[Wepl]

Originally Posted by MethodGit

Hmmm, what would probably help though, is if there was a good list of RAM requirements for each WHDLoad game. Not all slave readmes mention what amount of RAM is needed minimum, and amount to preload etc.

Check http://aminet.net/util/misc/WHDInfo110.lha it displays how many memory the slave directly requires, then you have to add 200 KB for WHDLoad itself. Then add memory for Preload by getting the sum of all files (or some if partial preload is sufficient, e.g. one diskimage contains only the intro...)

[Wepl]

Originally Posted by fisken uno

Well, I'm currently "converting" the CD32-444 compilation to use WHDLoadCD32 instead (and yes I've removed the disguised pirated WHDLoad key). It'll be interesting to see how this affects compatibility. As far as I can tell WHDLoadCD32 ignores all saving requests, which CAN be a problem...

This should not cause any problems because WHDLoad behave like the write has occured. So the Slave/Game does not see/know that the write has not been performed (as long it is not trying to load the data again).
If you encounter problems let me know...

I know that you cannot save anything on a standard CD32 (assuming that you cannot manually access the small memory supposed to hold highscore data etc), but previous compilations have solved this by saving to RAM. These saves will be lost upon reboot of course, but may be usable for games that require saving in order to run.

I dont know why such workarounds have been implemented on the cd's because also in earlier WHDLoad versions there was a check if the filesystem is read-only and in that case WHDLoad should never have tried to write anything on it and producing errors because of this.

Now, WHDLoadCD32 doesn't allow setting a savedir so I guess it doesn't even allow temporary saving...

WHDLoad never had an option to specify a savedir. You mean CoreDumpPath? That is only for coredumps and should be completely out of interest for a CD32 and a this kind of game cds.

Anyway. Once I've converted all script files it'll be easy to compare which games will be affected by compatibility issues

(I also plan to add games from the other compilations in order to make it "the one and only compilation you'll ever need" )

Great
With WHDLoadCD32 some more games should work because it uses less memory.

[fisken uno]

Originally Posted by Wepl

This should not cause any problems because WHDLoad behave like the write has occured. So the Slave/Game does not see/know that the write has not been performed (as long it is not trying to load the data again)

That's what I mean. Some games may want to read the data again and that could be a problem. On the top of my head I think Test Drive II saves to disk when you change car or scenery. I'm not sure how it behaves in WHDLoadCD32 because I haven't tested it (yet), but I'll let you know if I come across any problems with it

Originally Posted by Wepl

WHDLoad never had an option to specify a savedir. You mean CoreDumpPath? That is only for coredumps and should be completely out of interest for a CD32 and a this kind of game cds.

Hmm. Yes, sorry. That must have been it... I was sure I'd found a line referring to a savedir or something in the prefs file on the CD32-444 CD but it seems that I was indeed thinking of the coredumppath and just as you say, WHDLoadCD32 doesn't need such a path because it doesn't generate coredumps. How silly of me.

Another question... I assume you don't own a real CD32, Wepl? I think I read that somewhere... Anyway, it's odd because I have problems getting games that use a kick file (such as the 1.3) to run... at ALL. For example, when I try loading the WB 1.3 slave in WinUAE it works (with a massive amount of flickering due to OS swaps, but still) but on the real CD32 the screen just goes black and nothing more happens. I got the same behaviour with Pirates (the floppy version) to name another. There are more games that work from WinUAE's CD32 quickstart mode that just won't work as they should on the real CD32. Dragon's Breath starts but after the intro the screen goes black and the CD just reads and reads but nothing more happens. I've encountered this on several CDs too, so it's not write errors and/or scratched CDs... Just thought I'd let you know although I know it's too little information to be of any use to you. After I've completed the "conversion" of the CD32-444 I'll do some more structured playtesting of games to see which do / don't work and I'd be happy to pass this info on to you... It would, however, have helped greatly if you had a CD32 yourself. Unfortunately, I cannot donate anyone to you since I'm not parting with mine

[Wepl]

Originally Posted by fisken uno

That's what I mean. Some games may want to read the data again and that could be a problem. On the top of my head I think Test Drive II saves to disk when you change car or scenery. I'm not sure how it behaves in WHDLoadCD32 because I haven't tested it (yet), but I'll let you know if I come across any problems with it

yes, if there are really games with such problems it must be decided if changing the install or a modification for WHDLoad (saves to WriteCache) is appropriate.

Another question... I assume you don't own a real CD32, Wepl? I think I read that somewhere... Anyway, it's odd because I have problems getting games that use a kick file (such as the 1.3) to run... at ALL. For example, when I try loading the WB 1.3 slave in WinUAE it works (with a massive amount of flickering due to OS swaps, but still) but on the real CD32 the screen just goes black and nothing more happens. I got the same behaviour with Pirates (the floppy version) to name another. There are more games that work from WinUAE's CD32 quickstart mode that just won't work as they should on the real CD32. Dragon's Breath starts but after the intro the screen goes black and the CD just reads and reads but nothing more happens. I've encountered this on several CDs too, so it's not write errors and/or scratched CDs... Just thought I'd let you know although I know it's too little information to be of any use to you. After I've completed the "conversion" of the CD32-444 I'll do some more structured playtesting of games to see which do / don't work and I'd be happy to pass this info on to you... It would, however, have helped greatly if you had a CD32 yourself. Unfortunately, I cannot donate anyone to you since I'm not parting with mine

I have also a real CD32.
Can you send me a test iso for such a problem? I will check then.

[fisken uno]

Originally Posted by Wepl

I have also a real CD32.
Can you send me a test iso for such a problem? I will check then.

You do? That's wonderful! I'll try to prepare a test iso with a few of the games I have in mind, but I can't promise it'll be today/tonight. I'll let you know when it's done because it would be great if you could enlighten me on what's wrong.

Thanks in advance!