Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 alpha 4/15/85; site neoucom.UUCP Path: utzoo!watmath!clyde!cbosgd!neoucom!wtm From: wtm@neoucom.UUCP (Bill Mayhew) Newsgroups: net.micro.apple Subject: Re: ROM to RAM Message-ID: <203@neoucom.UUCP> Date: Sat, 17-May-86 10:10:33 EDT Article-I.D.: neoucom.203 Posted: Sat May 17 10:10:33 1986 Date-Received: Mon, 19-May-86 04:09:14 EDT References: <3440@reed.UUCP> Distribution: net Organization: Northeastern Ohio Universities College of Medicine Lines: 101 Summary: Somewhat painful on the Apple In the preceeding article, the author expressed a desire to be able to modify Apple Basic. Depending on your mix of hardware, firmware and software, the job of modifying the Apple can range for esay to pretty difficult. I have most of my experience writing stuff that runs under DOS 3.3. With DOS 3.3, the easiest way is to gain control of the console input vector, and replacing it with your own. That way, you can parse everything that comes in; if it is of no interest to your program "wedge" than you can drop the characters on through to the input routines used by DOS. The above is why it is necessary to preceed DOS function commands in BASIC programs with a control-D. DOS links into BASIC's "charget" routine. To save time, dos ingores everything until it detectes a carriage return followed by control-D in the input stream, it then parses the line until the next return comes up. Charget is a short subrountine that is stored in page zero, beginning at $39 (I think, but check the "Applesoft Programmer's reference manual" to be sure.) The other way to extend function is with the "&" function that is already provided in BASIC, see the apple literature for this one, they already have a decent description. Also, many of the Apple supplied goodies, such as the RENUMBER program use this, so you can apply some reverse engineering to figure out what's going on Also, you can use BASIC's parser to do your own dirtywork from a subroutine you supply. There is a function called STREVAL in rom that accepts a pointer to a /0 terminated string in RAM that is written according to the syntactic rules for variables and constants used in BASIC. STREVAL computes the result, and leaves the value in the Floating Point Accumulator in page zero. I've used this when I've needed to do floating point math in a machine language routine. Note that it also allows you to set variables accessed from BASIC from machine language. There was an issue of CALL A.P.P.L.E. about 6 or 7 years ago that published all the juicy addresses. It has a few addresses wrong, but you can get an idea of what's going on. All the major routines seem to be in the same places, even in the 2E! If you're interested, contact me at the address below if you can't find the original article. Note that the documentation about using the keyboard and console vectors in the Apple Programmer's reference is incorrect. DOS is very tenacious about giving up control. If either the input or output vector is attatched to DOS, it will reinstall the other vector you've taken over as soon as you do an I/O, thus disconnecting your subroutine. I've found the best way to take over control from DOS is to attack DOS itself. If I remember right, you can steal contol back by planting you vector in dos somewhere around $AA65. Disassemble DOS, and look for the vector that points to the input routine in the monitor ROM. I've used this approach to add a keyclick subroutine. ProDOS is yet another matter, we don't really use ProDOS, since all our major applications were written several years ago in DOS 3.3. At least DOS 3.3 allows you to write installable drivers for odd devices. The Apple PRoDOS Technical Reference Manual is quite good and complete with a demo diskette. It is put out by Addison-Wesley and is available just about everywhere. Also, see Beneath the the Apple ProDOS for in depth information. Yes, Applesoft can be shadowed to RAM if you have a 2E. Under normal conditions, the RAM under ROM is writeable. You can use this: 10 FOR I=13*4096 to 65535 20 POKE I,PEEK(I) 30 NEXT to move the ROM version to RAM. Then, two consecutive POKEs to $C080 should activate the shadow RAM and cut out the ROM. IF you have INTBASIC in RAM, you need to enable writing to the shadow RAM before you xfer. -- If I remeber right, that takes two pokes to $C083. Double check these addresses in your manual. Note, if you can get an old copy of DOS (perhaps 3.2.1) there used to be a relocatable version of AppleSoft on the disk for use by people that had INTBASIC in ROM! That can be very useful. I used that, and there were a couple of bgus in early versions. A last word, that graphics page right in the middle of memory sure is annoying, isn't it. I once had to write a 25K long program that used graphics, and had to be fast, so it couldn't use overlays. I discovered taht lines in BASIC end in /0 followed by the physical RAM address whre the next line can be found. The fix is easy. Use the Monitor ROM move routine to move the back half of your program past the graphics page, then edit the link. It takes longer to load initially, but makes life easier. I suppose that you could write a little subroutine to perform dynamic relocation to save loading time. I hope this is of some help to y'all. Happy hacking. Any questions? try the mail. I'm not an expert, but you're more than welcome to get my opinion. Bill Mayhew Electrical Engineeer Division of Basic Medical Sciences 4209 State Route 44 Northeastern Ohio Universities' College of Medicine Rootstown, OH 44272 USA (216) 325-2511 ext. 323 ...!allegra!neoucom!wtm