|
[ I am writing this to preserve historic Japanese computer called FM TOWNS. Please feel free to copy this information to anywhere. ]
If you have a FM TOWNS unit which is in perfect health except a broken internal CD-ROM drive, you may be able to play your CD-ROM based FM TOWNS games with this driver from an external SCSI CD-ROM drive. You need a boot floppy disk or a boot hard-disk partition, but that is easier to find than a replacement internal CD-ROM drive.
Fujitsu FM TOWNS made a history in Japanese PC scene in 1989. Unfortunately, the population of FM TOWNS units in working condition is decreasing. But, I believe it is worth preserving such a historic computer. I learned programming with Fujitsu FM-7, FM77AV, and FM TOWNS. I want to do my share in the preservation of those historic Fujitsu Micro computers.
The biggest impact of FM TOWNS was (1) first-in-the world computer that had a CD-ROM drive as a standard equipment, and (2) made 80386 native mode available to general public users by bundling PharLap 386|DOS Extender. However, very unfortunately FM TOWNS was born too early, and it was before SCSI or IDE standard for CD-ROM drives were made. Therefore, the internal CD-ROM drive is proprietary, and the protocol is not published. Pin-out is totally different from any other CD-ROM drives. Once the drive is broken, it is virtually impossible to find a replacement.
Miraculously, two device-drivers, CDSD.SYS and CDISC2.SYS were available, which redirects internal CD-ROM to external SCSI CD-ROM. But, the license term of CDSD.SYS tells it is ok to redistribute source code, but not binary. We cannot find a binary anywhere today. Anyway, CDSD.SYS was bugged and did not support TOWNS OS, although the developer claimed it supported FM TOWNS. I debugged it. But, all I could do was to post a corrected source code and build instruction. It was not too easy for an FM TOWNS user to actually build it. CDISC2.SYS had its own problem, and was not emulating CD-ROM BIOS call too well. Many game titles froze due to issues.
This time, I have developed a new driver YSSCSICD.SYS. This single driver does the same job, actually a better job, than CDSD.SYS + CDISC2.SYS. I have fixed the bugs and incomplete emulation of CDSD.SYS and CDISC2.SYS. I have already tested some game titles that did not work from external SCSI CD-ROM drive now work with my new driver.
Another problem in booting from a floppy disk into a system in the CD-ROM was the boot drive cache. FM TOWNS users knew that the system was caching the boot drive somewhere. But we didn't know where. What had been happening was, when you boot from a floppy disk, and CD to Q drive as soon as MSCDEX enables Q drive, and start TMENU.EXP from there, TMENU.EXP still look for some files in the floppy disk, and did not fully functional. This time I finally figured where it is cached. I have developed a program called SYSDRV.EXE. If you run this program at the beginning of AUTOEXEC.BAT, you can change the cached system drive to anywhere (by default it will be changed to Q). Well, it turned out Towns OS V1.1 was detecting the system drive in a different way from Towns OS V2.1. I also figured it, and SYSDRV.EXE takes care of it. You can boot from floppy disk into Towns OS V1.1 or Towns OS V2.1 in the SCSI CD-ROM drive.
I really appreciate developers of CDSD.SYS and CDISC2.SYS for opening the source code.
INT 93H AX=01C0H was not returning the drive mode in DL. Fixed the issue.
On INT 93H AX=05C0H CH=0FFH (Direct Read to Physical Address), I was reading to the buffer in the real-mode memory and then using unreal mode to transfer data. In this version, I directly issue SCSI command and use DMA to read data into the physical address. Since data-buffer is unnecessary, the size is reduced to less than 7KB.
Fixed total time returned from ReadTOC. YSSCSICD.SYS now supports Operation Wolf. Operation Wolf was checking first 5 bytes returned from ReadTOC to check if the CD was authentic. YSSCSICD.SYS was subtracting 2 seconds (150 frames) from the duration returned from SCSI. Operation Wolf identified it as a non-authentic CD and was refusing to start.
Now YSSCSICD.SYS emulates INT 93H, AH=05H/15H, CH=0FFH (read sector to low-4GB physical memory location). With this update, RAYXANBER can start with V1.1 L30 boot floppy disk.
Wing Commander BGM plays! It was a tough one. Wing Commander was setting its own hardware IRQ handler, which was using a buffer used for communication between 32-bit mode and 16-bit mode. When YSSCSICD.SYS got a command for play CDDA, it was first checking the drive status. The SCSI command for checking drive status also fired an IRQ to the Wing Commander's own IRQ handler, which destroyed the buffer. When YSSCSICD.SYS read from the buffer for CDDA starting and ending time, the data was gone by then. Now my driver caches the starting and ending time before checking the drive state. By the way, you need to start from V1.1 L30 boot disk into Wing Commander CD-ROM, or if you run from Towns OS V2.1 floppy disk (assume it is in A drive), start as:
Q: A:RUN386.EXE WC.EXP savepath=a: +m kanji
If you want to start in the English mode, remove "kanji" option.
Actually, "DEFAULT DRIVE" of DOS turned out nothing but the current drive. I thought DOS was caching where it was booted from. I guess I didn't have to make SYSDRV command after all :-P
Integrated SYSDRV.EXE and SYSINIW.EXE in YSSCSICD.SYS. By writing in CONFIG.SYS:
DEVICE=\YSSCSICD.SYS /D:Q
you can change the system drive to Q (CD-ROM drive). Also by writing:
DEVICE=\YSSCSICD.SYS /M
SIDEWORK.EXE and SYSINIT.EXE will show messages.
Better emulation of functions 57H and 58H. Also added SYSDRV.EXE and SYSINIW.EXE.
I realized that specifying /R option in CONFIG.SYS to enable RS232C debugging was risky. If this option is specified and if nothing is connected to RS232C port, the driver freezes. (You need to connect something to stop freeze.) Rather, I dropped CONFIG.SYS options and use ECHO command to enable/disable debug outputs.
RS232C Debugging Enable
ECHO R > CPTYS_CD
RS232C Debugging Disable
ECHO r > CPTYS_CD
Console Debugging Enable
ECHO V > CPTYS_CD
Console Debugging Disable
ECHO v > CPTYS_CD
First Success! First Release
I haven't played all the way, but at least confirmed that the game play starts. Some requires a special boot floppy disk.
(*1) This requires mouse. If you want to run it on 486DX and newer model in the FAST mode, copy V2.1 L20 TBIOS.SYS and TBIOS.BIN to the V1.1 Boot Disk.
(*2) Due to copy protection, insert V1.1 Boot Disk in the B drive, insert Augusta Program/User disk (copy protected) in the A drive, and boot from the B drive. If you know how to unprotect SETUP.EXP (which is not too difficult) you can copy all the files in the Program/User disk to the boot disk, to make a boot disk dedicated for Augusta.
(*3) Requires Towns OS V1.1 disk with V1.1 TBIOS. V1.1 disk + V2.1L20 TBIOS causes MOS_start function to fail. 486DX and newer model (maybe 486SX as well) needs to start in the compatible (or slow) mode. Boot from B drive while keeping the user disk in A driver, or boot from A drive and replace the disk in the A drive during the title screen. You may be able to copy data files in the user disk to the boot disk.
Source and Binary from GitHub -> https://github.com/captainys/FM/tree/master/TOWNS/YSSCSICD
(A) If you no longer can start Towns System Software V2.1 L20
Burn this disk image to a floppy disk. You may try this method.
(B) If you can still start Towns System Software V2.1 L20 but want to create a boot disk to prepare for CD-ROM Malfunction
CONFIG.SYS
SHELL=C:\COMMAND.COM C:\ /P DEVICE=\SYS\CTL.SYS DEVICE=\TBIOS.SYS /TBIOS.BIN /D DEVICE=\TOWNS.SYS DEVICE=\SYS\OAK0.SYS DEVICE=\SYS\OAK1.SYS /S0 /H1 /K0 /R0 /M3 /B1 DEVICE=\YSSCSICD.SYS /M /D:Q BUFFERS=8 FILES=20
AUTOEXEC.BAT
C:MSCDEX /D:TOWNS_CD /M:8 /L:Q Q: AUTOEXEC.BAT
Burn this floppy disk image to a disk. I hope you can use this method.
(This disk image for TownsOS V1.1 with V2.1L20 TBIOS.)
There is a good reason why you may want to start V1.1. You want to play Wing Commander, don't you? I totally understand!
But, the process is a little bit tricky. Also I am guessing you are not supposed to change the DOS Default Drive inside CONFIG.SYS. So, you need to use SYSDRV.EXE at the first line of AUTOEXEC.BAT.
Follow the steps below.
CONFIG.SYS
SHELL=C:\COMMAND.COM C:\ /P DEVICE=TBIOS.SYS /TBIOS.BIN DEVICE=YSSCSICD.SYS /D:Q BUFFERS=8 FILES=20
AUTOEXEC.BAT
SYSDRV.EXE C:MSCDEX /D:TOWNS_CD /M:8 /L:Q Q: AUTOEXEC.BAT
Good thought! You should make boot floppy disks and keep them in a ziploc and store in a cool dry place with silica gel.
Just create a disk with CD PLAYER from Disk Format menu, and then jump to Step 7 of Situation (B).
(1) Insert the boot floppy disk in Drive A.
(2) Connect your SCSI CD-ROM Drive to FM TOWNS and insert Towns System Software of the matching version CD-ROM.
(3) Turn on FM TOWNS with F and 0 keys held down. 0 key must be on the full key side, not on the num pad. Keep the keys down until it starts booting from the floppy disk. Or, you can also keep the A button of the game pad until it starts.
If CDISC2.SYS wanted to redirect internal CD-ROM BIOS calls to SCSI CD-ROM BIOS calls, it shouldn't need CDSD.SYS. Then, why did the developer added a dependency on CDSD.SYS, which was bugged and didn't run with TOWNS OS? (By the way it apparently ran with MS-DOS for TOWNS, not TOWNS OS. I debugged it) I could imagine two reasons. Actually three. The third one is weak.
If your FM TOWNS is healthy, and when you access your CD without a redirector, the control flow is something like this:
MSCDEX -> TOWNS_CD -> CD-ROM BIOS -> Internal CD-ROM Drive
If you are able to replace this CD-ROM BIOS with something that talks to an external SCSI CD-ROM drive, you are done. Theoretically, MSCDEX and TOWNS_CD won't be aware that it is accessing an external CD-ROM drive, and works just fine. However, while reading disassembly of the CD-ROM BIOS, I noticed that there are unpublished functions AH=0FCH, 0FDH, 0CH, 0EH, 0FH, 10H, 11H, 56H, 57H, 60H, 61H. Among them, 0FCH, 0EH, 0FH, and 61H are used from TOWNS_CD. Actually 11H is also used, but only when power off the computer, so it doesn't really matter. I suspect that the developer of CDISC2.SYS might have tried a simple method, just replacing CD-ROM BIOS, but in the process he realized TOWNS_CD driver was using some unpublished functions, and gave up with the simple method.
Another problem was the method for accessing a SCSI CD-ROM drive in FM-R and TOWNS were not published. CDSD.SYS was using an unpublished function INT 93H AH=0FDH AL=0BxH. Or, you need to directly read/write I/O ports. I have a book Official Technical Manual for Fujitsu FM-R Series (Edited by Interblog, BNN, 1989). It didn't list that function. The developer of CDSD.SYS should have an insider contact. Otherwise I don't think there was no way of outsiders to know how to use this function. Probably the developer of CDISC2.SYS didn't have an information of this unpublished function, and might have thought it makes more sense to use CDSD.SYS rather than to implement own SCSI BIOS calls.
The last but least probable problem was two functions that 80186 real mode could not implement. FM TOWNS's CD-ROM BIOS function AH=05H or 015H CH=0FFH will writes to anywhere in the low 4GB memory space. How can a real-mode BIOS do it? DMA. DMA doesn't know about real mode or native protected mode. It just writes to anywhere in the RAM. But, it cannot be emulated by 80186 CPU instructions. Since MSCDEX is a MS-DOS module, it was extremely unlikely that MSCDEX will request TOWNS_CD driver to copy data to high memory, we never knew if TOWNS_CD requested AH=05H/15H CH=0FFH. If that happens, it's over. There is no way of saving it. But, if CDISC2.SYS takes over both TOWNS_CD driver and CD-ROM BIOS, there is no worry about those two functions.
I don't know exactly what the developer of CDISC2.SYS was thinking. But, CDISC2.SYS does two things:
Therefore, in CDSD.SYS + CDISC2.SYS environment, majority of the file-access will be processed like:
MSCDEX -> CDISC2.SYS -> CDSD.SYS -> SCSI CD-ROM Drive
In this flow, since TOWNS_CD driver is not involved, there is absolutely no chance that high memory access become necessary.
The rest is to redirect FM TOWNS CD-ROM BIOS calls for CDDA to SCSI function calls. It is done by converting the request to MSCDEX style, and then redirecting to CDSD.SYS.
Unfortunately, CDSD.SYS had too many bugs. The biggest one was it was not really supporting TOWNS OS. Apparently, it worked with MS-DOS for FM TOWNS, but not with TOWNS OS. So, I don't think it was appropriate for the developer to say CDSD.SYS supported FM TOWNS. That was a false advertisement. I debugged it and made it support TOWNS OS. Also the interpretation of the return code from the SCSI BIOS in CDSD.SYS was not correct. It missed errors, namely Media Changed error. It didn't sense CD change. Worse, since its license term didn't allow redistribution of binary, all I could do was to upload corrected source and build instruction, which was very difficult to follow for ordinary FM TOWNS users.
CDISC2.SYS had its own problem, too. INT 93H, AH=52H, CH=0FFH, play CDDA with repeat, cannot be translated into SCSI2 command because SCSI2 does not support repeat. However, the best thing it could do was to play once, and let it go. Instead, CDISC2.SYS was returning ERROR. A lot of VING games including Splatter House and Kyukyoku Tiger was freezing due to this issue.
The new driver, YSSCSICD.SYS, simply replaces FM TOWNS's CD-ROM BIOS. To make it work, I needed minimum two unpublished functions 0EH and 0FH, which I read disassembly of FM TOWNS CD-ROM BIOS and figured how these works and emulated. Others are just pretend there was no error. For the two functions that writes anywhere in the low 4GB memory, I made it so that it works if the destination address happens to be in low 1MB. But, I haven't observed any sign that these functions are actually used.
Please see also Unpublished BIOS Functions and I/O Ports.
| Comments are welcome.
Send E-Mail to:
|