Please enable JavaScript to display the menu.

2019

ysflight.com

Please enable JavaScript to display links.

YS FLIGHT SIMULATOR Version 20181124

Not all programs in YSFLIGHT.COM are open source.  But, you can download some of the source code from the following URL.

https://github.com/captainys/public

When you try to run a program downloaded from this web site, you may see a warning like "This program is not digitally signed."  Code signature was invented for improving the computer security.  However, it added a new (and evil) purpose now, which is to decimate individual developers like myself.  A code signature used to be unreasonably expensive.  But, now it is not just expensive.  No matter how much money you pay, a code signature is not issued to an individual programmer.  It is obviously an infringement of freedom of publishing a software.  But, I can do nothing about it.  My main job as a programmer is secure even if one day I cannot publish a software, but what a boring world would it be?

2019/04/18

Can a Cessna 172 Save Retro PC Games? (Failed)

Actually I flew for this mission last December.

If you are visiting the top page of YSFLIGHT.COM, you should know that I am preserving historic Fujitsu 8-bit retro computers in working condition.  I kept some floppy disks and cassette tapes that I used back in 1980s.  Also since it got very easy to bit on Yahoo! auction I often bid and win those floppy disks and cassette tapes.

If I just want to play them, we see some re-created version for Windows, or it is not difficult to find a disk image or a tape image online that works with an emulator.  But, I noticed that the one I can download is often corrupted.  If not corrupted, the emulator is not emulating the copy protection, but the copy-protection code has been cracked on those images.  I personally think those copy-protection techniques are also a part of computing history, and if possible I want to preserve those historic titles including the original copy-protection.  Ideally I want to find a museum or a library that can permanently store and preserve those historic hardware and software.  In Japan, Game Preservation Organization is actively protecting those Japanese software legacy.  But, it is better if those software titles are stored in distributed locations.  If some are preserved in the U.S., that would be very nice.

(Read more

2019/04/16

Watching Cherry Trees from the Sky.

Japanese community in Pittsburgh has been working with Pittsburgh Park Services and planting cherry trees in North Park.  2019 is the 10th anniversary of the planting.  I'm not directly involved, but I have flown over the park for aerial photography from time to time.  It is one of the best privilege of pilots to see four seasons changing from the air.  (Read more)

Fujitsu Retro PC:

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 

Fujitsu Retro PC: 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)

Fujitsu Retro PC: FM77AV Keyboard Emulator

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.

BONDIC

I've already saved two rocking flowers with BONDIC.  I have tried various different types of adhesives but this one is universal.

AA

Boeing 737 MAX-800

Some topics came to my attention.

One of the TWO?  Sounded to me the MCAS system has such an important part of the auto-pilot.  Even Boeing dropped its long tradition of Yoke Jerk functionality and gave priority to the MCAS over the human pilot.  And, it was taking only two inputs?  The first aircraft that had an operational digital fly-by-wire computer control was F-16.  F-16 had 3 control computers, each of which were taking airspeed information from an independent Pitot tube.  If one of the three Pitot tubes failed physically or iced up, the computer takes votes and go with democracy.  Having three separate systems improved the reliability of F-16.

If there are only two inputs, it is good for a human pilot because a human pilot can identify which one failed.  We are trained to cross-check instruments.  From the computer point of view, having two input doesn't give redundancy.  When one fails, it doesn't know which to trust.  Still Boeing might have made an decision that the AOA sensor is unlikely to fail.  I can only guess.  But, I don't know if having only two AOA sensors was a good idea.  It's a very un-Boeing-like case.

I am seriously worried about the wrong trend of programming.  Too many programmers are thinking they can just release an incomplete software and then release updates to fix errors.  It is utterly wrong.  Even for-consumer products it is wrong.  Users are not specimen.  The trend can be contagious.  If this wrong mentality is contaminating the control-software developers in the aircraft design field, I hope it is not the case, but it is scary.  Someone needs to stop this wrong trend.

03/12/2019

Un-Boeing-like Accident?

We don't know if the crash of Ethiopian Airline B-737 Max 8 was caused by the same cause as Lion Air's crash a while ago.  However, even if the causes of the two accidents are different, the background of the accidents maybe traced back to the change of the design philosophy of Boeing.

Lion Air's accident reminded me of an Airbus 300-600R crash at Nagoya airport in 1994.  I don't know if you remember, but the crash was obviously from the design error by Airbus.  Airbus 300-600R in go-around mode, mixed control-input from the human-pilot and auto-pilot together.  Auto-pilot controlled the pitch trim, and the elevator input from the pilot controlled the elevator.  On April 26, 1994, the pilot of Airbus 300-600R accidentally pulled the go-around lever, setting the airplane into the go-around mode.  The pilot wanted to continue landing, but the auto-pilot pulled the nose up to go around.  The pilot pushed the yoke harder, fully deflecting the elevator to the nose-down position, while the auto-pilot moved the elevator trim to nose-up position to counter the elevator.  Eventually the elevator trim overpowered the human-pilot.  At that time, the aircraft no longer could lower nose.  The aircraft climbed violently, stalled, and then crashed killing all souls on board.  The obvious cause was that the aircraft could be put in a state that mixed input from the auto-pilot and the human-pilot together.

On the other hand, Airbus did everything to deny the design error.  They announced right away that the accident was caused by the human error.  Their point was since the human-pilot may make a mistake, the auto-pilot must be trusted in case of emergency.  Therefore the accident was caused by the human error.

You don't have to be a Ph.D to understand Airbus's logic was absurd.  We can discuss if the input from the human-pilot should be prioritized over the auto-pilot or vise-versa.  Both human-pilot and auto-pilot has some probability of making a mistake.  We need to bet on one of them.  Human cannot make accident absolutely zero.  All we can do is to minimize the probability of an accident.  If, as Airbus said, Airbus took a bet on the auto-pilot, and the human-pilot happened to be right, it was unfortunate, but not a design error.

Well, let's say Airbus was right that the auto-pilot should be prioritized.  Then, the inputs from the human-pilot and the auto-pilot must not be mixed.  If Airbus wants to trust the auto-pilot over the human-pilot, input from the human-pilot should be shut off.  Or, if they trust the human-pilot over the auto-pilot, the input from the auto-pilot must be shut off.  In either case, the inputs must not be mixed.  However, Airbus 300-600R mixed them in go-around mode.  Therefore, it was an obvious design error.

To my surprise, Japanese counterpart of NTSB, accepted what Airbus was saying and concluded that the accident was caused by the human error.  Hello??  As a Ph.D in Mechanical Engineering, I think it is obviously caused by the design error.  Airbus should have been held responsible.  By the way, Airbus should have kept Concorde flying instead of developing A380.

I guess someone working for Japanese NTSB got richer.  Airbus probably made a secret change in the control system of Airbus 300-600R.  Typically it is called an SB, or Service Bulletin.  No similar accident was reported after this Nagoya accident.

<- I've restored Amazon Affiliate Link.  I appreciate if you use this link when you buy something from Amazon.com.

Anyway, the Boeing's reaction to this accident was this:  Boeing trusts the human-pilot over the auto-pilot in case of emergency.  Therefore a similar accident is impossible in Boeing aircrafts.

It was supposed to be.

I had some chances to talk with employees of Boeing before in conferences.  They were saying Boeing likes pilots, and they trust the pilot in case of emergency.  They never employ side-stick because pilots love control yoke right in front of the pilot seat.  Boeing aircrafts disables auto-pilot and complies with the pilot's input when a strong pressure is applied to the control yoke.  Boeing was always pilot-centered.  That's what I heard then.

But, what about Lion Air's accident?  The reaction from Boeing was a copy of the reaction from Airbus after the Nagoya accident.  Boeing said that the solution was to make sure the pilot was informed and trained to deal with this situation.  No, it's not.  I wouldn't say it is an design error.  The human-pilot may make an error in case of emergency.  It is true.  If the design philosophy trusts the auto-pilot over the human-pilot, it is a valid philosophy.  There is not right or wrong.  But, we need to keep in mind that the computer may make a mistake, too.

I'm a programmer.  I know that a programmer makes mistakes because I make mistakes.  I'm not the god.  A control program used by the auto-pilot is written by a human-programmer and may include an error.  It is nothing to surprise if the auto-pilot makes an error.  Just like trusting the human-pilot will never eliminate an airplane crash, neither trusting the auto-pilot will never eliminate an airplane crash.  All we can do is make an airplane crash less likely to happen.

Which philosophy do I like?  Obviously I would trust the human-pilot.  A human-pilot can better adapt to an unknown flight condition.  But, if the auto-pilot steps on the programming error, it cannot correct itself.  Well, we can theoretically make it wireless-updatable.  But, do you want to start updating the control software of an airplane while flying?  "The flight-control computer needs reboot.  It would take 10 minutes to restart."  Would you click "Yes" to this?  Machine learning?  It does good, if the flight condition is an interpolation of the known training conditions, but it may go berserk if it happens to be an extrapolation.

So, I liked the Boeing's pilot-centered design.

In Lion Air's crash, the human-pilot tried to pull the nose up while the auto-pilot was trying to dive.  The auto-pilot was thinking the aircraft was about to stall.  The pilot was trying to prevent the aircraft to dive into the ocean.  From the aircraft point of view, it had no idea who was right.  In the aircraft-accident history, there were numerous cases that the human-pilot ended up pulling the nose up too high and stalled and crashed.  The aircraft trusted the auto-pilot.  And, the auto-pilot happened to be wrong this time.  It was unlucky.

Again, it is not a design error.  Both the human-pilot and the auto-pilot can make a mistake.  Who to trust depends on the design philosophy.  If the design philosophy trusts the auto-pilot over the human-pilot, it is a choice, not an error.  I don't like it though.

If Boeing trusted the human-pilot like it did before, Lion Air's accident could have been averted.  If current Boeing trusts the auto-pilot over the human-pilot, it is not an error, but I feel it is unfortunate.

03/03/2019

Trying to release a YSFLIGHT Demo for Android, but...

I have succeeded in running YSFLIGHT kernel on Android several months ago.  Alghouth it is not playable yet, I thought to release a demo-only version.

Since I have a new laptop now, I installed the latest version Android Studio.  As expected it could not build from a project set up by an earlier version.  Evidently, Google doesn't even running a unit-test of building a project from earlier-version Android Studio.  That's the way grad students write programs.  (No unit tests)

This is exactly the major problem of Android development system.  It changes.  It changes way too often.  Now many developers seems to be thinking frequent update is a good thing.  It is a huge mistake, as huge as a red-giant about to explode into a supernova.  If a software is coming close to its goal, it gets stable and has less-frequent updates.  If something needs to update frequently, it is an indication that the thing is bad.  It needs update because it is disgusting.  From my observation, Android Studio is a crap.

It's not just Android Studio.  Too many too often updates.  I want to shout "DON'T UPDATE!!!!"  Seriously I want developers to take time to make a secure and robust code that needs fewer updates.  Current trend of releasing pre-mature and updating later attitude is toxic.  The current trend of software development is quite deplorable.  That's not what I learned.  People may call me outdated.  But, if releasing a crap pre-mature software is the trend, I proudly stay outdated.

Fix for this problem was easy.  I entered the exact error message, and Google took me to the solution.  I wish Google didn't create this problem for the first place.

But, the program was running extremely slow, most likely because I compiled in the debug mode.  I changed the configuration to release mode and tried to test on the emulator, then I was told I needed to sign the code.  The APK file was indeed named as something-release-unsigned.apk.

Argh!  Code signature again!  The main purpose of this code-signature thing used to be for good cause, but now is to decimate individual developers in the name of security.  It's evil.  I followed an instruction to make my developer signature which presumably won't be accepted by the Play Store.  But, it's ok.  My plan is to upload my APK here.  I have no business with Play Store.

But, Android Studio keeps trying to run something-release-unsigned.apk and keeps complaining that the APK is not signed.  Android Studio could not see somthing-release.apk which d**n Android Studio has just built by itself seconds ago.  I force-deleted the something-release-unsigned.apk, but Android Studio only complains file not found.

The time is up for the day.  I reverted all the changes except the fix for the new version Android Studio.  Will try again.

03/02/2019

Added Night Solo.  (Although this flight took place a month ago.)

I flew a night-solo for the first time since November of 2013.

Original plan was to take my wife with me, but she got a cold.  I thought about cancelling it, but her condition improved, but not good enough to go flying with me.  So I flew solo.

(Read more)


 

02/23/2019

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)

02/15/2019 

Heard Airbus stopped building Airbus 380.  They should have modernized Concorde and kept them flying instead, or at least kept Concorde flying :-P

I reluctantly tried to upgrade my Ubuntu 14 in my virtual machine to Ubuntu 16, ending up destroying the desktop.  No icon, no menu, no Terminal opens with Ctrl+Alt+T.  Utterly broken.  I am not that familiar with Linux that I can log in single-user mode and correct settings.  I can choose to revert back to back-up Ubuntu 14, or otherwise only option looks to be clean re-installation, absolute waste of time.  I end up going through absolutely unproductive and unpleasant waste of time regular basis.

Linux is still extremely brittle.  It never gets solid.  If a major update breaks the settings so easily, I want Linux developers stop major updates.  I want security updates, but I don't want major updates.  Does anyone want a new version of an operating system?  I don't know anyone looking forward to a new version operating system.  A new version, from time to time, makes perfectly healthy hardware unusable by making changes to the device-driver model that I never asked for.  Kills good programs by making unnecessary changes in the kernel.  When there is major hardware updates, I understand it is inevitable.  But, did we have one in the recent years?  I am not aware of any.  For the past many years, the same thing has been just getting faster.  No major changes in the hardware.  Major upgrade of an operating system is always a nuisance to me.  If they keep doing what customers don't want, nobody will use their product eventually.

01/29/2019

A utility for FM-7/77 for loading and running tape-based (T77-image) software title via RS232C.

01/24/2019

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.

 

1/15/2019

YS FLIGHT SIMULATOR Version 20181124 Available for Download!

Thank you for your patience!  YSFLIGHT Ver 20181124 is ready for download!

Added Fujitsu FM-7/77 Disk Image Write-Back Utility

Updated FM77AV/AV20/AV40 Wireless Keyboard Emulator.

1/13/2019

Thank you for your patience!  YSFLIGHT Ver 20181124 is ready for download!  Major changes are as follows.

- Shadow mapping in OpenGL 2.x version.
- Particle rendering for clouds and smokes.
- Particle rendering support in OpenGL 1.1 and Direct3D9 executables.
- Added Air-Racing mode. Quite primitive, but it at least measures time to pass all check points for you.
- Massively and automatically tested add-ons. I hope the ones stopped working now works again.
- Stopped using Windows installer. I am tired of it.
- SRF models in .FLD file. Older preliminary implementation was checking bounding-box collision, but it now check polygon-by-polygon collision.
- Separated ILS view and Tower view (I think I made it back to same as previous versions.)

When you try to run YSFLIGHT, you may be seeing a security warning from your operating system stating that the executable binary is not code-signed.  The purpose of he code signature is to confirm that the program is written by a known person and not altered by a malicious hand.  The purpose itself is very correct.

Information security is extremely important.  There is no question about that.  We hear security breaches, stolen information, identity thiefts, and all sorts of crimes.  Many of those incidents originate from a malicious program.  Of course, the responsibility is primarily on a person who wrote such a malicious program.  Such a programmers should be locked for life without parole.

But unfortunately there are even more cowardly groups of people.  There are some companies called certificate authorities who are responsible for issuing digital certificates including code-signing certificates.  Those companies are taking advantage of the security problems and cowardly trying to decimate individual free-software programmers.

Code-signing certificate used to be too expensive for individuals.  Most of them used to cost like $500 per year.  Not just one-time payment every year you have to pay.  I wanted to get one for my projects.  Yeah, it is not impossible to pay $500 per year, but I couldn't justify to do it for my free-software projects.  This time one of the long-time YSFLIGHT users raised a concern about the security warning.  So, I did shop around again.  I then found $179 per year certificate from COMODO.  I paid for it, only to hear that they no longer issue a certificate for individual developers.

I looked into other major certificate authorities, too.  None of them issues a code-signing certificate to individuals any more.  They apparently are united and are trying to destroy individual developers.  It is not just unaffordable.  It is now impossible for an individual developer to get a certificate.  It is not right.  I don't understand how it is allowed.  The certificate authorities are intentionally trying to decimate individual programmers like myself.

Therefore, it is not what I like, but I am not able to sign my programs available from YSFLIGHT.COM.  I just release my programs without signature.  I can do nothing about it.  Probably those cowards will win.  Individual free-software developers will eventually extinct.  All I can do is to tell what's going on on this web site.

1/6/2019

Still no words from Vector.co.jp.  For the meanwhile, folks outside Japan can download YS FLIGHT 20181124 version from download.com already.

First Flight of the Year

I flew from Beaver today.

I had to cancel flight so many times due to bad weather.  I hope we have more flyable days this year.

I flew a local flight from Beaver.  I haven't practiced maneuvers for a while, so I thought to practice some this time.  After flying steep turns a few times, I noticed another airplane came into the proximity and started practicing maneuvers.  I think he was doing Power-On Stalls.  I picked a large gap of the clouds and climbed through it. 


FM TOWNS Internal SCSI connector pin assignments

If you are an owner of a classic Fujitsu PC, FM TOWNS, and if you are trying to put your hard-disk emulator such as SCSI2SD internal, WAAAAAAIT!!!

Do you have an adapter to be inserted between your SCSI2SD and FM TOWNS' internal SCSI connector?  Aren't you trying to directly connect your SCSI2SD to the internal SCSI connector because it is a rectangular 50-pin connector just like a standard SCSI connector?

DON'T DIRECTLY CONNECT YOUR SCSI DEVICE TO THIS CONNECTOR!!  MOST LIKELY YOU FRY YOUR DEVICE OR FM TOWNS OR BOTH!!

You need to insert an adapter between the FM TOWNS' internal SCSI connector and the SCSI device.

(Read more)

 

 

 

Comments are welcome.  Send E-Mail to: 

Back to http://www.ysflight.com