• Please review our updated Terms and Rules here

Tandy Sound Compatible PCB

In my defense, I didn't want to disassemble the entire thing, but rather teach CarlosTex a little assembly. RE'ing AMB.EXE in IDA, I can see that you're right :)
 
It is rather silly that they check for Tandy and then force it to use PC speaker. Maybe the authors really hated Tandy owners :p
 
There's actually Tandy detection code in there too.

I already had that part figured, i mentioned it in a previous post. I was not aware the Compaq check though!


The NOT instruction to perform the inversion is only so that values of FF, FE, FD, and FC show up as 0, 1, 2, or 3. (Which is weird, they could have just compared the byte directly, but whatever.) This is their way of checking if the model byte matches FF (IBM PC, or Tandy if f000:c000=21h), FE (PC/XT), FD (PCjr), or FC (PC/AT).

I know about the machine ID bytes and what was confusing me was why was there not a direct comparison to the byte. Because i'm mostly 8088 assembly illeterate the visual references are the ones i'm looking for first.

In my defense, I didn't want to disassemble the entire thing, but rather teach CarlosTex a little assembly.

And i thank you for that! It is actually something i wish to learn. I gotta order that book.


The first two jumps are for Compaq and Tandy detection. NOP them so it always falls through to the PCjr check. Then change "not bl" to "mov bl, 2". This is the value bl would have if the machine byte was FDh (for PCjr) and then inverted.

Holy crap, i was really close to patch it myself then! You see the only part i didnt understand was how the machine byte check was being made. I actually NOPped those jumps in a previous "desperate attempt" but since i never figured out the machine byte ID code just NOPping was not enough. I thought i was just a silly thought of mine and decided that maybe i would need assistance from the gurus.

It is rather silly that they check for Tandy and then force it to use PC speaker. Maybe the authors really hated Tandy owners :p

And that crossed my mind too, although i'm not sure if they done it on purpose or they just messed up.

Anyway, Plasma's suggestion works great and now Nine Princes in Amber can be patched too. I only tried it in DOSBox, but i'm sure it will work on my XT with the Tandy Sound Card.

Funny about this all, PC's that are not Tandy or Compaq Portable don't even need to patch the NOP instrcutions. All is needed is to force PCjr detection by changing F6 D3 (not bl) to B3 02 (mov bl,2) at 8F1A offset.

Edit: Tested and working on a real machine! Thanks to Plasma and Trixter.
 
Last edited:
Good news,

i patched 2 more games. One was The Wizard of Oz, which PC version seems to use the same engine as the Telarium adventure games, despite apparently being published by Windham.

The other game is Below the Root, i patched the DOS conversion. This game does not play 3 voice music on a Tandy machine, but it does now.

Code:
seg000:0346                 mov     ah, es:0FFFEh
seg000:034B                 cmp     ah, 0FDh ; '²'
seg000:034E                 mov     al, 0
seg000:0350                 jnz     short loc_10354
seg000:0352                 mov     al, 4

It was rather easy to patch, by just changing the value on offset 054Fh 00 to 02.

For the booter version the offset is 1B9Fh. Same treatment just replace 00 for 02.
 
Last edited:
Do we have a repo for these patched versions yet?

If not, I am offering to set up an FTP directory on ftp.oldskool.org and give the login/password to a user who is not myself, so that said user can be the contact for "forced tandy audio patched games" and upload them. I nominate CarlosTex.

Are there any public file sharing sites that allow multiple people to have admin access to a single repo? You'd think that problem would have been solved by now. I know github can work in that capacity, but using it as a dump for patched binaries is not in the spirit of using github and is likely against their terms of service.
 
What if we write patch scripts instead, rather than the actual binaries?
There's probably a generic DOS patcher out there, and if not, it's not too difficult to write one in Pascal or C I guess. Just a list of offsets and bytes.
I've done a simple one in C for Windows, could be ported if someone wants.

The patches will be smaller than the binaries, and they will not violate any laws or terms of service I guess.
 
Do we have a repo for these patched versions yet?

If not, I am offering to set up an FTP directory on ftp.oldskool.org and give the login/password to a user who is not myself, so that said user can be the contact for "forced tandy audio patched games" and upload them. I nominate CarlosTex.

I don't mind doing that at all. I already have a set of exe files ready and i'm gonna build a readme.txt file to document which and what are the changes to each game. ftp.oldskool.org was actually what i thought at first and i was eventually gonna contact you, if there was interest to host these patches.

Are there any public file sharing sites that allow multiple people to have admin access to a single repo? You'd think that problem would have been solved by now. I know github can work in that capacity, but using it as a dump for patched binaries is not in the spirit of using github and is likely against their terms of service.

Because of the issue you mention i don't think github is a good place either.


What if we write patch scripts instead, rather than the actual binaries?
There's probably a generic DOS patcher out there, and if not, it's not too difficult to write one in Pascal or C I guess. Just a list of offsets and bytes.
I've done a simple one in C for Windows, could be ported if someone wants.

The patches will be smaller than the binaries, and they will not violate any laws or terms of service I guess.

That's a very good idea, and probably th best way to go for the majority of people wanting to patch their games. However, i would like to keep the patched binaries in ftp.oldskool.org, specially because its a lot of fun to access the ftp from the actual vintage machines.

I'm trying catch the smaller fish, by patching these CGA only games that also support 3 voice sound. Other games seem to be much harder to patch so i'm probably gonna need some help from the gurus. With time, we can have a lot of games patched.


I would like to ask a moderator to move all the patching discussion from the last 2-3 pages to a different thread, so that this thread can be left just to the actual Tandy card discussion, even though the patching question is very much relevant to it.
 
What if we write patch scripts instead, rather than the actual binaries?

Because this only works if the binaries don't change size. One of the first things I do patching binaries is uncompress them, so a simple patching util won't work. (I don't know of a free tool that does complex differential patching that runs in DOS)

I don't mind doing that at all. I already have a set of exe files ready and i'm gonna build a readme.txt file to document which and what are the changes to each game. ftp.oldskool.org was actually what i thought at first and i was eventually gonna contact you, if there was interest to host these patches.

Okay, email me privately and I'll get it set up.
 
Because this only works if the binaries don't change size. One of the first things I do patching binaries is uncompress them, so a simple patching util won't work. (I don't know of a free tool that does complex differential patching that runs in DOS)

True, but in 99% of all cases, unp can probably take care of that. So that would make patching a 2-step process:
1) Run unp on the binary
2) Run the patch script

I believe unp needs at least a 386 though, so you may have to end up doing the unp and patching in DOSBox or such, before transferring to the target machine. At least, that's what I normally do.

An alternative could be a TSR-based patcher. You load the TSR with your patch-script, it hooks into some relevant DOS/BIOS call which you know will not be called until the binary is unpacked in memory. Then it patches on-the-fly.

Sure, binaries are easier, but they aren't legal. The above methods are.
 
I really don't think we need to worry about the legality of distributing 30 year old patched binaries that require additional data files to run anyway.
 
I really don't think we need to worry about the legality of distributing 30 year old patched binaries that require additional data files to run anyway.

We do if we want to use online services such as Github (we have to abide by their terms of service). That was the whole point.
 
I believe unp needs at least a 386 though, so you may have to end up doing the unp and patching in DOSBox or such, before transferring to the target machine. At least, that's what I normally do.

UNP works on any system.

Sure, binaries are easier, but they aren't legal. The above methods are.

Actually, they might be legal, if only the patched binaries are provided and not the other game data to make them run. But that's a discussion for some other thread.

I really don't think we need to worry about the legality of distributing 30 year old patched binaries that require additional data files to run anyway.

Repo is on ftp.oldskool.org, carlostex has the password, and I accept the responsibility of what goes in there (if I get a cease and desist letter, I'll shut it down).
 
First files (patched binary exe's and 1 booter) and readme have been uploaded already. New thread to be coming as well, the more contributers we get the better.
 
James, thanks for releasing the v1 PCBs. I finally got around to assembling mine. One question: the wiki lists the PC speaker input pull-up resistor as 10K, but the diagram shows it as 33R. Which is the correct value?
 
Tested my boards last night. One works fine but the other sounds discordant/out of tune. It seems that the rhythm of the music is correct but the notes are way too low?
Appreciate any feedback on what it could be. Duff PSG chip perhaps, or one of the data lines to the PSG isn't working correctly?

The working board sounds like this: https://www.youtube.com/watch?v=MpMasrnDiKI
The non-working board sounds like this: https://www.youtube.com/watch?v=QpT5eNeeDys

Both boards were assembled with the exact same components and in the same way.
Unfortunately I didn't socket the PSG otherwise I could swap them to test, doh!
 
Hmm, I can see from the datasheet that setting the frequency registers requires 2 bytes to be sent to the PSG while setting amplitude requires only a single byte. Perhaps the second byte of the frequency data is not being received correctly?

That would mean that amplitude would be set correctly (rhythm seems OK), but only the 4 most significant bits of the frequency would be set (notes sound off).
 
Sounds like the PSG chip is screwed. Solder is still fresh so shouldn't be hard to wick it out
 
I have 9 of them working now, and I'm about to list them on eBay today. James told me I have the last of them, so if anyone is interested feel free to ping me. I opted to leave the 33 ohm resistor off as it seems to cause a lot of noise if not in the right PC. I too am confused about the 33 ohm vs 10k resistor. 33ohms seems like a really low value and is would seem to be pumping a lot of current into this audio-in pin. However, reading through 40+ pages of this thread, it seems this was the value many have used. I personally wouldn't even put the input on V2, and would maybe just use something like an opa134 or ne5532 on the next one and send a line-out. This should simplify the design, and I'm guessing most folks are used to using amplified speakers anyway. This would eliminate the need for the volume knob issue too, and just use a nice set gain on it. :)

Thanks!
-Kevin
 
The 5160 PC speaker circuit uses a 33R output resistor (R6) and is open collector, the speaker itself wired straight to the 5V line. So a 33R pull-up gives ~2.5V swing which I think is similar to the PSG. The op amp on this board is working as a current amplifier.

Hope that helps!
 
Small update from my side: Today I finally took the time to take the 5160 apart, get the Tandy soundcard out, and replace the SN76489AN with an SN76496N.
I'm happy to report that the card works perfectly fine with this type of chip as well.
Also, my first impression was that the SN76496N is slightly louder than the SN76489AN was, but since I have no way to reliably do an A/B test with the chips, this may or may not be true (I may have misremembered how loud the SN76489AN was, or I may just have accidentally bumped the volume pot in the process of swapping the chips).
 
Back
Top