I do not get any graphical glitches with the PC Speaker at all. I only have a 486 machine, no less. I did not run the TSR software yet as I need to look for my external IBM FDD for my ThinkPad R40 to write to diskettes. Maybe I'm missing something, and I do disable the cache on the CPU and might find an L2 cache control software to slow the system down a bit more and see what happens.

Erm...
If you are not using the TSR, doesn't that mean that the Tandy audio output routines will write to the default port and mess up the secondary DMA controller which might then write garbage to random memory locations?

Benedikt wrote:

If you are not using the TSR, doesn't that mean that the Tandy audio output routines will write to the default port and mess up the secondary DMA controller which might then write garbage to random memory locations?

That is an interesting theory.
It would explain why only certain games have the problem:
The secondary DMA controller would have to be initialized in a certain way for the data to actually end up on screen. So only games that use the secondary DMA controller in a certain way will have the issue.
In other cases you may still be randomly writing data to memory, you just won't see it 😀

I think this may have to be investigated further.
If your theory is true, then the same problem should occur on every machine with a secondary DMA controller. And it should never occur on a machine without one.

I will download the TSR and push it to my 486 by connecting my IBM laptop running XP to the network card and see what happens.

Scali wrote:

That is an interesting theory. It would explain why only certain games have the problem: The secondary DMA controller would have […]
Show full quote

That is an interesting theory.
It would explain why only certain games have the problem:
The secondary DMA controller would have to be initialized in a certain way for the data to actually end up on screen. So only games that use the secondary DMA controller in a certain way will have the issue.
In other cases you may still be randomly writing data to memory, you just won't see it

It was just a wild guess, but maybe some games use the second DMA controller to move large chunks of graphics data around on screen.

I noticed a bit of a graphical glitch with the PC Speaker. Maybe the game has a bug in it. The Tandy TSR runs only with the EMM386 and HIMEM disabled. Getting somewhere.

Benedikt wrote:

It was just a wild guess, but maybe some games use the second DMA controller to move large chunks of graphics data around on screen.

Nice idea, but that's not how DMA works.

Funny thing is, King's Quest 1 and 3 EGA, Space Quest 1 and 2 EGA, and Police Quest 1 and 2 EGA work fine with the Lo-Tech Tandy sound card. I discovered that King's Quest 2 had graphical glitches when using a card newer than EGA, such as VGA. Works in DOSBox and I like using real hardware for games, so...

derSammler wrote:

Benedikt wrote:

It was just a wild guess, but maybe some games use the second DMA controller to move large chunks of graphics data around on screen.

Nice idea, but that's not how DMA works.

Some architectures can use their DMA controllers for memory-to-memory transfers. But you're right: The 8237 and friends can't do that. I forgot about that.

Benedikt wrote:

Some architectures can use their DMA controllers for memory-to-memory transfers. But you're right: The 8237 and friends can't do that. I forgot about that.

No, but you could still have corrupted graphics because of broken DMA transfers, if DMA is used to read the graphics from disk into memory.
Mind you, it's rare that HDD controllers use the 8237 for that. The ones that do are generally 8-bit cards, so that would rule out 16-bit transfers. But who knows 😀

And theoretically you can use the 8237 for memory-to-memory transfers. It's just... limited, because it only has 16-bit addressing.

Hm i have no issues with KQ2 on XT, works perfect.

Nec V20, Trident 9000 VGA Card.

Ordered new PCBs 😀

My card got modded by matze and works perfectly now. Less noise, thanks to better power supply, and no graphical glitches anymore when using the Tseng ET4000:

https://youtu.be/j5_xFX0AFN0

https://youtu.be/l0CszeCVc8A

glad it works, i already recieved some revised pcbs but they have dead via`s so i have to reorder.
but good thing is i got my money back.

smd version first.. dht version will follow later 😀

already shipped but i`m still waiting for china post 😁

matze79 wrote:

glad it works, i already recieved some revised pcbs but they have dead via`s so i have to reorder.
but good thing is i got my money back.

Was this through JLC? Didn't they advertise free standard verification on all orders? I guess their optical verification isn't as effective as their marketing would have us believe! I suppose I shouldn't be as trusting of the boards they deliver as I have been until now.

This is why i insisted pages back that the card should decode another 8 bit port, E0 being as far as i remember the best option for AT's and up. I'm happy it was implemented.

Patching C0 to E0 is trivial, and should be in my opinion much better than using a TSR to redirect the writes. Are these boards ready? I wouldn't mind getting one and actually starting to patch games and try it out on my AT systems.

Yeah but E0 will also not work on all machines.
Especial newer ones with PCI 😀

It would also be possible to just add Dipswitch and let users set any Adress they want, but i think this is just confusing.
So we have a good set of adresses now.

pcbs are on transit to germany.

for DHT Version, i did not incorporate the Changes now.
SMD first, because this is much easier for me to solder.
So first SMD Kits can be send in January 😀

matze79, what was primary cause of the problem with ET4000 and how did you fix it?

Arrived, tested, working... now running Longterm Test 😀

I can see on one pcb it has a silkscreen: "this card is property of keropi"
there is also somewhere a components bag with the same tag
😁 😁 😁 😁 😁