|
OK. I don't mean Tsugaru can now run on Linux. It has long been running on Linux. This time, Linux+JE4 1995-12 runs on Tsugaru VM. This Linux is old. The kernel version is 1.3.30. I haven't tried to install on a hard-disk image, but Tsugaru can boot Linux from CD, start X-Window and FVWM. If you start X in the high-resolution mode, mouse integration works as well. The mouse cursor jumps if you try to resize the window, but other than that, it looks to be working ok.
I thought Linux should start with no issue because Tsugaru was already good enough to run Windows 95. But, first I encountered a strange polling loop. The CD-ROM driver was polling a timer I/O without masking IRQ. The timer-up flag is supposed to be cleared in the interrupt handler. So, unless the IRQ is masked, the polling loop is not supposed to see the timer-up flag. However, when I experimented the same condition on real FM TOWNS II MX, the polling loop worked, and the IRQ was coming in while polling. WTF!? I cannot tell what's going on inside TOWNS. But, the observation tells that there is a lag after the timer is up before the interrupt-handler is invoked. I came up with a small change to support this lag. This part passed.
Then, this version Linux was using hardware task switching, which Windows 95 nor Windows 3.1 was using. Intel 80386 CPU can switch task by a CPU instruction. However, the switching seems to be doing too much work. Programmers figured switching tasks all by software was more efficient. So, pretty much nobody used this feature. 64-bit AMD CPU even deleted this feature. Only very early version Linux was said to be using it. Many sources told so. So, I was hoping I won't have to support this feature, but this version Linux turned out to be the very early version. Just switching tasks was not a big deal, but 80386 had a concept of nested tasks, which I still does not fully understand the concept. I thought it would be virtually impossible if Linux was using this nested tasks, but all I needed was a simple task switching. Linux started working!
The below is the screenshot of Linux+JE4 1995-12.
Big progress in the FM TOWNS/Marty Emulator Tsugaru! Finally! Finally it supports Windows 95! No, I'm not saying Tsugaru can run on Windows 95. Windows 95 can install and run inside Tsugaru VM.
The goal of Tsugaru was to fully emulate FM TOWNS II MX. FM TOWNS II MX was the best personal computer that has ever been sold and the last computer that I pledged loyalty to. If I want to say Tsugaru fully emulate FM TOWNS II MX, it needs to run not only FM TOWNS OS, but also FM OASYS, Windows 3.1, Windows 95, and Linux. Nonetheless, there were already DOS emulators that could run Windows and Linux. The main point of emulating TOWNS was to run FM TOWNS OS. That was my primary goal. So, I was thinking even DOS6 support was not necessary. But, once I released Tsugaru, I had passionate requests for DOS6 support. So, I did. When I was able to support DOS6 and EMM386, I got a little ambitious. I thought Windows 3.1 support was within reach. It was a difficult journey, but I nailed it. Then, if I could run Windows 3.1, why not Windows 95? But, Windows 95 support was even more difficult and was not making any progress for a while.
I did have a similar problem when I was an undergrad student. I moved from a rural city of Hirosaki to equally rural southern Fujisawa city. In the first year, I thought an air conditioner was unnecessary and did not buy one. But, I suffered many hot nights during the summer. I thought to get an A/C in the second year. But, I thought again. If I bought an A/C, then what was the point of my suffering in the first year? I did not buy an A/C and saved money. But, I had more difficult nights during the second year. I thought I had enough. I should get an A/C next year. That's what I thought. But, then I thought again. If I bought an A/C, then what was the point of my suffring in the first and the second year? I did not buy one. I ended up repeating for seven years. A very similar experience to DOS6 and Windows 3.1 support. (Ahhh, isn't it?)
The situation started moving when a frequent contributor called BCC reported that an extension to Windows 3.1, Win32S was still available for download, and when he tried it, the game Freecell, which was bundled with Win32S as an example, was crashing.
The biggest difference between Windows 3.1 and Windows 95 was that Windows 95 could run 32-bit applications. Win32S was an extension to Windows 3.1 to allow running some of such 32-bit applications. If I am able to support Win32S on Windows 3.1, maybe it will be enough to run Windows 95. So, I looked into it, and successfully ran Freecell.
So I hoped the changes allowed Windows 95 to install and boot, but it was not that easy. Nonetheless, I was a little bit motivated. Last time, I knew that it was stopping in a driver called TOWNSSYN.DRV. I went in to the code. After days of reading disassembly, I concluded that the crash of TOWNSSYN.DRV is unavoidable. Then I looked into .INF files, and I saw a description that TOWNSSYN.DRV was supposed to be deleted while installing Windows 95. It must be a Windows 3.1 driver. Also strange was the installer added FMRSYN.DRV. The filename implied that it was a driver for FM-R, not for FM TOWNS. Why is this FMRSYN.DRV installed? I searched for the location where this driver was installed. Then, found that it was not identifying the machine type correctly. Once found, fix was easy.
Finally, the installation was done. But, Windows 95 destroyed the file allocation table during the boot. Apparently VDMAD and VSCSID failed to initialize. Turned out, I was making DMA-status I/O write only. But, Windows 95 VDMAD was reading from the status I/O, set or clear some flags, and then writing back to the status I/O. Since FF was always returned from that I/O port, after setting or clearing a flag, all other flags were set. Once I fixed, Windows 95 started stably with floating-point unit turned on.
Then I fixed a problem that IME was crashing when a mode is changed, Explorer property window crash, MS-DOS Prompt crash, and now it is pretty stable. I successfully install and run some Windows 95 games, like Namco History Vol.1 and Puyopuyo Two. But, Windows 95 uses deep features of 80386. So, it needs to run in the High-Fidelity mode, which is notably slow. I hope Apple and Intel keep making faster CPUs.
So, I felt that I reached a big milestone. Then, an FM-7 game that I was searching for long time, QIX for FM-7 was on Yahoo! Auction! That was the very first game I bought in my life. Well, I am pretty sure Cosmo Crash and QIX were the first two. I am 80% confident that QIX was the first. I already have COSMO CRASH. I was desperately looking for QIX. I wanted to try it myself, but also I wanted to put it on display in events like Demosplash and Retro Game Night. It was not the first time I saw QIX on auction. Soon after Buyee.jp enabled bidding from the U.S., I tried to get one, but I was outbid by someone else. I was thinking I should have a next chance soon, and many years passed without any QIX on auction. I never imagined it was such rare. But, finally! It was my second chance! I was preparing to put $700 maximum, but I was able to win for $100.
Then it arrived. I was having a very good success rate in restoring tape-based games, so I was not expecting any difficulty. Well, nothing is easy actually. The data recorder that restored many games got a little unstable. The top and bottom of the wave started fluctuating. That's fine. I was preparing for the day my data recorder dies. I connected a spare data recorder that have been confirmed to work with real FM-7. This data recorder was not a good match with my PC. My PC records for a few seconds, and then the level dropped to near zero. Probably, the was pattern was too crisp and the audio hardware probably (stupidly) filtered out the sound. It was unusable.
But, the one got a little unstable gave a good-enough recording that I could fix manually. I used my tape image tool to fix it. Then I was able to confirm run on Mutsu and XM7. Before putting on display on a real hardaware, I should write a patch to support gamepad.
After passing two big (big to me) milestones, I was kind of in the state of burn out. Then, I got a report from jckarter that he figured how to boot into an original IPL in the 386SX models FM TOWNS.
I am writing an emulator Tsugaru, but to preserve the glory of FM TOWNS until the end of the universe, it is good to have a good emulator as well as working real hardware. The biggest obstacle (or I say holy grail) of FM TOWNS preservation is the broken internal CD drive. Fujitsu did it too early. There was no such thing called a standard CD drive then. Therefore FM TOWNS's internal CD drive was totally proprietary. If broken, it is not possible to get a new part. To solve this problem partially, I came up with a rescue IPL to use an external SCSI CD drive instead of the internal CD drive.
But this IPL could not support 80386SX models, UX, UG, and Marty. There were some software for FM TOWNS when 80386SX models were released. But, due to poor capability of 80386SX, the driver needed to do some things differently. It was too late to replace drivers bundled with already-released software. So, the system ROM secretly replaced the driver under the hood while booting. For replacing the driver (or FBIOS), it did not read and jump to my IPL. However, jckarter figured the way to get around this boot process and he successfully wrote a test code by himself. Based on his information, I was able to modify my IPL to support 80386SX models. Actually since I don't have one handy with my, I could only test on Tsugaru, but now Tsugaru replicates FM TOWNS very well. I am reasonably confident it should run on real FM TOWNS UX and UG. It does not rescue Marty though. Marty cannot connect a SCSI CD drive because it does not have a SCSI connector. Nonetheless, I believe this IPL can rescue all FM TOWNS models except Marty. (I am not considering FMV-TOWNS as a FM TOWNS model.)
It was a dense first quarter of the year.
New version of FM-7/77 RS232C serial expansion card, succeeded in configuraing COM1 or COM2 with jumper pins. You can find KiCAD Schematic and PCBs here (githug).
Earlier RS232C serial expansion card could not be used with FM77AV40 and newer models because I/O addresses collided with on-board RS232C. It probably worked if you kept the on-board RS232C off, but it can accidentally be turned on, then you never knew what was going to happen. But, the on-board RS232C could be only up to 19200bps. The expansion card could communicate at 38400bps, double the speed. The new version can be configured to COM1, which uses different I/O addresses, therefore it should work with FM77AV40 and newer models. (To be confirmed soon.)
The major advantage of BIOS Redirection to RS232C is it can be installed with just 4 lines of F-BASIC program, although it is not the fastest way of running FM-7/77 without actual floppy disk drive or tape drive. Actually, FM77AV40SX did not have the audio-cassette interface and therefore could not run tape-based programs. But, with this redirector, AV40SX can run tape-based games.
This new version RS232C card allows AV40 and newer models to use 38400bps transmission. It loads tape-based games at blazing fast (faster than tape), or somewhat usable as a virtual disk drive.
To support the new RS232C card, I have updated FM-7 Series Resurrection utilties, too. Disk BIOS Redirector, Tape BIOS Redirector, Disk Image Transmitter (RAWREAD) identifies COM0/COM1 automatically. If the computer has both COM0 and COM1, it uses COM1.
Major achievement in FM TOWNS preservation! Although this method only works for newer models (Probably TOWNS II CX and newer, I confirmed with an actual II HR, and II MX on Tsugaru), all you need to start a dead FM TOWNS is a SCSI-connected CD-ROM/CD-R drive, and a CD-R media!
FM TOWNS Rescue Boot Loader Project
FM TOWNS Internal CD-ROM Drive Reverse Engineering Project
FM TOWNS Internal CD-ROM to Exteranal SCSI CD-ROM BIOS Redirector YSSCSICD.SYS, SYSDRV.EXE
FM TOWNS Unpublished BIOS Functions and I/O Ports
Fujitsu FM TOWNS Preservation Project Going On.
Almost complete sampling of Fujitsu-original FM77AV40 Keyboard infra-red signals.
I have a long-term goals. One is to reverse engineer FM TOWNS CD-ROM drive interface and hopefully make an adapter that translates the FM TOWNS's CD-ROM commands into SCSI. Another is relatively shorter term. I want to figure why some game titles don't run with CDSD.SYS and CDISC.SYS. For those purposes, I am desperately looking for 386DEBUG customized for FM TOWNS.
When I was using FM TOWNS as my main computer, I at least had five back up floppy disks of 386ASM and 386DEBUG. When I was using FM-7, I lost data and programs saved in audio cassette tapes too often. That experience made me addicted to back ups. I am not comfortable unless I take at least triple redundant back up copies of my important files. Now I still have most of my source codes I wrote for FM TOWNS. But, I lost many of the programs that I was using in FM TOWNS. I searched everywhere, but id not find a single floppy disk of my backup 386ASM and 386DEBUG.
The last hope was two Magneto-Optical disks labeled as "Backup" and "D01". Maybe one of them is the backup of my system drive of FM TOWNS, which for sure had 386ASM. Today, with help from CMU Computer Club, I connected my IODATA USB MO drive, and opened the MO disk. Unfortunately it was not mine. All the files look to be my father's. My last hope was gone.
Actually I got hold of the original version of Pharlap 386ASM and 386DEBUG. But, when I try to run on FM TOWNS, it crashes with unhandled exception #0. I presume the FM TOWNS version was specially customized for FM TOWNS.
Recently I tried to win a copy of 386ASM and 386DEBUG for FM TOWNS on Yahoo auction, but I lost. I gave up when the price went beyond $1,000. I am wondering if the person who took it is actually using it or just keeping it for collection.
Succeeded in sending keyboard infra-red signal to FM77AV/AV40 with Arduino!
It turned out that Intel P82C51A seems to be able to run at 38400bps. I confirmed by modifying my RS232C card for Fujitsu Micro 7.
The Fujitsu-original RS232C card for FM-7 supports only up to 19200bps. The Fujitsu-original card uses Intel 8251A, which was manufactured around 1982. The maximum performance of 1982 Intel 8251A may really be 19200bps.
There are some 8251-compatible chips. OKI 82C51A officially supports up to 38400bps. I have a bunch of Intel P82C51A, which was manufactured in 1990, 8 years after the original Intel 8251A. The new Intel chip may be able to go up to 38400bps. I just did experiments.
Successfully Made YM2203C sound card for Fujitsu Micro 7!
It works! (Read more)
2019/05/01
I have successfully built RS232C serial-connection card, but I am still not very experienced in hardware. I was worried that I could fry my aging FM-7 motherboard when I plug my re-manufactured YM2203C sound card. Of course I'll do basic tests like no short between power pins, but who knows what's going to happen. I decided to get a spare FM-7 for my coming hardware projects.
I was able to win a good looking FM-7 for about $50 from Yahoo! auction via buyee.jp. The owner looks to have been taking real good care of this computer. GRAPH key stickers are neatly put on the side of the keys. No yellow color degradation. Not even dusts in the grooves. I was fully expecting this unit to function with no problem when I switched it on.
Such a clean
FM-7 like new.
Getting to the
motherboard.
The first easy test when you get a new FM-7 unit is to check if CAPS and KANA keys toggle LEDs. If CAPS and KANA LEDs don't toggle, the unit is in a grave condition. FM-7 controls the keyboard by a one-chip microcomputer MB88401, which works independent from main- and sub-CPUs. By checking CAPS and KANA LEDs toggle, you can confirm that the clock is coming in to this chip, and the chip is functioning as expected.
That worked.
Then, the next easy check is to press INS key and see if INS LED toggles. INS LED is controlled by the software. By looking at LED toggling, you can confirm that the CPUs are running. But, it didn't toggle. On top of it, once I press INS key, CAPS and KANA stopped toggling. I also plugged the monitor. If the sub-CPU is functioning I should see a cursor blinking top-left corner. There was no blinking cursor.
If the main CPU is functioning, by booting into DOS mode I should hear continuous beep. I have toggled the DIP SW 4 to ON position and turned on. No beep. <-(Later it turned out I remembered which DIP SWITCH to toggle wrong. I should have toggled DIP SW 1 to OFF position for this. At this time, evidently the main CPU was functioning.)
All I could confirm was MB88401 was working until I pressed INS. I looked into FM-7 schematic and tracked connections between MB88401 and sub-CPU. When a key is pressed, MB88401 issues FIRQ to the sub-CPU. The FIRQ handler of sub-CPU reads $D000, which returns acknowledge to MB88401. If the sub-CPU is not reading $D000 on FIRQ, MB88401 may be waiting for the acknowledge forever.
To test this hypothesis, I wrote a simple program that masks FIRQ and goes into infinite loop in the sub-CPU and ran it on my functioning FM-7. After the FIRQ of sub-CPU is masked and I pressed a key twice, CAPS and KANA stopped toggling. When I was using my FM-7 back in 1980s, I was thinking CAPS and KANA always toggle regardless of the CPU state. It was a new discovery for me after 35 years. Same thing could happen if I halt sub-CPU and leave it halted.
So, it was almost certain that the sub-CPU is not handling FIRQ. I needed to find why.
Power supply was easily tested by a tester. It should supply +5V, +12V, -12V, and GND. The power supply unit is connected to the motherboard with four wired, Black, Blue, Orange, and Red. The measured voltage between wires were:
Red-Black : +9.3V
Orange-Black : +20.9V
Orange-Blue
: +40.0V
Black-Blue : +19.1V
Nicely corresponds to +5V, +12V, -12V, and GND. The motherboard probably pulls down the voltage. What if the voltage drops when loaded? I connected the power and measured voltages between some ICs' Vcc and GND. All returned 5.04V. Looked perfect.
Power supply was not an issue.
I talked with Mr. Apollo, He said I should test power-supply, if CPU is getting clock signals, if CPU is sending E and Q signals, if CPU is reading from memory. I also talked with a Electrical and Computer Engineering student of the CMU Computer Club. Actually, he suggested the same thing before I asked if it is possible to test CPU clock signals. Looks like power supply and CPU clock lines are the first thing to test if you are to repair a classic computer hardware. He offered to test my non-functioning FM-7 with a logic analyzer.
At this time my hypothesis was EPROM. Since it was shipped by air, this FM-7 may be exposed to a strong X-ray during the security inspection, which could wipe the contents of EPROM. I could have pulled EPROMs from my functioning FM-7 and put into the non-functioning FM-7 and test. But, if the non-functioning unit has a short or anything that could damage the chip, it could ruin a chip in good condition. I didn't want to risk it.
While I was preparing which chips and pins to test, my hypothesis was somewhat broken. I thought the sub-CPU is not handling FIRQ because sub-system monitor (operating system for the sub-system) got wiped. In the FM-7 schematic, the sub-system monitor was stored in MB2764-20, which was an EPROM. But, on the actual board was MB3864, which is not an EPROM and shouldn't be wiped by X-ray exposure. Then, the loss of sub-system monitor may not be the case.
Anyway I took my non-functioning FM-7 for inspection. Surprisingly it seemed to be a broken 6809 CPU. Can a CPU broken? How likely it it? The logic analyzer told both main- and sub-CPUs are getting clocks. The lower-most bit of the main-CPU address bus was flipping, indicating that the CPU is doing something. But, the lower-most bit of the address bus of the sub-CPU was stuck high. Also tested RESET and HALT lines of the sub-CPU, both were high (active-low), indicating that the RESET and HALT are not stuck active either. Since FM-7's main- and sub-CPUs are interchangeable, we swapped the CPUs. Then, surprisingly CAPS and KANA toggled after pressing INS. Sub-CPU was responding to the FIRQ. Later I connected the monitor, and confirmed the blinking cursor at the top-left corner.
Also confirmed by the logic analyzer was that on FIRQ, the lower 4 bits of the sub-CPU address bus were 0x6, 0x7, and then 0xC. The sub-CPU read from $FFF6 and $FFF7 for FIRQ vector, and then jumped to $FDAC which is the FIRQ handler.
Testing clock input to the main CPU
Clock signal that the main CPU was getting.
The implication was that one of the CPUs, the one originally sitting in the sub-CPU socket, now sitting in the main-CPU socket is gone bad.
I ordered spare CPUs from JAMECO. The one I could found was 68B09EP, I assumed it must be compatible with 68B09P, which was on FM-7. <-(Later turned out 68B09EP was not signal-compatible with 68B09P. At this time I didn't know about it.)
By the way, I had a Hitachi 63C09P, which was a 6809-compatible chip with enhanced instruction sets. It was pin-compatible and as long as the program was not using an undefined instructions of 6809, which happened to be an enhanced instruction of 63C09, it should work same as 6809. Since I heard that replacing 6809 with this chip would improve the performance of FM-7, I bought it in Akihabara back in 1980s and tried on my FM-7. Then I ended up frying the PSG board, and put the original 6809 back in and replaced the PSG board. However, I might have just placed the PSG board in a wrong orientation then. 63C09 may not have been responsible for baking of the PSG board. One of the CPUs of this beautiful FM-7 was found dead. I tried my 63C09P anyway while waiting for the replacement 6809s.
HD63C09P
And the bag
HD63C09P was kept in. This shop
Takahiro Electronics look to be open for business today.
I inserted 63C09P in the main-CPU socket and powered on. Nothing. The cursor was blinking at the top-left corner, but no F-BASIC prompt. Sub-CPU was working, but main-CPU wasn't. I flipped the DIP SW 1 to OFF position, making it DOS mode, and re-started. After like a half-a-second silene, BEEP! The CPU is alive! Well, most likely. In the DOS mode, the boot loader will test if the disk drive is connected, and if not it goes into an infinite loop with continuous beep. It is an expected behavior. This implied that:
Then why no F-BASIC prompt? Was F-BASIC waiting for something forever? I could only imagine sub-CPU busy/halt. But, the sub-CPU was working. Was 63C09P not able to run F-BASIC? I didn't think F-BASIC was using undefined instructions. Is F-BASIC ROM corrupted? BASIC-mode part of the boot ROM corrupted? Or, RAM/ROM selector line stuck in the RAM mode? There are so many possibilities, but anyway I waited one more day for the replacement 6809 CPUs.
Four 68B09EP arrived the next day. I tested 68B09EP CPUs. I inserted the first one. Powered on. Nothing. Not even a beep in the DOS mode. Not to worry, I ordered four CPUs to prepare for a bad CPU. I tried the second one. No beep. The third one. No beep. The last one. No beep. All four 68B09EPs didn't work. Seriously? Only hope looked to be my 63C09P. I tried to insert 63C09P in the sub-CPU socket, and 68B09P in the main-CPU socket. I saw a violently flickering screen with beep from DOS mode. Sub-CPU looked to be writing something randomly to the VRAM. 63C09P cannot replace the sub-CPU.
One of the
four 68B09EP arrived. None worked.
.... If that's the case, maybe 63C09P cannot replace the main-CPU either. I swapped the CPUs. 63C09P in the main-CPU socket, 68B09P in the sub-CPU socket. For the one last attempt, I turned on, booting into the BASIC mode, and then....
F-BASIC PROMPT!!!!
All of a sudden, this beautiful FM-7 came back from death! It ran as if nothing had happened. I typed PLAY "V10CDEFGAB" and Yamaha AY chip played accordingly!
At this time I couldn't test what was going wrong since it was perfectly working. All I did was pulling and inserting CPUs many times. The student who helped me looked at the CPU pins, and suggested that the pins were oxidized and may not be transmitting signals. Indeed, some pins were dirty. Maybe oxidization layer was ground off while pulling out and inserting CPU. I also poked the socket holes with a capacitor leg to make it smoother. That could also cleaned the oxidization.
The one not
working. Well, the legs are pretty well oxidized. It was not so
clear until I magnified.
If that's the case, the one I took out may be restored by cleaning the pins. But, according to the Murphy's law, don't change if it is working. I'll keep my 63C09P in this FM-7 for the time being. I'll clean the one I took out to prepare for the future repair.
Looking back the 6809 data sheet, I see there is a good probability that dirty pins of the sub-CPU or sub-CPU socket held the main-CPU waiting forever. When the main-CPU halts the sub-CPU, the common way of doing is:
WAIT_READY LDA
$FD05
BMI WAIT_READY
LDA #$80
STA $FD05
WAIT_HALT LDA
$FD05
BPL WAIT_HALT
If the sub-CPU is not clearing the busy signal, the main-CPU will wait forever in the WAIT_READY loop. From the FM-7 schematic, the sub-CPU busy signal may not clear if BA and BS signal pins (pins 5 and 6) of 6809 is dirty, holding main-CPU in the WAIT_READY loop forever.
Lesson Learned: If you have a non-functioning FM-7, pull out the CPU and clean the oxidization. Also poke each pin-hole of the CPU socket with something like a capacitor or resistor leg two or three times. Then put the CPUs back on. That may resurrect your FM-7
By the way, 68B09EP may be simply not signal-compatible with 68B09P according to:
https://groups.google.com/forum/#!topic/comp.sys.m6809/nhhvKV3YRD4
I never knew 6809E and 6809P were not interchangeable. I know 68A09 cannot replace 68B09 though. There are a lot of new old things to learn.
2019/04/162019/04/16
Starting YM2203C expansion card reverse-engineering and re-manufacturing project.
Delphis for FM-7 joystick-support patch.
Emergency for FM-7 joystick-support patch.
2019/04/05
Running a Disk-Based Titles for FM-7 via RS232C
Actually I couldn't believe it worked. Couldn't believe it took only four days from start to the first success. It took another four days to add parameters and writing readme. If you are an owner of Fujitsu Retro 8-bit PC FM-7, it may be of your interest. (Read more)
FM77AV Keyboard emulator is also updated. Not really an update, but I found a cases that the program fails to transmit most of the letters when I compile it in no-console mode. I've just re-compiled binary in the console mode. You'll see an additional console window, but you can ignore it.
2019/02/23
Tried to repair my Sanyo Data Recorder (and failed).
Last year I bought a vintage game program called Plazma Line from www.suruga-ya.jp. I also ordered a Sanyo Cassette Data Recorder called MR33DR from Yahoo auction. According to the description the data recorder spins, but the seller could not confirm if it worked or not. Majority of the defective data recorder has some mechanical problems. If it spins, I thought it should be in good shape. The data recorder crossed the pacific ocean using the service from buyee.jp.
However, the data recorder didn't play sound. It spins. But no sound from the speaker and the phone jack. My problem became suddenly challenging then. But somehow I wrote a program that applies filters to the audio recording from a conventional audio cassette player and restored Plazma Line successfully.
Repairing my data recorder has been in my to-do list, but I have been postponing mainly because I didn't have a skill set to do so. Now, after making some serial connection adapters for FM-7, I thought maybe now I can do it. So I tried. (Read more)
2019/01/29
A utility for FM-7/77 for loading and running tape-based (T77-image) software title via RS232C.
2019/01/24
Succeeded! Fabricating FM-7/77 series RS232C serial communication card.
I have successfully fabricated a RS232C serial communication card for Fujitsu 8-bit FM-7/77 seriescomputers. I have tested with my still-working FM-7 unit.
In fact, I also succeeded in writing a code for overriding BIOS and loading audio-tape based programs into FM-7 via RS232C. The code will be posted here soon.
2019/01/15
Updated FM-7/77 series resurrection utility.
Updated FM77AV/AV20/AV40 Wireless Keyboard Emulator Update.
2018/12/03
Updated FM-7/77 series resurrection utility.
2018/11/17
FM77AV/AV20/AV40 Wireless Keyboard Emulator Update
Released Windows XP 32bit binary, and added Auto-Typing function.
2018/11/12
Demosplash 2018 Results
Demosplash 2018 is finally over. I was preparing so hard for this event. It is one of the two events that I can showcase my collection of FM series computers. I have also submitted two programs to Demo Compo competition.
In the Demo Compo competition, my program lost just by one point to the first-place winner, a very impressive Apple II demo. That demo was truely impressive. I'll need to get back to the first place next year.
I am very worried about the recent trend of programming. It is incrementally getting more and more difficult for an individual developer to publish a program. The whole industry is hostile to such individuals. If I want to publish a program, the developer feels a pressure to swear allegiance to a big guy.
Sorry, I only swear my loyalty to FM-7 and FM TOWNS. No thanks.
In this circumstance, Demoscene is a very valuable and important place for an individual and small-group developers to publish a work.
I set up my FM-7, FM77AV, FM77AV40, FM TOWNS 2F, and FM TOWNS 2MX in the Retro Gaming room. I was claiming a Fujitsu territory in one corner of the room. By the way, next to the Fujitsu territory was territories for MSX2 and X68000 owned by CMU Computer Club.
You can download my submission that won the second place in the Demo Compo competition below.
[The Golden Age of Fujitsu Micro]
If you cannot run it on an emulator or an actual FM TOWNS, you can watch a YouTube video.
And, this is a link to the pouet entry.
I was crazy enough to write another one for FM-7 series. This time I used FM77AV40 for screening. Last time I used FM-7, and it took a few minutes to load via the audio-cassette interface. This time I was able to boot from a floppy disk, and it was quicker.
You can download the program below:
Or, you can watch a YouTube video.
And, this is a link to the pouet entry.
This time Demosplash used 2nd floor of the University Center of Carnegie Mellon University. The Retro Gaming Room was immediately next to the Demo-screening room. It was very convenient.
2018/10/18
Submitted to Demosplash 2018
I have submitted my demos to Demosplash 2018. One for FM-7 and one for FM TOWNS. My goal is to write at least one demo for FM-7 series computer and one for FM TOWNS series computer every year.
When uploading, it was recommended to include a demo video with the package. I first was thinking to use a VGA to video adapter and a video capture unit. So I ordered VGA to video adapter and a USB video capture device from Amazon.
However, I've got a problem. When I used those devices independently, both worked fine. If I connect my laptop's VGA port to VGA to video adapter to my TV, I saw my ThinkPad X250 screen on my TV. If I connect my cable-TV set top box to my GV-USB2, I was able to capture video. However, if I connect my FM TOWNS to VGA-to-video adapter to GV-USB2, I didn't see any image on my video-capture software. I trust IO DATA. I suspected the VGA-to-video adapter's signal was somewhat unstable.
I then realized Video Card III came with my FM TOWNS 2MX that I accidentally outbid in Yahoo Auction. If I run my demo in 15KHz mode, Video Card III was supposed to output a video signal. I should be able to connect my SVideo cable to the connector of Video Card III.... That was not so easy. Video Card III had 6-pin mini DIN connectors. SVideo uses 4-pin mini DIN. Turned out Video Card III's connector was proprietary. However, like a miracle, I found its pin assignments here! I ordered connectors from DigiKey. I am not particularly good at soldering. I destroyed the first connector. But, I ordered some to be ready for the failure. The second connector I was able to solder fine, and worked for a while, but soon stopped working. I disassembled again and realized my soldering was not adequate. One cable was detached. I repaired it, and made another one just in case. Then I finally was able to record the video today.
Recording from FM-7 was more of a problem, but I already had JP 21-pin SCART to HDMI converter
Demosplash 2018 will be November 2 and 3 U.S. Eastern Daylight time. Friday from 1600 and Saturday from 1200 noon. The event will be broadcasted over the Internet.
My next big release will be a next stable version of YSFLIGHT. Apple made it complicated, but macOS version finally passed all batch tests yesterday. I also fixed support for some additional MOD packages. Hopefully I can make a release by the end of October.
2018/09/16
FM TOWNS Resurrection Project: Creating an Emergency GUI Boot Floppy Disk with English Localization
2018/09/15
FM TOWNS Resurrection Project: Writing a 1.23MB formatted floppy image back to an actual floppy disk in Windows 10
2018/09/10
How to bug-fix and build an external SCSI CD driver "CDSD.SYS" for Towns OS
There seems to be more than handful of FM TOWNS are kept in working condition. But, many of them are suffering from unstable internal CD drive. An internal CD drive was what characterized and differentiated FM TOWNS from other PCs. FM TOWNS was the very first computer that equipped a CD drive as a standard device. It was not an option. All FM TOWNS came with a CD drive. Therefore, although you still have an option to boot FM TOWNS from a SCSI HD emulator like SCSI2SD, not having a CD drive is very sad condition for a FM TOWNS.
However, miraculously there are two MS-DOS drivers CDSD.SYS and CDISC2.SYS, which substitutes an external SCSI CD drive to the internal CD drive. But, CDSD.SYS binary is documented as a commercial software, and you cannot download from anywhere. And, there is no place you can buy it any more. In addition, the latest version has two bugs that prevents CDSD.SYS from running on Towns OS (although it is advertised to work with Towns.)
I fixed the bug. I made a work flow to build a binary from the source. So I made it public. I have confirmed it to work with actual FM TOWNS 2MX.
Keep FM-TOWNS alive until the last day of the universe!
2018/03/09
Retro Gaming Night 2018
Last Saturday, CMU Computer Club held an event "Retro Gaming Night". I put my FM77AV, FM77AV40, and FM-TOWNS on display. FM-7 is still being repaired. I ran some programs I salvaged by my disk2tape utility plus Plazma Line.
Maybe because of its simplicity, many visitors enjoyed playing Plazma Line, though nobody (including myself) couldn't go beyond Stage 2. I explained that this title most likely was the very first title that used polygon-based 3D rendering. So far I haven't found anyone who knew any other title for a consumer PC that used polygon-based 3D rendering before December 1984.
I kept a racing game called VSGP on FM-TOWNS. I thought it was a simple racing game that everyone could enjoy.
My keyboard emulator worked perfectly. There was no problem in playing Plazma Line with the keyboard emulator.
When I bought FM77AV and FM77AV40 this December I was not expecting I could restore these two to this level. It was nice to put some Fujitsu computers on display in this event.
2018/02/25
Restoring Plazma Line for FM-7/77
I have purchased a game title called "PLAZMA LINE" from SURUGAYA, which has arrived here thanks to tenso.com. I wanted this title when I was a junior high student. But, due to limited money I had to give up. Like Gandhara, this Plazma Line was a rare title despite its high quality.
This title was available in a floppy disk or a cassette tape. But I never found a disk version available in an auction site. The version I got this time was a tape version.
The audio cassette degrades faster than floppy disks. A tape may physically be strained. Or, it can easily de-magnetized. Worse a length of tape are touching each other and magnetize each other over time. I need to make an image that can last longer. The process I was thinking was (1) hook the end of the loader to my program and dump the main memory to the disk, and then (2) get a disk image from which the memory image is extracted, and finally (3) write my own loader. I did similar thing several times before. I once disk-nized a tape version program called "Dragon Slayer". In that time, it didn't fit in a shadow RAM of FM-7, so I had to use FM77AV's expanded memory space, and ended up making a tape-version "Dragon Slayer" for FM-7 turned into disk-version "Dragon Slayer" that works on FM77AV series only.
Also this time I auctioned a cassette data recorder from Yahoo! auction so that I can restore a rare tape-version title whenever I get hold of. A data recorder had arrived about the same time as "Plazma Line". I have already written a memory-dump program. All I needed to do was to look into the loader and modify the right place so that the program calls my memory dumper when the program is ready to start.
But, the things don't go as planned, as always. The data recorder looked healthy. The motor spins. But no tone. No tone from the speaker when I press the "monitor" button, nor nothing from the audio out. I opened the lid to see an obvious sign of loose connection or cracked solder joints, but I didn't see anything obvious. It didn't give a tone for an unknown reason. I'm a programmer. Not a hardware person. There is virtually no chance that I am able to repair electronics.
Go Plan B.
I didn't have plan B. But I had to come up with a solution. I'm a programmer. I fix it by C++. C++ is always my plan B if not plan A.
I knew my audio cassette tape recorder didn't give a good signal. But, anyway I recorded the Plazma Line tape to a .WAV file. I recorded as stereo .WAV and compared left and right. Right channel looked to have better distinctive waves. I dropped the left channel. There is a utility called WAV2T77 from Mr. Apollo's site. If I am able to fix the .WAV file good enough for WAV2T77, I should be able to read it in the emulator, and make a disk image which will be written to a physical disk.
I started writing a very user-unfriendly WAV editor.
Wave pattern from the audio cassette
recorder. The height of the waves are going up and down and inconsistent.
As you can see, the output from the audio cassette recorder seems to be giving a correct wave lengths, but the peaks are going up and down and inconsistent. Highs must be at the same level, so does lows.
Luckily I have written a library for reading and writing .WAV files already. I didn't have to start from .WAV encoder and decoder. I somehow need to transform the wave so that the peaks have the same height. To do so, I need to calculate an envelope that encloses highs and lows and scale each sample so that the envelope is stretched from -30000 to 30000. (For 16-bit samples)
I didn't want to stretch white noise part between files. It was easy to visually find the area of white noise, and I saw three files in the audio sample. White noise segments were at front, back, and in between files. Only four segments. So, I manually selected the area and zeroed the segments.
White-noise segments are easily visible.
Zeroed white-noise segments.
The next problem was correctly identifying tops and bottoms. Due to sampling noise, there are virtual peaks where there shouldn't. What to do this situation? MEDIAN FILTER! Always the median filter is a solution for a noise problem. To some level. Another good thing about the median filter is it is so easy to implement. You can do it in five minutes.
Applying median filter several times visibly reduced the noises. The envelope could be calculated by connecting neighboring tops and bottoms. For the first cut, I just used piecewise linear envelope, and expanded. With this filtering, WAV2T77 gave me a .T77 file from which I could load the first BASIC program. However, the second program, the real loader could not be loaded with Device I/O Error.
Before median filter.
After median filter.
For this problem, I knew there was a spike in the second program segment. It was clearly visible. I suspected this spike was causing the error. But, strange thing was that the program was saved on both sides A and B, and I had spike from the both side samples. It may not be the cause. But anyway I repaired the wave pattern there.
Spike (no longer looks like a spike after scaled and clamped, but it was really
a spike)
At 44KHz sampling, the 1 bit must be about 40 to 45 samples wide, and 0 bit must be about 20 samples wide. This wave is stretched to 65 samples. I deleted excess samples and fixed the wave pattern manually.
Still I had device I/O error.
Then I needed to positively identify broken bytes. FM-7 tape data stores a byte as a 11-bit wave. It must look like
0xxxxxxxx11
A byte starts with a 0 (short) wave, followed by 8 waves, and terminated by a two 1 (long) waves. If it is broken and a byte is not starting with 0, not terminating with two 1s, or has a wave that the length is not match 0 or 1, it could cause Device I/O Error.
Also the file starts with a sequence of 0xFFs. I can find a start of a file by searching for a bunch of 0xFFs.
I wrote a function that extracts a wave, identifies 0, 1, or neither, and reads 11 bits when 0 is found, and check if the byte is broken. I have checked the second file. It consists of two blocks. The first header block was ok. The tape motor stops a fraction of a second, so there is a gap. The second block following the gap was also ok. Why was I getting Device I/O Error? Maybe a check sum?
I couldn't tell, but it didn't matter because the integrity checker also gave me a dump of the first file. I could make a brand new tape image from the dump anyway. Disassembly of the dump told that the program was read to 0x7C00. It sets 0x8000 to S (stack) register. Reads the image from the third file in the tape into 0x0000 to 0x7BFF (I am wondering if it was 0x7C02), then jump to 0x0000.
So, I made a .T77 tape image for the third-file segment and tried to load by the extracted loader.
Still no luck. XM7's debugger told that the loader seems to be reading a meaningful file for the first a few bytes.
CLRA
TFR A,DP
LDS
#$FC80
JMP $362B
But, the disassembly from 0x362B appeared meaningless.
Going back to .WAV. I used the same function to check the integrity of the third file segment of the .WAV. Turned out there are many bytes that the last 11 was stretched just a tiny length. Actually either first low hump or the next high hump is stretched, and the other hump was shorter. So, as a whole it was giving a correct wave length. I manually replaced those waves with a sine wave. Also I found bunch of spikes. Looks like the median filter could not take all of the tiny bumps.
After fixing 100 waves or so, it was the time to go to a bowling league. The results were 183, 211, 181. Not bad considering an extremely dry oil condition of the lanes. The Saturday league is nothing serious. There are a few serious bowlers like me, but the rest are just recreational. The bowling alley doesn't seem to be serious either. The oil condition is inconsistent every week, and always dry. The dry condition is good for muscle bowlers who can throw very fast ball. I don't have a speed ball. The oil condition is nothing favor for me. Since my strong balls hooks too much, I am forced to use weak balls that don't give as many strikes as strong balls. You need to be a fast bowler with a strong ball, or have a professional-like precision to throw a weak ball to an exact pocket. I closed all the frames in the third game, but I didn't reach 200. I also bowl on Thursdays in Playmor, which is more serious sanctioned league. There they flood the lane with the oil. I can use a strong ball and more commonly getting 200 games.
On the way back, I was thinking what to do with the .WAV file. I didn't seem to be able to manually fix all the spikes. There are too many. Also stretched 1 bits, maybe I should relax the condition to validate a wave. Instead of checking the lengths of the low hump and high hump separately, I should only check the total length.
To remove noises leftover from the median filter, I needed to specify a good threshold. I made a list of height changes from neighboring top and bottom pairs, and sorted in the ascending order, and then flipped through by a key stroke. Height difference like 1500 looked to be a good threshold. It starts picking a real wave at 8000 or so. I deleted the falsely-identified peaks by the threshold of 1500.
A spike caused by the falsely-identified peaks.
The cause was a wrong envelope (gray) from the false peaks.
Envelope after deleting peaks with the threshold.
Final waves. No spike.
Also I changed linear interpolation to cosine interpolation so that the envelope becomes smoother.
Then I searched for the longest and shortest waves. Surprisingly, there was only one irregular (long) wave that is out of bound to be either 0 or 1. Somehow top and bottom of that particular wave was missed.
The raw recording near the irregular wave. One wave didn't have peaks.
Stretched.
Manually fixed.
Obviously, the last half of a long wave is blended with the following short wave. I could easily select the regions for the long and short waves and replaced with two sine waves. After this repair, all waves could be classified into 1 or 0.
Then I checked for the integrity, and all bytes passed! Actually I was able to extract 0x7C04 bytes. I tried to convert this WAV to T77 with WAV2T77, but failed to load. Rather, I decided to go with my dump. I could see ASCII strings like "COURSE" and "GAME OVER" and other human-readable words in the dump. I was hopeful that the dump was correct.
I knew the first a few bytes that should be written from 0x0000. It should start with CLRA. But, the dump had an extra 0 at the beginning. So, I deleted the first byte of the dump and split into two for 0x0000-0x3FFF and 0x4000-0x7C02. I wrote a 6809 code that transfers those bytes to the shadow RAM. Then, another code that transfers those bytes from the hidden RAM to 0x0000-0x7C02, and JMP to 0x0000. The first attempt failed due to my error in the assembly (I used BNE where I should have used BCS). But, in the second attempt, Plazma Line started in the emulator!
I've just played the first stage, but it worked fine.
It was released in 1980s. Just 32KB to achieve interactive 3D polygon rendering in an 8-bit computer. Very impressive. That time, there existed extremely skilled programmers. Am I at their level now? I don't know, but all I can do is keep programming, and hope to transfer some of those knowledge and skill to the next-generation programmers.
I am very happy to be able to restore Plazma Line with my C++ programming.
I have also confirmed it runs on the actual FM77AV.
I got a very rare title for FM77AV called "Gandhara" (ENIX) from Yahoo! Auction. Actually I didn't know Gandhara was ported to FM77AV then. Well, I was not too much interested in playing it, but I just wanted to preserve a rare title. There was no competition in the auction, and thanks to buyee.com, it crossed the pacific ocean.
When I first inspected the disk, I saw some areas of discoloration. I was worried about the mold. But, it just was a piece of dust. After rotating the disk one round, the discoloration was gone.
I had no intention of playing it through on the actual FM77AV. I need to save running time to keep it alive as long as possible. Also, I didn't want to use this disk in the drive too often. The disk head touches the magnetic media in the floppy disk drive. The floppy disk eventually is ground off by the head. Rather I wanted to make it a disk image that can be used in the emulator. But, to make a disk image in the format that the FM7/77AV emulator can recognize, I needed a DOS PC with an internal floppy disk drive. USB drive doesn't work. I don't have such a PC any more .....
I found it! Actually a TOSHIBA Dynabook 2002 model was mothballed in the CMU lab. My wife bought this laptop before coming to the U.S. for her Ph.D. This one was heavy and bulky, but it does have an internal floppy drive. Luckily I also had a Windows-98 boot floppy for installation, but it must be pretty much the same as a DOS. Also I had a DrDOS floppy that came with an ABit motherboard BIOS flash utility.
The battery was completely drained. I connected the power, and pressed the power button. It starts! And then I was able to boot into Windows 98 command prompt. Then copied DITT.EXE to the RAM drive, and executed it.
Nothing happened.
DITT.EXE just froze. I also boot into DrDOS, but the result was the same. DITT.EXE just froze. Then I remembered there was a utility that runs on Windows XP. It took several minutes before I found a password for this Windows XP. But, I installed NDitt and tried.
Success!! NDitt created a floppy image of Gandhara A and B disks. The advantage of the .D77 format is it can simulate sectors with CRC errors. Some copy protection checks if a specific sector is causing a CRC error. Raw disk images like an image from dd command cannot do it, and you'll need to reverse engineer and modify code to un-copy-protect the title. But, with D77, theoretically you don't have to.
Title
Playing
I wanted to play through and confirm that the image is correctly created. But, I don't seem to have time during the semester.
Instead, I tested NDITT.EXE with some other miraculously-remaining floppy disks for FM77/77AV. Well, the results were not so good. NDitt doesn't seem to be able to read contents of sectors that give CRC error. Some titles like Xanadu checks the contents of F7 sector which is giving CRC error. So, NDitt may not be good for some types of copy protections.
Anyway, it is good to have at least one environment that I can run NDitt. I need to take good care of this guy. If the hard drive dies, it may be difficult to find a replacement IDE drive at this time. Also, the internal CD-ROM drive is already dead. I'll need to start with replacing the internal CD-ROM drive.
2018/02/14
Confirmed the second drive of my FM77AV40 is also fully functional
A floppy-disk drive head cleaner, manufactured by Sanwa Supply corporation, has arrived from Japan yesterday. I have applied it to the second drive of my FM77AV40. When the computer arrived, a floppy disk seems to have been sitting in the second drive for more than 30 years. I could see the stamp of the head on the magnetic sheet of the disk. I suspected that the head would have been contaminated by the 30 years of contact with the sheet. So, I decided not to use it until I clean it, and was waiting for the head cleaner.
I could have ordered a floppy-disk drive head cleaner manufactured in the United States, but I have great faith in Sanwa Supply. I waited for a cleaner from this company. Actually it was sold in U.S. Amazon.com. Many sellers from Japan recently sells stuffs on U.S. Amazon. It is very convenient. I had a little worry about if it was really new. I didn't want to use a used cleaner, which could already be dirty from previous use. But, I have received a new cleaner as advertised. Of course, this cleaner is no longer in production. This one must be left over from a stock somewhere. Probably young people don't even know about such a product existed.
I was expecting that the drive was not in too bad a shape since the overall condition of my FM77AV40 was very nice. After applying the cleaner once, the second drive worked flawlessly. Now I have two of FM77AV series computers in my hand. It will be on the spotlight only twice a year, but I'll keep them alive as long as they want.
By the way, I tried to use my IRToy-based keyboard emulator while cleaning it, but the program didn't work this time. Turned out I was not initializing repeat-timer, and the program was not sending anything to IRToy. The issue was fixed and updates have been uploaded.
2018/01/31
Updated FM77AV/AV40 Wireless Keyboard Emulator and FM-7/77 series resurrection utility.
2018/01/24
Release FM77AV/AV40 Wireless Keyboard Emulator!
2018/01/14
Release FM-7/77 series resurrection utility.
2018/01/05
FM77AV40 crossed the Pacific
FM77AV40, which is an upgraded version of FM-7, that I auctioned from Yahoo! Auction, has arrived. I already have RGB21->HDMI converter, but in my office I only have a monitor that takes VGA and DVI. I need to wait a few more days until HDMI to VGA converter arrive to see the image.
By the way, this RGB21->HDMI converter.
Even without an image, I could test so far:
I could do all these without a monitor. This FM77AV40 came in the original box, although the box is beat up. I guessed that the original owner was taking a very good care of the computer. Only one disappointing thing was that the floppy disk was kept in for over years, probably almost three decades. The disk is already mechanically dead. Center metal part and the magnetic film severed. I can clearly see the stamp of the disk head on the film. I don't think the head is healthy after kept contact with the film for this long time. Nonetheless, if the main drive works, I can do many things with this guy. Main purposes will be the Retro Gaming Night and Demosplash. So, as long as the tape interface works, it can do most of its duty.
By the way, FM77AV series use RGB21 connector for monitor output. RGB21 connector has the same shape as Euro SCART connector. However, the pin assignments are totally different, and connecting a RGB21 device and Euro SCART device might in the worst case fry devices. On top of it, the cable looks to be a cross-connection. According to Apollo, who is extremely knowledgeable about FM-7 series, even-number pin and odd-number pins among pin 1 through 10 need to be cross-connected.
Since I knew about this information, I tested a SCART cable I purchased from U.S. Amazon.com before actually using it. It was indeed a cross-connection, but based on the Euro SCART pin assignments. My test indicated the pins of this cable were connected as follows.
Connection of a SCART
cable from U.S. Amazon.com. Not good for FM77AV. By the way should pins 17
and 18 crossed?
I don't know if pins 17 and 18 also need to be crossed, but it was crossed when it arrived. On the other hand, a correct RGB21 cable must cross connections as follows.
JP RGB21 cable connections.
Even-number pin and odd-number pin of pins 1 through 10 need to be crossed. I had no plan on getting a Euro SCART device. I disassembled and re-connected the pins for JP RGB21.
2017/12/16
FM-7 surgery didn't go well.
To solve the VRAM Blue Plane bit7 problem, I asked for help from the CMU computer club. But, the surgery didn't go well, and now I cannot read letters on the screen.
During the test after the surgery, the system didn't start and smoke came out from the board. I once gave up hope. But, the surgeon quickly found the location of short, and he recovered the system so that at least the CPU can start and run.
But, something related to the display got burnt. Now bit6 of all planes seems to be on (which used to be bit7 of blue plane.) Also the letter seems to be smeared laterally and cannot read.
However, the surgeon and other computer-club guys still have hope. They guess that one of the LS244 chips got burnt, and probably the custom chip is most likely saved. If so, they can replace LS244 chips and should be usable again. They are going to perform another inspection and surgery in January.
.... I'm tempted to get one FM-7 unit from Yahoo auction.
Actually I already purchased a FM-77AV40 from Yahoo auction, which should arrive early January. The seller says at least it turns on, but he didn't have a skill to do further checks. If the unit is damaged, it is still good because it comes with a keyboard, which is hard to find. I am determined to get one working FM-77AV unit here.
2017/12/09
Carnegie Mellon University (CMU) is famous for the Number-1 Ranked School of Computer Science (SCS). (I am working for the Department of Mechanical Engineering, by the way.) The Computer Club of CMU has members who are studying in SCS, and therefore their skill level is very high. Undergrad students write assembly code like their native language. They can fix minor hardware problem easily by a soldering iron. I'm mostly a software person. To me, their soldering-iron technique looks like a magic. If I knew about the Computer Club, I would have shipped my FM-77AV from my home instead of letting my parents throw away!
But, last summer, I found my old FM-TOWNS and FM-7 were still sitting in my parents home in Japan. I shipped them here. FM-TOWNS works almost perfectly except that sometimes the CD-ROM drive closure is not detected. Probably a switch for detecting the CD-ROM drive lid is closed
So I talked about it to my friends in the CMU Computer Club, and they asked me if I was interested in giving a talk about FM computers in this year's DemoSplash. I always like to give a talk, so I agreed. That was a fun talk to make. I enjoyed it. Actually I was hooked with the retro programming, and wrote a demo for FM-7, and ended up winning the first place in the retro category in the Demo competition in DemoSplash. That part I wrote in here.
This FM-7 was one of my few friends while I was a bullying victim. Then the bullying was not recognized as a problem therefore pretty much I had no help. I was victimized every day. Thinking back, I don't know why I didn't kill myself in that torturous days. This FM-TOWNS was my comrade who fought against the evil empire of PC-9801. I knew interactive 3D graphics was going to become the next major thing in the computing. Japanese most popular PC called PC-9801 was too low performance for the next paradigm of multi-media computing. (I personally was not so interested in watching movies on the computers, but I was interested more in interactive 3D graphics.) Unless somehow PC-9801 gave way to FM-TOWNS, the culture of Japanese computers was not going to survive into the 21st century. Well, we couldn't win the battle, and Japanese computers which were making a unique evolution were gone.
So, when I started FM-7 and FM-TOWNS, I really felt like I met with very old friends. I will keep these FM-7 and FM-TOWNS alive as long as these guys want to. There are at least two events that these guys can shine. Retro-gaming night and Demosplash. I'll run these guys next to X68000 owned by the computer club.
SCSI2SD
A friend lent me a device called SCSI2SD. He was not using it, so I can keep it for a while, until he needs it. This device emulates a SCSI hard drive. Probably young people don't know about a SCSI hard drive. It used to be a standard for an external hard drive, until USB drive became common. Anyway, this device should be recognized as a hard drive from my FM-TOWNS.
Actually this was very nice because the CD-ROM drive of FM-TOWNS may go bad any time. It already sometimes didn't sense the lid closure. By booting from SCSI2SD, I can reduce usage of the CD-ROM drive, and extend the life of it. Also the game I want to run during the Retro Gaming Night, VSGP, can be installed on the hard drive. So, I won't need the CD-ROM at all.
Well, it would be nice to run my own programs for FM-TOWNS, but most of the games are 3D shooting / flight simulator, which are not suitable for a casual gaming.
But, the problem was cables. SCSI cables were numerous before, but I didn't have any more. I ordered one from Amazon.com. The next cable problem was how to connect the SCSI2SD connector, which was for internal connection, to the external cable. I had tough time to find an SCSI hard-drive enclosure. But, I found one in eBay! It would be nice to fabricate a enclosure using this cable, but probably it's ok to use it exposed.
To use SCSI2SD, you first need to set up the device. You can go to SCSI2SD web site and download the set-up program. You plug the device by USB to a PC with no SCSI cable attached, no SD card inserted. Then you specify the hard drive specification. FM-TOWNS was from the days hard drives were measured by megabytes. Not even gigabytes. Also maximum partition size was 127MB. Can you believe it? It doesn't even store a movie. So, no matter how large your SD card is, it's a good idea to keep it small. I remembered I could use at least 512MB hard drive. I made it 512MB. Also FM-TOWNS cannot boot from the hard drive of SCSI-ID #0. It is because if something happens to the internal hard drive, the system may not become bootable unless the internal drive is disconnected. (Fujitsu didn't want to let the user touch inside.) So I configured the SCSI ID to be 1. Actually that time external hard drives were more in common, and we easily booted from an external hard drive. When I switched to a DOS PC, I was surprised how inconvenient it was. Do I have to open up the computer and replace a hard drive to boot a different operating system? Give me a break!
SCSI2SD configuration
Then I unplugged it from the PC, inserted 16GB micro SD, connected to my FM-TOWNS via two cables, and turned on. Wow! It is recognized as a hard drive!
Connection.
Yes!
It is recognized as a hard drive!
Setting
up partitions.
And
assigning drive letters.
Installing Towns OS. The iPhone5S box is for storing SCSI2SD.
FM-7
I am having tough time typing this paragraph. Microsoft products quickly became too slow too buggy after .NET and C# were introduced. Look at Microsoft Word. Aagh! Once it was a professional tool, now it's like a toy. Visual Studio! Too slow, too slow, toooooo slow!!!!! I have no business with Visual Studio, but I cannot avoid when I am answering questions from students. So frustrating. Don't get me wrong. Visual C++ is an excellent compiler. I love it. But, .NET framework should be terminated. A lesser copy of C++, called C#, should be gone.
After struggling a few minutes, I manually corrected broken HTML, and seems to be able to type again. I corrected formatting of the above paragraph. I started using Front Page 2000, so I am using Expression Web, but I am feeling maybe I should start just manually typing HTML.
What I want to say here is testing FM-7, at least making sure the CPUs are working, is easy. I say CPUs. It has two CPUs. It's an 8-bit computer from 1982, but it was already doing multi-core. Isn't it amazing? First test is, (1) Turn it on (if it comes with a disk drive, make sure the drive is empty), (2) Press "INS" key and see if the INS LED comes on. (3) Then press "INS" key again and see if the INS LED is off.
The INS LED is controlled from the SUB CPU. Unless SUB-CPU is running, you won't see INS LED turning on/off with the INS key stroke.
Then, type:
BEEP
and enter. You must see a beep if the main CPU is running.
Then, type:
PLAY "CDEFGAB"
and enter. You will hear a nice greeting tone from the PSG. By the way, if your DIP switches are set for DOS mode, F-BASIC interpreter won't start. Make sure your DIP switches are set correctly.
My FM-7 randomly started or didn't start. But, CPU looked healthy. Next problem was how to show the picture? FM-7 output was digital RGB. There's no cable avaiable, at least no new cables. A schematic of the cable for drawing RCA video signal from green-monitor connector is available in here. But, if possible, I want to have a color image. Then, I found a cable! Digital RGB to VGA cable was available from here!
A cable for connecting FM-7 digital RGB out to 15KHz VGA monitor.
Even better, they ship to the U.S. I placed an order. But, another problem is the frequency. The output is 15KHz. Virtually no new LCD monitors supports this frequency. Scan converters called XRGB series can up-convert the signal, but pricy. Then, I found an affordable one in Amazon.
15KHz to higher frequency up-scan converter for $89
I didn't know if it was going to work. I placed an order anyway. And, it worked! It only accepts 15KHz signal. It is not good for 24KHz signal. It doesn't pass-through higher-frequency signals either. But, it does the minimum required job.
The white box is the scan converter.
OK. Then, the next problem was how to feed the program into the computer. There's no floppy-disk controller extension card. Only interface available was the data-recorder interface. We used an audio-cassette to save/load programs and data back in 1982. I fabricated a cable based on the information here, and used my 2008 MacBook Pro as a data recorder, and succeeded in loading and saving programs.
Data-recorder connector pin assignments.
I never imagined I could write a program for FM-7 and run on the actual machine. It's so fun. I was using this computer when I was a fifth grader. I was too young to know mathematics and programming concepts. I have a nicer text editors. Version-controlling systems. Assembling for 6809 CPU is brazing fast on Windows.
FM-7�̃N���[���A�b�v�ƃR���f���T����
This FM-7 looked almost healthy, but there was one problem. I see blue vertical lines every 8 pixels. Reading back from VRAM, I figured that almost all bit7 of blue-plane VRAM were on. I suspected it was because of the hardware modification done on the motherboard.
I asked help to CMU Computer Club to help cleaning the modification, and they cleaned it up.
Cleaned Motherboard.
However, the blue lines still stayed. After talking with an FM-7 expert, we located the suspected VRAM chip. The computer club's soldering guru tried to help replacing the chip. But, the tragedy was waiting to happen....
Comments are welcome.
Send E-Mail to:
 |