Falcon IC pinouts

[dml]

Having repaired a couple of completely dead Falcons, plus minor repairs to two others I figure somebody else might be able to use this.

One of the repairs involved changing a COMBEL chip. Anyone who has tried this will know it's not a fun job. I had to patch some lifted pads/tracks with Kynar wire also.

A couple of things which made the job 3x harder than it should have been:

1) Really, really bad scan of the Falcon schematics. It's very difficult to read pin and resistor numbers around the COMBEL and some other places. I had to use probes and guesswork in a few cases esp. where tracks were in a middle layer and travelled long distances.

2) The COMBEL chip pinout I found actually has bugs in it - the pins aren't all correctly assigned or indicated. I had to figure that out too.

So here's the corrected COMBEL pinout below (edit of the original mono diagram by M.Ruge). I had to refer to a few of the other chip pinouts from the same page and I saw some problems with those too (esp. the CPU one - missing pin labels), but didn't try to correct them. If you do end up using those, make sure you build a 100% correct pinout using the schematics and probes *before* soldering anything!

combel-work2.png

Note that the input/output/bidirectional arrow indicators are a guess. They might not be correct so don't rely on them.

I can't currently find the page which holds all of the originals but when I dig it up again I'll link it here. [EDIT] It's the "chips 'n chips" .hyp reference by Michael Ruge. There is a well hidden link to an HTML version but Google fails miserably to locate it. now I'm not sure how I located it in the first place.

Last note: If you're going to probe a cold board with a continuity meter, make sure the continuity meter is set to diode test / 'beep' mode, AND that you've checked the voltage it's producing in that mode WITH ANOTHER VOLTMETER. It should not rise above 0.45v (i.e. a gate drop). If it does, you could cook a selection chips just by probing them even with the power off. Be careful.

[kristjanga]

NICE JOB!! and thanks for posting this

[dml]

NICE JOB!! and thanks for posting this

I have some other bits and pieces like this lying around - I'll post more when I get organised Have 2 other code projects still on the go, so no more repair stuff for me for a while...

[Scarlettkitten]

Fantastic work, very useful

[mikro]

I had my fun time with repairing Falcon, too: http://atari-forum.com/viewtopic.php?f= ... 68#p168862

The only difference is that I was the cause why it's not working in the first place :D So yes, I'm with you with the Combel soldering, what a dull work.

[dml]

I had my fun time with repairing Falcon, too: http://atari-forum.com/viewtopic.php?f= ... 68#p168862

The only difference is that I was the cause why it's not working in the first place So yes, I'm with you with the Combel soldering, what a dull work.

Yes looks like you had a lot of fun there. :-z

It took me 3 attempts (in different months, after putting it aside) before I got it functioning. I invented a few new swearwords on the 2nd attempt.

[sporniket]

Hello, sorry for necro-bumping this topic. I stumbled upon it some weeks ago, and I thought that I would make a Kicad symbol ; because I have a little python script that can generate some variation from a nicely structured markdown datasheet.

So here is the datasheet for proofreading,

...and a sample of one of the generated symbols (the one that reproduces the physical layout of the pins),

combel-phy-symbol-draft.pdf

...and the candidate lib file for kicad 5 (remove the 'txt' extension)

falcon_combel.lib.txt

[sporniket]

A little update, with an overview of the 3 types of symbols.

About the printability on a A4-sized sheet, one can see that for such big ICs, it is only possible with the multiple unit version (the demo put all the unit on the same page, but one can also split over several pages). Monolithic symbols require an A3-sized sheet, and thus makes it impracticable for an hobbyist (either a bunch of pages to assemble, or a zoomed pages with too little sized text, requiring a magnifying glass).

FalconCombelRegular.pdf

FalconCombelPhy.pdf

FalconCombelMultiUnit.pdf

[czietz]

Looking at https://github.com/sporniket/kicad-symb ... _combel.md I noticed two things:
- Either the names or the comments for the 8 and 4 MHz clock outputs (CLK8, CLK4) are swapped.
- IACK is actually the interrupt acknowledge towards the MFP.

Sorry for not having time to do a proper GitHub PR for this.

[mpattonm]

Just to remind EAGLE users, you can find library with full Falcon030 HW implementation right here: https://github.com/salacpavel/F030NG/ ./eagle

[sporniket]

Looking at https://github.com/sporniket/kicad-symb ... _combel.md I noticed two things:
- Either the names or the comments for the 8 and 4 MHz clock outputs (CLK8, CLK4) are swapped.
- IACK is actually the interrupt acknowledge towards the MFP.

Sorry for not having time to do a proper GitHub PR for this.

Thanks for the feedback, it's fixed.

Just to remind EAGLE users, you can find library with full Falcon HW implementation right here: https://github.com/salacpavel/F030NG/tree/master/eagle

Good to know.

[Rustynutt]

since 8MHz COMBEL is mentioned (off topic here, bit a good insert point) tested a theory whether or not the 8MHz clock is "insync" with the COMBEL clock out. Judging by the test, there is no correlation between the 16MHz COMBEL CPU clock out, and the COMBEL 8MHz clock.

[sporniket]

Another instance where not having the real thing prevents one to do a simple check, I have some contradictory data for 'pad**' signals between the schematic, the service guide, and the diagram from DML...

Code: Select all

Signal	Schem.	Serv.	DML
================================
PAD0X	138	138	138
PAD1X	73	125	-
PAD0Y	125	73	125 & 73
PAD1Y	111	-	111

So, no problem for PAD0X and PAD1Y, but I am a bit puzzled for PAD1X and PAD0Y...

edit : excerpts from the schematics...

Schematic_G.png

...and the service guide

Service_guide.png

since 8MHz COMBEL is mentioned (off topic here, bit a good insert point) tested a theory whether or not the 8MHz clock is "insync" with the COMBEL clock out. Judging by the test, there is no correlation between the 16MHz COMBEL CPU clock out, and the COMBEL 8MHz clock.

Interesting. On the exxos forum, they recently have measured a discrepancy in the 16MHz clock generated by the latest C301712 STe shifter. If I understand correctly, the Combel now directly receives the 32MHz clock, maybe the logic from that shifter has been copy/pasted into the combel ?

[Rustynutt]

Gotta get me one of those (scope)
Thank you for that link, really helpful with what I was doing.

Was hoping the 8MHz COMBEL signal was gated out the COMBEL the same as the 16MHz out.

Looking at (Steve's) data, it seems to be shifted a bit (they are comparing ST IC's, correct?).

As Exxos states, the specs for the flip flops are all over the place.

Had discovered on the Falcon, slowing the bus (using a 46MHz COMBEL input oscillator) from 23MHz to 11.5MHz allowed for error free floppy and DMA operation.
This however required using a software switch.
This worked regardless type of clock patch, including Exxos double flip flop on this last Falcon patch. Worked just as well without a patch installed.

Tested using the 8MHz COMBEL clock (now 11.5MHz due to the 46MHz main) hoping to get around this, where it failed.

Anyway, read hours and hours Motorola's 68040 Design hand book where it goes into depth with respect to PCB voltage drops and delay due to various trace conditions. It was pretty dry stuff. But best source I've read about PCB material type conductivity and such, with calculations if math is your thing

Back to the ST-Falcon relation.
Looking at the Sparrow daughter cards, one being a CPU/FPU/DSP, and an unseen seperate DMA board, there could be a missing link where the processor boards were utilized on an STe, with the DMA board connected to a Sparrow at a later point.

As the Sparrow is supporting ST video modes, kind of goes to reason this was the direction of the mitigation process of the blitter.

The Sparrows floating around now have a prototype COMBEL in place, with the board much more resembling a Falcon. There also yet remains a 64 pin plcc socket, that I'd assumed was for the STe Shifter, now looking more closely appears to possibly be where the CPU daughter card could of been connected. Rang out a few connections, they among other IC's, connect to the 68030 socket.

Would imagine it possible that what is seen on the scope readings from Exxos site could of been carried forward into the Falcon COMBO. No missing link, just jumped from STe, through the Sparrow, into the Falcon, so to speak.

For my purpose, really need a scope. Was jumping through a (rather long) delay at the DMA input, if the unused 8MHz output on the Falcon COMBEL is skewed, wouldn't of been close to lining up clock edges.

Thanks for pointing this out. At lease think I got it:)

Wish I could get thoughts out in 30 words or less...

[mpattonm]

Another instance where not having the real thing prevents one to do a simple check, I have some contradictory data for 'pad**' signals between the schematic, the service guide, and the diagram from DML...

Výstřižek.PNG

How did you come to this conclusion if I may ask? Did you i.e. verify it with continuity meter? I can verify it on some board, but honestly, it does not make any sense and can not be correct, if you look at the ext. joystick ports schematic as they are hooked to these pins.

[sporniket]

Another instance where not having the real thing prevents one to do a simple check, I have some contradictory data for 'pad**' signals between the schematic, the service guide, and the diagram from DML...

Výstřižek.PNG

How did you come to this conclusion if I may ask? Did you i.e. verify it with continuity meter? I can verify it on some board, but honestly, it does not make any sense and can not be correct, if you look at the ext. joystick ports schematic as they are hooked to these pins.

This is just what is stated in the diagram posted by DML at the beginning of this thread. I guess -I hope- that it's a typo. I have no Falcon to do the checking myself, otherwise I would not bother anybody.

[mikro]

Another instance where not having the real thing prevents one to do a simple check, I have some contradictory data for 'pad**' signals between the schematic, the service guide, and the diagram from DML...

Výstřižek.PNG

How did you come to this conclusion if I may ask? Did you i.e. verify it with continuity meter? I can verify it on some board, but honestly, it does not make any sense and can not be correct, if you look at the ext. joystick ports schematic as they are hooked to these pins.

See DML's diagram above: viewtopic.php?p=235355#p235355

[mpattonm]

Another instance where not having the real thing prevents one to do a simple check, I have some contradictory data for 'pad**' signals between the schematic, the service guide, and the diagram from DML...

Výstřižek.PNG

How did you come to this conclusion if I may ask? Did you i.e. verify it with continuity meter? I can verify it on some board, but honestly, it does not make any sense and can not be correct, if you look at the ext. joystick ports schematic as they are hooked to these pins.

See DML's diagram above: viewtopic.php?p=235355#p235355

Ah yes. Sorry, I must have still been half asleep. I though DML is some kind of source unknown to me.
Anyway, these are traces from actual PCB:
U49 P5 (XPAD0X) -> U56 P138
U49 P9 (XPADOY) -> U56 P125
U50 P5 (XPAD1X) -> U56 P73
U50 P9 (XPAD1Y) -> U56 P111
Perfect match with schematic.

[sporniket]

Thank you, it's fixed.

[sporniket]

Just a follow up : I have merged the source file in the main branch, and I will release a new archive of the generated libraries shortly. I wanted to tweak my generation scripts first, but I have other, more fun things to do in my backlog.

[sporniket]

Here is the symbol for the Combel for Kicad.

falcon_combel.lib.txt

coming from this release