[An FPGA Drives This Antique LCD Screen
Facunda Ganesh
ATAPI is more demanding for a microcontroller than SCSI ? Because there are people that made a SCSI emulator just with a stm32
=81tLrZeMP8U
(Which I think can also emulate a SCSI CD-ROM drive)
Just a reminder that SCSI was introduced in '86 and predates ATA. Also, what SCSI level, surely not the Ultra modes?
If you keep to SCSI-1, or subset of SCSI-2, then I'd argue it is easier. Reason being each transaction is always ack'ed so if you can't keep up it will simply slow down the transfer, but not break it. ATA modes, on the other hand, are timed on both ends and if you do not present data in that window, you just completly glitched it.
So, in other words, PIO 0 mode might seem slower than SCSI-1 on paper but you have to be able to present the data in 600ns (less than that actually to account for various line delay issues). Miss it just once on any occasion and that's it. In SCSI you just take more time to ACK and this causes a single clock strech, you can easily make it up with the rest of the stream and end up with higher transfer rate overall. Downside of SCSI is more signals and addressing, and several other bus modes but these are optional so the software side is more complicated but not that much.
I have to wonder if a simple board that has a 40pin connector for IDE, molex power connector, analog and digital internal audio headers, and 1/8 jack that ends up being a Pi hat or allow connecting to an ESP32 module would be enough? Both a Pi and ESP32 can run with 5V so the earlier comment about some chips being 3.3V nowadays goes away. It could even have headers to support a cheap small screen and buttons you attach to a 5 1/4 bay insert.
One of the nice things about ESP32 is its speed - its fast and capable enough to not only play CD audio off of raw CD image, but it could also decode audio from mp3/ogg files on the fly = much smaller disk images.
AFAIK the ESP32 is sort of virtual machine, that is the user code is running under RTOS kernel layer that has priority, so interrupt latency sucks. It might be so bad that even reliable PIO 0 is not possible.
Take another look. I think you missed an FGPA - with all the logic in it. So no, not just a couple of '245 buffers.
Also, what can this do, exactly? Somehow I doubt it properly emulates ATA commands to switch the PIO modes, rather it has one or two baked-in timings and hopes the host will not attempt anything faster. Will this work? Sure. With every retro PC? With 60cm long cable and another ATA device already connected to it? I have my doubts.
Frankly I do not know exactly how these work, but chances are it's a layer above the direct laser stream. I mean, the console itself would need a fast ADC and logic to process such data to tell if it's legit or not, why do that if you can have an ASIC return it in already digitized and somewhat processed way, like what Saturn does. But even if that was a laser stream - it's for a console, and not even every mobo is supported. You can take some shorcuts if you know the system well, the emulation doesn't need to be perfect, or even correct as such. It only needs to fool the mobo, by whatever means it takes, to accept the "CD-ROM" as valid. Maybe they found a simple glitch that somehow works.
Any attempt to go for these seems to need extra chips or an FPGA. I've seen for example, SCSI2SD v6 prototypes had an Lattice FPGA. Production models have what it looks like an ASIC (that Silicon Blue chip) coupled with an STM32 CPU, thus is magnitude more expensive than simpler asynchronous/no ultra speed v5's.
So he uses the 2 chip CPLD+CPU approach... Using an STM32 is natural, as you don't need computation horsepower for this task, as I've been saying... Well, at least if you don't emulate DPM copy protections with MDF image dumps. And I suppose there should be beefier STM32s for the last one. Still, remains to know how "cheap" his approach is. Dunno is cheaper than SCSI2SD v6 which also uses an STM32 + CPLD/ASIC which does the physical layer hardwork.. But who knows...
afaik it doesnt work like that. you dont switch device speeds, you read device capabilities returned by Identify command "Word 51: PIO Data Transfer Cycle Timing Mode." and set your controlled to an appropriate PIO mode
???
There is no ADC, data on the disk is already digital. CD ASICs work in a similar manner to floppy controllers - there is some kind of RF amp, then PLL and comparator - all of this is used to recover original clock and clean up the data flow. Then you have EFM decoder, descrambling, reformatting, CRC error checks etc.
Saturn. Saturn is a great example of design by a committee (or a few). Its a hodge podge of everything, so many chips, busses, processors. I think I tried counting all of the separate busses at some point and ended up at 144bits or something crazy like that ?. No DFM, no integration. In Saturn it looks like HD49232 handles this preliminary decoding +4 other chips to arrive at actual data. Looking at schematics you inject data into YGR019A 124-131 pins, + obviously monitor laser head position.
In early PSX you have small RF amplifier + big Sony ASIC consuming RFAC and doing everything from clock recovery, thru decoding cdrom data to sound DSP.
You can take some shorcuts if you know the system well, the emulation doesn't need to be perfect, or even correct as such. It only needs to fool the mobo, by whatever means it takes, to accept the "CD-ROM" as valid. Maybe they found a simple glitch that somehow works.
Depends who you ask I guess. I'd argue I have a few happy customers, I take you aren't one. FYI you can hack together an IDE interface with a decent AVR, you don't need ESP32 cores for that. It's not fast and doesn't really handle any kind of errors but it works - most of the time. Is it good enough for an actual, stable ODE? Nope.
If I sound overly pessimistic it's because I don't want anyone to underestimate such project, including the non-technical side of things. Point is though, I now see it's personal. I did mention this subject can get toxic and I know where this argument is heading. Fine, I'll just leave it in your capable hands, I'm done here.
2) Regarding PC support in particular, old school IDE/ATA is a super pain on PCs - they're where it came from so it turns out to be way less "correct" than the ATA/ATAPI specification documents you can find online would have you believe. Some Super I/O chip datasheets even happily admit to timing specs completely incompatible with the claimed ATA ones, so it's basically just an exercise in reverse engineering, but there's a million variations out there from a million old PCs. Either way at this point I have it working on all the 386s and 486s in my possession, with various Super I/Os (both ISA and VLB). Some users still report some sort of edge-case timing issue on some hardware I can't replicate based on reports on my issue tracker, so I'm still just ordering weird looking Super I/Os from eBay when I spot them and testing them out. Support for non PCs (and PCs with a Southbridge, where the IDE port is just pure I/O) has been a lot simpler, even weird Roland synths were pretty well behaved as their IDE ports are not really just ISA.
3) I did also have the notion of attempting to do a cost reduction step, possibly by switching to a combi FPGA/MCU chip, and larger (maybe almost 5.25") to get single sided for cheaper assembly instead of having the FPGA on the back as well as maybe also squeeze SPDIF output some people requested on, but the chip shortage has postponed me from getting prototypes (all the good chips are just "52 week lead time" just now, at least at US companies). The original version was small as it was meant to plug straight into the IDE socket on a Konami System 573, after all.
3) I did also have the notion of attempting to do a cost reduction step, possibly by switching to a combi FPGA/MCU chip, and larger (maybe almost 5.25") to get single sided for cheaper assembly instead of having the FPGA on the back as well as maybe also squeeze SPDIF output some people requested on,
If you're willing to go bigger will you also consider a laptop cdrom version? allthough that would be pretty annoying given all the different connectors manufacturers used to connect the cd/dvdrom drives to the laptops. ?
but the chip shortage has postponed me from getting prototypes (all the good chips are just "52 week lead time" just now, at least at US companies). The original version was small as it was meant to plug straight into the IDE socket on a Konami System 573, after all.
Interesting idea - I'll see what I can do. I suspect (as the IDE cards just connect some signals from the ISA bus fairly directly onto the IDE bus) that'd be best as motherboard + card combinations, I'll just need to figure out what the motherboards are (they don't seem to be well labelled, especially the little low profile 386s)
795a8134c1