Contact Sales
Let us know who you are...
...and we'll reach out to understand your needs.
Just how do you teach old hardware new tricks?
Software.
That’s it.
One of my favorite demonstrations of this is a demo called Area 5150. Using actual 40 year old hardware, software engineers were able to present full color 60 frames per second on hardware that, when it was state of the art, had at most 3 colors (see in the image on the right, magenta, cyan, white) visible at a time.
What makes this sort of stuff possible? Certainly the hardware manufacturers must have known it was possible at the time. And they somewhat did. The IBM hardware manufacturers made a poorly documented and poorly used 160x100x16 color mode. See page 9 of the CGA manual. That’s a far cry from the 60 fps 512-1024 colors visible in the 5150 video.
Gradually what happened was that the demo scene itself took off in the late 80’s and 90’s. Alone that resulted in a number of optimizations that when backported to 5150 hardware would still be a net win. In the 2000’s DOSBox and other emulators came out and with them, extremely careful attention to detail as hardware was often emulated right down to historical bugs and arcane features. This meant software developers became aware of hacks simply by debugging and bit matching software from that era.
As this was done, developers writing the emulated versions learned the hardware with even better familiarity than the original engineers. And so they invented techniques for 512-1024 color generation and combined them with the blitter/copper effects from the late 80’s and 90’s. And sure enough, an old dog can learn new tricks.
The CGA adapter was largely limited not by the video displays of the era, but rather the price of RAM in 1981. The whole machine retailed for about $1,500 in 1981 dollars. $200 of that would have been the 16K of ram on the CGA card. And as such, due to price constraints, color count in graphical modes was kept low.
How does this relate to Juice?
Software development paradigms are generally a consequence of the limitations of their era.
Juice represents the logical conclusion of several limitations ending at once within software and hardware development. I won’t list them all there, but from our perspective, Juice, commodified GPUs in general, and network-attached compute are a forgone conclusion.
One very important change is the development of very low-level API access with video cards. Vulkan represents a dramatic shift in how video hardware is accessed. Before, graphics API abstraction levels were at levels not convenient for either the developer or the hardware. One could contend that Vulkan makes the API very convenient for the hardware, and they’ve be correct. By a shift in very low-level API, a great deal of visibility is afforded software like Juice while also optimizing performance overall, both at the CPU and GPU level.
Another important change is compression technology in general. zlib, while a great library and the standard in open source compression since 1995, just doesn’t have nearly the throughput needed for real-time applications. Enter zstd. zstd is a magnitude or more faster and better in compression. This is not necessarily due to improvements in hardware (except for SIMD and CPU memory access) but from rethinking previous notions around compression.
Vulkan and zlib together, with a number of similar recent advances, allow Juice to operate seamlessly, with low latency and high efficiency. Watch this space as we dive deeper into the details of what makes Juice so revolutionary!
For further information, check out our Discord here
