Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems running a reA4091 with a BFG9060 at 100MHz #8

Open
jdieguez opened this issue Jun 18, 2024 · 3 comments
Open

Problems running a reA4091 with a BFG9060 at 100MHz #8

jdieguez opened this issue Jun 18, 2024 · 3 comments

Comments

@jdieguez
Copy link

jdieguez commented Jun 18, 2024

Hi!

I'm the proud owner of a A4000D (with buster-11) and a BFG9060 (with a rev6 68060), which run stable at 100Mhz, also with Z3 cards (such as cybervision 64).

Lately I have purchased a reA4091 + ZuluSCSI compact. It works fine at 50Mhz but has a lot of issues when trying to run at 100Mhz. Very seldom, it manages to boot, but more often than not, the zulu does not get recognized at all, I get "Not a dos disk", checksum errors, or the mouse cursor remains in "clock icon" waiting forever for something to happen after workbench loads.

My card came with 42.25 ROM, but I've updated it to 42.29 and I still get exactly the same symptoms.

Also, I tried two different A4000 motherboards, with different buster-11 chips, and got exactly the same results.

I've seen in a1k.org that some people also have issues with this configuration, and for some other people everything works fine. I've opened the issue here because I think this might be down to the GALs.

I attach a picture of the GALs I'm using. Thankfully they are socketed so I could easily reburn them or swap them with different GALs. Some observations about my GALs:

  • According to the part numbers written on the labels, I believe I have almost the latest versions, including the changes related to signal quality (just missing a couple of the latest commits which reduce access time on ROM, and optimize STERM generation).
  • The label on U303 seems to contain a typo (I have U303-02 but the latest version in the repo is U303-01).

So I would like to ask what would you suggest to get the card running properly at 100Mhz.

  • Would it help to re-burn the latest jedecs in my existing chips and try again?
  • Shall I replace the 2 Lattice GALs with ATF22V10C-10 GALs, or are my existing Lattice chips preferred, even if I'm using the latest versions of the jedec files?
  • should I expect any improvements hunting down older (obsolete) versions of Lattice GALs (22V10 / B / C ) or even PALCE22V10H-15JC/4 as used in the original boards?
  • Would it help to ensure that resistors R109E and R109H are 560Ohm instead of 1kOhm?

I'm open to any suggestions / experiments I can do. Any help would be greatly appreciated.

Thank you in anticipation.

IMG_2320

@jdieguez
Copy link
Author

jdieguez commented Jun 20, 2024

I'm going to start doing some experiments.

The original ICs in the Commodore card are

  • U304-01 GAL22V10B-10LJ
  • U207-01 PALCE22V10H-15JC/4
  • U205-02 PALCE22V10H-15JC/4
  • U203-01 PALCE22V10H-15JC/4
  • U306-02 GAL22V10B-10LJ
  • U202-01 PALCE22V10H-15JC/4
  • U305-02 GAL22V10B-10LJ
  • U303-01 PALCE22V10H-15JC/4

My assumption is that Commodore used GAL22V10B-10LJ for the most time sensitive parts and cheaper PALCE22V10H-15JC/4 for all the rest. Acording to (https://www.embeddedrelated.com/showthread/comp.arch.embedded/32832-1.php), these PALCE, while cheaper, seem to be prone to all kind of issues anyway and a Lattice GAL is probably a much better choice:

I picked up some AMD PACLCE22V10's as a cheaper
replacement for Lattice GAL22V10's and had really nasty problems with
ground bounce, metastability, and just general weirdness. I had to
recall all those boards and refit GAL's.

So I'm going to try and use GAL22V10D-7LJ as a replacement for the faster 10ns parts, and GAL22V10D-10LJ as a replacement for the slower 15ns parts. My hope is that these will run just as fine with the BFG9060 at 50Mhz and have a better chance at 100Mhz.

The main difference with your selection is that i'm upgrading all 3 10ns parts to 7ns (U304, U306 and U305 instead of just U306) and that I'm also upgrading the U205 15ns part to 10ns.

My hypothesis why your choice works for some users at 100Mhz and not for others is GAL tolerances (some GALs may be actually faster than what they nominally specify). So I'm going to force them faster.

I also want to avoid using ATMELs at all because the pin-keeper circuits seem prone to cause issues as well (even if they help bringing power consumption down a bit).

Will report back.

@reinauer
Copy link
Member

Hi, Francisco!

Thank you for your feedback! The BFG9000 at 100MHz is pushing the timing limits on the Amiga pretty hard and it is tricky to say whether this is an issue on the A4091, the BFG9000, or your Amiga mainboard.

  • Would it help to re-burn the latest jedecs in my existing chips and try again?

It is doubtful that that will have any impact on the stability running on a BFG9000.

  • Shall I replace the 2 Lattice GALs with ATF22V10C-10 GALs, or are my existing Lattice chips preferred, even if I'm using the latest versions of the jedec files?

We have been going back and forth on the 2 Lattice GALs and in our experiments long term stability was still a lot better with the 2 Lattice GALs than when attempting to run on all ATF chips.

  • should I expect any improvements hunting down older (obsolete) versions of Lattice GALs (22V10 / B / C ) or even PALCE22V10H-15JC/4 as used in the original boards?

Unlikely. I expect the original boards to have the same problems on a BFG9000 @100MHz as the ReA4091.

  • Would it help to ensure that resistors R109E and R109H are 560Ohm instead of 1kOhm?

Where is that idea coming from? What's the rationale here?

So I'm going to try and use GAL22V10D-7LJ as a replacement for the faster 10ns parts, and GAL22V10D-10LJ as a replacement for the slower 15ns parts. My hope is that these will run just as fine with the BFG9060 at 50Mhz and have a better chance at 100Mhz.

Please note that U205 deliberately uses a slower part to make the card function. If you figure out how to make the card work reliably with faster chips, please let me know.

As for testing, please make sure to test stability with the a4091 utility that is part of the a4091-software repository. It can test various aspects of the card as well as run load tests. The cards various builders sold typically survived a few thousand cycles without a crash / hang on an A3000 (which is a lot trickier timing-wise than the A4000)

Regarding the use of ATF parts, our rationale here was that these parts are available new. With Lattice GALs we have occasionally seen relabeled parts that were significantly faster or slower than the timing grade printed on them. Chris' Brutus28 has a method of testing GAL speed grades.

Ideally we would better understand which signal is specifically causing trouble here rather than avoiding pin keeper chips all together.

One possible experiment could also be to connect the VCC pins of each ATF that are currently NC. These pins were unused in Lattice GALs but help with the signal frequency on ATF parts.

Looking forward to the results of your experiments.

@jdieguez
Copy link
Author

Sorry for the delay, it took a bit of time to get the required parts for the experiments.

Well, it's working now. In the end I did not need to change any GALs, just reprogram one of them.

It just turns out that the latest version of U305 (which enables early byte-lane) is not happy with my BFG9060 at 100Mhz.

Reverting this change (ie reprogramming U305 with the Dave Haynie version from https://github.com/A4091/a4091-logic/releases/tag/Rev_B ) solves the problem for me and the card works fine at 100Mhz now.

Pity about the potential 10% speedup that I'm giving up, but I'd rather have the board working at 100Mhz than having to stick to 50Mhz.

If you'd like me to beta test any alternate versions of U305 with my setup, I'd be glad to do so.

Attachment: Picture of the fixed system :)

IMG_2905

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants