> As we know, it's always been somehow difficult or tricky to add sound for RaspberryPi. Some use gpio to generate pwm to make sound for speakers, some use I2S audio module to generate sound for speakers. But they all have some shortcomings. PWM generated from gpios on raspberryPi have much noise that make the speakers nealy usable, and I2S audio module will occupy the very precious gpio resoureces(usually take 3 gpio pins). And in some operating system there is no driver for these pwm or I2S audio module. Due to the reasons above this is how I solve the sound problem. [1]
Ok, digging into the schematic, I think I see the problem.
Almost all of the normally free GPIO is eaten up by a DPI (Display Parallel Interface) connection to the screen.
The screen should instead use the currently unused MIPI pins if you're already at the level of sophistication of laying out PCIe and USB3 traces.
That gives you back nearly all of your GPIO to use for stuff like I2S, and you can then even expose more non USB externally than just that one stemma port.
On top of that, for a project like this, I would disagree with the quality you get out of the pwm as audio thing. It's not audiophile by any means, but neither is some cheap Bluetooth receiver chip, and it's certainly good enough for the speakers that weren't designed for this case.
When I've used i2s it has required setting spi clocks that made my spi devices not function. While it does have all of these IO buses, using more than one at a time is a bit of tetris. I wouldn't be surprised if there is some hardware constraint making i2s impossible.
The design artifacts are released with a liberal license, it shouldn't be TOO hard to fix that. Though I've never worked with SPI or I2S sound chips before.
Specifically what I heard on the grapevine was that Microsoft sponsored a collection of small island nations into the ISO process, in exchange for their vote on OOXML.
Not only small islands nations. For example in Finland Microsoft partners invaded the local working group to get the standard passed in the voting process.
That is not on MS though. That is a fault of those in change of ISO, that they assign same vote weight to the enormous empires and to the microstates. Votes should be proportional to the population, full stop. Then no one would be able to abuse the system by simply playing by the rules.
So, if I'm understanding your argument correctly, failure to stop a bad actor from taking a hostile action absolves the bad actor of all responsibility for that hostile action? Because that seems to be what you're saying.
If two companies decide to merge, is it by default a hostile action? I don't think so. And what if later anti-monopoly agency decides that it was an infraction and blocks the merger? Then I think it was.
Does informing voters about something is a hostile action by default? I don't think so. But if it was later decided that there was a law breach, then it would be hostile action.
All people and even megacorps are innocent until proven guilty. Maybe even until accused of being guilty by some authority, though it is pushing it. But until someone at least does something to show their displeasure and point fingers, then yeah, no hostile action has happened, it was fair play.
So to answer your question - vote bribing is 100% a failure of the organizer of said vote and of the law enforcement system (in bigger cases) IF that organizer or govt never complained about it or did jack shit in general. But if they at least complained or better did something about the problem, then yes, vote bribing failure would be a shared responsibility of both bad actor doing it and the people who hadn't done any reasonable prevention in advance.
Since it is obvious that assigning equal weights to the countries can and did lead to the vote manipulation, I can say that ISO committee had NOT done reasonable prevention of vote manipulation and so is also guilty, just as bad actor MS.
In fact it looks like apple silicon maintains support for 4kb pages just for running Rosetta. It's one of those things like TSO that was enough of a pain to work around the assumptions that they just included hardware support for it that isn't enabled when running in regular arm software mode.
> x86 decoding must be a pain - I vaguely remember that they have trace caches (a cache of decoded micro-operations) to skip decoding in some cases. You probably don't make such caches when decoding is easy.
To be fair, a lot of modern ARM cores also have uop caches. There's a lot to decide even without the variable length component, to the point that keeping a cache of uops and temporarily turning pieces of the IFU off can be a win.
Adding to what everyone else has said, Japan is known to be a threshold nuclear state (from a weapons perspective). They explicitly stay around just weeks away from being able to perform a nuclear weapons test, and they are commonly referred to being "a screwdriver's turn" away from having a nuclear weapon.
They have massive government investment in not only maintaining that status, but also doing so on a completely domestic supply chain as much as possible.
Therefore they have the same need for supercomputers that the US national labs do (perhaps more so, since they're even more reliant on simulation), and heavily prefer locally sourced pieces of that critical infrastructure.
I wouldn't be surprised if an incredibly large part of the local push for Rapidus is to pull them off of TSMC and the supply chain risk for their nuclear program in case the whole China/Taiwan thing comes to a head.
Oh that's very interesting. Unfortunately for all of us many countries are revisiting nuclear ambitions it seems, but I can see how that makes sense from the Japanese perspective, given an environment with more aggression in general and a lot much reliable US as an ally.
But: if you consider the amount of nuclear generating capacity has (4th in the world, more than Russia), and its advanced space program, “within one year” probably means closer to “weeks or months” than “three hundred and sixty four days”.
It may be widely considered, but that doesn't mean it's an accurate assertion.
The internal structure of DEC BASIC PLUS is a far, far cry from what MS-BASIC (MSB) is. Outside of some shared syntax, the implementations are night and day.
BASIC+ (B+) is compiled to p-code, not tokenized and then interpreted. Those are completely different runtime approaches. B+ has a raw text source that is edited and maintained by the runtime, MSB does not. After you hit ENTER on MSB, your "source code" is gone. It's converted, and not necessarily losslessly, into an internal tokenized form. That tokenized form is read and recreated into the source lines you see when you LIST the program.
This scratch text file for the B+ program actually allows B+ to work in even more memory starved environments than MSB because the text is never fully loaded into RAM, so the bulk of RAM is compiled byte codes and data. You also don't have to "pay" for having extra spaces in your code, as the raw text does not impact that actual runtime size in contrast to MSB tokenized form.
B+, being compiled, supported much different styles of things like loops and if statements.
10 ODDSUM=ODDSUM + A(I) IF A(I) MOD 2 = 0 FOR I = 1 TO 10
MS-BASIC can not handle that properly with it tokenizer based system.
On the surface, they look similar with their interactive development environment. Internally, it was a completely different story.
Right, though there's two or three different questions here: whether DEC BASIC influenced MS BASIC, whether MS should have acknowledged that today, and whether DEC BASIC's influence on MS BASIC amounted to a copyright violation. On the last question, my guess would be that there's at least a reasonable argument that MS' use of the DEC BASIC code was transformative enough to get it off the hook, but IANAL. To the extent that it is in a grey area, honestly that's probably a good reason for MS to keep a diplomatic silence about any possible DEC influence today.
But that doesn't mean that there aren't two or three questions, just that there there are answers to which I, and most people here, aren't privy. And, sure, that wouldn't come as a suprise.
reply