AM reception is essentially the direct conversion of the strength (amplitude) of a given radio frequency into an audio signal. Any other noise present at the same frequency is added to the signal (superposition/interference) and therefore impacts the strength of that frequency at the receiver. Therefore it is impossible for the receiver to know whether the amplitude it received is just signal or is signal plus noise.
The claim 'the effect of random noise is to amplitude modulate' is probably not 100% correct, because to my understanding it's not actually performing modulation (the modulation happens at the transmitter but the noise happens between the transmitter and receiver), but it is impacting the amplitude at a given frequency and to a receiver this is impossible to know whether said change in amplitude happened before modulation (signal) or after modulation (noise).
FM works better because it is easier to detect the change in frequency independently of any change in the amplitude.
I'm unsure of what the correct terminology would be, but (for my linear algebra brain) you could say something like, for FM the noise dimension is orthogonal to the signal dimension, while for AM the noise and signal dimensions are the same. Therefore for FM any change in amplitude in the noise dimension should be mostly isolated from the signal dimension, while it is essentially impossible to tell what is noise and what is signal for AM - you could probably do some radio equivalent of a differential pair in order to detect noise and remove it, but then why would you bother when FM has improved noise rejection anyway.
My understanding of PC game development at the time was that most games would re-implement their own drivers for system hardware, hence why you would often need to select what kind of graphics card, sound card, and their settings during the setup. As such, a game running from a boot disk is closer to just skipping DOS and having no OS rather than implementing a custom OS, although from another perspective you might just say that the game is the OS.
Sort-of. IIRC DOS games that wanted to use more than 512KB(?) of memory had to use one of a series of particular high memory access drivers. HIGHMEM.SYS ("XMS"?), EMM386.SYS ("EMS"?), etc. You had to load these and other drivers (in particular sound and mouse drivers, antivirus programs, etc.) when booting up in your CONFIG.SYS and/or AUTOEXEC.BAT. These were referred to as 'TSR' (terminate and stay resident) programs. There were all sorts of tricks to get things working... LOADHIGH, etc. In the end, most games required one particular approach to high memory, and you had to have a CONFIG.SYS/AUTOEXEC.BAT that left enough base memory free as well. It was a huge hassle. In later days most programs used DOS4GW ... https://en.wikipedia.org/wiki/DOS/4G ... which made things a lot easier.
I was a 90s kid, and was totally head over heels for Origin Systems' games (Ultima, Wing Commander, etc). Par for course, I had a selection of DOS boot disks to set up the right operating environment for each game. Ultima VII featured a memory manager[0] based on 'Unreal Mode', which made getting it running even more precarious. The quote at the bottom of that link from the developer is really telling.
Didn't get the Ultima series so never experienced that one, but an Origin Systems game I loved was System Shock. Still unbeaten in my book for raw experience as an early FPS RPG... so damn scary. It had so much complexity to the plot, it really set the bar high. I don't think it was matched until 15-20 years later ... many far more popular games were pathetically linear, simplistic and mono-dimensional by comparison. Other early games which left a mark for me: Heretic (which for unknown reasons performed very smoothly on my graphics hardware - Oak?), Descent (first really 3D game, excellent gameplay and many overnight sessions with friends), Dune II (defined the RTS genre on PC), Mechwarrior 2 (strongly immersive and awesome experience with a proper joystick), X-Wing/Tie Fighter (strongly immersive). Later, Command and Conquer (first modern RTS), C&C2: A Bridge too Far (awesome top-down historic battles via modem). Ahh, these days why do all the games seem so rinse-and-repeat... I think the last one I played that really impressed was Shenzhen IO.
Then making a boot disk using 4DOS to manage the whole lot of it. As each game had its own idea of what being 'setup' looked like with different other TSRs (mouse, cd, etc).
I do find internationals usually do miss the second "Aussie, Aussie, Aussie". It really confuses crowds when international sports commentators come over and don't understand the call and response ordering!
Ramtha's School of Enlightenment used to come to a university I used to work at between sessions while the students were away. They would have a section of paddock fenced off and would wander around it blindfolded making "PSSHHTT" noises to stop running into each other (I assume). They definitely seemed like a peculiar bunch.
Even seated you would make these psssshhht sounds of pushing air out, you would end up sweating from a meditation session because your muscles would also be contracted as you focus on the hand position in your chest... In your mind you have to visualize words backwards and breath them out letter by letter... I still laugh at the "so be it" that has to be said with absolute certainty for your wishes to come true
It's hard to tell what's actually happening in that clip. To me it looks like the chain is actually fully off the rear sprocket just before the rear locks up (it appears to have come off around 1:12). At that point in time the rear wheel should just be free spinning. It also appears to be free spinning during the highside, which is strange because I would expect the most likely non-rider-error issue in this case to be the chain binding between the rear sprocket and the swing arm.
I'm almost inclined to call that one rider error. Their general body language and control of the bike don't suggest to me that they're an experienced rider, and it almost looks like they've just panic-braked and locked up the rear, except it's an odd speed and place to have done that too.
Programming is all about abstractions and the ways they interact. Specifically this article talks about what it means for two instances of an object to be "equal", which depends very much on what kind of equal you care about.
Consider the possibility that you order two laptops from your favourite computer store. When you order them, you customise one, then in the shopping cart you hit "+1" to order two of them, so for the purposes of this example they are functionally equivalent. When they arrive though, they have different serial numbers ABC, and XYZ. So then we start asking the question, are they equal?
One way of asking this question is "Do these two things perform the same function?" to which we can answer yes, ABC and XYZ perform the same function - this line of questioning treats the laptops as ValueObjects as described in the article - laptop ABC and laptop XYZ can be swapped for each other without concern about whether they will behave differently.
Another way of asking this question is what amounts to something closer to "Is this thing the one that I care about?". This line of questioning treats the laptops as ReferenceObjects. You've just received both laptops, taken them both out of the box, they're functionally identical except that you've decided that you want to use ABC for work stuff, and XYZ for personal stuff, and now you have some work stuff to do. You pick up one laptop and ask "Is this laptop ABC?" - not because the function of the laptops matter at this point, but now because of what they represent.
Both have their pros and cons (as described, ValueObjects are better when they are immutable, ReferenceObjects might tend to be more complex), and different languages make different choices about whether certain language primitives and standard objects/classes are implemented as ValueObjects or ReferenceObjects, but understanding them both conceptually allows you to write code that forces one kind of behaviour because that's what matters most for your chosen solution, independently of what the language you are writing it in has as its standard behaviour.
The claim 'the effect of random noise is to amplitude modulate' is probably not 100% correct, because to my understanding it's not actually performing modulation (the modulation happens at the transmitter but the noise happens between the transmitter and receiver), but it is impacting the amplitude at a given frequency and to a receiver this is impossible to know whether said change in amplitude happened before modulation (signal) or after modulation (noise).