Page 3 of 4
Posted: Mon Oct 17, 2011 11:55 pm
by ElEctric_EyE
...//dip fan

Posted: Tue Oct 18, 2011 11:22 am
by ElEctric_EyE
Off-Topic: This is one of those morning after moments, where I wonder what I was thinking when I wrote the above

. Sorry, but it doesn't happen too often at least.
On-Topic:
BGA has a problem of heat warpage, balls losing contact and repair capability. Notice how all the newer systems have such issues with their BGAs, creating such joys as the red ring of death....
What systems?
Posted: Wed Oct 19, 2011 6:34 pm
by BigEd
BGA has a problem of heat warpage, balls losing contact and repair capability. Notice how all the newer systems have such issues with their BGAs, creating such joys as the red ring of death....
//dip fan :)
Just saw a link to
baking an HP printer board for 8mins (every 6 months) to keep it functional - maybe that's a poor man's reworking station.
Posted: Wed Oct 19, 2011 9:02 pm
by Dajgoro
I registered and asked for help on the easy68k forum, now lets hope that help arrives

.
If it goes all right, i will be able to use it in my 68k project, and maybe one day in my 6502 sbc...
Posted: Thu Oct 20, 2011 7:34 pm
by Dajgoro
Here are the 68k macros:
http://www.easy68k.com/EASy68Kforum/vie ... php?t=1049, now somebody should make them compatible for the 6502...
Re: 68881 FPU and other FPU
Posted: Fri May 04, 2012 9:03 pm
by Dajgoro
I found that a seller on ebay sells lots of MC68882 in plcc package for just a few $, i was thinking to add it to my sbc.
http://cgi.ebay.com/ws/eBayISAPI.dll?Vi ... 0861459891
Re: 68881 FPU and other FPU
Posted: Sun May 06, 2012 3:55 am
by Dajgoro
I bought two, one for the graphic project, another for my sbc...
Re:
Posted: Mon Jul 02, 2012 4:04 am
by dclxvi
There was a floating point card for the Apple II called the Floating Point Engine that used a 68881. I don't know much about it other than that, though (I don't know how it worked). I read about it in a 1988 (or so) issue of Call-A.P.P.L.E.
For anyone interested, I have dug out the magazine in question. It is the "Programming on the Apple IIGS with APW" article by Mike Westerfield in the June 1988 issue of Call-A.P.P.L.E (pp. 30-36). The article discusses integer, fixed-point, floating-point, and BCD math, and Apple's SANE math library. There are speed comparisons with the Floating Point Engine, but it doesn't really describe how the Floating Point Engine works.
Re: 68881 FPU and other FPU
Posted: Mon Sep 01, 2014 2:15 am
by Rob Finch
The low cost of FPU's on ebay (<$10) has got me wondering (late night musings).
I'm wondering how hard it would be to stack multiple 68882's in order to create a vector FPU. I note that for the peripheral interfacing all the signals except CS/ can be connected in parallel. By sending the same command to all 68882's it should be possible to do vector operations.
Can the pins of an PLCC package be "unbent" and would they be long enough to solder the 68882's into a stack ?
Where's the best place in a 65816 memory map for a block of FPU's ?
Re: 68881 FPU and other FPU
Posted: Mon Sep 01, 2014 5:11 am
by GARTHWILSON
Can the pins of a PLCC package be "unbent" and would they be long enough to solder the 68882's into a stack?
I just tried it with a junk 84-lead PLCC, and it reaches, but with absolutely no overlap, which might mean it would be unreliable, like soldering wires end to end with no overlap (although wires usually have to be able to handle more tug).
Re: 68881 FPU and other FPU
Posted: Mon Sep 01, 2014 7:32 am
by BigDumbDinosaur
Can the pins of an PLCC package be "unbent" and would they be long enough to solder the 68882's into a stack ?
I just tried it with a junk 84-lead PLCC, and it reaches, but with absolutely no overlap, which might mean it would be unreliable, like soldering wires end to end with no overlap (although wires usually have to be able to handle more tug).
I'm surprised none of the pins broke off from being bent that much. Seems like a shaky proposition to me.
Re: 68881 FPU and other FPU
Posted: Mon Sep 01, 2014 8:07 am
by GARTHWILSON
I didn't do all the pins, just one, then put the corner of another PLCC under the corner where I straightened the one pin, to see if it would reach. I think the hard part would be getting all the pins straight enough. Since it barely reached, I don't think I'll be trying the whole thing.
Re: 68881 FPU and other FPU
Posted: Mon Sep 01, 2014 8:22 am
by BigEd
If I were tackling this, I'd consider soldering vertical bare wires to the original "pins" of the PLCCs: I'd put in a millimetre or two of air gap as well, as a nod to heat management.
Cheers
Ed
Re: 68881 FPU and other FPU
Posted: Sat May 30, 2020 1:40 pm
by BigEd
I notice Marten Feldtmann has designed a card to connect a 68882 FPU as peripheral on a Z80 bus - it can only be easier than that to connect to a 6502 bus!
https://schrievkrom.wordpress.com/2020/ ... pfingsten/
I see that PLCC parts are pretty cheap presently whereas PGA parts are expensive.
Re: 68881 FPU and other FPU
Posted: Sun May 31, 2020 10:28 pm
by Chromatix
Indeed, I just read the MC68882 datasheet, and the hardware connections to a 65xx bus look reasonably simple. I don't see any reason why you couldn't attach it to either a 6502 or a 65816.
As shown above, the data bus can be configured to operate in 8-bit chunks, originally for compatibility with the 68008. Just tie /SIZE low, gang all four bytes of the 68882's databus together, and connect all five address lines. The /CS line should be produced conventionally for a 32-byte address range, R/W should be brought directly from the CPU, /DS is just /WE, and /AS is just Phi1.
The only real wrinkle is /DSACK0, which in the 68K bus protocol is used to implement wait states; it is also a line that should be pulled up (gently). Since the 68882 has complex internal processing and operates on an independent clock from the CPU bus (in general, though you can use the same clock for both if requirements permit), the number of wait-states is not predictable in advance. So you'll need to pull RDY low (or stretch the 65xx clock, if you prefer) when accessing the 68882, until /DSACK0 also goes low. I think you can do that by cascading two NAND gates:
So, if either the 68882 is deselected or it has signalled completion, RDY goes high.
I think a 1-chip interface solution - of which only half the chip is even used - is definitely simpler than the Z80 board linked earlier.
One final wrinkle: the 68882 only guarantees TTL signal levels. This is probably fine for a basic system, just something to be aware of.