After taking a detour to create an AppleSoft assembly listing, I hit the wall with BASIC.SYSTEM.
Summary: Hacking BASIC.SYSTEM to support Control-D from 6502 code looks like a lot of work; impractical to patch a running copy. Nothing that I would want to do.
My research is based on BASIC.SYSTEM 1.6.
“Beneath Apple ProDOS” by Don Worth and Pieter Lechner
The BASIC.SYSTEM globals page is also documented in the ProDOS8 Technical Reference at http://www.easy68k.com/paulrsm/6502/PDOS8TRM.HTM
Bob Sander-Cederlof's annotated AppleSoft http://www.txbobsc.com/scsc/scdocumentor/index.html
da65 disassembler https://github.com/cc65/cc65
Modified version the cross assembler https://sourceforge.net/projects/dev65/
Apple II emulator for the Mac http://www.virtualii.com
Apple //e Extended Debugging Monitor http://www.jamtronix.com/blog/2007/05/24/apple-extended-debugging-monitor/
Note that I use lowercase symbol names.
Some information about BASIC.SYSTEM -
* Code starts at $9A00.
* Uses AppleSoft TRACE mode. cout never gets Control-D at the beginning of a line.
* Can allocate pages of memory. However, individual pages cannot be freed; all allocated memory can be freed.
* Hooks into AppleSoft execution, doing what it needs before a statement is executed.
* Control-D on output is only intercepted for the PRINT and IF statements.
BASIC.SYSTEM states -
The state value at $BE42 is an index into the address array for output and input handling. The states are:
0 - immediate execution
4 - deferred (in a program execution)
8 - capture a OOS command in the input buffer after Control-D
When a PRINT or IF statement is executed, the output handler to check for Control-D is used. If the next character printed is not Control-D, state 4 is set.
If Control-D is printed, processing includes:
* set inptr ($BE48) to zero
* set state 8.
State 8 finishes when a carriage return is printed. The implementation for doscmd ($BE03) is called. If there is no error, state 4 is set. If there is an error, it exits through the implementation for errout ($BE09).
BRUN under DOS 3.3
I have been away from DOS 3.3 for too long so needed to experiment with some BRUN abuse.
It is possible to BRUN A, which can BRUN B, which can BRUN C. However B cannot return to A due to DOS restoring the stack pointer after BRUN C completes.
It seems to me that getting DOS like Control-D behavior in BASIC.SYSTEM requires many changes due to the use of AppleSoft TRACE mode.
Additionally the desire to convert DOS 3.3 file names into ProDOS compatible file names makes it unlikely to patch a running copy of BASIC.SYSTEM.
One approach would be to recreate a BASIC.SYSTEM source and start rewriting. This is beyond my interests.