https://anikun.kutami.jp/towns-gcc/download.php FM Towns: FM Towns GCC (2.72) cross compiler under DosBox. (http://hp.vector.co.jp/authors/VA015321/). I'm using the following tools to create the FM Towns version. mkisofs - Creates ISO and adds IPL track. The IPL track has to be manually modified to point to the correct sector of the IO.SYS file (Byte 32 of the IPL). Also, the IO.SYS should (maybe needs) to be the first file in the file system. RawToFMT - Custom written command line utility to convert graphics from 24 bit raw files to 16 bit raw files in FM Towns format (GBR 655 format). I also use bin2elf, from the NeoDev environment, to link the graphics into the application. I would like to have the graphics stored on the CD and read in when the program starts, but there seems to be some problem with this. The correct number of bytes are read, but the buffer isn't changed. Dosbox - Dosbox is required, since the compiler files are .exp files and require EXE386. Exe386 only runs in a non DPMI mode. The EGB and Snd libraries are used for graphics and joystick control. The EGB was very difficult to figure out, since all the documents are in Japanese and are very concise. It's very hard to find sample programs or source that uses EGB. I've posted many times on the UNZ message board (http://tcup7122.at.infoseek.co.jp/townsemu/bbs) to get clarification on EGB parameters. The message board is 95% Japanese, but the emulator author and a few others speak English well enough to help out. I thought about using hardware sprites, using the SPR library, but it only supports a 256 x 240 resolution for sprites. This would've been a problem, since the program is written assuming a 320 x 224(+) screen size and 16x16 and 24x16 or 32x16 sprites. I could've done the conversions in the routines, but that would've been a big challenge, and probably wouldn't have worked correctly. I use the UNZ FM Towns emulator for testing of the game most of the time. I burn a CD, every two or three days, to ensure it still works on the real hardware. All my projects use Photoshop for graphics editing and Paint Shop Pro to save pcx (as needed) files correctly. I use Visual Studio for all the projects, most of them are compiled directly from Visual Studio using a nmake compatible makefile. The FM Towns version cannot be compiled directly from Visual Studio, since it uses Dosbox. I would eventually like to get Watcom working as a compiler. Watcom can output the .exp format, but I need to figure out which format to use (since there are 3 or 4 varieties). I've already done some of the work to convert the EGB library to NASM (and Watcom) format. Thanks to the author of the UNZ emulator, I fixed the access to the video memory (VRAM). I'm also implementing a double buffering system to remove the flicker that can be seen at the top of the screen, when a sprite is moving. This is only visible on the real hardware. Accessing VRAM through selector $010C changes the layout of VRAM. It's used for 256 color mode. Selector $0104 is used for 32,000 or 4 bit color. Before fixing the selector, the code required a weird routine modification to work correctly. Everything it working nicely now. - FM Towns fixes. I'll be receiving a beta version of the CD-I emulator this weekend (at the earliest). This will speed up development of the CD-I version. I've already paid the registration fee for this excellent piece of software. The CD-I version will be resumed at this point. Since the CD32 version is going to be delayed, I've decided to fix up some of the problems with the FM Towns version. I've fixed the speed issues. I turned off the sprite animation system update checks, which was causing all of the sprites to be drawn each frame. I've also fixed the flashing text and sprites, by adding a changed flag for each double buffered surface. The play still seems a bit uneven. I need to further optimize some of the routines. I may also convert everything to 8 bit, which will further speed up the updates. - FM Towns version sped up. There is not a 256 color 320x240 video mode, supported by the bios. It's probably possible to set it up using the CRTC registers, but I don't have good enough documentation to do that. But, I was able to optimize the assembly language blit routines to gain some speed. I haven't used my 386 optimizing skills in 6-8 years. I did some loop unrolling, but was limited by the width of the fonts (8 pixels) and sprites (multiple of 16 pixels). I did optimize the sprite and font transparent blits by reading 2 pixels (DWORD) at a time and writing each pixel seperately, skipping 0 colored pixels (16 bit). I also did some simple stuff like using an 'or' instruction instead of a 'cmp'. It doesn't seem to slow down much (in the emulator), and I haven't tested the updated version on real hardware yet. I also gained some speed by eliminating the wait for vertical blank, since this seems to be handled by the egb page flipping routines. The next challenge is finding a way to change the sky color as time passes. I could change the color in the background image, but this would probably cause a noticable slowdown. It might be easier to create multiple copies of the background at startup, but this may take too much memory...