Kickflash OS4 problems

[Noster]

Hi,

now it's upt to me to ask for an advice:

Is there anybody that has experiences with a "Kickflash OS4"-Zorro-II card ?

I have bought a new Kickflash OS4 and installed it yesterday in my A3000T (OS 3.9, CyberStormPPC, CyberVision64/3D,...) and have problems getting it to work :-(

After installation I tried to write the drivers to a FFS-formated disk as mentioned in the manual:
"Insert an empty FFS-formated disk into df0:, pressing and holding down the right mouse-button, turning on the computer..."

Nothing happened, the Amiga starts booting (respectively showing the boot-screen, because I had removed my hard-disks for testing) :-(

I tried several times, with and without jumper set, no luck.

After these tests I renounce and decided to use the driver loaded from web. I reassembled my Amiga, powered on WITHOUT pressing the mouse-button and voila: The screen flashed red (no disk in drive). I reinserted the FFS-disk in df0:, reseted the Amiga (without pressing any (mouse)key) and the driver is written to disk, the screen flashes green !?
I retried this, it was reproducable. Whenever I press the right mouse-button during start-up, the Amiga starts as usual, if the mouse-button is not pressed, it tried to write the disk.

Ok -- I thought -- bad documentation, doesn't matters me, I have what I want, let's try flashing the new firmware and the OS 3.9 ROM-update.

I deactivated the Kickflash-card by setting the jumper, booted the Amiga, installed the software (the newer version CoyoteFlash 1.1 from web).

The I started it, backuped the current contents of the Kickflash and added the new firmware (1.2A).
I added the RomUpdate (BoingBag 2) without "Ram-Handler" and "Shell" and added the updated "L:Ram-handler" and "L:Shell-seg".
I saved the image to the flashrom, powered of the Amiga, removed the jumper and repowered the Amiga:

NOTHING, the Amiga boots two times as before :-(

Ok, try again, set the jumper, start CoyoteFlash. It reads the contents of the flashrom, that seems to be that what I've flashed previously, so the flashing itself seems to work.

I tried all available firmware versions and revisions (1.0, 1.2A, 1.2B, and 1.2C) none worked.
I tried to use the ROM-update inclusive all modules without additional modules -- without luck.

I changed the "setpatch" line in my startup-sequence to "Setpatch NOROMUPDATE QUIET" (this should not be needed for the new firmware version), which leads to no reboot on cold-start, but the ROM hasn't been updated.

Yes I've removed the jumper after every flash, before repowering the computer.

It simply doesn't work.


It couldn't be a major fault, because the writting of the FFS-disk has worked (even if the mouse-button hasn't to be pressed) and the flashing also seems to work (firmware 1.2C leads to an endless-reseting loop, I'm not shure but 1.0 seems to lead to an error too, I think I've seen the power-LED blinking several times, before the system starts booting).

Any ideas ? I've written emails to "Coyote Flux" the programmer team and J. Schoenfeld from Individual Computers, but I've no hope that they could help me in the next days...

Happy eastern to all...Noster

[Framiga]

Hi noster,

have you enabled MapRom in the CSPPC?

Try to disable it.

Ciao

EDIT- have you the original Amiga mouse or serial-usb?

[Noster]

Hi

> have you enabled MapRom in the CSPPC?
> Try to disable it.

Have tested with both settings (usually I have disabled it) without any change in the behaviour.

> have you the original Amiga mouse or serial-usb?

I use the original Amiga mouse, I love the A3000 mouse with its unusual design and it works quite good for 12 years now !! (just had replaced one of the switches until now)

I have no USB-hub for the Amiga (no need for it, if I need to access an USB-device I plug it into a Wind#+*? PC and go over the network, but currently I have no USB-device at all, printers are still parallel, scanner and external CDR are SCSI-devices)

Noster

[Piru]

From Amiga® Hardware Reference Manual:

Instead of using the pot pins as variable-resistive inputs, you can use these pins as a four-bit input/output port.  This provides you with two additional pins on each of the two controller ports for general purpose I/O.

If you set the output enable for any pin to a 1, the Amiga disconnects the potentiometer control circuitry from the port, and configures the pin for output.  The state of the data bit controls the logic level on the output pin. This register must be written to at the POTGO address, and read from the POTGOR address. There are large capacitors on these lines, and it can take up to 300 microseconds for the line to change state.

To use the entire register as an input, sensing the current state of the pot pins, write all 0s to POTGO. Thereafter you can read the current state by using read-only address POTGOR.  Note that bits set as inputs will be connected to the proportional counters (See the description of the START bit in POTGO).

These lines can also be used for button inputs. A button is a normally open switch that shorts to ground. The Amiga must provide a pull-up resistance on the sense pin. To do this, set the proper pin to output, and drive the line high (set both OUT... and DAT... to 1).  Reading POTGOR will produce a 0 if the button is pressed, a 1 if it is not.

You have to delay a bit after writing 0xffff to 'potgo' and reading the results back from 'potinp'. If you didn't delay, the button state would be read wrong.

Perhaps the flash is broken here?

[Noster]

Hi

@Piru

I will ask the guys from "Coyote Flux", when they answer to my email.

Jens Schoenfeld has answered my mail (wow, thats really fast) but he said:

> Naja, das Schreiben der Software sollte eigentlich wie dokumentiert
> funktionieren. Gerade weil der Mausknopf ganz ohne Betriebssystem-Routinen
> abgefragt wird ist es doch sehr verwunderlich, daß sich der Rechner so
> verhält, wie Sie's beschrieben haben. Ich hasse es wie der
> Microsoft-Support zu klingen, aber "das kann nicht sein"! Tatsächlich würde
> ich da schon fast nach einem Defekt des Rechners suchen.

Ok, I try to translate:

The writing of the software to disk should work as documented. The mouse-button is tested without the use of operating-system functions, it is very astounding that the computer is acting as described by you (me Noster). I hate to sound like the Micros#+?*-support but "That could not be"! I would almost suppose a defect of the computer.

Oh no, please not :-(

Sometimes I have the problem that the internal diskdrive (df0:) detects a diskchange, while a disk is still in the drive, i.e. the icon of the floppy disappears from the Workbench and the drive reads the disk again without touching the disk at all. I've always thought this is an error of the drive, but could that have the same cause. And what might be the cause ? (The CIAs are ok, I'm shure, changed them when this problem occured the first time).

Noster

[bloodline]

Could be a problem with Paula... and the Interupt system?

[Framiga]

hi,

before to start to think that it is due a Gremlin, start to think from the bottom . . . Flat-cable fault, often underestimated but it can cause a lot of problems, during startup. (often is old as the computer itself)

Ciao

[platon42]

> You have to delay a bit after writing 0xffff to 'potgo' and reading the results back from 'potinp'. If you didn't delay, the button state would be read wrong.

Could be the problem, but Coyote Flux has to look at their code. The Algor/Romulus Firmware even waits for at least 1/50sec to ensure the middle mouse button state is correct.

[Noster]

Hi

> Could be a problem with Paula... and the Interupt system?

Paula is ok ! I've removed Paula from my other (working) A3000T and inserted it into this one and nothing changed :-(

Good luck, I've found the cause for the problem with the floppy-drive :-D

I'm a fool, the problem was my old "noclick"-tool. That's the problem when you use a computer for 12 and more years and never make a complete reinstall ;-)
It always worked to update the system without the need for a complete reinstall (show me a PC from 1992 that runs Wind#+=? XP and never required a completely new setup :-D).
Also if I replaced the harddisks it always works to copy the old installation to the new drive (try to copy a Wind#+?§ XP to another disk and repartition it on the fly -- without the usage of PartitionMagic or something like that :-))

Now that I removed the old "noclick" from startup-sequence and downloaded a new one from aminet the drive(s) work perfect.

But the Kickflash OS4 still doesn't work. Whether the CyberVison64/3D nor the Ethernet-card are the cause (required to remove them to get to Paula). For about 10 minutes I've had a pulse of 180, because I've thought I killed my CV64/3D, because it doesn't worked any more, but simply refitting it into the Zorro-slot managed that problem)

Still searching for a solution....

Noster

[Noster]

Hi,

for those who are interested, I have a productive week behind me. I'm staying in intensive mail-contact to the developers of the CoyoteFlash device driver of the KickFlash OS4 (they are very cooperative) and we have worked out a new version of the driver that will be released soon.

They have made a few changes and I have found the cause, why the software doesn't work in my A3000T. I disassembled the code and made some patches to the drivers code so I found the problem:

The mayor problem WAS the test of the right mouse-button.

@Piru

> You have to delay a bit after writing 0xffff to 'potgo' and reading the results
> back from 'potinp'. If you didn't delay, the button state would be read wrong.

You have been nearly right, but the problem was not the relaying, the problem was that they didn't write to POTGO at all before reading POTGOR :-)
Magically this works in an A4000, but not in a A3000 (and maybe not in the A4000T, they have had problems running the driver in some A4000Ts).

Now my A3000T boots OS 3.9 after power-on within 20 seconds :-D, no more annoying reboots and my Amiga is ready for OS 4.0.

Noster

[Piru]

@Noster

Figured it would be the right mouse button test, I once had similar problems (reading the RMB state properly after reboot) years ago. Reading the amiga hardware reference manual carefully helped here... :-)

Anyway, good to hear it got fixed.