Biostar TZ77XE4—Visual Inspection

With memories of Biostar fresh in my mind from the 990FX roundup, I have another chance to tackle a motherboard from them. This one comes in at more of a premium than the other—at an MSRP of $169 it is not the cheapest board this time. However, it does seem to have learned some lessons with the PCIe layout at least, but in terms of features we are perhaps a bit lacking.

Biostar have characteristically been black and orange, and we see it here again on their top Z77 model, the TZ77XE4. Power delivery is essentially a 10+2 (CPU/iGPU) system with large brightly colored heatsinks to remove heat, both connected via a heatpipe. These heatsinks are set a little away from the Intel designated socket area, though the memory banks are right up against the boundary—with only two sticks of memory in the board there will be enough room for most of the beefiest air coolers.

In terms of fan headers, Biostar have unfortunately put much effort in here, with only three to play with—a 4-pin CPU fan header to the top right of the socket, and two 3-pin at the south end of the board. Anyone requiring headers for fans will have to resort to providing their own fan control.

Along the right hand side, apart from the 24-pin power connector, we have a series of eight SATA ports—two SATA 6 Gbps from the PCH, four SATA 3 Gbps also from the PCH, and another two SATA 6 Gbps from an ASMedia controller. These are unfortunately not color coded, meaning users will have to double check every time that the SATA cable is going into the port as intended. Below these, we have a two-digit debug display for error reporting.

The chipset heatsink sports the bright orange Biostar color, but is rather small which could lead to it being warm to the touch. On the south side of the board, we are not exactly bursting with headers—aside from the fans, we have front panel headers, a pair of USB 2.0 headers, and power/reset/clear CMOS buttons. These buttons are all similar and next to each other, so I can just see myself accidentally pressing the wrong one from time to time. It is also important to note the location of a USB 3.0 header, just above the third full-length PCIe slot. This is a rather awkward place, and cements its use primarily for rear facing adaptors (as long as there is nothing in the PCI slot beside it).

The PCIe layout is better than previous iterations, featuring an x16 (x8 in dual-GPU), x1, x8, PCI, PCI and Gen 2.0 x4. This leaves a space between GPUs, and a spare x1, PCI and x4 when dual GPUs are being used. Note we do not have a molex connector here, suggesting that Biostar are happy with the power delivery when the PCIe slots are in use.

For back panel functionality, we have a PS2 keyboard port, two USB 2.0 ports (black), DisplayPort, HDMI, D-Sub, DVI-I, eSATA, two USB 3.0 (blue), gigabit Ethernet, two more USB 2.0 (black), and audio jacks. I should stress that even though there is a DVI-I on the back panel, it does not accept analog signals by adaptor.

Board Features

Biostar TZ77XE4
Size ATX
CPU Interface LGA-1155
Chipset Intel Z77
Power Delivery 10 + 2 + 1 + 2 (CPU/GPU/VCCIO/Memory)
Memory Slots Four DDR3 DIMM slots supporting up to 32 GB
Up to Dual Channel, 1066-2600 MHz
Video Outputs DisplayPort, HDMI, DVI-D, D-Sub
Onboard LAN Realtek 8111E
Onboard Audio Realtek ALC898
Expansion Slots 2 x PCIe x16 Gen3 (x16, x8/8)
1 x PCIe x16 Gen2 (x4)
1 x PCIe x1 Gen2
2 x PCI
Onboard SATA/RAID 2 x SATA 6 Gbps (PCH), Support for RAID 0, 1, 5, 10
4 x SATA 3 Gbps (PCH), Support for RAID 0, 1, 5, 10
2 x SATA 6 Gbps (ASMedia Controller)
1 x eSATA 3 Gbps
USB 4 USB 3.0 ports (2 back panel, 2 from headers)
8 USB 2.0 ports (4 back panel, 4 from headers)
Onboard 4 x SATA 6 Gbps
4 x SATA 3 Gbps
1 x USB 3.0 Header
2 x USB 2.0 Header
3 x Fan Headers
1 x CIR Header
1 x SPDIF Output Header
1 x Front Panel Audio Header
Power Connectors 1 x 24-pin ATX connector
1 x 8-pin 12V connector
Fan Headers 1 x CPU Fan Header (4-pin)
2 x SYS Fan Header (3-pin)
IO Panel 1 x PS/2 Keyboard Port
1 x eSATA
2 x USB 3.0
4 x USB 2.0
1 x DisplayPort
1 x HDMI
1 x DVI-D
1 x D-Sub
1 x Gigabit Ethernet
Audio Jacks
Warranty Period 3 years from date of sale
Product Page Link

Aside from the extra SATA controller, PCI slots, Power/Reset buttons and the use of all four display outputs, there's nothing much 'extra' that Biostar have put on the board which isn't already in the default chipset. This could perhaps be their downfall when it comes to conclusions after testing.

ECS Z77H2-AX Features To Watch Out For
Comments Locked

145 Comments

View All Comments

  • Iketh - Sunday, April 8, 2012 - link

    "handling input in a game engine" means nothing here. What matters is when your input is reflected in a rendered image and displayed on your monitor. That involves the entire package. Lucid basically prevents GPUs from rendering an image that won't get displayed in its entirety, allowing the GPU to begin work on the next image, effectively narrowing the gap from your input to the screen.
  • extide - Tuesday, April 10, 2012 - link

    I am sure he knows that. He was just giving a bit of detail as to his exact experience, of which I would bet is far more than most people on here. You have to be very aware of things such as latency and delay when you are handling input in a game engine. I agree with the OP and am skeptical also. The bit that makes me most curious is the transfer of the fully rendered screens from one framebuffer to the other, that has to add some latency, and probably enough to make the entire process worthless. It's not like Lucid has a good track record on stuff like this, I mean we all know how their cross platform SLI/CF took off and worked so well....
  • Iketh - Wednesday, April 11, 2012 - link

    Why would you need to physically copy framebuffers?? I'm sure pointers are used...

    I have no idea if this has tangible benefits, but theoretically it does. None of us know until we can test it. I'm more inclined to discredit the people already discrediting Lucid, despite Lucid's track record. That's what you call hating.
  • Iketh - Wednesday, April 11, 2012 - link

    excuse me, you're right... it has to copy the frame from gpu to igpu... what kind of crap tech is this???
  • ssj3gohan - Sunday, April 8, 2012 - link

    Personally, I'm absolutely uninterested in anything 'high-performance', especially fancy gaming stuff. Not to say that I don't think that's a valid market niche, but I see other possibilities.

    I'm really looking forward to new thin ITX boards with built-in DC-DC converter (i.e. running directly off a 19V brick), and I am especially wondering whether Intel (or Zotac, possibly) is going to build a golden board this time around. Last time, they made DH61AG which was a nice board, but lacked an msata port (kind of a must for a truly thin computer) and 'only' had an H61 chipset.

    With H77, I expect it will be possible to make a thin ITX board with USB 3.0 and a fast on-board SSD option, combining this with an HD 4000 equipped processor would enable users to build a truly thin (sub-4 inch thick) computer that fits on the back of their monitor but still provides ample computing power.
  • Senti - Sunday, April 8, 2012 - link

    It sounds to me that Lucid Virtual V-Sync is just glorified triple buffering with a lot of marketing and a bit of overhead for transferring frames and powering two video cards instead of one. I'm very skeptical on the HyperFormance too.
  • Cavalcade - Sunday, April 8, 2012 - link

    It seems a bit more involved than triple buffering, more like having 2 buffers where the back buffer is not flipped until it is fully rendered. Seems like this would lead to more stuttering, and given the number of times they asked Mr. Cutress to reiterate that this would be a bug, it may be something they are seriously concerned with.

    Thinking about it a little more, I'm not sure what advantages this system would have over a system with separated input and rendering modules. The academic side of me is extremely interested and hopeful, but the practical developer side of me is going to require a lot more to be brought on board.
  • Iketh - Sunday, April 8, 2012 - link

    Separate input and rendering modules, as I stated in an earlier post, means nothing. They allow for a responsive mouse cursor, for instance. But, when you actually provide input that alters the RENDERED WORLD, you have to wait for that input to reflect on screen. It doesn't matter how perfectly the software solution is architected, you still have to wait for the rendering of the image after your input.

    Lucid simply prevents renders that never get displayed in their entirety, allowing the GPU to work on the NEXT image, shortening the time from your input to the screen.
  • Cavalcade - Monday, April 9, 2012 - link

    The comment was to indicate that while I have experience writing input systems, rendering is still relatively new to me; simply a qualifier of my impression and opinion.

    The way I am understanding Lucid, it is attempting to preempt displaying a frame that is not fully rendered in time for the next screen refresh. By presenting a virtual interface to both the GPU and the application, the application believes the frame has been rendered (displaying user input at that time) and proceeds to render the next frame. Thinking more about it, would this reduce the time interval between input reflected in frame one (which was preempted) and frame two (which will be displayed) so that rather than having input sampled at a fixed rate (say 60Hz) and displayed at a variable rate, input would be more closely tied to the frame for which it is intended.

    My interest is rising, but it still seems like a rather complex solution to a problem that I either haven't experienced, or which doesn't really bother me.
  • Iketh - Tuesday, April 10, 2012 - link

    it's not preemtively doing anything, except determining if a frame added to the queue will finish rendering in time... if not, it >>>>DOESNT LET THE GPU RENDER IT<<<< and places the previously rendered image in its place, allowing the GPU to immediately begin work on the FOLLOWING frame... that's it... it cuts unneeded frames from queues

    as for your input sampling rate question, that's entirely based on how the application is coded to handle input, lucid has nothing to do with this...

Log in

Don't have an account? Sign up now