On Nov 14, 2013, at 8:12 AM, Ethan Dicks wrote: > >> a second solution could be to replace the EPROM by one with my own >> content; not having to use this weird SASI protocol, it would >> simplify the interfacing. > > I think it might be possible to tweak the ROM code to properly > support SCSI command packets, but it would probably take a > lot more tweaking to support partial sector writes to a drive that > was formatted to 512 bytes per sector. The DOS 3.0 filesystem > maxes out around 16MB anyway (if you were to rewrite the code > that expects a ~300-cylinder drive with 32 sectors per track and > either 4 or 6 heads) so there's no real loss in giving up half of > each sector. Even my smallest embedded SCSI drive is 50MB, > so I couldn't address every block. > > I see two approaches to the same destination - put a SCSI bus > analyzer on a working drive and watch the transactions for > format, reads, and writes, and disassemble the DOS Board > ROMs and look for every command packet that the board > sends to the SASI-MFM board. It's probably only about half > a dozen kinds. Once we know what the SASI commands > are, that's a long way to sticking a replacement on the bus. Early SCSI is extremely simple. You don't have complex commands like READ DEFECT DATA or the like. With an Atmel with USB support, you could easily emulate the SASI interface on one side and talk to a USB flash drive on the other. You could do this either at the filesystem level (generate FAT commands to write to a storage file) or the raw level (using only 20 MB out of a 4 GB drive, hehe) via command translation. The former would pretty much be sd2iec but for SASI. -Nate Message was sent through the cbm-hackers mailing listReceived on 2013-11-15 02:00:04
Archive generated by hypermail 2.2.0.