Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Modify DOS 3.3 to load Integer Basic from Extended 80 Column Card?
154 views
Skip to first unread message
Jayson Smith
Apr 7, 2021, 10:11:36 PM4/7/21
to
I know this is a strange one. I'm blind, so on my real and emulated
Apple computers, I use an Echo II or II+ speech synthesizer with the
Textalker software. Textalker loads itself into the language card under
DOS 3.3, which means the normal DOS 3.3 trick of loading Intbasic into
the language card won't work with the Echo speech.
There exists a smaller version of Integer Basic which is included on
many talking disks of games. When you want Integer, you just BRUN
INTEGER, wait for the > prompt, then you're good to go until you FP, run
an Applesoft program, reboot, etc.
My crazy idea the other day, which I have nowhere near the expertise to
implement, goes as follows. When a disk boots, it runs code that first
loads this smaller version of Integer into memory on the Extended 80
Column Card, or complains loudly and aborts if one is not present. Then,
it patches DOS to hijack the INT command handler/function code. The new
INT code, instead of looking for Integer in the language card, copies it
from the 80 column card into its proper place in main memory, then runs
it. Ideally, this would allow for Applesoft and Integer programs to be
run at will, since any time Integer was needed, it'd just yoink it from
the 80 column memory and go on.
Any thoughts? Is this even possible, or am I wildly dreaming?
Thanks,
Jayson
--
Remove all qxz from my Email address to reply privately.
Apple computers, I use an Echo II or II+ speech synthesizer with the
Textalker software. Textalker loads itself into the language card under
DOS 3.3, which means the normal DOS 3.3 trick of loading Intbasic into
the language card won't work with the Echo speech.
There exists a smaller version of Integer Basic which is included on
many talking disks of games. When you want Integer, you just BRUN
INTEGER, wait for the > prompt, then you're good to go until you FP, run
an Applesoft program, reboot, etc.
My crazy idea the other day, which I have nowhere near the expertise to
implement, goes as follows. When a disk boots, it runs code that first
loads this smaller version of Integer into memory on the Extended 80
Column Card, or complains loudly and aborts if one is not present. Then,
it patches DOS to hijack the INT command handler/function code. The new
INT code, instead of looking for Integer in the language card, copies it
from the 80 column card into its proper place in main memory, then runs
it. Ideally, this would allow for Applesoft and Integer programs to be
run at will, since any time Integer was needed, it'd just yoink it from
the 80 column memory and go on.
Any thoughts? Is this even possible, or am I wildly dreaming?
Thanks,
Jayson
--
Remove all qxz from my Email address to reply privately.
Michael 'AppleWin Debugger Dev'
Apr 8, 2021, 11:43:42 AM4/8/21
to
Hello Jason
Sorry to hear about your condition.
If you don't know 6502 assembly language along with understanding DOS 3.3 internal implementation then this task will seem impossible. It is indeed doable but will require a lot of code patching and zero-page fixups.
There are two solutions:
* Relocate Integer Basic (IB) to run from a different address
* Relocate Echo II to run from from a different address
The bad news is that both of these are non-trivial.
The good news is that both of these are indeed doable -- with a lot of elbow grease.
IB is normally located from $E000 - $F7FF.
Relocating IB is probably the easier of the two since there are disassembly listings. Also, there was a relocatable version of Integer Basic+ but I'm not aware if this on Asimov. (FTR I also haven't looked.) I would first try to track this down.
There are two problems:
1. Fixing IB to run from a different address
2. Fixing IB HIMEM ($4C,4D) to use "safe" memory so as to not over-write IB and/or DOS 3.3
3. You also might need to fixup LOMEM / Integer Program Start ($CA, $CB)
The Extended 80 Column Card is AUXMEM. Instead of trying to get IB to run from AUXMEM I would first get it running from main RAM but at a lower address.
Making IB "relocatable" is not easy. But also not impossible. It requires manually patching up all the absolute addresses uses. (See note at end.)
It might be convenient to load IB into main RAM at $7000. Unfortunately this leaves almost a 4K (!) gap from $8800 .. $9600.
i.e. Wastes $E00 bytes.
It is tempting to use $8000 for the start of IB. This is doable but requires telling DOS to use less memory for its file buffers via MAXFILES 2.
Why MAXFILES 2?
IB located at $8000 uses $8000 .. $97FF. This unfortunately overlap's one of DOS 3.3's file buffers by 512 bytes. DOH!
DOS 3.3 file buffers "start" at $9600 because MAXFILE defaults to 3. Each file buffer requires 595 bytes. Here is a table of the lowest address DOS uses for each of the MAXFILES settings:
MAXFILES 3, HIMEM = $9600
MAXFILES 2, HIMEM = $9853
MAXFILES 1, HIMEM = $9AA6
You could change MAXFILES to 2 to move the top of DOS 3.3 file buffers up to leave enough room for IB. You would then need to manually fixup Applesoft and IB zero-page pointers to $8000 so a program's variables don't overwrite the IB code.
NOTE: I say "start" at $9600 but technically DOS 3.3 files buffers start at high RAM and work down.
NOTE: Applesoft HIMEM is zero-page $73, $74. Integer Basic HIMEM is zero-page $4C, $4D, IB SOP is $CA, $CB.
Snippet of BLDFTAB - Build File Tables
283B:68 095 PLA
283C:85 74 096 STA ASHM1+1
283E:85 70 097 STA ASHM2+1
2840:68 098 PLA
2841:85 73 099 STA ASHM1
2843:85 6F 100 STA ASHM2
2845:60 101 RTS
102 ;
103 BFTIB EQU *
2846:68 104 PLA ; SET IB
2847:85 4D 105 STA IBHMEM+1 ; UPPER MEM LIMITS
2849:85 CB 106 STA IBSOP+1
284B:68 107 PLA
284C:85 4C 108 STA IBHMEM
284E:85 CA 109 STA IBSOP
2850:60 110 RTS
Another solution is to relocate the start DOS 3.3 file buffers down. This leaves a gap between the file buffers and the start of DOS 3.3 code at $9D00. You'll probably want to read the comment on the MAXFILES Command Handler. Again this is non-trivial but doable.
http://www.textfiles.com/apple/ANATOMY/cmdmxfil.txt
You'll also want to take a look at this SO question:
https://retrocomputing.stackexchange.com/questions/13137/using-integer-basic-on-apple-ii-plus-without-a-language-card
I would follow-up researching the answer to this interesting answer:
> It was, in fact possible to load Integer BASIC into RAM without the Language Card, and without purchasing a modified variant. Back in the day there was a magazine article (Creative Computing, Byte, Nibble come to mind as likely candidates) detailing how to perform the relocation patch. From then on you were good to go.
TL:DR;
0. Find relocatable version of IB. Use this. Done.
OR:
1. Load Integer Basic at $7000
2. Fixup Integer Basic so it runs at this address
3. Fixup zero-page address for both Applesoft and IB
$4C, $4D = $7000
$6F, $70 = $7000
$73, $74 = $7000
$CA, $CB = $7000
There maybe others?
4. [Optionally] Once that is working, MAXFILES, 2, relocate to IB $8000, perform zero-page fix ups.
5. Move IB to AUXMEM, patch up INT command and FP so they work.
Good luck!
Michael
Sorry to hear about your condition.
If you don't know 6502 assembly language along with understanding DOS 3.3 internal implementation then this task will seem impossible. It is indeed doable but will require a lot of code patching and zero-page fixups.
There are two solutions:
* Relocate Integer Basic (IB) to run from a different address
* Relocate Echo II to run from from a different address
The bad news is that both of these are non-trivial.
The good news is that both of these are indeed doable -- with a lot of elbow grease.
IB is normally located from $E000 - $F7FF.
Relocating IB is probably the easier of the two since there are disassembly listings. Also, there was a relocatable version of Integer Basic+ but I'm not aware if this on Asimov. (FTR I also haven't looked.) I would first try to track this down.
There are two problems:
1. Fixing IB to run from a different address
2. Fixing IB HIMEM ($4C,4D) to use "safe" memory so as to not over-write IB and/or DOS 3.3
3. You also might need to fixup LOMEM / Integer Program Start ($CA, $CB)
The Extended 80 Column Card is AUXMEM. Instead of trying to get IB to run from AUXMEM I would first get it running from main RAM but at a lower address.
Making IB "relocatable" is not easy. But also not impossible. It requires manually patching up all the absolute addresses uses. (See note at end.)
It might be convenient to load IB into main RAM at $7000. Unfortunately this leaves almost a 4K (!) gap from $8800 .. $9600.
i.e. Wastes $E00 bytes.
It is tempting to use $8000 for the start of IB. This is doable but requires telling DOS to use less memory for its file buffers via MAXFILES 2.
Why MAXFILES 2?
IB located at $8000 uses $8000 .. $97FF. This unfortunately overlap's one of DOS 3.3's file buffers by 512 bytes. DOH!
DOS 3.3 file buffers "start" at $9600 because MAXFILE defaults to 3. Each file buffer requires 595 bytes. Here is a table of the lowest address DOS uses for each of the MAXFILES settings:
MAXFILES 3, HIMEM = $9600
MAXFILES 2, HIMEM = $9853
MAXFILES 1, HIMEM = $9AA6
You could change MAXFILES to 2 to move the top of DOS 3.3 file buffers up to leave enough room for IB. You would then need to manually fixup Applesoft and IB zero-page pointers to $8000 so a program's variables don't overwrite the IB code.
NOTE: I say "start" at $9600 but technically DOS 3.3 files buffers start at high RAM and work down.
NOTE: Applesoft HIMEM is zero-page $73, $74. Integer Basic HIMEM is zero-page $4C, $4D, IB SOP is $CA, $CB.
Snippet of BLDFTAB - Build File Tables
283B:68 095 PLA
283C:85 74 096 STA ASHM1+1
283E:85 70 097 STA ASHM2+1
2840:68 098 PLA
2841:85 73 099 STA ASHM1
2843:85 6F 100 STA ASHM2
2845:60 101 RTS
102 ;
103 BFTIB EQU *
2846:68 104 PLA ; SET IB
2847:85 4D 105 STA IBHMEM+1 ; UPPER MEM LIMITS
2849:85 CB 106 STA IBSOP+1
284B:68 107 PLA
284C:85 4C 108 STA IBHMEM
284E:85 CA 109 STA IBSOP
2850:60 110 RTS
Another solution is to relocate the start DOS 3.3 file buffers down. This leaves a gap between the file buffers and the start of DOS 3.3 code at $9D00. You'll probably want to read the comment on the MAXFILES Command Handler. Again this is non-trivial but doable.
http://www.textfiles.com/apple/ANATOMY/cmdmxfil.txt
You'll also want to take a look at this SO question:
https://retrocomputing.stackexchange.com/questions/13137/using-integer-basic-on-apple-ii-plus-without-a-language-card
I would follow-up researching the answer to this interesting answer:
> It was, in fact possible to load Integer BASIC into RAM without the Language Card, and without purchasing a modified variant. Back in the day there was a magazine article (Creative Computing, Byte, Nibble come to mind as likely candidates) detailing how to perform the relocation patch. From then on you were good to go.
TL:DR;
0. Find relocatable version of IB. Use this. Done.
OR:
1. Load Integer Basic at $7000
2. Fixup Integer Basic so it runs at this address
3. Fixup zero-page address for both Applesoft and IB
$4C, $4D = $7000
$6F, $70 = $7000
$73, $74 = $7000
$CA, $CB = $7000
There maybe others?
4. [Optionally] Once that is working, MAXFILES, 2, relocate to IB $8000, perform zero-page fix ups.
5. Move IB to AUXMEM, patch up INT command and FP so they work.
Good luck!
Michael
qkumba
Apr 8, 2021, 3:32:55 PM4/8/21
to
Using option (0), it sounds like the only needed addition is an Applesoft program to BRUN Integer Basic before running the Integer Basic program.
I am Rob
Apr 8, 2021, 3:39:40 PM4/8/21
to
On Wednesday, April 7, 2021 at 8:11:36 PM UTC-6, Jayson Smith wrote:
> My crazy idea the other day, which I have nowhere near the expertise to
> implement, goes as follows. When a disk boots, it runs code that first
> loads this smaller version of Integer into memory on the Extended 80
> Column Card, or complains loudly and aborts if one is not present. Then,
> it patches DOS to hijack the INT command handler/function code. The new
> INT code, instead of looking for Integer in the language card, copies it
> from the 80 column card into its proper place in main memory, then runs
> it. Ideally, this would allow for Applesoft and Integer programs to be
> run at will, since any time Integer was needed, it'd just yoink it from
> the 80 column memory and go on.
>
> Any thoughts? Is this even possible, or am I wildly dreaming?
Michael gave a very good explanation of things. Only have a couple of things to add.
> My crazy idea the other day, which I have nowhere near the expertise to
> implement, goes as follows. When a disk boots, it runs code that first
> loads this smaller version of Integer into memory on the Extended 80
> Column Card, or complains loudly and aborts if one is not present. Then,
> it patches DOS to hijack the INT command handler/function code. The new
> INT code, instead of looking for Integer in the language card, copies it
> from the 80 column card into its proper place in main memory, then runs
> it. Ideally, this would allow for Applesoft and Integer programs to be
> run at will, since any time Integer was needed, it'd just yoink it from
> the 80 column memory and go on.
>
> Any thoughts? Is this even possible, or am I wildly dreaming?
I have already re-assembled Integer Basic to work at $8000. I added a couple of commands to work under Prodos.. The only commands that were removed were the LOAD/SAVE tape commands but should still run under Dos 3.3 as well as Prodos as is.
But if still wanted to use Integer Basic from the language card, it only uses memory from $E000 to $F5FF. Does not use $D000.DFFF or $F600.F7FF. This may allow enough room for the Echo routines.
The disk image I uploaded is called "INT.BAS.PDOS8.2MG". I assume you have the means to get the files from a disk image to your real Apple II?
I am Rob
Apr 8, 2021, 3:54:50 PM4/8/21
to
> Michael gave a very good explanation of things. Only have a couple of things to add.
>
> I have already re-assembled Integer Basic to work at $8000. I added a couple of commands to work under Prodos.. The only commands that were removed were the LOAD/SAVE tape commands but should still run under Dos 3.3 as well as Prodos as is.
>
> But if still wanted to use Integer Basic from the language card, it only uses memory from $E000 to $F5FF. Does not use $D000.DFFF or $F600.F7FF. This may allow enough room for the Echo routines.
>
> The disk image I uploaded is called "INT.BAS.PDOS8.2MG". I assume you have the means to get the files from a disk image to your real Apple II?
1) The disk image is Prodos. Copy files to a Dos 3.3. disk.
2) The links to Dos 3.3 were removed and need to be re-added
3) Space is made using the Prodos buffer command at $BEF5. This call can be removed and changed to just lowering the Himem values at $73.74.
Jayson Smith
Apr 9, 2021, 2:45:21 AM4/9/21
to
Hi,
The good news is that, as I said in my first message, someone else
already did the relocatable Integer Basic probably back in the 80's. I
have no idea about the history of this version, but it was on tons of
talking disks with a mix of Applesoft and Integer programs. Right now
when I want to run an Integer program, I just BRUN INTEGER, then run the
program. My intended use case for this hack would be, for example, a
menu containing all the programs on a disk, wherein Applesoft and
Integer programs can be run willy nilly, without regard to which
language is currently loaded. Were Textalker not an issue, I'd just load
INTBASIC into the language card and be done with it, but I can't do that
with Textalker in the mix.
I'm pretty sure the relocatable Integer Basic I have starts at $8000. It
loads at $0800, then moves most of itself to $8000, then does a JSR
$9000, presumably to initialize something, then modifies several
locations within DOS, then does a JMP $8003, presumably to start the
Integer interpreter. My version can be found at:
http://www.bluegrasspals.com/disks/talking/egames.dsk
To the person who made a ProDOS version of Integer Basic, where can your
disk image be found?
Thanks,
Jayson
The good news is that, as I said in my first message, someone else
already did the relocatable Integer Basic probably back in the 80's. I
have no idea about the history of this version, but it was on tons of
talking disks with a mix of Applesoft and Integer programs. Right now
when I want to run an Integer program, I just BRUN INTEGER, then run the
program. My intended use case for this hack would be, for example, a
menu containing all the programs on a disk, wherein Applesoft and
Integer programs can be run willy nilly, without regard to which
language is currently loaded. Were Textalker not an issue, I'd just load
INTBASIC into the language card and be done with it, but I can't do that
with Textalker in the mix.
I'm pretty sure the relocatable Integer Basic I have starts at $8000. It
loads at $0800, then moves most of itself to $8000, then does a JSR
$9000, presumably to initialize something, then modifies several
locations within DOS, then does a JMP $8003, presumably to start the
Integer interpreter. My version can be found at:
http://www.bluegrasspals.com/disks/talking/egames.dsk
To the person who made a ProDOS version of Integer Basic, where can your
disk image be found?
Thanks,
Jayson
I am Rob
Apr 9, 2021, 10:57:44 AM4/9/21
to
> To the person who made a ProDOS version of Integer Basic, where can your
> disk image be found?
https://mirrors.apple2.org.za/ftp.apple.asimov.net/images/games/collections/Int.Basic.Pdos8.2mg.zip.
> disk image be found?
There is a notes text file on the disk, but here are a few quick notes to get started:
Some new commands that have been programmed into IB are
1) Ctrl-C now exits back to the prompt during a listing. (badly needed)
2) Use & to CATALOG the current directory while in Integer Basic; Note: there is no Prefix command. You will have to exit to Applesoft using FP, change the Prefix, then re-enter IB with the &, then use the & to CATALOG the new directory.
3) FP exits to the applesoft prompt and re-engages Basic.system; use & to return to IB
4) Type LOAD and press RTN to get a prompt to load a file; Once loaded, control will return to the prompt. Type RUN. Note: There is no RUN-FILE command from the IB prompt.
5) IB programs that have disk commands using CHR$(4) cannot be run directly. See below for a work-around.
Here is a work-around to run IB programs that have a CHR$(4) disk command in it:
- exit to Applesoft
- BLOAD the file that is Bloaded from the IB program
- re-enter IB
- load the IB program and list it.
- remove or change all CHR$(4) tokens to CHR$(0) in all lines - this shouldn't hurt the operation of the program
- type RUN - program should run as normal
Additional Notes: IB programs can be created but cannot be saved
Text files cannot be edited or viewed from IB
IB programs with CHR$(4) disk commands will only work using the work-around explained above.
I am not totally sure of your use case with Integer Basic, but just viewing IB file listings can be done from Prodos with an installed TYPE command that can tap into IB's LIST function.
0 new messages