Very interesting. I wonder if this would be easier to use than SCSI2SD[0].
SCSI2SD reportedly works well with older SCSI computers (old Macs in particular), but it requires very careful formatting/setup of the SD card you're using.
Yes. I'm using one with a Kurzweil K2600 synthesizer. Really, for most devices the only reason it requires care when setting up is because the usability of the config software is poor, and the documentation is worse. For a simple case (like just turning the whole of a 4GB SD card into a single virtual disk it's pretty straightforward, once you understand what the config utility is expecting you to do.
The docs say that the hardware supports both initiator (host) and target (disk/peripheral) modes, which could open up some older hardware devices as well.
I wish, there was an english version, because this looks very interesting.
One curious thing I gleaned from the schema is that the scsi-bus can also be used to tunnel ethernet and remote file-systems, and not only block devices.
We've changed the URL from http://retropc.net/gimons/rascsi/index.html to the article that that one quotes from. It has an annoying autoplaying video though, sorry. If anyone can find a better article in English, we can change it again.
Will be fine and still show increase upon the era they are emulating.
A USB based solution may of proved more portable and sellable though IMHO. Though that market catered with many SDcard SCSI HD emulation dedicated adapters.
I believe they are stretching the envelope a bit. ~10-20MHz is probably the reliable top end for the RPi GPIOs, and even early SCSI standards well exceed that at 5MB/sec. That's taking the rather naive assumption that 20MHz is 20 mega bits (not bytes)/sec. Various encoding ideas could make that better, or worse.
This is a cool dancing bear and all, but I would stick with the microcontroller implementations for real needs. This is cool to experiment with.
SCSI2SDV6 is supposedly capable of 10MB/sec. There's also a guy that designed something with a very capable teensy and a real NCR 5380 SCSI controller. https://www.pjrc.com/tiny-scsi-emulator/
Edit: The Teensy is pretty impressive in this general area. Teensy 4.0 is a features an ARM Cortex-M7 processor at 600Mhz, 1024K RAM, with lots of community support, and it costs $20. You can imagine it blurs the lines a bit on "microcontroller". Bitbanging GPIOs, in bare metal mode, on it will likely work a lot better than an Rpi/Linux. https://www.pjrc.com/store/teensy40.html
It looks like the Raspberry Pi is generally accepted to be capable of ~14MHz reliably in a true GPIO mode, so at least on paper it should be able to handle SCSI-1 and SCSI-2 "Fast SCSI" speeds. It's not clear to me which variant this project supports.
The Pi has enough GPIO pins to support the 16 bit SCSI-2 "Fast Wide SCSI" variant but the schematics here are just for 8 bit "narrow" SCSI.
There are also certain pins on the Pi with specific hardware I/O capabilities that can transfer data faster which can be bodged in to working for a lot of things they aren't intended for, see also the RGB LED control setups and such, but I don't think those will be relevant to this use case.
Because GPIO for communication protocols is what is termed "bit banging", normally for high speed communication stuff you have a dedicated ASIC that handles all the low level signaling itself and presents a high level (possibly DMA) interface to the CPU.
With bit banging/gpio you are using the CPU itself to write/read the raw binary signal of the GPIO, usually with no buffering. This involves tight loops and polling and is slow because the CPU must marshal and construct all signaling (including timing!) in a synchronous way, bit by bit, rather than just dumping a block of data into memory somewhere and having a high level ASIC deal with it (or reading said block).
A good analogy might be writing your friend a long note and then having him read (The high level interface) it vs phoning your friend and sharing the note, one letter at a time.(the low level bit banging interface), which do you suppose would be faster, and less demanding of your attention?
On top of all that, remember that this project is doing that reliably enough to use as a disk while sharing CPU time with the rest of the system. It's not running on a RTOS or doing bare metal trickery, so achieving tight timing is really hard and you end up wasting a lot of CPU time just doing that.
Is it just me or does the article just link to broken yahoo pages? I can't find a proper link to the project but the article contains nonsense irrelevant embedded videos about cloud-versus-onpremise hosting? Is this spam? Flagged.
This reminds me of this video of a "reverse-emulated" NES using a raspberry-pi: https://www.youtube.com/watch?v=ar9WRwCiSr0 (you can skip to 3:35 if you're not interested in the jokes).
I was looking for something similar but with IDE or SD card. Does anyone have some resources on this?
My use case is mostly for continuous testing. Say, another single-board computer, but with the SD card driven with something like an USB gadget. Same for the IDE bus, but for older devices (targeting emulators).
Thank you, that's more or less what I was looking for.
I had probably come across it during my earlier attempts at finding a suitable project, but the need for an FPGA likely turned me a bit down. I might re-evaluate that if I really need it.
I also bought a SD Card -> IDE adapter some time ago. SD cards can communicate via SPI, so it should be feasible to directly hook up a raspberry pi (after writing a host SD card protocol layer), unless I am missing something? More recent Pi version should be able to drive the SPI link at more than 25 MHz, I hear.
I visited the project page at http://retropc.net/gimons/rascsi/index.html , which is mostly OK to read through Google Translate, and then stumbled upon a truly aesthetically wonderful piece of software - one of the Sharp X68000 demo pictures [0] is running MMDSP [1] [2]. It also turns out there's a PC clone of this application called MDXWin, which I was able to download only through a somewhat bizarre series of steps.
28 comments
[ 5.3 ms ] story [ 71.2 ms ] threadOld Macintosh and Amiga enthusiasts should get a kick out of this as well.
SCSI2SD reportedly works well with older SCSI computers (old Macs in particular), but it requires very careful formatting/setup of the SD card you're using.
[0] http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD
Also worth looking at the alternative solutions as many USB adapters as well as dedicated SCSI<>SDcard had adapters about in the wild.
A USB based solution may of proved more portable and sellable though IMHO. Though that market catered with many SDcard SCSI HD emulation dedicated adapters.
This is a cool dancing bear and all, but I would stick with the microcontroller implementations for real needs. This is cool to experiment with.
SCSI2SDV6 is supposedly capable of 10MB/sec. There's also a guy that designed something with a very capable teensy and a real NCR 5380 SCSI controller. https://www.pjrc.com/tiny-scsi-emulator/
Edit: The Teensy is pretty impressive in this general area. Teensy 4.0 is a features an ARM Cortex-M7 processor at 600Mhz, 1024K RAM, with lots of community support, and it costs $20. You can imagine it blurs the lines a bit on "microcontroller". Bitbanging GPIOs, in bare metal mode, on it will likely work a lot better than an Rpi/Linux. https://www.pjrc.com/store/teensy40.html
The Pi has enough GPIO pins to support the 16 bit SCSI-2 "Fast Wide SCSI" variant but the schematics here are just for 8 bit "narrow" SCSI.
There are also certain pins on the Pi with specific hardware I/O capabilities that can transfer data faster which can be bodged in to working for a lot of things they aren't intended for, see also the RGB LED control setups and such, but I don't think those will be relevant to this use case.
With bit banging/gpio you are using the CPU itself to write/read the raw binary signal of the GPIO, usually with no buffering. This involves tight loops and polling and is slow because the CPU must marshal and construct all signaling (including timing!) in a synchronous way, bit by bit, rather than just dumping a block of data into memory somewhere and having a high level ASIC deal with it (or reading said block).
A good analogy might be writing your friend a long note and then having him read (The high level interface) it vs phoning your friend and sharing the note, one letter at a time.(the low level bit banging interface), which do you suppose would be faster, and less demanding of your attention?
The author further explains how he did it in this "making of" video: https://www.youtube.com/watch?v=hTlNVUmBA28
My use case is mostly for continuous testing. Say, another single-board computer, but with the SD card driven with something like an USB gadget. Same for the IDE bus, but for older devices (targeting emulators).
I had probably come across it during my earlier attempts at finding a suitable project, but the need for an FPGA likely turned me a bit down. I might re-evaluate that if I really need it.
I also bought a SD Card -> IDE adapter some time ago. SD cards can communicate via SPI, so it should be feasible to directly hook up a raspberry pi (after writing a host SD card protocol layer), unless I am missing something? More recent Pi version should be able to drive the SPI link at more than 25 MHz, I hear.
0: http://retropc.net/gimons/rascsi/rasdrv.png 1: https://github.com/gaolay/MMDSP 2: https://www.youtube.com/watch?v=gVdJj9juRnQ
It offers SCSI disks, CD, Ethernet(tap device on rpi side) and a way to share a Linux directory with the X68k.
Performance is well over what an early nineties computer could require.
First thing I fired up was MMDSP and listened to some awesome tunes available.
geocities, oh Japan :) this link is dead :(