Hacker Newsnew | past | comments | ask | show | jobs | submit | polpo's commentslogin

The repo will be made public when the hardware is launched. Should be a few weeks.


A stamped steel plate is not possible at my planned price point. But one thing I will note is that this 3D printed front panel is only a prototype.


On the contrary, I think you’ve done a fantastic job with the enclosure. Far from looking “half melted”, you’ve made good use of the bed texture, and the design is top notch.


as an aside to anyone else reading this, laser cut and bent sheet metal has gotten pretty cheap and easy, I think you could have an okay (unpainted) tray/case like this made for maybe $5 to $10 at 100 units


BTW I'm pretty well versed in getting laser cut and bent sheet metal made, both in China and via US-based providers like SendCutSend - my PicoIDE project uses a metal bracket. In fact when so many other projects were using 3D printed brackets, I decided that was not good enough and dove in and did the work to get nice brackets made affordably. It really elevates the project to a higher level of professionalism.

That being said, $5-$10 sounds about right (if maybe a little on the high side) for something the size of PicoIDE, but unfortunately that is too much for the price point I want to hit. Affordability is a major target for PicoIDE. And also, WiFi is a feature of the front panel and for that reason, metal is a no-go. The WiFi antenna is at the front of the device to give it the best chance of decent reception, so it needs to be plastic.


totally reasonable, the cost tradeoffs on these types of products seems very challenging


Where, out of interest?


Currently, it implements the ATAPI READ SUB-CHANNEL command and fully supports the current position data format code. Other format codes like ISRC and UPC currently return dummy data, but wiring that up would be pretty straightforward. Supporting image formats like CloneCD's .ccd/.img/.sub that store arbitrary subchannel data also seems doable, but would definitely be more work.


have you tried this on a pci-e ide adapter yet?

i want one of these for my old 486

but also just went “gee it would be nice to just scroll a menu and select different usb LiveCDs for a lab box” and not constantly switching or losing usb dongles for them

ive done boot loader menus and sooner or later one OS clobbers or screws up the others. so im into the idea of segregating them and using your device to select imgs.

yeah its something i could solve with a PXE environment but then i have external dependencies that change over the years as im moving around and getting different internet providers, home equipment , or using different solutions for dhcp and routing etc. this would work well on an airgapped system even if its been collecting dust on a shelf for a few years


The annoying part of .ccd files is the lack of support in the specifications for DPM data. It was officially used just for some old Karaoke machines and VDJing mixers, but more importantly for retrogaming aficionados, it was used by SecuROM and Starforce copy protections.

Can't think of an open format with support for that, IIRC not even CHD files store them.


MDF/MDS isn't open, but could possibly be reverse-engineered enough to read the DPMS data.


CDEMU/libmirage support both CCD et al and MDF/MDS images. Mixed modes, etc - the whole shebang. How good the copyright protection emulation is I cannot say tho.


I could be utterly wrong on this, but AFAIK the "emulation" in tools like Daemon Tools or Alcohol was only required when the disc image was created with partial or missing DPMS/subchannel data; If the virtual drive provides transparently the required stream the copy protection should be none the wiser on the actual drive emulation.


I'm by no means an expert on Starforce and friends, I'm just bringing attention to a nifty tool many I suspect aren't aware of. Also to highlight that CDEMU should support all these subchannel and stuff in CCD and others - maybe you right and this itself should make the protection algo happy, provided the image file is correct and comprehensive. It's just that I vaguely remember Cdemu had some specific protection options, but I might be wrong here.


Fun seeing this posted - I'm the creator of the project. While it's meant to be a generic IDE/ATAPI emulator the two main use cases I envisioned for the project are in the area of retro computing: CD-ROM under MS-DOS and Windows 9x, where software-only virtual drive emulation options are lacking or nonexistent, and IDE hard drive emulation on early IDE machines where the drive geometries are fixed.

Since the project has been announced, lots of people have come out of the woodwork with other fun potential use cases, such as CD-ROM replacement in arcade cabinets and the Dreamcast, and hard drive replacement in multitrack recorders and samplers.


How does the PicoIDE compare with the ZuluIDE? Are they direct competitors or are there different use cases?

I've been on the fence about getting a ZuluIDE for a while because of the price and because I don't exactly need one... I'll wait and see how the PicoIDE is priced.


The price will definitely be lower, and another difference is that PicoIDE will be entirely open firmware and hardware, while ZuluIDE is not.


Good to hear. Thanks for replying.


ZuluIDE uses FPGA, PicoIDE is beautiful $1 rp2350 + buffers.

rp2040/rp2350 are the best things that raspberry pi ever released. From bitbanging HDMI to 400Msps logic analyzers https://github.com/gusmanb/logicanalyzer?tab=readme-ov-file#...


You moved up to IDE while Im playing with RLL and investigating EDSI and SMD :) https://github.com/raszpl/sigrok-disk

You know, with couple differential transceivers on a daughterboard you could support everything this https://www.drem.info does :)


<inconsequential webpage bug report> First few images link to the full size version of the _next one_ </inconsequential webpage bug report>


Thanks. Fixed!


Outside of the US, they have symbols: ⇥ intead of "tab", ⇪ instead of "caps lock", ⏎ instead of "return", etc.


Did you actually read the article? Doesn't seem like it, the author says he literally talked to Peri in it.


I switched to Aisler who are in Germany. They're certainly more expensive than China but still way less than quick turn options in the US. There will still be tariffs but they won't be nearly as high. There are also smaller PCB vendors in China other than the "big two" of JLCPCB and PCBWay that are willing to be a bit more flexible and not charge the max possible duty upfront via DDP incoterms.


As a maker of open source hardware, I and others in the US selling my projects stocked up before the de minimis threshold was eliminated on May 2. We're not increasing our prices until those stocks run out and we have to reorder - we don't want to screw the community over.


>We're not increasing our prices until those stocks run out and we have to reorder - we don't want to screw the community over.

That's a nice thing to do, but it might be more sustainable to increase the cost some now, so that you don't have to increase it as much to cover the tariffs in the future.


But once you run out, will you screw the community over or eat the costs?


That's a very uncharitable way to put things. Since my original posts it looks like things have cooled and the worst of the tariffs have been walked back, but at the sky-high tariff rates from before today, my options would have been:

- Raise prices to account for tariffs.

- Not raise prices, therefore not make any profit, therefore not make it worth my time, therefore not make any hardware at all.

I'm not operating at big margins but I do make a profit because I want to balance supporting the community and keeping things at a sustainable level for my sanity. Those tariffs would have wiped those margins out completely.


That's what I always assumed it was, too.


I use this to remember what it does and also like thinking of XOR as an operation you can apply with a mask to flip bits (the linked article mentions this).


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: