RXB code from beginner!

[atari1byte]

Stampa i numeri primi sbagliati...
Dove sbaglio?

 

10 h=.5
20 s=1000 !dim s(1000)
30 for j=1 to s
40 CALL LOAD(s+j,1)
45 next j
46 print "array cleared"
50 for n=2 to 1000
60 CALL PEEK(s+n,X):: IF X<h THEN 90 !if s(n)<h then goto 90
70 print n;
80 for J=n to 1000 step n
81 call load(s+u,0)
82 next j
90 next n
100 end

[RXB]

Hmm the CALL LOAD is not even remotely useful for what you are doing.

And you are loading and peeking in RAM not VDP where the variable names are stored so sorry this program is mostly nonsensical.

 

I am going to release in next update of RXB a command that will do what you are attempting to do.

So with CALL LOAD and CALL PEEK but this above program is never going to function.

 

CALL ASSIGN(numeric-variable,address) or CALL ASSIGN(string-variable,address) will do what you are trying to do in the future release, sorry hang in there.

Rich

 

 

 

[senior_falcon]

1 hour ago, atari1byte said:

Stampa i numeri primi sbagliati...   Print the wrong prime numbers...
Dove sbaglio?                                Where am I wrong?

 

A couple of points:

1 - This does not require RXB to run. Standard XB or any of the other variants will work fine.

2 - there is 8K of ram from 8192 to 16384, but the first 8 bytes cannot be used. As I noted in another post, you should start at 8200 and there are 8184 bytes available. Your program is writing to ROM and reading from ROM. Here is your program, modified to start using ram at 8200. This works properly.

I keep forgetting to add this line: 5 CALL INIT

10 H=.5 
20 S=1000 !dim s(1000)
30 FOR J=1 TO S
40 CALL LOAD(8200+J,1)
45 NEXT J
46 PRINT "array cleared" 
50 FOR N=2 TO 1000 
60 CALL PEEK(8200+N,X):: IF X<H THEN 90 !if s(n)<h then goto 90
70 PRINT N;
80 FOR J=N TO 1000 STEP N
81 CALL LOAD(8200+J,0)
82 NEXT J
90 NEXT N
100 END 

 

[senior_falcon]

As noted in a different post, you can speed up the initialization process with a simple change:

30 FOR J=0 TO S STEP 10
40 CALL LOAD(8200+J,1,1,1,1,1,1,1,1,1,1)

This will initialize about 3x faster.

I like the way the program speeds up as it runs.

 

"sorry this program is mostly nonsensical."

"this above program is never going to function."

This is awfully harsh, and not very welcoming to a newcomer. Especially when it took only a tiny change to make the program function as intended.

[atari1byte]

14 hours ago, senior_falcon said:

Un paio di punti:

1 - Questo non richiede RXB per funzionare. Standard XB o una qualsiasi delle altre varianti funzionerà bene.

2 - c'è 8K di ram da 8192 a 16384, ma i primi 8 byte non possono essere utilizzati. Come ho notato in un altro post, dovresti iniziare da 8200 e ci sono 8184 byte disponibili. Il tuo programma sta scrivendo su ROM e leggendo da ROM. Ecco il tuo programma, modificato per iniziare a usare la ram a 8200. Funziona correttamente.

Continuo a dimenticare di aggiungere questa riga: 5 CALL INIT

10 H=.5 
20 S=1000 !dim s(1000)
30 FOR J=1 TO S
40 CALL LOAD(8200+J,1)
45 NEXT J
46 PRINT "array cleared" 
50 FOR N=2 TO 1000 
60 CALL PEEK(8200+N,X):: IF X<H THEN 90 !if s(n)<h then goto 90
70 PRINT N;
80 FOR J=N TO 1000 STEP N
81 CALL LOAD(8200+J,0)
82 NEXT J
90 NEXT N
100 END 

 

WOW!!!
Thank you for helping me!
The code works great!
RXB is a little slow....
The main function of this simple code is to also see the Video Ram access speed by continuous number prints...
This code was very important for me to see the power of the programming languages of the 1980s.
I noticed that in XB it is much faster in execution....
can the performance be improved in Rxb?
Thank you all for your support!

[RXB]

6 hours ago, atari1byte said:

WOW!!!
Thank you for helping me!
The code works great!
RXB is a little slow....
The main function of this simple code is to also see the Video Ram access speed by continuous number prints...
This code was very important for me to see the power of the programming languages of the 1980s.
I noticed that in XB it is much faster in execution....
can the performance be improved in Rxb?
Thank you all for your support!

 

First off RXB does not need a CALL INIT that XB needs to use CALL LOAD so for XB had to add line 9 CALL INIT

 

Second I used the routine that Senior Falcon proposed for the XB version

30 FOR J=0 TO S STEP 10
40 CALL LOAD(8200+J,1,1,1,1,1,1,1,1,1,1)

 

Now for RXB I changed 

30 CALL LOAD(8200,1)
40 CALL MOVES("RR",1001,8200,8201) ! This is a ripple command in GPL that RXB uses it moves 8200 to 8201 then 8202 then 8203 and so on

I then ran both versions in Classic99 side by side and RXB version beat XB by a couple of seconds.

I even started XB first before RXB.

So try this and see which one is faster.

Having to do a CALL INIT in XB really slows down XB but the FOR/NEXT loop really is slow compared to RXB CALL MOVES that is way faster.

[Reciprocating Bill]

Call Moves initializes a 1000 values nigh on instantaneously. Nice.   

[HOME AUTOMATION]

After removing the corresponding...

 

45 NEXT J

[Reciprocating Bill]

Call Moves() propagates the values through RAM with a single command - without the For-Next loop. 

 

I Call Peeked and checked - it works. 

[senior_falcon]

RXB does a nice job of initializing the array. Very fast, and a nice simple instruction to do it.

XB 2.7 and beyond have CALL MOVE which can achieve the same end, and almost as fast, but the coding is not nearly as tidy.

Thinking a little differently, I noticed that after the primes 2 and 3 had modified the array there was a repeating sequence of the numbers 0,0,0,1,0,1

I modified the program to use CALL LOAD to initialize the array exactly as it would be after the primes 2 and 3 had been found. And of course I had to add PRINT 2;3; to the program.

You can see that RXB initializes super fast, but the program bogs down when dealing with the primes 2 and 3. That is not a problem with RXB, it will happen with any version of XB when you initialize the array to ones. In my modified program, the CALL LOAD  doesn't initialize as fast, but not having to deal with 2 and 3 more than makes up for that.

 

 

 

10 H=.5
20 S=1000 !dim s(1000)
30 FOR J=2 TO S STEP 18
40 CALL LOAD(8200+J,0,0,0,1,0,1,0,0,0,1,0,1,0,0,0,1,0,1)
45 NEXT J
46 PRINT "array cleared"
48 PRINT 2;3;
50 FOR N=2 TO 1000
60 CALL PEEK(8200+N,X):: IF X<H THEN 90 !if s(n)<h then goto 90
70 PRINT N;
80 FOR J=N TO 1000 STEP N
81 CALL LOAD(8200+J,0)
82 NEXT J
90 NEXT N
100 END

 

[RXB]

In RXB I would change some lines for better response:

 

10 H=.5
20 S=1000 !dim s(1000)
25 CALL LOAD(8200,0,0,0,0,0,1,0,1,0,0,0,1,0,1,0,0,0,1,0,1) ! Need to initialize 8000 and 8001
30 FOR J=2 TO S STEP 18
35 CALL MOVES("RR",18,8202,8200+J) ! First moves just overwrites first 18 bytes with same values
45 NEXT J
46 PRINT "array cleared"
48 PRINT 2;3;
50 FOR N=2 TO 1000
60 CALL PEEK(8200+N,X):: IF X<H THEN 90 !if s(n)<h then goto 90
70 PRINT N;
80 FOR J=N TO 1000 STEP N
81 CALL LOAD(8200+J,0)
82 NEXT J
90 NEXT N
100 END

Ran this in XB, XB 2.7 and  XB 2.9 vs RXB 2022 and same results even when I started RXB last.

RXB was first to finish.

[senior_falcon]

No surprise there. MOVES is going to be faster than CALL LOAD. After line 45 the programs are the same.

[senior_falcon]

Atari1byte has expressed an interest in more speed. Since he is a newcomer to the site, he may not be aware of the XB compiler and what it can do. Below is a comparison running XB 2.9 on the left and compiled XB on the right. The XB program finds the primes up to 400; the compiled program finds the primes up to 8000.

 

 

Edited July 7, 2022 by senior_falcon

[SkyPilot]

Obviously XB 2.7 and 2.9 win, but that compiled version blows everything else away.  RXB does not compile, correct?

Edited July 7, 2022 by SkyPilot

[senior_falcon]

21 minutes ago, SkyPilot said:

Obviously XB 2.7 and 2.9 win, but that compiled version blows everything else away.  RXB does not compile, correct?

Actually, when running in XB, RXB wins because MOVES  can initialize the array faster than CALL LOAD.

You could run the compiler in RXB and the prime numbers program would compile just fine. That's because the XB  program is only using the statements that are inherent to all XBs. Unfortunately, there is no support for the added CALLs unique to RXB. (For that matter, there is no support for the added calls in XB 2.9 G.E.M.)

Edited July 7, 2022 by senior_falcon

[atari1byte]

13 hours ago, senior_falcon said:

Atari1byte ha espresso interesse per una maggiore velocità. Poiché è un nuovo arrivato nel sito, potrebbe non essere a conoscenza del compilatore XB e di ciò che può fare. Di seguito è riportato un confronto che esegue XB 2.9 a sinistra e XB compilato a destra. Il programma XB trova i numeri primi fino a 400; il programma compilato trova i numeri primi fino a 8000.

 

 

thank you for information.

[RXB]

RXB is designed to run from a Console and FinalGROM cart, nothing else is needed.

Of course, this would be very limited in what you can do unless you add SAMS memory or F18 Video board.

 

My main concern is being easy to use and keeping all subprograms in RXB to be as easy to use and learn as possible.

Most commands in RXB are based on what people want to do in XB.

[RXB]

Been working on a real pain of a routine CALL VAR(numberic-variable,address)

What it does is you put in the variable like say X or TEMP or YODA and it returns the RAM or VDP address of that 8 byte Floating Point value.

So how is this useful?

 

Game plan involved SAMS RAM as the idea is to increase variables and not suck it out of 24K memory.

Here is the issue.

Any variable in XB like say you type X=9 in VDP whether in console with or 32K memory here is what happens:

 

>0001 >0000 >37D7 >FE00 >58 in VDP RAM

Length Word of variable in this case >0001 for X 

Pointer to next variable in list but in this case only one so is >0000

Pointer to variable symbols in this case >37D7 points to >58 this is the X symbol

Pointer to Floating Point address of 8 byte value >4009000000000000 this is in 9 in Floating Point format at address >FFE0 in RAM

Finally >58 is X symbol you typed in X=9 in XB

 

But wait there is the >4009000000000000 at either VDP RAM or RAM also.

This means a single X=9 takes 9 bytes of VDP RAM and 8 bytes of CPU or VDP RAM.

That is 17 bytes of memory for a single 9 in X?

Yes sounds insane to me too! 

You are screwed, unless we have CALL VAR(X,address)

 

So what if you want something like say DIM X(8000) well that is impossible as XB could only manage X(3000) and leave 10 bytes for your program!

Well back to X=9 you have that address so everything can be in X but you can use SAMS  8 bytes to save as many as you want by stepping 8 bytes each time.

This would make it possible to have a DIM X(40000) using SAMS memory instead, of course you have to switch SAMS pages but again look at the advantage.

 

Oh also CALL VAR(string-variable,address) also shows string address so looking at SAMS again for more ideas...

 

P.S. Think of using less variables as 2 variables in program can be used over and over without using program space for more.

       Instead of 17 bytes, just 8 each time.