Eivind wrote on 2024-01-11, 18:14:

So... reading your comments and thinking about this, I suspect the ferrite bead FB8 is either broken or not making good contact […]
Show full quote

So... reading your comments and thinking about this, I suspect the ferrite bead FB8 is either broken or not making good contact with its pads.
First of all - the ferrite bead itself should only drop the voltage a miniscule amount, like 0.01V in my measurement. The fact that you're both not seeing any voltage there when there's no AGP card inserted, and a drop of 0.2V when there is looks to me like that rail "VCC_3V3_AGP" is being backfed from the other 3.3V AGP rail, the "VCC_VIO_AGP" through the card itself. Which is definitely not good, but might explain the card-dependant erratic behavior you're seeing - as these are supposed to be separate rails providing power to the card.
I'll attach a screenshot of the AGP schematic here for now.

Using a voltmeter, try measuring resistance through the ferrite bead, and play around with touching either the bead leads themselves, or the tiny pads it's attached to.
You could also try desoldering the FB8 bead and bridging the gap with solder directly.

That's so funny that I would write all that and not realize that there should never be any voltage across a ferrite bead. I guess because all SMD stuff looks the same, I forgot that it's just a jumper with a bead around it, 🤣. That's what happens to an EE that's done software his entire career. That has to be the issue. I'll give it a try later today...thanks for the schematic fragment. I'll remove the cap on the ATT, since that is obviously not related.

This thing is SO AWESOME!

I printed a case for the Pi Zero (https://www.printables.com/model/341183-pi-ze … o-case-reversed, if you are interested) alongside the SoC active cooler. Stuck a Voodoo3 2000 in the AGP slot and it worked straight away - BIOS updated, love the touches there, you've done a great job Eivind. My stash of SATA stuff is seemingly exhausted so I'll have to sort that out, as well as a proper SFF case with a window to show this thing off.

tabm0de wrote on 2024-01-02, 14:19:

Nice, waiting for my case, need to try to make a io plate also if no one has made one 😀

Would very much appreciate this, TinkerCAD is about as far as I can go..

doogie wrote on 2024-01-11, 23:09:

tabm0de wrote on 2024-01-02, 14:19:

Nice, waiting for my case, need to try to make a io plate also if no one has made one 😀

Would very much appreciate this, TinkerCAD is about as far as I can go..

Did someone say tinkercad? I just got my board mounted in a case today and made this real quick. I will share a link once I have it fine tuned if anyone wants. Or if someone has something better I am all for printing that instead.

Aaron707 wrote on 2024-01-11, 23:46:

doogie wrote on 2024-01-11, 23:09:

tabm0de wrote on 2024-01-02, 14:19:

Nice, waiting for my case, need to try to make a io plate also if no one has made one 😀

Would very much appreciate this, TinkerCAD is about as far as I can go..

Did someone say tinkercad? I just got my board mounted in a case today and made this real quick. I will share a link once I have it fine tuned if anyone wants. Or if someone has something better I am all for printing that instead.

Please do share!!! Well done!

rknize wrote on 2024-01-11, 19:25:

Eivind wrote on 2024-01-11, 18:14:

So... reading your comments and thinking about this, I suspect the ferrite bead FB8 is either broken or not making good contact […]
Show full quote

So... reading your comments and thinking about this, I suspect the ferrite bead FB8 is either broken or not making good contact with its pads.
First of all - the ferrite bead itself should only drop the voltage a miniscule amount, like 0.01V in my measurement. The fact that you're both not seeing any voltage there when there's no AGP card inserted, and a drop of 0.2V when there is looks to me like that rail "VCC_3V3_AGP" is being backfed from the other 3.3V AGP rail, the "VCC_VIO_AGP" through the card itself. Which is definitely not good, but might explain the card-dependant erratic behavior you're seeing - as these are supposed to be separate rails providing power to the card.
I'll attach a screenshot of the AGP schematic here for now.

Using a voltmeter, try measuring resistance through the ferrite bead, and play around with touching either the bead leads themselves, or the tiny pads it's attached to.
You could also try desoldering the FB8 bead and bridging the gap with solder directly.

That's so funny that I would write all that and not realize that there should never be any voltage across a ferrite bead. I guess because all SMD stuff looks the same, I forgot that it's just a jumper with a bead around it, 🤣. That's what happens to an EE that's done software his entire career. That has to be the issue. I'll give it a try later today...thanks for the schematic fragment. I'll remove the cap on the ATT, since that is obviously not related.

OK, so FB8 was open. The solder did look a bit questionable, but reflowing it did not help. I removed it and soldered in a jumper and it's fixed!

Here is a link to the I/O Shield I made. Feel free to copy it and improve upon it and re-share.
https://www.tinkercad.com/things/785XyBLg61A- … ma-io-shield-v3
To easily change the holes, just click the "ungroup" button once when editing in TinkerCAD, then group everything to complete the change.

rknize wrote on 2024-01-12, 01:48:

OK, so FB8 was open. The solder did look a bit questionable, but reflowing it did not help. I removed it and soldered in a jumper and it's fixed!

Ah, that's good to hear, so glad we got to the bottom of this!
Now, obviously this leaves me wondering why I didn't notice this issue when testing your card - and the only explanation I have is that my particular graphics cards were able to function with only the VCC_VIO_AGP rail available.
I must say, I'm a little disappointed with the overall soldering work done by JLC for this particular batch - I also had issues with the SOM connector pins on some of the boards, but at least these were clearly visible and I managed to manually resolder them.

Aaron707 wrote on 2024-01-12, 05:21:

Here is a link to the I/O Shield I made. Feel free to copy it and improve upon it and re-share.

Nice! 😎

Eivind wrote on 2024-01-12, 08:30:

Ah, that's good to hear, so glad we got to the bottom of this! Now, obviously this leaves me wondering why I didn't notice this […]
Show full quote

rknize wrote on 2024-01-12, 01:48:

OK, so FB8 was open. The solder did look a bit questionable, but reflowing it did not help. I removed it and soldered in a jumper and it's fixed!

Ah, that's good to hear, so glad we got to the bottom of this!
Now, obviously this leaves me wondering why I didn't notice this issue when testing your card - and the only explanation I have is that my particular graphics cards were able to function with only the VCC_VIO_AGP rail available.
I must say, I'm a little disappointed with the overall soldering work done by JLC for this particular batch - I also had issues with the SOM connector pins on some of the boards, but at least these were clearly visible and I managed to manually resolder them.

I did go around the board and clean up some of the other solder work last week. There was nothing obviously wrong, but some that could be improved. Some of the ESP pins were not soldered, but I assume these are unused. The shield around one of the USB input modules is not tied to ground. This shouldn't be much of an issue, but something I noticed.

I didn't have much time to play with it last night, other than to test one of the problematic graphics cards. At some point I'll see if I can find the root cause of the disk corruption issues over USB. I don't actually plan to run Windows on this thing long-term, but I wanted to put it through its paces.

Got my board in yesterday and got it up and running in DOS. Mostly everything seems to work great. Awesome job on an awesome board 😎

I'm having trouble getting mt32-pi to work. I've set up a Pi 2 Zero W just like the project instructs, and when the system turns on, the LED on the pi turns on. When I try to play Doom (for example) with MIDI music enabled, I hear nothing. The LED on the Pi blinks like it's receiving data and the mt32-pi logs don't report anything is wrong. I can even switch modes with m32-pi-control.

I tried checking the CS4237's mixer with the CWDMIX.EXE provided in the Github repo, but it tells me "Cannot find Crystal Sound Card." I can re-initialize the card with Unisound and turn up the Line-in with that utility, which did allow me to hear my DreamBlaster's output if I swap out the Pi for that. It also allows me to use CWDMIX.EXE to adjust the Line-in volume. However, output from the Pi remains silent.

I've double- and triple-checked the jumpers J25-27 are set to "PI" and J39-40 are set to "INT" with no luck.

EDIT: In case someone sees this later: The CWDMIX problem was my own fault: It needs the BLASTER variable set before it will work.

EDIT 2: The mt32-pi problem was that I didn't configure the output to be I2S as described here. In case that link ever breaks, you set it in the mt32-pi.cfg file like this:

1[audio]
2output_device = i2s

rknize wrote on 2024-01-12, 15:55:

I did go around the board and clean up some of the other solder work last week. There was nothing obviously wrong, but some that could be improved. Some of the ESP pins were not soldered, but I assume these are unused. The shield around one of the USB input modules is not tied to ground. This shouldn't be much of an issue, but something I noticed.

I didn't have much time to play with it last night, other than to test one of the problematic graphics cards. At some point I'll see if I can find the root cause of the disk corruption issues over USB. I don't actually plan to run Windows on this thing long-term, but I wanted to put it through its paces.

The ESP pins not soldered aren't used. As for the combined USB/Ethernet connector, you're correct that the metal housing isn't connected to ground, but the USB part is properly grounded.
I'm interested to see what you find out when testing your USB issues further.

valterb wrote on 2024-01-13, 04:13:

Got my board in yesterday and got it up and running in DOS. Mostly everything seems to work great. Awesome job on an awesome boa […]
Show full quote

Got my board in yesterday and got it up and running in DOS. Mostly everything seems to work great. Awesome job on an awesome board 😎

I'm having trouble getting mt32-pi to work. I've set up a Pi 2 Zero W just like the project instructs, and when the system turns on, the LED on the pi turns on. When I try to play Doom (for example) with MIDI music enabled, I hear nothing. The LED on the Pi blinks like it's receiving data and the mt32-pi logs don't report anything is wrong. I can even switch modes with m32-pi-control.

I tried checking the CS4237's mixer with the CWDMIX.EXE provided in the Github repo, but it tells me "Cannot find Crystal Sound Card." I can re-initialize the card with Unisound and turn up the Line-in with that utility, which did allow me to hear my DreamBlaster's output if I swap out the Pi for that. It also allows me to use CWDMIX.EXE to adjust the Line-in volume. However, output from the Pi remains silent.

I've double- and triple-checked the jumpers J25-27 are set to "PI" and J39-40 are set to "INT" with no luck.

At first glance, what you're describing looks like two separate issues - one being the CWDMIX not working and the other one the mt32-pi not outputting sound.
Let's address the CWDMIX issue:

So, first of all - you shouldn't use UNISOUND at all, there's full initialization of the CS chip to a known good state, running at boot time from the ROM/BIOS.
Running CWDMIX is one of the things I tested before shipping the boards, so it's strange that this doesn't find the card.
Two things I can think of that might cause this;
1. There's a bad solder connection on one of the ISA lines going to the CS chip, causing the CPU-to-CS communication to fail somehow. Though, that doesn't quite make sense given that you're able to hear all other audio besides what's coming from the mt32-pi.
2. You've configured the system (BIOS setting) to use the external OPL3 module and it's either not populated or doesn't work. I know the CWDMIX utility does an Adlib check (maybe among other things) to check for the presence of the chip.

I'd start by going into the BIOS settings and double checking the audio config. Play around with using either the internal or external (OPL3 module) FM synth.
Just so I have a better understanding of your issue - are you saying that FM sound works (setting "Music Sound Card" to "Sound Blaster" in Doom setup, for instance)?

Then for the mt32-pi...Also one of the things I tested 🙁 The fact that you're able to get sound from a wavetable board with the J25-27 jumpers set to "WT" but not from a Pi when the jumpers are set to "PI" (while everything else is set up the same way) I don't immediately understand. Do you have an oscilloscope or a voltmeter at hand? We could measure some voltages on the PCM5102 DAC chip perhaps?

Eivind wrote on 2024-01-13, 09:26:

So, first of all - you shouldn't use UNISOUND at all, there's full initialization of the CS chip to a known good state, running at boot time from the ROM/BIOS.
Running CWDMIX is one of the things I tested before shipping the boards, so it's strange that this doesn't find the card.

I understand that UNISOUND isn't necessary. I only tried it as a last resort when trying to rule out the Line-in volume being my problem. I did figure out why CWDMIX wasn't working though: I hadn't set the BLASTER env var. That's my mistake, I didn't know that utility required it. Setting it allows me to run CWDMIX and unmute the Line-in, so that half of the mystery is solved.

Eivind wrote on 2024-01-13, 09:26:

Just so I have a better understanding of your issue - are you saying that FM sound works (setting "Music Sound Card" to "Sound Blaster" in Doom setup, for instance)?

That is correct: Sound Blaster digital audio and FM synth through both the Crystal chip and the OPL3 work fine.

Eivind wrote on 2024-01-13, 09:26:

Then for the mt32-pi...Also one of the things I tested 🙁 The fact that you're able to get sound from a wavetable board with the J25-27 jumpers set to "WT" but not from a Pi when the jumpers are set to "PI" (while everything else is set up the same way) I don't immediately understand. Do you have an oscilloscope or a voltmeter at hand? We could measure some voltages on the PCM5102 DAC chip perhaps?

This could be a problem with my Pi or my soldering job with the pin header. I'll double check those things first and if still no luck, I do have a scope I can use to check the DAC chip.

valterb wrote on 2024-01-13, 17:21:

I understand that UNISOUND isn't necessary. I only tried it as a last resort when trying to rule out the Line-in volume being my problem. I did figure out why CWDMIX wasn't working though: I hadn't set the BLASTER env var. That's my mistake, I didn't know that utility required it. Setting it allows me to run CWDMIX and unmute the Line-in, so that half of the mystery is solved.

Good to hear! 😀

valterb wrote on 2024-01-13, 17:21:

This could be a problem with my Pi or my soldering job with the pin header. I'll double check those things first and if still no luck, I do have a scope I can use to check the DAC chip.

Sounds like a good idea! Pins 13-15 are the digital I2S inputs to the DAC, pins 6 and 7 are the left and right analog outputs.

Still doing a bit of setup on my Llama, and it’s still going well. Windows 98 is, well, Windows 98 and obviously comes with some stability caveats but I think we’re pretty close to as good as it gets.

I swapped the microSD for a 240GB Crucial SSD, did my normal fdisk/format in FreeDOS trick, and I installed 98 SE from the slipstreamed files on GitHub. Thanks for doing that. Saves a lot of headache. I put most of my “setup” files on a USB stick and just exposed that as a fixed disk (also an EXCELLENT feature).

Some super minor “bugs” encountered..

-there are 2 PCI ISA PnP entries in Device Manager (and Windows suggests getting a new BIOS to correct the issue). Seems mostly cosmetic honestly and doesn’t seem to harm anything.
-I have a PCI Universal Serial Bus device that I don’t seem to have a driver for yet. I installed the nUSB 3.6 patch provided.
-Lastly with the USB flash drive->fixed disk feature..while it works great in DOS, eventually in 98 I get I/O timeouts, garbage data and so on. I assume this is much more to do with unorthodox things Windows 98 does. Really what this means in my case is, copy the setup files in DOS to the SSD, then pull the USB flash drive and carry on entirely from SSD or network.

So anyway. Easy stuff to work around.

If I had *any* clue how to fix these items I’d offer PR’s. The BIOS is already fantastic.

Meanwhile I got my Voodoo3 2000 laced up with some better cooling, and flashed a newer V3 3000 BIOS on it. Worked great, no complaints. Should hopefully have the build off the test bench and completed next week. Still need to get the MT32-Pi working properly and a good DOS config but I’m not worried much about that at all.

Figured out my problem with the mt32-pi!

I was being a dummy and I didn't configure the output to be I2S like it describes here. Your suggestion to check the I2S pins reminded me that the DAC is I2S and I should probably see if that needs to be explicitly configured.

Maybe these two gotchas could be added to the ITX-Llama README in case someone as dumb as me comes along 😁

My only remaining problem is the ATTiny being weird, as already reported. It has about a 60% chance to happen to me on boot and it's a little extra annoying because it causes the HDD clicker to constantly click.

Also, one suggestion: Would it be possible to make Esc not choose the default boot option after the POST? If you spam it to catch the device selection before the monitor turns on, it just chooses the default and moves on anyway.

This may be obvious to those with better recollection of how EMM386 works, but I had to pass FRAME=D000 to it in order to move things out of the way of, I assume, the NIC or another BIOS shadow range. I've got Descent running happily now with EMS+XMS enabled.

I have not however been able to get the UMB region to free up according to Win98SE/DOS 7. If that trick has been figured out, please speak up. I think it's a trip to CheckIt, MSDiag or a similar utility to get a map of the 640k-1mb area.

BIOS ROM is shadowed between addresses F000 and FFFF
Video ROM is shadowed between C000 and roughly C3FF (conservatively)

-I have a PCI Universal Serial Bus device that I don’t seem to have a driver for yet. I installed the nUSB 3.6 patch provided.

Sometimes it won't auto install the driver even with nUSB 3.6 installed.
Run the driver install wizard manually and point it to C:\WINDOWS\INF and it should find the driver and install.

I have tried many AGP graphics cards. From ATI, S3 to Nvidia.

Geforce 4 440MX
GeForce 2 TI 64MB
Riva TNT 2, 64 and 32MB
Riva Vanda 16MB
Radeon 9550SE 128MB
Radeon 7500 64MB
....

None of these cards were able to run at 100%. BIOS finds the card, VGA works but as soon as I install the drivers (from philscomputerlab or CD driver) the installation goes through but after reboot this happens:

1. Windows 98 SE boots fine but Windows writes that the card "The card is not working properly".
2, Windows boots fine but I'm still in VGA and the Display is Unkown Monitor on Unkown Device. And in System Properties it has a yellow exclamation point.
3. Windows 98 SE keeps rebooting over and over again when booting.

I have tried many drivers and different card installs but it always ends up the same.

The only cards that work are S3 and ATI Rage II (4mb), but they don't handle 3D very well.