VOGONS


Voodoo4 M4800 + Dell Precision M4800 + coreboot/SeaBIOS

Topic actions

Reply 141 of 144, by sdz

User metadata
Rank Oldbie
Rank
Oldbie

@Tiido Thanks!

Some more updates/fixes/etc:

Audio related:
-laptop headphone jack now works (and mutes internal speakers when something is plugged in)
-docking station jack (had horrible screeching, fixed from coreboot) now works (and mutes internal speakers when something is plugged in)
-hotplugging the laptop in the docking station, audio behaves as one would expect
-mute (internal speakers & headphone jacks) now works
-laptop multimedia keys (Mute, Volume Up/Down) now work even in Windows98

Video related:
-the previously fixed 1280x1024 VESA mode that worked with regular HDMI monitors did not work with the scaler used on the MXM card. Patched the VBIOS to adjust timings, fixed now.
-320x200 mode did not work with any monitor even on reference DVI V4 with reference BIOS. Only equipment that accepted that signal was a HDMI analyzer. Patched the VBIOS and now that is fixed.
Everything from 320x200 up to 1920x1080 now works.
-when changing resolution, sometimes the scaler would not re-lock on the new signal. Now, when there is a pixel clock change and the MMCM relocks, the FPGA gates the TMDS signal that is fed into the scaler for 200ms. No more issues with the scaler not relocking.
-fixed a bug in the scaler firmware (was using a GPIO to indicate when it has a valid lock, which was fed into the SMC). Now that behaves properly and the SMC gates its backlight PWM output accordingly. When there is no valid signal (eg. during resolution change) the panel backlight is off. Also, when the "monitor" is turned off, now the backlight is actually off. Mostly did this for power saving reasons when system is in idle and on battery.
-during the EC bruteforcing (where the system powered off suddenly for hundreds of times) I noticed that the scaler firmware got corrupted twice. Previously, I had connected the flash WP# pin to GND to prevent these exact issues. Turns out (if one bothers to read the datasheet) that the WP# pin of the flash does not actually protect the array. It only protects the status register. From that status register one can protect the actual array to write protected. WP# connected to 3V3, so that the scaler firmware can program the status register and protect the array. Issue should be fixed now and it could allow for a nice to have feature (more on that later).
-scaler was configured to scale 16:9 resolutions full screen on the 16:9 panel. 4:3 resolutions were upscaled to 1440x1080 and black pillarboxes were added to preserve aspect ratio.
This is nice and worked just fine, but DOS resolutions, like 720x400, are widescreen, and were stretched to fill the whole panel. This is not correct, as even if those are 16:10, they were meant to be viewed on 4:3 displays. Reworked scaler firmware so now it detects those modes and forces 4:3 aspect ratio.
720x400, 640x400, 640x350, 720x350 are now upscaled and 4:3 aspect ratio is preserved.

16:9 content:

The attachment S1.jpg is no longer available

4:3 content:

The attachment S2.jpg is no longer available

16:10 DOS modes:

The attachment S3.jpg is no longer available

This is all handled automatically, no need to configure anything.

One thing that bothered me is that now the BIOS setup screen (720x400) was not fullscreen anymore (stretched looked fine to me, screenshots on the previous page). Since I didn't want to figure how to render in 16:9 graphics mode, I added an override for that. Made BIOS/SMC firmware/scaler firmware changes, so now, when the system either cold boots or is reset (the SMC monitors the PCI reset signal), the default setting is that the force DOS resolutions to 4:3 is disabled. Just before SeaBIOS starts booting from an actual device (HDD/SSD/USB etc), the override is lifted. Thus, only when in SeaBIOS, the DOS 16:10 content is actually fullscreen (and if it fails to boot from a device and goes back to the boot menu, the override is restored).

Reply 142 of 144, by sdz

User metadata
Rank Oldbie
Rank
Oldbie

It took some doing, but I finally got the scaler's UART and I2C3 working (that devboard I made a while ago sure was useful for iterating fast as the firmware could be updated via HDMI with an Intel or Nvidia card).

I2C3 is routed to the VSA-100. Switched the VSA's I2C from the dedicated EDID EEPROM to the scaler's I2C3 (the hardware already allowed for that). Baked the EDID into the scaler firmware.
And, to the feature that actually matters, now the scaler's firmware can be updated via the VSA's DDC I2C (Linux only). Really nice not having to tear the laptop down, remove the flash IC, program it externally and put it all back together for flashing a new firmware.

The UART is connected to the SMC (which talks to the host via the PCIe to PCI bridge GPIOs), which means that the host can now control the scaler's functionality. Now, from either the BIOS setup or the DOS application or the win32 application, the following can be changed (all non-volatile, saved into the SMC's FRAM and applied automatically):

-contrast
-white balance
-edge enhancement
-and ,most importantly, selectable upscaling filters with programmable parameters. This is really a nice feature and allows one to really tune how the upscaled image looks like.
All these setting apply live, with 0 screen downtime.

The attachment S1.jpg is no longer available
The attachment S2.jpg is no longer available
The attachment S3.jpg is no longer available

Really hard to take good photos of how the screen actually looks, just a small sample:

The attachment S4.jpg is no longer available
The attachment S5.jpg is no longer available

Worth mentioning that the whole chain (VSA-100 -> FPGA -> Scaler -> LVDS panel) does 70Hz, there is no frame skipping. For example DOS 720x400@70Hz is upscaled while forcing 4:3 aspect ratio to fit 1080 vertically, centered, black bars added on each side. The signal fed into the panel is 1920x1080@70Hz.

One could make a pretty decent retro monitor with the scaler IC + current firmware and a good quality LVDS panel.

A few other fixes/updates worth mentioning:
-added BIOS setup option to set how USB disks are mapped to fixed disks (auto: only the boot device (if USB) is mapped as a fixed disk, all: all USB disks are mapped as fixed disks. Latter useful in DOS, not so much under 98 where one USB disk would appear at the same time as a fixed disk and remove storage (thus auto option)).
-downgraded SMBIOS to 2.4, Sisoft Sandra no longer blue screens when reading MB info
-investigated suspend S3. Under XP it does work, but waking from S3 results in the wrong color format on the digital video output. Because the card is powered off in S3, VSA's vidInFormat[8] and vidInFormat[22] lose the values programmed during option ROM execution and the wrong color format is set. Same thing happens on OEM V4 in a regular PC. Windows98 would also wake from S3, but go to a blue screen quite quickly. Since 98 is really not happy about S3, and there is nothing I can do about the power loss (there is no power at the MXM connector while in S3), I axed S3 support. The system no longer advertises those capabilities, so standby no longer appears as an option under 98/XP/etc. Not a huge deal, the system boots fast enough anyway.
-adding this here as it's relevant VSA100-modefix

Reply 144 of 144, by sdz

User metadata
Rank Oldbie
Rank
Oldbie

Thank you Tiido!

A few more updates:

-eventually connected a logic analyzer to the primary LPC bus (on yet another M4800, running OEM firmware), and managed to sniff what the system and EC chips were doing during dock init, docking and undocking. Got a bit lucky and enabling the LPC bridge took a lot less than I expected. After that it was only a matter of configuring the SuperIO.

The attachment S1.jpg is no longer available

Added COM/LPT setup options to the Setup page.

The attachment S2.jpg is no longer available

One can select between COM1 3F8h IRQ4 / COM2 2F8h IRQ3 / COM3 3E8h IRQ4 / COM4 2E8h IRQ3 and LPT1 378h (polled) / LPT2 278h IRQ5 (with the option to select AT / PS/2 / ECP).

IRQ7 is not available for LPT1, as it is used by the HDA. Can't really move it to another IRQ. It would work under W98, but under DOS, when using SBEMU, JEMMEX crashes if HDA is not on IRQ7. At the moment I have no idea why this happens, and already investigated this before.

COM port tested under DOS/Win98/WinXP/Linux, LPT tested with internal loopback under Linux and by probing some pins (I don't have any LPT device to test with).

The attachment S4.jpg is no longer available

Undocking on the other hand (without freezing the system while doing so), that was a huge can of worms. It works now, but it is a bit of a hack at the moment. Will address it at some point in the future.

Besides the dock SuperIO working, there is now a working LPC bus in the docking station. One could connect there rasteri's dISAppointment, or, with a little glue logic (eg. small FPGA), a real OPL3 IC.

-finished the rest of the CPU related setup options. Besides CPU turbo, now a clock cap can be selected (no cap/800MHz/ 1.2GHz/1.6GHz/2GHz/2.4GHz), hyperthreading can be enabled/disabled, CPU cores can be enabled or disabled (1/2/4) and the CPU caches can be enabled or disabled.
Also made some other fixes, with no cap and turbo enabled, the CPU (in this case i7-4800MQ) does 3.7GHz under 98/XP/Linux (before, under 98 and XP it would only do 3.2GHz, still above the base clock of 2.7GHz, but far from 3.7GHz).

The attachment S3.jpg is no longer available

With these, one can really tune performance (eg. Outlive (Windows game) isn't really playable on a fast CPU, but with the CPU capped at 800MHz, there are no issues).

The attachment S5.jpg is no longer available

Or cripple the system, eg:

DOOM, max details, FreeDOS, i7-4800MQ (2.7GHz Base clock, 3.7GHz boost clock), without MTRRLFBE or FASTVID

no cap, caches on -> 83.92FPS
no cap, caches off -> 3.65FPS

800MHz, caches on -> 62.71FPS
800MHz, caches off -> 1.33FPS

I think I'm mostly done with the coreboot/SeaBIOS part for now. Next step is designing some hardware.