|
Let's say you have a almost-functioning FM TOWNS, but its internal CD-ROM drive is dead, floppy-disk drive is dead, and CMOS battery is gone. In that situation, all you could do was pretty much power it up and watch boot-device cycles at the lower-right corner.
Until now.
I have already released a SCSI CD-ROM driver, YSSCSICD.SYS. This driver let Towns OS think SCSI-connected CD-ROM drive is an internal drive. However, it had some problems. First, you need to make separate boot disks for Towns OS V1.1 and V2.1. Or, even if your game title is not directly accessing CD-ROM I/O, some of those titles use a special driver or BIOS, in which case you needed a separate boot disk for your game title.
The second problem is it doesn't help your FM TOWNS if internal floppy-disk drive is dead as well. In that situation, possible boot devices left were SCSI hard drive, or IC memory card. However, to boot Towns OS from a SCSI hard drive, you need to assign a drive letter, but to assign a drive letter you need to boot Towns OS. It's a same old chicken and egg problem. IC memory card that can be accessed from FM TOWNS virtually doesn't exist any more.
The third problem is since it relies on a floppy disk, it is impossible to manufacture using Windows 10. Well, you could with an earlier version of Windows 10, but not any more. If you are able to format a 1232KB floppy disk, you may be able to do something, but to do so you need TOWNS. Again, it's a salmon and ikura problem.
On the other hand, my FM TOWNS Emulator "Tsugaru" is now able to emulate SCSI CD-ROM drive. I am able to develop and debug an IPL (Initial Program Loader) and boot loader in Tsugaru.
So I started FM TOWNS Rescue Boot Loader project. TOWNS reads and executes the IPL sector of a hard drive regardless of the drive-letter assignment. Therefore, theoretically it should be possible to write an IPL that loads IO.SYS from external SCSI CD-ROM drive, intercept before it hands off the control to MSDOS.SYS, install BIOS redirector, and continue the rest of the boot process. Then, TOWNS will think an external SCSI CD-ROM drive is the internal drive. Since it installs the BIOS redirector much earlier than CONFIG.SYS, it won't require separate disk for different versions of TownsOS.
Now you can use an emulator such as Tsugaru or UNZ to set up a hard-disk image, and append the boot loader, and use the image in the virtual SCSI drive such as SCSI2CD to save a TOWNS (except 386SX models at this time) without using CD or FD. I have uploaded an insturction here.
(* Turned out FM TOWNS UX and UG's boot process is too complex compared to other models to support. These two models are the only FM TOWNS models with 80386SX. I don't have a Marty. So, I cannot test if the boot loader works with Marty, but probably not.)
INT 93H AX=01C0H was not returning the drive mode in DL. Fixed the issue.
Now I don't think new SCSI CD drive exists any more, but still you can get one from eBay. Good luck!
A ground-breaking discovery. FM TOWNS II MX and FM TOWNS II HR's system ROM read IPL sector from a SCSI CD drive and jump to IPL. TOWNS 2F didn't. My guess is TOWNS II CX and newer models models' system ROM reads IPL from SCSI CD drive. On the emulator I confirmed with MX ROM, and actual HR did the same.
Therefore, if I write an IPL, I can start a program from SCSI CD-ROM drive directly without relying on a floppy disk.
So I did it. How to use is extremely easy. Download the ISO image from the following URL and burn to a CD-R.
https://github.com/captainys/FM/tree/master/TOWNS/IPL/DISKIMG
Start your TOWNS II with this CD-R in the SCSI CD drive. You will be prompted to change the disc to the one you want to boot and press a button on game pad or mouse. If you follow the instruction, your app will start from the SCSI CD drive.
There are some limitations:
Actually, you can make a Towns OS directly boot from the SCSI CD drive. It's extremely easy. Make an ISO image of the Towns OS disc (can be system software or any game), and overwrite the first 6KB with the following binary:
https://github.com/captainys/FM/tree/master/TOWNS/IPL/BOOTSECT
You can just open a .ISO file in a binary editor and overwrite first part with this boot sector. In CUE/BIN format, if the data track sector length is 2048, you can do the same for BIN file. If the sector length is not 2048, there are gaps between sector data, and you need to skip those gaps. I don't know if there is such a tool. I might write one if there is a demand.
Due to some resource issues, I could confirm only Towns System Software V2.1L31 on my TOWNS II HR, but on the emulator, it seems to work with majority of Towns OS apps as long as it is not directly beating CD-ROM I/O. (Same limitation as YSSCSICD.SYS)
Floppy-Disk Boot Loader does not solver the problem of floppy-disk dependency. However, it at least solves a problem: YSSCSICD.SYS approach needed separate disks for Towns OS V1.1 and V2.1. If you have a functioning FM TOWNS unit, maybe it's a good idea to make one for the doomsday when its CD/FD drives are gone.
In addition to "What You Need", you need at least one floppy disk.
I have confirmed the following image successfully starting Towns OS from external CD-ROM drive with FM Towns II MX and II HR. Download FDIMAGE.BIN or FDMINI.BIN and write to 1232KB-format floppy disk.
https://github.com/captainys/FM/tree/master/TOWNS/IPL/DISKIMG
The boot loader uses first 160KB (I reserve 160KB just in case. It is actually using much less.) You can write first 160KB using FDMINI.BIN or entire disk with FDIMAGE.BIN.
2020/10/12 update: FDMINI.BIN / FDIMAGE.BIN immediately searches SCSI CD drive on startup. Instead, if you use FDMINIM.BIN or FDIMAGEM.BIN, the boot loader starts the boot menu.
Now it is difficult to find a floppy disk without bad sectors. Even in that case, you only need first 160KB. If you have a floppy disk with a bad sector in the middle, you can still recycle it for emergency-boot disk. This boot loader is environmentally friendly.
Once you have a disk, connect your SCSI-CD drive, put Towns OS V1.1 or V2.1 system disk (or whatever game you have) in the SCSI-CD drive, insert the boot floppy disk in drive A or B, and power on. After a while, it boots from external SCSI-CD drive.
Well, it's getting more and more difficult to manufacture a 1232KB-format floppy disk. But, if you have a working TOWNS, you can format in Towns OS, and then use the following command-line tool to write a disk image.
https://github.com/captainys/FM/tree/master/TOWNS/FDWRITE/EXE
You need to format your floppy disk in 1232KB format with Towns OS or DOS. Then, go into Towns OS Command Mode, and type like:
RUN386 -nocrt FDWRITE.EXP A: FDMINI.BIN
It won't confirm before write. Be careful not to overwrite your important floppy disk.
You can see how it goes using my FM TOWNS Emulator "Tsugaru". Tsugaru GUI is not supporting this, but from CUI, you can type like:
.\Tsugaru_CUI.exe ROM_MX -SCSICD5 TownsOSV2.1L20.cue -FD0 FDIMAGE.BIN
to see how this boot loader starts from SCSI-CD drive.
Let's say your TOWNS has bad floppy-disk drives. None of drive A nor B reads a disk. Or, it can be like your TOWNS has a dead CD drive and cannot start Towns OS. You don't have a spare TOWNS in working condition. And you upgraded your Windows 10 and you can no longer format a floppy disk in 1232KB format. (Good job, Microsoft!) Or, you may have ended up with getting a SCSI CD drive that cannot be configured to SCSI ID between 0 and 4. I have seen many portable CD drives that could only be configured to SCSI ID 5 and 6. In that case, SCSI CD boot image and boot sector don't help.
Now, you can use an emulator, such as UNZ or Tsugaru to make a bootable hard-disk image for Towns. You can bring it to the actual Towns by writing the hard disk image to a SD card or Compact Flash and mounting it on a virtual SCSI hard drive such as SCSI2CD or Henkan Bancho. The problem is, you need to assign a drive letter to boot into Towns OS or MS-DOS. However, you need to boot into Towns OS or MS-DOS to assign a drive letter. It creates a salmon and ikura situation.
Until yesterday.
I have made a hard-disk image that can start a boot menu, something like a DOS BIOS menu, from which you can set up drive-letter assignments.
The image is HDIMAGE.BIN you can download from the link below.
https://github.com/captainys/FM/tree/master/TOWNS/IPL/DISKIMG
You can try it with one of the emulators before actually trying on an actual Towns.
When it starts, by default it is selecting boot from "SCSI CD Drive". Use gamepad0 up and down to select "BACK TO MAIN MENU", then go to "DRIVE LETTER ASSIGNMENTS". There you can assign SCSI IDs to the drives. Up and down to select a drive letter, and left and right to change assignments or unassign when you press left from SCSI ID 0.
Although I haven't tested yet, you can add 0s after this hard disk image to make it appear a larger-capacity hard drive to the emulator, then you should be able to add partitions where you can fresh install TownsOS. Also I should be able to make a program that appends this partition to the end of existing hard-disk image. I'll try it eventually.
This should be able to help older models with a virtual SCSI hard drive.
If you are trying to reconfigure the TOWNS with CMOS battery depleted, follow the instruction below:
(1) Replace the battery. If is not a too-difficult maintenance work. If you are not confident, find someone who is experienced.
(2) Start into a TownsOS or MS-DOS bootable HD image, not this HD image. You will see an error message in Japanese. The translation is "a drive letter is not assigned to the boot drive." But, this will reset the CMOS.
(3) Power off TOWNS.
(4) Then start into this HD image where you can assign drive letters.
(5) Put your TownsOS or MS-DOS bootable HD and start.
If you skip steps (1) and (2), IO.SYS will reset the drive-letter assignment in the subsequent start up.
Thank you for sending me the test reports!
Basically those require a patch to run with YSSCSICD.SYS won't run with this boot loader.
During the initial boot process, FM TOWNS' system ROM read the first sector of a media to B000:0000, and if the first four bytes are "IPL4", it jumps to B000:0004. This process is independent of CMOS setting. Therefore if you write your own boot loader and write to the first sector of a media, the system ROM will find your program and jump to offset 0004 even if your CMOS RAM is wiped due to depleted battery. The boot loaders here use this mechanism.
The first stage of the boot loader, or initial program loader (IPL), is limited to (apparently) 2KB, 2 sectors of a 1232KB floppy disk, or 4 sectors of a SCSI hard disk drive. It cannot do too much things in 2KB. So, IPL reads the second-stage boot loader to 8000:0000, and jump there.
The second stage boot loader reads YSSCSICD.SYS driver to B400:0000, then search for CD-ROM or CD-R drive in the SCSI chain. If it finds a CD drive, it then searches for a sector starting with "FBIOS". It indicates the start of the IO.SYS. IO.SYS needs to be loaded from 0040:0000 the size depends on the version of Towns OS, but looks like the maximum size is 128KB. So, the boot loader just reads 64 sectors (1 sector of a CD is 2KB).
Once IO.SYS is read into the RAM, the original IPL jumps to the offset 0000H of segment written at 0050:0000. From there, my boot loader searches for a JMPF instruction that takes place after BIOSes are initialized. Finding it was not too difficult because it is preceded by a bunch of near CALL instructions mixed with one MOV SI,????H instruction.
If the JMPF instruction is found, the boot loader tweaks the jump destination so that IO.SYS will jump to the boot loader once all BIOS initializations are done. And then it jumps to the entry address of IO.SYS.
When it jumps, the value of AX is set to F7FFH. The bits of AX is interpreted as presence of RAM banks. 1 bit corresponds to 64KB. By erasing bit 11, I can make IO.SYS think B0000H to BFFFFH doesn't exist. That's the location where I keep YSSCSICD.SYS safely. Also the value of BX is set to 0008H, which makes IO.SYS think it is booting from the internal CD-ROM drive.
IO.SYS will initialize all the BIOSes and then jumps back to the boot loader. This is the timing that the boot loader redirects INT 93 to YSSCSICD.SYS.
Then it hands the control back to IO.SYS. Since IO.SYS is thinking INT 93H is already initialized, it won't touch the INT 93 jump vector. In the rest of the boot process, IO.SYS will call INT 93H to access CD-ROM drive. Those BIOS calls will be intercepted by YSSCSICD.SYS, and therefore the rest of the boot process reads files from the SCSI CD drive.
The replacement boot sector packs the IPL, second-stage boot loader, and YSSCSICD.SYS in 8KB. The system ROM is thinking it was reading 4 sectors from a hard drive, which should be 2KB. Instead, it is reading 4 sectors from a CD drive, which is four times bigger. Also, the system ROM tells from which SCSI ID the boot sector is read from in BH. Therefore I could omit SCSI scan. Also since the system ROM already accessed the sectors, I could omit wait for unit ready. The size of YSSCSICD.SYS is 32KB, but 28KB of them is just DB 2356*12 dup (0). So, the essential part is about 4KB. In fact, the IPL and boot loader didn't take much. Everything including AOMORI-prefecture map and an invitation to Demosplash 2020 fit within 6KB. I have 2+KB space to add a demo if I choose to. (As a Demo coder, I am tempted to do so.)
By the way, booting TOWNS from a SCSI CD drive was supposed to be impossible. Before doing this project, I checked the behavior of the system ROM using Tsugaru. It was issuing SCSI command 12H (INQUIRY), and the purpose of this command is supposed to be to check the device type. I guessed that the system ROM will not try to read the boot sector if the device type is not a hard disk drive. In fact, TOWNS 2F's system ROM gives up reading the boot sector if the device type is not a hard disk drive. But, just in case, I stated Tsugaru with a virtual SCSI CD drive. Next thing I could not believe. MX's system ROM did issue command 12H (INQUIRY), but then it issued command 28H (READ 10) as if it ignored the device type returned from the INQUIRY command.
I really couldn't believe what I was seeing, but I let it continue. Of course the unmodified CD boot sector was thinking it was booting from the internal CD drive. It then printed an error message indicating illegal interrupt, and then stopped. If the system ROM did not read the boot sector, it won't jump, and move on to the next boot device. Illegal interrupt was the sign that the boot sector was loaded.
Next thing I should do was to test it on actual TOWNS. I picked a random CD from my pile, put it in my SCSI CD drive connected to my TOWNS, and started. It indeed showed the same error message. So, I thought MX's system ROM does read a boot sector from a SCSI CD-ROM drive, but may be unique to TOWNS II MX.... Next moment, I realized that the TOWNS I thought was MX actually was HR. Earlier in the day, I was fabricating a AT power to TOWNS power conversion cable, and for testing I moved my MX off my desk, and put HR in place. Oops, I accidentally tested that HR's system ROM does the same thing. Although I cannot confirm because I don't have TOWNS models between 20F and CX, my guess is TOWNS II CX and later can boot from SCSI CD drive.
If that's the case, I can write a boot sector, so I did, and that's the boot loader and boot sector you can download from the above.
| Comments are welcome.
Send E-Mail to:
|