Sunday, January 15, 2017

Classic Systems - The True Framerate

Classic color NTSC uses a frame rate of 59.94  However, classic video game consoles and home computers never adhered strictly to the NTSC standard.  Here are the exact frame rates as I have been able to find :

NES & SNES : 60.0988
GB, GBC & GBA : 59.7275
SGB : 61.1679
SGB2 : 60.0988

Apple II, Atari 2600, Colecovision, IBM CGA, PCjr., Tandy 1000, EGA @ 200, MSX, SMS & Genesis : 59.9275
Commodore 64 = 59.862

Hercules Graphics : 50.050048
IBM VGA : 70.086303
IBM VGA 640x480 : 59.940475

Gamecube & Wii : 60.00222p/59.88814i

How do you calculate the exact frame rate?  You do it by discovering exactly how long it takes for the console to output all the pixels it sends to the TV each second and divide that by the number of pixels per line and the number of lines per frame.

Let's start with True NTSC.  The colorburst frequency is 3,579,545 Hz.  That represents the number of times the color can change in a given second.  True NTSC outputs 262.5 lines every odd and even field.  The half line tells the TV tube to draw an odd field or an even field.  Each line of an NTSC display has 227.5 color clocks.  This was chosen to minimize interference with the luminance and audio signals.  The frame rate is = 3,579,545/227.5/262.5 = 59.94 Hz.  The line rate is 59.94 * 262.5 or 15,734.26 Hz.

For consoles, the calculation is almost identical, but the figures are not.  First, we need to know the total number of lines output by the device every frame.  Classic consoles and computer adapters typically output 262 or 263 lines to avoid telling the TV to interlace.  No classic NTSC device used that many lines as part of their active video.  Typically only 192, 200, 224 or 240 lines were used. The Atari 2600 is unique in that unlike other devices, it does not have modes with a set number of lines.  It is up to the programmer to tell its graphics chip, the TIA, to send a vertical sync signal to get the TV beam back up the screen.  Although 262 lines was the standard, games more often than not output lines other than 262.  Some games output so many lines that some modern TVs get confused and think they have a PAL signal!  Here is a list of games and the lines they output :

http://www.digitpress.com/library/techdocs/vcs_scanlines.htm

Next we go to the trickier part, we need to figure out how many color clocks and how many pixels are being sent for each line.  Typically, the number of color clocks consoles use are 228.  Usually the console is sending pixels at some multiple of the color clock rate.  The Atari 2600 sends one pixel per clock, but only 160 of those pixels are active.  The Apple IIe and IBM CGA can send one, two or four pixels per clock.  The Sega and Nintendo 8-bit consoles usually send 1.5 pixels per clock.  Their graphics chips run at 5,369,317.5 Hz, 1.5x faster than the colorburst.

So for the Sega 8-bit console, it is outputting 342 pixels for 228 color clocks.  This gives us the following formula  : 5,369,317.5/342/262 = 59.9275 Hz

The Apple II High Resolution and the IBM CGA 320x200 modes are outputting 456 pixels at 7,159,090 Hz.  The calculation remains the same.  In the Apple IIe/IIc double high resolution mode or the IBM CGA 640x200 mode, both the rate and the number of pixels are doubled again, but the refresh rate remains the same.

Let us consider the C64.  The NTSC C64 outputs 8 pixels per cycle and uses 65 cycles per line.  In other words, it is outputting 520 pixels per line.  It does this at 8,181817 Hz.  It displays 263 lines per frame, that gives a framerate of 59.826Hz.

The NES and the SNES act similarly to the SMS and Genesis, but have two important differences.  First, while they output 1.5 pixels per color clock, they output 341 pixels, not 342.  341/1.5 = 227.33 color clock.  As a result, there is a staircasing effect every three scanlines for color objects because each line is offset a third of a pixel from the previous line.  Black and white pixels are unaffected, since they don't care about NTSC color.  Second, the number of pixels output changes by 1 for the last scanline of every frame.  On odd frames, the last scanline has 341 pixels, and on even frames the scanline has 340 pixels.  Nintendo did this to reduce composite color artifacts, but on non-CRTs it makes for a very gritty display.

Because of the 1-pixel difference, here we calculate by the total number of pixels per frame.  That is (341 x 261) + 340.5 =  89,341.5.  The formula becomes = 5,369,317.5/89,341.5 = 60.0988.

The Game Boy doesn't care about NTSC color, so its calculation is done differently.  The Game Boy runs at 4,194,304 Hz or cycles per second.  It draws a frame in 70,224 clock cycles (not machine cycles!).  4,194,304 / 70,224 = 59.7275 Hz.  The Game Boy Color runs twice as fast and draws a frame in twice as many cycles.  Ditto for the Game Boy Advance except that now it runs four times as fast as the Game Boy and takes four times the cycles to draw a frame.  The Super Game Boy uses the SNES master clock signal (21,477,273MHz) divided by 5 to run at 4,295,454 Hz.  Because the Super Game Boy still takes 70,224 cycles to draw a frame, it draws 61.16 frames per second.  The Super Game Boy 2 does not use the SNES for a clock source, it has a Game Boy 4,194,304 clock in the cartridge, but it is still accelerated by the SNES to its framerate, not an LCD Game Boy's.

Sunday, January 8, 2017

YouTube Playthrough and Demonstration Series

This Christmas, I got a capture device.  The device in question is an I-O Data GV-USB2.  It can accept composite or s-video input and has stereo sound inputs.  The manual is in Japanese but the drivers are in English.

One of the reasons why I acquired this device is because I found a disturbing lack of video game footage captured from real hardware on YouTube.  While there are plenty of playthroughs or longplays of various games, many of these are from emulators.  Footage directly captured from consoles tends to be older and is reduced to 30 frames per second.  The heyday of 480i/30 frames per second was the Playstation 2 era.  Before the Playstation 2 and the Dreamcast, it was not often used and almost never used by the SNES or Genesis.  They used 240p and ran at 60fps.  So did many vintage computers from Apple, TI, Commodore and Atari.  Even 320x200 256 color VGA graphics is just double-scanned 240p.

As many people know, 240p is a hack of 480i.  TV tubes were designed to display 480 interlaced lines 60 times per second (in NTSC countries).  The odd lines of an image would be displayed, followed by the even lines of an image and your eyes would see fluid motion.  30 times per second the TV would be drawing odd lines and 30 times per second the TV would be drawing even lines. 240p works by telling the TV to odd lines always, 60 times per second. Because the even lines are never being drawn, there is a space between the lines which can be noticed at times as scanlines.  The console or computer is sending a complete frame for the TV to draw on the odd lines.

240p works in every regular NTSC CRT TV.  It is not used in broadcast TV or on home media, whether it is VHS, DVD or Laserdisc.  The resolution of a 240p signal is too poor for lifelike images but perfect for video game pixel art.  Fortunately, most composite capture devices will capture a 240p signal, but these devices treat it as an interlaced 480i signal.  My device treats the lines from the first frame as the odd frame and the lines from the second frame as the even frame and the monitor usually displays both at the same time.  Motion will show interlaced artifacts when the the image is no longer the same from frame to frame.  Thanks to AviSynth's SeparateFields function, you can recover the full 60 frames from an analog video capture.

YouTube is a useful source of acquiring game information.  Unfortunately the number of game videos using an emulator vastly outnumbers the number of videos using real hardware.  Moreover, most of those real hardware videos were posted prior to YouTube's 60p support or simply don't bother to do a proper conversion.  Because YouTube only supports 60p with a 1280x720 or better resolution (1920x1080, 2560x1440 or 3840x2160 currently) they need to be upscaled properly.  This I have learned how to do in order to give the best presentation of videos I can.

I have put several videos on YouTube already at the time of this writing, captured from my real hardware.  I am initially going to place my videos into two categories.  Each will be added to a playlist.  The first category of videos will be Playthroughs, where I show a game from its beginning to its completion.  Most of these playthroughs will not win me any awards in the speedrunning or no-hit or no-death categories.  The second category will be Demonstrations, where I show off a substantial portion of a game I cannot beat or I just want to demonstrate some interesting feature or effect from a game.

Capturing Atari or Famicom requires routing the RF video through a VCR, which converts it to composite video and audio.  TV tuner devices with an analog coaxial screw do exist but they often have severe problems with the kind of RF output by a video game machine.  A VCR will output proper composite video and separate audio.  While it won't look or sound any better than the RF output, it is simple to capture.

NES video will look very gritty.  The NES not only offsets each line by 1/3 of a pixel for every three lines, the odd frames are shifted one pixel compared to the even frames.  This makes the image sharper than the Sega Master System but it also less friendly to analog capture devices. It is the nature of the beast, the only improvement I could conceivably do is to mod a system with a NESRGB board.  The NESRGB board will output S-Video.

For SNES video, I am fortunate to have an official NES S-Video cable, so the output will look not only significantly sharper than NES video, but it won't have that three-line stairstep caused by the filter inside the NES PPU.  Unfortunately, I do not have a modded 1-Chip console, so it will look a little fuzzy.

Sega Genesis video will show lots of artifacting, which many Genesis games employed to show more colors than the system could officially display.  Sonic 2 in particular goes nuts with this to show transparencies.  Even the Master System could have issues with artifact colors.

IBM PC CGA captures can use old CGA or new CGA cards, but I discovered a simple trick to tame old CGA cards so they can be captured : https://www.youtube.com/watch?v=8k-U4LiL4GI I have also captured from the IBM PCjr.'s composite output.  While I could capture from the Tandy 1000 SX or TX's composite output, I find that its composite output is very washed out compared to CGA or PCjr.

Game Boy captures will have to be done with a Super Game Boy for now.  Someday soon I may be able to acquire a Super Game Boy 2 from Japan for proper speed.  I also hope to acquire an SD Card Launcher for the Gamecube so I can use my Game Boy Player with the Game Boy Interface Ultra Low-Latency version for true 240p captures.

Before I acquired my capture device, I thought I could perhaps do this using a camera pointed at the TV screen.  This simply didn't work for a variety of reasons, although I do have a few videos up where I believe it is important to show some physical hardware or feature that cannot be experienced through a capture card.

I considered whether I should add commentary to my videos.  Often game commentary is mostly about filling dead air with talk.  Talking masks game audio.  If YouTube had a commentary track feature that could be turned on and off I would consider it.  Since it does not, I believe that a game's audio is preferably to my nasal tones.

So far, I have used footage of games that can be completed in about an hour.  There are games that take hours upon hours to finish. While YouTube can host 10 hour videos, I cannot store 10 hours of YUV-encoded video on my system!  Well I can, but it will have to be precompressed which limits the resulting video quality.  So for now, that playthrough of SNES Final Fantasy III will have to remain something of a long term goal.

Here are the links to the playlists.  First are the Demonstrations :

https://www.youtube.com/playlist?list=PLvqpAsa7-dlxkXzRZIo3pn_BHSuGG_iWe

Second are the Playthroughs :

https://www.youtube.com/playlist?list=PLvqpAsa7-dlzF0dR7Wzi1tWD7jeD37oBt

Monday, January 2, 2017

Sega Genesis - Is the Stinker really that bad?



Official Sega Genesis and Mega Drive consoles vary quite a bit in terms of their built-in sound quality.  When I was looking to acquire a Genesis several years ago, I read that the conventional wisdom was that the original Model 1 was the one to get because it had the best sound quality and did not have the TMSS copy protection scheme.

The original Model 1 is the one with the headphone jack and mono line audio output.  I did not know at the time that there were Model 1s with the High Definition Graphics text and Model 1s without the High Definitions Graphics above the cartridge slot.  The one I acquired did not have the High Definition "HDG" text. Sometime thereafter, I found out that the non-HDG Model 1s had such terrible sound quality compared to HDG Model 1s that they have been given the nickname "the Stinker."  Faced with this reputation, I quickly bought myself an HDG Model 1.  I believed that all HDG consoles would not have TMSS, but the one I got did.

Model 1 of the Sega 16-bit console had several motherboard revisions, as had its successor the Model 2.  Using the information here : http://www.sega-16.com/forum/showthread.php?7796-GUIDE-Telling-apart-good-Genesis-1s-and-Genesis-2s-from-bad-ones, I have created this table identifying the distinguishing features of all models of the Sega 16-bit console where such information is known :

Monday, December 26, 2016

Community Produced DOS Game Enhancement Hacks

In the past several years, ambitious and talented programmers and hackers have made some substantial improvements to some classic DOS games.  Here in this blog entry I will highlight some of the hacks I consider to be the most impressive or most useful.  I am particularly interested when elements of a game, such as unique sound effects, that could have been experienced at the time of the game's release in a less than ideal way have been added to the DOS versions of these games.

This is not intended to be a comprehensive list of every hack out there.  I am not including simple speed fixes or DOSBox compatibility patches.  I also am not including any hack which I feel violates the "spirit" of the original DOS code.  Some of these hacks are more involved than others, but I wanted to give an overview of what kind of hacks are out there.   Some of these hacks are nearly 10 years old, but all were given to an organized community of vintage computer and DOS gaming enthusiasts.


Sunday, December 18, 2016

Getting a Roland/Edirol UM-1X and Windows 10 64-bit to Work Together

About ten years ago I found myself in need of a hardware MIDI solution for my Windows XP machine.  At the time I had a Sound Blaster X-Fi in the machine, but it did not have a hardware MIDI IN and OUT port.  The add-on that would add these ports was very expensive at the time, but I needed a hardware MIDI solution to use my Roland MIDI modules such as the CM-500 I had at the time.  A less expensive solution was a USB MIDI interface, so I decided to buy one.  The one I bought was the Edirol/Roland UM-1X, and it was not particularly inexpensive but I figured I needed a good quality solution for non-GM devices like the MT-32.

The UM-1SX is the same interface as the UM-1X but you need to plug in your own MIDI 5-pin cables.  There were earlier UM-1 and UM-1S, which appear to function identically to the UM-1X and UM-1SX except they do not have the Advanced Driver Switch on them.  After the UM-1X is the UM-1EX, which adds a switch for toggling MIDI OUT and MIDI THRU functionality and the UM-2EX, which adds a second MIDI OUT.  After the 1EX and 2EX came the UM-ONE and the Roland UM-ONE mk2.  The UM-ONE mk2 is the only one of these products which is not discontinued.  The ONE and the ONE mk2 are the only one of these interfaces that have Windows 10 drivers.  The rest have drivers only until Windows 8/8.1.


Wednesday, December 14, 2016

Windows 3.0 Multimedia Edition - Early Windows Multimedia Gaming


Microsoft Windows 3.0 was the first widely adopted and truly successful version of Microsoft's graphical "Operating System."  It was released on May 20, 1990 and came on five 1.2MB floppy disks.  It could be purchased in a box and was the first version of Windows that was noted for being bundled with new PCs.  It had an incremental update, Windows 3.0a, released on October 31, 1990.


Thursday, December 8, 2016

Spin the Knob, Roll the Ball, Drag the Puck : Rotary-Based Video Game Controllers

A rotary encoder is a wheel that sends positional information as it is moved.  The rotor or disk looks like a wheel with spokes and holes.  The wheel is attached to a shaft which is moved.  The movement can be tracked electromechanically or optically.  Electromechanical rotary encoders send information as an electrical circuit is made and broken by movement of the rotor.  Optical rotary encoders send information as the spokes and holes of optical transmitter/receiver allow and break an infrared beam.

A rotary encoder can be found at the heart of several input devices, namely spinners, mice and trackballs.  The earliest arcade spinners, such as those found on Pong and Breakout, were just knobs stuck on the shaft of a potentiometer.  Movement would typically be calculated by measuring the charge or discharge time of a resistance/capacitive circuit. These knobs could be moved in either direction to a stopping point, they could not perform a full 360 degree rotation.


Monday, December 5, 2016

Diagonsing and Fixing DOS Games - King's Quest VI and the Sound Blaster 16

On Friday, I sat down at my 486DX2/66 computer and decided to play a little King's Quest VI: Heir Today, Gone Tommorow.  KQ6 is definitely one of Sierra's best games and it had been a long time since I last tried to play it through.  I had the floppy version installed on my hard drive, so I started up the floppy version.  Unfortunately, it took the whole weekend to track down the problem and implement a solution for it.