Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA1762 ; Tue, 23 Feb 93 14:56:53 EST From: uhclem@nemesis.UUCP Date: 19 Feb 93 23:25 CST Newsgroups: comp.unix.bsd Subject: Re: Orphaned Response Message-ID: <-13547388@nemesis> Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!sun-barr!cs.utexas.edu!news.uta.edu!utacfd.uta.edu!trsvax!trsvax!nemesis!uhclem Nf-ID: #R:<C2CouK:33:nemesis:-13547388:000:3119 Nf-From: nemesis.UUCP!uhclem Feb 19 23:25:00 1993 References: <33@<C2CouK> Lines: 57 <> [0]Are those cheesy CD-ROM drives DAK is selling for $200 functional and usable [0]on a BSD system? If it is a caddy-less drive and it looks a lot like the one in the Radio Shack catalog (last DAK catalog I got this was the case), then this is a Mitsumi drive, which has a DREADFUL programming interface. I have seen the source code Mitsumi produced for the DOS driver, which is a whopping 350+ pages, and is quite possibly the worst code I have even seen. (These guys would have flunked my assembly course while still registering for it.) Seems the programmer didn't actually know 8086 assembly, but was familiar with 8042s. So a lot of work is done exclusively in AX when it doesn't have to be, the carry flag is usually cleared before an ADD instruction (NOT an ADC instruction!), unconditional jumps to jumps, etc. Looks a lot like code emitted from a really bad C compiler with no optimizer, but it was really written that way. Since there is no publicly-available command set spec for the drive, examining the existing code to determine the drive programming has to be considered. Apart from the code being bad, a lot of things that you would expect the drive to do are handled by the driver, so you have to have code in there to do some ECC and other nasties. It also has some interrupt and command timings that are somewhat critical and not very forgiving, which may be a problem in a multitasking world. Now, if the driver can run spl7() all the time... On the other hand, the 16-bit version of the Mitsumi interface is very efficient on CPU usage, taking about 8% of the CPU on a 16MHz 286, compared with 30% of a 486SX-25 for the caddy-less LMS (Philips) CD-ROM drive. The Mitsumi drive (if its the same as the RS version) also provides subcodes (CD+G or CD+MIDI), but the driver has to deinterleave and ECC them. A *nix driver could be written for this drive, but there are far simpler implementations out there to deal with. I have thought about doing one since the drives are so cheap, but not real hard. Also, some of the Mitsumi drives have trouble reading certain brands of write-once media, so if you have any of the gold/green discs around, this may be an issue with you. FYI, The last firmware I saw could not read single or multi-session Photo-CD either. One other thing to remember: The drive RS sold was a 650-800 msec drive. Mitsumi changed a worm-gear, driver and firmware to speed it up (somewhere in the 350-500 range if I recall), but in the process broke something so that many of the MPC CD-ROM apps you ran on it got UAEs or GPFs. The party who was interested in the speed improvement gave up on Mitsumi and switched to another vendor. A short time later, DAK got a great deal on some Mitsumi drives. Got it? Frank Durda IV <uhclem@nemesis.lonestar.org>|"How do I know? I had to beat ....utacfd!nemesis!uhclem (nearest internet) | the code for its lower-cost ....letni!rwsys!nemesis!uhclem | brother into marginal ....decvax!microsoft!trsvax!nemesis!uhclem | functionality. The sign he holds up says "Tainted by the source... Cannot work for food."