Hi, On a related note, I have successfully replaced the power supply of an 8250LP drive with a very small switching supply bought from ebay for a few dollars. You wouldn't believe how heavy those 8250LP supplies are. Anyway, the replacement supply ouputs 5V @ 2A and 12V @ 2A using the same connector as used on PC floppy and IDE hard drives. If anyone needs info or pictures please let me know. Steve ----- Original Message ---- > From: Wolfgang Moser <womo@news.trikaliotis.net> > To: cbm-hackers@musoftware.de > Sent: Tue, August 9, 2011 2:36:17 AM > Subject: Resending: Repairing a SFD-1001 (8250/LP, 8050, 4040, 3040, 2040) > > Hello hackers, > > unfortunately the first version of this mail article didn't made its way > onto the list, either because of crude formatting or because of using a > news2mail-gateway or both. Now I removed the attachement, please get it > from: > > http://xw15.de/cbmstuff/Universal-Floppy-Dumper-20110807.zip > > > Read on for my first mail, Womo > > -=-=-=-=-=-=-=-=-=--=-=-=-=- > > Hello hackers, > > this article is about my successful repair attempts to resurrect at > least the electronic parts of a batch of SFD-1001 floppies, a 8250LP and > a 8296D. It will be followed by two other articles where I will call for > your help regarding the mechanisms and specific ROM contents. > > In April this year Tommy Winkler released a first version of a firmware > for Nate Lawson's ZoomFloppy (USB connected backend for OpenCBM) with > support for Commodore IEEE disk drives. Because we always planned to > have support for IEEE drives within the ZoomFloppy and already designed > the hardware to support these, I collected some SFD-1001 drives and such > alikes from eBay for two years or so. Most of them were not working or > in bad condition otherwise. For example the 8250LP is missing its top > cover. From a series of auctions where a german sold the bequest of his > father I got some five or so additional SFD-1001 mainboards and an empty > case in mint condition with power supply and metal cage. > > With this I started my repair attempts. Two drives very relatively easy > repaired by only checking the blink codes and swapping some chips more > or less systematically. Since one of these didn't produce sane results, > when tested with the ZoomFloppy I changed the mainboard with one of the > spares and voila, I had two working drives. > I then started with checking all the socketed chips from all SFDs and > the 8250LP and found one defective 6532 RIOT and two defective 6530 > RRIOTs aka 901885-04. A 6530 from one of the drives was missing, missing > 6532 chips could be replaced with chip that I pulled from the spare > mainboards. > > A third drive could be assembled from the spare case with the known good > power supply. One mechanism needed a thorough head cleaning procedure: > 1) getting a tissue, folding it and then placing it between two R/W > heads with the door closed, 2) saturating the tissue with isopropyl > alcohol, repeating the saturation every five minutes and letting it > solve all the dirt at the heads for 30 minutes or so, 3) mechanically > cleaning and polishing the heads with a standard head cleaning diskette > and the recommended procedure. > > For a fourth SFD-1001 drive one of the remaining power supplies could be > repaired as well as the mainboard by getting a last working 6530 out of > the 8296D. Unfortunately I ran out of working mechanisms. I did not make > systemtic checks of all the remaining mechanisms from the SFD, 8250LP > and 8296D since I decided to first work for a solution on another problem... > > > Where to get new 6530 chips? > ============================ > > Answer: Nearly nowhere. As I found out from different discussions it > seems to be a problem for nearly a decade or so to get any replacement > parts for the 6530, especially the mask programmed version for the SFD > and similar drives. As Nicolas Welte pointed out in several such > discussions, the 6530 not only has a mask programmed ROM, but also a > mask programmed logic. This is something that could be compared with > ASICs from manufacturing principles as of today. > > In the SFDs and 8250LPs Commodore did not make use of an own customised > 6530 with a dedicated logic and ROM mask, but reused chip from the older > drives like the 8050. They simply ignored the 6530 internal masked ROM > and replaced it with an EPROM with new contents with the help of a > little adapter board. So this means that the programmed logic gate masks > for the 6530 were all the same or at least nearly identical to be reused > in other floppy types with small external adaptions. > > In all the discussions from above Nicolas and perhaps some other people > also often mentioned that it should be possible to replace a 6530 with a > 6532, an additional ROM chip and some logic to recreate the internal > programmed logic gate mask. One needs "only" to find out about the > concrete implementation of that programmed logic. > > So the way to go for getting 6530 replacements was defined. > > > How to create a 6530 replacement from a 6532? > ============================================= > > Meanwhile, perhaps initiated by these discussions form the past some > others already showed that such an adapter is infact possible to create. > French pinball enthusiasts created an "adapteur" to replace defective > 6530 chips in some Gottlieb Sys1 and Sys80 soundboards for pinball > machines. A german company sounds a very similar board named > "MIOT-Adapter". And finally the Micro-KIM replica of the MOS > Technologies KIM-1 single board computer was created by Briel Computers > and it came with an integrated replacement circuitry for the two 6530s > of the KIM-1. > > Last but not least there is probably the mother of all these existing > 6530 replacement circuits. Ruud Baltissen's "Build your own KIM-1" page > where he described all the oddities about how the create a replacement > for the 6530 by using a 6532, a ROM and some "glue" logic. > > This showed to me that such a replacement must be doable also for the > Commodore floppies. I also was willing to find a way to get a 100% > compatible solution for the "fourth" problem described by Ruud. I looked > out for a way so that the additional 6532 IRQ generation method which > depends on the behavior of PA7 cannot be enabled anymore. > > > But at first the "fifth" difference, "the last and major one" needed to > be solved, "the way the registers ..." of the 6530 "... are selected" in > the Commodore floppy disk drives, namely the SFD-1001, 8250LP, 8296D, > 8250, 8050, 4040, 3040, 2040. > > > Analysing the CBM floppies' memory maps > ======================================= > > From old Funet.FI files (now on zimmers.net) I saw that at least three > people already did investigate the memory map of the floppy disk > controller of different CBM floppies. And they wrote some programs for > this purpose. Olaf 'Rhialto' Seibert described the memory maps both for > the bus controller (BC) and the disk controller (DC) as well of a 8250 > floppy disk drive. He also described a little routine executed as job > code to copy one memory page from the DC onto the shared memory between > the DC and BC. Afterwards standard M-R commands could be used to read > out the contents from this buffer. > > William Levak used a similar routine and composed a memory map for the > 4040 disk drive based on readout results. And then there is Andre Fachat > whose program is not much different to the one from William, but also > provides one which can be used to download the BC's ROM. > > > Except for Williams memory map analysis for the 4040 drive, no > information could be found in the net for all the other drives. > Therefore I investigated memory maps on my own for the SFD-1001 and > 8250LP. I also wrote my own tool which is able to a) read out the whole > adressable 64KiB map of the DC (although actually only unmirrored 16KiB > adress space are adressable by the CPU), b) read out the whole address > 64KiB map of the BC and c) it does /not/ leave the floppy in stuck > condition so that it needs to be reset afterwards. Please find a listing > of the floppy side code as well as a little bash shell script which uses > OpenCBM cbmctrl calls to control the uploaded floppy routine attached to > this article. The shell script should be easily convertable to standard > Basic commands since OpenCBM cbmctrl is nothing else than a simulation > of standard IEC/IEEE commands. > > > Creating a 6530 replacement circuit > =================================== > > With additional read out address maps from all my working SFD drives and > the 8250LP (only the electronics part is working yet) I recognised that > the 6530 internal decoding depends on /CS2, RS0, A6 and A7 only. With > the two existing Chip Select inputs from a 6532, the required glue logic > could be reduced to two NOT gates. One is needed to enable the extra ROM > chip whenever PHI2 is high (same as on the Commodore adapter boards), > the other is needed to invert A6 is 6532-CS1 input while CS2 is > connected with 6532-CS2. To have a more clean design PHI2 should be > NANDed with R/W which is then used as ROM enable. RS0 is used as ROM > output enable while A7 is connected to 6532-RS. > > Above I wrote that I wanted to have Ruud's "fourth" difference between > the 6530 and 6532 be solved. This objective was reached by connecting > 6532-A4 to a fixed high level. That way the described IRQ method cannot > be enabled anymore (check the datasheets). A4 from the 6530 chip socket > was connected with 6532-A6 instead. The latter effectively halved the > 6532's RAM size from 128 Bytes to 64 Bytes. In the end this measure > improved overall compatibility of the 6530 replacement in two points: > supported IRQ methods and RAM size. > > Currently the chosen Flash ROM is 32KiB in size. Smaller ROMs are not > available for reasonable prices. Therefore I decided to pack as much as > possible different FDC drive ROMs into it and make all the banks > selectable by DIP switches. With this it should be possible to support > all drive DOS ROM versions of all Commodore dual CPU drives with only > one final circuit and firmware. Currently I don't know how many such > ROMs do exist, therefore one of the follow-up articles will follow. > > > Supporting SpeeDOS 2K FDC ROMs > ============================== > > Since nearly all TTL chips contain more gates than I needed for the > circuit I tried out, if the 8250/8250LP EDOTRONIK SpeeDOS system could > be supported by an alternative configuration option. And it was possible > by using a 4-NAND gates chip. Switching from 1KiB FDC-ROM support to > 2KiB support means that A10 DIP switch configuration option is lost and > only 16 different ROM images can be supported with a 29C256 chip (or > 28C256, 27C256, ...). When a 27C512 EPROM is used, maybe 32 different > 2KiB ROM images could be used (untested). > > Since the 1KiB/2KiB option could be selected with a pair of jumpers even > mixed 1KiB and 2KiB ROM images could be stored within the same ROM chip, > so I hope that a '256 ROm chip is enough for all existing ROM image files. > > > Current state of the development > ================================ > > In the last months a hand wired prototype was developed, debugged -- > Commodore mixed up PHI2 and R/W in the schematic of the 6530 adapter > board which costed me at least eight weekends of debugging with a mixed > signal o'scope and logic analyser -- then successively extended by the > SpeeDOS option and tested again. Several other circuitry alternatives > were constructed, optimised and tested until the current design was > chose which only needs one TTL chip for the glue logic. No GAL, no > difficult to find exotic components, just standard and easy to get parts. > > Currently only a SFD-1001 drive was tested thoroughly by the replacement > adapter and only from an electronics point of view. I don't know of any > good testing programs that could check, if there remain any > compatibility problems from the replacement. > > I have plans for creating a profesionally manufactured PCB and already > created a layout that fits into a 8250LP and a SFD-1001 as well. I don't > know, if the same design would also fit into the 8250, 8050, 2040, 3040, > 4040 and perhaps some other suitable drives. > > > What else? > ========== > > Before declaring that little project as being finished I would like to > discuss some remain topics with you. The first one is about available > ROM image files about all the different FDC-ROM versions that are > documented by Commodore, but not available up to date (e.g. the FDC-ROM > from the 2040's DOS-1). Please see my follow-up article on this topic > which I will write up the next weekend or so. Next I would like to > discuss options about repairing the mechanisms in the 8250LP and > SFD-1001 disk drives or perhaps options about replacing the mechanism > with a drive from a different manufacturer. To me it would not make any > sense to have a 6530 replacement, when I'm still not able to repair the > mechnisms. > > Maybe, if there is some interest in it and if we find solutions for all > the other top-10 defects for all the old CBM disk drives, then a final > 6530 replacement adapter could by available by the end of the years. But > this would require also that someone else finds a source for 6532 chips. > If the 6530 chips are impossible to source nowadys, the 6532 ones are at > least very hard to find in new and factory packaged condition. > > > > Womo > > PS: If someone else also collected defective CBM drives and was > successful in repairing some of them, maybe there is an option to > exchange some parts. Currently I'm searching for at least five 100 TPI > mechanisms used in the SFD-1001 and 8250LP drives. I would be willing to > give away my original and working 6530 chips and perhaps some other > electronic parts since now I know how to replace them and I already got > some spare 6532 chips years ago. > > -- > ------ to obtain more infos about me, look up the page ------ > ------ http://www.wmsr.de | wm (at) wmsr (dot) de ------ > > > Message was sent through the cbm-hackers mailing list > Message was sent through the cbm-hackers mailing listReceived on 2011-08-09 17:00:12
Archive generated by hypermail 2.2.0.