Using the Falcon's expansion connector

[MegaSTEarian]

Quick update, guys. I haven't done any further development this week whilst waiting for some replacement parts.

If I can get this 32MB version running reliably, I'm I'm thinking of doing an extra revision with two, cheaper, CPLDs rather than one big expensive part.

It'll delay the final version by a spin, but the cost of these is a big design goal for me and having a single part that, if you blow it up, is a quarter the BOM cost is too risky for my tastes.

I've been doing a bit of software work in the meantime which I hope will have a direct connection to the booster, so all's good.

BW

Again a big thanks for all the work you put into this. Thanks!

[Badwolf]

Well another week gone, a completely new board built from scratch with a completely new CPLD.

She ran beautifully for several hours at 40MHz with one of my plastic 030s then, whilst I was sat at my desk renaming some files to boot to a different configuration, the LEDs went out and the screen when black.

That was it. The CPLD had died again.

No shorts detected. The chip was the straightest and best soldered I've managed. I had an additional ground strap as suggested on this thread and yet it's again died in the same way. Works fine for a few hours then gives up.

I can only assume I've something wrong in the firmware that's perhaps inadvertently driving two pins in opposition or something. My first rev3b board is still going strong, happily working at 50MHz with the ceramic, but some of the pins are reassigned on that as it's had some track damage.

I think I'll have one go at replacing this CPLD (tend to ruin the board, TBH) and rebuild the firmware from scratch assigning as few pins as possible as I go. If I kill another then I'll be be assigning Rev3 to the bin and starting work in earnest on Rev4. Perhaps with split bus and RAM CPLDs to distribute risk.

Disheartening in the extreme, but I'm now *absolutely* sure it's not a soldering fault.



BW

IMG_4201.jpeg

EDIT:

Gah! In my annoyance I was careless plugging my working board back in and misaligned the pins. I think I've blown my SDRAM!

EDIT2:

False alarm -- I'd forgotten this board needs a RAM clock jumper on account of it being old and battered (did I mention that?)

[Orion_]

nice board, too bad it didn't last long
I too have always bad luck when trying electronics, I almost gave up :/

[DoG]

Since I can't see, I guess you have all the decoupling caps underneath the PCB?

[Badwolf]

Since I can't see, I guess you have all the decoupling caps underneath the PCB?

Yeah, all caps and resistors on the bottom. Along with the voltage regulator.

I have a fully working one here with the same layout so don't think it's the ground plane, caps or supply, but the first board has some lost pads and broken tracks, so the pinout is effectively different.

I suspect that's the ultimate difference. Perhaps I'm driving a pin with another by accident as the pinout is different. I'll need to build the firmware up from first principles on my next (and final) go.

BW

[dhedberg]

I suspect that's the ultimate difference. Perhaps I'm driving a pin with another by accident as the pinout is different. I'll need to build the firmware up from first principles on my next (and final) go.

First, I know nothing about FPGAs, so excuse me for any stupid suggestions, but isn't there any software that can validate and find out if you do anything harmful to the FPGA before going live?

[Badwolf]

First, I know nothing about FPGAs, so excuse me for any stupid suggestions, but isn't there any software that can validate and find out if you do anything harmful to the FPGA before going live?

It's a CPLD rather than an FPGA, but yes. There are boundary scanning packages that can check for pin shorts and whathaveyou.

Unfortunately I've not found one that isn't thousands of pounds or has a dummy's "please check my pins" button. Willing to be shown one!

BW

[Rustynutt]

There's a positive side, you've not burned up the Falcon

None of this is falling on deaf ears. Knowledge has a unique way to mitigating downward Giving me plenty of thought to chew over.

You may have already stated, what software package are you using for the layout? Assuming it can auto trace, calculate trace impedance and import common IC and socket sizes? Wouldn't a clue as to what to look for. Can the layout you have for the expansion pins be exported? I got as far as CadKey, DOS version

Need to get off my butt and finish an adapter card, basically to sort the mess in the photo, but also to add a few IC's onboard to clean up the Afterburner installation and make overclocking much less messy.

https://1drv.ms/u/s!AqgO-98ycfwZhVs9aMtXtgpqwsbH

[Rustynutt]

A note about the CPLD blowing.
Read a very brief bit about their history and where they fit into on a Wiki page.
May be as dumb as saying all fire trucks are red, so red trucks put out fires

Over the course of years, have "blown" a number of Falcon bus GALs, usually U63. Never looked more into it other than "wow, what an easy fix" and like you keep several spare, a bit less cost

Is there any association of your hardware to those circuits?

Just throwing it out there.

[Badwolf]

Is there any association of your hardware to those circuits?

Just throwing it out there.

The GALs drive some of the logic (eg XDTACK) that I listen to, but that's the same on the working and the not working boards. For the most part it's me driving them.

I've had time to think about it some more and it occurs to me that perhaps the reason I think my ENABLE and DQM0 lines are broken is not perhaps the reason why they are broken.

Perhaps those (adjacent) pins actually failed in the "working" version. A precursor to complete system failure that I've seen on the other boards.

I'm wondering if there's not some cross talk between those two pins somewhere on the circuitboard and when they're active and functional I'm basically occasionally partially shorting to VCC or GND. The ENABLE pin is jumpered to hard VCC or hard GND. It's an input. The DQM0 line is only active when AltRAM is is use, so we wouldn't see the problem in the many hours I spent testing with AltRAM disabled.

It therefore would fit the evidence if, for example, there's a mid-impedance bridge between DQM0 and ENABLE. When DQM0 starts toggling for AltRAM usage, part of the time it's trying to sink a massively increased current. Perhaps this eventually caused the pin to fail on the 'working' version. Problem solved by routeing to a different pin.

On the other versions I've been less lucky and the whole chip has cooked?

I'll try to get a meter onto those two pins on the failed board and see what sort of resistance there is. Should be hundreds of Ohms in circuit. If it's too low, I might have a candidate for the failure & I may be able to simply not use those lines to avoid the problem.

Still, this board is a dead end and it's time for revision 4 either way.

BW

[viking272]

Hey BW,
Great work mate, it's tough going with these blown chips and hopefully you're onto something with your last post. Really interesting project.

[Rustynutt]

Thanks for all the lessons
There's so much more to 68k hardware than "what's in the manual"

[Badwolf]

Cleaned up, metered out.

It's not what I thought. No low impedance between the AltRAM pins or adjacent lines.

Last CPLD on the shelf. What do we think? Should I try one last time and add pins in stages, checking for a hot chip?

The 'working' board runs cool, so any heat would be clue.

BW.

IMG_0310.JPG

[mpattonm]

I am thinking, have you scoped for ripple on 3.3V? Maybe the regulator is just not right type for your application and the ripple kepps killing your CPLDs?

[Badwolf]

I am thinking, have you scoped for ripple on 3.3V? Maybe the regulator is just not right type for your application and the ripple kepps killing your CPLDs?

The output clocks are a bit iffy at slow speed -- will be addressed in the new version, but power lines look OK.

This one works with the same regulator and it's the same regulator used in the TF line of Amiga accelerators.

The difference between the two is is the working version has two lost traces on the bottom left of the CPLD (DQM0 and ENABLE) and has some hacks to the clocks as I was experimenting with termination.

I was thinking to not use ENABLE (I'm deeply suspicious of that ENABLE line even though it all buzzes out) and perform the same clock hacks off the bat.

I don't think Rev4 will use this chip, so whilst it's an expensive gamble, I'm thinking it may be worth it to prove (or not!) a point.

BW

[Badwolf]

The fuller story of the demon rev 4 board is documented over here: https://www.exxoshost.co.uk/forum/viewt ... =29&t=4258

BW

[czietz]

While I cannot offer any suggestion, I'm really interested if you ever find out the root cause of those dying CPLDs. In my experience XC9500XLs are hard to kill. During Storm ST development, I purposefully tried to damage one (as a robustness test in case a customer mishandles the board). Even "crazy" things such as a hard short (output pin driven high but connected directly to ground) sustained over many seconds didn't do any obvious damage.

[Badwolf]

While I cannot offer any suggestion, I'm really interested if you ever find out the root cause of those dying CPLDs.

I'm really hoping it's something startlingly obvious which I'll realise in a head-smack moment.

If I *do* find it out, I'll shout it from the rooftops, even if it's embarrassing.

BW

[mpattonm]

Are you buying them from reputable source, BTW?

[Badwolf]

Are you buying them from reputable source, BTW?

Of the last two that went 'pop' one was from Farnell and one was from a RS. The Farnell one arrived in 40cm box!

I've only got one left at the moment, which is a cut-tape one left over from an early batch I got from a Chinese supplier. So this one might be a bit suspect, but I don't think that's the cause of my ability to knacker these.

BW

[Badwolf]

I've put together a short demonstration video & narrative of progress so far on DFB1.

https://www.youtube.com/watch?v=8jn95nXQBlE

The preferred discussion forum is over at https://www.exxoshost.co.uk/forum/viewt ... f=8&t=4330

Hope it's of interest

BW

How to embed?

[Atari030]

Love it. Frontier is the yardstick I use for testing my machines (CT2b Falcon, Stock Falcon, TT030 and MegaSTE - even the amoebas). I'll have to check the CT2b for a comparison.

I'm enjoying seeing you project come along, mate. Nice work.

[MegaSTEarian]

Cheers Badwolf. Very nice project. Can't wait for it.

[joska]

Looks very promising Will probably buy one if you decide to manufacture a batch.

[viking272]

Looks very promising Will probably buy one if you decide to manufacture a batch.

I'm pretty sure BW said he wouldn't produce any but let others do that? I'm sure he'll be along to confirm.
It looks a great project.