Two more troublesome HD-installers!

[MethodGit]

Might as well put the pair in the one thread so as to save space...

Yup, encountered a couple more non-WHD installers I wanted to look at that aren't performing very well.

Citadel
Now, the version available on TOSEC has an HD-install program on disk 1. Installation looks simple enough, but the issue is that it'll say on screen "saving configuration to S:Citadel.cfg" (or something along those lines)..... and then just sit there. No disk activity. No further messages. Just nothing. It's like it doesn't know what to do next and it quietly dies out while at the same time not quitting out. I've tried both the English and Polish versions and they exhibit the same problem.

Lotus III
Now, there's this Crimewatch loader for the game (available from Dr Zarkov) that actually installs just great (it uses YADI for diskimaging which isn't a problem at all), it's just that the loader itself seems a bit buggery. No matter what WinUAE settings I specify, both the normal and fast loaders will crash/guru the system after I click out of the CW cracktro. I actually looked at this one years before and couldn't work it out then either. I'm pretty aware that CW was never well known for quality loaders, but pretty much everything else by them I can at least get to load, so I can only assume that this is one of those loaders that doesn't work at all, or which requires a very specific memory configuration. Any ideas?

Ta!

[Retro1234]

Maybe MackHD.library or some other library I cant look for a few days, sure someone will know.

:but yeah the CW installers are quite buggy

If your installing a load of Misc HD installers maybe you could upload them to the EAB file server - New section Misc installs - I might have a few.

[MethodGit]

Just looked at the loaders, and they don't reference MackHD.library or any other odd libraries not already in ROM.

Not sure if it's CW who use MackHD anyhow. Seems like one of those libraries from the really old days of HD gaming.

[StingRay]

Originally Posted by MethodGit

Lotus III
I'm pretty aware that CW was never well known for quality loaders, but pretty much everything else by them I can at least get to load, so I can only assume that this is one of those loaders that doesn't work at all, or which requires a very specific memory configuration. Any ideas?

The Crimewatch loader only works with the AGA fixed version of Lotus 3, any other version won't work since the loader loads and executes the trainer menu.

Originally Posted by MethodGit

Not sure if it's CW who use MackHD anyhow. Seems like one of those libraries from the really old days of HD gaming.

The Lotus loader doesn't use that very library which was made my Mars Bar as well.

[Retro1234]

Originally Posted by MethodGit

Not sure if it's CW who use MackHD anyhow. Seems like one of those libraries from the really old days of HD gaming.

If Ruff N tumble is considered "really" old days of gaming & CW doesnt mean CrimeWatch
http://home.wanadoo.nl/robertoh/misc...umble-Cwuk.txt

Hows about uploading these installs then.

[TCD]

Originally Posted by MethodGit

Citadel
Now, the version available on TOSEC has an HD-install program on disk 1.

Wouldn't trust that version too much (regarding good dump and working HD install). Ask for images of the original disks I'd say.

[s2325]

Remember about quality of polish Amiga games, if game is poor same case can be with installer.

[StingRay]

Originally Posted by TheCyberDruid

Wouldn't trust that version too much (regarding good dump and working HD install).

And why not? The images seem to be perfectly fine!

Originally Posted by MethodGit

Citadel

Assign S: to RAM: and the installation will work.

[Retro1234]

Originally Posted by s2325

Remember about quality of polish Amiga games, if game is poor same case can be with installer.

I think there as worthy of preserving as any ADF that may or may not be 100% - Not in anyway a replacement for WHDload -doesnt even come close by still worth preserving

[TCD]

Originally Posted by StingRay

And why not? The images seem to be perfectly fine!

Because the installed game doesn't work for me. Might be my disk 2 or config of course.

[MethodGit]

Originally Posted by StingRay

The Crimewatch loader only works with the AGA fixed version of Lotus 3, any other version won't work since the loader loads and executes the trainer menu.

What AGA-fixed + trained version of Lotus 3? There's only the plain Fairlight crack in TOSEC.

EDIT: My bad, looks as if I didn't notice the one with [f AGA][t +5] first time round. The readme didn't mention this specific version mind you, just "cracked by Fairlight".

[MethodGit]

Hmmm, the Citadel thing was strange. Assigning S: to RAM: didn't change a thing about my installation prospects as it was still freezing on the saving config line. *However* (and only after much testing through ClassicWB), I decided to create a quick PC folder to boot from, with only a startup-sequence in S telling the system to boot "df0:install", put Disk 1 in the drive, brought up the system menu from holding down the mouse buttons, set it to boot off DH0:, install program comes up, tell it to install in DH0:, and would you frackin' believe it, it installed! (Actually, it's in the middle of installing as I speak, I just paused emulation for the time being to tell you the news. ) So it must be an issue with ClassicWB, or possibly even WB in general.

BTW, found another tricky bugger...

Chase HQ
Galahad's HD patch for this game (also on Dr Zarkov's Domain) doesn't seem to be compatible with any version of the game on TOSEC, nor the original (retail) IPF. Readme doesn't really outright state what version it's designed for, but Galahad mentioned being given the original to work on, so I thought "just go for that then". No dice. GPatch (that which is used to apply the patch file) keeps stating "No matching patches" and fails to create the new image file. Same with every other version I tried. Not too sure what disk Galahad actually worked on now, to be honest.

[Khyron]

Originally Posted by MethodGit

Citadel
Now, the version available on TOSEC has an HD-install program on disk 1. Installation looks simple enough, but the issue is that it'll say on screen "saving configuration to S:Citadel.cfg" (or something along those lines)..... and then just sit there. No disk activity. No further messages. Just nothing. It's like it doesn't know what to do next and it quietly dies out while at the same time not quitting out. I've tried both the English and Polish versions and they exhibit the same problem.
Ta!

Yeah.. I remember this one..
has to be Kickstart 2.X, a '020 CPU (maybe '030).
start the installer and let it fail as usual, next reboot edit the S:Citadel.cfg
and just type DH0: in the file and save it (or whatever you HD partition actually is). put the floppy in the drive, and open a shell/cli and

cd df0:
stack 10000
install

it'll work fine or ( if it crashed on the last disk, just try again, and it usually works.)

you can copy the files it installed to any other machine w/any cpu etc.. and the game will work fine.

to run it..
forget the icon.. from the cli
stack 10000
citadel

and it'll ask you to put in disk 4 (for the save games)

[MethodGit]

Originally Posted by Khyron

Yeah.. I remember this one..
has to be Kickstart 2.X, a '020 CPU (maybe '030).

Strange, I just got it to install on a stock A1200 config (Kick 3.1, 020, 2Mb RAM).

start the installer and let it fail as usual, next reboot edit the S:Citadel.cfg

Now the problem here is that when I was attempting to install it before, the installer would never create this file before freezing.

and just type DH0: in the file and save it (or whatever you HD partition actually is). put the floppy in the drive, and open a shell/cli and

cd df0:
stack 10000
install

it'll work fine or ( if it crashed on the last disk, just try again, and it usually works.)

you can copy the files it installed to any other machine w/any cpu etc.. and the game will work fine.

to run it..
forget the icon.. from the cli
stack 10000
citadel

and it'll ask you to put in disk 4 (for the save games)

So stacking some memory should make a difference, is what you're saying?

[jotd]

oh MarsBar / CWUK are the people that made me starting working HD-installers back in 1995: I could not make their loaders work, not one!

[TCD]

Originally Posted by jotd

oh MarsBar / CWUK are the people that made me starting working HD-installers back in 1995: I could not make their loaders work, not one!

[MethodGit]

Originally Posted by jotd

oh MarsBar / CWUK are the people that made me starting working HD-installers back in 1995: I could not make their loaders work, not one!

I'd imagine they'd have been more problematic back in the day, without emulation on our side.

Incidentally, that Lotus III loader of theirs ain't so bad now that I know which version it prefers. The standard chip-loader (Cwuk-Loader) doesn't seem to like Kick 3.x all that much though. It's more friendly (and more likely to continue into the game) under Kick 2.x. The Fast RAM loader has no such Kick issues.

[Khyron]

Originally Posted by MethodGit

Strange, I just got it to install on a stock A1200 config (Kick 3.1, 020, 2Mb RAM).

Now the problem here is that when I was attempting to install it before, the installer would never create this file before freezing.

So stacking some memory should make a difference, is what you're saying?

I was just going by what I remember, haven't tried to play it in a long time, way back when I tired to install it on my new 4000, and it didn't work, I dug out my 2000 which was an '020 KS2.X/1.3 where I knew I had it installed and just copied the files over.

The increased stack I remember the issue on my 2000, but by the time I moved it over the 4000, I already made a script/iconx to launch it since adding stack= to the tooltypes didn't seem to help it from not crashing on the 1st screen. never tried on the 4000/3.1 to start it from it's original icon.

[StingRay]

Originally Posted by MethodGit

Hmmm, the Citadel thing was strange. Assigning S: to RAM: didn't change a thing about my installation prospects as it was still freezing on the saving config line.

It worked fine for me, I installed to RAM: however which makes all the difference in the world. The file saver/loader routines of the installer aren't particularly good thus the install freezes as soon as it tries to create a file.

Originally Posted by MethodGit

Chase HQ
Not too sure what disk Galahad actually worked on now, to be honest.

I have the original released archive somewhere (Galahad released it with all needed binaries, i.e. no installer needed), will upload it when I find it.

Originally Posted by Khyron

Yeah.. I remember this one..
has to be Kickstart 2.X, a '020 CPU (maybe '030).

Works with Kick 3.x as well, see above why it fails.

Originally Posted by MethodGit

So stacking some memory should make a difference, is what you're saying?

Increasing the stack won't fix anything here and isn't required either.

Originally Posted by MethodGit

The standard chip-loader (Cwuk-Loader) doesn't seem to like Kick 3.x all that much though. It's more friendly (and more likely to continue into the game) under Kick 2.x. The Fast RAM loader has no such Kick issues.

This is not a "chip loader", the difference between Cwuk-Loader and Cwuk-Fast is simply that the Cwuk-Fast version loads the disk images into RAM and patches them, this needs more RAM for obvious reasons but is safer than loading parts of the data on the fly which is how Cwuk-Loader works. Needs less RAM but may freeze or crash the system.

[MethodGit]

Originally Posted by StingRay

It worked fine for me, I installed to RAM: however which makes all the difference in the world. The file saver/loader routines of the installer aren't particularly good thus the install freezes as soon as it tries to create a file.

I see. So really the solution is to either install to RAM: then copy the directory to an HD afterwards, or to create a boot disk/folder and invoke the install program from a startup-sequence.

I have the original released archive somewhere (Galahad released it with all needed binaries, i.e. no installer needed), will upload it when I find it.

Cheers, looking forward to it.

Increasing the stack won't fix anything here and isn't required either.

Neither was assigning S: to RAM: required for the way I did it.

This is not a "chip loader", the difference between Cwuk-Loader and Cwuk-Fast is simply that the Cwuk-Fast version loads the disk images into RAM and patches them, this needs more RAM for obvious reasons but is safer than loading parts of the data on the fly which is how Cwuk-Loader works. Needs less RAM but may freeze or crash the system.

Maybe I should've said "Chip RAM loader" then (apologies), but isn't loading data on the fly precisely how a chip-ram-only HD loader works? (I'm going by the assumption that anything not specified as a Fast loader doesn't require Fast RAM full stop, of course).