Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: Disk Device Driver & Cross Development System
Message-ID: <49209@sun.uucp>
Date: 12 Apr 88 17:38:39 GMT
References: <347@midway.ece.scarolina.EDU>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Distribution: na
Organization: Sun Microsystems, Mountain View
Lines: 33
Keywords: device driver cross development

In some article (Stuart Anderson) writes:
-> 1.	Does anybody have some code that accesses the disk drive
-> hardware directly (as in device driver). If someone could send me some,
-> it would save me hours of pain and grief re-inventing the wheel.

This code is built into the Amiga ROM and it is called trackdisk.device.
You can talk to it through Exec. Note that using the trackdisk.device 
does not imply that you have to use AmigaDOS' disk format, at its simplest
is will read and write raw bits to the disk. Designing your own MFM 
blitter encoding routines, while educational, are often not very 
productive. Also you can use exec and trackdisk when "taking over the machine"
because they are always around in ROM even if you blow off DOS etc. 
There is lots of good documentation on trackdisk in the developers notes
from the last developers conference. ($20 from CATS, 1200 wilson drive, etc)

-> 2.	Since there is a public domain C compiler and a PD assembler 
-> both of which run on other machines, all we would need is a PD linker
-> and a little utility that makes function stubs from the .fd files
-> for creating a library (maybe we can use amiga.lib as is) and we
-> would have a nice PD cross developement system that would let us
-> develop programs on other computers and download the executable.
-> This would be nice for those larger programs that require to much memory
-> or disk space to be developed natively.

You can use Amiga.lib as is. And the difficulty of getting a C compiler
is primarily the library routines that do things that C programs expect
to be able to do (like fopen() and lseek()). Those would have to come
from a library of your own design/implementation. 


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.