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

Whoop-de-sodding-doo to you!

Jan has every right to post whatever he wants whenever he wants.

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

At the risk of repeating myself once more, the point is to make something with the pile of parts I was gifted and learn something about SBC design along the way. The 8K address space makes for some interesting ROM challenges in order to make a system that is not built for a specific microcontroller problem. The funky gaps in the memory map into which you can add your own peripherals made for some fun address decoder practice. See the repository for deets.

It was 40 years ago, TBH I don't remember the detailts, but it was a generic CPU. I'm pretty sure it was straight from Mick & Brick and didn't deviate from one of the designs presented there. Honestly, the UDel EE department at the time was pretty crappy at teaching any useful digital design beyond a simple state machine for a traffic light controller. When I went to UofU for CS as a grad student I discovered that undergrad CS students did more digital design in a one year course than I did during 4 years at UDel. Kurt Akeley was like one or two years ahead of me, but I never interacted with him at that time. I learned more about practical digital design by assisting John Kelly on his PhD graphics processor. I wire wrapped something like

The designer of the chip recently gave a talk on it:

There are two types of value I am getting out of these projects:

- actually building *something*

- having fun building them

I was subscribing to the AdaFruit AdaBoxes for a while but they aren't very interesting because you don't *build* anything. You connect prefabricated modules with cables and load firmware. The HackerBoxes still actually require you to solder stuff, even if you're not designing boards/circuits from scratch. Sure, they use a bunch of modules with microcontrollers and you load firmware into them, but they are less oriented as a complete thing than as a platform into which you can experiment. Plus HackerBoxes has managed to deliver a monthly project on time for multiple years, whereas AdaBox flaked out and took like a 6 yr break between the last one I got for my "subscription" and the next one that came out.

Pi Pico projects are fun that way and I've done a little fiddling around with them, but nothing serious yet. The 401x printer dongle thingy will like be a Pico with some analog ramp circuitry attached.

Suit yourself. If I'm going to invest time in a project, I want something that I can *use* from it. Otherwise, spend the time reading a book...

E.g., I am currently hoping the local maker house gets a waterjet or plasma CNC so I can use *it* to cut the copper sheeting I will be using in my "light fixtures". I have no desire to purchase one and paying someone else doesn't benefit anyone -- as it would the maker house (it would also likely drum up some interest due to its scale)

The advantage of tailoring a processor to a specific application comes from the performance benefits that accrue. E.g., having to write subroutines/functions to provide the same sort of capability makes it abundantly clear how inefficient the COTS solutions are for these tasks. That's why we have graphics accelerators, crypto coprocessors, etc. -- it's not that you *can't* perform those actions on a generic processor but that they are horribly inefficient when done thusly.

E.g., having a blitter in hardware means the processor doesn't waste its time converting linear addresses to rectangular (as well as all of the opcode fetches involved in doing so -- just move the data directly!)

I met Karl in the early 80's when he was pitching the 99K to us. He had a very different idea of how the technology should be applied (and, given that we were making lots of *product*, I had more faith in our understanding of the problem than his).

Exactly. Slap together things that someone else designed (and MADE!) and pat yourself on the back for your accomplishment.

There is (was) a TV commercial where two kids are spying on their mom in the kitchen: "She's BAKING!!!!!", excitedly.

No, she's taking a refrigerated, oversized cookie and HEATING IT UP.

It is not easy to come up with ideas for projects that others would LIKE to make -- let alone document them in enough detail for them to do so! My arrangement with my colleagues is that they can "steal" whatever I've done but don't expect me to redirect my attentions to make your life much easier (if you want a finished product, wait until it is FINISHED!)

So then, how did the periodic table form?

And then all the combination elements always interacting, finally some formed structures that remained stable ('alive' if you will) and copied themselves. The ones that were best at surviving the 'surroundings' got more complex over time and there we are. How could a bunch of cells like we design a TV or reach the Moon?

Darwin was right.

No trump or Adam and Eve needed

And extremely likely happening everywhere is 'space' 'life' Denying it ? He who does not want to see is effectively blind.

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!)