HELLO! welcome to scottdisk.device, originally written by scott turner as a homebrew SCSI driver. i (scott drysdale) have changed it to drive an ibm pc through the parallel port, such that the pc's hard drive may be used by amigados. HISTORY i have included all of Scott Turner's warnings/disclaimers/threats, for what it's worth. i have none to add other than don't use my code for commercial purposes without letting me at least know about it. i'd be interested (or maybe amused?). if Scott or anyone else wants to get in touch with me (i tried, Scott, honest i did - the net doesn't seem to know you anymore!), here i am: Scott Drysdale 100 East 6th St, Apt 3 Frederick, MD 21701 (301) 694-4915 usenet: ziggy!scotty i should be there at least another 4 months 8-). here's scott turner's original "what you can do with this" blurb. **************************************************************************** Scott Turner L5 Computing 12311 Maplewood Avenue Edmonds, WA. 98020-1115 USA I may also be reached via: JST on GEnie scotty@l5comp.UUCP or stride!l5comp!scotty I am NOT releasing this source code into the public domain. However, I here by grant a license for distribution via AmigaDOS format 3.5" diskette or via an online telecommunications medium provided that the party charges less than the following to do so: USA $10 for a copy on an AmigaDOS 3.5" disk. USA $10 an hour for 1200 baud connection at 18:00 PST from Seattle, WA USA. You may not use this source code to make object code if you intend to charge anything above the above limits for the object code alone. ie you may not sell the object code for more than the above stated limits for the source. I also hereby grant a license for converting this source code for the following purposes: 1. To change the hard disk drive parameters. 2. To work with other SCSI buss interface cards. 3. To work with other SCSI buss devices. 4. Re-tune time delays. HOWEVER, under this license you may NOT: 1. Remove my copyright. 2. Modify or make additions to this license. 3. Change the name of the device from 'scottdisk.device'. 4. Change the limitation on charges for object code. (If you wonder if I'm egotistical, please note that 'scott' is the same length as 'track'. This is handy for patching disk editors to use this device driver rather than trackdisk.device.) I reserve all other rights. This source code is made available "AS IS" and I make no warranties for it's fitness for any purpose. *************************************************************************** ----------------------------------------------------------------------------- WHAT IS THIS? it's the amazing amiga to ibm pc sleazy hard disk hack! using the software provided and your amiga and an ibm pc and the cable you construct yourself, you can get a pretty slow (but real cheap, if you have a pc with a hard drive sitting around) hard disk for your amiga. the amiga software is in the form of your basic trackdisk.device emulator (named scottdisk.device as requested by the original author). the ibm software is in the form of a little ms-dos application in assembler which deals with the amiga's demands. the amiga end runs by simply MOUNTing the thing using one of the entries provided in the MOUNTLIST file in this package. of course, you may increase the side of the fake disk by changing the mountlist, but you must also make a bigger file on the pc. ----------------------------------------------------------------------------- GETTING IT RUNNING this software requires: - an amiga 1000, 500, or 2000 (i have only tested it with a 1000, but the signals on the 500/2000 should be the same) - an ibm pc with hard drive (sick idea - use it's FLOPPY drive!), and a modified parallel port (see modification instructions later in this document) - a cable to connect the amiga parallel port to the ibm parallel port (again, see instructions in this document) - this software (scottdisk.device / mountlist entries on the amiga side, and create.exe / ppa.exe on the ibm side) ----------------------------------------------------------------------------- PERFORMANCE the low-level byte transfer isn't all that great. with a Logix Microcomputer turbo XT (8Mhz 8088) i got around 70 microseconds per byte to complete a cycle. with the Logix 20Mhz 386, i get around 30 microseconds per byte. that works out to a maximum of 33333 bytes/second with the 386, and 14285 bytes/second with the turbo XT. the majority of the low performance is due to the software-driven handshake i'm doing. it'd be vastly improved by adding a little hardware. the filesystem-level performance is dismal as a result. with FFS using the aforementioned 386 machine with a 40 meg priam 28ms drive and a disk cache program running on the pc (1 meg cache), and 200 buffers on the amiga, diskperf sez: File create/delete: create 5 files/sec, delete 25 files/sec Directory scan: 100 entries/sec Seek/read test: 57 seek/reads per second r/w speed: buf 512 bytes, rd 22215 byte/sec, wr 13870 byte/sec r/w speed: buf 4096 bytes, rd 27306 byte/sec, wr 13870 byte/sec r/w speed: buf 8192 bytes, rd 27887 byte/sec, wr 13870 byte/sec r/w speed: buf 32768 bytes, rd 28187 byte/sec, wr 13797 byte/sec obviously, this is pretty dismal (not much better than floppies). i don't have numbers for the turbo XT, but as i recall they were proportionally worse than the 386. the old file system will slow things down too. some of the slowness is due to the fact that i'm using very large ms-dos files to simulate the amiga partition. with the turbo XT, there were LONG pauses when a seek was performed (like 1 or 2 seconds) as ms-dos tried to figure out where to go. with the 386 machine, they are still visible but probably down to 1/4 second or less. maybe someone who knows ms-dos deep down inside can rewrite the software for the pc side so it directly accesses an ms-dos partition instead of a file. the scottdisk.device driver as assembled disables interrupts while a transfer is taking place. this of course nukes interrupt driven stuff for a brief period, and is especially annoying as far as the mouse is concerned. your serial port will also suffer (CAUTION: see the BUGS section near the end of this document for serial.device warnings). there is a flag in the sd.asm source which will allow you to enable interrupts during a transfer, but this increases the chance of a crash. again, see BUGS. ----------------------------------------------------------------------------- HOW DOES IT WORK? these programs form a link between an amiga and an ibm pc (clone). the physical link is via their parallel ports (with a mod to the ibm side - see later description). the low level protocol is a master-slave type of thing. the amiga tells the pc to do it, and the pc does it and then waits for more abuse. the link uses the 8 data bits provided by each machine as the data bus. the control is performed by using two handshake lines, one driven by the amiga and one driven by the pc. the amiga is the only one making requests, and the pc merely services them and provides information back (if it's a read). there is no passing of error conditions or other exceptions between the two (but it could be easily added). the physical link looks like this (this is NOT a wiring diagram!): AMIGA DATA PORT <=========== 8 bits ============> IBM DATA PORT AMIGA REQ/ACK --------------------------------> IBM ATN AMIGA ATN <-------------------------------- IBM ACK the ibm side is constantly polling it's ATN line, waiting eagerly for the amiga to give it something to do. the process of making read/write requests goes like this: AMIGA IBM ----------------------------------------------------------------------- READ: send block address perform seek in disk file send read command read 512 bytes from disk file get 512 bytes from ibm, return them to caller. WRITE: send block address perform seek in disk file send write command send 512 bytes to ibm read 512 bytes from amiga, write to disk file return to caller. on the byte level, things look like this: READ: poll ATN line until asserted put byte on 8 bit bus put bus in output mode assert ACK line poll ATN line until asserted detect ATN line asserted read byte from 8 bit bus assert REQ/ACK line poll ATN line until deasserted detect ATN line asserted deassert ACK line put bus in input mode poll ATN line until deasserted detect ATN line deasserted deassert REQ/ACK line detect ATN line deasserted WRITE: poll ATN line until asserted put byte on 8 bit bus put bus in output mode assert REQ/ACK line poll ATN line until asserted detect ATN line asserted read byte from 8 bit bus assert ACK line poll ATN line until deasserted detect ATN line asserted deassert REQ/ACK line put bus in input mode poll ATN line until deasserted detect ATN line deasserted deassert ACK line detect ATN line deasserted ----------------------------------------------------------------------------- MODIFYING THE IBM PARALLEL PORT FOR BIDIRECTIONAL OPERATION determine the I/O address of the parallel card you're going to modify and make sure the address doesn't conflict with any other I/O cards you have in the machine. conflicting cards or telling the software the wrong I/O address will cause problems which are difficult to trace. see the "IBM SOFTWARE" section further down if you need to tell the software an address other than 378H. the first thing to do is make sure your ibm parallel port can be modified for bidirectional operation. fortunately, most clone makers tend to exactly duplicate the original ibm parallel card, so the mod is pretty much universal. the ibm parallel port looks kinda like this: read enable -----------\ | readback buffer (for testing) v / ----------- out | buffer | in expansion bus <===========| 74xx240 |<====\\ || | | || || ----------- || || || || ----------- || || in | latch | out || ||====| 74xx373 |============> centronics conn. || | | || -----------\ || ^ 1^ centronics output latch || | | || | | output enable || | | || wr enable | in || | ----------- | | latch | GND ctl wr ena------| 74xx174 |15 | |------- spare output ----------- the mod is simple - cut the output enable pin of the 373 (might be a 374 on some cards). now wire the output enable pin to the spare output of the 174. we can now turn off the parallel port's output and read data in via the selftest buffer. the output enable of the 373/374 is pin 1. the spare output of the 174 is pin 15. i have heard that some boards come this way from the factory, but both of the cards i've hacked were as above. the bios on the machines i've tried this with even helps out by writing the spare output as a 0 all the time, making it work normally when connected to a printer! you, however, may not be so lucky and may wish to install a switch or jumper to disable the mod. BEFORE MAKING THE MOD, VERIFY THAT THE CIRCUIT IS SIMILAR TO THE ONE ABOVE BY TRACING THINGS AROUND AND MAKING SURE THAT YOU'VE GOT THE RIGHT CHIP. IF YOU SCREW UP, YOU MAY PERMANENTLY DAMAGE THE AMIGA OR THE PC OR THE PARALLEL BOARD. -------------------------------------------------------------------------- BUILDING THE CABLE the ibm parallel port has a female DB25 connector. the amiga 1000 has a male DB25, and the 500/1000 have female DB25's. i built my cables using ribbon cable and insulation displacement type connectors. both are available at radio shack. put the (or one of) the female connectors on one end of the cable, and put the other connector on the other end of the cable. make sure, of course, that pin 1 of the connectors goes to the same wire. now we've got a straight through cable. that's NOT what we want, however. we must remove some wires completely and shunt a few in different directions. using an exacto knife, carefully separate the conductors of the cable on the amiga side for about 3 inches along the cable. now, cut out the separated segments as shown in the diagram below. leave the long ends of wires 1 and 21 on the ibm side, and the long ends of wires 23 and 25 on the amiga side. remove all the other segments (except the ones shown as lines completely across). now connect wire 1 from the ibm side to wire 23 of the amiga side, and wire 21 of the ibm side to wire 25 of the amiga side. the result should be: wires 3, 5, 7, and 9-18 connected straight through. wires 2, 4, 6, 8, 19-22, and 24 broken. wire 1 of the ibm side to wire 23 of the amiga side. wire 21 of the ibm side to wire 25 of the amiga side. NOTE: THESE ARE WIRE NUMBERS, NOT CONNECTOR PIN NUMBERS! AMIGA SIDE IBM SIDE <-2"-><--3"--><-enough to reach the pc 4' max-> 1 ----- /-------------------------------------- 1 2 ----- | -------------------------------- 2 3 -------|-------------------------------------- 3 4 ----- | -------------------------------- 4 5 -------|-------------------------------------- 5 6 ----- | -------------------------------- 6 7 -------|-------------------------------------- 7 8 ----- | -------------------------------- 8 9 -------|-------------------------------------- 9 10-------|--------------------------------------10 11-------|--------------------------------------11 12-------|--------------------------------------12 13-------|--------------------------------------13 14-------|--------------------------------------14 15-------|--------------------------------------15 16-------|--------------------------------------16 17-------|--------------------------------------17 18-------|--------------------------------------18 19----- | --------------------------------19 20----- | --------------------------------20 21----- | /----------------------------------21 22----- | | --------------------------------22 23-------/ | --------------------------------23 24----- | --------------------------------24 25-----------/ --------------------------------25 if you really can't figure it out, the wire numbers map to DB25 pin numbers as follows (wire number - pin number): ------------------------------------------------------------------------------- |1-1 3-2 5-3 7-4 9-5 11-6 13-7 15-8 17-9 19-10 21-11 23-12 25-13| \ / \ 2-14 4-15 6-16 8-17 10-18 12-19 14-20 16-21 18-22 20-23 22-24 24-25 / -------------------------------------------------------------------------- ----------------------------------------------------------------------------- THE SOFTWARE FOR THE AMIGA SIDE the software for the amiga side is supplied as several files: SD.ASM / SCOTTDISK.DEVICE the source/executable device driver itself. requires some include files (anything from the original stuff to the latest should work). BUILD.SCRIPT a sample script file for building SCOTTDISK.DEVICE from SD.ASM, using the metacomco assembler and software distillery's BLINK. SCOTTDEVICE.ASM where it all began. scott turner's original code. does not require any include files. build this one (if you want) just like SD.ASM. MOUNTLIST two mountlist entries for scottdisk.device, one for FFS and one for the old file system. both are set up for 10 megabytes. you must copy scottdisk.device to your devs: directory and insert one of the mountlist entries into your devs:mountlist file. rename the disks as you like. if you want to make the disk bigger or smaller, change the surfaces/blockspertrack/lowcyl/highcyl numbers accordingly. of course, you'll also have to change the size of the file on the ibm pc. i left "reserved" at 2, but i don't think the reserved part is of any use unless you're going to autoboot off of it (good luck!). to calculate the disk size in blocks of 512 bytes, do like this: surfaces * blockspertrack * (highcyl - lowcyl + 1) for example, the sample mountlist entries would go like this: 1 surface * 8 blockspertrack * (2559 highcyl - 0 lowcyl + 1) comes to 20480 blocks, or 10485760 bytes, or 10 megabytes. the amiga-pc disk must, of course, be formatted. because of a reliability problem (described later) it sometimes hangs when being severely beaten on. i suggest using FFS and formatting with the QUICK option. i leave the device-driver dependent "how it works" up to the student 8-). note that it differs significantly from the mydev.asm example given in the RKM. i originally attempted to get my parallel port stuff to work with a mutation of mydev.asm, but it just didn't wanna play. anyone have a "fixed" version of mydev.asm? ----------------------------------------------------------------------------- THE SOFTWARE FOR THE IBM PC SIDE the software for the ibm pc side is provided in several files. create.c / create.exe source/executable for the C program which creates the amiga.dsk file. the .EXE file was created with microsoft C and LINK, but it should go through any compiler unscathed. ppa.asm / ppa.exe source/executable for the assembler program which services amiga requests. the .EXE file was created with microsoft MASM and LINK. run this on the ibm side before you mount the device on the amiga side. while it's waiting for a request from the amiga, you may abort it by pressing a key (it may take a few seconds to see it). if it hangs in the middle of a transfer, you'll probably have to reboot the pc and the amiga. currently create.c is wired to create a 10 megabyte file. change the #define at the beginning and recompile to change it. note that the disk size specified in the amiga mountlist must not exceed the size of the ibm file. ideally, they should match. ppa.asm is wired for a parallel port at I/O address 378H. if your parallel port is at a different address, change the 'PPB EQU 378H' line in ppa.asm. ----------------------------------------------------------------------------- WHY IS THE CODE SO UGLY? i have kept scott turner's style (or lack of it) as far as includes and references to library offsets and structure offsets. it's rude, crude, and disgusting, but at least the metakumquat assember doesn't take three weeks to assemble it this way. i started to fix it, and was appalled at the 3 minute or more assembly times, with hardly any hard disk access! you'll note that i gave in when it came to the interrupt disable/enable stuff since i didn't wanna play detective to find out what the offset for the IDNestCount was. ----------------------------------------------------------------------------- AND NOW, THE BUGS... there seems to be a very intermittent reliablity problem with this thing. the symptom is that either the amiga or the PC hang as if they are in the middle of a byte handshake, and the other side can't see the handshake anymore or has falsely detected one. i'm at a loss. the NOINTS flag in the code will allow you to disable interrupts during transfer if set to 1, and allow them if set to 0. this is a stopgap measure, as it doesn't CURE the problem but at least reduces it greatly. a long time ago when i first wrote this thing, the problem seemed to be that someone in exec was reprogramming the CIA data direction registers occasionally. i haven't done any real tracking down since i don't really have a use for this stuff anymore (it was more of a curiosity - "yeah, yeah - let's write a device driver!"). the problem may also be the slow rise/fall times of the handshake signals giving false indications to either side. whatever. if you find the problem, i'd like to hear about it. another warning - sometimes using serial.device will knock out the CIA also (ie, using your favorite terminal program). flame CBM. and for heaven's sake, DON'T use parallel.device while this driver is operating. rename it to something like parallel.dev to prevent accidental use. ----------------------------------------------------------------------------- IDEAS FOR ADDITIONS TO THIS SOFTWARE first of all, to increase speed, someone who knows ms-dos real well could fix this up so the pc software accesses a reserved ms-dos partition instead of doing it on a huge file. make the protocol more general - maybe write more drivers for the amiga to access the ibm's serial or parallel ports, or other resources. of course, the ibm software will have to learn to deal with these requests, and most likely have to go from the busy poll it currently uses to something interrupt driven. a simpler modification would be to allow for multiple units in the amiga code and multiple amiga.dsk files (or partitions) on the ibm side. you could change the hardware interface so that it's not a master-slave system anymore. allow the pc to initiate requests for whatever it likes, perhaps letting it access amiga resources. you could change the hardware so that it's not completely software driven. if you examine the byte level protocol, you'll see that there's alot of polling and signal assertion/deassertion going on, which could easily be done with hardware. this will give the best raw speed increase. change the ibm hardware/software side so that it's interrupt driven and runs like a TSR, so that you can still use the PC while the amiga uses it's disk or other resources (sidecar/bridgeboard anyone?). and the big change, the one i really wanted to do - make the amiga software a filesystem handler instead of a low level device driver. it could then access the files on an ms-dos formatted disk. i think there would be some significant speed improvements with this one, since directory-oriented stuff is not transferred between machines - only the file data is. ----------------------------------------------------------------------------- A FINAL NOTE thanks to everyone who was interested in the code. this'll be my first entry into the public domain. and of course, thanks to everyone else who contributes to the PD library. there may be one or more bugs in my code (and possibly scott turner's code). in connection with the reliability problem mentioned above, i would appreciate it if someone in-the-know would scrutinize the resource allocation stuff (getting control of MR_PARALLELBITS and MR_PARALLELPORT). also, if anyone's got a similar or completely different device driver put together, i'd like to see it. device drivers are one of the fuzzy areas in the rom kernel manuals. unfortunately for this project, i don't have full time access to ibm pc's (dragging one home from work on the harley isn't real easy, and the truck uses too much gas!). so i don't think i'll be doing too much more work on this driver. i am currently designing an 8 port serial board which will have it's own CPU (an intel 80186, cuz we have emulators for it in work and it's cheap). it'll go like a bat out of hell - how's 19.2K baud transmit/receive full blast on all 8 ports simulateously, without annoying the amiga's 68000 too much, sound? of course, this will require another driver, one which is compatible with the poorly-documented serial.device! anyone got serial.device figgered out completely? --Scotty