I fell in love with the Aptera back during the Automotive X Prize era. Back then batteries were expensive enough that a vehicle that got decent range by being ultra-efficient was rather attractive. I also loved the unconventional look.
Much harder to justify in a world with normal car EVs with decent range at fairly normal car prices. There are a fair number of choices below their $40K target price. I still hope they succeed, but hard for me to imagine buying one
It's well below the average selling price for a new car in the US. In California, you'll also get HOV ("carpool") lane access, which 4-wheeled EVs lost recently.
> For me the bigger problem is that it's classified as a motorcycle, which may mean wearing a helmet, and needing to have a class M license.
The only state that requires a motorcycle endorsement for the Polaris Slingshot (an "autocycle" style trike) is Massachusetts, but that state's motorcycle definition exempts fully enclosed vehicles so it shouldn't apply to the Aptera. It's trickier to find a quick summary for helmet laws though. At least some states have exemptions for fully enclosed vehicles and some exempt all autocycles even if they're not fully enclosed. California has an exemption for enclosed trikes that meet certain minimum size and weight requirements which I expect the Aptera to meet.
Sounds like they've worked on some ActivityPub related software based on their other blog posts and codeberg.
The details remind me more of the Bluesky PDS though. It's nodejs-based and the only officially supported way to run it is via a largely self-contained docker container.
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
Honda's recent hybrids (CR-V, Civic, Accord) are like this too. Mostly series, but the engine can directly drive the wheels via a single overdrive gear for better cruising efficiency.
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.
Ah, that'd be it then; it would've been such a cool experiment.
Regardless, I don't really know if there's the notion of an SMP-enabled m68k board based on Linux so I would not really know where to start.
For SuperH, I've gotten very lucky because there's a single CPU subtype (J2, https://j-core.org/) which has SMP tidbits that helped me understand what to look for and where in terms of wiring the 32X's CPU subtype.
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?
Yes so, this was tested within a software context; the ASIC that does the bus arbitration on the side of the 32X has some of the required pins as N/C. They do a much more interesting deep-dive on the link you added.
I initially thought the 68000 side /UWR & /LWR pins were wired to the complimentary 315-5818 ones (Since there wasn't any apparent difference between the pinouts of both).
This makes the setup a bit different since you'd not be addressing the cart's PSRAM, but instead, the 32X's SDRAM. With XIP (Like on the Jaguar port) you could probably pull it off (Not sure if you'd be able to cram the entire Busybox environment but maybe a small program could do it).
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.
I was actually thinking, if memory is the bottleneck; I could always go with the Saturn instead (Or find a way to have the 32X catridge writes go through…; but I’m no EE unfortunately).
I do recall having a RAM expansion cartridge in mine that could possibly be used to fit more stuff if the main 2MBs it had were too little to hold Linux.
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.
It does require an MMU technically, this kernel is built with that in mind but I see no mention of uCLibc whatsoever on the kernel log (Or that I remember out of all the files I saw open). I’ll see if I can pinpoint exactly what it is.
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.
Much harder to justify in a world with normal car EVs with decent range at fairly normal car prices. There are a fair number of choices below their $40K target price. I still hope they succeed, but hard for me to imagine buying one