a4091 firmware 42.31 and later issue(s)

[wmaciv]

I spoke with Stepan on EAB, and he was kind enough to burn and send me a current replacement ROM, rev 42.35.

I updated my a4091 mini with the 42.35, leaping all the way from 42.25 I had been using with no issues in my installation, and it immediately showed drive errors on my mass storage device. When I reverted to the old firmware, it worked as before.

My frustration led me to order an XGecu T76 programmer and a set of 5 Winbond W27C512-45Z about the time he shipped me the latest firmware, and learned just how easy it is to create my own ROMs from the file repository here.

I have stair-stepped through all the firmware revisions, the non-CDFS versions, to find out what revision might have changed things.

The last "good" (for me at least) rev. is 42.30, and the last "working" revision is 42.31. Using SpeedGeek and Robert Miranda's RSCP 1.15 for testing, 42.30 give me anywhere between 3.6 to 4.0 MB/sec consistently with 95-98% CPU availability. When I jump to 42.31, transfer rates are virtually the same, but CPU availability drops to 50%, consistently.

All revisions 42.32 and beyond just throw disk errors and dont allow booting from the a4091.

I am using an ACARD 760-B chipset based RaizinMonster from Stratos Technology (ARTMIX), a straight CF-to-SCSI solution. I used one many years ago in my A4000T I owned at the time with great success, usually achieving right at 8.5-9MB/sec with the onboard 53C710 SCSI.

I also have a few ACARD 7720U IDE-to-SCSI adapters based on the same 760-B chipset with varrying firmwares. They behave similarly to the RaizinMonster, as expected.

I have a ZuluSCSI Blaster I will try to run throught the paces next, see if it dislikes the later firmwares or is ok with them.

For right now, I will stick with 42.30, as it gives me the best perfomrance in my setup.

I would love to know what might have changed to cause:

1. The CPU load increase at the jump to 42.31
2. The "break" in my setup at the jump to 42.32

My extended setup is as follows:

A4000D w/Acill reproduciton motherboard (original A4000D riser card)
AmigaOS 3.2.3 KS and Workbench, fully updated, with latest MMULibs and P96 3.2 commercial version
TF4060 w/68060 rev. 6, running successfully at 100 MHz when activated
zz9000 R-4, running 1.13 firmware (no ZIII RAM version)
RaizinMonster CF-to-SCSI w/SanDisk Extreme PRO 32GB UDMA7 CF card (I have also subbed in the ACARD 7720U / CF-to-IDE adpater combo with a couple of Delkin Industrial SLC CF cards, and get the same results, or close enough to be within standard deviation)

If I can be of any help, I would love to participate.

Thank you.

[reinauer]

Can you please test the latest build? I was able to boot on the AztecMonster I got last week with the latest changes.

[wmaciv]

Now boots without problem into Workbench on the RaizinMonster. RSCP now benching at 2.5 MB/sec. but working. Jumping back to 42.30, I am getting just shy of 5MB/sec on Sysspeed2.6 and Sysinfo 4.4 / xsysinfo.

See below for problems with current build and diskspeed reporting:

1. On latest build, SysInfo 4.4 now give an instantaneous drive speed readout of 39 MB/sec. Obviously an error, but was actually scanning the drive and giving a "reasonable" answer on 42.30. I realize all the legacy benchmarking programs have issues, just sharing this for a relative change example. I also tried xsysinfo, and it came back with 28mb/sec

2. On latest build, Sysspeed2.6 makes it through the drive speed checks until it attempts the "RawRead" function, then triggers a checksum error on my OS partition. Assume the RawRead is not liked by the RaizinMonster? I am getting no other errors in common usage so far. As stated above, works as expected on 42.30, making it all the way through the tests.

According to Manabu Sakai, (Artmix), the RaizinMonster is the elctrical twin to The AztecMonster, just in the easier fit 3.5 form factor. How literal that is, I cannot apeak to, but visually, the components are all there. The onboard firmware may differ as well. So far, my Acard 7720U's are all acting in like fashion, so I think we are still dealing with the ARC760-B ASIC peculiarities?

Another issue that has been present all along, seemingly unrelated to any partiular rom revision. When I "cold boot", and the TF4060 goes through its early startup/reboot bootng sequence, the a4091 behaves well. When I perform a warm reboot (cntrl-amiga-amiga), and I am soley using the 4091 as mass storage (nothing on the ehide.device on the TF4060), it invariably brings me to the KS ROM Boing Ball boot screen. I have to perform a cold boot to get the 4091 back into play. I just assumed it was becasue of the mapping of the a4091 rom into ram and subsequent decompression? I seem to vaguely remeber reading something about there being no way around a cold boot because of that? This hapened on all firmware revisions, which is why i'm thinking its just inherent to the setup.

[reinauer]

For the TF4060 situation,... Do you have 128MB or 256MB on the TF? Did you fix the GALs on the Amiga mainboard to deal with the 256MB memory window?

[wmaciv]

I am unaware of any GAL conflicts requiring a hardware fix on the motherboard. Could you elaborate?

What I have done is to set the partition masks to 0X0FFFFFFF per the instructions on alenppc's TF4060 site:

**"A4091/Fastlane Z3 compatibility

The A4091/Fastlane Z3 will work correctly with the TF4060, the only caveat is that you need to set the partition mask value to 0x0FFFFFFF in HDToolBox. This will limit the DMA transfers to the first 128MB, since the A4000 only natively supports DMA access to that region of memory."**

When I enter the recommended mask setting, I make sure and hit return to ensure the setting takes. When I re-enter the settings to see if it took, I find that the OS 3.2.3 version of HDToolbox has "truncated" the setting and visually returns it as 0xFFFFFFF, removing the zero in the thrid position of the hexadecimal string. I have to assume it is functionally the same as what I entered? It has worked this far with no issues I can detect (no Guru Mediation or system lockups).

Thoughts?

[reinauer]

With an unmodified A3000/A4000 you will get corruption during DMA to the second half of the 256MB memory because the system has no idea that that memory lives on your accelerator.

https://github.com/saft6luck/U714_TF4060_GAL

[reinauer]

The Mask instructions might work to mitigate this, but I am not sure about side effects.

[reinauer]

Please try the image from this experimental build

[wmaciv]

Behaving the same for me. Sysinfo still gives outrageous tranfer rate without scanning the bus/drive. Sysspeed still fails at RawRead. I attached the ACARD 7720U, and same profile. The one difference was with the ZuluSCSI Blaster, it did not output a RawRead result on Syspeed, but at least did not throw a checksum error for the drive. For the record, I am using the ZuluSCSI currently in its "legacy" mode as just a SD-to-SCSI device with the SD card partitioned in HDToolbox. I have never set it up with the hdx.img files on a FAT formatted SD card for the microcontroller to translate to the SCSI bus, as intended. Still, it did not return a RawRead value, which all devices did on 42.30, so something is sitll amiss...