agg23

This is exactly the type of thing I was thinking of. Thanks

iroh seems like a very well positioned product in the era of people rapidly building applications for personal use. I'm really interested in seeing how they continue to grow.

I personally have been looking off and on at providing an "app relay" using it, where people can get an OSS, self-hostable (if desired), zero config way to remotely access their app/data on their network. This would be separate than a "network relay" (a la Tailscale), as this is done selectively as part of the application server and client, requires no knowledge or configuration as the user, and exposes a much smaller surface area.

I would recommend that changing to GPL just to gain better ad blocking, which is far from being a primary feature, is probably not the greatest idea if you care about licensing.

I wasn't taught directly (and don't know what I'm doing still), but I've had a lot of fun learning about retro hardware design as a software engineer. I've made a few of my own reverse engineered designs, trying to synthesize how the real designers would have built the chip at the time, and ported others for the Analogue Pocket and MiSTer project.

Here's an example of my implementation of the original Tamagotchi: https://news.ycombinator.com/item?id=45737872 (https://github.com/agg23/fpga-tamagotchi)

Beware that pressing the back arrow twice takes you to unexpected naked photos.

Unsong is extremely amusing to me for some reason. Something about how Scott comes up with reasonably sounding similarities and manages to make those relate to an overall story.

That ends up not actually being that fast. The real goal was to be able to wake the Pocket/Tamagotchi core and have it automatically fast forward time as if the device was running that whole time. But when the FPGA fabric (and my design) limits us to 1800x, that means we get a whopping 30 minutes of sim time per every 1 second of real time. So even if you slept the device for a day, it's unreasonable to wait for it to fast forward.

Nothing special happens when fast forwarding, other than you can kill your Tamagotchi very quickly :P

As someone with no hardware experience, I find working with HDLs to be a very different environment and potentially hard to reason with. I did my best to document things from a software perspective (particularly for the Analogue Pocket) (https://github.com/agg23/analogue-pocket-utils/wiki). My code is also running in some capacity in most of the main core ports to the Pocket.

I wrote my first project in VHDL (https://github.com/agg23/openfpga-pong) due to the type safety, then learned that the US (and Analogue team) primarily use Verilog, so I switched. I don't use many System Verilog features, but I saw no need to use older versions unnecessarily.

I've talked to the Amaranth people. I'm not incredibly interested in using real programming languages to write HDL, but I think I like keeping programming and hardware separate in some ways.

The Analogue Pocket is fantastic for getting started with FPGAs because everything you need is built into the device and it's not "too" expensive. You do lack Pmods. There is the fully open source Game Bub (https://www.crowdsupply.com/second-bedroom/game-bub) as a cool new platform to target, but it will have orders of magnitude fewer users than the Pocket. NOTE: I am extremely biased about the Pocket; I have a working relationship with Analogue and own the main platform ports to the Pocket (for example NES, SNES, and many more).

This is something you can accomplish very easily in a ESP32 form factor, streaming audio over wifi/bluetooth. However, it doesn't fully deliver the same experience; the goal was for it to replace your phone, so it needs to support a lot more functionality such as data persistence, offline support, notifications, cellular, maybe some form of visual IO (the laser projector), etc.

From my perspective I was just interested in the excellent industrial design, which is something that is virtually impossible for a DIY setup to attain.

It would, but the vulnerability was found and patched in mainline Android a few months after the device came out, but with over half a year until support was dropped. We obviously can't expect them to have kept the OS up to date, especially given the pressure they were under, but applying security patches seems very reasonable.

I definitely agree. Humane cared about physical device security a lot and it really shows with how they built out the firmware.

Very nice. I'm always happy to see new FPGA implementations of retro computing hardware. I've wanted to try Chisel, but have never gotten around to it.

I have spent hundreds of hours developing multiple apps for AVP, but I personally can't use it at all. My vision is uncorrected for general daily use (I wear glasses at the computer for slightly improved comfort, but I can see fine), but I find the Vision Pro to be fairly blurry, to the point that it's uncomfortable to use. I bought the custom Zeiss lenses, and they help marginally, but it's still blurry, particularly when mirroring a Mac display.

I recently had a friend with similarly good vision try it out, and he didn't think it was so bad until I mirrored the Mac display, and he agreed it was unusable.

Very disappointing for me, as this was something I was looking forward to for a long time.

I believe I looked up common machines with good prices, then searched for those individually, which obviously isn't going to work very well for this tool.

This is really nice, and I just did this analysis myself.

It seems like the tool is missing some of the better deals, like Optiplex 3070 with 9th gen i5s for ~$100, entire working system included (this is what I ended up buying).

I did this with silver (see my other comment) and it was a great experience. I was very sad to hear Shapeways is shutting down.

I custom designed a ring for my then girlfriend and sent it to Shapeways to have a mold 3D printed, then cast in silver. It turned out quite well (other than us having sizing issues). You can see my progress pictures here: https://old.reddit.com/r/3Dprinting/comments/6292xd/i_design...

----

Now, 8 years later, I'm really wishing I had designed my own ring. I would prefer to avoid the cliche metals (silver, gold, platinum), and I can't wear silver anyway (allergic). I would really like to find an interesting or unusual metal (scientifically or just in general) that isn't going to cause issues due to its hardness if my finger swells (titanium or tungsten are very difficult to cut off in those situations).

Does anyone have any material suggestions?

I have the same problem with everything being slightly blurry, including Mac mirroring, rendering it unusable. It's very annoying given I have very good vision normally, but have so much trouble seeing in Vision.

I discovered recently that I can focus fine on my hand a few inches from my face in real life, but the default onscreen keyboard position on Vision is too close for me to see clearly, even though its "much further away".

I'm very curious if they've seen reactions like this. In my mind Rewind is more egregious privacy wise, though it does have the advantage of being very unknown and default off, compared to built into Windows.

I imagine the motivation is privacy above anything else.

I'm interested. What is the subscription for? Are you running it through your own server?

It really all depends on what you want.

It may sound like shilling, but the Analogue Pocket is actually an excellent development platform because it's everything all in one; you don't need to figure out how to take input, load data, or output to HDMI, because that's all taken care of you automatically. Now you pay for that in having a $200-250 price tag, plus ~$50-70 for your JTAG adapter, but I think it's excellent for starting.

For OSS, I would probably recommend a Lattice FPGA. Gowin FPGAs are really, really cheap (Tang Nano 9k), and _partially_ support an OSS toolchain, but it's missing many core components, and I've actually found bugs in the hardware (confirmed by others), so probably stay away.

The DE-10 Nano is very capable, though fairly sought after at this point. It has a decent amount of IO, and can run the MiSTer retrocomputing project, which has the largest collection of OSS cores out there.

----

However, probably before you even buy any hardware, play with simulations. Choose your HDL (Verilog is US focused, VHDL is EU focused) and choose a simulator. For VHDL, you can use GHDL and GTKWave for an entirely OSS setup. For Verilog, I would recommend downloading the closed source Intel ModelSim, but you can also produce very fast, C++ controlled simulations using Verilator.

In any case, start simulating and looking at waveforms. Debugging multiple sets of nets at once is a very interesting experience and is at the core of what you're doing when working with FPGAs (verification is something like 80-90% of the time), so you can learn a lot without any hardware just working on that. If you use Verilator, you can have psuedo LEDs or even a display to draw on.

In theory yes, but in practice there's many sources of latency introduced by a modern system with OS, and even an emulator running on bare metal has additional latency. Framebuffers and input are the main sources, and there's no real parallel in emulators, unless you're going to multithread on dedicated separate cores, dedicating one to input, one to video, one to CPU, etc.

Now for the vast majority of users, this does not matter at all. As much as I like to think I can tell, it's probably placebo or the slightest feeling like something is not right. But I think it's a worthwhile reason to have a different method of replicating these old and eventually dying machines, and it's much more intellectually interesting as you say.

This is retrocomputing specific, but this Discord server (https://discord.gg/3wv3gMhp) has quite a few of the big devs in the FPGA gaming space, and they're more than willing to answer questions. They're what really got me going after I built my Pong core.

I have always been a big advocate of learning while doing, especially in software. Find something, preferably small, that you want to build (your Pong), and work on making it a reality. Maybe it's making Snake entirely in HDL. Maybe it's playing around with LiteX on your preferred development platform so you can build something cool with the RISC-V processor (I don't suggest this though, start with learning a normal HDL). Maybe it's simply looking through one of the existing retrocomputing cores, trying to figure out how stuff ticks.

Until you get to the CPU design level, the general concepts you'll encounter will be fairly simple. I think it's enough to just play around with blinking lights, learning how parallel synchronous logic works, relative to how we think of software working.

LiteX is very neat, but at the same time is a massive pain as soon as you move past building an example SoC. I've been spending a lot of time on this recently.

On the note of my sibling comment, a common book in this space for learning is "Designing Video Game Hardware in Verilog", which is specifically retrocomputing related.

I _technically_ had prior knowledge as a computer architecture class had us stick some premade pieces together to create a CPU we designed, but I personally wrote no Verilog, and it was a small subset of the class.

I don't have much documentation for getting started with HDLs (Verilog, VHDL, etc), but I have tried to document my process as much as possible. I have primarily developed for the Analogue Pocket, so my documentation is themed towards that device, but there's IP (code modules) and wiki entries that would be useful for everyone: https://github.com/agg23/analogue-pocket-utils

I had previously written a cycle accurate NES emulator, so I was familiar with hardware techniques, but not what they look like in circuits. The first core I wrote was a schematic accurate Pong implementation. This was both good and bad because it's very simple and has no CPU (and thus no code), but it also makes it very hard to tell what is going on. I went from there to doing a lot of ports (NES, SNES, PCE, and a few more), and after that I worked on my own cores (Tamagotchi, Game and Watch). Tamagotchi I took a very typical software approach where I wrote massive amounts of unit tests and wrote against those tests. While this is what real hardware developers do, I found it to be a huge waste of time when you're working by yourself on a small project.

I, and a few others, are very willing to help people learn (though I'm still really a noob). If you want to play around in this space, let me know and I'll try to help you with what you need.

Retrocomputing FPGA work is a fun diversion from normal software, enough that my brain was convinced they weren't related (had a bit of a mental block for software). Over the course of a year, I went from knowing basically nothing to releasing 3 different FPGA emulation cores of my own for multiple platforms, along with releasing something like 5 ports (which is not necessarily trivial, particularly for a beginner) of existing cores to the Analogue Pocket.

It has been a very fun experience, and I've found it to be extremely addicting. It helps that there's a fairly tight-knit community very interested in furthering the development of FPGA hardware preservation, so people are very willing to donate, test, and contribute feedback, which is a great feeling for open source work.

My limiting factor is _command_ throughput in my brain; coming up with the words I want and how to spell them massively slows me down. I really wish I could figure out how to go faster (~80 WPM) because I'm essentially limited by the speed my internal narrator dictates to me, which is close to realtime speaking speed. This is less of a problem while coding, but I still think it's quite relevant.