There's a lot of hardware out there that does 95% of what OP's does, though you'll pay a pretty penny for it (e.g. https://www.peplink.com/products/cellular-modems-adapters/po... ) though ther's been a flood of them from noname sellers on Aliexpress and eBay under the banner of "LTE Landline Converters"
As someone who is firmly in Portal's "target audience"
I would have enjoyed the game immensely with such an adaptive feature. Just like I appreciate the amount of work that Valve has put into closed captioning for their games.
It is insane because IBM wanted a wireless keyboard. If you're not familiar with the PCjr keyboard, it has two IR transmitters (they are electrically the same, just having two gives you a better transmission path). The PCjr system has an IR receiver.
Now, a normal keyboard cable is a standard two-wire serial protocol with clock and data. Being wireless, you have no clock, so you have to synchronize clocks, or have clock recovery built into the protocol. The PCjr does the former, using the 8253 timer chip.
The keyboard has no way of knowing if the system has received a keystroke, so the system must receive every keystroke - they can't be stored in a fifo, they can't be resent if the CPU missed it.
This rules out the possibility of using system interrupts - so when you type a key on the CPU and the IR receiver gets the start bit - the NMI line is raised, the 8253 is programmed to time the clock bursts from the IR receiver, and the CPU reads out every bit of the scancode.
The PCjr also famously has no DMA, so things like floppy drive transfers are both extremely slow and somewhat unreliable - the IBM floppy controller is somewhat additionally weird is that they disable interrupts as well. The only way the PCjr knows what the controller is doing is by polling its status register, and there is enough ambiguity that it sets a 555 timer that will reset the FDC and start everything over if things time out.
The combination of these two decisions means its inadvisable to type while your floppy drive is transferring data
How's the guts look? There's a lot of flash and pizzaz about aesthetics, but I work with files in the 400-800GB range on a regular basis, so I tend to prefer dumping gigantic SSDs into my work machines (I recently liquidated fortune 5 stock to get an 8tb disk[1]).
There's some words about "oh yeah you can upgrade this" but not many details. The only thing I've seen so far has been a single shot from the Pentagram splash where it looks like a fairly standard off-the-shelf mini PC that's been gutted and put on life support like a Raspberry Pi Cyberdeck.
I've always taken it to be that the color is unique to the situation/viewer -- a sort of pearlescent void-color that can't be described in any known language, but which just Is. More a physical phenomenon than an actual color, but distinctly hued somehow.
When many of the core datasets were being produced, a lot of these companies mangled the text to be "friendlier" to try and avoid certain issues.
The changes they made often resulted in this kind of weird nonsense: Swapping the word "Failure" for "Disappointment" in a vain attempt to keep it from saying "you're a failure", but also just stripping out words such as slurs and insults, resulting in at one point the hilarious situation in which Gemini for quite a while would INSIST that the lyrics for the Dire Straits song "Money for Nothing" contained "That little has his own jet airplane/that little is a millionaire" -- which in certain contexts changes the meaning of the song incredibly.
These hack-and-slash text manglings have resulted in some of these clbuttic sort of writing styles being used during LLM-assisted writing. A more famous version of this was caused by one paper: https://world.edu/a-weird-phrase-is-plaguing-scientific-pape...
It is the easy part. Four weeks is plenty of time.
That's why it's so bizarre that the RISC-V design is so awful.
The hard part is the software support side (though, as comments elsewhere in the thread point out, AI is pretty helpful there) and then those lovely pieces like specifying the precise behavior of interrupts.
If it had a snowball's chance in hell of going in to any kind of production anywhere, I'd have no problem spending the next month laying out an ISA. But, again, as this thread makes very, very clear: ISA really just doesn't matter.
> That's why it's so bizarre that the RISC-V design is so awful.
Not bizarre.
The design is a direct result of the biases of its initial designers, and its original intended use-case. And TBH, if you assess it by its original design criteria, it's actually pretty good.
It's just by the time RISC-V had escaped containment and was starting to become a general purpose open ISA, it was a little too late to start from the beginning and consider what the correct design criteria should even be.
Very true... but I can't help but note that basically every person I've ever met with significant experience with multiple architectures at this level, and not connected in some way to RISC-V, utterly hates the thing.
It looks an awful lot like something that was designed by a sizeable committee made up mostly of academics, most of whom won't have written ten lines of code in as many years. I don't actually know in this case, but I've had to sit and watch standards created in this manner, and Dmitry's description of the RISC-V mess matches their output fairly closely, a chaotic mess that includes every idea everyone on the standards committee has ever had, all made optional so no-one will vote against it when it comes to balloting.
How many people are working on this in your couple years example? Is that just one guy or a team of 20 or something else? Whats the average salary for the team *n this scenario?
I said "me" and "four weeks" because laying out an ISA is a pretty straightforward job for one person in one month.
The deliverable would be a (theoretically) complete specification PDF like RISC-V's.
I have little doubt that I or Adrian could do it, or plenty of others. It might not reach the quality of something like AArch64 with that level of resources, but it's not hard to beat RISC-V.
I am trying to figure out if i can afford to make it happen or not lol. Would the labour coat of getting to something good with the support infra be a fewmillion or tens of millions?
Are you trying to get to a working simulator, a working core in HDL/FPGA, a thoroughly debugged and validated core in HDL, a fast core in HDL, a validated fast core in HDL, or functioning silicon in hand?
I'd guess low six figures for the beginning of that list and mid eight figures for the end. Real silicon also needs all the uncore stuff, which is easy if you don't care how it performs and very very hard if you do.
I mean, I'm probably just being contrarian and I too would appreciate it if people stopped suffering, but like, people are suffering worse than that right now as we type this.
They did not get vaporized in the fireball. We have survivors at the hypocenter. Intense burns and radiation poisoning killed most plus conventional blast damage mechanisms. Half the acute deaths happened after the first day.
Sure, and I dunno, it probably does no one any good, I just find it mildly annoying when people treat the atomic bombs dropped in ww2 as some kind of completely incomparable atrocity.
Like the beatles joke, "were the atomic bombs the worst atrocity of all time? They weren't even the worst of that war!"
I mean, we don't really need to rank awful things, we can acknowledge anything beyond a certain level is awful without comparing them, but lots of awful things happen without involving nukes.
I mean, even only considering bombing raids, more people were killed during the various fire bombing campaigns against japanese cities and so on, granted those took 1000 planes instead of 1, but somehow I doubt the people burning to death considered that a meaningful distinction.
I wrote a tool a short bit ago to handle massive parallel hashing. Originally, it was a testbed for a project I built to make multiprocessing easier in Go.
In it, I learned that there's some interesting quirks about the way the traditional shaXsum tools work, specifically that they focus on a set of inputs from the shell command line, which means that you can exhaust the shell command line length fairly easily (try hashing every file in the Linux source tree, for instance; zsh, bash, and fish will all eventually tell you "Fuck off, there's too many characters in argv")
I also discovered that Go's handling of file handles varies drastically based on OS. Windows, for instance, has no problem with you taking a file handle to every single file on a disk. Linux will get upset but eventually capitulate, macos will stomp its feet and inform you that you are a bad child and kill you off.
> In it, I learned that there's some interesting quirks about the way the traditional shaXsum tools work, specifically that they focus on a set of inputs from the shell command line, which means that you can exhaust the shell command line length fairly easily (try hashing every file in the Linux source tree, for instance; zsh, bash, and fish will all eventually tell you "Fuck off, there's too many characters in argv")
Did you try to run something like
sha256sum **/*.*
Because if so, then you'll of course exceed the maximum number of arguments. That applies to all command-line tools that take an unbounded number of arguments.
A simple solution is to use find, which handles that for you:
find -type f -exec sha256sum "{}" "+" # 1.4s on my system for Linux 7.1.5
Alternatively, you can combine find with xargs (or parallel), which also handles it and optionally allows you to specify exactly how many arguments to process per call (-n), and how many commands to run in parallel (-P):
I always have all these parallel things take a configurable number of worker go routines, then try different numbers and run btop or iostat to see how close I am to being hardware bound. Never had a machine where the limit was anywhere close to the number of open FDs allowed. I guess I haven't proven this but my idea is having the generic scheduler have to sort 60k FDs or 2M (I have a lot of dup files in my "backup everything, randomly and repeatedly, since 1998 file system) FDs is going to thrash stuff more than just having go's runtime and my own code.
