OSS ACTION! programming language

[cas]

Yeah, I know, in Forth you can make new programming structures (like WHILE, REPEAT clauses, TYPEs and ARRAYs) and new languages. Forth was mentioned many times in ANALOG and ANTIC magazines as very powerful language but unfortunatelly user base was too small for this language to have better impact.

 

The "user" base is quite big, counting all the Sparc, IBM PPC and Apple PPC machines booting with the help of Forth out in the world (called OpenFirmware). And with the OLPC (One Laptop per Child) Project also using Forth as it's "build-in" boot language, there will be 2 million more next year.

 

Forth is not so visible in the literature, magazines, books etc. But the community is quite active. It's just that "thinking in Forth" seems not to be compatible with every programmers brain.

 

There is a lot Forth right now in Vending Machines, Cars, Satellites (NASA Solar-B, started last September, is partly operated by Forth --> http://solarb.msfc.nasa.gov/ )

[+Larry]

 

(snip)

Forth is not so visible in the literature, magazines, books etc. But the community is quite active. It's just that "thinking in Forth" seems not to be compatible with every programmers brain.

 

There is a lot Forth right now in Vending Machines, Cars, Satellites (NASA Solar-B, started last September, is partly operated by Forth --> http://solarb.msfc.nasa.gov/ )

 

I bought a couple of books and "gave it a go" in the mid-80's, but could not get past the unusual structure. Perhaps if I had been using an HP calculator (RPN), it might have been clearer to me. Or if I'd been able to take a FORTH course in school. -Larry

[dwhyte]

All this talk of Forth is bringing me back to my college days, when I was really interested in that language... I lost interest somewhere along the way (mainly due to programming PCs... Intel instruction set.... uggg)

 

So now after reading this thread, I'm a little more than interested to get back into it, this time on the A8... I downloaded Antic Forth 1.4s and... My question is... does anyone know where there's an online version of the manual? I can't seem to do anything very productive with it, like saving, loading... an explanation of how the disk based screens work... the only things I can seem to get working properly are setting the proper screens and listing them...

 

Any info regarding the usage of Antic Forth would be greatly appreciated...

 

 

Thanks...

 

 

p.s. How did an Action! thread get turned into a Forth thread?

[cas]

All this talk of Forth is bringing me back to my college days, when I was really interested in that language... I lost interest somewhere along the way (mainly due to programming PCs... Intel instruction set.... uggg)

 

So now after reading this thread, I'm a little more than interested to get back into it, this time on the A8... I downloaded Antic Forth 1.4s and... My question is... does anyone know where there's an online version of the manual? I can't seem to do anything very productive with it, like saving, loading... an explanation of how the disk based screens work... the only things I can seem to get working properly are setting the proper screens and listing them...

 

Any info regarding the usage of Antic Forth would be greatly appreciated...

 

 

Thanks...

 

ANTIC Forth is an extended FIF (Forth Intreest Group) Forth System, so every FIG-Forth manual will work.

 

ANTIC Forth comes with a Tutorial Disk, you can download the ATR here --> http://www.strotmann.de/twiki/bin/view/APG/LangForthAntic

 

to start the

Basic commands, comment in parentheses:

 

<number> LIST  ( list the screen <number>, screen number 0 has a kind of disk directory sometimes )
<from> <to> INDEX ( list 1st line of screens from -> to )
<number> LOAD ( load screen number and all following screens that end in "-->" which is the FIG Forth word for "load next screen also" )

L,N,P	  - List current,next
		  or previous screens
LL		 - List lower 1/2 of
		  current edit screen
UL		 - List upper 1/2 of
		 current edit screen
DOIT	   - Take top 16 lines
		  of screen and place
		  them into the top
		  or bottom 1/2 ( LL
		 or UL ) of the edit
		 screen.
x y COPY   - Copy block x to
		  block y. No change
		  to block x
  n LIST   - Set SCR to n and
		  list the block
x y SHOW   - List blocks x to y
		  inclusive
x y INDEX  - List first line of
		  blocks x thru y
FLUSH   - Return to FORTH voc
		  and write out all
		  updated blocks
  UPDATE   - Mark block (SCR) as
		  updated

   FAST EDIT  COMMANDS

  EDT   - same as EDITOR
  FORTH - exits EDITOR without
	   action
  n UE  - same as n EDIT UL
  n LE  - same as n EDIT LL
 N   - edit next upper scrn
 N.  - edit next lower scrn
 P   - edit prev upper scrn
 p.  - edit prev lower scrn
 T   - edit other upper scrn
	   in buffer
 T.  - edit other lower scrn
	   in buffer
 FH  - same as FLUSH
  WIPE   - clr scrn to be edited
 W	- WIPE,will respond
		with question, RETURN
		or Y will execute
  LOAD   - FLUSH scrn edited,and
		LOAD
  n LOAD - will flush and load n
  L#OFF  - off LINE # display
  L#ON   - on  LINE # display
  SOUNDOFF - remove tone cue
		(the beep heard for
		 various edit comnds)
  SOUNDON  - reset tone cue


  EDITOR LINE EDITING COMMANDS

  n TL  - Type line n	>(PAD)
  n HL  -	  line n	>(PAD)
  n DL  - Delete line n  >(PAD)
  n IL  - Insert (PAD) after n
  n RL  - Replace n with (PAD)
  n SL  - Spread at line n
  n BL  - Blank line n

  n $_  - Text following $_ will
	   replace line n and go
	   to PAD
  n %_  - Text following %_ will
	   be inserted after line
	   n and go to PAD
s n CL  - Move line n of block s
	   to PAD


*** NOTE ***

 >(PAD) : Means that line n is
	   also moved to PAD


n1 n2 n3 COPIES
	 - move scrns n1 to n2
	   to location starting
	   at scrn n3 (n1-->n3,
	   n1+1-->n3+1 etc.)
n1 n2 DUPLICATE
	 - will duplicate scrns
	   on a single drive
SYS	 - loads bootmaker and
	   related words on
	   SCREEN # $7
STACKON - turn stackdisplay on
STACKOFF- turn stackdisplay off
 NOTE:  BORDER REFLECTS # BASE
 STON   - STACKON
 STOF   - STACKOFF
 WARNON - display warning txt
 WARNOFF- just display error #
 DRAIN  - EMPTY-BUFFERS
 n1 n2 LZERO
	- CLEARS scrns n1 to n2
n SETPHYS
	- set PHYSOFF to n
RESPHYS- reset PHYSOFF to orgnl
	   value, use n STEPHYS
	  twice to chnge RESPHYS
 DCP	- DECOMP
ZZ	 - DECOMP
 x y CDUMP - dump char. x to y,
  USE LIKE BDUMP-  cont nxt scrn

 

I find the FIG Forth model a little bit problematic these days. The model is not used very often in modern forth todays, Forth 83 or ANSI Forth is much more common and you can use newer books on Forth with that Forth 83 system or ANSI Systems. Also with the block disk access, you are in a totally different world from normal Atari DOS based systems and it is hard to exchange data between the Forth and non-Forth world.

 

That is why I restarted volksForth development, to have a more modern, file-based Forth system for the Home-, Small- and Vintage-Computer community. Unfortunately the English translation of the handbook will take it's time (it is now only available in german language, version from 1989), but I'm working on it.

 

p.s. How did an Action! thread get turned into a Forth thread?

 

That's my fault, sorry. Both are interesting languages for the A8!

 

Carsten

[cas]

Any info regarding the usage of Antic Forth would be greatly appreciated...

 

MesaForth is also an A8 FIG model based Forth. It has Block I/O as well as File I/O, and the Blocks are not in Sectors but in DOS 2.x files.

 

Here is the manual (everything in the Appendix marked with "FIG" should also be the same in ANTIC Forth) --> http://www.strotmann.de/twiki/bin/view/APG/LangForthMesaDoc

 

If you want to try MesaForth, you'll find ATR Images here --> http://www.strotmann.de/twiki/bin/view/APG/LangForthMesa

 

Carsten

Edited January 13, 2007 by cas

[a8isa1]

Hi all,

 

I have a question for any Action! maestro... Finally my bigger project realized, but when I included runtime library, severe problems arised. I have never had any problems with smaller programs, but now, with a serious, bigger program, I often get Action! error number 61: Out of symbol table space. I am aware that this means I am out of stack memory resources for PROCS and variables, but what's next, what's the solution to this? A8isA1, can you please tell me again which library can be used to fix that? We talked about that, but I forgot the name of the library.

 

If those problems continue, I will maybe switch to Quick or maybe assembler. But, I like Action!, it's great.

Oops! Sorry Gury, I missed your note!

 

I'm glad Carsten was here to help you.

 

- Steve Sheppard

[Gury]

Oops! Sorry Gury, I missed your note!

 

I'm glad Carsten was here to help you.

 

- Steve Sheppard

Hehe, that's ok. Yes, he directed me into the right direction. No troubles anymore, in Action! you just have to make sure not to make unnecessary global variables, because they fill stack for global things like PROCs and FUNCs. Make local ones where ever possible. There are no other issues. There was one, with bigger source files, but it is not a problem. Just compile directly from disk.

 

I now develop libraries as needed, also runtime library is amended accordingly, depending on the program complexity.

[Gury]

Can anybody tell me about good Action! documentation describing its memory usage, local and global variable storage areas, free memory usage, etc. Everything is ok, but I have to know some more details, because some memory areas change in runtime version of the Action! program. I noticed this while creating new display list with text window area. It's no problem to directly writting to this specific areas and showing data at will properly, but the problem arised when I used standard routines (Print...) to write to text window. Its address differed in runtime version of the program, while it worked perfectly when running with Action! cartridge inserted. But ok, I just had to change text window address for the executable program not needing the cartridge. For now, I just had problems with this specific address, I will look if there are more surprises waiting for me.

 

So, if anybody has an explanation for this, please tell me. I know, it's probably simple solution, as normally is, it's just I don't know every bit of Action! functioning. As far as it goes, everything else works perfectly in this great langauge.

[cas]

Can anybody tell me about good Action! documentation describing its memory usage, local and global variable storage areas, free memory usage, etc. Everything is ok, but I have to know some more details, because some memory areas change in runtime version of the Action! program. I noticed this while creating new display list with text window area. It's no problem to directly writting to this specific areas and showing data at will properly, but the problem arised when I used standard routines (Print...) to write to text window. Its address differed in runtime version of the program, while it worked perfectly when running with Action! cartridge inserted. But ok, I just had to change text window address for the executable program not needing the cartridge. For now, I just had problems with this specific address, I will look if there are more surprises waiting for me.

 

So, if anybody has an explanation for this, please tell me. I know, it's probably simple solution, as normally is, it's just I don't know every bit of Action! functioning. As far as it goes, everything else works perfectly in this great langauge.

 

Hi Gury,

 

do you have a small code example to test?

 

Carsten

[Gury]

Deleted

Edited March 12, 2007 by Gury

[Gury]

Hi Gury,

 

do you have a small code example to test?

 

Carsten

Hi Carsten,

 

Ow jes... Sorry, my mistake. Small part of the code just slipped away from my eyes and LMS address just jumped where I told it to jump

 

The overlooked part was offset to screen memory in original DLIST, which should be used as entry point in new DLIST (created as an array variable). I mistakely used the offset in the new DLIST which was different because of different mode lines and additional LMS.

 

Sorry my talking... Action is not mistaken, it's me...

 

Anyway, I am still looking forward for good manual showing the memory map usage of Action! language. Thank you.

[whitman]

Deleted

 

I have the manual and action cartridge. I am interested in selling. Let me know.

[cas]

Anyway, I am still looking forward for good manual showing the memory map usage of Action! language. Thank you.

 

Hmm, I'm not aware of any existing documentation anything then the official handbook. Might be an exercise for further investigation.

 

Carsten

[Gury]

Deleted

 

I have the manual and action cartridge. I am interested in selling. Let me know.

whitman:

Many thanks, I will consider this offer. Please wait a little while, I will send you mail soon.

 

Cas:

It would be great if there is any, but if not, we will go with available ones. There are also some quality manuals online like the one in ABBUC newsletter, which links were changed lately.

 

http://www.spaceweb.us/news/news9501.html

http://www.spaceweb.us/news/news9502.html

http://www.spaceweb.us/news/news9503.html

http://www.spaceweb.us/news/news9504.html

http://www.spaceweb.us/news/news9506.html

http://www.spaceweb.us/news/news9507.html

http://www.spaceweb.us/news/news9508.html

http://www.spaceweb.us/news/news9510.html

http://www.spaceweb.us/news/news9511.html

http://www.spaceweb.us/news/news9512.html

http://www.spaceweb.us/news/news9601.html

http://www.spaceweb.us/news/news9602.html

http://www.spaceweb.us/news/news9603.html

[Pengwin]

p.s. How did an Action! thread get turned into a Forth thread?

 

That's my fault, sorry. Both are interesting languages for the A8!

 

Carsten

 

At the risk of hijacking this thread again, I think the Atari has such a rich and diverse range of languages. And many of those have several variants. Various Forth variants have already been mentioned, but also different C and Pascal implementations exist, and I wouldn't even like to hazard a guess at the amount of Basic interpreters and compilers that are out there.

 

I think it goes to show, once more, how versatile the Atari 8-bit was and still is. There is pretty much a language for everyone.

 

As people know, my primary language at the moment is Kyan Pascal, but when I move on to doing some games, I am probably going to use Quick or Action!. And when my son is older, if he is interested, I will teach him to program the old fashioned way, starting with Logo.

[Gury]

At the risk of hijacking this thread again, I think the Atari has such a rich and diverse range of languages. And many of those have several variants. Various Forth variants have already been mentioned, but also different C and Pascal implementations exist, and I wouldn't even like to hazard a guess at the amount of Basic interpreters and compilers that are out there.

 

I think it goes to show, once more, how versatile the Atari 8-bit was and still is. There is pretty much a language for everyone.

 

As people know, my primary language at the moment is Kyan Pascal, but when I move on to doing some games, I am probably going to use Quick or Action!. And when my son is older, if he is interested, I will teach him to program the old fashioned way, starting with Logo.

No, no, you are not hijacking here It's true, 8-bit Atari has very large base of great programming languages to go with: for the kids (Logo, Pilot), for the beginners (BASIC) and the more serious: C, Pascal, Forth, Action!, Quick and derivates of them, LISP and pure assembly language. I didn't mention all of them, so the list is even longer.

 

Pengwin, I am looking forward on the progress of your project in Kyan Pascal. Keep going. And that's good idea to introduce your son the Atari Logo, you can't go wrong.

[Gury]

Does DEFINE command take any memory? From the reading in the Action! manuals I understand it doesn't. If this is the case, DEFINE constants are normally substitution for the values, expressions and commands in compilation time. Very usable for variables as ARRAY values with element naming (to lower public variable usage) and assembler mnemonics with no extra RAM needed.

[rsh]

Has anyone built lib/proc(s) in ACTION! for accessing the 130xe extra memory banks.  Like the Basic XE commands: move srcAddr,destAddr,size,bank and  BPUT/BGET #1,start,end,bank would be kicka$$...  

Seems this would be a helpful set of functions.

 

. 

Edited December 28, 2020 by rsh

[Dmitry]

1 hour ago, rsh said:

Has anyone built lib/proc(s) in ACTION! for accessing the 130xe extra memory banks.  Like the Basic XE commands: move srcAddr,destAddr,size,bank and  BPUT/BGET #1,start,end,bank would be kicka$$...  

Seems this would be a helpful set of functions.

 

. 

 

I'm probably not helping, because i cannot specifically answer your question.  But as it happens, I typed in the Ian Chadwick Demo for accessing Antic 130xe extended memory just a few days ago..over Christmas break.  It uses regular Atari Basic.  It was kind of fun, that is, typing from a magazine again.

 

In my case, i was examining the Basic, to implement what I needed to do in Assembler.  And I found that I just had to look at the code, it was obvious enough from the demo how it works.  Which, I cannot say the same from reading the article.

I found the article to be completely incomprehensible, I think it really misdirected by talking about logical addresses that have no importance at all - it just seems to me that was the writing style in the 1980s.   I finally just had to ignore the article.  But the code is clear, poke portb give the cpu access to the bank, write your data.  Poke portb again, give antic access to read the written data, addressing never changes, just the active bank.

 

And I even found another article, that basically said don't try to use extended ram, unless you have Basic XE!  Wow!  It's no wonder it didn't catch on more, those magazine articles were highly influential.

 

 

 

[777ismyname]

@Dmitry, is this the article you are referencing? >>> https://www.atarimagazines.com/v4n7/memorymanagement.html

[576XE]

I've never programmed in Action! But I understand it's reasons etc.

As far as it's concerned EXTMEM, may be this code can help you someway...

!====================================!
! BANKS.PRG                          !
!   Using 130XE Extended Banks in    !
!     PL65 Programming Language      !
!------------------------------------!
! Evgeny Zolotarev,(aka 576XE), 2020 !
!====================================!
INCLUDE TERMINAL.LIB

!- CONSTANTS & VARIABLES:
CONST bkMask=%10010001
BYTE PORTB=$D301,NMIEN=$D40E,bkTag
INT bkNum

!- DUMMY array representing ---------!
!- selected BANK's slice ------------!
BYTE bkMem[$4000]=$4000

!- Bank Selector Values -------------!
!- Atari800WinPlus 576XE ------------!
BYTE bkSel[33]
DATA $93,
  $81,$83,$85,$87,$89,$8B,$8D,$8F,
  $A1,$A3,$A5,$A7,$A9,$AB,$AD,$AF,
  $C1,$C3,$C5,$C7,$C9,$CB,$CD,$CF,
  $E1,$E3,$E5,$E7,$E9,$EB,$ED,$EF;

!- Bank Selector Values -------------!
!- Altirra 576XE Compy scheme -------!
! BYTE bkSel[33]
! DATA $33,
!      $21,$23,$25,$27,$29,$2B,$2D,$2F,
!      $61,$63,$65,$67,$69,$6B,$6D,$6F,
!      $A1,$A3,$A5,$A7,$A9,$AB,$AD,$AF,
!      $E1,$E3,$E5,$E7,$E9,$EB,$ED,$EF;

! String VAR  to store in all BANKS
STRING inp$[4+27]
  DATA " => User DATA from Bank #00";

! Set string as VAR for appending
STRING out$[4+27]
  DATA "                           ";

!- PROCEDURES:
!- Clear Screen Procedure -----------!
PROC clrScr()
  CONST clr=255
BEGIN WRTSTR(CHR$(125)) END

!- Wait for Any Key Pressed ---------!
PROC anyKey()
  CONST none=255
  BYTE CH=764
BEGIN
  WRTSTR("Wait for a Key...") CR()
  WHILE CH=none DO ENDWHILE
  CH=none
END

!- Place bkSel Tags into PORTB ------!
PROC setBk*(BYTE bkTag)
BEGIN
!- Wrapper STOPs/STARTs IRQ & NMI ---!
  SEI LDA #$00 STA NMIEN
  LDA PORTB
  AND bkMask OR bkTag
  STA PORTB
  LDA #$40 STA NMIEN CLI
END

!- Send bkNum to setBk subroutine ---!
PROC setBank(INT bkNum)
BEGIN
  bkTag=bkSel[bkNum]
  setBk*(bkTag)
END

!- Writes to Bank -------------------!
PROC writBk()
BEGIN
  FOR bkNum=0 TO 32 DO
    WRTSTR("Writing to BANK #") WRITE(bkNum) CR()
    IF bkNum<10 THEN
      inp$[25,25]=STR$(0) inp$[26,26]=STR$(bkNum)
    ELSE inp$[25]=STR$(bkNum) ENDIF
    out$=inp$
    setBank(bkNum)
    MOVE(.out,LEN(out$),.bkMem)
  NEXT
END

!- Reads from Bank ------------------!
PROC readBk()
BEGIN
  FOR bkNum=0 TO 32 DO
    WRTSTR("Reading BANK #") WRITE(bkNum) CR()
    setBank(bkNum)
    MOVE(.bkMem,LEN(out$),.out)
    WRTSTR(out$) CR()
  NEXT
END

!------------------------------------!
MAIN()
  BYTE PORT
BEGIN
  LDA PORTB STA PORT
  clrScr() anyKey() writBk()
  anyKey() clrScr() readBk()
  LDA PORT  STA PORTB
END
! >>> EOF <<< !

 

Edited December 29, 2020 by 576XE

[+slx]

20 hours ago, rsh said:

Has anyone built lib/proc(s) in ACTION! for accessing the 130xe extra memory banks.  Like the Basic XE commands: move srcAddr,destAddr,size,bank and  BPUT/BGET #1,start,end,bank would be kicka$$...  

Seems this would be a helpful set of functions.

Atari Wiki has Action! code to use RAM under the OS. Maybe you can expand this to use more 130XE RAM. 

[rsh]

19 hours ago, Dmitry said:

 

I'm probably not helping, because i cannot specifically answer your question.  But as it happens, I typed in the Ian Chadwick Demo for accessing Antic 130xe extended memory just a few days ago..over Christmas break.  It uses regular Atari Basic.  It was kind of fun, that is, typing from a magazine again.

 

In my case, i was examining the Basic, to implement what I needed to do in Assembler.  And I found that I just had to look at the code, it was obvious enough from the demo how it works.  Which, I cannot say the same from reading the article.

I found the article to be completely incomprehensible, I think it really misdirected by talking about logical addresses that have no importance at all - it just seems to me that was the writing style in the 1980s.   I finally just had to ignore the article.  But the code is clear, poke portb give the cpu access to the bank, write your data.  Poke portb again, give antic access to read the written data, addressing never changes, just the active bank.

 

And I even found another article, that basically said don't try to use extended ram, unless you have Basic XE!  Wow!  It's no wonder it didn't catch on more, those magazine articles were highly influential.

 

 

 

Yep PORTB magic! ... I would be interested in looking at that same basic program as well.  Do you remember what/where I could get it.  I found a page but can't seem to find the full code behind it.

Edited December 29, 2020 by rsh

[rsh]

2 hours ago, 576XE said:

I've never programmed in Action! But I understand it's reasons etc.

As far as it's concerned EXTMEM, may be this code can help you someway...

!====================================!
! BANKS.PRG                          !
!   Using 130XE Extended Banks in    !
!     PL65 Programming Language      !
!------------------------------------!
! Evgeny Zolotarev,(aka 576XE), 2020 !
!====================================!
INCLUDE TERMINAL.LIB

!- CONSTANTS & VARIABLES:
CONST bkMask=%10010001
BYTE PORTB=$D301,NMIEN=$D40E,bkTag
INT bkNum

!- DUMMY array representing ---------!
!- selected BANK's slice ------------!
BYTE bkMem[$4000]=$4000

!- Bank Selector Values -------------!
!- Atari800WinPlus 576XE ------------!
BYTE bkSel[33]
DATA $93,
  $81,$83,$85,$87,$89,$8B,$8D,$8F,
  $A1,$A3,$A5,$A7,$A9,$AB,$AD,$AF,
  $C1,$C3,$C5,$C7,$C9,$CB,$CD,$CF,
  $E1,$E3,$E5,$E7,$E9,$EB,$ED,$EF;

!- Bank Selector Values -------------!
!- Altirra 576XE Compy scheme -------!
! BYTE bkSel[33]
! DATA $33,
!      $21,$23,$25,$27,$29,$2B,$2D,$2F,
!      $61,$63,$65,$67,$69,$6B,$6D,$6F,
!      $A1,$A3,$A5,$A7,$A9,$AB,$AD,$AF,
!      $E1,$E3,$E5,$E7,$E9,$EB,$ED,$EF;

! String VAR  to store in all BANKS
STRING inp$[4+27]
  DATA " => User DATA from Bank #00";

! Set string as VAR for appending
STRING out$[4+27]
  DATA "                           ";

!- PROCEDURES:
!- Clear Screen Procedure -----------!
PROC clrScr()
  CONST clr=255
BEGIN WRTSTR(CHR$(125)) END

!- Wait for Any Key Pressed ---------!
PROC anyKey()
  CONST none=255
  BYTE CH=764
BEGIN
  WRTSTR("Wait for a Key...") CR()
  WHILE CH=none DO ENDWHILE
  CH=none
END

!- Place bkSel Tags into PORTB ------!
PROC setBk*(BYTE bkTag)
BEGIN
!- Wrapper STOPs/STARTs IRQ & NMI ---!
  SEI LDA #$00 STA NMIEN
  LDA PORTB
  AND bkMask OR bkTag
  STA PORTB
  LDA #$40 STA NMIEN CLI
END

!- Send bkNum to setBk subroutine ---!
PROC setBank(INT bkNum)
BEGIN
  bkTag=bkSel[bkNum]
  setBk*(bkTag)
END

!- Writes to Bank -------------------!
PROC writBk()
BEGIN
  FOR bkNum=0 TO 32 DO
    WRTSTR("Writing to BANK #") WRITE(bkNum) CR()
    IF bkNum<10 THEN
      inp$[25,25]=STR$(0) inp$[26,26]=STR$(bkNum)
    ELSE inp$[25]=STR$(bkNum) ENDIF
    out$=inp$
    setBank(bkNum)
    MOVE(.out,LEN(out$),.bkMem)
  NEXT
END

!- Reads from Bank ------------------!
PROC readBk()
BEGIN
  FOR bkNum=0 TO 32 DO
    WRTSTR("Reading BANK #") WRITE(bkNum) CR()
    setBank(bkNum)
    MOVE(.bkMem,LEN(out$),.out)
    WRTSTR(out$) CR()
  NEXT
END

!------------------------------------!
MAIN()
  BYTE PORT
BEGIN
  LDA PORTB STA PORT
  clrScr() anyKey() writBk()
  anyKey() clrScr() readBk()
  LDA PORT  STA PORTB
END
! >>> EOF <<< !

 

Holy Smokes this might be exactly what I need.    If I can get this to work...  I will see about creating those copy lib calls like Basic XE.   Thank you this is another good place to start! appreciate it!

[rsh]

19 minutes ago, slx said:

Atari Wiki has Action! code to use RAM under the OS. Maybe you can expand this to use more 130XE RAM. 

I will tinker with this as well, thanks!  This worries me a little since I want it to work with runtime don't want any gotchas!