Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #4961 > unrolled thread

BASIC Commands Broken After Running BIN Program

Back to article view | Back to comp.sys.apple2.programmer

Contents

  BASIC Commands Broken After Running BIN Program Bill Chatfield <billchatfield1@gmail.com> - 2019-01-25 21:01 -0800
    Re: BASIC Commands Broken After Running BIN Program kegs@provalid.com (Kent Dickey) - 2019-01-25 23:48 -0600
      Re: BASIC Commands Broken After Running BIN Program Antoine Vignau <antoine.vignau@laposte.net> - 2019-01-25 22:08 -0800
        Re: BASIC Commands Broken After Running BIN Program Bill Chatfield <billchatfield1@gmail.com> - 2019-01-25 23:04 -0800
          Re: BASIC Commands Broken After Running BIN Program Antoine Vignau <antoine.vignau@laposte.net> - 2019-01-25 23:31 -0800
      Re: BASIC Commands Broken After Running BIN Program Bill Chatfield <billchatfield1@gmail.com> - 2019-01-25 23:03 -0800
        Re: BASIC Commands Broken After Running BIN Program gids.rs@sasktel.net - 2019-01-26 09:33 -0800
          Re: BASIC Commands Broken After Running BIN Program Bill Chatfield <billchatfield1@gmail.com> - 2019-01-26 10:26 -0800
            Re: BASIC Commands Broken After Running BIN Program Marco Verpelli <mverpelli@libero.it> - 2019-01-26 10:52 -0800
            Re: BASIC Commands Broken After Running BIN Program gids.rs@sasktel.net - 2019-01-26 11:30 -0800
              Re: BASIC Commands Broken After Running BIN Program Antoine Vignau <antoine.vignau@laposte.net> - 2019-01-26 11:34 -0800
                Re: BASIC Commands Broken After Running BIN Program Bill Chatfield <billchatfield1@gmail.com> - 2019-01-26 13:46 -0800
                  Re: BASIC Commands Broken After Running BIN Program gids.rs@sasktel.net - 2019-01-26 14:50 -0800
                    Re: BASIC Commands Broken After Running BIN Program Bill Chatfield <billchatfield1@gmail.com> - 2019-01-27 15:04 -0800
                      Re: BASIC Commands Broken After Running BIN Program gids.rs@sasktel.net - 2019-01-27 17:44 -0800
                      Re: BASIC Commands Broken After Running BIN Program Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2019-01-27 21:41 -0600
                        Re: BASIC Commands Broken After Running BIN Program Bill Chatfield <billchatfield1@gmail.com> - 2019-01-30 14:23 -0800
                        Re: BASIC Commands Broken After Running BIN Program Michael Pohoreski <michael.pohoreski@gmail.com> - 2019-01-31 23:05 -0800
                          Re: BASIC Commands Broken After Running BIN Program Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2019-02-02 13:15 -0600
                Re: BASIC Commands Broken After Running BIN Program Bill Chatfield <billchatfield1@gmail.com> - 2019-01-27 15:38 -0800
      Re: BASIC Commands Broken After Running BIN Program Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2019-01-26 14:04 -0600
    Re: BASIC Commands Broken After Running BIN Program Du Hast <duhast6377@gmail.com> - 2019-01-28 16:54 -0800

Page 1 of 2  [1] 2  Next page →

#4961 — BASIC Commands Broken After Running BIN Program

I have a BIN program that loads at $800, written with Merlin32. It is 405 bytes long. After I run it from inside BASIC.SYSTEM, commands like NEW return a SYNTAX ERROR. It's not long enough to overwrite anything in BASIC.SYSTEM which should start at $2000. It calls MLI OPEN and CLOSE. No errors are returned. What could be happening that causes the BASIC commands not to work after running my program?

The program is here if you want to look at it: https://github.com/gungwald/prodos-more/more.s

But, I'm just looking for ideas for things that I could look for, not for someone to fix it for me.

Thanks!

[toc] | [next] | [standalone]

#4962

In article <62f71a77-f980-4681-b040-b33d46647c15@googlegroups.com>,
Bill Chatfield  <billchatfield1@gmail.com> wrote:
>I have a BIN program that loads at $800, written with Merlin32. It is
>405 bytes long. After I run it from inside BASIC.SYSTEM, commands like
>NEW return a SYNTAX ERROR. It's not long enough to overwrite anything in
>BASIC.SYSTEM which should start at $2000. It calls MLI OPEN and CLOSE.
>No errors are returned. What could be happening that causes the BASIC
>commands not to work after running my program?
>
>The program is here if you want to look at it:
>https://github.com/gungwald/prodos-more/more.s
>
>But, I'm just looking for ideas for things that I could look for, not
>for someone to fix it for me.
>
>Thanks!

Applesoft really wants a 0 at $800.  I suspect

poke 2048,0

fixes everything.

I think the ProDOS command FP should fix things, too.

Kent

[toc] | [prev] | [next] | [standalone]

#4963

The link is KO but I found it.
Did you try assembling at $1000?

Use STR for filename ;-)

Antoine

[toc] | [prev] | [next] | [standalone]

#4965

On Saturday, January 26, 2019 at 1:08:03 AM UTC-5, Antoine Vignau wrote:
> The link is KO but I found it.
> Did you try assembling at $1000?
> 
> Use STR for filename ;-)
> 
> Antoine

Sorry the URL is bad. Should be: https://github.com/gungwald/prodos-more

Yes I'll switch to STR for filename. Good point. Thanks.

[toc] | [prev] | [next] | [standalone]

#4966

Basic pgms are loaded, by default, at $801. Your pgm will write over the one in memory,
av

[toc] | [prev] | [next] | [standalone]

#4964

On Saturday, January 26, 2019 at 12:48:19 AM UTC-5, Kent Dickey wrote:
> In article <62f71a77-f980-4681-b040-b33d46647c15@googlegroups.com>,
> Bill Chatfield  <billchatfield1@gmail.com> wrote:
> >I have a BIN program that loads at $800, written with Merlin32. It is
> >405 bytes long. After I run it from inside BASIC.SYSTEM, commands like
> >NEW return a SYNTAX ERROR. It's not long enough to overwrite anything in
> >BASIC.SYSTEM which should start at $2000. It calls MLI OPEN and CLOSE.
> >No errors are returned. What could be happening that causes the BASIC
> >commands not to work after running my program?
> >
> >The program is here if you want to look at it:
> >https://github.com/gungwald/prodos-more/more.s
> >
> >But, I'm just looking for ideas for things that I could look for, not
> >for someone to fix it for me.
> >
> >Thanks!
> 
> Applesoft really wants a 0 at $800.  I suspect
> 
> poke 2048,0
> 
> fixes everything.
> 
> I think the ProDOS command FP should fix things, too.
> 
> Kent

Moving it to $803 does seem to fix the problem. Thanks! Memory maps seem to imply that it is ok to use $800. But, $803 is the default for cc65. So, makes sense.

But, now it is corrupting any Applesoft program in memory. Any ideas about that?

[toc] | [prev] | [next] | [standalone]

#4967

On Saturday, January 26, 2019 at 1:03:35 AM UTC-6, Bill Chatfield wrote:
> On Saturday, January 26, 2019 at 12:48:19 AM UTC-5, Kent Dickey wrote:
> > In article <62f71a77-f980-4681-b040-b33d46647c15@googlegroups.com>,
> > Bill Chatfield  <bill> wrote:
> > >I have a BIN program that loads at $800, written with Merlin32. It is
> > >405 bytes long. After I run it from inside BASIC.SYSTEM, commands like
> > >NEW return a SYNTAX ERROR. It's not long enough to overwrite anything in
> > >BASIC.SYSTEM which should start at $2000. It calls MLI OPEN and CLOSE.
> > >No errors are returned. What could be happening that causes the BASIC
> > >commands not to work after running my program?
> > >
> > >The program is here if you want to look at it:
> > >https://github.com/gungwald/prodos-more/more.s
> > >
> > >But, I'm just looking for ideas for things that I could look for, not
> > >for someone to fix it for me.
> > >
> > >Thanks!
> > 
> > Applesoft really wants a 0 at $800.  I suspect
> > 
> > poke 2048,0
> > 
> > fixes everything.
> > 
> > I think the ProDOS command FP should fix things, too.
> > 
> > Kent
> 
> Moving it to $803 does seem to fix the problem. Thanks! Memory maps seem to imply that it is ok to use $800. But, $803 is the default for cc65. So, makes sense.
> 
> But, now it is corrupting any Applesoft program in memory. Any ideas about that?


If you insist on having the binary program at $800 but still want to use applesoft programs, then you can change the default address where your applesoft program loads by poking a couple of memory locations.  The two most popular memory locations are $4000 (decimal 16384) and $6000 (decimal 24576).  From the prompt, poke these values.

]poke 104,64: poke 16384,0: REM $40 (decimal 64) loads applesoft program at $4000
]poke 104,96: poke 24576,0: REM $60 (decimal 96) loads applesoft program at $6000

Just remember to return the default address to $800 (decimal 2048) if using higher memory for binary programs.

]poke 104,8: poke 2048,0

[toc] | [prev] | [next] | [standalone]

#4968

On Saturday, January 26, 2019 at 12:33:42 PM UTC-5, gid...@sasktel.net wrote:

> If you insist on having the binary program at $800 but still want to use applesoft programs, then you can change the default address where your applesoft program loads by poking a couple of memory locations.  The two most popular memory locations are $4000 (decimal 16384) and $6000 (decimal 24576).  From the prompt, poke these values.
> 
> ]poke 104,64: poke 16384,0: REM $40 (decimal 64) loads applesoft program at $4000
> ]poke 104,96: poke 24576,0: REM $60 (decimal 96) loads applesoft program at $6000
> 
> Just remember to return the default address to $800 (decimal 2048) if using higher memory for binary programs.
> 
> ]poke 104,8: poke 2048,0

Good info. Thanks. By loading it at $800 I was just trying to put it into the first free location in memory. The ProDOS memory map shows that location as free. And it is "free" in terms of ProDOS, but not in terms of BASIC.

My goal is to create a command that you can use while running BASIC.SYSTEM. That being the "shell" most people use on an Apple II.

So in my case I don't want to break anything in ProDOS or BASIC.SYSTEM. Where would be the best location to load the program to accomplish that?

[toc] | [prev] | [next] | [standalone]

#4969

> My goal is to create a command that you can use while running BASIC.SYSTEM. That being the "shell" most people use on an Apple II.

If you have not already done, read the ProDOS technical manual.
Appendix A.3.2 give an example on how to add commands to BASIC.SYSTEM

Marco

[toc] | [prev] | [next] | [standalone]

#4970

On Saturday, January 26, 2019 at 12:26:51 PM UTC-6, Bill Chatfield wrote:
> On Saturday, January 26, 2019 at 12:33:42 PM UTC-5, gid...@sasktel.net wrote:
> 
> > If you insist on having the binary program at $800 but still want to use applesoft programs, then you can change the default address where your applesoft program loads by poking a couple of memory locations.  The two most popular memory locations are $4000 (decimal 16384) and $6000 (decimal 24576).  From the prompt, poke these values.
> > 
> > ]poke 104,64: poke 16384,0: REM $40 (decimal 64) loads applesoft program at $4000
> > ]poke 104,96: poke 24576,0: REM $60 (decimal 96) loads applesoft program at $6000
> > 
> > Just remember to return the default address to $800 (decimal 2048) if using higher memory for binary programs.
> > 
> > ]poke 104,8: poke 2048,0
> 
> Good info. Thanks. By loading it at $800 I was just trying to put it into the first free location in memory. The ProDOS memory map shows that location as free. And it is "free" in terms of ProDOS, but not in terms of BASIC.
> 
> My goal is to create a command that you can use while running BASIC.SYSTEM. That being the "shell" most people use on an Apple II.
> 
> So in my case I don't want to break anything in ProDOS or BASIC.SYSTEM. Where would be the best location to load the program to accomplish that?


Creating commands that work with applesoft programs requires a pretty extensive knowledge on how applesoft programs work in memory.

I recommend downloading Nibble magazines and study their source listings.  And there already are a lot of commands out there and you can study their code to see how they did it.  Look for ProCmd on Asimov.

[toc] | [prev] | [next] | [standalone]

#4971

Keep it simple:
- either put your code at $9000,
- follow Marco's advice,
- then gid's one (ah, signature)

Antoine

[toc] | [prev] | [next] | [standalone]

#4973

On Saturday, January 26, 2019 at 2:34:47 PM UTC-5, Antoine Vignau wrote:
> Keep it simple:
> - either put your code at $9000,
> - follow Marco's advice,
> - then gid's one (ah, signature)
> 
> Antoine

I think loading it at $9000 is what I want to do for now. But thanks Marco and gid. Those are both good ideas. I have looked at those options and may eventually do that. But, those solutions require an extra setup step to load the extended commands and attach them to BASIC.SYSTEM. Then for the commands to work, that extra setup step has to be properly configured to run every time BASIC.SYSTEM is loaded on every startup disk you want to use them on. It's hard enough just to create a boot disk with PRODOS and BASIC.SYSTEM on it. It's hard just to copy a file since there is no copy command. I know there are copy commands out there but they're not in the default command set so it takes extra work to make them available.

For now, I want a free-standing command that doesn't require BASIC.SYSTEM, but can also run in the presence of BASIC.SYSTEM without screwing it up. If I can create a loading mechanism that can also optionally attach the command to BASIC.SYSTEM as per your suggestions, I'll probably go for that next.

Basically, I want to create something that works they way you expect it to regardless of how it is started. So it will probably have to have separate startup and end code for each scenario. These are my target startup scenarios so far:

1. The PRODOS program that allows you to select the next SYSTEM program to run.
   I forget what this is called.
2. Inside BASIC.SYSTEM as a free-standing program.
3. Inside BASIC.SYSTEM as an extended command.
4. From inside other shells like davex.

Of course, this might not be possible. I'm just having fun exploring the possibilities...  :-)

[toc] | [prev] | [next] | [standalone]

#4974

On Saturday, January 26, 2019 at 3:46:16 PM UTC-6, Bill Chatfield wrote:
> On Saturday, January 26, 2019 at 2:34:47 PM UTC-5, Antoine Vignau wrote:
> > Keep it simple:
> > - either put your code at $9000,
> > - follow Marco's advice,
> > - then gid's one (ah, signature)
> > 
> > Antoine
> 
> I think loading it at $9000 is what I want to do for now. But thanks Marco and gid. Those are both good ideas. I have looked at those options and may eventually do that. But, those solutions require an extra setup step to load the extended commands and attach them to BASIC.SYSTEM. Then for the commands to work, that extra setup step has to be properly configured to run every time BASIC.SYSTEM is loaded on every startup disk you want to use them on. It's hard enough just to create a boot disk with PRODOS and BASIC.SYSTEM on it. It's hard just to copy a file since there is no copy command. I know there are copy commands out there but they're not in the default command set so it takes extra work to make them available.
> 
> For now, I want a free-standing command that doesn't require BASIC.SYSTEM, but can also run in the presence of BASIC.SYSTEM without screwing it up. If I can create a loading mechanism that can also optionally attach the command to BASIC.SYSTEM as per your suggestions, I'll probably go for that next.
> 
> Basically, I want to create something that works they way you expect it to regardless of how it is started. So it will probably have to have separate startup and end code for each scenario. These are my target startup scenarios so far:
> 
> 1. The PRODOS program that allows you to select the next SYSTEM program to run.
>    I forget what this is called.
> 2. Inside BASIC.SYSTEM as a free-standing program.
> 3. Inside BASIC.SYSTEM as an extended command.
> 4. From inside other shells like davex.
> 
> Of course, this might not be possible. I'm just having fun exploring the possibilities...  :-)


1.  BYE is built in to Prodos and is used to select the next system program and does not take up any extra memory.  Just type BYE at the prompt

2. the main reasons this is not popular is because the command has to be installed before an applesoft program is loaded into memory or risk trashing the applesoft program or its data

3. check out ProCMD, it installs all commands inside Basic.system and is protected from Applesoft programs, but should still be installed before running any applesoft programs.  Over 75 commands are available


An alternate solution is to collect and use the System applications to do the job, using the BYE command, then return to Basic.system.  Most major system applications automatically return to the internal BYE program and you can either return to the Basic environment or select another system program to do another job.

On a side note, I also wanted all commands to operate while working in Basic.  There was no method that I could find so I created a command-line structure that makes all commands external.  Meaning ... I stripped out all of Basic.systems commands such as LOAD, BLOAD, SAVE, BSAVE, CATALOG, STORE, RESTORE etc, and made them into disk commands.  The extra space that was saved with the internal command removal is then reserved and used to launch one command at a time.  Some pretty large applications can be made into commands and loaded into this protected area.  Some of my more noteable commands have a bit of power, one of my favorite being FIND "program" (uses wild card characters and finds by type, date, prefix and suffix of a filename and can sort files by filename, type or size)

You probably won't find programs with this much power and will have to write your own.

There is also a command installer that installs multiple commands into Aux memory if you have a 128kb IIe/IIGS, and there is a control panel program with quite a few commands that can be accessed with Ctrl-OA-ESC for use only on a IIGS.  I believe it is called Soft Witch or some such.

I can't point you to any disk images that contain these programs right now, but best you go to Asimov and check out the programs that are there.

[toc] | [prev] | [next] | [standalone]

#4975

Thanks everyone for the great information. I have another related question. My "online" program (https://github.com/gungwald/online) is setup to load at $2000 and the type is SYS. But I am able to run it inside BASIC.SYSTEM, which should also be loaded at $2000. I didn't realize what I was doing when I set it up that way. But it doesn't seem to cause any corruption of the in memory BASIC.SYSTEM. How is this possible? Am I just getting lucky?

[toc] | [prev] | [next] | [standalone]

#4977

On Sunday, January 27, 2019 at 5:04:44 PM UTC-6, Bill Chatfield wrote:
> Thanks everyone for the great information. I have another related question. My "online" program (https://github.com/gungwald/online) is setup to load at $2000 and the type is SYS. But I am able to run it inside BASIC.SYSTEM, which should also be loaded at $2000. I didn't realize what I was doing when I set it up that way. But it doesn't seem to cause any corruption of the in memory BASIC.SYSTEM. How is this possible? Am I just getting lucky?


No, not luck.  Just ignorance :)

Normally a system file will remove Basic.system from memory and use all available lower 48 kb of memory, except page $BF00.BFFF, which is reserved for Prodos usage.

As long as your system file is not too large and doesn't tromp on Basic.system or remove Basic.system from memory, it is in essence no different than a binary file at the same location.  The majority of system files exit by calling the Prodos program selector (BYE program).  This is the safest method to ensure that a fresh fresh copy of Basic.system is loaded into memory.  Also, Basic.system uses zero page memory locations that if get used in your system program, can crash Basic.system.

You already found out that the NEW command malfunctioned in your original post when $800 was non-zero.  A fresh install of Basic.system will ensure this value is correct and any memory it uses are reset to their default values.

[toc] | [prev] | [next] | [standalone]

#4978

On 27/01/2019 17.04, Bill Chatfield wrote:
> Thanks everyone for the great information. I have another related question. My "online" program (https://github.com/gungwald/online) is setup to load at $2000 and the type is SYS. But I am able to run it inside BASIC.SYSTEM, which should also be loaded at $2000. I didn't realize what I was doing when I set it up that way. But it doesn't seem to cause any corruption of the in memory BASIC.SYSTEM. How is this possible? Am I just getting lucky? 

BASIC.system doesn't stay at $2000; it relocates itself to the space 
below $BE00 ($BE00..BEFF being BASIC.system's globals page, and 
$BF00..BFFF being ProDOS' globals page.  It then allocates some buffers 
below itself.  All of this extends downward to near $A000 or 
$9000--which is why you got "NO BUFFERS AVAILABLE" when you tried to 
load there.  BASIC.system extensions (e.g. the ProCmd stuff) push this 
even lower; so you might want to load even lower than $8000.

$2000 is getting pretty low, and will step on the end of any BASIC 
programme over 6k.  It's also the start of the first hi-res graphics 
screen, which (not including the last screen hole) ends at $3FF8.  The 
second HGR screen ends at $5FF8.  So $4000 or $6000 is a pretty safe 
load addresse for a mid-sized chunk of transient code.  It largely 
depends upon what you want to avoid trashing.

Also note that the free space is used by BASIC for variables; but if 
your code is not meant to coexist with a /running/ BASIC programme, 
that's not an issue.

As for running SYS programmes from BASIC, this is a weird thing to do, 
and can become complicated.  You can do it, and RTS from them back to 
BASIC; but RTS is not a viable way to return from a SYS programme to the 
quit (BYE) handler.  So things meant to return to BASIC may as well be 
BIN programmes (which also allows you to choose where they load--whereas 
SYS files always load at $2000.

[toc] | [prev] | [next] | [standalone]

#4985

On Sunday, January 27, 2019 at 10:41:32 PM UTC-5, Brian Patrie wrote:
> On 27/01/2019 17.04, Bill Chatfield wrote:
> > Thanks everyone for the great information. I have another related question. My "online" program (https://github.com/gungwald/online) is setup to load at $2000 and the type is SYS. But I am able to run it inside BASIC.SYSTEM, which should also be loaded at $2000. I didn't realize what I was doing when I set it up that way. But it doesn't seem to cause any corruption of the in memory BASIC.SYSTEM. How is this possible? Am I just getting lucky? 
> 
> BASIC.system doesn't stay at $2000; it relocates itself to the space 
> below $BE00 ($BE00..BEFF being BASIC.system's globals page, and 
> $BF00..BFFF being ProDOS' globals page.  It then allocates some buffers 
> below itself.  All of this extends downward to near $A000 or 
> $9000--which is why you got "NO BUFFERS AVAILABLE" when you tried to 
> load there.  BASIC.system extensions (e.g. the ProCmd stuff) push this 
> even lower; so you might want to load even lower than $8000.
> 
> $2000 is getting pretty low, and will step on the end of any BASIC 
> programme over 6k.  It's also the start of the first hi-res graphics 
> screen, which (not including the last screen hole) ends at $3FF8.  The 
> second HGR screen ends at $5FF8.  So $4000 or $6000 is a pretty safe 
> load addresse for a mid-sized chunk of transient code.  It largely 
> depends upon what you want to avoid trashing.
> 
> Also note that the free space is used by BASIC for variables; but if 
> your code is not meant to coexist with a /running/ BASIC programme, 
> that's not an issue.
> 
> As for running SYS programmes from BASIC, this is a weird thing to do, 
> and can become complicated.  You can do it, and RTS from them back to 
> BASIC; but RTS is not a viable way to return from a SYS programme to the 
> quit (BYE) handler.  So things meant to return to BASIC may as well be 
> BIN programmes (which also allows you to choose where they load--whereas 
> SYS files always load at $2000.

Great explanation. Thanks!

[toc] | [prev] | [next] | [standalone]

#4993

Great explanation!  One minor correction:

Technically,

 HGR ends at $3FF7 (not $3FF8), and
HGR2 ends at $5FF7 (not $5FF8).

i.e.
The last 8 bytes of the last page are part of the screen holes.

Michael

[toc] | [prev] | [next] | [standalone]

#4995

On 01/02/2019 01.05, Michael Pohoreski wrote:
> Great explanation!  One minor correction:
> 
> Technically,
> 
>   HGR ends at $3FF7 (not $3FF8), and
> HGR2 ends at $5FF7 (not $5FF8).
> 
> i.e.
> The last 8 bytes of the last page are part of the screen holes.
> 
> Michael

Yes, indeed!  Thanks for catching my brain malfunction!  :)

[toc] | [prev] | [next] | [standalone]

#4976

On Saturday, January 26, 2019 at 2:34:47 PM UTC-5, Antoine Vignau wrote:

> - either put your code at $9000,


This appears to result in the dreaded "NO BUFFERS AVAILABLE" error. If I load it at $8000 instead I don't get the error.

Here's some of my favorite errors. I can add "NO BUFFERS AVAILABLE" to the list:

1. General Protection Fault (Remember this?)
2. Segmentation fault
3. NullPointerException
4. Press any key to return to Windows and wait.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web