I had a Cyrix 6x86 when Quake first came out. My disappointment at how poorly Quake ran on it was significant, especially because pretty much every other game at the time ran well on the Cyrix. The FPU performance in Quake was doubly handicapped on the Cyrix: not only was its FPU slower than the Pentium's to begin with, Quake's code was indeed hand-optimized for the Pentium's FPU pipeline. Fabien Sanglard's writeup of Michael Abrash's optimizations for Quake goes into great detail: https://fabiensanglard.net/quake_asm_optimizations/
Cyrix was physically incapable of pipelining FPU instructions. Without Pentium Quake would have had to wait two more years for commodification of CPUs delivering similar floating point performance.
Quake needed March 1994 Pentium 90-100 to deliver ~smooth 25fps. Cyrix released similarly performing 6x86MX PR200 in May 1997, AMD K5-PR166 January 1997. Quake was unfeasible till ~1998 at the earliest to be able to sell playable game.
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.
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.
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.
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.
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.
reply