Thanks! I was actually thinking of trying a similar thing of what you suggested (bind a command line OC utility to a keyboard shortcut), but I couldn't find any. I'm not sure if changing the clock like that would insta-crash, never tried it.
The FPGA can't hold a copy of the VSA BIOS. The VSA BIOS needs to be executed by the laptop.
From what I tested so far, the only thing that's not working as expected is the clocks that reset when set by V.ctrl or VSA100 OC. And that might be an issue with my installation, not necessarily the lack of BIOS execution. I'll test on another identical system and see what happens. Still, not a major issue, since OC works fine with the other tool.
@EriolGaurhoth
I too dreamed of this 😀
Always wanted a 3dfx powered laptop.
@maw
Thank you!
I managed to fix the whole image shifted right bug.
Also, now 1920x1080 works (VSA-100 outputs 1920x1080). There are some timing issues to fix, as can be seen in the picture, but it works.
And the following resolutions currently work fine with the card inside the laptop ( VSA-FPGA-SCALER-PANEL chain):
640x480
800x600
1152x864
1280x1024
1600x900
1600x1024
1920x1080 with minor errors (which I hope will be an easy fix, but the FPGA is already pushed quite far...)
Sadly, I have to take a break from this for about a month.
-last time I wanted to develop a thunderbolt device with Intel's ICs, to get access to the documentation/tools, one would need to describe to Intel what's the application, and get their blessing.
Intel has surrendered the Thunderbolt standard to the USB IF and they cooked USB4 from it which is an open standard. Your best bet, however, is to get an existing DIY eGPU like the TH3P4 Lite . https://egpu.io/ is the forum for these.
But again, you really don't want to mess with that, just get a ready module which demultiplexes the PCIe signal for you -- whether it's USB4 or older TB3 doesn't matter for this use case.
@chz I wanted to use controllers made by Intel, since those are available at Mouser. They should work in a Thunderbolt or USB4 port, and that place I think is the right one for obtaining the documentation/tools.
Otherwise, I'll have to see how to source Asmedia ICs (or some other obscure ICs), which I'd like to avoid.
Either way, no datasheets are available for any of these, and while the standard is open, it doesn't help, as I don't want to build my own thunderbolt/USB4 ICs, I just want to use one.
The FPGA can't hold a copy of the VSA BIOS. The VSA BIOS needs to be executed by the laptop.
Well, as long as FPGA can access PCI you can add little microcontroller on it that will write bunch of registers on power on.
Something along these lines https://www.edaboard.com/threads/interfacing- … troller.236934/
Also, don't laptop BIOSes scan and execute PCI option ROMs?
I wonder if it would be possible to create something like that not in MXM format, but rather in PCCard? Quiet a lot of old laptops and devices have a PCCard/PCMCIA port which should be similar enough to PCI.
Worked on the firmware side a bit. Now the microcontroller reads the VSA-100 I2C temperature sensor, internal temperature sensor, and monitors the PGOOD signals of the PSUs.
If the VSA or MCU temperature are greater than a certain threshold, or if one of the power rails goes down (eg. due to overtemperature) the MCU immediately turns off the power rails and sends an emergency shutdown signal to the laptop. This is tested and works fine.
Fan is now controlled depending on the VSA-100 temperature. For now, it's just a simple LUT, I'll implement some hysteresis.
Backlight control was switched back to the MCU, and the scaler backlight control is fed into the MCU. The scaler can override the MCU backlight control only when it wants to turn it off.
Now for the more interesting part. The PCIe to PCI bridge has 5 GPIOs. Two of them are used for the I2C EEPROM that stores the bridge configuration. 3 GPIOs are left, and I used them to implement a bidirectional communication bus between the bridge and the MCU. These pins are set as RX, TX and CLOCK. On the MCU and host side there are two state machines implemented that are basically a shift register, and package/parse the data.
On the host side, by reading/writing the PCI configuration registers of the PCIe-PCI bridge, the GPIOs are configured as input/output and their values can be set or read. The MCU also stores configuration persistently in the FRAM.
Now, this is the first time I write a GUI application, (or a Windows application for that matter ), so the design maybe isn't the prettiest thing, but it works.
I wrote this in Visual Studio Express C# 2008, which, unexpectedly , was a joy to use.
Now backlight control from the OS works, the VSA-100 frequency can be changed, VSA-100 core voltage can be changed from 2.5V to 3.1V, and Framebuffer Size can be changed between 32MB and 64MB without tearing down the laptop and flipping a switch.
It can also read back the data that's persistently stored on the card, card model and revision, temperature sensors.
This will need further testing on multiple boards (there's only 1 at the moment), as the FPGA is running a bit out of spec at this resolution.
I looked closer at the display and the image is still shifted to the right (not as much as before) and I started to investigate. It's either the VSA, my FPGA code, or the scaler.
-tested the scaler, by using the devboard I previously made, connected to a PC and to the laptop display. It looked fine.
-generated a test image from the FPGA (on the MXM card), in the laptop, it looked fine.
-plugged a V5 DVI in a PC, connected to the scaler devboard and to the laptop display, offset
-V5 DVI in a PC, connected to a regular HDMI monitor, and the offset is there.
I wonder if it would be possible to create something like that not in MXM format, but rather in PCCard? Quiet a lot of old laptops and devices have a PCCard/PCMCIA port which should be similar enough to PCI.
I think the challenge with PCCard/PCMCIA is bus speed. I somehow doubt you'd be able to get a Voodoo4 on a PCCard/PCMCIA because I think it would require too many transfers per second that the PCMCIA bus wouldn't be able to handle. However, I've always believed that it would be possible to get an older PCI graphics card, perhaps a Voodoo1 or Voodoo2, working on a PCMCIA card. There was/is a company called Magma that made PCMCIA cards with an interface to a portable PCI chassis, which in turn you could connect a full PCI card to, including graphics cards, though those were usually used for external displays (you'd likely need to bodge some kind internal mechanism to the pins of the PCMCIA connector to loop the video back to the internal laptop display and connect with the existing notebook's GPU, since the V1 and V2 still needed an existing GPU for 2D). Since such a thing existed, it would be theoretically possible to turn that entire system, the card + PCI connector board + GPU, into an SoC just on a card, but it would be a feat of engineering beyond anything I've yet seen. And I'd want to be 1st in line to buy such a kit, if/when it exists, haha!
I think the challenge with PCCard/PCMCIA is bus speed. I somehow doubt you'd be able to get a Voodoo4 on a PCCard/PCMCIA because I think it would require too many transfers per second that the PCMCIA bus wouldn't be able to handle. However, I've always believed that it would be possible to get an older PCI graphics card, perhaps a Voodoo1 or Voodoo2, working on a PCMCIA card. There was/is a company called Magma that made PCMCIA cards with an interface to a portable PCI chassis, which in turn you could connect a full PCI card to, including graphics cards, though those were usually used for external displays (you'd likely need to bodge some kind internal mechanism to the pins of the PCMCIA connector to loop the video back to the internal laptop display and connect with the existing notebook's GPU, since the V1 and V2 still needed an existing GPU for 2D).
I had a Magma PCI enclosure and used it with a PowerVR card, it worked enough to be playable from what I remember.
Also, they were pcmcia/cardbus graphic cards, but their main purpose was to connect extra screens.
Late pcmcia revisions and cardbus offered a feature called ZoomVideo allowing the card to directly access the vram of the laptop, it was used for mpeg1/2 decoders and some capture cards to display their input without any lag.
Late pcmcia revisions and cardbus offered a feature called ZoomVideo allowing the card to directly access the vram of the laptop, it was used for mpeg1/2 decoders and some capture cards to display their input without any lag.
This idea is most promising, I didn't know there was any way for pcmcia to augment, in any way, the vram of a laptop, even if it was just for decoders and not for adding 3D acceleration. I'm wondering if such a thing would be possible: A PCMCIA that directly enhances the internal VRAM thus allowing for better graphics via the internal display as opposed to other cards (Magma, Village Tronic) that would simply output to an external display.
If such a thing is ever designed, a PCMCIA/Cardbus 3D graphics accelerator card for accelerating graphics through a laptop's INTERNAL display...it would be instantly be my favorite piece of neo-retro tech ever invented.
Dude this blew my mind, i have 2 laptops (Acer TravelMate 525TX/Dell Latitude CPi D266XT) that could benefit from something like this, i would definitely go for something less exotic too, do you think it would feasible? is it in your plan to make more cardBUS gpus?