Discussion:
ProDOS, non-BASIC apps, and CHR$(4)
(too old to reply)
Steve Nickolas
2017-08-03 06:20:26 UTC
Permalink
Raw Message
As you may be aware, BASIC.SYSTEM only supports CHR$(4) from BASIC apps,
and not from machine language apps. This is the reason a fair number of
machine language apps written for DOS 3.3 do not run under ProDOS.

Some time ago, I proposed "porting" DOS 3.3 to ProDOS, such that low-level
DOS calls were reinterpreted as ProDOS calls, as one way DOS 3.3 programs
could be ported to ProDOS, if they could not be made to run under
BASIC.SYSTEM. I've actually come up with a simpler version of that idea.

Many applications, even those not written in BASIC, only interact with DOS
via the PRINT CHR$(4) route. The idea would be to either rewrite the
interpreter, or create a wedge between the program and BASIC.SYSTEM -
preferably the former but even the latter may work and be easier! - so
that when a program does the equivalent of PRINT CHR$(4);"COMMAND" it
knows to do the right thing. At most, a hook commonly used for regaining
control from the error handler, and the CALL 1002 hook, will need to be
supported.

For a more complete implementation, paths could be assigned to virtual
drives to emulate ,D1 or ,D2 on a hard-disk system.

I suspect that simply supporting this method will be enough for a lot of
eduware.

-uso.
(There is MECC.SYSTEM, but it is a crutch!)
Michael J. Mahon
2017-08-03 07:43:27 UTC
Permalink
Raw Message
Post by Steve Nickolas
As you may be aware, BASIC.SYSTEM only supports CHR$(4) from BASIC apps,
and not from machine language apps. This is the reason a fair number of
machine language apps written for DOS 3.3 do not run under ProDOS.
Some time ago, I proposed "porting" DOS 3.3 to ProDOS, such that low-level
DOS calls were reinterpreted as ProDOS calls, as one way DOS 3.3 programs
could be ported to ProDOS, if they could not be made to run under
BASIC.SYSTEM. I've actually come up with a simpler version of that idea.
Many applications, even those not written in BASIC, only interact with DOS
via the PRINT CHR$(4) route. The idea would be to either rewrite the
interpreter, or create a wedge between the program and BASIC.SYSTEM -
preferably the former but even the latter may work and be easier! - so
that when a program does the equivalent of PRINT CHR$(4);"COMMAND" it
knows to do the right thing. At most, a hook commonly used for regaining
control from the error handler, and the CALL 1002 hook, will need to be
supported.
For a more complete implementation, paths could be assigned to virtual
drives to emulate ,D1 or ,D2 on a hard-disk system.
I suspect that simply supporting this method will be enough for a lot of
eduware.
-uso.
(There is MECC.SYSTEM, but it is a crutch!)
The preferred method of executing most BASIC.SYSTEM commands from assembly
language programs is to copy them to $200 and call DOSCMD at $BE03.

I've found it useful to set BASIC.SYSTEM's state (BSSTATE = $BE42) to $FF
before the call. (I also save and restore the previous value of BSSTATE.)
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Steve Nickolas
2017-08-03 07:56:42 UTC
Permalink
Raw Message
Post by Michael J. Mahon
The preferred method of executing most BASIC.SYSTEM commands from assembly
language programs is to copy them to $200 and call DOSCMD at $BE03.
I've found it useful to set BASIC.SYSTEM's state (BSSTATE = $BE42) to $FF
before the call. (I also save and restore the previous value of BSSTATE.)
While that won't help for error handling, it will probably help the usual
case... a wedge, which catches i/o, and does this. Might be enough for a
simpler program.

-uso.
Michael J. Mahon
2017-08-03 17:22:43 UTC
Permalink
Raw Message
Post by Steve Nickolas
Post by Michael J. Mahon
The preferred method of executing most BASIC.SYSTEM commands from assembly
language programs is to copy them to $200 and call DOSCMD at $BE03.
I've found it useful to set BASIC.SYSTEM's state (BSSTATE = $BE42) to $FF
before the call. (I also save and restore the previous value of BSSTATE.)
While that won't help for error handling, it will probably help the usual
case... a wedge, which catches i/o, and does this. Might be enough for a
simpler program.
-uso.
Not sure what you mean regarding error handling, but DOSCMD sets Carry if
an error occurred and returns the error code in A.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Steve Nickolas
2017-08-03 08:32:39 UTC
Permalink
Raw Message
Post by Michael J. Mahon
The preferred method of executing most BASIC.SYSTEM commands from assembly
language programs is to copy them to $200 and call DOSCMD at $BE03.
I've found it useful to set BASIC.SYSTEM's state (BSSTATE = $BE42) to $FF
before the call. (I also save and restore the previous value of BSSTATE.)
This got me thinking: Could BASIC.SYSTEM be stripped down, and then a DOS
3.3-style CHR$(4) handler attached to it?

-uso.
Michael J. Mahon
2017-08-03 17:22:43 UTC
Permalink
Raw Message
Post by Steve Nickolas
Post by Michael J. Mahon
The preferred method of executing most BASIC.SYSTEM commands from assembly
language programs is to copy them to $200 and call DOSCMD at $BE03.
I've found it useful to set BASIC.SYSTEM's state (BSSTATE = $BE42) to $FF
before the call. (I also save and restore the previous value of BSSTATE.)
This got me thinking: Could BASIC.SYSTEM be stripped down, and then a DOS
3.3-style CHR$(4) handler attached to it?
-uso.
Or simply replaced with a "BASIC.SYSTEM" that implements the DOS commands
rather than the ProDOS commands.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
groink_hi
2017-08-03 20:09:53 UTC
Permalink
Raw Message
Post by Michael J. Mahon
Or simply replaced with a "BASIC.SYSTEM" that implements the DOS commands
rather than the ProDOS commands.
This would be the route I would take. You basically do not want to change a single bit of the original program, in order for it to run in a later version of an operating environment. You want total seamless integration. Replacing BASIC.SYSTEM with one that can capture and interpret CHR$(4) and other DOS 3.x codes would be the way to go.
Antoine Vignau
2017-08-03 20:53:56 UTC
Permalink
Raw Message
That is a good idea but that does not solve the length of file names between DOS 3.3 and ProDOS. Solutions exist...
Steve Nickolas
2017-08-03 23:03:37 UTC
Permalink
Raw Message
Post by Antoine Vignau
That is a good idea but that does not solve the length of file names
between DOS 3.3 and ProDOS. Solutions exist...
PDOS RDOS does translation. If there's enough free space from gutting the
RWTS and replacing it with a ProDOS translator, it might be possible to do
the same thing here. Illegal characters would be mapped to dots and base
filenames truncated to 15 characters - this transparent to the
application.

There is a table of vectors in DOS 3.3. I believe a lot of programs alter
this table to capture DOS errors. Obviously that isn't going to work with
BASIC.SYSTEM - you'd be overwriting a random word and might cause the
thing to blow up.

-uso.
Michael J. Mahon
2017-08-04 02:44:54 UTC
Permalink
Raw Message
Post by Steve Nickolas
Post by Antoine Vignau
That is a good idea but that does not solve the length of file names
between DOS 3.3 and ProDOS. Solutions exist...
PDOS RDOS does translation. If there's enough free space from gutting the
RWTS and replacing it with a ProDOS translator, it might be possible to do
the same thing here. Illegal characters would be mapped to dots and base
filenames truncated to 15 characters - this transparent to the
application.
There is a table of vectors in DOS 3.3. I believe a lot of programs alter
this table to capture DOS errors. Obviously that isn't going to work with
BASIC.SYSTEM - you'd be overwriting a random word and might cause the
thing to blow up.
-uso.
In that case, DOS has actually been made a part of the application.

A clean API is necessary for a clean emulation.

Or, perhaps, 97% of DOS apps use only a very narrow interface to DOS
(including the vectors) that could be emulated moderately cleanly.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Steve Nickolas
2017-08-04 03:04:39 UTC
Permalink
Raw Message
Post by Michael J. Mahon
Post by Steve Nickolas
Post by Antoine Vignau
That is a good idea but that does not solve the length of file names
between DOS 3.3 and ProDOS. Solutions exist...
PDOS RDOS does translation. If there's enough free space from gutting the
RWTS and replacing it with a ProDOS translator, it might be possible to do
the same thing here. Illegal characters would be mapped to dots and base
filenames truncated to 15 characters - this transparent to the
application.
There is a table of vectors in DOS 3.3. I believe a lot of programs alter
this table to capture DOS errors. Obviously that isn't going to work with
BASIC.SYSTEM - you'd be overwriting a random word and might cause the
thing to blow up.
-uso.
In that case, DOS has actually been made a part of the application.
A clean API is necessary for a clean emulation.
Or, perhaps, 97% of DOS apps use only a very narrow interface to DOS
(including the vectors) that could be emulated moderately cleanly.
That was my idea.

The vector table, I/O hooks (including CALL 1002) and CHR$(4) seem to be
enough for many applications.

The following is probably well known here:

The I/O hooks are AA53-AA56 (the function to properly set these is JMP'd
to from 03EA, hence CALL 1002.

The vector table is located at 9D56:

chaintry: .word $A4FC ; "Addr of CHAIN entry point to BASIC" runfprom
runtry: .word $A4FC ; "Addr of BASIC's RUN command" runfprom
adbscerr: .word $D865 ; "Addr of BASIC's error handler"
tocldvec: .word $E000 ; "Addr of BASIC's cold start rtn"
towrmvec: .word $D43C ; "Addr of BASIC's warm start rtn"
rlocntry: .word $D4F2 ; "Addr of rtn that enables pgms to relocate"

I suspect ADBSCERR is frequently rejigged.

-uso.
Steve Nickolas
2017-08-06 07:39:34 UTC
Permalink
Raw Message
Replying to myself although I know it's daft.

So let me go into detail about how this would work at its most
BASIC...er...basic...

1. I/O would have to be vectored the usual way. Does anyone know if any
programs are idiotic enough to poke the hooks in DOS RAM, as opposed to
setting them in zero page and calling 1002 ($03EA)? If not, then the
actual addresses might not need to be kept.

2. The usual means of entry for DOS commands, i.e., from the command line,
and by using PRINT CHR$(4), would need to be supported, and the common DOS
commands need at least token support.

3. The 9D56 vector table needs to be supported since some of the values
are commonly edited by programs.

4. At least anything sane which is mentioned in Peeks, Pokes and Pointers
should probably be supported if reasonable. I'm sure that at least the
BLOAD words (AA60-AA61, AA72-AA73) and the slot (AA6A) and drive (AA68)
values are commonly referenced.

5. We can assume FPBASIC and remove support for INTBASIC (erroring if
INTBASIC is found).

6. If there's room I might see whether it is possible to "flatten"
filenames to ProDOS-compatible ones; to add commands like PREFIX and BYE;
and to allow a path to be linked to a pseudovolume.

-uso.
r***@gmail.com
2017-08-06 19:09:30 UTC
Permalink
Raw Message
Hi Steve,

Before getting too deeply into the details, a bigger picture would be helpful.

What titles do you have in mind?

Do any of these require 64K? Language card support would be tricky.

What about AppleTalk compatibility? (Not at all likely, but worth mentioning.) This has a bunch of restrictions.

Running DOS code under ProDOS also needs to consider:

* ProDOS file names are only shorter, the naming is considerably more strict than DOS
* Reading the catalog track is going to have problems
* Binary files are stored differently

IIRC, the requirement for MECC ProDOS products was 128K of RAM. Early on I called it PigDOS. (Losing the language card was a big deal.)
Steve Nickolas
2017-08-06 19:49:05 UTC
Permalink
Raw Message
Post by r***@gmail.com
Hi Steve,
Before getting too deeply into the details, a bigger picture would be helpful.
What titles do you have in mind?
Do any of these require 64K? Language card support would be tricky.
I suspect most of these types of programs, that would work with this
method, are 48K apps. Which is key; if it needs more than that it's going
to clash with ProDOS anyway.

<snip>
Post by r***@gmail.com
* ProDOS file names are only shorter, the naming is considerably more strict than DOS
On-the-fly conversion of illegal filenames would help with this, if
there's room to do so (PDOS RDOS does this).
Post by r***@gmail.com
* Reading the catalog track is going to have problems
* Binary files are stored differently
If a program is only using the higher level access to DOS, then these are
going to be irrelevant. It seems to be rare they do a low-level catalog
read, and if they're BLOADing, then how the data is stored isn't going to
make a difference so long as they get the same data.
Post by r***@gmail.com
IIRC, the requirement for MECC ProDOS products was 128K of RAM. Early on
I called it PigDOS. (Losing the language card was a big deal.)
And DOS 3.3 stuff would vary between 48-64K, a few older programs worked
in 32 and a couple needed 128. Not too many of these from MECC would
work, but a few others from Methods and Solutions or DLM or Random House
might.

-uso.
Michael 'AppleWin Debugger Dev'
2017-08-17 21:24:29 UTC
Permalink
Raw Message
The relevant DOS 3.3 source code in question:

058 ;
059 ;NON-RELOCATING ADRS
060 ;
061 IBASVT EQU *
1D56:36 E8 062 CHAIN DW IBCHN
1D58:E5 24 063 RUN DW IBRUN
1D5A:E3 E3 064 BREAK DW IBBRK
1D5C:00 E0 065 GO DW IBGO
1D5E:03 E0 066 CONT DW IBCONT ; BASIC CONT ENTRY POINT
1D60:00 00 067 ASEQ DW 0


1E6B:4C 51 28 217 JMP MVCSW ; $3EA: Set CIN/COUT to DOS

112 ;
113 ; MVISW - MOVE INPUT SWITCH
114 ;
115 MVCSW EQU *
2851:A5 39 116 LDA INSW+1
2853:CD 03 1D 117 CMP CINA+1 ; === Page 6 ===
2856:F0 12 118 BEQ MVOSW
2858:8D 56 2A 119 STA SVINS+1
285B:A5 38 120 LDA INSW ; SAVE CHAR IN SWITCH
285D:8D 55 2A 121 STA SVINS
122 ;
2860:AD 02 1D 123 LDA CINA ; SET DFB CHAR IN ADR
2863:85 38 124 STA INSW
2865:AD 03 1D 125 LDA CINA+1
2868:85 39 126 STA INSW+1
127 ;
128 ;
129 ; MVOSW - MOVE OUTPUT SWITCH
130 ;
131 MVOSW EQU *
286A:A5 37 132 LDA OUTSW+1
286C:CD 05 1D 133 CMP COUTA+1
286F:F0 12 134 BEQ MVSRTN
2871:8D 54 2A 135 STA SVOUTS+1
2874:A5 36 136 LDA OUTSW ; SAVE CHAR OUT SWITCH
2876:8D 53 2A 137 STA SVOUTS
138 ;
2879:AD 04 1D 139 LDA COUTA ; SET DFB CHAR OUT ADR
287C:85 36 140 STA OUTSW
287E:AD 05 1D 141 LDA COUTA+1
2881:85 37 142 STA OUTSW+1
143 MVSRTN EQU *
2883:60 144 RTS
Michael J. Mahon
2017-08-04 02:44:53 UTC
Permalink
Raw Message
Post by Antoine Vignau
That is a good idea but that does not solve the length of file names
between DOS 3.3 and ProDOS. Solutions exist...
It could. The ProDOS filename could simply be a tag for a separate DOS
filename table on the disk.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
r***@gmail.com
2017-08-12 01:56:26 UTC
Permalink
Raw Message
If 48K is the target and Control-D the only interface to DOS, I figured that BASIC.SYSTEM already does most of the heavy lifting.

So I started digging into BASIC.SYSTEM. I expect this to end badly.

Some progress was made on the Control-D issue, as long as the CALL is in a running program. I tested on the newest and oldest copies of BASIC.SYSTEM that I have around.

100 HOME
110 ?"BASIC.SYSTEM only enables Ctrl-D for"
120 ?"certain tokens."
130 ?
140 ?"This program patches BASIC.SYSTEM in"
150 ?"memory to allow a CALLed routine in a"
160 ?"RUNning program (not in immediate mode)"
170 ?"to print Ctrl-D to run a command."
180 ?
200 IF PEEK(978)<>190 THEN ?"Probably not running BASIC.SYSTEM":?
210 FOR C=47200 TO 47359:REM$B860 to $B8FF
220 IF PEEK(C-1)=139 AND PEEK(C+1)=141 THEN 300:REM$8B and $8D
230 NEXT:?"Sorry, did not find tokens":END
300 REMThe CALL token is 140 $8C, replace its routine with PRINT 186 $BA
310 X=PEEK(C):P=PEEK(C+46)
320 IF X=P THEN ?"Already patched":END
330 POKE C,P:?"Patched"

The filename problem is really quite ugly, since there are two major components to the problem:

* The running code, and
* How to rename the files when copying from DOS to ProDOS

I am beginning to think that rename in the conversion is actually the harder problem.
r***@gmail.com
2017-08-12 03:03:26 UTC
Permalink
Raw Message
Post by r***@gmail.com
If 48K is the target and Control-D the only interface to DOS, I figured that BASIC.SYSTEM already does most of the heavy lifting.
So I started digging into BASIC.SYSTEM. I expect this to end badly.
Some progress was made on the Control-D issue, as long as the CALL is in a running program. I tested on the newest and oldest copies of BASIC.SYSTEM that I have around.
The first disk I tried was Minus Mission, which remarkably doesn't need any filename conversion.

However it needs BRUN to support Control-D, so this didn't get very far. *Sigh*
Antoine Vignau
2017-08-12 03:03:50 UTC
Permalink
Raw Message
Which version of the Basic interpreter did you patch?
Steve Nickolas
2017-08-12 03:10:30 UTC
Permalink
Raw Message
Post by r***@gmail.com
If 48K is the target and Control-D the only interface to DOS, I figured that BASIC.SYSTEM already does most of the heavy lifting.
So I started digging into BASIC.SYSTEM. I expect this to end badly.
Some progress was made on the Control-D issue, as long as the CALL is in a running program. I tested on the newest and oldest copies of BASIC.SYSTEM that I have around.
100 HOME
110 ?"BASIC.SYSTEM only enables Ctrl-D for"
120 ?"certain tokens."
130 ?
140 ?"This program patches BASIC.SYSTEM in"
150 ?"memory to allow a CALLed routine in a"
160 ?"RUNning program (not in immediate mode)"
170 ?"to print Ctrl-D to run a command."
180 ?
200 IF PEEK(978)<>190 THEN ?"Probably not running BASIC.SYSTEM":?
210 FOR C=47200 TO 47359:REM$B860 to $B8FF
220 IF PEEK(C-1)=139 AND PEEK(C+1)=141 THEN 300:REM$8B and $8D
230 NEXT:?"Sorry, did not find tokens":END
300 REMThe CALL token is 140 $8C, replace its routine with PRINT 186 $BA
310 X=PEEK(C):P=PEEK(C+46)
320 IF X=P THEN ?"Already patched":END
330 POKE C,P:?"Patched"
* The running code, and
* How to rename the files when copying from DOS to ProDOS
I am beginning to think that rename in the conversion is actually the harder problem.
Binary-patching can take care of that easily enough.

The other thing is that there are two vector tables (the mirror of the i/o
table, AA53-AA56, and the BASIC vector table, 9D56-9D61 (specifically the
word at 9D5A, used to take over error handling), which are commonly
patched even by stuff that otherwise only uses ? chr$(4).

-uso.
r***@gmail.com
2017-08-20 17:23:03 UTC
Permalink
Raw Message
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.

References:
“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

Software Tools:
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.


Conclusions

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.
g***@sasktel.net
2017-08-20 23:36:41 UTC
Permalink
Raw Message
Post by r***@gmail.com
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 -
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.
* 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.
Conclusions
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.
Sounds to me the easiest approach would be to tap into the CHRGET routine and when a CTRL-D or CHR$(4) or VAR$ (with a value of 4) is encountered, copy the text in between the quotes into the keyboard buffer ($200). If a string variable is encountered, then find the variable and copy its string to the keyboard buffer. If an FP or Integer variable is found, then convert its value to a ascii equivalent which is stored at $100, and copy its contents to the keyboard buffer. This would all have to be handled by your routine.

Once an end-of-statement is encountered, either a colon or end-of-line, then do the JSR $BE03. When control is returned to your tapped in routine, then load a colon into the accumulator and send that to Basic.system to be processed. Basic.system would be none the wiser that anything external happened.
Loading...