@p
I noticed you are still using that DevTerm (very nice piece of kit) and you mentioned that you are looking into Risc-V.
I'm waiting for my VisionFive2 to come (it's taking it's sweet time) and I really do think that in the next two years that shit is going to pop off, at least in foreign markets.
Right now I'm just trying to figure how the support for Risc-V is looking, and see if I can learn more about the architecture.
@p
> Have RISC-V core for DevTerm, very pleased. It is slow but it feels nice. Absurdly high battery life, too.
Oh sick (maybe I misread the other post), it's going to be fairly sluggish in the early days, just since it's only recently becoming even affordable to buy any chipset with it. What I'm really curious about is since it's open, and there's no licensing involved. The possibilities with specialized instruction sets for different things (kind of like MMX or SSE) could get really whacky and fun.
> It's absurd. It's easier to get shit working on RISC-V than on ARM.
I'm thankful to hear that; i was hesitant but that's kind of what I've been reading on the forums and shit. It seems like the software support for the arch has experienced unprecedented growth. I'm a little weary since I remember getting into ARM when it was fairly new and getting no support for most shit for over like 2 years. (this was VERY early on)
Cheapest one they were selling when I ordered the uConsole back in October 2022, and it arrived a couple of months ago finally. I might not have picked it up had it not been both weird and cheap, because I have not been excited about the hardware in the past. One of my big objections, though, was that no one was making them and it remained to be seen if it'd work out, my suspicion was that it was a wank, overspecified pre-silicon that was driven by wishful thinking instead of the practical realities. Even if it worked, I expected Pentium f00f bugs and whatnot and I expected flakiness, weird shit, I expected X to crash randomly and the kernel to throw "illegal instruction" errors and the thing to hard-lock. I've been using the thing for a while and it's delightful, it's solid, the compiler doesn't get weird on me, no heatsink or fan and it never gets too hot to touch.
> since it's open, and there's no licensing involved.
> The possibilities with specialized instruction sets for different things (kind of like MMX or SSE) could get really whacky and fun.
Well, the RISC-V Foundation seems to be keeping a handle on extensions. I read an interview with one of the designers, interesting stuff, he wants to revive some of Cray's ideas and do vector instructions instead of multiple-dispatch and I'm kinda excited about that.
I mean, see attached for some grounding (hardware should be boring), but something cool might be happening. Cautiously optimistic.
> I'm thankful to hear that;
Oh, yeah, everything's easy to work with, etc. It's beautiful.
> I'm a little weary
:reeEEE:
> I remember getting into ARM when it was fairly new and getting no support for most shit for over like 2 years. (this was VERY early on)
Oh, yeah, it was a little rough. (I don't know how early "early" is. Acorn desktops in the 90s? iPAQ? GBA?) ARM is still a little rough. It's actually easier to work with RISC-V already. And part of that is, like, they pushed some stuff into the ISA that might be in the ABI otherwise, like which registers are caller-save versus callee-save, and that alone simplifies a lot. something_new_and_stupid.png
> One of my big objections, though, was that no one was making them and it remained to be seen if it'd work out, my suspicion was that it was a wank, overspecified pre-silicon that was driven by wishful thinking instead of the practical realities.
A fair objection; up until about a few months ago that was my thoughts almost exactly.
> I've been using the thing for a while and it's delightful, it's solid, the compiler doesn't get weird on me, no heatsink or fan and it never gets too hot to touch.
That's comforting, I've read a lot about some peeps experiences and it's hard to really figure if it's just a "them problem" or something deeper.
Though I know you are quite good about this sort of thing which gives me hope :blobcateyes:
> he wants to revive some of Cray's ideas and do vector instructions instead of multiple-dispatch and I'm kinda excited about that.
As the current meta seems to be, "spend as many cycles as humanly possible" I think that's a solid idea. Main line software is only going to get more bloated, but I think that heavy optimizations/extensions should make it quite nice for the rest of us who like running light. The vector processing is such a cool idea, but I understand why, especially back during it's time; it was a bit too forward thinking.
From my understanding, most developers, and their associated companies, were more interested in procedural, and graphics and other things weren't so advanced to the point where something like that was high-priority way back in the day. Although I think we are slowly seeing a shift. Even in systems where GPUs are the crowned king of performance (when it comes to hashing, shit like that) they are often bottlenecked by pipelined instructions from the CPU, increasing latency across the board as the CPU is still the "brain", whereas GPU's, memory controllers, etc. are all just limbs.
Even packaging the information to send to a GPU is paramount to it's success. One of the big reasons ASICs are so big in mining, from my understanding, is a closer relationship between what's being requested, and an optimized path for those instructions (which are limited to one use case)
> I mean, see attached for some grounding (hardware should be boring), but something cool might be happening. Cautiously optimistic.
He's right; however I can't help but get a little hopeful :02_laugh:
> Oh, yeah, everything's easy to work with, etc. It's beautiful.
:blobcatheart:
> Oh, yeah, it was a little rough. (I don't know how early "early" is. Acorn desktops in the 90s? iPAQ? GBA?) ARM is still a little rough. It's actually easier to work with RISC-V already. And part of that is, like, they pushed some stuff into the ISA that might be in the ABI otherwise, like which registers are caller-save versus callee-save, and that alone simplifies a lot.
Oh lol, I done screwed up there. I meant a bit early for modern applications (outside of phones), with a decent amount of interest in this latest "wave" of RISC adoption, I just didn't communicate that bit. Yeah it's had a long and hard road. I think ARM took a major hit just because the goals of most companies weren't optimized battery life and super light little clients. To do "real work" you usually would need a fat client running on your system which, to do things "optimally" you were restricted to the partial truth of CISC >>> RISC. The goals of [current year] has departed in many ways from those in the 90s. It also doesn't help that processor speeds were menial so doing more in one instruction, 20 cycles or so, was a better proposition than 3-4 instructions of varying cycle counts per.
But that's just how one dude sees it.
Wrong place, wrong time. Also to normies it was considered an emergent technology that doesn't have practical use. Though thanks to ARM being more widely adopted in the past few years, and support from major vendors, I hope that people will be more open to RISC-V once it matures a bit more.
@p
Note: I'm aware i'm speaking very generally about the 90s.
There was also a lot of interest in hobbyist spaces for parallel computing as well as other neat things like RISC. However I'm only talking about mainstream goals and the bigger manufacturers/publishers like MS, IBM, shit like that.
Also fuck Apple for leaving PowerPC to die, when they moved to Intel in later years that was pretty fucked up, they went backwards.
> There was also a lot of interest in hobbyist spaces for parallel computing as well as other neat things like RISC.
Industry kind of expected that MIPS and SPARC were going to stay where they were, no one expected x86 to eat the world. Coming into the 90s, it was m68k and then all the Serious Business computing was RISC.
> Also fuck Apple for leaving PowerPC to die,
IBM continues get a lot of mileage out of it with Blue Gene et al, it's just not something people put on the desktop. Looks like, per https://www.top500.org/lists/top500/2023/11/ , it's EPYC, Xeon, Xeon, A64FX, EPYC, Xeon, and then #7 is a POWER9.
@rher@FailurePersonified I think you learn one assembly language, it makes everything else you write make sense, you start to see things very differently. You learn two and then you can kind of extrapolate: they are largely neither complicated nor too different from each other, so learning an obscure one is easy if you know anything with a similar ISA. This one has fewer registers and it's a pain, this one has some registers that are saved for interrupt handlers, this one saves all registers for interrupt handlers, etc.
ARM is a bit weird (in a fun way): conditional flags on any instruction rather than just branches, that's the big one. Then aarch64 and thumb.
Anyway, especially old chips, you can pick up assembly for them in a couple of hours as long as you know a similar chip. For example, if you know x86, you can probably pick up most of the old 8-bit chips right away, Z-80 or 6502 or whichever.
So what I did was I learned x86 (or at least as much of it as a person learns if they want to get by; maybe no one knows the entire ISA), then I ended up with an ARM chip and it was delightful, that chip is a lot of fun. Then anything else, I have just picked up as I went. I'd like to play with RISC-V more, but I look at the compiler's output and I can more or less read it.
@ins0mniak@FailurePersonified@rher Ha, I got it from some English kid that lived in France. (He's older than we are but I'm pretty sure he was a kid when he wrote it.) It was at heyrick.co.uk , had tutorials and reference, and enough information that you could hack out some GBA games if you also had a reference to the GBA's memory map.
For sure. A pi can't run ps2. A rock 5b may be able to though.
For ps2, I'd advise buying a refurbished Dell optiplex micro with an i7 6th Gen and 16gb ram. You can grab them on ebay for between $100 and $200. They usually don't have bt, so you'd need to buy a dongle for the controllers.
As far as storage on a pi, you could get a 2TB external SSD. Then you could have entire sets, like dos, amiga, and ps1. Read time from usb isn't a huge issue for those systems.
The Odroid n2+ is another solid option if you want an sbc for emulation. Hardkernel makes quality boards.
I have one, but use it at my office as my main pc. I threw an nvme in it, and I throw it in the safe when I leave. There's literally no client information on any other cpu in my office, so if someone breaks in. 🤷♂️
I've never tried emulating on it.
I have a dell optiplex micro in my living room connected to my TV. It runs arch with plasma. Kodi and retroarch run great. The actual roms / media files are in a box upstairs. It's an old dell tower. I threw 4x8TB HDDs in it. It also runs local irc, mumble, mpd, and kabanboard servers.
I use moca adapters for my network, so I can use the existing coax in the walls.
I have full rom sets from Fairchild channel F through PS2 / Xbox, movies, albums, and an entire copy of project gutenberg, the main and generated collections. 😏
@Humpleupagus@n3f_X@FailurePersonified@ins0mniak@p@rher I’m mulling this over now and I was hoping to find a way to do that with one computer, but TV/Playstion media server access software sucks. Apple‘s attempt isn’t much better (and requires the TV to do something it doesn’t want to: be an Apple device). I have all the stuff I just…don’t want work in my living room, but if that’s your setup thats probably the way to go 😑
I use sshfs to fuse mount the remote directories to the computer in my living room. Those mounts don't include my work files. Those are on a separate system with separate accounts and ssh keys. They can only be accessed from my home office cpus.
I should have been more clear. I still have my actual ps2 so emulating it is pointless for me other than my ex jacking my fucking Ghost in the Shell game.
Add comment