A tiny universe in a bottle reveals clues to the origin of life

not one word of tronics in your reply New here? Start learning

Jan Panteltje snipped-for-privacy@comet.invalid spake the secret code <113n2iv$1oomr$ snipped-for-privacy@dont-email.me thusly:

The low-wattage poster's standard move is now visible from orbit: paste an off-topic press release, invent the missing electronics angle only after being asked, fail to trim quoted sludge, reply with "beep" and "start learning," and then pretend the problem is everyone else's technical incompetence rather than his own inability to form a design question. This is not sci.electronics.design; it is headline composting by a man who thinks "tronics" is a subject keyword and that random lab equipment becomes on-topic if he squints hard enough at the power cord.

Don Y snipped-for-privacy@foo.invalid spake the secret code <113lsl5$1ed5q$ snipped-for-privacy@dont-email.me thusly:

Seeing as how you have design experience with these chips, I'd be curious to hear your thoughts on the best way to attach them to a frame buffer capable of 1080p double buffered 32-bit/pixel. Putzing around with AI suggested that I use 1Mbyte VRAMs, if I could find them. The alternative to actual NOS VRAMs was to use modern memory with an FPGA front end to the 340x0 pretending to be VRAM.

Thoughts?

Children! Behave yourselves.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Was trump or Elon so pissed with what I wrote that he assigned you to this group? Are you human? The s*it you utter makes me think you are Elon's AI

His last launch failed... Not even all the engines came on.

Jan Panteltje snipped-for-privacy@comet.invalid spake the secret code <113o8tj$25r1l$ snipped-for-privacy@dont-email.me thusly:

There it is again: ask Jan what his ScienceDaily paste has to do with electronics design and the little Musk-shaped cuckoo clock in his head bursts through the door, screams "Elon's AI," waves a Starship abort link, and declares victory over an argument nobody was having. The topic was your off-topic headline dumping, your inability to state an electronics design question, and your retroactive "high voltage stuff" excuse, but somehow the discussion has been dragged back to Elon, because apparently every corridor in the Panteltje maze leads to the same damp shrine with a SpaceX logo on it. This is not technical discussion; it is Elon Tourette's with a newsreader.

Do you *really* want 4 billion different color/intensity combinations per pel? That means moving aa lot of data (over a fixed bandwidth bus) if you want on-screen motion or effects.

"Back in the day", 4b/pel was typically used and razzle-dazzle was created by strategically manipulating the CLUT -- let what the data *represents* be changed instead of the data itself. E.g., a set of chase lights on a marquee don't physically move -- yet give the appearance of doing so!

At 1080p, you're looking at ~2M pels per frame; doubled if you want it buffered. To repaint the screen (the "buffer") at a 60Hz frame rate, you have to process 120Mpels/second. And, *think* about how you want to process them (not just paint them into the display).

At 30Hz, half that.

What was usually done was smaller pel representations (less data per pel) and knowledge of where the frame buffer display update was currently referencing memory. E.g., let the display controller tell you when the

In a video game, slot machine, etc. this is relatively easy to do as you know (and can PREDICT) the general contents of the display going forward. With full motion video, there are few such optimizations that can be exploited -- the entire content can change from one frame to the next (so, you have to be able to repaint "the whole screen", which usually leads to compromises as to how you define that screen!)

We just used 64Kx1 DRAMS with home grown memory controllers (e.g., muxilpeckers to do the RAS/CAS addressing and a bit of junk logic to sequence the controls into the array). Fitting the memory controller to the processor in a manner that did not interfere with display refresh *but* also didn't wait-state the CPU was the typical challenge (some processors make it easy to share memory; others are tedious and the arbiter requires more careful consideration)

Using modern memory (SDRAMs) would be a bit of a design effort as the controller isn't quite as trivial.

Consider how you will *program* it. "Back then", there was no real choice but ASM. So, development was expensive and time consuming. We typically built our own debugging tools fitted to our own design technologies to provide hooks into the running system (ICEs are expensive -- especially if you need one per developer. Even moreso if you have to SHARE one!)

Figure out what you want to *do* with it. E.g., when designing the

In a video game, these are unfounded assumptions; adapting the gameplay to the limitations of the hardware would have been silly. And, adapting the implementation to TOLERATE the hardware limitations would likely negate the value of having sprite support in hardware!

Understand my disdain for TI's solutions?

By contrast, I designed a "sprite processor" that allowed for sprites of any dimension (defined in the sprite's-specific definition) and color mapping -- along with trivial rotations and reflections to economize on the amount of memory (remember, we're talking kilobytes not megabytes) used to store sprite descriptions -- to be created and exist anywhere on the screen at any time.

I could conditionally do sprite collision detection on specified sprites (i.e., did this bullet -- which is only a specific portion of THIS sprite defintion, not the whole sprite itself! -- hit anything?) as well as order sprites within the field ("in front of" vs. "behind"). *My* limitation was the bandwidth of the frame buffer interface that determined the overall limitations imposed on the game -- something that is much easier to address in a design than "what if 5 sprites want to exist on the same scan line???"

(I had a lot of fun coming up with special processors tailored to the needs of their applications. COTS offerings have to assume a more generic/universal deployment which limits the tricks they can employ)

PC hardware and GPUs have spoiled developers by hiding all of these issues behind their magic. But, this comes at the cost of more complex hardware designs. (we were building in quantities of thousands, not millions!)

Don Y snipped-for-privacy@foo.invalid spake the secret code <113pk8f$2k0tb$ snipped-for-privacy@dont-email.me thusly:

- 24-bit RGB double buffered

- 32-bit Z buffer

- 8-bit window id for fast clear

For best color gamut representation, 8-bits per channel isn't even enough, you really want at least 10-bits per channel. The ARS (Advanced Rendering System, another period E&S device) hardware did this to get full fidelity gamma corrected 8-bits output per channel.

Agreed. Hence double buffered.

Yes, but I want truecolor rendering, not indexed color rendering.

It's my understanding that you can reconfigure the video modes in the

Yes, I know.

But we're not really getting at an answer to my question, you're talking about what other people did back then.

You've still not indicated your intended use.

You can create all sorts of extremely high resolution displays.

Monitors used to display digital X-Rays are insanely detailed but aren't used to display MOVIES due to the sheer amount of data that must be processed. E.g., this unit:

But, you need two people to transport it (80 pounds) and could buy a car for what you'd spend on it ($35K).

You still have to be able to fill one plane in the time it takes to display the other. It's a bandwidth question. If you're emulating spinning reels of a slot machine, most of the display image is static (or simple CLUT effects). So, a CPU in the display controller (e.g., 34010) can actually repaint the display CONTENT as fast as it is being displayed. Especially if the content can be predicted (like the next section of a simulated "reel" rolling past a display window).

If, OTOH, you want to do full motion video where the entire display is repainted at frame rate, then you need a pipe that is wide enough AND a CPU that can generate that "new data" at the corresponding rate.

There are reasons video games had static backgrounds, few active colors, etc. -- every capability you rely on adds to cost. (the software folks would BEG for a 2 (two!) MHz version of the hardware but the cost increase was never sufficient to justify such a move -- everything has to be twice as fast!!)

If you want 2026 capabilities, then use 2026 hardware (and software).

Then something has to give. I don't believe you can *move* 120MB/sec with a 34010, let alone *synthesize* that imagery at the same time.

There's no way to relate to what you are asking without knowing your intentions and constraints you are willing to impose on your design and application.

If I gifted you one of the aforementioned monitors, it would be a fancy paperweight -- no way to drive it and nothing to

If you can drive a 1080x1920 display but can't alter the contents of the frames at a meaningful rate (for whatever application you intend), then you've got a similar paperweight.

Never mind; I've found a better way to explore the design space.

-- "The Direct3D Graphics Pipeline" free book

You're clearly going to need more horsepower if you intend that level of resolution and color depth in the frame buffer. Recall, TIGA was really only good on PCs for CAD/EDA type work -- largely static.

Oops, you did ask one important question that I didn't answer.

Don Y snipped-for-privacy@foo.invalid spake the secret code <113qobh$31b0i$ snipped-for-privacy@dont-email.me thusly:

A hardware accelerated implementation of PHIGS-PLUS, which basically means 3D with lighting, depth cueuing and Gouraud shading. Also, basically OpenGL 1.x with no texturing.

As I said, you're going to need more horsepower.