Moll wrote:
Don Bruder wrote:In article <x7%7e.16366$Xm3.9317@trndny01>, Moll <MollyBaker@Spam.GMAIL.Spam.Spam.Spam.Com> wrote:I'm wondering what it would take to be able to get Integer Basic to work correctly on ProDOS. I know there's a version that will load on DOS 3.3 in 48K (i.e., doesn't use the language card), which I have as a BIN file on a disk image: http://www.dosius.net/diskint.dsk.gz (22 sectors)I wonder, if this could be disassembled, if it could be adjusted to work with ProDOS and re-assembled.Moll.Unlikely. "BASIC.SYSTEM" under ProDOS is really little more than a mass of glue that sits between ROM Applesoft and the ProDOS MLI, turning the various disk-accessing things in BASIC into MLI commands to ProDOS, and shuttling any data involved to and from the proper places.I am aware of that, and such a program as this would be, would rely on BASIC.SYSTEM to already be loaded.Integer would need a similar wad of glue on top of moving it around. I seem to recall substantial portions (don't take this as gospel - I've forgotten how long it's been since I looked at an Integer memory map) of ProDOS living in places the RAM-based Integer expects to live, which was one of the main reasons it never got "ProDOS-ized". ("main" other than the fact that it was pretty much hopelessly out of date long before ProDOS came along)Yeah, and that's why I mentioned disassembling and reassembling, so as to make sure it's somewhere else in the memory map (this version does that, I think - it runs in 48K on DOS 3.3), and to make sure it doesn't step on ProDOS's ZP globals.Moll.
So you plan to write a INTEGER.SYSTEM program? which would include the GLU to the MLI + the interpreter? Beneath Apple ProDOS addendums might be very helpful to you if havn't got them yet to see what they did for applesoft and mimic that for INTBASIC.
Just curiuos what would be your application of this BASIC? Glenn