Tiny SCSI Emulator

As I have had some time to further the project, I've done a redesign of the board (see the pictures section on the left) with room for two Teensy microcontrollers, and a header for a Pimoroni Pirate Audio (or other Raspberry Pi compatible I2S audio hats with optional screens) or a Raspberry Pi and whatever hats you want to use (forgoing the need for the second Teensy).  Additionally there is a 20x30 prototyping area, and mounting holes that match up with 3.5" bottom screw positions for mounting (or you can use right-angle hardware.)

The previous OLED menu system is being brought out to a separate microcontroller to allow for some more advanced features.

Once the design has been validated, I'll upload the new design to the project files.

For $50 you should be able to build your own basic board with just the NCR5380, backend Teensy 3.5, and minimal passives / connectors.

For around $100 you can fully populate the board with two Teensy microcontrollers, and a front panel LCD / Audio module.

HDD sound simulator:

The frontend Teensy can generate simulated harddrive sounds (and eventually CD & tape mechanical sounds too!) in realtime, for those who miss such things.  There is a sample recording in the Files section.

CDDA emulation:

You can have the frontend Teensy play back wav files from it's own SD card, though I might implement a pass-thru for the backend to send audio that is embedded in a bin/cue image.  With a Teensy 3.5, this uses 16-24% of the CPU time on the frontend controller.  The frontend Teensy can be a 3.5, 3.6 or 4.1.  The 4.1 should be powerful enough to decode MP3 files in realtime, and can do S/PDIF audio (passthru to your sound card!)  The backend however still needs to be a Teensy 3.5 to work safely with the NCR 5380.

240x240 UI:

Using the Pirate Audio hat, the screen can be much larger than the previous 64x32 or 128x32 OLED displays, and in 16-bit color too.  There are multiple versions of the Pirate Audio hat, one with a line-out, and another with a small speaker.  The UI on the front will let you mount/unmount images, change IDs and modes, control CDDA playback, etc.  Some basic UI elements are implemented already to allow changing the volume of the CDDA and HDD sound simulation.  I'll be uploading a video of the updated UI soon.

So I had some time to play with one of the TSE boards I had built up, and use it with an HP 712/100 PA-RISC system this past week.  In doing so I found several bugs, and have made some changes to the project in response.  Some of the changes that have been asked for relate to the missing flexbus defines in recent versions of the teensyduino SDK.  The firmware repo now has a flexbus.h uploaded with those missing defines.  When I get a chance to merge some of the changes between the various trees I have locally, I'll update the repo with the bugs I found last week fixed.

In the handling of SCSI messages, ABORT (6) wasn't handled correctly.  Apparently the correct response is to drop everything and release the bus with no messages back to the initiator.  And then there were bugs in the handling of reads & writes and conversion between different sector sizes.  On classic mac these were not as easy to see, but on PA-RISC it was obvious that too much data was being transferred for the read requests.

As far as multi-target support, it has been made even more obvious to me that selecting one target immediately after deselecting another target when both are handled by the TSE is problematic. This is most evident when a host is scanning for drives at boot and it only finds the first one.  I'm not sure yet what I can do there, but if you experience this, try leaving gaps of 1 or 2 IDs between your targets handled by the TSE.

I had planned on a 53c94 port, but as I found previously, that would only support one target ID per chip, and finding examples of target firmware for the 53c94 has been difficult.  I do have a board that uses the 53c94 in a target role with a Z80 cpu, which I can run an emulator in circuit or a logic probe and dump all the I/O targeting the 53c94.

So even though this project has been quite dead for the past couple years, I haven't given up on it yet.

The new boards and chips have arrived, and over 200 solder joints later, the Teensy and 53c94 are talking, and menu buttons are working. Now to finish separating the 5380 code from the target service code the rest of the way, and write the 53c94 driver. There is one downside to the 53c94 that I didn't notice before, it only can listen on one device ID at a time. It can still do multiple LUNs per device, but this means most of the modes are mutually exclusive for older software where LUNs are not supported. So you could emulate a harddisk, cdrom, ethernet, or graphics adapter, but not any of them at the same time on a m68k mac. The 5380 is slower, but more versatile on this one point.

On another note, the SuperMac SuperView arrived, and I was able to get it working with the Quadra 630 in my collection (albeit very poorly, as it causes issues with the native graphics). I hope to reverse engineer that protocol soon and start work on the pi Zero software.

The start of the OLED Menu system is underway, you will be able to enable/disable individual devices, change device types (disk, cdrom, tape, ethernet, graphics), start/stop the target mode, eventually perform initiator mode tasks (save/restore disk images from/to real drives) and make various other changes to the device config without needing a computer attached.

I've adjusted the layout of the previous status screen to only take the top 8 pixels, and hopefully be a clearer representation of what is going on. Here you can see IDs 3,4,5 are enabled, and I've just disabled ID 2 from the menu system. There is no activity on any of the devices, as shown in the top row of dots. Detailed status such as SD Card size and partitions will be available via the menus.

I spent the day plotting out the schematic and board layout for the 53C94 based iteration. TSE94Desktop.sch and TSE94Desktop.brd can now be found in the hardware repo to the left.

Boards and parts are now on order and should be in the middle of January. Until then, work will progress on the 5380 based model.

That didn't take very long. Many thanks to MAMEDev, SCSI2SD, and the SCSI CD docs, optical drive emulation is working well enough to mount & verify a Debian install disc on my linux testbed.

This means that virtual disks/discs with sector sizes other than 512 bytes are supported now as well.

I also have a SuperMac SuperView SCSI graphics card on order, which I hope will arrive before things get crazy again at work.

I have assembled one of the first run of boards and it works beautifully, even with my terrible soldering job. I have found an mistake that prevents the OLED display from being mounted on the Teensy side of the board, as the uSD slot overlaps the pins. I suspect anyone who would be using the OLED display would probably have it on cable or would be fine with mounting it over the NCR 5380, so it isn't a huge deal yet.

Many thanks to Hackaday for the writeup: http://hackaday.com/2016/12/25/the-tiny-scsi-emulator/ !

Merry Christmas, Festivus, Yule, Chanukah, Holidays and a New Year!

Rev0 Boards arrived from OSHPark, now I have to dig up some 48 pin sockets from my collection to fit the Teensy 3.5

Just pushed a major change set to bitbucket, adding the initial SCSI/Link emulation and central configuration through config.h

I spent the day rethinking the architecture of TSE, and plotting out the eventual move to support other controllers and device emulations.

Still having issues with the Cabletron emulation, but it is being joined by DaynaPort SCSI/Link which hopefully is a little better documented.

I've split the ethernet controller driver out from the ethernet emulations so it will be possible to mix & match in the near future. Particle Photon / Spark Core have potential as WiFi bridges handling all the network duties and leaving the SCSI to the Teensy. RNDIS over USB is another option to explore.

Initiator implementation has been pushed up the stack a tiny bit, in case I end up implementing RFC 2143, which necessitates being both a target and an initiator, supporting full bus arbitration, and exciting things that direction. Outside of Linux hosts with a specific chipset and driver, I don't know of any other implementations of the standard. I still plan on TSE being usable as a standalone SCSI cloning box.

ScuzzyGraph & PowerView are on the radar for future implementation if I can get any sort of documentation or can reverse engineer one (donors?).

Transport mechanisms are another avenue to explore. Are there any tape / cd vaults that are documented well? It would be interesting to have an entire catalog of ISO images to choose from, and mount them from a native application. Even better if I don't have to write the front end.

I'm still waiting on my first batch of boards from OSHPark, so all testing has continued on the breadboards for now. I've dug out a sacrificial VaxStation motherboard (corroded by leaking caps, rodent contaminants) to steal a pair of 5380 chips from, and have one SCSI floppy controller to steal another from if needed.

With my Quadra 630 attached, (needed to run NetBSD) I have gotten much further with the ethernet support. The Cabletron diagnostics now recognize the device. Likely just due to the incomplete Mode Sense implementation, NetBSD and its related tools don't like my disk emulation. And on the unforeseen complications, I now have to put some form of mutex / locking on the ethernet and oled drivers, which pushes me closer to switching to an RTOS and changing how I handle the SCSI PHY.

UPDATE: I just suck at installing crusty drivers. The Cabletron MacOS driver isn't an extension like you would expect, instead it patches the System file with the actual driver, and has some sort of patched Ethertalk extension. I'm further along than before, but without having the original hardware to compare against, I'm just blindly implementing their protocols by reading the NetBSD driver source code. The driver goes through the process of adding a protocol and a multicast address to the frame filter, and asking for any available frames. If the stats DA is installed, it attempts to poll as well. I suspect the card returns some sort of "No data, ask later" response when there are no frames to retrieve, but can't find any reference in the NetBSD driver.