Unimportant

Indeed, as @gabrielcarvfer said, template definitions should be placed in the include file so they are completely visible in each compilation unit where they are included. The reason should be obvious, they can't be compiled, and linked later, the regular way since they need to be specialised for each diffirent template type they are invoked with.

Your typical 9V battery has too high an internal resistance. It cannot output a lot of current. Certainly not enough for such a camera.

Do you have a C compiler for that thing ? Do you know how to access it's graphic subsystem to plot pixels ?

That wouldn't be a valid fix. The function would return a pointer to a local array that ceases to exist as soon as the function returns. A solution would be to pass a pointer to str to the function for it to use.

@ImGodz According to the service manual there's an additional 270 ohm in series with the headphone output.

@Malalkin I'd go for the standard boost-converter topology then: (image from wikipedia) For the switch and diode, use parts that can handle the desired output voltage, and required current. The diode should be fast recovery, probably a high voltage schottky. For the inductor use a ferrite core with many windings, the more inductance the better (upto a limit of course, the core will saturate at some point anyway). Use your 555 to generate adjustable PWM to drive the switch transistor. Start with a low duty cycle and slowly move it up until the core saturates (you'll see the current draw spike up, a scope would help with this). Then back it off a fair bit, you don't want to be in the saturation region. That'll set it to it's maximum. With the right inductor you should be able to reach a pretty high voltage. Mind you it'll draw substantial amount of current, you cannot create energy out of nothing. High voltage, low current out means low voltage, high current in. Use a high voltage elco as capacitor but put some film capacitance in parallel with it to compensate for the elco's poor properties. Build this on a proper perf board with short connections to keep stray inductance low in both current loops.

@Malalkin Considerations: 1N400x has way too slow reverse recovery. Use 1N4148 or schottky diode. Regulation zener D2 is required for freewheeling. Whitout it (and no load) voltage will rise and kill transistor/cap. Second image has way too low inductor turns (cant see first very well). Its not just the ratio between pri/sec, which can be 1:1. You need enough inductance. Wikipedia lists 20 turns for each. Make sure to use ferrite core toroid. Ferrite is typically black. Resistor color bands are unclear in picture. Last band looks like it might be orange in stead of brown. Make sure it's not many kilo-ohms. Perhaps try BigClive's original joule thief first: http://www.bigclive.com/joule.htm The original joule thief just drives a LED, soldered straight onto the transistor, which does all the clamping. This modified design, basically a poor man's boost converter, might not be as suited for a dead-bug method as it might be more suseptible to stray inductances causing ringing/resonance and killing the transistor.

On x86/x64, the CPU throws an invalid opcode exception. Whatever happens then depends on the OS, which should have installed a handler for that exception. One way for applications to handle supporting multiple instruction sets would be to check CPU capabilities at runtime using the CPUID function and selecting the correct version of a library. Using diffirent DLL's for each supported instruction set, for example. Altough modern C++ compilers can create vectorized code under the right conditions it requires manual optimisation for the best performance. Using immintrin.h, for example.

So basically it's returning in tenths of a degree. If you're going to print that on a display or something you don't even need to convert anything, just drop a decimal dot in there. That's often done with microcontrollers to avoid floating point.

Take note that in a lot of countries the light circuits are fused at lower currents then thr wall socket circuits. So you won't be able to use the socket for high power appliances.

SDL can decode mp3 and handle the output side of things. On top of that it's available on many platforms thus portable. https://gist.github.com/cdave1/10563386&ved=2ahUKEwjSt_7r4IbsAhVLsaQKHfswAYkQFjAAegQIAhAB&usg=AOvVaw230gaWNAWOsUFs_5EYw9xd&cshid=1601121105707

I assume you mean flowcharts? We use them mainly for interface design of large applications. Any non trivial application will end up with a complex interface (you can click this, but not when that is enabled, and you shouldn't be able to do that when this condition is not met, etc...). So we plan these things beforehand with flowcharts.

Have you even tried compiling it? (it should't, you've got code outside a function body.)

With RAM sizes increasing constantly, the statistical error chance rises with it. If you double your RAM there's now twice as many bits to possibly go faulty. Now, of course the manufacturing technology improves as well and increases the reliability of the produced parts. However, do you think it realistic to improve reliability at the same rate as size increases ? It isn't. So yes, statistically, RAM is becoming more unreliable with size increases outpacing manufacturing improvements.

The C program is broken. Both i and j can reach a value of 99999. Multiplying them would overflow int. signed int overflow is undefined behavior.

I'd say the low level stuff. There's an abundance of ever more abstract languages, further and further removed from the hardware, and the accompanying programmers who know less and less about how things work under the hood. That's nice and all but what I see regularly: Their abstract machine fails in some way or the other -> they're clueless about what to do next. Less and less people in the fields that actually design and build the underlying systems these languages run on. And as a result, those who do have this knowledge can eat all the other's lunch.

Just pointing out the futility of people standing at the back of the car pointing and discussing why it won't run while the engine is in the front.

I can't imagine 4 SOT23-5 voltage regulators doing much talking over USB, so the party pieces of this camera are on the unseen backside of the PCB.

Doesn't matter, it's still linear, it'll dissipate +100W worst case - that's way too much to be reasonable. (and the chip can nowhere near handle that kind of power/current).

Unusable, 12V/9A would dissipate +100W worst case.

The options are (from simplest to most complex): A simple fuse that pops when you go above the allowed current and needs to be replaced. An electronic fuse: A circuit that disconnects the load when it goes above the allowed current and then needs to be manually reset (or resets itself when the fault condition goes away). Linear current limiter: A circuit that does not allow more then the allowed current to flow to the load and lowers the load voltage as required. Probably not usable in this case as it would dissipate around 100W worst case here. Switching current limiter: A circuit that does not allow more then the allowed current to flow to the load but does so by switching current trough an inductor on and off quickly - dissipates little power.

Looks like a 2 layer board? Make the complete underside one large ground plane. Put all other traces on the top side. Use way thicker traces and/or polygons (especially the traces that actually carry current, such as power traces and the outputs to the motor). Don't place traces so close together for no reason, leave some room (it's a simple board, no need for acrobatics). Place C2 and C3 physically close to IC1. C1 is bulk capacitance - place it physically close to the POWERIN connector. Put a 100nF decoupling capacitor close to U$1's power pins. Edit: Also, this looks autorouted. Don't do that. Route manually, otherwise you get a mess like this. The autorouter is only meant to autoroute things like data or addressbusses.

@artuc He also mentioned a DC-DC converter can rely on the capacitor ESR for loop stability. (The ESR introduces a zero which provides phase boost at higher frequencies). Polymers have much lower ESR then plain electrolytics. The result might not be stable or have such low phase margin that it rings and overshoots. Edit: nvm, I tought you meant replacing plain electrolytics with polymers.

In the power supply or the motherboard? Because from what I can see in online pictures the PS3 motherboard does not contain any electrolytics. The other types of capacitors typically don't show visual signs of failure (except for tantalum, which can be overly visual on failure).

I'd stick with the configuration as it was originally. More often then not, if a modern DC-DC converter has a bank of capacitors rather then 1 large one it is done to reduce ESR and/or spread ripple current and power dissipation across multiple capacitors, not because they need a certain amount of microfarads. In fact, at the high frequencies modern converters switch at you theoretically only need a very small amount of capacitance, in practice much more has to be used to counter above mentioned non-ideal properties.