harmon@abvax.UUCP (12/03/87)
I finally got a copy of the OS9 development system the day before Thanksgiving. So I spent a bit of time that long weekend trying it out. In general I was very happy with the package. For $99 you get a debugger, an editor, an assembler, a linker, a ram disk driver, and more. A good deal. I worked with the RMA a bit trying to write a SASI hard disk driver and had quite a bit of success. However one thing I didn't figure out was how to write a device descriptor module using the RMA. Has anyone had any experience with this? I was able to build a descriptor using debug to modify another descriptor, but I would really like to be able to build one from code. Another problem I encountered was the lack of an rbfdef.a file and missing definitions in the os9defs.a file. Converting the level 1 rbfdefs file to an rbfdefs.a file was simple. All orig statements were converted to csect statements and endsect statements were added at the end of sections. Also the . operators needed to be changed to *. The os9defs.a required some additions (which were in os9defs) to allow my rbfdefs.a file to work properly. All in all the procedure was simple but why should everyone have to do it? Are there any public defs files in the proper format for the RMA ? While I'm rambling I'd like to talk about one last problem, debugging a device driver. How does one find the data area assigned to a device driver? I tried using the debugger's 'e' command, but the data in the areas pointed to by U and Y didn't look like my data. I ended up using FCB statements in my code and writing debug values in these locations (since I knew where the code was) as a debugging tool. Does a better method exist? Larry Harmon
pete@wlbr.UUCP (12/07/87)
In article <131@abvax.UUCP> harmon@abvax.UUCP (Larry Harmon) writes: > > I finally got a copy of the OS9 development system > > Another problem I encountered was the lack of an rbfdef.a file and >missing definitions in the os9defs.a file. Converting the level 1 rbfdefs >file to an rbfdefs.a file was simple. Plainly, they screwed up. What happened was that the RBF and SCF defs were left off of the Development disk. It's somewhat murky yet as to who dropped the ball (Tandy/Microware), but Microware has made good. They have posted versions in their new Forum on Compuserve (GO MSC). I will get copies of the SCF and RBFDEFS and post them here. I think that they are still in the old (not *.a) format, but as you discovered, that's no big deal. >How does one find the data area assigned to a device driver? >... Does a better method exist? > There are a couple of new system state debuggers out. One is called ERINA or SERINA. Believe that Jim Omura can expound on this product. It will allow you to do exactly what you're trying to do.. view system memory. The basic trick they use (I think) is to use a pseudo-device driver that acts sort of like a full system ramdisk. This way, any byte in the system can be read or written. Powerful, but dangerous. -- Pete Lyall (OS9 Users Group V.P.) Eaton Corporation (818)-706-5693 Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud) Usenet: {trwrb,scgvaxd,ihnp4,voder,vortex}!wlbr!pete or pete@wlbr.eaton.com
jejones@mcrware.UUCP (James Jones) (12/09/87)
SERINA is the one (of these two OS-9/6809 debuggers) that will let you debug things such as device drivers; ERINA is for non-system code. James Jones