• Please review our updated Terms and Rules here

Tandy Sound Compatible PCB

keenerb said:
I was thinking we'd just tie the PIC directly into the CE/D0-D7 traces on the PCB, but now that I think about it that might corrupt valid data on the ISA bus...
Click to expand...

You could combine the two ideas though.... If you put a PIC and a relay on it, then the PIC could control the relay.
On bootup, the PIC can start a countdown, and switch the relay to enable output after X seconds... which will be long enough to have booted the PC and loaded SNDOFF.COM
 
Scali said:
You could combine the two ideas though.... If you put a PIC and a relay on it, then the PIC could control the relay.
On bootup, the PIC can start a countdown, and switch the relay to enable output after X seconds... which will be long enough to have booted the PC and loaded SNDOFF.COM
Click to expand...

Could the CE signal from the 688 trigger the PIC to flip the relay?

It would boot muted, any data written to the configured port triggers PIC to unmute the chip.

Combine that with SNDOFF.COM in autoexec.bat and basically everything would be covered.

There might be weird cases with, say, booter games that assume the chip is silenced properly to begin with and don't init the chip correctly, but those would behave the same even without a mute circuit; you'd HAVE to have a bios mute function.
 
pearce_jj said:
Something like this maybe:

http://www.mouser.co.uk/Search/m_Pr...ha2pyFaduh7C8SRp%2b2a6dMoPfMq936qvvJWFJneP2k=

Don't forget the fly back diode. Or use a Darlington driver, ULN2803A might be something you have in the parts drawer perhaps.
Click to expand...

These words sound important, but I don't really know what they mean.

I'll just wait for a parts list.

I did see this ont he datasheet for the relay:

Long-term Continuously ON Contacts
Using the Relay in a circuit where the Relay will be ON
continuously for long periods (without switching) can lead to
unstable contacts, because the heat generated by the coil itself
will affect the insulation, causing a film to develop on the contact
surfaces. Be sure to use a fail-safe circuit design that provides
protection against contact failure or coil burnout.

Won't it be "ON" for long periods in our use case? Is that something we should worry about?
 
We could drive it from MUTE, so it's only active when the sound board is not needed, i.e. coils de-energised once sound is enabled. This would work by pulling down the input at the mixer.
 
pearce_jj said:
We could drive it from MUTE, so it's only active when the sound board is not needed, i.e. coils de-energised once sound is enabled. This would work by pulling down the input at the mixer.
Click to expand...

The on-board ROM is probably the simplest way to do it, I just hate taking up another XXkb window for upper memory blocks...
 
keenerb said:
The on-board ROM is probably the simplest way to do it, I just hate taking up another XXkb window for upper memory blocks...
Click to expand...

I considered this to be an 8088-related project. And 8088 machines don't usually have memory beyond 640k anyway. In fact, the original PCjr and Tandy 1000 machines didn't have anywhere near 640k memory.
 
Things can get crowded in the Upper Memory Area, even on an XT-class machine. ROM, BASIC, DOS-in-ROM, HD ROM, Video RAM, EMS Page Frame, Ethernet etc. Granted you would only need a PROM's size of code, maybe a small microcontroller would be the way to go?
 
The ROM wouldn't really help anyway since the code is not necessarily executed particularly near power on, e.g. An XT will run its memory tests first. The best solution is to decouple or pull down the output at power on then have an executable clear it in autoexec. Of course someone could easily roll that into a 2KB option ROM so it could be appended to the XTIDE-UB for example for machines also using my storage adapters, which have plenty of ROM space available for such.
 
pearce_jj said:
The ROM wouldn't really help anyway since the code is not necessarily executed particularly near power on, e.g. An XT will run its memory tests first. The best solution is to decouple or pull down the output at power on then have an executable clear it in autoexec. Of course someone could easily roll that into a 2KB option ROM so it could be appended to the XTIDE-UB for example for machines also using my storage adapters, which have plenty of ROM space available for such.
Click to expand...

That's a good point, re: rom execution order. I've only tested it at the very beginning of a custom xi8088 bios, so I known for certain it was executed very early in the boot order.

Using an executable to enable audio output to will cause booters to remain muted, potentially? Not that any of them will necessarily WORK without real tandy hardware but i wouldn't put it past the programmer guys to maybe fix that...
 
I guess having a microcontroller or whatever circuit that outputs the volume commands on bootup would be the most elegant and foolproof solution.
But how difficult/expensive is that going to be?
 
Personally I favour a discrete solution because the barrier to assembly is then lower - home assemblers expressed (by way of sales!) a strong preference for 7400-series based XT-CF boards over the CPLD version, for example.
 
keenerb said:
Using an executable to enable audio output to will cause booters to remain muted, potentially? Not that any of them will necessarily WORK without real tandy hardware but i wouldn't put it past the programmer guys to maybe fix that...
Click to expand...

I've patched booter version of Below the Root to support 3 Voice sound on non Tandy machines.

I apologise that i haven't uploaded the latest patches yet.
 
pearce_jj said:
Personally I favour a discrete solution because the barrier to assembly is then lower - home assemblers expressed (by way of sales!) a strong preference for 7400-series based XT-CF boards over the CPLD version, for example.
Click to expand...

Well obviously. The CPLD has to be programmed and it isn't exactly a super easy process.

Eventually as 74 series logic gets obsolete and becomes unavailable other options have to be considered
 
I'm not sure we've gotten anywhere on this design...
How about we keep it simple and effective?
I think the simplest of all solutions would be to place the volume pot for the SN76489 at the backplate of the card, so that you can easily turn it off during bootup, and dial it up once you have booted up and silenced the chip with a simple utility.
For booters, I think you'd be okay if you would boot the system first, silence the card, and then do a warm boot (ctrl-alt-del) to run the booter game. It shouldn't reset the SN76489, and therefore it should remain silent.
If that fails, I could build a simple utility (if one does not already exist) to launch a booter from DOS.

A variation on that theme could be to have a simple switch at the back of the card as well, to silence the output without having to adjust the volume. The switch could either just break the gnd on the output jack, or switch the gnd for the op-amp. Whichever way is easiest to stop it outputting any signal.

Since both Tandy and PCjr explicitly silence all 4 channels from the BIOS, I think it will be wrong to assume that games will silence all channels themselves at bootup, so whenever a game doesn't use all 4 channels, the unused channels might continue to output the 'startup' tone indefinitely.
And it seems that silencing the chip automatically is blowing the complexity up by a few levels, so that's probably not feasible.

I wonder though... how difficult would it be to write 4 bytes to the card with discrete logic?
Because basically we only need to do the following sequence:
9F, BF, DF, FF

So the following pattern is always static:
9F -> 10011111
We could hardwire those.
Only bits 5 and 6 need to change during this pattern:
00, 01, 10, 11

So technically we'd just need to send a sequence of 4 2-bit values to the card, with the handshaking required to the SN76489.
An extension rom or microcontroller is massive overkill of course. But how difficult would it be to do this in discrete logic? It'd be like a 2-bit adder, where the input needs to be triggered by the SN76489 lines I suppose. Don't have the details worked out yet.

I think the main problem for either a discrete circuit or a microcontroller is to somehow mulitplex between the ISA port and our 'alternative' data source.
I can think of using some and-gates, so that the ISA port signals can only come through if another signal is also active at the same time.
That would allow you to put the ISA bus on 'ignore' during initialization, and then make the ISA bus active at the end.
But it'd still blow up the complexity considerably. You'd need 10(?) extra AND gates to pull that off.
 
Not sure what the current schematic looks like, but would it be viable to just analog mute the output, have the analog mute release on the first access to the sound chip, and include a boot ROM to initialize it? Boot ROM would trip the mute as soon as it started initializing the IC.
 
glitch said:
Not sure what the current schematic looks like, but would it be viable to just analog mute the output, have the analog mute release on the first access to the sound chip, and include a boot ROM to initialize it? Boot ROM would trip the mute as soon as it started initializing the IC.
Click to expand...

If we can get that to work then it would also give us some alternatives:
1) The BIOS ROM can be optional: if you don't install it, you can still use the DOS utility to mute the chip and trigger the circuit to enable the output.
2) You could also choose to put the BIOS routine into another card's ROM, eg if you already have an XT-IDE card in your system.

Biggest downside of the BIOS method is that it will only work as long as the base address coded into the BIOS is the same as the base address your card is configured to. As soon as you change the jumpers, you need to update your BIOS as well.
Since you cannot read from the chip, the only way to 'autodetect' the chip would be to write a command to it and time how long it takes. Then guesstimate that if it takes roughly the time you expect an SN76489 write to take, the card is configured at that address.
This has two obvious flaws:
1) It's not foolproof, so if you happen to have some other hardware at one of the possible addresses, and writing to that takes about as long, then you will get a false positive.
2) You're basically randomly writing data to ports... The whole reason you might want to change the base address from C0 in the first place is because there is other hardware there (such as the second DMA controller in AT-class systems). Not exactly a smart thing to be writing data to that. You might break stuff.
 
I've thought about modifying the XT-IDE to allow reading the I/O switches as a memory address, but ultimately decided not to since it would potentially break compatibility with older BIOSes. Since that's not an issue with this board, it's possible to just read the I/O address in and have the code talk to the correct I/O port automatically. Not particularly complex. You'd just place the register for it either within the onboard ROM address space, or just after it. If it's within the ROM address space, you have to have one address read the switches, and then the other read the inverse, to cancel it out for the option ROM checksumming process. Again, not too complicated. Last I saw of this board, it's fairly small/simple anyway.

The boot ROM being optional/includable on some other BIOS was my thought as well, your modified xi8088 BIOS would mean in your case you'd have no need to populate the ROM circuitry, and as you mentioned it could be included in an XT-IDE ROM or on the ROM on a network card or something. And, like you said, if you just use the DOS utility to initialize the chip, the analog mute will release as soon as the utility starts writing to the sound chip. That, plus being able to read in the jumpers, sounds like a solid solution to me.
 
You must log in or register to reply here.
Back
Top