I will make a couple more MXM 3.0 cards (a V3 and something more powerful than the V4 M4800), after that I will look into making some PCMCIA/Cardbus cards.
I don't know if this can be done somewhat easily, as I couldn't find any PCMCIA-PCI bridge ICs, only the other way around. If no such ICs exist, then it would need to be implemented from scratch in an FPGA, which would require deep knowledge of how PCI and PCMCIA works.

sdz wrote on 2024-08-20, 08:25:

I will make a couple more MXM 3.0 cards (a V3 and something more powerful than the V4 M4800), after that I will look into making some PCMCIA/Cardbus cards.
I don't know if this can be done somewhat easily, as I couldn't find any PCMCIA-PCI bridge ICs, only the other way around. If no such ICs exist, then it would need to be implemented from scratch in an FPGA, which would require deep knowledge of how PCI and PCMCIA works.

Dude i will say this for everyone in this thread, we are waiting for you and any amazing project you will whip out for laptops, many old laptops also had ports for docking stations that enabled people to add a PCI card, that's also an option, while other systems had some weird mini agp connection (check picture)
It's gonna be hard i guess but cool that's for sure.

Oh man, what a fantastic project, @sdz! Shame I didn't stumble across this earlier, mad wizardry!

Just to satisfy my curiosity, in regards to wet dreams of combining something like this (if you want to open-source it, that is) with my Vortex86EX-based projects, I was wondering if you could answer a few questions?

1. How hard is it to source the various components?
2. What's the approx cost of components per board?
3. What's the approx power draw?
4. Would this run over a gen 1, single-lane (x1) PCI-e connection?
5. Would you need a special video BIOS in a non-MXM, HDMI or VGA output setup?
6. How many layers are you using on the PCB?

Thanks! 😀

@Eivind Thank you! Great work on your projects as well!

I do plan to opensource it, I just need to take care of some minor things, but that implies tearing down the laptop again to mess with the MCU and FPGA firmware. At the moment I use the laptop for gaming, just finished HL on it 😀

1. How hard is it to source the various components?
In a non-LVDS/eDP setup (VGA and HDMI output), there are only 2 obsolete components, the VSA-100 and the AT49BV512-12TI FLASH IC that holds the VSA BIOS. Both of them are easily sourced. The rest of the components can be bought from mouser/digikey etc.

2. What's the approx cost of components per board?
I have no clue at the moment, but I don't think it's exactly cheap. If you want I can send you the BOM.

3. What's the approx power draw?
I haven't measured yet (it's something that I planned to do), but I guess around 20W if the VSA is not overclocked.

4. Would this run over a gen 1, single-lane (x1) PCI-e connection?
Yes, it will work fine like this.

5. Would you need a special video BIOS in a non-MXM, HDMI or VGA output setup?
No special video BIOS is needed, at the moment the card (through the MXM to PCIe x1 adapter (which is mostly passive) that I posted previously) works fine in a PC.

6. How many layers are you using on the PCB?
It's a 12 layer board.

The VGA and HDMI signals are routed to the MXM connector, and the card only needs power (7-19V), 1 PCIe lane + clock, PCIe RST.
So one could add an MXM slot next to a DM&P SOC and just plug in the card 😀

This could allow for future upgrades/downgrades (I plan a V3 MXM model and something more powerful than the V4).

If you'd like to go this route, I could assemble another MXM card and ship it to you, for devel/testing.

sdz wrote on 2024-09-10, 11:34:

@Eivind Thank you! Great work on your projects as well! […]
Show full quote

@Eivind Thank you! Great work on your projects as well!

I do plan to opensource it, I just need to take care of some minor things, but that implies tearing down the laptop again to mess with the MCU and FPGA firmware. At the moment I use the laptop for gaming, just finished HL on it 😀

1. How hard is it to source the various components?
In a non-LVDS/eDP setup (VGA and HDMI output), there are only 2 obsolete components, the VSA-100 and the AT49BV512-12TI FLASH IC that holds the VSA BIOS. Both of them are easily sourced. The rest of the components can be bought from mouser/digikey etc.

2. What's the approx cost of components per board?
I have no clue at the moment, but I don't think it's exactly cheap. If you want I can send you the BOM.

3. What's the approx power draw?
I haven't measured yet (it's something that I planned to do), but I guess around 20W if the VSA is not overclocked.

4. Would this run over a gen 1, single-lane (x1) PCI-e connection?
Yes, it will work fine like this.

5. Would you need a special video BIOS in a non-MXM, HDMI or VGA output setup?
No special video BIOS is needed, at the moment the card (through the MXM to PCIe x1 adapter (which is mostly passive) that I posted previously) works fine in a PC.

6. How many layers are you using on the PCB?
It's a 12 layer board.

The VGA and HDMI signals are routed to the MXM connector, and the card only needs power (7-19V), 1 PCIe lane + clock, PCIe RST.
So one could add an MXM slot next to a DM&P SOC and just plug in the card 😀

This could allow for future upgrades/downgrades (I plan a V3 MXM model and something more powerful than the V4).

If you'd like to go this route, I could assemble another MXM card and ship it to you, for devel/testing.

OMG sdz! You are my MASTER!

Why this topic was hidden from my sight? Fingers crossed, If You need any help (tests or anything else) let me know please I'm eager to help!

Amazing WORK!

Regards!

sdz wrote on 2024-09-10, 11:34:

@Eivind Thank you! Great work on your projects as well! […]
Show full quote

@Eivind Thank you! Great work on your projects as well!

I do plan to opensource it, I just need to take care of some minor things, but that implies tearing down the laptop again to mess with the MCU and FPGA firmware. At the moment I use the laptop for gaming, just finished HL on it 😀

1. How hard is it to source the various components?
In a non-LVDS/eDP setup (VGA and HDMI output), there are only 2 obsolete components, the VSA-100 and the AT49BV512-12TI FLASH IC that holds the VSA BIOS. Both of them are easily sourced. The rest of the components can be bought from mouser/digikey etc.

2. What's the approx cost of components per board?
I have no clue at the moment, but I don't think it's exactly cheap. If you want I can send you the BOM.

3. What's the approx power draw?
I haven't measured yet (it's something that I planned to do), but I guess around 20W if the VSA is not overclocked.

4. Would this run over a gen 1, single-lane (x1) PCI-e connection?
Yes, it will work fine like this.

5. Would you need a special video BIOS in a non-MXM, HDMI or VGA output setup?
No special video BIOS is needed, at the moment the card (through the MXM to PCIe x1 adapter (which is mostly passive) that I posted previously) works fine in a PC.

6. How many layers are you using on the PCB?
It's a 12 layer board.

The VGA and HDMI signals are routed to the MXM connector, and the card only needs power (7-19V), 1 PCIe lane + clock, PCIe RST.
So one could add an MXM slot next to a DM&P SOC and just plug in the card 😀

This could allow for future upgrades/downgrades (I plan a V3 MXM model and something more powerful than the V4).

If you'd like to go this route, I could assemble another MXM card and ship it to you, for devel/testing.

Oh wow, I'm even more interested now! 😁
I think I'll send you a DM, as not to hijack or take anything away from this great thread.

@Spitz
😁
Thanks! I'll let you know. At the moment mostly everything works fine, there are just a number of minor issues to address:

1. In aprox. 1 in 300 boots, at system start-up, the microcontroller for whatever reason triggers the laptop's thermal trip.
2. I need to tweak the FPGA timings a bit, as the VSA has quite a bit of jitter on the RGB interface, and that jitter varies depending on the specific VSA, resolution, overclock, temperature and current 3D mode (glide/D3D/opengl).
3. Some resolutions do not work: 960x720, 1280x720, 1360x768. I need to investigate this further, as it may be the FPGA, scaler, or a combination of the two. Besides these, everything works fine, from 512x384 to 1920x1080.
Edit: just checked my notes. Those resolutions don't work even with a regular DVI V5 5500 + the scaler used on the MXM card. So most likely the FPGA has nothing to do with this issue. Either the scaler doesn't like those resolutions, or it doesn't like them from a VSA-100. Next I will test those resolutions with a non 3dfx card and the scaler.

There are also some VSA specific issues, that I would like to fix:
1. 1280x960 does not work on any VSA card via DVI output.
2. From my testing, all DVI V4/V5 cards have the image shifted to the right by about 4 pixels. EDID doesn't matter, and any horizontal porch timinigs adjustment from the registry does nothing.
Ideally, I'd like to find a fix for all existing VSA cards. If not, I can fix it on this card by tweaking the horizontal porch from the FPGA.

@Eivind
I don't mind hijacking the thread, as it will probably take a bit until I start posting any significant updates again.

sdz wrote on 2024-09-10, 11:34:

...there are only 2 obsolete components, the VSA-100 and the AT49BV512-12TI FLASH IC that holds the VSA BIOS. Both of them are easily sourced.

I'm having trouble finding any, apart from one expensive ebay listing. What are the easy sources of these chips?

Is there any chance I can get one of the PCBs. I can populate the parts by hand.

@Shreddoc
VSAs can be found here, and these are the cheapest:
https://www.ebay.com/itm/323658511158?_skw=35 … yKkte8ZA&edge=0
The flash IC can be found at various suppliers.

@ahmadexp
Please wait a bit until I finish the firmware/FPGA code.

The process of making a card is a bit more involved than just soldering the parts.
You will need a Xilinx JTAG programmer for writing the FPGA bitstream into the QSPI FLASH, a SBW programmer for TI MSP microcontrollers, and a dedicated programmer for flashing the EEPROM connected to the VSA that holds the EDID for DVI, the parallel FLASH IC that holds the VSA BIOS, the I2C EEPROM that holds the PCIe-PCI bridge configuration, the SPI FLASH that holds the scaler firmware and the I2C EEPROM that holds the scaler config.

ahmadexp wrote on 2024-09-12, 03:43:

Is there any chance I can get one of the PCBs. I can populate the parts by hand.

I would also be interested in building one by hand. maybe not the BGA parts but everything else.
let me know when you have schematics somewhere we can build from!

@snipe3687 Hopefully I'll publish soon the design files.

Today I had some free time and decided to finally address the image shifted to the right by 4 pixels bug.

First thought was that there is something wrong with the horizontal timings coming out of the VSA-100. The following is from the V2 documentation, but it also applies here (hsync polarity is inverted compared to the VSA-100, but that doesn't matter):

Adjusting the horizontal back porch (hBackPorch in the above diagram) was a good place to start. I modified the FPGA code to make it smaller by increasing (doubling) the horizontal sync pulse length (hSyncOn) in the above diagram.

FBI_HSYNC_IBUF is the horizontal sync signal coming from the VSA-100, hsync_out is the increased horizontal sync pulse that is fed to the TMDS encoder block, FBI_VIDEO_D0_IBUF is one of the 12 bits of RGB data sent by the VSA.
This did absolutely nothing.

Next I took a closer look at the blanking signal coming from the VSA:

FBI_BLANK_IBUF is the blanking signal generated by the VSA, FBI_VIDEO_D0_IBUF is one of the 12 bits of RGB data sent by the VSA.
The video data is sent by the VSA exactly 4 pixel clocks after the blanking signal is deasserted. The delay is always 4 pixels clocks, regardless of the resolution. This seems wrong, and 4 pixel clocks correspond to the 4 pixels shifted to the right bug, so I delayed the rising edge of the blanking signals by exactly 4 pixels clocks from the FPGA, now it looks like this:

blank_out is the delayed signal, that is then fed to the TMDS encoder block at the same time as the RGB data.

This is how it looked before:

And this is how it looks now:

The sticker is there as a reference.

This fixed the issue for all resolutions. Obviously, this fix applies only for the V4 M4800 and not regular DVI V4 and V5 cards. In the future I'll try to find an universal fix.

OMG Sdz You are a Genious!!!! 😀))

"1. In aprox. 1 in 300 boots, at system start-up, the microcontroller for whatever reason triggers the laptop's thermal trip."

This was a bit annoying to investigate. It would only happen when the system powered up, and never during runtime. If the system was already powered on, and I attached the debugger and reloaded the code, it would never happen.
It would also never happen while I had the card outside of the system, and on my desk. Obviously.

The MCU monitors all 4 major power rails (if the power_good signal is deasserted), the temperature sensor underneath the VSA-100 and an internal temperature sensor (as it is mounted close to the VRM).
If any of the power rails shuts down (due to overtemperature or overcurrent), or if the VSA temperature is too high, or if the internal temperature sensors reads too high, the MCU would shut down all power rails, and assert the external thermal trip signal, that would cause the laptop to shut down immediately.
I don't have any extra GPIOs for sending the shutdown reason via an UART or something. I could have stored the shutdown reason in the FRAM, and dump it later somehow, but I decided to go the lazy route.

Here it is, the pinnacle of debugging:
-modified the code to behave as before, just not assert the thermal trip signal and keep the laptop powered on (with the MXM card basically shut down)
-depending on the shutdown reason, it would change the duty cycle of the PWM signal that controls the fan. 10% for the 1V0 rail, 20% for the 1V8 rail, 30% for the 2V5 rail, 40% for the 3V3 rail, 50% for internal temperature sensor overtemperature, 100% for VSA temperature sensor overtemperature.

Waited for the bug to happen again ( unsurprisingly it did only after I assembled the laptop), and when it did, I just measured the duty cycle. It was 50%.
Checked the code, and indeed, there was a bug, where the first read of the internal temperature sensor was sometimes erroneous.

Fixed that, and now the laptop doesn't shut down unless it has a good reason to.

Made some power measurements.

VSA-100 rev. 220, 64MB framebuffer size

2.5V VCORE, 166MHz
IDLE: 12W
LOAD: 14.52W

2.6V VCORE, 183MHz
IDLE: 14.16W
LOAD: 16.33W

2.9V VCORE, 200MHz
IDLE: 17.52W
LOAD 20.28W

Regarding the video offset issue of VSA-100 via the digital out port.

Under Windows XP SP3, with amigamerlin and SFFT drivers, with Voodoo4 4500 DVI, Voodoo 5 5500 DVI, and obviously the Voodoo4 M4800 (without the FPGA overriding the VSA timings), the issue is present. Regardless of the timings in the registry or the EDID of the display connected to the VSA. The offset is always there, 4 pixels, from 512x384 up to 1920x1080.

Under Windows 98SE however, with the official 3dfx driver or the generic VGA driver, there is no offset.

Irrelevant for the V4 M4800, since the Dell Precision M4800 will probably never run W98, so the FPGA correcting the timings is a good fix for now.

As for the V4 M4800, I worked on the FPGA side these last two days, and I'm pretty happy with it. The only issue that remains is that 960x720, 1280x720, 1360x768 and 1280x960(which doesn't work on regular DVI V4/V5 cards under XP with amigamerlin/SFFT) do not currently work.

I'll try getting those working, but at least for me, that's not a big issue. I've been gaming on the laptop for quite a while, and it hasn't bothered me yet.
Next step is making 4 or 5 more cards, and installing them in separate laptops, so that I can properly test for variations (VSA loves outputting jittery signal...) and the impact on the FPGA part.
If all is good, I'll publish the design files.

sdz wrote on 2024-10-09, 12:53:

Regarding the video offset issue of VSA-100 via the digital out port. […]
Show full quote

Regarding the video offset issue of VSA-100 via the digital out port.

Under Windows XP SP3, with amigamerlin and SFFT drivers, with Voodoo4 4500 DVI, Voodoo 5 5500 DVI, and obviously the Voodoo4 M4800 (without the FPGA overriding the VSA timings), the issue is present. Regardless of the timings in the registry or the EDID of the display connected to the VSA. The offset is always there, 4 pixels, from 512x384 up to 1920x1080.

Under Windows 98SE however, with the official 3dfx driver or the generic VGA driver, there is no offset.

Irrelevant for the V4 M4800, since the Dell Precision M4800 will probably never run W98, so the FPGA correcting the timings is a good fix for now.

As for the V4 M4800, I worked on the FPGA side these last two days, and I'm pretty happy with it. The only issue that remains is that 960x720, 1280x720, 1360x768 and 1280x960(which doesn't work on regular DVI V4/V5 cards under XP with amigamerlin/SFFT) do not currently work.

I'll try getting those working, but at least for me, that's not a big issue. I've been gaming on the laptop for quite a while, and it hasn't bothered me yet.
Next step is making 4 or 5 more cards, and installing them in separate laptops, so that I can properly test for variations (VSA loves outputting jittery signal...) and the impact on the FPGA part.
If all is good, I'll publish the design files.

That's awesome! If you don't mind me asking, what are the main differences between the official and various other drivers?

There are many differences... I'm not the right person to answer this question 😀

For the V4 M4800 Llama edition, I can connect one GPIO of the MCU to the FPGA, so that from the control panel, via the PCIe to PCI bridge-MCU link, it can configure the FPGA for offset fix or no offset fix. This way, it will work fine via HDMI on 98 and XP, with whatever drivers.
Could be a waste of time, as I don't think XP would run great on that CPU.

sdz wrote on 2024-10-09, 13:07:

There are many differences... I'm not the right person to answer this question 😀

For the V4 M4800 Llama edition, I can connect one GPIO of the MCU to the FPGA, so that from the control panel, via the PCIe to PCI bridge-MCU link, it can configure the FPGA for offset fix or no offset fix. This way, it will work fine via HDMI on 98 and XP, with whatever drivers.
Could be a waste of time, as I don't think XP would run great on that CPU.

Hehe, nifty!
Yeah well, for the Vortex86EX it doesn't make sense to run XP, you're right about that! If we're lucky and see the EX3 next year though... 😉
If by connecting a GPIO of the MCU to the FPGA you meant adding a hardware trace that's not already wired up, then sure - good to have that option for later?