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


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

Best place to hide about 30 bytes in //e RAM

Started byEgan Ford <datajerk@gmail.com>
First post2012-03-03 07:41 -0800
Last post2012-03-05 14:25 -0800
Articles 11 — 5 participants

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


Contents

  Best place to hide about 30 bytes in //e RAM Egan Ford <datajerk@gmail.com> - 2012-03-03 07:41 -0800
    Re: Best place to hide about 30 bytes in //e RAM Steven Hirsch <snhirsch@gmail.com> - 2012-03-03 14:10 -0500
      Re: Best place to hide about 30 bytes in //e RAM Hugh Hood <hughhood@earthlink.net> - 2012-03-04 17:55 -0600
        Re: Best place to hide about 30 bytes in //e RAM Hugh Hood <hughhood@earthlink.net> - 2012-03-04 17:57 -0600
          Re: Best place to hide about 30 bytes in //e RAM Egan Ford <datajerk@gmail.com> - 2012-03-05 08:55 -0700
    Re: Best place to hide about 30 bytes in //e RAM Antoine Vignau <antoine.vignau@laposte.net> - 2012-03-03 12:53 -0800
    Re: Best place to hide about 30 bytes in //e RAM "ict@ccess" <gids.rs@sasktel.net> - 2012-03-03 18:47 -0800
    Re: Best place to hide about 30 bytes in //e RAM Egan Ford <datajerk@gmail.com> - 2012-03-04 11:33 -0700
      Re: Best place to hide about 30 bytes in //e RAM "ict@ccess" <gids.rs@sasktel.net> - 2012-03-04 19:19 -0800
        Re: Best place to hide about 30 bytes in //e RAM Egan Ford <datajerk@gmail.com> - 2012-03-05 08:56 -0700
          Re: Best place to hide about 30 bytes in //e RAM Antoine Vignau <antoine.vignau@laposte.net> - 2012-03-05 14:25 -0800

#209 — Best place to hide about 30 bytes in //e RAM

FromEgan Ford <datajerk@gmail.com>
Date2012-03-03 07:41 -0800
SubjectBest place to hide about 30 bytes in //e RAM
Message-ID<jite2e$7vc$1@news.xmission.com>
Programmers,

I just created a program launcher that I'd like re-activate on 
CTRL-RESET.  I know that I have no control over the programs being 
launched and that there will be a chance that my reset vector bytes 
($3F2-$3F4) may get hosed, but in the event they do not, where is the 
least likely place someone will use memory?  I tried page $BF with the 
worse results.  Right now I am starting at $310 with good results, but 
I'd like better results if possible.

Thanks.

P.S., I should mention that this is for the //e only.  The main program 
is in AUX memory, my reset routine on CTRL-RESET copies back to main 
memory.  I cannot run from AUX memory since I use self-mod code and need 
a fresh instance on restart.

Thanks again.

[toc] | [next] | [standalone]


#210

FromSteven Hirsch <snhirsch@gmail.com>
Date2012-03-03 14:10 -0500
Message-ID<VJSdnWiZfuoI8c_SnZ2dnUVZ_vWdnZ2d@giganews.com>
In reply to#209
On 03/03/2012 10:41 AM, Egan Ford wrote:
> Programmers,
>
> I just created a program launcher that I'd like re-activate on CTRL-RESET. I
> know that I have no control over the programs being launched and that there
> will be a chance that my reset vector bytes ($3F2-$3F4) may get hosed, but in
> the event they do not, where is the least likely place someone will use
> memory? I tried page $BF with the worse results. Right now I am starting at
> $310 with good results, but I'd like better results if possible.

How about the beginning of the stack page?  IIRC, few (if any) programs get 
that close to the end.  I hacked up a modified version of the RamFast ROM that 
copied a small software loop into that location to speed things up when 
running with ZipChip or TransWarp 2e accelerators (where DMA is a 
non-starter).  Never saw a problem with stack collisions.

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


#214

FromHugh Hood <hughhood@earthlink.net>
Date2012-03-04 17:55 -0600
Message-ID<CB795D1E.8B4B%hughhood@earthlink.net>
In reply to#210
Steven,

I don't mean to step on Eagan's thread, but your idea of stealing a few
bytes from the beginning of the stack page is super nifty.

Frankly, I never considered it, until now. Thanks.

I wonder how far into that stack page a guy could go before he ran into
trouble? I guess it 'depends'. Hmmmm.

BTW, your tease about the RamFAST ROM mod just screams for more detail.

Apologies, Eagan.




Hugh Hood
 






in article VJSdnWiZfuoI8c_SnZ2dnUVZ_vWdnZ2d@giganews.com, Steven Hirsch at
snhirsch@gmail.com wrote on 3/3/12 1:10 PM:

> 
> How about the beginning of the stack page?  IIRC, few (if any) programs get
> that close to the end.  I hacked up a modified version of the RamFast ROM that
> copied a small software loop into that location to speed things up when
> running with ZipChip or TransWarp 2e accelerators (where DMA is a
> non-starter).  Never saw a problem with stack collisions.
> 

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


#215

FromHugh Hood <hughhood@earthlink.net>
Date2012-03-04 17:57 -0600
Message-ID<CB795D8E.8B4D%hughhood@earthlink.net>
In reply to#214
in article CB795D1E.8B4B%hughhood@earthlink.net, Hugh Hood at
hughhood@earthlink.net wrote on 3/4/12 5:55 PM:

> Steven,
> 
> I don't mean to step on Eagan's thread, but your idea of stealing a few
> bytes from the beginning of the stack page is super nifty.
> 
> Frankly, I never considered it, until now. Thanks.
> 
> I wonder how far into that stack page a guy could go before he ran into
> trouble? I guess it 'depends'. Hmmmm.
> 
> BTW, your tease about the RamFAST ROM mod just screams for more detail.
> 
> Apologies, Eagan.
> 
> 
> 
> 
Egan,

Apologizes again. I _will_ learn how correctly to spell your name.

Hugh...

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


#217

FromEgan Ford <datajerk@gmail.com>
Date2012-03-05 08:55 -0700
Message-ID<jj2nl0$aue$1@news.xmission.com>
In reply to#215
On 3/4/12 4:57 PM, Hugh Hood wrote:
> in article CB795D1E.8B4B%hughhood@earthlink.net, Hugh Hood at
> hughhood@earthlink.net wrote on 3/4/12 5:55 PM:
>
>> Steven,
>>
>> I don't mean to step on Eagan's thread, but your idea of stealing a few
>> bytes from the beginning of the stack page is super nifty.
>>
>> Frankly, I never considered it, until now. Thanks.
>>
>> I wonder how far into that stack page a guy could go before he ran into
>> trouble? I guess it 'depends'. Hmmmm.
>>
>> BTW, your tease about the RamFAST ROM mod just screams for more detail.
>>
>> Apologies, Eagan.
>>
>>
>>
>>
> Egan,
>
> Apologizes again. I _will_ learn how correctly to spell your name.
>
> Hugh...
>
>
No worries.  No offense taken.

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


#211

FromAntoine Vignau <antoine.vignau@laposte.net>
Date2012-03-03 12:53 -0800
Message-ID<01b412b4-0a23-42e8-a72d-3ec3ffe57b20@w19g2000vbe.googlegroups.com>
In reply to#209
Is the launcher ProDOS or DOS 3.3 based?

If it is ProDOS, use either the beginning of page 1, the first 128
bytes of pages 2 or 3.
If it is DOS 3.3 based, use the RWTS buffers from $BB00 to $BC55
unless your launcher reads sectors from disk.

In both cases, you have free room in the text screen area...

Antoine

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


#212

From"ict@ccess" <gids.rs@sasktel.net>
Date2012-03-03 18:47 -0800
Message-ID<cd0d8563-7d5b-446c-972f-9afdd91c4920@hs8g2000vbb.googlegroups.com>
In reply to#209
On Mar 3, 9:41 am, Egan Ford <dataj...@gmail.com> wrote:
> Programmers,
>
> I just created a program launcher that I'd like re-activate on
> CTRL-RESET.  I know that I have no control over the programs being
> launched and that there will be a chance that my reset vector bytes
> ($3F2-$3F4) may get hosed, but in the event they do not, where is the
> least likely place someone will use memory?  I tried page $BF with the
> worse results.  Right now I am starting at $310 with good results, but
> I'd like better results if possible.
>
> Thanks.
>
> P.S., I should mention that this is for the //e only.  The main program
> is in AUX memory, my reset routine on CTRL-RESET copies back to main
> memory.  I cannot run from AUX memory since I use self-mod code and need
> a fresh instance on restart.
>
> Thanks again.

Since you mentioned $BF, I gather you are using Prodos.  Are you using
Basic.system?
Do you still need your reset program to be safe in memory when you run
system programs?

So why not install your 30 bytes between Prodos and its buffers.

LDA #1
JSR $BEF5

The accumulator is returned with the high byte of the address where
free memory has opened up.

I have a whole page of different subroutines that I install there when
I run basic.system, so very little memory is wasted.  Anything from
keyboard shortcuts to a short program to allow the <delete> key to
work ... etc etc

OR

put your program launcher in place of the BYE routine in Prodos.  This
way any system, binary or applesoft program has access to it, since
Prodos is always in memory.


Rob

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


#213

FromEgan Ford <datajerk@gmail.com>
Date2012-03-04 11:33 -0700
Message-ID<jj0ci4$k0n$1@news.xmission.com>
In reply to#209
On 3/3/12 8:41 AM, Egan Ford wrote:
> Programmers,
>
> I just created a program launcher that I'd like re-activate on
> CTRL-RESET. I know that I have no control over the programs being
> launched and that there will be a chance that my reset vector bytes
> ($3F2-$3F4) may get hosed, but in the event they do not, where is the
> least likely place someone will use memory? I tried page $BF with the
> worse results. Right now I am starting at $310 with good results, but
> I'd like better results if possible.
>
> Thanks.
>
> P.S., I should mention that this is for the //e only. The main program
> is in AUX memory, my reset routine on CTRL-RESET copies back to main
> memory. I cannot run from AUX memory since I use self-mod code and need
> a fresh instance on restart.
>
> Thanks again.

Sorry guys, I should have provided a bit more information.  Here is a 
video of my project: 
http://asciiexpress.net/gameserver/gameserverclient.mp4.  It does not 
use DOS or ProDOS, but directly loads from disk using this tool: 
http://asciiexpress.net/files/c2d-0.1.zip.  Once loaded into memory and 
copied to AUX memory the diskette is only used if it is necessary to 
reload the program launcher from disk.  The actual program selected gets 
launched from the cassette port input.

Steven,

Yes, great idea and I tried, but too many of the games hosed the entire 
stack.

Antoine,

I started with page 3, and was mostly successful, but after reading your 
post, I switched to page 2 ($2D0)--even better, thanks!

Rob,

Thanks for the tips, but not using ProDOS.  I wanted to load the client 
as quickly as possible and opted to use directly load from diskette.

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


#216

From"ict@ccess" <gids.rs@sasktel.net>
Date2012-03-04 19:19 -0800
Message-ID<76edba60-3f0a-4516-9cb0-6c8580df3b81@s7g2000vby.googlegroups.com>
In reply to#213
>
> Thanks for the tips, but not using ProDOS.  I wanted to load the client
> as quickly as possible and opted to use directly load from diskette.

2nd try

If you are not using Dos or Prodos, that should mean then that the
area usually reserved for those OSes are available.

Such as $3D0 to $3EF.  $3F0-$3FF still can use interrupts, the reset
handler, the ampersand and ctrl-Y handler.

But there is 32 bytes that should never be trounced on due to it
normally being reserved by one of the OSes.

Rob

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


#218

FromEgan Ford <datajerk@gmail.com>
Date2012-03-05 08:56 -0700
Message-ID<jj2nmi$aue$2@news.xmission.com>
In reply to#216
On 3/4/12 8:19 PM, ict@ccess wrote:
>
>>
>> Thanks for the tips, but not using ProDOS.  I wanted to load the client
>> as quickly as possible and opted to use directly load from diskette.
>
> 2nd try
>
> If you are not using Dos or Prodos, that should mean then that the
> area usually reserved for those OSes are available.
>
> Such as $3D0 to $3EF.  $3F0-$3FF still can use interrupts, the reset
> handler, the ampersand and ctrl-Y handler.
>
> But there is 32 bytes that should never be trounced on due to it
> normally being reserved by one of the OSes.
>
> Rob

I'll give $3D0 a shot.  Thanks.

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


#219

FromAntoine Vignau <antoine.vignau@laposte.net>
Date2012-03-05 14:25 -0800
Message-ID<c2c07b59-eb27-45b2-97a5-8f2fb559c7c1@s7g2000vby.googlegroups.com>
In reply to#218
FYI, within ProDOS, $280..$2FF is reserved for the prefix buffer.
antoine

[toc] | [prev] | [standalone]


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


csiph-web