Custom ROM & Kickflash problems

[quenthal]

Some of you might remember when I had problems with booting up my A4000. The it was recommended for me to check that turbo is properly connected etc.

I now have isolated the problem to be with Kickflash. Whenever I'm using custom rom with it, there is a chance that my Amiga needs Ctrl-A-A to finish up booting.

The ROM-image itself is not the cause - I've tried rom with minimum number of patches/modules, one with full of patches and updates and everything between. I have thought that maybe the sw I'm using to create these images might be the fault (tools from BlizKick, zapexec, Remus) but all give the same result.
AND all of those images work when softkicking them with Blizkick.

Even though it doesn't happen evertime, it is very irritating.

Currently I'm using Kickflash, but without ROM-image. Instead, I'm using parts of AmigaOS-ROM Updates in ROMU and rest of the patches and modules as external files. This has worked so far (and is even a little bit faster that whole image in flash).

Is anyone else having same issues or is mine Kickflash faulty? I'm using newest fw in it (1.6).

Even though with this configuration it works, I still wonder what might be wrong. And in this form I can't use Piru's exec and unofficial patched versions of console.device and shell, since they cannot be added as external file, only directly in the rom image :-(

[motorollin]

Does it do the same thing if you disable the Kickflash and use BlizKick to load the ROM image from disk?

BTW, you can use Doobrey's Remus utility to insert patches like exec44 etc in to the ROM image, which would mean you could flash them on to your Kickflash.

--
moto

[quenthal]

Umm.. maybe I didn't write it very clear - I've tried it all, and the problem is not with how to use all those patches, the problem is that using rom-image with kickflash there is a chance that my machine won't boot correctly from cold boot without ctrl-a-a. And as I said in the message, with blizkick all those images work.

So to sum it up, when using complete 512kb custom ROM with Kickflash, there might be some problems when "coldbooting". No matter what is in the rom, no matter which software I used to build that rom. With BlizKick they work.

IF, however I don't use ROM-image with Kickflash, and add instead ROM Updates and other patches/modules as files one by one to it, booting works fine. It is just that by doing this I can't use all the modules I wan't (exec44 and few others), because they require to be put inside rom and don't work as external modules.

[motorollin]

Do you have another machine you can test your Kickflash in?

--
moto

[quenthal]

Hmm.. didn't think about that - I'll try it with my another A4000 and report asap.

[quenthal]

Nope :-(

I think have only three options here:

1) wait if CoyoteFlux (makes of software for Kickflash) cleans their public mailbox, get bugreports and update their software

2) use kickflash in this crippled mode

3) get rid of it and get algor pro later this year, which I think has better software and probably more active development

[motorollin]

So the same thing happened in your other A4k?

--
moto

[Doobrey]

quenthal wrote:

 And in this form I can't use Piru's exec and unofficial patched versions of console.device and shell, since they cannot be added as external file, only directly in the rom image :-(

Does CoyoteFlash give you an error when you try and load them?
The patches on aminet for console and shell still leave the files as a standard relocatable hunk file, so they should be able to be loaded in the same way as the unpatched ones.

Also, does all this mean that the ram-handler patch in Remus wasn't the culprit after all? (I double checked it and couldn't see anything obvious with it)

Is it only custom ROM images that cause you problems, or does it happen if you load a normal 3.1 kickstart into the KickFlash too ?

Finally...
 I've just uploaded a new RomSplit archive on my site that might be worth trying if you were having problems with Exec v45.20 (exec needs to be extracted again, and any ROM image rebuilt with it)
 There was a problem with Exec v45 in ROM, and Blizkick rejecting the ROM image.RomSplit now does a tiny patch when exec's extracted (1 instruction changed) to fix it .. maybe the CoyoteFlash firmware has a similar problem?

@Motorollin
  Any news on the 1MB ROM image?

[quenthal]

@Motorollin:

Motorollin wrote:
So the same thing happened in your other A4k?

Sorry, I don't know what I meant with that "nope" in my answer ;-) Just when I thought that testing it in my other A4k would be good idea, I remembered why I didn't do it already - turbo in it is not capable of remapping...

@Doobrey:

Doobrey wrote:

quenthal wrote:

 And in this form I can't use Piru's exec and unofficial patched versions of console.device and shell, since they cannot be added as external file, only directly in the rom image :-(

Does CoyoteFlash give you an error when you try and load them?
The patches on aminet for console and shell still leave the files as a standard relocatable hunk file, so they should be able to be loaded in the same way as the unpatched ones.

No errors from CoyoteFlash (that software probably can add anything without giving errors), it just that if use those as external modules, my machine won't boot - rapid blinking from powerled.

Also, does all this mean that the ram-handler patch in Remus wasn't the culprit after all? (I double checked it and couldn't see anything obvious with it)

So it seems, nothing wrong with it afaik.

Is it only custom ROM images that cause you problems, or does it happen if you load a normal 3.1 kickstart into the KickFlash too ?

I think it happens with every rom image, regardless of patches used in it. And they all work when kicked in with Blizkick.

Finally...
 I've just uploaded a new RomSplit archive on my site that might be worth trying if you were having problems with Exec v45.20 (exec needs to be extracted again, and any ROM image rebuilt with it)
 There was a problem with Exec v45 in ROM, and Blizkick rejecting the ROM image. RomSplit now does a tiny patch when exec's extracted (1 instruction changed) to fix it .. maybe the CoyoteFlash firmware has a similar problem?

Could be - is Algor(Pro)'s flash-program more up-to-date?

Hmm... maybe it is best to get rid of this card... :-( It seems that CoyoteFlux is dead when I tried to reach them a while back:

A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:

  info@coyoteflux.nl
    mailbox is full: retry timeout exceeded

[quenthal]

Argh...

now it did it. I couldn't boot with even with known to work colection of patches without kickstart rom-image. Coyoteflash claimed that the card is write protected even though it is not, and showed garbled text instead of module names. And when  I got rid of that requester after few boots it gave flash erase errors or something like that when trying to write there. Now it again suddenly works.

[quenthal]

 There was a problem with Exec v45 in ROM, and Blizkick rejecting the ROM image.RomSplit now does a tiny patch when exec's extracted (1 instruction changed) to fix it .. maybe the CoyoteFlash firmware has a similar problem?

To clarify a bit my thought around this - Exec 45 worked fine already when used in ROMU-slot in CoyoteFlash (ie. as a part of complete/partial ROM-Update). After your patch I can use it also in a FILE slot as a first module. Piru's Exec44 cannot be used as a module, only if it is written inside the ROM-image before inserted into flash.

Those other patched I told you (shell 45.12, console.device 44.10) work too but it seems that only when I'm using just them and few other patches, but when I start to add more things to flash and try them out, power led blinks few times and I can see that none/only some of the patches really got thru. I'll make more complete research on this behaviour during weekend.

And now I tried with basic 3.1 rom image with kickflash - I'm not sure if it even remapped it at all, or if it did, it did not make any of the usual things during booting. I tried only oen or two times, and during them it worked fine. I just didn't ave the patience to test it further, since I haven't anything in IDE-connectors and it takes so long to see if it works or not... :-)