0%
0%
Tiny SCSI Emulator
Teensy 3.5 & NCR 5380 based SCSI device emulator.
Teensy 3.5 & NCR 5380 based SCSI device emulator.
NCR_53C94_53C95_53C96_Data_Sheet_Feb90.pdfNCR 53c94 DatasheetAdobe Portable Document Format - 2.86 MB - 12/26/2016 at 21:59 |
|
|
K64P144M120SF5RM.pdfKinetis MK64 Reference ManualAdobe Portable Document Format - 19.85 MB - 12/14/2016 at 22:32 |
|
|
SCSI Reference.pdfSCSI Command ReferenceAdobe Portable Document Format - 3.78 MB - 12/14/2016 at 22:32 |
|
|
NCR_5380_SCSI_Interface_Chip_Design_Manual_May85.pdfNCR 5380 DatasheetAdobe Portable Document Format - 2.99 MB - 12/14/2016 at 22:32 |
|
|
K64P144M120SF5.pdfKinetis MK64 DatasheetAdobe Portable Document Format - 1.51 MB - 12/14/2016 at 22:32 |
|
|
Due to lack of time, motivation, and costs associated with the 5380 and C94 chips, I'm taking a break from this project. I hope to start working on a new project Pocket SCSI Tool with many of the same goals, but using less expensive hardware that is in current production. I believe there is still room for the 5380 and C94 based TSE designs, but less ambitious as multi and single target disk emulators respectively. Writing new SCSI target drivers for linux is a better use of time and resources, as it makes the drivers portable to other SCSI bus types and devices in the future.
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.
More work on Ethernet support last night. The W5100 raw socket code is in place, and the Cabletron EA412 driver attempts to load on the Macintosh SE. Unfortunately the Cabletron driver crashes (hard) and prevents MacOS from booting further.
The command sequence thus far is:
Inquiry
Inquiry
Get MAC Address
Set Protocol
Set Multicast
<Crash>
Sometimes I don't even see the Set Protocol command.
My next steps will be to try it under NetBSD, and to install macsbug on the SE so I can try to see where the Cabletron driver is crashing.
Over Thanksgiving I was able to dedicate a couple of days to development and testing of firmware revisions and some hardware revisions to get basic disk commands, DMA, and partitioning working. Currently the disk emulation is maxing out the SCSI PHY with plenty of room for growth on the SDHC bus. Future hardware revisions will likely be based on later SCSI PHY controllers which should increase speeds to match the limits of the SDHC socket on the Teensy 3.5.
The current revision hardware manages 16MB/s between the microsd card and Teensy RAM, resulting in about 7MB/s data rate when copying between partitions on the card using the firmware console. FATfs in the firmware is much slower (used to backup and restore partition images) at around 600KB/s and likely to be an improvement goal further down the line.
DMA to/from the host results in upto 1.3MB/s with the current PHY.
Emulation of SCSI Ethernet adapters has been prototyped out in the current firmware, needing the attachment of a SPI interface ethernet controller without a TCP/IP stack. Optical drive emulation will be added in the future.
Hey, sorry I haven't seen your messages here as I don't have much time to dedicate to these projects anymore. the FB_CS* registers are detailed in the Reference Manual for the K64 mcu. Not sure how my SDK at the time had these registers defined, but it should be fairly simple to transcribe the info from the pdf (check the files section above) to recreate the needed info.
Page 743 is the start of the info you are seeking.
Hi.
First of all I wish to express my greatest respect for your work. It really really helps to understand scsi communication and data handling.
I am trying to replicate your project in order to replace the SD-Card with a 40-years old reel-to-reel magnetic tape drive. However.... I would like to ask you if this project ever worked.
TSE Laptop rev. 1 has a 2 x 20 pin connector, not the regular scsi-1 2 x 25 pin connector. Big trouble when using a standard 50-pin scsi1 cable.
Schematics are extremely hard to follow due to the lack of buses. Just renaming the pins is not helpful when trying to follow the logic at hardware level.
Regarding the software side - these references look like setup of some internal registers but there is absolutely nothing inside TeensyDuino libraries to confirm that.
Here is why:
drvNCR5380:146: error: 'FB_CSAR0' was not declared in this scope
drvNCR5380:147: error: 'FB_CSCR0' was not declared in this scope
drvNCR5380:147: error: 'FB_CSCR_BLS' was not declared in this scope
drvNCR5380:147: error: 'FB_CSCR_PS' was not declared in this scope
drvNCR5380:147: error: 'FB_CSCR_AA' was not declared in this scope
drvNCR5380:147: error: 'FB_CSCR_ASET' was not declared in this scope
drvNCR5380:147: error: 'FB_CSCR_WS' was not declared in this scope
drvNCR5380:148: error: 'FB_CSMR0' was not declared in this scope
drvNCR5380:148: error: 'FB_CSMR_BAM' was not declared in this scope
drvNCR5380:148: error: 'FB_CSMR_V' was not declared in this scope
drvNCR5380:149: error: 'FB_CSAR1' was not declared in this scope
drvNCR5380:150: error: 'FB_CSCR1' was not declared in this scope
drvNCR5380:151: error: 'FB_CSMR1' was not declared in this scope
drvNCR5380:152: error: 'FB_CSPMCR' was not declared in this scope
I want two, one for my SE30 and one for my Quadra 950 … where or when can I buy this? I love it!
Soon... Soon... I wouldn't want to take advantage of folks though, and this is far from stable. There are times it works better than the SCSI2SD, and times it works worse.
Has this project died? Looked like it had some potential.
The 53C9x avenue might be dead, since it can only handle one SCSI ID. I have had contact with a couple other folks who have worked on similar projects and there is a possibility of making this into a commercial product in the future. Realistically, using a beaglebone looks like a better option in the long run, if I can ever manage to set aside time to figure out the best way to implement the SCSI PHY in the PRUs.
Please don't abandon this project! Lots of people are interested, it has a lot of potential!
Very nice and interesting project. I was wondering if there's any reason for choosing that MCU. I'm thinking about a similar implementation based on a STM32F4. Any ideas?
Sorry for taking so long to get back to you, yes the STM32 series would work well for this, most of the firmware could be ported over to something like ChibiOS or something similar quite easily. Ideally, you would use the FSMC to interface with the 5380. There are a few examples for using the FSMC to interface with LCD screens, and the setup needed for that would be a good starting place for rewriting the Teensy/Kinetis specific code.
No problem, and thank you for your reply. Well, I had the FSMC in mind for interfacing with the SPC, however, the problem is getting the DREQ/DACK handshake work with the STM32. It could be done, but it's tricky. I believe the MCU you chose provides external DREQ/DACK signals, right?
Not exactly, at least not that I have used. There isn't very much gain from implementing DMA operations, aside from relieving some CPU cycles on the MCU. The 5380 tops out well below the FSMC interface speeds, so you're going to saturate the 5380 long before you run out of cycles on the STM32. I've gotten some very good speeds on the STM32F4 discovery board when interfacing to a 16bit LCD, and still had plenty of CPU time left for other tasks. Now if you can get the 53CF94 interfaced to an STM32F4, there is a chance you might be stuck waiting on the SD card handler. Myself and others would love to see an inexpensive SCSI emulator that could handle 20MB/s.
Would be ecstatic to purchase one or more of these if that is an option.
As far as I know Zilog are still making 5380 compatible SCSI IC's.
You will have to search on mouser Z53C8003VSG or similar
Really cool project. I am interested in building one for my SE/30. Is the OLED required for operation or is it optional? Thanks!
Great project, David! I used your schematic and board files and had the boards made @ PCBWay earlier this month. Looking forward to populating one and seeing if I can get it working on my SE/30! Thanks again!
GREAT Project ! Will follow and buy a board if it commes available
Do you plan on eventually eliminating the NCR 5380? It is a vintage part... and SCSI has been implemented in other devices without using anything similar to it (SCSI2SD doesn't use a hardware PHY).
It is entirely possible, and as far as the SCSI2SD, they implement their own PHY in a second AVR in the rev 5 board. i think the rev6 switched to a FPGA phy implementation. Currently I'm working on making the PHY driver a configurable option, so that you could use either the 53c80 or 53c9x, and eventually move on to better options including FPGA or eliminating the PHY (almost doable with just the Kinetis since every pin has pin change interrupts, and could still abuse the FlexBus interface to read/write the SCSI data bus. You work with whats easy, build up to whats hard.
There are tons of NOS SCSI chips available still in backchannels (ebay etc), in many different kinds.
Hi, do you think using a Teensy 3.6 instead of the 3.5 would cause headaches (i.e. timing problems maybe)?
The 3.6 doesn't have 5V tolerant pins, so depending on the SCSI chip you use, there likely could be problems. Both the 5380 and 53c94 are 5v parts.
Ah, good catch! I have some lvl shifters, but I guess getting a 3.5 would make it easier anyway. Any pointer as to how you've connected the 50pin header? Did you use a breakout?
For the breadboard I just used male to female jumper wires to connect the header pins to the corresponding chip pins.
Yes, there are eagle cad files linked in the hardware repo https://bitbucket.org/tinyscsi/hardware and depending on response I will probably make a large order for PCBs in the coming weeks as I finalize the designs, especially for the 53C94 version.
all im looking for is a compact scsi cdrom emulator that is not scsi2cd
scsi cdrom emulation is just barely starting. It is enough at this point that I have successfully booted a debian live cd from it on my Pentium III linux box. if you have the parts on hand, a breadboard is a good starting place. the eagle schematics should be enough to match up what pins need to be connected where.
Hi David. I commented on your thread in one of the Facebook groups about a 2.5" version for Powerbook drivebays, and IIRC you seemed interested. Just wondering if you ever got around to a layout for that? I think you mentioned it would have to be done without the OLED.
Either way, I'm interested in hearing when you get around to a batch run :)
@clae yes! I have been working on the laptop version in parallel with the new 53c94 based design, but haven't gotten boards made yet and need to find out some specifics for connector placement and mounting holes. There are some - preliminary, unverified, needs work, you get the idea - files in the hardware repo for two different laptop models. the 5380 based model has the firmware working reliably for hdd emulation, and needs some tweaks still for optical emulation. The 53c94 version needs much work still both hardware and software wise and will only be able to emulate one device at a time due to limits of the chip. A CPLD / FPGA phy will be in the works sometime in February, and I have been challenged to get Ultra-320 speeds within a few months (but without specifying the cost of doing so!)
Are you still interested in using existing faster SCSI ICs, or is it full steam ahead to CPLD/FPGA implementation?
im looking to make scsi plug with only 4-6 cdrom images . idea is to get rid of a scsi cdrom drive and have this plug with lcd on the back side . select image and forget it
Is this meant to be a generic SCSI emulator? By that I mean is it platform agnostic or is it targeted at a specific platform?
I ask because the 5380 emulation would likely make it functional for a lot of 16/32bit Motorola 68k era systems like the Amiga and Atari ST et al.
I'm pretty sure there would be significant interest from those communities as well as the classic 68k Mac crowd.
That is the general idea. The first project log notes that I have tested it with Macintosh SE, Adaptec 3940 (in a Pentium III), and the VaxStation 3100 M76's host controller.
LUN support has been tested successfully in Linux on the Pentium III.
Not only is it a generic SCSI harddisk emulator at this point, it should also be compatible with many SASI devices such as X68000 and various S100 bus systems with an appropriate controller.
That's great because I already ordered two SCSI chips in anticipation of this project ;')
Keep up the great work.
Since you seem to be emulating some of the more unusual SCSI stuff..... I'm just going to point out the Scuzzygraph Mac video adapter.. it would be neat to have a clone of it... I have the drivers somewhere I can dig them if if you are curious.
IT was based on a TMS34010... which is interesting in of itself. I gathered up as much info and links as I could awhile back about it.. https://68kmla.org/forums/index.php?/topic/20802-so-what-is-a-scuzzygraph-exactly/
That is one of my longterm goals. I have about 80% of the Cabletron Ethernet emulation written, including the lowlevel hooks that shuffle data back and forth to the W5100 I'm using. There is something making the driver unhappy, and I don't have macsbug installed to figure out where the issue is. For the Scussygraph, I'd have to get some documentation about it, and would probably need a much beefier controller (add a PiZero maybe?)
David Kuder
Stuart
Scott Hasse
eric
....and.... myth busted. replication is NOT working due to those undefined registers. Hardware assembled on perforated test board, awaiting feedback on the aspect below, timeout encountered. Those variables are not defined anywhere in the entire teensyduino, even if they are specified inside the chip manual you attached to this project. It seems your project sparked some kind of a revolution inside the kinetis.h because it is stripped down of all references. Please advise.