Does the patch rely on the TANDY string that starts at F000:C078 ? It would be cool that the patch would allow 3 voice sound without needing to detect a Tandy, as to make it possible to work with the upcoming Tandy Sound Card.

As always, amazing stuff bjt

It doesn't use the Tandy string, but the Machine ID byte, so right now it'll fall back to beeper on anything but a Jr, Tandy 1000 or PC 5150. Easy enough to change though.

I guess there will need to be a more general solution for the Tandy sound card, like a PM TSR that traps all these things and redirects Tandy sound writes.

I could not get the patch file to work. I understand it requires real MS-DOS, and I am using 6.22. On my Tandy, the patch file complains of file not found, even though I have the ALLEYCAT.EXE with 61,568 bytes in the directory. When I try to manually do the steps, debug hangs. Is there something wrong with the batch file or debug?

Also, do you think you could add support for CAT.EXE with a byte size of 55,067 bytes? That is the retrograde station booter hard drive conversion, which is more common and does not have a pirate logo obscuring the original IBM copyright text.

bjt wrote:

I guess there will need to be a more general solution for the Tandy sound card, like a PM TSR that traps all these things and redirects Tandy sound writes.

As far as i know the Tandy Sound Card approach was to place the sound chip on C0h / 1E0h selectable with a jumper. From what i could understand the last few months i launched the Tandy thread, a TSR is great for interrupt interception but not to read a memory location.

In fact i think having the hardware sit directly on the proper locations is the best approach. It should work great on XT systems (and theoretically it shouldn't be a problem on AT's as well) and no need for software that will require a 386.

For games that DO require to read the TANDY string there's 2 choices: either patch the games like you did or place the TANDY string at the proper location, creating a BIOS extension to do so, like 2M-XBIOS does vias the DOS prompt.

I went as far as changing the Tandy ROM BIOS and changing the string from TANDY to DANDY via hex editing on location F000:C078 and it was not a surprise games that rely on that string started to play PC Speaker music and having monochrome graphics.

bjt wrote:

It doesn't use the Tandy string, but the Machine ID byte

Can you tell me the exact memory location of the byte?

carlostex wrote:

As far as i know the Tandy Sound Card approach was to place the sound chip on C0h / 1E0h selectable with a jumper. From what i c […]
Show full quote

bjt wrote:

I guess there will need to be a more general solution for the Tandy sound card, like a PM TSR that traps all these things and redirects Tandy sound writes.

As far as i know the Tandy Sound Card approach was to place the sound chip on C0h / 1E0h selectable with a jumper. From what i could understand the last few months i launched the Tandy thread, a TSR is great for interrupt interception but not to read a memory location.

In fact i think having the hardware sit directly on the proper locations is the best approach. It should work great on XT systems (and theoretically it shouldn't be a problem on AT's as well) and no need for software that will require a 386.

For games that DO require to read the TANDY string there's 2 choices: either patch the games like you did or place the TANDY string at the proper location, creating a BIOS extension to do so, like 2M-XBIOS does vias the DOS prompt.

I went as far as changing the Tandy ROM BIOS and changing the string from TANDY to DANDY via hex editing on location F000:C078 and it was not a surprise games that rely on that string started to play PC Speaker music and having monochrome graphics.

bjt wrote:

It doesn't use the Tandy string, but the Machine ID byte

Can you tell me the exact memory location of the byte?

The location of the "Tandy ID Byte" is FC00:0000 and the byte must have the value of 21. Just checking the BIOS area for the ASCII "TANDY" will not suffice on its own to identify a Tandy 1000 compatible machine. Other Tandy PC-compatibles like the 1200, 3000, 4000 would also have this text string. Of course, other BIOSes may have a 21 there as well, so you get programs that check both the ID string, then the ID byte before they use Tandy graphics and sound.

Looks like Github is screwing up the line endings on the batch file and patch data, if you load them into Edit and save them out again they should work. I also need to remove the usage of an V20/286+ instruction.

I would have liked to patch CAT.EXE but I couldn't locate the 3-voice output code. The patch does however remove the "Hacked by" text on the title screen of ALLEYCAT.EXE.

Great Hierophant wrote:

Just checking the BIOS area for the ASCII "TANDY" will not suffice on its own to identify a Tandy 1000 compatible machine.

Depends on the game/program. Some might require one or the other or in some cases both. In fact, i changed the machine byte from 21 to 22 (on ASCII hexadecimal 21 is '!') and AGI games still detect Tandy machine just fine. Now try to change the TANDY ASCII to something else and you'll see the difference, no Tandy graphics and no Tandy 3 voice sound. This or maybe PCem sucks at emulating a Tandy but keep in mind it uses a real Tandy ROM image.

I also tried Maniac Mansion and this one unlike AGI games desn't give a crap about the TANDY ASCII string or should i say the bytes: 54 61 6E 64 79 that start at F000:C078. It does however care about the 21 hex byte at FC00 and changing it to anything else will result in 4 color graphics and beeper sound. The AGI games is the complete opposite. They do not care about the single byte at FC00 but they do care about the 5 bytes at F000:C078.

Using the 386 PM features it's possible to trap access to both IO and specific ranges of memory, e.g. reads from the BIOS ROM. Basically set a page to inaccessible then handle the exception that's raised on access, letting most through unchanged but return different values for specific addresses. Can't see many people burning a new ROM. Or maybe if the BIOS is shadowed in RAM it can be changed in place.

The machine ID byte I was referencing is actually at FFFF:E. FF for Tandy, FD for PCjr, something else for early XT, 86 for XT/AT.

OK, I've fixed the issue with the line endings and a crash which would happen on 8088 or 86 machines (hence me not seeing it on the TL/2 or Dosbox...). There's a new release on GitHub.

Regarding CAT.EXE, I tried it in Dosbox with the machine type set to PCjr and it plays beeper music. So, it looks like the 3-voice code was removed from that version. I couldn't find any writes to port C0 either.

I did think about restoring the IBM copyright text for ALLEYCAT.EXE, but settled for just disabling the pirate logo.

I tried your suggestion about edit and it allowed the patch to work properly, thank you. Excellent job.

I'll test this this weekend. thx!
perhaps we can get a patched version of boulderdash too? 😀 I never got the booter-version that can be patched? to work.

perhaps we can get a patched version of boulderdash too? 😀 I never got the booter-version that can be patched? to work.

Super Boulder Dash (from Electronic Arts) contains CGA, PCjr and Tandy executables that can be extracted. The Prism Software versions run under DOS but do not include a Tandy executable.

carlostex wrote:

Great Hierophant wrote:

Just checking the BIOS area for the ASCII "TANDY" will not suffice on its own to identify a Tandy 1000 compatible machine.

Depends on the game/program. Some might require one or the other or in some cases both. In fact, i changed the machine byte from 21 to 22 (on ASCII hexadecimal 21 is '!') and AGI games still detect Tandy machine just fine. Now try to change the TANDY ASCII to something else and you'll see the difference, no Tandy graphics and no Tandy 3 voice sound. This or maybe PCem sucks at emulating a Tandy but keep in mind it uses a real Tandy ROM image.

I also tried Maniac Mansion and this one unlike AGI games desn't give a crap about the TANDY ASCII string or should i say the bytes: 54 61 6E 64 79 that start at F000:C078. It does however care about the 21 hex byte at FC00 and changing it to anything else will result in 4 color graphics and beeper sound. The AGI games is the complete opposite. They do not care about the single byte at FC00 but they do care about the 5 bytes at F000:C078.

The AGI games may be conducting graphics adapter tests in addition to using the TANDY string. Late versions of the interpreter will display the games on an EGA or VGA card if installed in the Tandy, which disables the built-in TGA. However, Sierra explicitly advertised their games as working on the Tandy 1200, an XT clone, the Tandy 3000 and 4000, which were using 286s and 386s. Those systems must have the copyright string somewhere in their BIOS.

I have taken the liberty of enhancing bjt's patch to

1. support a variety of versions. If CAT.COM/CAT.EXE/ALLYCAT.COM/ALLYCAT.EXE/ALLEYCAT.COM/ALLEYCAT.EXE are not found, the file is created by reading the sectors off the original disk in drive A or B;
2. make the patched executable work as the original game on CGA and PCjr; i.e. low-intensity palette on CGA and asking about external sound on PCjr;
3. produce intensity colors on EGA/VGA;
4. not switch to text mode on BIOSes (e.g. Matrox) that do not preserve AX on AH=10 Int10 calls;
5. support the cursor keys on the original Tandy 1000 keyboard.

ZIP file

The use of BSPATCH means that the patching procedure (not the patched game) will need to happen on a 386+ system.

Great Hierophant wrote:

The AGI games may be conducting graphics adapter tests in addition to using the TANDY string. Late versions of the interpreter will display the games on an EGA or VGA card if installed in the Tandy, which disables the built-in TGA. However, Sierra explicitly advertised their games as working on the Tandy 1200, an XT clone, the Tandy 3000 and 4000, which were using 286s and 386s. Those systems must have the copyright string somewhere in their BIOS.

Keep in mind i never tested with real Tandy 1000 hardware but with PCem instead. The AGI games i tested include King's Quest 1 and 2, Leisure Suit Larry, Space Quest 1 and 2 and Police Quest. These had AGI interpreter versions 2.917, 2.426, 2.440, 2.089, 2.912, 2.915. All had the same behaviour when i changed the string from Tandy to Panda. The games then force Composite CGA and beeper sound. I made the mistake thinking it was Hercules mode but its not. It's clearly composite CGA.

So no TANDY string at F000:C078 seems to result into the game thinking it is just a regular XT. I know the Tandy 1200 is an XT clone but i never took a look into its BIOS. It seems to have been manufactured by Tandon and from what i could see from a youtube video BIOS strings seem to be Tandon and not Tandy.

I'm mostly confident that if someone wants to try it on a real Tandy 1000 the results would be exactly the same with AGI games. All one needs is a hex editor and an EPROM/EEPROM burner. 😀

Sound works, but still only displays cga in dosbox.

DOSBox 0.74 does not emulate the Tandy/PCjr palette properly. You need a newer build such as Daum.

Updated my version of the patch again to support the TI chip at I/O addresses other than 0xC0. The I/O address used is queried via AH=81/Int1A. This makes it work under DOSBox with tandy=on under non-Tandy machine types, and should make it work on machines like the Tandy 1000 RSX which have the TI chip at 0x1E0.

ZIP file

maybe you can add support for enhanced (tandy) sounds on ibm ps/1 machines that mount that ps1 audiocard? If I remember well, jmk's ps1 audiocard driver is based on the tandy one (hardware is similar).