There are some motherboards that can switch either PS/2 or RS232 signalling onto USB-A connectors, but this is completely non-standard hack mostly seen on some enterprise stuff few years back that seems to have mostly died away.
AT keyboard (DIN5) and PS/2 keyboards are in terms of electrical signals and the low-level framing protocol equivalent. As for the higher protocol level PS/2 is technically an superset of AT keyboard, but when used on PC platforms (or with Linux) the difference does not matter. And in reality most of the cheap keyboards you can buy only implement small subset of the protocol that is used by BIOS and Windows, such keyboards will not work with things like DEC Alpha workstations. (this also leads to somewhat surprising observation that under windows some keyboards work when plugged into mouse port, some do not)
I somehow suspect that the reason why Quake2 does this lies in the legacy of Quake1 written in DJGPP. DJGPP supports dynamicaly loaded libraries (although the API is technically unsupported and internal-only), but does not have any kind of dynamic linker, thus passing around pair of such structs during library initialization is the only way to make that work.
Mostly because that format is not strictly speaking Windows-specific but comes from Unix System V release 4. Also various oddball embedded platforms use the full NT-style PE COFF as their native object/image format (but these usually either specify i386 as machine type or place some invalid value there).
This seems to be meant as pretty much 8051 replacement. 8051 cores are duct-tape of the modern computing and in almost anything, while 8051 is not exactly C-friendly architecture.
That was long after MSP430 were widely used, that pricing was part of the launch of the "value line" G-series (And it's associated MSP430 LaunchPad eval board, which is what was priced at $4.30).
-? should be lowest common denominator, because that is exactly equivalent to passing incorrect argument list when using getopt(). Whether that should produce concise help of the kind "usage: foo -abcdeEf <file>" or full help is another question.
During the relevant time there were two predominant layouts for the number key row: “typewriter-paired”, which is more or less same as the one used today and “bit-paired” where the symbols had the same order as they have in ASCII (ie. pressing a number key while holding shift produces a character represented by that number's ascii codepoint minus 0x10)
Espressif ships the wifi driver also as an .o file that takes huge struct of function pointers to OS-provided functions that works with other RTOSes. But you need some kind of RTOS.
Primary user of 5GHz band is weather radar service. Operators of that are universally fed up with interference caused by misconfigured wifi devices, so you should do everything you can as to not interfere with that if you do not want to get huge fine from your local equivalent of FCC (in most other bands you will get a friendly warning that you are doing something you should not be doing, in 5GHz the enforcement is often swift as the amount of violators simply does not leave them much of a capacity for friendly warnings).
Originally it was more or less one for POTS, one Rx, one Tx and one spare (used for power in ISDN S/T interface, which otherwise shares the same pinout).
Then came 1000-base-T, where the “base” is kind of misnomer and it is actually related to SHDSL. Each pair is essentially a separate full-duplex 250Mbps link with active echo cancellation and four of them is combined to create one 1Gbps link.
Technically it is an hardware limitation, amd64 in long mode has only vestigal support for memory segmentation (enough to implement Win32/ELF i386 TLS ABI and that's it), so you cannot reasonably run either 16b protected mode or vm86 tasks in 64b OS on that platform.
3210 did not support MMS, but EMS with some semi-proprietary extensions. Sending images and ringtones over EMS was generally not interoperable between different vendors.
MMS is much later technology where the user data go over HTTP, which implies at least WAP support and GPRS to be really practical.
The specification does not explicitly say that, but the clear intention is that REP with CX=0 should be no-op (you get exactly that situation when REP gets interrupted during the last iteration, in that case CX is zero and IP points to the REP, not the following instruction).
Bit-serial but multi-conductor cable. The 6 pairs, ground and if I count correctly two single-ended status lines make more sense than 30-pair Cisco serial cables or 34-pair HSSI of the 90's…
The physical layer as described in report 1822 is bit-serial, but uses synchronous clocking scheme without fixed baud-rate reminiscent of parallel SCSI's REQ/ACK. It is a weird scheme for serial links, but it has the clear advantage that it adapts to cable length automatically (but runs at significantly smaller bitrate that could be supported by the cable, which probably was not exactly an issue in 70's).
In fact the whole report 1822 deals mostly in bits (the messages on the IMP-host interface can have arbitrary bit lengths). Obviously this was done in order to support architectures with weird word sizes (eg. 36bit PDP-10).
IIRC there never was any kind of shareware version of TTD much less at any kind of stable URL that OpenTTD could automaticaly download. Also OpenTTD needed assets from particular version of TTD (different one than what I have as a boxed copy).
It is implemented in dedicated small CPLD that cannot be flashed by any software means. My understanding of relation to T2/SEP is that this CPLD serves as a kind of "IO expander" for T2/SEP which also hardwires logic like this.
If there is a discrete PA in the speaker path, then not. But I would not be that surprised if there is a single chip codec + PA combination that can conect an internal ADC to pins that are primarily meant as PA outputs of the integrated PA.
In general the power to the amplifiers is series connected and the ocean does not come into the question at all. If it did you would have huge issues with corrosion even ignoring the effects on the ocean itself. So, along the cable there is a wire that carries small DC current that goes between the amplifiers, each amplifier places zener diode along this wire and gets its power from it. At each landing station there is a current source (that is capable of developing significant open-circuit voltage) that powers this (this scheme is the reason why the cables are laid not only in loops, but in "loops-of-loops").
ThinkPads of that era used some kind of rubbery coating material, that over the time absorbed something from the environment that caused it to became this weird goo. I would not be that surprised that this weird icky goo also emits some kind of vapors that some people find repulsive. I would recommend just washing that off with 1:1 mix of acetone and isopropyl alcohol (but well, if you find the smell coming from the goo repulsive, get an FFP3 mask when you do that, as the vapors coming from that mixture are in completely different ball park)
It does not make sense to dedicate full read port for reading PC. Just run a bus directly from the register cells, which is exactly how it is done in ARM7TDMI in question.
This is one of the features of early ARM cores that show that the thing is not a classical RISC design, but traditional CISC core with RISC-like ISA and optimized internal buses.
As for the overall X.509 ecosystem (not limited to name constraints), the certification validation logic of common clients accepts various subtly, but completely, invalid certificates because CAs used to sign (or even use as root certificate) various kinds of invalid certificates, one can probably even find a certificate, that should be logically trusted, but isn't even a valid DER encoding of the (TBS)Certificate.
I assume that the mentioned “some setup” involve not only distributing the new root CA, but also somehow prepopulating the old cross-signed certificate, as the services know nothing about that and thus will not send it in their cert chain. Or am I overlooking something?