marc@reed.UUCP (05/14/86)
| | A recent discussion in net.micro.cbm explained how one could change the C64 basic rom to ram by copying that block of memory to itself (loop of POKE X,PEEK(X)) and then set a pointer at location $00. This would copy the rom into a block of ram under it, so that the Basic routines could be edited normally. The pointer told the computer to use the new ram instead of the rom. Does anyone know if this can be done on the Apple ][e? If not, is there another way of altering Basic functions, keywords, etc.? Please mail or mail and post any responses. Marc Leonard {ihnp4,hplabs,decvax}!tektronix!reed!marc
god3@sphinx.UChicago.UUCP (Peter Godwin) (05/16/86)
In article <3440@reed.UUCP> marc@reed.UUCP (Marc Leonard) writes: > A recent discussion in net.micro.cbm explained how one could >change the C64 basic rom to ram by copying that block of memory >to itself (loop of POKE X,PEEK(X)) and then set a pointer at >location $00. This would copy the rom into a block of ram under >it, so that the Basic routines could be edited normally. The >pointer told the computer to use the new ram instead of the rom. > Does anyone know if this can be done on the Apple ][e? If not, >is there another way of altering Basic functions, keywords, etc.? > Please mail or mail and post any responses. A company called Beagle Brothers Microsoftware, Inc. sells many utilities which allow one to modify DOS and Applesoft commands. Beagle Basic is probably the closest thing to what you're looking for. This program allows you to modify the names of Applesoft commands, token words, and it also gives you lotsa extra commands (like if then else and swap a,b where a and b are variables). And of course, there's the "oldee but goodee" DOS BOSS which allows you to do the same to DOS 3.3 commands. Hope this helps -- Peter Godwin uucp: ...ihnp4!gargoyle!sphinx!god3 Univ. of Chicago Comp Ctr mailnet: x9.xpg@UChicago.Mailnet Room 2322x bitnet: god3%sphinx@UChicago.Bitnet 5824 S. Kimbark Ave. ARPA: x9.xpg%UChicago.Mailnet@MIT-Multics.ARPA Chicago, IL 60637
wtm@neoucom.UUCP (Bill Mayhew) (05/17/86)
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
6101695@pucc.BITNET (Raymond Chen) (05/18/86)
> DOS links into BASIC's "charget" routine. Well, sort of. DOS actually links into KSW, which is a part of the system, not BASIC. This explains how DOS can operate from within the monitor or from Integer BASIC. (Integer BASIC does not have a CHARGET routine.) KSW is not a subroutine. KSW is a vector which resides at $38/$39 (zero page). It is referenced by KEYIN ($FD0C) which is the "official" way of getting characters from the keyboard. DOS doesn't worry too much about KSW. The only reasons it bothers to trap input is so that (a) it can act upon DOS commands typed directly at the keyboard (like CATALOG), (b) it can feed INPUT statements when you are reading from the disk (with OPEN file, READ file) and (c) it can feed GETLN (the "official" line input routine) when you are EXECing a file. Actually, most of DOS's work is done by its vector into CSW. CSW is yet another vector (at $36/$37) which is called by COUT, the "official" Character OUTput routine.) It is there that DOS sniffs for a RETURN followed by Ctrl-D. > The other way to extend function is with the "&" function . . . I have found the Apple PugetSound Program Library Exchange (the people who put out Call -APPLE) publication "All About Applesoft" to be very handy, especially the section on Applesoft internal entry points. > DOS is very tenacious about giving up control. > . . . I've found the best way to take over control from DOS is >to attack DOS itself. I recommend the "official" method of installing custom routines: 1. Install your routine as if DOS didn't exist. 2. Call $03EA. $03EA (DOSCONN) connects DOS to your routine by copying the CSW and KSW vectors into the DOS table at $AA53/AA54 and $AA55/AA56. If you want to disconnect DOS completely, just put $FDF0 into CSW and $FD1B into KSW, and DON'T call DOSCONN. Warning: Once DOS is disconnected, you can't do things like CATALOG and such. If you want to reconnect DOS, just call $03EA. (CALL 1002 from BASIC) >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. It may work, but it is excruciatingly slow. My method: 1. Drop into the monitor (CALL -151) 2. C081 C081 (This write-enables the bank-switched RAM, but does not read-enable it. If it were read-enabled, the system would hang, since there is nothing there to read.) 3. D000<D000.FFFFM (This is the monitor equivalent of the BASIC program.) 4. C083 C083 (This write- and read-enables the RAM. You can now deal with it as you please.) 5. make modifications 6. C080 (This write-protects but read-enables the RAM. Doing this makes your newly-modified RAM look like ROM.) 7. ctrl-c (to return to BASIC, if you haven't clobbered it.) If you really want to know, all you really have to copy is the range F800.FFFF if you are willing to go without BASIC. Please pardon my verbose Pavlovian response. I'll try not to do it again. Raymond Chen (6101695@PUCC) "Don't look at me. I'm new here."
ix742@sdcc6.UUCP (James Hayes) (05/19/86)
wtm@neoucom.UUCP (Bill Mayhew) writes in article <203@neoucom.UUCP>: > ..... 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.) Nope. DOS never looks at CHARGET. DOS looks at the KEYboard INput (KEYIN) vector. This lies at $38/$39 (Low/High) and contains the address of the routine that reads from the keyboard. KEYIN is used to monitor what you type. I.e. "CATALOG". DOS also looks out Character OUT (COUT $36/$37) for the routine to listen to the output of BASIC, etc.. It looks for commands like "OPEN", "CLOSE", "CATALOG" that are preceded by <CR>^D{command}. This is how BASIC works with DOS. The Applesoft CHARGET routine also lies in page 1 but is used for an entirely different purpose. When BASIC wants the next character in the program, it calls CHARGET. This is just a memory fetch routine. Once the fetch has completed, the address of the fetch is incremented. You can modify CHARGET to filter commands in basic. I.e 10 !UNDO(3,4):PRINT "HELLO" The !UNDO command doesn't belong to BASIC. If you modify CHARGET, you can intercept the command when you see the initial !. I beleive PRODOS modifies CHARGET to look for HGR, HGR2, LOMEM, HIMEM and the like, so it can modify it's on memory map. But note that BASIC stores it's own commands in a one byte TOKEN. So modifying what HOME does (for example) is as easy as looking for one byte. I can't remember the charget address off hand, but I beleive it lives near $10-$20. > 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. A slightly more portable way to do this is the following: Set up the addresses of the input/output hooks to point to your routines, and then ask DOS to connect them for you. This is done by calling the DOS reconnect vector at $3EA. This will automatically modify DOS's internal vectors for you. This is more reliable, for different DOS versions might have different internal vectors. $3EA will always set them properly. A sample keyclick program: $300 LDY #<CLICK ; Determine address of CLICK LDX #>CLICK STY $38 ; Store it in the KEYIN vector STX $39 JMP $3EA ; Ask DOS to reconnect * CLICK BIT $C000 ; Wait for key BPL CLICK ; Keep looping BIT $C030 ; Twitch speaker LDA #20 JSR $FCA8 ; Delay BIT $C030 ; Twitch speaker again. LDA $C000 ; Read the key struck BIT $C010 ; Clear the key struck RTS ; Return Note: This DOES NOT disconnect DOS. DOS will still monitor the I/O looking for it's comands. This is very handy... I hope I haven't created more confusion than I've gotten rid of... -- Jim Hayes, UCSD EE/CS Department. ARPA: hayes@UCSD.EDU UUCP: {ihnp4, gatech, ucbvax, decvax, etc.}!sdcsvax!hayes "There are two ways to dislike poetry; one way is to dislike it, the other is to read Pope." -- Oscar Wilde
avery@puff.UUCP (Slippery Jim) (05/20/86)
This will be fairly short, as compared to the last few articles on the subject.
They have pretty much explained it the way I would. One note about the
difference between a ][ or ][+ and a //e is that if, on a ][ or ][+, you have
the upper 12k occupied by read-only RAM (tweaking $c080), and you hit reset,
the apple uses the RAM's version of the reset vector ($FFFE,$FFFF I think,
but I don't have my manuals any more) and will jump to whatever's in those
addresses no matter what. This was used for some hard reset trapping in the
old days. The //e, on the other hand, replaces the RAM with the ROM monitor
and basic whenever you hit reset. The normal address to have in the reset
vector is a RAM address to jump to. I believe this address is in page 3.
There's another vector next to the reset vector in the rom of interest to
some people -- the IRQ vector. This also normally holds a page 3 address,
which, I believe, on the ][+, promptly returns. I once wrote an interrupt
driven terminal program for the ][+ with the Novation Apple-Cat ][ modem
which can actually run in the background! It was very simple, and it took over
half of the screen, but you could be on a BBS and be editing and debugging
a basic program at the same time! Not bad for a 6502 based micro, huh?
Just a couple of thoughts. If you must reply, please use this address:
{seismo,ihnp4,allegra,topaz}!uwvax!gumby!bambam!pebbles!avery
as I'm no longer on puff.6101695@pucc.BITNET (Raymond Chen) (05/22/86)
hayes@UCSD.EDU (Jim Hayes) says in <2620@sdcc6.UUCP> > . . . I beleive >PRODOS modifies CHARGET to look for HGR, HGR2, LOMEM, HIMEM and the >like, so it can modify it's on memory map. > Pre-releases of ProDOS may have twiddled with CHARGET, but the current release does not, as far as I can tell. The Apple people decided to use the TRACE flag to keep tabs on Applesoft. TRACE is always ON, but ProDOS watches COUT for a '#', traps it, and does its own pre-line processing. One thing I know it does is count the number of assignment statements. When it hits a certain number (determined by the amount of FREe memory), ProDOS executes its own fast-FREe routine so Applesoft never uses its (slow) FREe routine. It probably does other stuff, but I didn't bother to disassemble it that much. >I can't remember the charget address off hand, but I beleive it >lives near $10-$20. CHARGET hangs out at $B1. CHRGOT re-fetches the last token ($B7) and TXTPTR ($B8, $B9) points to the current token. Now I KNOW that I've confused the matter beyond recognition. (What was the original topic again?) Raymond Chen, BITNET: 6101695@PUCC "Don't look at me. I'm new here."