Doesn't work at 40mhz in Q650

[ZigZagJoe]

Hey! Fantastic piece of work. I got one of these off jockelill at VCFMW to play with.

Just as a heads up, it doesn't work at 40mhz in a Quadra 650 (wombat) board. Seems that it will partially read some DeclROM structures into slot manager structures, then the card stops replying and will give bus errors when I try look for its declrom anywhere in $FEFF0000. Most often it just won't show in slot manager at all.

However, possibly the Macsbug looking for ROM methodology may not be a good one, as it seems like the card also goes unresponsive and will bus error at fbIrq trying to read from the card after exiting MacsBug (while at 33mhz).

Replication:

1. Install a jumper/switch at J29 (recommended) to allow swapping between the crystal at G3 (x2) and 40mhz bus speed. Or install a 20mhz crystal at G3
2. Install QuadraFPGA, boot machine
3. No display output; typically not listed in tattletech but sometimes will be seen with partially populated sResources and no board info.

No real need for this to be fixed, more of a FYI, but figured it'd be good to get it written down somewhere :)

[rdolbeau]

40 MHz might be a bit much for the current design. In theory there's no reason why it shouldn't work (40MHz is not a lot for an Artix-7 FPGA), but in practice the lack of proper timing specifications (I still can't figure that stuff out and it mostly work without...) and the low voltage used (the FPGA + CB3T combo only drive the bus to 3.3V, not 5V, though they can in practice reach more than the 2.4V required by 5V TTL) means sometimes the signals don't move quick enough... and then things break. But for now it's fairly 'deterministic': a given device in a given system will work, or it won't.

The IIsiFPGA is known to become extremely touchy (late /STERM causing double-write, maybe more) when combined on a riser with a '882 FPU and a IIsiSEthernet. I wouldn't be surprised if the QuadraFPGA was already borderline at 33 MHz, despite the design passing timings at 40 MHz on the CPU clock. Faster slew/higher drive would help, but then that can cause ringing which isn't great either...

Does it work for you under 'normal' operating condition at 33 MHz? That's the only thing that was tested... As for MacsBug, if you're poking and peeking at the device, it can be quite fragile as there's no protection against access to internally unmapped addresses. Reading from the ROM should be fine. Accessing unmapped addresses (or trying to write to read-only addresses) can cause internal issues that can only be resolved by a full device reset (i.e., rebooting the Mac).

[ZigZagJoe]

I only just got it working last night after finding that 33mhz was required, so I haven't delved in any depth as of yet. Seems fine, though.

Interestingly, simply entering macsbug (@33mhz) and then exiting without entering any command but 'g', it will bus error on the next vblank irq after exiting macsbug. This is with the FPGA set as a second display, as MacsBug has issues drawing on the FPGA screen as primary.

Timing being tight seems plausible since it's clearly reading part of the declrom before the card stops responding @ 40mhz, though it's interesting that it manages to read any of it at all, as you said, usually it's a bit of an all or nothing affair. (when it reads the ROM) the amount it gets before the card stops responding is inconsistent.

Just observations, anyways :) It is good to see this in action as the Pickles source, SuperMario and NubusFPGA were major touchpoints for me as I was writing my DeclROM for 30video.