RXB 2016

[RXB]

Well RXB 2016 is being created and will be released before 2017 begins.

 

New feature is new 24K swap using the SAMS memory card, thus allows creation of 48K XB programs running from XB memory.

What does this mean? Well now you have not one 24K for XB programs, but two 24K for XB programs!

 

Here is how it works:

 

Normal XB 24K page of RAM:

 

100 CALL CLEAR

110 X=10

120 CALL AMS24K(1000) ! Switch to new 24K and goto line 1000

130 PRINT X

140 END

 

NEW XB 24K page of RAM:

 

1000 FOR L=1 TO X

1010 NEXT X

1020 CALL AMS24K(130) ! Switch to normal 24K and goto line 130

 

Ok so how would you load these two 24K as they can not be in the same place at same time?

 

CALL AMS24K

 

Switch 24K presently in and to switch back CALL AMS24K will switch again to other.

(Notice no parenthesis for line number.)

 

Example:

OLD DSK1.APROGRM ! Load first half of program into XB.

CALL AMS24K ! Switches upper 24K to other 24K page.

OLD DSK2.BPROGRM ! Load second half of program into XB.

CALL AMS24K ! Switch upper 24K back to original 24K page.

RUN

 

So to recap we have anytime CALL AMS24K is called will switch Upper 24K RAM to other 24K page.

And CALL AMS24K(line-number) can only be used from a running program.

 

Now as for Variables it should be explained that nothing has changed other then programs size has increased, not number of variables or string space.

But DATA statements could be up to 23K in size for XP programs to use as these do not cost string space or numeric variable space.

Edited October 6, 2016 by RXB

[+Ksarul]

Hey Rich, it would be nice to be able do the CALL AMS24K from within the running program (without the line number), in addition to from the command line to allow the entire load process to occur within the program and be transparent to the eventual users. Looking at how you used it above, that may not be possible though, as the loader won't continue to run during and after the 24K context switch.

[Omega-TI]

 

New feature is new 24K swap using the SAMS memory card, thus allows creation of 48K XB programs running from XB memory.

What does this mean? Well now you have not one 24K for XB programs, but two 24K for XB programs!

 

Now this is cool! I can see this getting some use, possibly even unseating versions others may have gotten accustomed to using.

 

If it's not too late,

I'd like to request for your consideration,

one additional new feature that would make your BASIC so much easier to program...

 

... make it possible to display in 80 columns while in entry mode.

Being able to program in 80 columns, and have the screen match

the print-out would be awesome to us old timers as our eyes are not

what the used to be. Debugging would be much easier!

[+jedimatt42]

Along the lines of Ksarul's ask, can this load and switch and load be performed through the RXB batch running mechanism?

 

-M@

[+InsaneMultitasker]

How will the two programs co-exist as far as numeric variables and other VDP-space is concerned? Does this swap keep the two programs from stomping on one another, especially during prescan?

[+Ksarul]

I think Rich had already mentioned that the variables from one would be accessible to the other, at least so far as the variables that were used in both programs. The key there is to define the necessary variables up front, as there wouldn't be a prescan run when the program in the second 24K is called.

[+InsaneMultitasker]

I think Rich had already mentioned that the variables from one would be accessible to the other, at least so far as the variables that were used in both programs. The key there is to define the necessary variables up front, as there wouldn't be a prescan run when the program in the second 24K is called.

Numeric variables normally reside in the 24K space along with the program. When the second 24K is banked in, the variables from the first bank will be unavailable. It isn't clear (to me) how defining variables up front will help. Does RXB store variables differently than standard XB?

[RXB]

Hey Rich, it would be nice to be able do the CALL AMS24K from within the running program (without the line number), in addition to from the command line to allow the entire load process to occur within the program and be transparent to the eventual users. Looking at how you used it above, that may not be possible though, as the loader won't continue to run during and after the 24K context switch.

You could do a CALL AMS24K from XB but it would just assume to go to the next line, so I suppose you could do that but predicting how the program would work would amount to a

FLOW CHART NIGHTMARE!

 

And what loader are you talking about?

[RXB]

Numeric variables normally reside in the 24K space along with the program. When the second 24K is banked in, the variables from the first bank will be unavailable. It isn't clear (to me) how defining variables up front will help. Does RXB store variables differently than standard XB?

No you would have to include a switch to handle Numeric variables so both 24K would have the numeric variables.

This is why DATA statements would be a better overall way to handing massive number of Numeric Variables.

 

Let me finish my work and I can better show how it works.

[RXB]

 

Now this is cool! I can see this getting some use, possibly even unseating versions others may have gotten accustomed to using.

 

If it's not too late,

I'd like to request for your consideration,

one additional new feature that would make your BASIC so much easier to program...

 

... make it possible to display in 80 columns while in entry mode.

Being able to program in 80 columns, and have the screen match

the print-out would be awesome to us old timers as our eyes are not

what the used to be. Debugging would be much easier!

Part of the XB Editor is in the ROMs, so unless I get a disassembled listing in the ROM assembly that is a pipe dream.

I can modify the XB GPL pretty easy but the ROMs would have to be changed too.

[RXB]

I think Rich had already mentioned that the variables from one would be accessible to the other, at least so far as the variables that were used in both programs. The key there is to define the necessary variables up front, as there wouldn't be a prescan run when the program in the second 24K is called.

Actually you could run both and both be used:

 

Example: (page 1)

100 A=10 :: B=20

200 CALL AMS24K(1000)

300 PRINT A+B+C+X

400 END

 

(page 2)

1000 C=3

1010 FOR X=1 TO C

1020 PRINT X

1030 NEXT X

1040 CALL AMS24K(300)

 

See the Variable pointers were never changed so XB will search the variable table for the names A, B, C and X as Stack or Variable pointers have not changed it will find them in either program.

Even though C and X may be in page 2 memory the same spot as A and B XB always searches from >A040 first for the names and values.

 

Cool huh?

Now the only problem is if you search for a variable never established in the other page it can not find Numeric Variables in the other page thus the above program would print:

1

2

3

30

 

C and X are in second 24K so are invisible to first 24K. But this is a problem and a bonus at same time much like SUB variables are not accessible to main XB programs.

I suppose I could create a routine to pass values from one AMS24K page to the other AMS24K page.

Edited October 8, 2016 by RXB

[RXB]

Along the lines of Ksarul's ask, can this load and switch and load be performed through the RXB batch running mechanism?

 

-M@

Yes, matter of fact it would much more easy to load and run these programs from TEXT files using CALL BATCH("DSK#.FILE")

Edited October 8, 2016 by RXB

[Omega-TI]

Part of the XB Editor is in the ROMs, so unless I get a disassembled listing in the ROM assembly that is a pipe dream.

I can modify the XB GPL pretty easy but the ROMs would have to be changed too.

 

Okay. I guess that is why the 80 column Cortex BASIC is limited on space, it's all program.

[RXB]

Ok so the project to use the SAMS to swap the upper 24K does switch and does switch back but the XB Program pointers are crashing the switch.

Turns out the line pointer and variable pointers do a CRUNCH (Memory recovery) similar to a C language MALLOC routine but that resides in the XB ROMs.

 

From Command mode I can do a CALL AMS24K and it swaps the upper 24K and another command mode CALL AMS24K swaps them back.

I can write a program:

RUN

10 CALL AMS24K USING 1200

swaps 24K

1200 PRINT "PAGE 1"

crash and locks up

 

But it will crash after this if I have a program in the other upper 24K as the pointers are incorrect and it does a memory recovery and crashes system.

Will play around to see if I can make this work.

[RXB]

Made a video of how it works:

 

[Sinphaltimus]

Forgive me but it looked like you told the program to swap at line 100 but did not include a line 100. Am I misunderstanding what I'm seeing?

[RXB]

Forgive me but it looked like you told the program to swap at line 100 but did not include a line 100. Am I misunderstanding what I'm seeing?

No the problem is when I switch from one page of 24K to the other I can put a program there.

The problem is when I switch back it changes the location of the starting and ending line number table locations.

 

If both programs are exactly the same in both 24K then there is no problem, but that makes

the entire concept useless huh?

 

10 CALL CLEAR

20 CALL AMS24K USING 10

 

Other program is the same:

10 CALL CLEAR

20 CALL AMS24k USING 10

 

This works great but like I said useless.

Edited October 24, 2016 by RXB

[Sinphaltimus]

Right, I'm thinking one of the safest useful purposes would be to store different subprograms in there.

But what I meant was above you typed "using 10" but in the video you typed "using 100" (4:54 in the video) when there is no line 100 and the next error is line not found.
I found that confusing if it wasn't a typo.

Edited October 24, 2016 by Sinphaltimus

[Asmusr]

These additions are great, but I'm curious about whether it would be at all possible to make a version of RXB that supported SAMS in a way that was transparent to the user, by which I mean that you could use SAMS for programs and data without having to think about page switching at all?

[RXB]

Right, I'm thinking one of the safest useful purposes would be to store different subprograms in there.

 

But what I meant was above you typed "using 10" but in the video you typed "using 100" (4:54 in the video) when there is no line 100 and the next error is line not found.

I found that confusing if it wasn't a typo.

Again I put line 100 in to show it was looking in the other page but currently it does not work, but how I would like it to work.

 

What would be the point of showing something that just loops in a useless circle?

[RXB]

These additions are great, but I'm curious about whether it would be at all possible to make a version of RXB that supported SAMS in a way that was transparent to the user, by which I mean that you could use SAMS for programs and data without having to think about page switching at all?

Tell me how it would know what to put where?

[Sinphaltimus]

Again I put line 100 in to show it was looking in the other page but currently it does not work, but how I would like it to work.

 

What would be the point of showing something that just loops in a useless circle?

I missed the presentation. Simply not understanding it. I guess somehow the 100 line was added to one bank and not the other? That's probably what I don't get, or how the actual switch took place while typing the program. I haven't had that moment of revelation as to what exactly is going on so it seems confusing, it's new to me is all. Edited October 25, 2016 by Sinphaltimus

[Asmusr]

Tell me how it would know what to put where?

 

In the same way as 'it' is deciding to use VDP memory and/or 32K memory I guess? I have no insight in how it works, I'm only trying to get a sense of the challenges. Since it's already using two different types of memory it's tempting to think that adding a third might not be that difficult.

[RXB]

I missed the presentation. Simply not understanding it. I guess somehow the 100 line was added to one bank and not the other? That's probably what I don't get, or how the actual switch took place while typing the program. I haven't had that moment of revelation as to what exactly is going on so it seems confusing, it's new to me is all.

Yea it is confusing:

Imagine two pages of the upper 24K for XB.

I call page 0 the first one.

I call page 1 the second one.

 

CALL AMS24K will switch from one to the other and does not care which one it presently is in.

 

CALL AMS24K USING line# will do the same thing but when it gets there starts at that line number.

[RXB]

 

In the same way as 'it' is deciding to use VDP memory and/or 32K memory I guess? I have no insight in how it works, I'm only trying to get a sense of the challenges. Since it's already using two different types of memory it's tempting to think that adding a third might not be that difficult.

Normal XB has a built in routine to see if memory expansion 32K is available and if it is moves the Numeric Variables, Line number table and XB program into upper 24K.

Normal XB nothing changes with String Variables or Static Symbol Table no matter if there is a 32K available or not, they are always in VDP memory.

 

An entire rewrite of XB from scratch including the ROMs would be needed to do what you are asking using the SAMS.