Author of BlastEm, an accuracy focused high performance emulator for the Sega Genesis/Mega Drive. Currently writing C++ at Discord for the game console voice integration. Opinions are my own and don't necessarily reflect those of my employer.
https://www.retrodev.com/
投稿
FCC Investigates Radio Station over Coverage of Immigration Raid
cato.org
10 ポイント·投稿者 mikepavone··0 コメント
Show HN: BlastEm – A highly accurate and moderately fast Genesis/MD emulator
Chevy Volt was still a parallel hybrid. The gasoline engine was used for driving the wheels for highway cruise because it was more efficient. I think the range extender version of the BMW i3 was a pure serial hybrid though
Yeah, the Saturn is probably the more practical target. The SH-2s are clocked a little faster, the memory bus is 32-bit wide and there's an off-the-shelf 4MB RAM expansion cartridge. There's also a readily available, first-party PS/2 keyboard adapter (this adapter can also be used on the MD, but you need a custom passive adapter since they switched connectors).
> Good thing is, this is actual Linux (And not uCLinux) so there's still stuff that can be disabled further if for some reason it can't fit still on the available memory.
For what it's worth, the Sub 68K (mostly*) does not share memory with the main 68K. This makes SMP impossible, but on the bright side there's no contention. Sadly, there's also no way for the faster Sub 68K to directly access the cartridge so I think it would be difficult to run Linux on that CPU at all unless you can cram everything into 768KB (program RAM + word RAM)
* Word RAM can be swapped between the 68Ks, or can be operated in a split mode where each 68K gets half. There's no mechanism to allow both 68K's to access the same bank simultaneously though.
Neat to see this on HN after discussing this a bit with you on the Emudev discord (I'm Mask of Destiny there). I'm curious if you tested this on hardware. I think I mentioned this previously, but my understanding is that the SH-2s are incapable of writing to the cartridge area [0]. This would seem to preclude using the cart as RAM even with the extended "SSF2" mapper. Did you find that to be not the case or was this only tested in an emulator?
So the problem with the Model 1 that the mixing cable is trying to solve is that the expansion port on that model has audio input pins, but no audio output pins. Now strictly speaking, this is sufficient if you just want to use the MD1's headphone jack (stereo) or A/V out (mono), but in addition to the analog audio circuitry not being amazing (though honestly the MD1 is much better than the MD2 here in general) it also imposes a fairly aggressive low-pass filter. This is rather undesirable for 44.1 kHz CDDA. As you note, the mixing cable allows the RCA outputs to be mixed on the CD hardware side which works around this issue.
On the MD2, they added audio output pins to the expansion port in addition to the existing audio input pins. This allows them to achieve the same effect with no mixing cable.
I'm working on adding Sega 32X support to BlastEm [0], the Genesis/Mega Drive (as well as some related Sega systems these days) emulator. I've gotten most games working on this point, though still have some bugs to track down. Also want to increase timing accuracy (even if its not needed for games, it's helpful for homebrew development) and improve perfomance.
Yeah, with some effort it's possible (or at least it was) to extract the ROM from the Steam release and play it on the real hardware. They went to a fair bit of trouble to prevent that though. ROM isn't even stored in the clear in-memory while it's running. I guess they wanted to make sure they didn't cannibalize the cartridge release
I'm not sure it's even a particularly relevant comparison to an hour of use of various other electronic devices. I'm sure the median user is running a lot fewer queries than a Claude Code power-user, but I would guess it's still more than one in a typical session.
As someone with a self-hosted Mercurial instance dealing with this, I will say that the big names (OpenAI included, but not exclusively them) generally at least use proper user-agents and respect robots.txt, but they are still needlessly aggressive compared to traditional search indexers.
There are also scrapers that are hiding behind normal browser user agents. When I looked at IP ranges, at least some of them seemed to be coming from data centers in China.
Nothing stopping you from encoding h264 at a low frame rate like 5 or 10 fps. In webRTC, you can actually specify how you want to handle low bitrate situations with degredationPreference. If set to maintain-resolution, it will prefer sacrificing frame rate.
> They shared the polling code in the article. It doesn't request another jpeg until the previous one finishes downloading.
You're right, I don't know how I managed to skip over that.
> UDP is not necessary to write a loop.
True, but this doesn't really have anything to do with using JPEG either. They basically implemented a primitive form of rate control by only allowing a single frame to be in flight at once. It was easier for them to do that using JPEG because they (to their own admission) seem to have limited control over their encode pipeline.
You probably won't get acceptable latency this way since you have no control over buffer sizes on all the boxes between you and the receiver. Buffer bloat is a real problem. That said, yeah if you're getting 30-45 seconds behind at 40 Mbps you've probably got a fair bit of sender-side buffering happening.
> When the network is bad, you get... fewer JPEGs. That’s it. The ones that arrive are perfect.
This would make sense... if they were using UDP, but they are using TCP. All the JPEGs they send will get there eventually (unless the connection drops). JPEG does not fix your buffering and congestion control problems. What presumably happened here is the way they implemented their JPEG screenshots, they have some mechanism that minimizes the number of frames that are in-flight. This is not some inherent property of JPEG though.
> And the size! A 70% quality JPEG of a 1080p desktop is like 100-150KB. A single H.264 keyframe is 200-500KB. We’re sending LESS data per frame AND getting better reliability.
h.264 has better coding efficiency than JPEG. For a given target size, you should be able to get better quality from an h.264 IDR frame than a JPEG. There is no fixed size to an IDR frame.
Ultimately, the problem here is a lack of bandwidth estimation (apart from the sort of binary "good network"/"cafe mode" thing they ultimately implemented). To be fair, this is difficult to do and being stuck with TCP makes it a bit more difficult. Still, you can do an initial bandwidth probe and then look for increasing transmission latency as a sign that the network is congested. Back off your bitrate (and if needed reduce frame rate to maintain sufficient quality) until transmission latency starts to decrease again.
WebRTC will do this for you if you can use it, which actually suggests a different solution to this problem: use websockets for dumb corporate network firewall rules and just use WebRTC everything else
FWIW, they still seem to have not actually pulled the trigger on the account requirement and they've removed the "Starting soon" portion of the nag bar text in the Hue app (though it's still on the web page you get to when hitting "Learn more"). I do wish they would either get it over with or make it clear they're not actually going ahead with forcing accounts though.
> This is not how nuclear works. Nuclear sets a low price that corresponds to its cost, then lets more expensive marginal energy sources set the final price.
This may be an accurate description for fully-depreciated nuclear plants, but it doesn't reflect the economics of new-build nuclear at all. You have to consider both operating and capital costs. Nuclear plants are cheap to operate once built, but those operations have to pay off the capital costs. If the load factor is low, then each unit of generated power has to bear a higher portion of the capital costs. If your capital costs are very high, then you either need a very high load factor or very high spot prices to bear those costs.
> Nuclear can by the way be modulated +20%\-20%
Net demand on CAISO can go from about 2 MW to 30 MW in the summer. 20 MW of that ramp occurs over just 3 hours. I'm sure you can build nuclear plants that ramp that fast, but you need a lot more than the range you're mentioning here. Regardless, I'm not making an argument about the physics of nuclear power plants, just the economics. Expensive plants generally need high load factors to pay off the capital costs.
> nuclear generation in France can go from 25GW to 45GW during a day.
Most of France's nuclear plants are old and thus fully depreciated. The only one built recently (Flamanville Unit 3), is a good example of the bad cost trend in nuclear. While this was a bit cheaper than Vogtle Units 3 and 4 in the US on a dollars per nameplate capacity basis, at 19 billion euro it's still very expensive (and also way over budget).
France also has high rates of curtailment, which is not necessarily a huge problem for them since so much of their generation is already carbon-free, but it does suggest they're already hitting the limits of their ability to ramp production up and down. Whether this is an engineering problem or something to do with the structure of their electricity market is a bit unclear to me
> New small modular reactors promise great improvements, as they can be pre-built in factories, require limited maintenance, lower risk, and as a result much lower cost per MW.
This has been the promise for years, but so far the low costs have yet to materialize and they are estimated to have a higher LCOE than traditional plants. Currently only 2 are actually operational, a demonstration plant in China and a floating power plant using adapted ice-breaker reactors in Russia. There are a few more in the pipeline, but they are all at least a couple years out from actually producing power.
You totally can do it with some combination of overbuilding, storage and increased interconnection. It just starts to get expensive the higher the portion of your generation you want to supply with renewables. There's a good Construction Physics article[0] about this (though it simplifies by only looking at solar, batteries and natural gas plants and mostly does not distinguish between peaker and more baseload oriented combined cycle plants).
Personally, while I'm not opposed to nuclear, I'm pretty bearish on it. Most places are seeing nuclear get more expensive and not less. Meanwhile solar and batteries are getting cheaper. There's also the issue that nuclear reactors are generally most economical when operating with very high load factors (i.e. baseload generation) because they have high capital costs, but low fuel costs. Renewables make the net-demand curve (demand - renewable generation) very lumpy which generally favors dispatchable (peaker plants, batteries, etc.) generation over baseload.
Now a lot of what makes nuclear expensive (especially in the US) is some combination of regulatory posture and lack of experience (we build these very infrequently). We will also eventually hit a limit on how cheap solar and batteries can get. So it's definitely possible current trends will not hold, but current trends are not favorable. Currently the cheapest way to add incremental zero-carbon energy is solar + batteries. By the time you deploy enough that nuclear starts getting competitive on an LCOE basis, solar and batteries will probably have gotten cheaper and nuclear might have gotten more expensive.
I have a 2017 Bolt as my only car and the slow L3 charging is definitely a downside, but I haven't found it to be a huge issue in practice. On a trip long enough to worry about fast-charging you're going to need to stop to eat periodically anyway so if you plan your charging around meals you don't end up waiting too long. Obviously gets a bit more annoying on trips that are long enough to require more than one fast-charge per-day, but I don't take trips that long frequently.
Day to day charging is generally all going to be L2 or even L1 depending on how far you drive and how long typically parked somewhere with a plug. That will be roughly the same speed in any car. Some cars do have higher capacity L2 chargers than the Bolt does, but most public L2 stations don't provide the higher current needed to see the difference.
https://www.retrodev.com/