The FM TOWNS was the first computer to come with a CD-ROM drive, and it well predates attempts to standardize bootable CD-ROM behavior on the IBM PC and other platforms. The FM TOWNS' boot process for CD-ROMs (as well as floppies, IC cards, and hard disks) is very similar in overall shape to the boot process for IBM-compatible PC disks, but with some fun wrinkles due to the way Fujitsu evolved the platform over time. I managed to make a bootable image that loads a small "kernel" that switches into protected mode and scribbles all over the screen, and get it working both in the Tsugaru emulator (which emulates an FM TOWNS MX) as well as my real-world UX20.
The boot ROM
Similar to a PC, the first thing that runs when you turn on an FM TOWNS is its boot ROM. This checks the hardware and RAM in the system, and if everything looks good, it cycles through the drives connected to the computer looking for a bootable medium. This includes the ROM drive, a DOS disk image burned into ROM which contains versions of MSDOS.SYS, COMMAND.COM, and MSCDEX.EXE, so that developers could ship games and software on bootable CDs without having to pay Microsoft to store those files on disk. On most FM TOWNS models, the ROM disk doesn't include Fujitsu's custom IO.SYS, and it isn't a bootable system on its own, and so the boot ROM skips past it and proceeds to cycle through the floppy drives, CD-ROM drive, IC slot, and any hard drives connected to the SCSI bus until it finds a bootable medium.
The IPL boot sector
If you're familiar with PC development, you know a bootable floppy or hard disk has the magic bytes 55 AA at the end of the first sector, with the rest of the sector containing the boot code. Similarly, the FM TOWNS boot ROM looks at the first sector of each device looking for the magic string "IPL4" at the beginning of the sector to indicate that it's got a valid boot sector (IPL being a term dating back to IBM mainframes to refer to boot code, meaning "Initial Program Load"). If it matches, then the first 2048 bytes on the disk are loaded into memory at linear address 0xB0000, and the boot ROM does a call far 0xB000:4 in real mode to transfer control to the boot code immediately following the magic string. Unlike a PC boot sector, an FM TOWNS boot sector can retf back into the boot ROM if something goes wrong during its attempt to boot from the disk, in which case the boot ROM will move on to the next potential bootable device.
At the point the IPL runs, the int 0x93 disk BIOS routines described in the FM TOWNS Technical Databook are not yet available, but the boot ROM provides most of the same API through the entry point call far 0xFFFB:0x14, so it is easy to read any kind of drive the boot ROM supports, including floppies, CD-ROMs, or SCSI drives, without any additional driver code.
Loading IO.SYS
As with Western variations of MS-DOS, the first part of DOS to load is IO.SYS, which prepares the hardware and provides a base layer of disk, console, and other basic device drivers for MSDOS.SYS to use. Fujitsu's IPL implementation reads IO.SYS from a fixed location on disk, and writes it to memory starting at linear address 0x400 (as low as it can go without clobbering the real mode interrupt vector table). It checks the beginning of the file for the magic string FBIOS. If it doesn't match, then the boot fails, and it returns back to the boot ROM, but if it succeeds, it loads a real-mode segment number from linear address 0x500, then does a jmp far <segment>:0 to transfer control into IO.SYS. IO.SYS then typically proceeds to initialize the hardware, set up device drivers, and then loads MSDOS.SYS and MSCDEX.EXE from the ROM disk, before passing control on to MSDOS.SYS. From that point, things behave mostly like a typical DOS system, just with suspiciously early-loaded support for ISO 9660 CD-ROM filesystems.
The FM TOWNS UX series and Marty
You might wonder why I went into so much detail about how IO.SYS is loaded, when this post is ostensibly about how to boot a non-DOS-based environment. There's a major wrinkle in dealing with the FM TOWNS UX models, as well as the Marty console. The original FM TOWNS machine used an 80386DX CPU, and its physical address space spans the full 32 bit address space supported by that CPU. Most models followed suit, using full 386DX, 486, or Pentium processors with the same hardware memory map. However, the UX and Marty were based on the 80386SX CPU—although internally, the 386SX executes the same 32-bit x86 machine code we all know and love, outwardly it was chopped down to a 16-bit data bus and 24-bit physical address space. These models therefore had to use a totally different hardware physical memory map from the other models, and existing FM TOWNS software, with its OS software already burned onto discs, would not "just work" on these models.
Fujitsu's solution to this was to exploit their ROM disk. Unlike other FM TOWNS models, the ROM disk in a UX or Marty is a bootable device itself, and the image contains its own version of IO.SYS. This ROM-based IO.SYS completely takes over the boot process from the boot ROM. However, instead of charging ahead booting into DOS itself, it still checks all the bootable devices on the system itself for a device to boot on behalf of. It does this by loading the IPL sector from each disk in turn, but it doesn't execute the IPL's code; instead, it picks out the first sector and sector count of IO.SYS from the IPL, and loads the IO.SYS from that disk. It then inspects a string that appears at the beginning of TOWNS OS versions of IO.SYS, which generally looks something like this:
IO.SYS ( BIOS ) Middle Resolution Display Type
BIOS Version 3.58 1995-07-17
If the date code looks like one of the original versions of TOWNS OS that pre-date the UX series (1989-11-11, 1989-12-16, or 1990-10-01), then the ROM's version of IO.SYS will take over, booting itself instead of the IO.SYS that was on the disk. The ROM version of IO.SYS then also arranges to patch the corresponding older versions of Fujitsu's TBIOS library to support the 24-bit hardware if they're loaded. However, if none of the date codes match, then the ROM assumes it's a newer version of TOWNS OS that presumably natively supports the 24-bit hardware. In this case, it chain-loads the IO.SYS file from disk, loading it into memory at address 0x400 and then jumping into the segment stored at address 0x500 as if it had booted straight from the IPL.
Fooling the UX ROM to load your own kernel
So if you want to boot your own software on an FM TOWNS, and want to support the UX and Marty models, writing your own boot sector isn't enough on its own; your "kernel" also has to look enough like a TOWNS OS IO.SYS that the UX ROM disk will load it for you as well. This didn't turn out to be that hard. In the boot sector, the UX ROM appears to determine where the disk's kernel file is by reading the first sector as a 32-bit value from offset 0x20, and the number of sectors to load from offset 0x24. To mimic the load and entry sequence for IO.SYS, your kernel file needs to expect to be loaded at linear address 0x400, start with the magic string FBIOS, store the real mode segment to start execution from at linear address 0x500 (offset 0x100 from the start of the file), and should not contain any of those looked-for date strings in its first 256 bytes.