Please enable JavaScript to display the menu.
Building SCSI CD-ROM Driver CDSD.SYS for FM TOWNS with a Dead CD-ROM Drive

I have developed a single driver called YSSCSICD.SYS that can replace CDSD.SYS and CDISC2.SYS!  This new driver replicates some functions that CDSD.SYS + CDISC2.SYS was not emulating correctly.  YSSCSICD.SYS will be able to run more CD-ROM based titles than CDSD.SYS + CDISC2.SYS.  The new driver still requires a boot floppy disk or a boot partition, which is same as CDSD.SYS + CDISC2.SYS, but the new one will save more game titles for FM TOWNS.

Here is a link to YSSCSICD.SYS





I leave the article below for the sake of future reference only.

I recently accidentally won a bid for FM TOWNS 2MX in Yahoo Auction. I was not expecting to win at $300.  I bid for up to $350.  I ended up with winning it for $250. This was the same type FM TOWNS that I was using as my primary computer while I was sophomore year to 1st year into my graduate study.  PC-9081, the most boring PC among three major computers in Japan, had had to go, or Japanese original personal computer culture wouldn't last long.  I tried to help pushing FM TOWNS up to the throne as much as possible by mass-producing free software.  I have been good at making a wrong prediction, but this prediction, Japanese original computer culture wouldn't last long, was unfortunately correct.

The unit I was using then was adopted to my friend when I left Japan.  I wondered what kind of owner was using the unit I've just acquired, and what kind of history this unit was living.

I at least want to preserve some Japanese personal computer history as much as possible.  Now I have FM-7, FM77AV, FM77AV40, FM TOWNS 2F (I thought it was 20F, but turned out 2F), and FM TOWNS 2MX.  FM-7 and FM TOWNS 2F among those were the ones that actually I was using when I was younger.  The condition of FM-7 was not super, but an extremely experienced repair guru of CMU Computer Club fixed a bad VRAM chip and is now fully functional.

I acquired FM TOWNS 2MX from a reliable seller who has a very good knowledge of retro PCs.  And the seller was indicating that its CD drive was functioning.  Unfortunately it was not.  It was partially.  But, the laser output may be weak and it doesn't read CD-Rs.  I keep original CDs in a safe place.  I don't want to pull it out for 2MX.  Also CD-DA doesn't work.  And, CD drive was very unstable especially when reading the outer part of the CDs.

To my shame, although I was one of the co-authors of a book called "FM TOWNS System Setup Guide" but, I am not a hardware person.  I was just thinking if the primary CD drive breaks, I could replace with a standard SCSI CD drive.  I was wrong.  FM TOWNS is using a proprietary Fujitsu drive, and it is not possible to replace with a standard SCSI CD drive.

However, there was a hope.  If I install CDSD.SYS (developed by Mr. Nario Unozawa) and CDISC2.SYS (developed by Mr. Takeo Kato), an external CD drive is recognized as the system CD drive.  Also it can play CD-DA from the external drive.  In short, it was successful.  It worked like a miracle.  My FM TOWNS 2MX recognized Panasonic CW-7502-B.  I am so grateful to the authors of the drivers.

But, to use CDSD.SYS, there is one problem for a general users.  Only source code is available, and you need to build yourself.  The document says the binary is sold.  But, it is sold nowhere.  I would have paid $100 for it.  Even if you find a place where you can buy, probably the driver wouldn't work with your FM TOWNS due to two bugs, which I have fixed and explain below.

This driver CDSD.SYS is beneficial to those who are maintaining FM TOWNS in working condition.  Surprisingly many FM TOWNS units seem to be kept in working condition in the U.S.  Probably due to many high-quality DOS and arcade game ports (and in many cases with high-quality BGM from CD-DA).  I think it is worth explaining how to build CDSD.SYS for those people who has a working FM TOWNS to prepare for the day the CD drive stops functioning.

By the way, although CDSD.SYS source code claims that it is for FM-R/TOWNS, it doesn't work if you try to use with TOWNS OS.  One problem is buffer overflow in parsing CONFIG.SYS parameters.  The second problem is FORRBIOS installation go into infinite loop if you don't connect a CD drive.  But, I'm a programmer.  If there is a source, I fix.  I worked with 8086 assembly for the first time in 30 years.  I fixed it.  The license clause says it is ok to open a fixed source code.  So, you can download it here.

I hear that FM TOWNS is prone to CD-drive malfunction.  I wish I could get a permission from the CDSD.SYS author and open the built binary with some restriction like making it exclusively to FM TOWNS and fixing SCSI ID and drive name.  But, I cannot find a contact of the author.

The authors of CDSD.SYS and CDISC2.SYS have granted re-distribution permission of the source files of CDSD.SYS, and source and binary of CDISC2.SYS.  Therefore I make them available from the following link, too.  This CDSD.SYS source files have been bug-fixed to support FM TOWNS.


Building CDSD.SYS

First of all, you need:

  1. Source files of CDSD.SYS
  2. Build script FMBUILD.BAT
  3. FM TOWNS emulator "UNZ" and a system disk that you can go into command mode.  (Probably any DOS emulator is fine.)  Or, if you have a mean to transfer files to actual FM TOWNS or DOS machine, that works, too.
  4. MASM (I tested with V5.0) or TASM (confirmed with 4.1)
  5. EXE2BIN.EXE and LINK.EXE (I salvaged from MS-DOS 3.1 system disk)
  6. A tool for reading/writing a floppy disk image (Like Editdisk or ImDisk)  If you do it on an actual machine, you don't need it.

The first obstacle is MASM.  It used to be available from Microsoft web site.  Not any more.  I noticed that a set of MSDN discs in the lab were disposed already.  (S**t!  Why I didn't pick it up!)

You need to search.  You only need one file called MASM.EXE.  That's all I can tell.  Maybe in the closet of your college lab.  Maybe in your grand-parents' garage.  Maybe in a used-software shop.  Maybe from eBay.  Good luck. 

Probably EXE2BIN.EXE and LINK.EXE are easier since they can be found in MS-DOS V3.1 system disk.

You can download FMBUILD.BAT from here.  But, if your browser refuses to download a .BAT extension, you can cut & paste from below.



ECHO Assembler not found.



ECHO LINK.EXE not found.
ECHO LINK.EXE must be in UTIL directory



ECHO EXE2BIN.EXE not found.
ECHO EXE2BIN.EXE must be in UTIL directory


cd source

..\util\link cdsd;
..\util\exe2bin cdsd.exe cdsd_xa.sys
del cdsd.exe
del cdsd.obj
copy cdsd_xa.sys ..
del cdsd_xa.sys

..\util\link cdsd;
..\util\exe2bin cdsd.exe cdsd_old.sys
del cdsd.exe
del cdsd.obj
copy cdsd_old.sys ..
del cdsd_old.sys

..\util\link cdsd;
..\util\exe2bin cdsd.exe cdsd_photo.sys
del cdsd.exe
del cdsd.obj
copy cdsd_photo.sys ..
del cdsd_photo.sys

cd ..


Once you get MASM.EXE, EXE2BIN.EXE, and LINK.EXE, the next problem is how to run.  It is a DOS program, and doesn't seem to run from Windows 10 command prompt.  So, you can use a DOS emulator.  In my case, I used FM TOWNS emulator UNZ.  I think any DOS emulator is fine.

Then, use a tool (like Editdisk) to create a disk image with the following directory structure.  Or, create a floppy disk like this if you do it on an actual machine.

    CDSD.ASM etc.  All files from CDSD_SRC.ZIP
    MASM.EXE       I copied only one file MASM.EXE from MASM 5.0 disk, and everything worked.
    EXE2BIN.EXE    Salvaged from MS-DOS 3.1 system disk
    LINK.EXE       Salvaged from MS-DOS 3.1 system disk

By the way, I've confirmed that Turbo Assembler V4.1 creates exactly the same binary.  If you use TASM, replace MASM.EXE with TASM.EXE.  FMBUILD.BAT automatically identifies an assembler you have in the disk image.  You need only one executable TASM.EXE.

Then start UNZ, or a DOS emulator of your choice.  Mount the disk image to the emulator's A drive, and then type:

Q> A:

By the way, if you have problem with jumping mouse cursor of UNZ, try reducing the screen resolution.  On my ThinkPadX250, if I reduce the screen resolution to 1024x768 mouse cursor stops jumping.  Or, when I move UNZ window to my second monitor (1280x1024), the cursor stops jumping, too.

After several enter-key strokes, the build will be over, and you get:


Then use Editdisk or ImDisk to salvage the files.  If you built in an actual machine, you know the files are in your floppy disk.

So, I had three drivers, but I didn't know which one to use.  CDSD_XA.SYS looks to be working fine.  Then, add the following two lines in CONFIG.SYS before BUFFERS= in your TOWNS OS system-bootable disk.


You can download CDISK2.SYS from here.  I made it available from here by courtesy of the author.

And replace TOWNS_CD in MSCDEX line of AUTOEXEC.BAT with CDISC_CD as:


By this modification, when you connect an external CD drive, it will be recognized as Q drive.  Or, the internal CD drive will be recognized as Q drive.  If your internal CD drive is totally dead, maybe no point to use "/D:TOWNS_CD" in CDISC2.SYS parameters.  But, if the internal CD drive is partially alive like my 2MX it may still have a use.  The most importantly, TOWNS OS starts up even when you don't connect your external CD drive.

For those you who are wondering the meaning of the parameters of CDSD.SYS (CDSD_XA.SYS in this case) and CDISC2.SYS, /I6 option of CDSD.SYS lets CDSD.SYS check SCSI ID 6 for the SCSI CD drive, and /D:SCSI_CD creates a SCSI device called SCSI_CD.  If CD drive is not found, this CDSD_XA.SYS will create a device "DISCONN" and the device will always respond with an error.

/D:SCSI_CD and /D:TOWNS_CD options of CDISC2.SYS lets CDISC2.SYS look for SCSI devices called SCSI_CD and TOWNS_CD, and creates a virtual SCSI device called CDISC_CD by /N:CDISC_CD option.  CDISC2.SYS looks for the SCSI device in the order specified in the parameters.  Therefore, if SCSI_CD exists, it uses SCSI_CD, or if not it uses TOWNS_CD.  TOWNS_CD is the default CD drive, or the internal CD drive.

Modifications to the original CDSD.ASM

Although the documentation of CDSD.SYS tells it can be used in FM TOWNS, it doesn't work with TOWNS OS.  Two problems:

  1. Buffer overflow while parsing CONFIG.SYS parameters.  It busts into the next line of CONFIG.SYS and gives a parameter error.
  2. When you boot without connecting SCSI CD drive, the installation of FORRBIOS goes into infinite loop.

The first problem may be specific to TOWNS OS, I don't know about other MS DOS versions.  The DOS version which TOWNS OS is based on terminates CONFIG.SYS string with 00H 0AH, not 0DH.  The original CDSD.ASM is assuming that the line is terminated by 0DH.  It seemed impossible to debug without developing environment.  However, I used the debugger function of UNZ to find this problem.  Once the cause is found, the fix was easy.

Add checks for 00H and just in case 0AH in GetArg procedure.  Modify immediately after GetArg2 as follows:

     ; CaptainYS >>
     cmp al,00h ; TOWNS-OS terminates with 00 0a
     je GetArg9
     cmp al,0Ah ; TOWNS-OS terminates with 00 0a (Just in case)
     je GetArg9
     ; CaptainYS <<
     cmp al,0dh ; CR ?
     je GetArg9
     cmp al,'/' ; Separator ?
     jne GetArg1

With this modification, CDSD.SYS really functions with FM TOWNS.

The next problem was more serious, although you can get away if you always connect your external CD drive.  But, it is not convenient.  Sometimes you may only want to boot with your SCSI2SD keeping your ext CD drive in the closet.

With original CDSD.ASM, if an external SCSI CD drive is not connected, the installation of FORRBIOS (from autoexec.bat) goes into an infinite loop.  FORRBIOS is something to do with FM-R BIOS, and CDSD.SYS uses FM-R BIOS call to identify a CD drive.  My guess is CDSD.SYS is holding on to a BIOS resource and causes FORRBIOS to hang.  I have salvaged a technical documentation of FM-R and FM TOWNS from my parents' place this summer.  But, I didn't find an explanation of the system call issued from CDSD.SYS (AH=0FDH, INT 93H).

Init procedure in CDSD.ASM calls Inquiry proc in BAS-SCSI.ASM, which calls Phase procedure in IF.ASM, which calls ExPhase procedure in IF.ASM, which issues this BIOS call.  It passes a pointer Work_0 defined in CDSD.INC to the SCSI BIOS.  It looks to be the only one BIOS call issued during the initialization.  Probably, this Work_0 connects FM-R BIOS and this driver, the resource kept by the driver.  If I know the way to release this pointer from FM-R BIOS, I can make a cleaner solution, but at this point I cannot.

CDSD.SYS follows steps to abort device-driver installation if it cannot find a CD drive.  Setting zero to Break address, and zero to the number of drives.  Then, DOS will consider the driver didn't exist, and uses the memory space temporarily occupied by the driver for other purposes.  Probably it destroys the BIOS resource.  Then, how about CDSD.SYS pretending to be successful installation, but returns errors for all subsequent requests?  Actually, it worked.

First, replace xor bx,bx in Init8 with:

mov bx,offset Break
call NukeJumpTable

And add a procedure NukeJumpTable at the end of Init procedure as:

; CaptainYS >>
    push di
    push ax
    mov di,offset ComTbl0
    mov word ptr [di] ,offset None
    mov word ptr [di+2] ,offset None
    mov word ptr [di+4] ,offset None
    mov word ptr [di+6] ,offset None
    mov word ptr [di+8] ,offset None
    mov word ptr [di+10],offset None
    mov word ptr [di+12],offset None
    mov word ptr [di+14],offset None
    mov di,offset ComTbl8
    mov word ptr [di] ,offset None
    mov word ptr [di+2] ,offset None
    mov word ptr [di+4] ,offset None
    mov word ptr [di+6] ,offset None
    mov word ptr [di+8] ,offset None
    mov word ptr [di+10],offset None
    mov word ptr [di+12],offset None
    mov word ptr [di+14],offset None
    mov word ptr [di+16],offset None
    mov di,offset IIOCTbl
    mov word ptr [di] ,offset None
    mov word ptr [di+2] ,offset None
    mov word ptr [di+4] ,offset None
    mov word ptr [di+6] ,offset None
    mov word ptr [di+8] ,offset None
    mov word ptr [di+10],offset None
    mov word ptr [di+12],offset None
    mov word ptr [di+14],offset None
    mov word ptr [di+16],offset None
    mov word ptr [di+18],offset None
    mov word ptr [di+20],offset None
    mov word ptr [di+22],offset None
    mov word ptr [di+24],offset None
    mov word ptr [di+26],offset None
    mov word ptr [di+28],offset None
    mov word ptr [di+30],offset None
    mov di,offset OIOCTbl
    mov word ptr [di] ,offset None
    mov word ptr [di+2] ,offset None
    mov word ptr [di+4] ,offset None
    mov word ptr [di+6] ,offset None
    mov word ptr [di+8] ,offset None
    mov word ptr [di+10],offset None
    mov byte ptr [DevNam] ,'D'
    mov byte ptr [DevNam+1],'I'
    mov byte ptr [DevNam+2],'S'
    mov byte ptr [DevNam+3],'C'
    mov byte ptr [DevNam+4],'O'
    mov byte ptr [DevNam+5],'N'
    mov byte ptr [DevNam+6],'N'
    mov byte ptr [DevNam+7],' '

    pop ax
    pop di
; CaptainYS <<

Init endp

With this modification, if CDSD.SYS doesn't find a CD drive, it will reply with None for all the subsequent requests, which essentially returns an error.  It also changes the device name to "DISCONN" to prevent subsequent drivers or MSCDEX to find a failed device.

When an external CD drive is connected, it is recognized as specified in the parameters to CDSD.SYS, or the subsequent drivers and MSCDEX will take it as a non-existing drive otherwise.

These modifications have already done to the source in CDSD_SRC.ZIP

Comments are welcome.  Send E-Mail to: 

Back to