Thursday, May 18, 2023

Random Computer and Video Game Musings

Sometimes I have something to say but the topic is not worthy of a full blog post.  In this case I have gathered four topics which I believe are interesting but not necessarily related and put them into this consolidated blog post.  Enjoy!

Nintendo & Sega - Each Missing a Generation

Nintendo and Sega became fierce rivals when their systems competed in the 3rd Generation with the NES and Sega Master System, the 4th Generation with the Genesis and SNES, the 5th Generation with the N64 and Saturn.  They might have competed in the 6th Generation but the Dreamcast was cancelled before the GameCube was released.  But their entries in the 1st and 2nd Generation of video game consoles did not have an answer from the rival company.  

From 1977-1979, Nintendo released five fixed-game consoles, the Color TV-Game 6, Color TV-Game 15, Color TV-Game Racing 112m, Color TV Game Block Kuzushi and Computer TV-Game.  These consoles were essentially Nintendo's version of Pong clones and similar video games of the 1970s which played only their built-in games and generally did not include microprocessors.  Pong systems are included in the 1st Generation of Video Game systems.  Nintendo did not release another home console thereafter until the Famicom.

Sega did not appear to release dedicated home video game consoles in the home market during the 1st Generation era.  Its SG-1000 console has nearly the same capabilities of the ColecoVision, which is indisputably a (late) 2nd Generation console.  Unfortunately for the SG-1000 it was released the same day as the technologically superior Famicom (July 15, 1983) which ushered in the 3rd Generation in Japan two years before it established that generation elsewhere.  The SG-1000 had good early sales while the Famicom suffered from teething problems in its first year, but by the end of 1984 its fate was sealed to 2nd place and even superior consoles like the Mark III could not put a dent in Nintendo's dominance.

It should be noted that Sega published games for the Atari 2600 and Coleco ported Nintendo games like Donkey Kong to the Atari 2600, Intellivision and ColecoVision.

Famicom Games with No Expansion Port Controller Support

From launch day Famicom games supported reading not only the two internally wired controllers but also controllers plugged into the expansion port.  Famicom gamepads are serial controllers and each require one data line to transmit the state of their buttons sequentially to a memory location.  Each memory location has several bits connected to these data lines, which requires very little additional programming and performance overhead to read the state of two bits as opposed to one.  

Unless a game supported or required an optional expansion port peripheral, a game developed or programmed in Japan could be expected to support a controller plugged into the expansion port.  Hori, Hudson and Sansui made popular controllers that supported turbo buttons.  These controllers also stuck out from the front of the console instead of the back and usually had longer cable lengths than the internally connected controllers.  If you connected a single controller, it would be recognized as "Player 1" and if you used a splitter, you could plug in two controllers and the 2nd controller would be recognized as "Player 2".  There were a few three and four player games, and in this instance the controllers plugged into the expansion port would be Player 3 and Player 4.

While this convention was widespread, there were some Famicom games that did not support it.  In virtually every case, this is because the game was developed and programmed by Western software companies.  These games were developed with NES hardware and released released first for the NES and then later distributed in Japan.  Here is a list with the developer and Japanese distributor:

Battletoads (Rare, Masaya)
Dragon's Lair (Movietime, Epic/Sony)
Fushigi na Blobby - Blobania no Kiki (Absolute Entertainment, Jaleco)
Hook (Painting by Numbers, Epic/Sony)
Hudson Hawk (Ocean, Epic/Sony)
Metal Flame: Psybuster (Sculptured Software, Jaleco)
Solstice (Software Creations, Epic/Sony)
Star Wars (Sculptured Software, Victor)
Star Wars - The Empire Strikes Back (Sculptured Software, Victor)
WWF Wrestlemania Challenge (Rare, Hot-B)

Super Mario USA also does not support expansion controllers, but it is a curious case.  The original game on which it is based, Yume Koujou - Doki Doki Panic, was developed by Nintendo for the Famicom Disk System in 1987.  With a Mario facelift the game was released for NES cartridges as Super Mario Bros. 2 in 1988.  Several years later (1992) Nintendo released what it called Super Mario Bros. 2 outside of Japan for as a Famicom cartridge titled Super Mario USA.  As Doki Doki Panic, the game supports expansion controllers but expansion port functionality was dropped by the Super Mario Bros. 2 beta and never restored, not even for Super Mario USA.  

Nintendo and Konami released other Famicom Disk System games (Akumajou Dracula, The Hyrule Fantasy: Zelda no Densetsu 1) that were ported to cartridges overseas and then re-localized onto Famicom cartridges late in the system's life, but they retained their expansion port support at all stages of their porting journeys.

Not all Western-developed games released for the Famicom eschewed support for expansion controllers.  Here is a list of such games which support expansion controllers:

Densetsu no Kishi - Elrond (Rare, Jaleco)
Klax (Tengen, Hudson Soft)
Paperboy (Tengen, Altron)
RoboCop 2 (Painting by Numbers, Data East)
Super Sprint (Tengen, Altron)
Terminator 2 (Software Creations, Pack-In-Video)
Tom & Jerry (Software Creations, Altron)
The Untouchables (Special FX Software, Altron)

Some licensed games that were released in Japan like Knight Rider, Predator and Die Hard were based on western properties but programmed in Japan and follow the convention of supporting expansion port controllers.  Ghostbusters and Maniac Mansion was ported by Japanese companies for their Japanese releases, so they followed the convention.  Many, if not most, Japanese games ported to the NES will retain their ability to read expansion port controllers even though the functionality is not useful on an NES.

Tandy 1000-incompatible PC Games

The Tandy 1000 computers were highly compatible with the IBM PC.  While you might have the occasional quirk due to the differences in the layout between an IBM PC Keyboard and a Tandy 1000 Keyboard, some disk protection scheme that required a memory upgrade with a DMA controller or a program which required Cassette BASIC in ROM (mainly by IBM's educational and young children software), for the most part PC software would "just work."  Recently I discovered a version of a game that would not work on a Tandy 1000 but due to none of these issues. 

Demon's Forge was released twice for PC-compatibles, the first time by Boone Software in 1983 and the second time by Mastertronic in 1987.  Until this year only an original floppy image of the Mastertronic version was available, but this year an original floppy image of the Boone version has been made.  Both versions are self-booting programs that came on a 5.25" disk and they do not use DOS to load.  

I found that the Boone version booted and ran perfectly in my IBM PC/XT and IBM PCjr. but failed to load in my Tandy 1000 SX or TX.  It displayed * Boot Error * "Press Any Key to Reboot" when the BIOS information is displayed.  The Boone version only supports 4-color CGA or composite CGA graphics as it predated the PCjr.  The Mastertronic release adds 16-color graphics as an alternative to the CGA graphics but only shows them with a DMA-less Tandy 1000.  The Mastertronic release does not work at all with a PCjr.

Why does the Boone version fail in the Tandy 1000s? Because of a small compatibility error in their Phoenix ROM BIOS, namely, an incorrect value in the default Disk Parameter Table (DPT).

The DPT contains a number of fields that are sent to the Floppy Disk Controller (FDC) on every Read Data command. One of these fields is the Last Sector Number: regardless of the requested data transfer length, the FDC stops reading a track after having transferred a sector whose on-disk number matches (not "exceeds") the Last Sector Number field. The structure by default is located in ROM BIOS, but may be relocated to RAM by modifying the Interrupt 1Eh vector, something that almost every game, as well as DOS, do. Demon's Forge does not, and so relies on the correctness of the ROM BIOS' default values.

Demon's Forge's only copy protection is that the sectors on its 160 KiB disk are not numbered 1 to 8, but 9 to 16 in the Boone version. This is good enough to fool DISKCOPY, though not enough to fool TeleDisk or CopyIIPC. The game reads a track issuing, via BIOS, an FDC command to the equivalent of "give me eight sectors on track XX, starting at number 9". This works with IBM's original ROM BIOS because the default DPT's Last Sector Number is 8, since in 1981, 160 KiB disks with their eight sectors per track were standard. The value 8 never matches any sector number found on the game disk, and so all eight sectors, 9 to 16, are transferred.

The Tandy 1000's Phoenix BIOS on the other hand denotes a default Last Sector Number of 9. Phoenix may have thought they were clever in making this change, since by 1984, 360 KiB disks with their nine sectors per track had become standard. In the case of Boone Demon's Forge however, this means that the very first sector of each track matches the default DPT's Last Sector Number, and so only the first sector of each track is read, causing the game to miss out on seven eights of its data. The Mastertronic version changes the copy-protected tracks by renumbering the sectors from 9..16 to 17..24, making that version work with both IBM and Phoenix BIOSes.

Additionally, there have been claims that the original version of Wizardry: Proving Grounds of the Mad Overlord, does not run on the Tandy 1000. A friend of mine bought a copy of the original release and imaged it in a Kryoflux and sure enough, the game booted fine on my IBM PC/XT but refused to get past the screen where it asks you to insert the master diskette on my Tandy 1000 SX.

There is no reason why Wizardry's original release would refuse to work in a Tandy 1000 except for copy protection. A deprotected disk image works in the Tandy 1000 as does the re-release with its protection scheme intact.

As the game used the UCSD p-System instead of DOS for its operating system, debugging the protection routine would be quite challenging. However, another friend of mine was able to locate the keydisk checking routine. The routine reads the protected sector, which is 4096 bytes instead of the usual 512 bytes, five times. The check will pass if the program is able to read the protected sector within 13-28 timer ticks.  Each timer tick is about 54.93 microseconds long.  The IBM PC/XT will read the sector between 12-14 timer ticks, so the protection will pass (although you may need to press Return once or twice if an "Insert the 'MASTER' Wizardry diskette! then press [RET]" prompt appears on boot.)  The Tandy 1000 SX will read the sector between 30-32 timer ticks, so it will never pass the protected sector check. 

It is not yet known why the Tandy/Phoenix BIOS is so much slower than the IBM BIOS to read the protected sector. One reporter noted that the original Tandy 1000 BIOS, the 01.00.00 version, was able to play the original release with its protected master disk and the Tandy 1000A BIOS, the 01.01.00 version, was not. The Tandy 1000 SX and 1000 EX use the 01.02.00 version of the BIOS. A comparison of the 01.00.00 to the 01.01.00 BIOS has shown no differences which would impact the sector read timing, so that reporter must have been mistaken.

Original IBM PC BIOS Only Games

There are two known early PC games which only run with the original IBM PC Model 5150 BIOS, they are Cyborg by Sentient Software and Story Time by Spinnaker Software.  The original 5150 BIOS is dated 04/24/1981 and there were later versions dated 10/19/81 and 10/27/82.  The last revision of the BIOS, which came with a mainboard which supported more memory, is by far the most common of the BIOSes found in the Model 5150.  

The only reason why these games work is due to a bug that is present only in the first version of the IBM PC BIOS (and possibly the second version).  When the disk calls for sectors to be read via INT 13H on later BIOSes, the BIOS will report the number of sectors successfully read in the CPU's AX register, and in Cyborg's case it will report 7 sectors successfully read.  But Cyborg expects AX to be 0000, not 0007, because the first revision of the IBM PC BIOS does not actually report the number of sectors successfully read even though it was meant to by its programmers.  Because Cyborg is not getting the response it is seeking, it will try to quit to ROM BASIC.  Only if Cyborg sees a 0 will it continue to run its code.  Unfortunately it will only see that value only on the earliest IBM PCs, not an XT, PCjr., AT, Tandy 1000 or virtually any other PC clone.

1 comment:

  1. Thank you for proper documentation of this miscellany, especially Cyborg. I'd forgotten the original reason.

    ReplyDelete