Jeff Blakeney wrote:
To: gids.rs On Sat, 6 Jun 2009 07:12:22 -0700, gids.rs wrote:You are mistaking the ROM monitor that resides from $F800 to $FFFF. Applesoft resides from $D000 to $F7FF. No calls made by Basic.system ever go into Applesoft. RobSorry, actually thats not true :). Basic.system intercepts commands from a program and either passes them on to Prodos or to applesoft depending if a chr$(4) character is found. But as I said before. No entry points have been compromised.If that's true, why is BASIC.SYSTEM 10 KB in size and why has there been multiple versions with bug fixes since it came out with ProDOS v1.0? My memory may be failing me here but I'm with Rob. I thought that the Applesoft ROM space got switched out and BASIC.SYSTEM was loaded into the high part RAM.
BASIC.SYSTEM has nothing to do with executing Applesoft programs--only with intercepting ProDOS commands and, incidentally, garbage collecting after each statement. It's so big not only because there's a lot of work to be done to perform BASIC.SYSTEM commands in ProDOS, but because it is a more "structured" implementation than Applesoft, with a lower function/byte ratio. ;-) Applesoft is entirely in ROM on all Apple II models since the Apple ][+, and the contents of the ROM interpreter have been left essentially unchanged--meaning all original bugs intact--since they were first shipped. I suspect that they considered that even obvious bugs (like floating-point multiply) had achieved the status of "features". The fact that ONERR/RESUME stack handling was buggy was handled in the first release not by fixing the ROM, but by documenting the bug and the workaround. That's been the pattern ever since (where there *are* work- arounds). -michael ******** Note new website URL ******** NadaNet and AppleCrate II for Apple II parallel computing! Home page: http://home.comcast.net/~mjmahon/ "The wastebasket is our most important design tool--and it's seriously underused."