anderson@midway.ece.scarolina.EDU (Stuart Anderson) (04/12/88)
[]
A request and a thought (proposal?)
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.
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.
Help with #1 would be appreciated, comments on #2 would be interesting.
------------------------------------------------------------------------------
Stuart Anderson, University of South Carolina ECE Dept.
ucbvax!decvax!mcnc \
ames!nrl-cmf!ukma ..!gatech!hubcap
bloom-beacon ....../ \
ncr-sd ............................!midway!anderson
anderson@ece.scarolina.educmcmanis%pepper@Sun.COM (Chuck McManis) (04/13/88)
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.walker@sas.UUCP (Doug Walker) (04/13/88)
In article <347@midway.ece.scarolina.EDU> anderson@midway.ece.scarolina.EDU (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. I assume you want something below the level of trackdisk.device? If not, check out the RKM on how to use trackdisk.device to get at the disk at the track level. > >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 Well, it's not PD, but it is freely redistributable - BLINK versions up to 7.0 are available on just about any BBS, from Fred Fish, and hundreds of other sources for free. >This would be nice for those larger programs that require to much memory >or disk space to be developed natively. Any program that is too big to be developed on a 512k Amiga with two floppy drives is not going to be developed on a PD C compiler. I'm sorry, but I cannot believe that a PD compiler has had all the work put into it that is necessary to do really significant projects. Also remember that the Distillery wrote BLINK and ported both HACK and LARN to the Amiga with 512K two-drive A1000's. LARN is so large that it will not run if workbench is loaded on a 512k A1000. HACK sources and objects had to be stored on different disks because they were too big to go on one disk, but other than that there were no problems.
anderson@midway.ece.scarolina.EDU (Stuart Anderson) (04/14/88)
In article <455@sas.UUCP> walker@sas.UUCP (Doug Walker) writes: >I assume you want something below the level of trackdisk.device? If not, Correct, I would like to have to be able to implement my own device driver and not use trackdisk.device. I not only want to "take over the machine", but I would like to expell everything that is there. If this does turn out to be too much of a problem, I will look into letting the trackdisk.device stay around and use it as long as it doesn't depend too heavily on other parts of the 'ROM' which may not be there anymore (especially interupt service routines). Can anyone say XINU?? >>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 >Well, it's not PD, but it is freely redistributable - BLINK versions up >to 7.0 are available on just about any BBS, from Fred Fish, and hundreds >of other sources for free. But will it run on an NCR Tower? Let me clarify my idea some. I have the SOURCE for the pdc and the assembler and compiled them under UN*X. What I was thinking was to find the source to a linker that could compile under UN*X (or dos or whatever). This would provide a PD cross developement system that can run on (almost) any machine. In <49209@sun.UUCP> the problem was brought up about the standard library. One solution (depending on legalities ) would be to use the one that came with the C compiler you normally use (assuming you have one) since it has been stated that the amiga.lib would work so would lc.lib. Another solution would be to develope a PD library. I have seem a couple of PD libraries (tiny.lib, etc.) but don't remember there contents. ARP is PD so maybe we could start with it. >>This would be nice for those larger programs that require to much memory >>or disk space to be developed natively. > >Any program that is too big to be developed on a 512k Amiga with two floppy >drives is not going to be developed on a PD C compiler. I'm sorry, but I >cannot believe that a PD compiler has had all the work put into it that is >necessary to do really significant projects. Also remember that the I agree, but recently there was some talk about doing some more work on the one that is availible, and bringing it up to acceptible functionality. A system like this could provide the encouragement needed to do the additional work needed. >Distillery wrote BLINK and ported both HACK and LARN to the Amiga with 512K >two-drive A1000's. LARN is so large that it will not run if workbench is I know that it can be done, but I have become acustomed to having lots of disk space and not having to swap disk ( This becomes tiresome with 141Mb mounted inside the computer :-) ). I was just thinking of alternate ways of developing programs for the Amiga. Some people may have more resources (time being one of them) availible to them at work/school than they have at home. ------------------------------------------------------------------------------ Stuart Anderson, University of South Carolina ECE Dept. anderson@ece.scarolina.edu { decwrl!decvax, duke, ecsvax, rti, uvaarpa }!mcnc!ece-csc ......\ { bbn, bloom-beacon, mcnc, purdue, rutgers, ukma }!gatech!hubcap ....\ { charsh, hplabs!hp-sdd }!ncr-sd ................................./ | | /............................................................../ | \..!ncrcae!usceast!midway!anderson
cmcmanis@sun.uucp (Chuck McManis) (04/15/88)
In article <348@midway.ece.scarolina.EDU> (Stuart Anderson) writes: ->In article <455@sas.UUCP> walker@sas.UUCP (Doug Walker) writes: ->>I assume you want something below the level of trackdisk.device? If not, [ Actually I wrote that ...] ->Correct, I would like to have to be able to implement my own device driver ->and not use trackdisk.device. I not only want to "take over the machine", ->but I would like to expell everything that is there. If this does turn ->out to be too much of a problem, I will look into letting the ->trackdisk.device stay around and use it as long as it doesn't depend too ->heavily on other parts of the 'ROM' which may not be there anymore (especially ->interupt service routines). Can anyone say XINU?? I can say XINU, but expelling the ROM (where trackdisk.device lives) would mean that you couldn't run Amiga programs even if you wanted to. And I assume you will be burning the XINU kernel into ROM to replace it ? My guess is that if you rewrite the software, including replacing all of Kickstart you have a 10 manyear project on your hands (if you do it in under two years I can guaruntee you a job a Sun :-)). I think you can say "maybe not worth it" ? Still, the answer is get the hardware manual from CATS and the developers conference notes. Everything you need is in there. ->But will it run on an NCR Tower? Let me clarify my idea some. -> ->I have the SOURCE for the pdc and the assembler and compiled them under UN*X. ->What I was thinking was to find the source to a linker that could compile ->under UN*X (or dos or whatever). This would provide a PD cross developement ->system that can run on (almost) any machine. In <49209@sun.UUCP> the problem ->was brought up about the standard library. One solution (depending on ->legalities ) would be to use the one that came with the C compiler you ->normally use (assuming you have one) since it has been stated that the ->amiga.lib would work so would lc.lib. Another solution would be to ->develope a PD library. I have seem a couple of PD libraries (tiny.lib, etc.) ->but don't remember there contents. ARP is PD so maybe we could start with it. Several points. Amiga.lib just calls routines in the ROM, if you blow it away (the ROM) none of the libraries for the Amiga will be of any use. That means you will need source to the libraries you use. Both Manx and Lattice will sell those sources but they aren't cheap. Second point ARP IS NOT PD! It is freely distributable but it is COPYRIGHTED. You could use it but you can't sell it. As I have said before, the Amiga makes an excellent O/S development platform, primarily because you don't have to blow away the existing O/S to develop a new one. Replace it a piece at a time until it is all working. I don't want to discourage you, doing is the best way to learn, but my feeling is that you haven't grasped how much you can do without driving around with a bull dozer. It sounds like trying to design a new car by machining new parts out of a block of steel. -- --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.
anderson@midway.ece.scarolina.EDU (Stuart Anderson) (04/18/88)
[] In article <49671@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <348@midway.ece.scarolina.EDU> (Stuart Anderson) writes: >->In article <455@sas.UUCP> walker@sas.UUCP (Doug Walker) writes: >->>I assume you want something below the level of trackdisk.device? If not, > >[ Actually I wrote that ...] Got my replies crossed. Sorry. >->interupt service routines). Can anyone say XINU?? > >I can say XINU, but expelling the ROM (where trackdisk.device lives) would >mean that you couldn't run Amiga programs even if you wanted to. And I >assume you will be burning the XINU kernel into ROM to replace it ? XINU is generally an educational tool. Because of this, I am not bothered by not being able to run Amiga programs while I am working with XINU. I don't intend on burning XINU into ROMs. I want to be able to load it like any other program, except that the initialization function takes over the machine. >My guess is that if you rewrite the software, including replacing all >of Kickstart you have a 10 manyear project on your hands (if you do it I don't want to replace all of Kickstart. XINU seems well partioned, so that it can be implented in stages allowing me to do as much or as little as I care to do. >in under two years I can guaruntee you a job a Sun :-)). Thanks for the offer! :-) >I think you can say "maybe not worth it" ? I can. I am still just investigating the possiblilty of such a project. If many of the pieces can be found, then the amount of work is reduced. If anybody else is interested, then the project can be divided up and the work for any one person reduced even further. >Still, the answer is get the hardware manual >from CATS and the developers conference notes. Everything you need is >in there. I have the RKM & Hardware Manual set. It is not always clear (or even correct). I was looking for sample code from someone that has already figured it out. I don't want to do this all by myself. Can somebody summarize whats in the developers conference notes (maybe an index or table of contents?). Can somebody send me info on ordering the developers conference notes? >->But will it run on an NCR Tower? Let me clarify my idea some. >-> >Several points. Amiga.lib just calls routines in the ROM, if you blow it >away (the ROM) none of the libraries for the Amiga will be of any use. That MISUNDERSTANDING! (Possibly my fault). The cross developement system idea is mutually exclusive of the XINU idea. They were just part of the same posting. The 'ROM' will still be there ( unless XINU is running :-)). >Second point ARP IS NOT PD! >It is freely distributable but it is COPYRIGHTED. You could use it but you >can't sell it. I stand corrected. >As I have said before, the Amiga makes an excellent O/S >development platform, primarily because you don't have to blow away the >existing O/S to develop a new one. Replace it a piece at a time until it >is all working. Back to XINU: I am all for re-use. I would like to use as much as possible. I would like to implement XINU as close to it's original intentions instead of being layered on top of something else for performance reasons. >I don't want to discourage you, doing is the best way to learn, but my >feeling is that you haven't grasped how much you can do without driving >around with a bull dozer. It sounds like trying to design a new car by >machining new parts out of a block of steel. Perhaps I am just not conveying my ideas clearly. I am open for suggestions, after all, this is still just a feasibility study at this point. PS: If this seems like it should be in .tech, then let's migrate to there. ------------------------------------------------------------------------------ Stuart Anderson, University of South Carolina ECE Dept. anderson@ece.scarolina.edu { decwrl!decvax, duke, ecsvax, rti, uvaarpa }!mcnc!ece-csc ......\ { bbn, bloom-beacon, mcnc, purdue, rutgers, ukma }!gatech!hubcap ..\ { charsh, hplabs!hp-sdd }!ncr-sd ................................./ | | /............................................................../ | \..!ncrcae!usceast!midway!anderson