A2000 Autoconfig Help - GottaGoFastRAM

[psoma]

Hi all,

Am struggling at the moment with the Autoconfig on a mate's 2000 that I'm fixing (battery leakage). I've installed a GottaGoFast 8MB RAM card underneath the CPU, which works fine, detecting 8MB with no other cards in the system. When I install his HardFrame SCSI adaptor however, it detects fine, but the RAM no longer AutoConfigs.

As per the GottaGoFastRAM instructions (https://github.com/LIV2/GottaGoFastRAM), I've connected the CFGIN pin to pin 8 of U606 but this doesn't seem to make a difference... it still only detects the HardFrame.

Incidentally... if I connect CFGIN to U606 pin 8 *without* the HardFrame card in there, it doesn't AutoConfig the RAM either.

Any help/thoughts would be greatly appreciated!

Cheers,

Tom

[hooverphonique]

I see two possibilities:
1. The hardframe gets configured first, and "steals" the 8MB config space.
2. You have a problem in your config chain - cfgout of the amiga should go to the "first" expansion, then the cfgout of that should go to cfgin of the "next" expansion, and so on.

[LIV2]

Another option for the CFG hookup is to instead connect the GottaGoFast's CFGOUT pin to U606 Pin 13 and not connect CFGIN, this will cause it to be configured first before the HardFrame.
I'd recommend giving that a try

[LIV2]

Originally Posted by psoma

Hi all,
Incidentally... if I connect CFGIN to U606 pin 8 *without* the HardFrame card in there, it doesn't AutoConfig the RAM either.

That's very strange, pin 8 should be low when no cards are installed but it sounds like it isn't, perhaps U606 is busted or the connections to RP607

[thebajaguy]

The problem with under-CPU memory expansions is that AutoConfig tricks must be taken to make things work, and sometimes they break. If you are hacking an A500 with no sidecar expansion (which uses AutoConfig like the A2000), it generally works fine.

When you are in an A2000, the AutoConfig process in the CPU and Zorro II slots is a feature all cards rely on, and cards in the slots do not expect upstream tricks.

You are likely getting a race condition / conflict when the OS sees the 'first card' at the base AutoConfig address ($E80000). Whatever the CPU sees here it tries to configure, and the process is sequential. When there is only 1 expansion, life is good. When there is 2 appearing, you get a clash.

You may have to settle for a different 8M RAM expansion in an actual Zorro II slot here.

[thebajaguy]

An explanation, and a few more thoughts:

The CFG_IN and CFG_OUT pins in expansion slots start at the CPU slot (it's grounded on CFG_IN) and gets bridged with a 74-series logic gate to the CFG_OUT pin. The 74-series logic gates are next to Buster. You see that for each slot's CFG_IN / CFG_OUT lines. The logic gates help the 'low-active' signal hop over any unpopulated card slots. The CFG_OUT line of a card (when it is present) must send VCC (logic-high), keeping cards that follow after it off the bus. The given card stays off the bus until it's CFG_IN line goes logic-low (GND), register info is read by the CPU, it's destination address written to (becomes the card's base address), then the card drops it's CFG_Out to logic-low (GND) to signal the next card to hop on the bus to be read, rinse-repeat for each card.

What is likely happening with the under-CPU expansion is they are trying to sneak in line (there is no CFG_IN / CFG_OUT signals to do it properly) - assuming it is first in line with nothing after, but there is nothing holding the HardFrame card off the bus until the 8M expansion is configured - The HardFrame sees low (ground) indicator on CFG_IN and proceeds to appear on the bus for AutoConfig at the default address. One or both cards is therefore getting read and/or programed (written to) with the same Kickstart board config process. Memory and I/O cards generally go to different places in the expansion spaces.

If the under-CPU memory can be set to the Z2 8M space range of $200000-9FFFFF, but not try to do AutoConfig, you can try to hack it into the memory list later with an AddMem command during startup. I don't know if this can be done on your card, but it is a solution if it allows it. Make the AddMem command the first line in Startup-sequence if this kind of setting is possible with the card. Not as optimal for the various system structures which will end up in ChipRAM before boot, but still better than nothing.

I was re-reading some of the thread - If the 8M memory expansion provides a CFG_OUT signal, then you may try to connect that signal to the CFG_OUT line off the CPU slot (will need the correct pin on the 74xx chip near Buster - I wouldn't mess with the 86-pin slot connector, possibly bending something - see the A2000 Schematics). In theory, this would hold the CFG_IN signal to the first Zorro slot (and all other slots) logic high until the 8M is configured by the OS. This keeps the HardFrame off the bus until the 8M has completed configuration.

[LIV2]

Yes the GottaGoFastRAM board has both cfgin and out, as described in the OP he has connected cfgin of the GottaGoFastRAM board to pin 8 of U606 which normally causes it to be configured after any other board (pin 8 of U606 is the cfgin signal for the leftmost zorro slot)

My previous post recommending to try connecting CFGOUT to pin 13 would instead add the gottagofastram to the beginning of the chain by connecting it to U606 pin 13 this would give it the same priority as a coprocessor card.

In any case the pin 8 connection should have just worked, that it can't find the board when that is connected means that there is some issue preventing the signal from being low as it should. perhaps some issue with the connections between U606 and RP607

While I also designed a 2000 specific board there is no problem running the GottaGoFastRAM board in an A2000 alongside other Zorro devices if hooked up as recommended (and the system is working as expected).

[thebajaguy]

Thanks for the description of what the board offers.

Odd question: Would an 86-pin CPU slot adapter board which gives you access to the CFG_IN (optional?) and CFG_OUT from the slot be a solution in this (mount the card here)? It could guarantee your AutoConfig order as before the 100-pin slots, and jumper lines need not run all over the machine.

[LIV2]

Yeah as a matter of fact some slot adapters such as Sukkoperas one include a pad labelled "copcfg" which can be connected to the cfgout pin of the GGFRam board to add it to the start of the chain.

I also just remembered that I wrote a special firmware that allows it to work with other Autoconfig devices without needing any wires which is available here https://github.com/LIV2/GottaGoFastRAM/tree/snoopy

This fw requires kickstart 2.0 or higher.
Kick 2 & higher query Autoconfig registers twice for some reason, this firmware snoops on autoconfig cycles and enables the board once it notices that no other device is answering the Autoconfig process, it also reconfigures the size of the board so that it will fit even if some other device is using the 8MB address space

The result is that the board can be used in e.g an Amiga 2000 with several other Autoconfig cards without needing any wire connections to cfgin/out

If the OPs Amiga has a compatible kickstart I'd recommend trying this firmware version

[psoma]

Brilliant! Thanks for the insights everyone. I'll try the CFGOUT option as recommended by LIV2... but yeah, I'll do a bit more digging and work out why the signal isn't being pulled low (I want this board to work right, not just work).

That firmware sound great too - I have a Xilinx programmer; if I can't work out what's happening with the Autoconfig, I'll give it a crack (have a 3.1 KS installed). Cheers.

[psoma]

Alrighty.... very interesting!

Connecting CFGOUT of the GottaGoFastRAM to U606 pin 13 worked (thanks @LIV2)! But, then, the HardFrame SCSI card in SLOT 1 didn't. Figuring the AutoConfig may have been clashing with that slot now, I moved it to SLOT 2 and got both working simultaneously - see screenshot from DiagROM below:



Moving the SCSI card to SLOT 3 just for the purposes of diagnostics, I started getting very bizarre and unpredictable performance, and then in slots 4 and 5 it failed to autodetect entirely. This at least explains why the CFGIN from the leftmost slot wasn't working.

So... I'm thinking we have eroded traces, which given the original state of this board is not unsurprising. Unless there's another common reason I'd be experiencing this sort of behaviour?

Cheers,

Tom

[thebajaguy]

AutoConfig lines run to some 74-series logic near Buster to be able to jump empty slots.

Data and Address lines are common across all 5 slots. The A2000 schematics are online. Rev 4.x and Rev 6.x are effectively the same between the ChipRAM buffers to the right of the ROM over into to the expansion area.

[psoma]

Originally Posted by thebajaguy

AutoConfig lines run to some 74-series logic near Buster to be able to jump empty slots.

Data and Address lines are common across all 5 slots. The A2000 schematics are online. Rev 4.x and Rev 6.x are effectively the same between the ChipRAM buffers to the right of the ROM over into to the expansion area.

Yep, and it turns out that's where the issue was. Pin 1 of U606 was meant to be going down to the CFGIN on CN604 but the trace had been purposefully cut at some point (for some reason) under U606. That fixed up both the slots and the AutoConfig issue I had originally raised, but the machine is still a little flakey. It boots off the drive OK, but gets random data read and Guru errors. I think this is more likely due to replacing some 74F245s with 74HC245s but we'll see.

Thanks for all your guidance/knowledge... got me sorted!

[cpiac64]

i have found some memory zorro2 working on slot and some memory not working in the same slot, because battery leakage have break a connection on slot zorro2 unused on some fastram

verify zorro2 connection to cpu

[psoma]

Actually - turns out this is a B2000-CR Rev 4... do I need to apply the various fixes from here: https://pastebin.com/CR7WBXxW to get this thing running stably using a SCSI Zorro card?

[LIV2]

I'm not sure if the fixes will fix your problem but you should apply them yeah.

IDK if the 245's are the issue but 74HCs are going to cause problems as they don't have TTL compatible IO levels and are extremely slow compared to 74F, I would recommend putting 74F's in U103 & U105 or maybe 74AHCT would work too.

[psoma]

Applied... but you're right - it didn't fix the problem (didn't make it worse at least )

Have ordered a couple of 74Fs. It *was* U103 and U105 I used the HCs on... thought they might have been OK, but I should have learned from previous experience that if it's an F when the board has HCs and LSs, then it's an F for a reason (no way Commodore would use anything more expensive than they had to :P)

[psoma]

OK, popped SN74F245Ns into U103 and U105 but I'm still getting random (but frequent) #8000000B errors on disk access.

Any other thoughts as to what might be going on?!? System is otherwise stable if running stuff off floppy... it's only when using the SCSI HDD through the HardFrame (which appears to be terminated correctly)

[hooverphonique]

Originally Posted by psoma

Any other thoughts as to what might be going on?!? System is otherwise stable if running stuff off floppy... it's only when using the SCSI HDD through the HardFrame (which appears to be terminated correctly)

I don't think incorrect termination should cause gurus if you just copy the data around (without evaluating or executing it), so try and see if that makes a difference.

[thebajaguy]

Give the Hardframe's card edge connector a good cleaning with isoproply alcohol and a toothbrush. Same for any other cards in the Zorro bus. I cleaned up some instability on some systems recently that way.

A slight lift and re-seat of any DIP socketed chips on the card(s) might also help. Leave the PLCCs alone, although check them for cracks just in case.

The rev 4.x updates to Rev 4.5 - I would address Buster (if not MOS), Gary (if not MOS), and any parts they mention around the 74-series buffers. The rest is usually not critical unless a problem is seen.

Try also moving the J300 under the PSU area to the right - a dirty Tick signal from the PSU (possibly from aged caps, messy AC frequency) can cause some oddities sometimes, and this moves the clocking away from that. This position is used for ATX replacement PSUs that have no tick signal.