Unimportant

I'd say it depends on the type of software you're interested in. For example, if you're interested in gaming possible era's could be: ISA era, you need ISA slots for soundblaster AWE/Gravis ultrasound cards, which are required to get the incredible soundtracks in some games of old. 386+ era. Able to address more then 1MB of RAM trough protected mode, many DOS games of that era simply don't run on sub 386 systems. 3Dfx glide era. 3Dfx had it's own API, called glide. Many games of that era were hardcoded to glide and don't run on anything else (besides software rendering). So hardware that can support a Voodoo/2 card could be grouped together. (PCI 2.1 slots, windows 95/98 driver support, ...)

Before you buy anything, understand that non-sinusoidal signals are composed of multiple sinusoidal signals in superposition (harmonics). Harmonics are always on multiples of the base signal frequency (fundamental). In short, you cannot accurately view a 10Mhz square wave on a 50Mhz scope, for example. So, depending on the signals you'll be working with you might need more BW then you'd naively think.

Depends on the application. What does this MOSFET do in the VCR? Power supply switching?

Then there's the issue of soldering the new cells. Such a basic soldering iron (15W?) won't be able to heat those cells. And even if you get a soldering iron that can, you shouldn't, it's bad for the cells. The proper way is spotwelding.

Try using the STL as much as possible, it's there for that, results in short and cleaner code and tends to perform better then hand-rolled alternatives. std::vector<int> bigVec{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16}; std::vector<int> smallVec{4, 5, 6}; auto it = std::search(bigVec.begin(), bigVec.end(), smallVec.begin(), smallVec.end()); /* it = iterator to the first occurence of the sequence in bigVec. end if not found. if you need the location rather then a iterator use std::distance */ if (it == bigVec.end()) { std::cout << "not found\n"; } else { std::cout << "Sequence starts at element number: " << std::distance(bigVec.begin(), it) << '\n'; }

It's not so much about the CPU executing the instructions, a modern x86-64 CPU is perfectly capable of executing 16-bit code, but more about the entire execution environment. A computer is much more then simply which instructions a CPU understands. Any x86 CPU still boots in real mode, which is a 16-bit environment capable of accessing 1MB RAM using a 16-bit segment:16-bit offset memory model. Install freeDOS and you can run all the 16-bit DOS programs you want. However, much of these old programs are hard coded to access certain peripheral hardware directly. Many of these peripherals have been removed or modernized trough time, resulting in missing or malfunctioning functionality or even flat out crashing when the software tries to access these non-existing/modified peripherals. And, as said in the video, many things will run way too fast, which can also cause technical issues as lots of old software has hard coded timing routines for talking to hardware, etc.

Flushing stdin is undefined behavior. Use std::istream::ignore to clear input streams. cin.ignore(std::numeric_limits<std::streamsize>::max())

One can always run the wire multiple times trough the loop. Each turn adds to the detected current.

You can buy ready made units with relay outputs and adjustable trip point like these: https://www.amazon.com/Dwyer-Miniature-Current-MCS-111050-Continuous/dp/B00I9IFJOM

Have you tried connecting it to 110V AC to check if it works ? Looks like it might be a flyback current regulator design which can possibly boost voltage aswell.

That's the most likely option. The fact it took so much longer on the second system and it had to be aborted supports the view that it missed the 100000 mark.

It depends on the PSU in question. More expensive higher end PSU's create a single 12V in the flyback section, which is then further converted to 5V and 3.3V using DC/DC converters. On such a PSU you can use the 5V rails and leave the 12V unused without problems. Other PSU's however, create all rails in the flyback section, but only a single rail can be used for regulation. This is usually the 12V rail. Using only the 5V rail in such a PSU, without using the 12V rail, might cause poor regulation on said 5V line.

Are you sure someone removed those parts? Having unpopulated positions is not uncommon.

The function keys are often used in debuggers for "step over", "step into", etc. You'll probably spend a lot of time in a debugger so ...

Probably a power supply problem. The degaussing you hear is handled via a posistor and works even with a broken power supply.

Why? One does not dynamically allocate memory without a good reason.

4kHz is fine, nothing to worry about.

Into a vector I'll assume, as array sizes are fixed at compile time. #include <iostream> #include <string> #include <algorithm> #include <sstream> #include <iterator> #include <vector> int main() { std::string exampleString = "{2.5, 3.5, 36.4}"; //Test if string begins with { and ends with }. if (exampleString.front() != '{' || exampleString.back() != '}') { std::cout << "String does not begin with '{' and/or end with '}'\n"; return 1; } //Replace {} and comma's with whitespace. exampleString.front() = exampleString.back() = ' '; std::replace(exampleString.begin(), exampleString.end(), ',', ' '); //Create stringstream from string. auto iss = std::istringstream(exampleString); //Create vector of doubles from stringstream. const auto doublesVector = std::vector<double>(std::istream_iterator<double>(iss), std::istream_iterator<double>()); //Check for errors. if (!iss && !iss.eof()) { std::cout << "Error parsing string.\n"; return 2; } //Print result. for (const auto d : doublesVector) { std::cout << d << ' '; } return 0; }

You'll need one for testing/debugging. Expierenced engineers need multiple spins, testing and measuring, before they get it right. You're going to get it right first time without any testing ?

Doable in the same way it's doable to put a man on the moon... Not something you're going to be doing as a hobbyist. A cheap oscilloscope with the required bandwidth will set one back the price of a nice car - We're talking pico-second rise and fall times here (= harmonics to the moon).

Let's agree to disagree there.

So? I don't see K&R anywhere assisting me when I have to deal with the countless problems caused by omitting the brackets. I said nothing about using/not using temporary variables. I said to not declare all variables in the top of a function asif this was old C code. E.g. This: //Some code... const auto length = ... const auto width = ... const auto surface = length * width; rather then this: int length = 0; int width = 0; int surface = 0; //Some code ... length = ... width = ... surface = length * width; You declare variables at the point you need them, not in the top of the function asif old C.

The problem is that a lambda cannot be converted to a function pointer if it has a capture. A solution would be to wrap the callbacks in std::function. However, std::function's cannot be stored in a std::unordered_set as unordered_set relies on std::hash and std::equal_to, both of which don't operate on std::function. Small example using std::vector instead: #include <functional> #include <vector> #include <iostream> template <class... Params> class Event { public: template <class T> using MemberPtr = void (T::*)(Params...); using Callback = std::function<void(Params...)>; template <class T> void Subscribe(T* t, MemberPtr<T> m) { const auto lambda = [=](Params&&... params) { (t->*m)(std::forward<Params>(params)...); }; Addcallback(lambda); } void Notify(Params&&... params) const { for (const auto& callback : mCallbacks) { callback(std::forward<Params>(params)...); } } private: void Addcallback(Callback callback) { mCallbacks.emplace_back(callback); } std::vector<Callback> mCallbacks; }; struct EventListener { void eventListenerCallback(int i) { std::cout << "Received " << i << std::endl; } }; struct DoublingListener { void eventListenerCallback(int i) { std::cout << "Double of received value " << i * 2 << std::endl; } }; int main() { Event<int> event; EventListener listener; DoublingListener doublingListener; event.Subscribe(&listener, &EventListener::eventListenerCallback); event.Subscribe(&doublingListener, &DoublingListener::eventListenerCallback); event.Notify(1337); return 0; }

Simpler implementation of that logic: #include <iostream> #include <string> using namespace std; int main() { const auto numLines = 10; for (int i = 0; i < numLines; ++i) { cout << string(numLines - i - 1, ' ') << string(i * 2 + 1 , '*') << '\n'; } return 0; }

If we keep adding more humans to the global population at the rate we're doing, the crazy stuff we're going to have to do to generate enough energy for them all ought to get really scary.