Return to BSD News archive
From: uhclem@nemesis.UUCP Date: 16 Jul 93 22:10 CDT Newsgroups: comp.os.386bsd.questions Subject: Mitsumi: not that great of a deal Message-ID: <-21066807@nemesis> Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!spool.mu.edu!sol.ctr.columbia.edu!news.kei.com!news.oc.com!utacfd.uta.edu!trsvax!trsvax!nemesis!uhclem Nf-ID: #N:nemesis:-21066807:000:5986 Nf-From: nemesis.UUCP!uhclem Jul 16 22:10:00 1993 Lines: 105 I sent this out the other day but it didn't seem to go anywhere. There has been some discussion of doing a driver for the various Mitsumi CD-ROM drives that can be found all over the place under dozens of different trade names. I realize these things are cheap and the promise of low-cost CD-ROM access is really promising. However, I'll repeat my [learned the hard way] advice again: Beware. Speaking as someone who had access to actual Mitsumi source code and drive specifications, I cannot advise anyone to seriously consider any of Mitsumi's current or earlier CD-ROM drive offerings. By this I mean the clamshell version (push-click-pull tray, raise lid, either 850 or 390 msec versions), or the motorized tray version (seen with BSR plate from DAK or in Tandy VIS system, 1,300 msec (yes, 1,300 msec!)). All of these drives are frequently seen with various brand-name labels on them, including Acer, BSR and Tandy, and can be found for $175 to $299, depending on the shop. Different retailers publish slightly different access times, although it is the same drive, with perhaps a slightly different DOS driver or firmware. The Mitsumi MTBF (mean time between failure) on these drives is listed at under 9000 hours, well below what you would find on any other drive out there. (MPC II spec calls for at least 40,000 hours MTBF.) There are several reasons why the Mitsumu drive has this low MTBF: (1) Brush-style DC motor (remember when cars had generators with brushes instead of alternators?) on the optic transport (some models also have one brush CD motor on the spindle too, which must be equipped with a spin-down-when-idle function to avoid wearing out too quickly) and, (2) they use a rubber band drive belt for optical pick-up transport on some models, and a nylon wormgear on others. (3) some models can only read discs with 63 minutes of data or less. Depending on the model, the firmware has a bug, or (I swear I am not making this up) the cable harness to the optical transport is too short and "can't reach" the areas of the disc above the 63 minute mark. On those crammed-full source discs (Walnut Creek, etc), which can get as high as 74 minutes, this is a BIG problem. And yes, if it's a >63 minute music disc, it screws up too. Some versions also hate to read write-once media. The clamshell model can also damage discs if the door is opened too quickly and the disc is still spinning. This should be impossible with the motorized tray, but every now and then it will open the tray with the disc still spinning and scraping around the tray. There are also numerous firmware revisions, none of them fix all the bugs. Command and functions appear in one and disappear (or quit working in the next.) Finding a single driver that works on every iteration is probably impossible. Mitsumi has not managed that yet for DOS, so a BSD driver that works correctly for all versions is unlikely too. (Watch out for firmware bugs like transferring 5 bytes of excessive data on read requests that exist in some versions.) The DOS driver(s) they provide are a massive joke, obviously written by someone who had never written 80x86 assembly before. Did you know you must always CLC before doing an ADD? And AX is the only register that conditional operations can be done in? Whoever wrote that code thought so. Yes, a new driver won't have these issues, but peeling away all of that trash to get at the code that is actually needed is a big task. These drives provide R-W subcodes (nice feature), but a massive amount of code is required to de-interleave, error correct, and get around bugs in the firmware. If you want CD+G or CD+Kaoroke, you really have to work at it. The drive interface is also pretty efficient, according to the Microsoft benchmark. The motoroized drive had 8% CPU overhead on a 12MHz 286 system, while a popular drive from another vendor had 30% CPU overhead on a 25MHz 486SX computer. The difference is mainly DMA vs non-DMA, with many drives being non-DMA or using strange serial interfaces. Both Mitsumi models can do 150K/sec streaming data transfers, but the motorized version is highly sensitive to ground loops between data, power cables and the frame. The presence of a ground loop can drop the data rate to as low as 23K/sec. This makes sticking it in any old computer a problem. There is also a bug in the Mitsumi firmware (ALL VERSIONS to my knowledge) that if you have a mixed-mode disc (track 1 data, track 2-n audio) and you attempt to read a file or block within about 40K of the end of Track 1, it will get read errors and start playing music out the D-to-A. We had to master all our disc with a large file (or oversized partition ) that was never accessed in the last part of track 1 to avoid this problem. If its just a HS/ISO disc, the dead space is still required or else the drive will get read errors trying to read-ahead into the lead-out area. Of course, how many CD-ROM vendors are going to do this for you? Finally, at last report, Mitsumi still doesn't have a drive that would do multi-session photo CD correctly. Tandy gave up and stopped using Mitsumi drives in Spring 1992 for computers and switched to a LMS (Philips in America) drive. Mitsumi does appear to be trying to improve these models. For example, the difference between the 800msec and <400msec drives is a firmware change(!), and on some models, a different pitch wormgear improves access time. But when you buy one of these drives, you have no idea how long it has been on the shelf and which problems it has. Bottom line, you pay for what you get. :-( Frank Durda IV <uhclem@nemesis.lonestar.org>|"How do I know? I used to beat ...utacfd!nemesis!uhclem (nearest internet) | on these drives, that's how. ...letni!rwsys!nemesis!uhclem | UNIX Driver/Kernel person ...decvax!microsoft!trsvax!nemesis!uhclem | seeking non-DOS opportunities. Saw THE source, but didn't inhale." :-(