Jump to content
IGNORED

RXB - Rich Extended Basic


Bones-69

Recommended Posts

On 1/2/2020 at 12:06 PM, MikeV said:

For using RXB to write a program for AMS ramdisk support is that the new 2020 version or the existing 2015? If the latter, I will try and figure it out! Thank you.

Some real changes coming in RXB 2020.

 

When saving or loading SAMS memory instead of 8K at a time it will be 4K at a time, but in a better view you can select where it loads each time.

 

CALL MLOAD(C,"DSK4.FILENAMEC",D,"DSK4.FILENAMED") 

This would load 4K into SAMS at >C000 and 4K into SAMS at >D000

 

CALL SAMS(C,87,D,88) 

This would change SAMS page at >C000 to page 87 and change SAMS page at >D000 to 88

 

The changes allow better control of where everything is located in SAMS and loading or saving or changing pages is much easier.

Link to comment
Share on other sites

3 hours ago, RXB said:

Some real changes coming in RXB 2020.

 

When saving or loading SAMS memory instead of 8K at a time it will be 4K at a time...

 

 

Maybe it's a case of great minds think alike.  I decided that this was the best way to manage SAMS as well. 

 

Of course whenever I would say that expression my mom would "Yes but fools seldom differ." :) 

 

 

 

  • Like 1
Link to comment
Share on other sites

On 1/3/2020 at 7:03 PM, RXB said:

Some real changes coming in RXB 2020.

 

When saving or loading SAMS memory instead of 8K at a time it will be 4K at a time, but in a better view you can select where it loads each time.

 

CALL MLOAD(C,"DSK4.FILENAMEC",D,"DSK4.FILENAMED") 

This would load 4K into SAMS at >C000 and 4K into SAMS at >D000

 

CALL SAMS(C,87,D,88) 

This would change SAMS page at >C000 to page 87 and change SAMS page at >D000 to 88

 

The changes allow better control of where everything is located in SAMS and loading or saving or changing pages is much easier.

I am looking forward to the new version. In the meantime I found your xbramdisk video (and about 94 others!) on youtube and will go through the demos and examples. Thanks!

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...

Rich, I'm getting a CALL IO ERROR 90 on line 610 with this code:

CALL IO(3,1,CRU,1) !TURN ON RS232 CARD
CALL IO(3,1,CRU+7,1) !TURN ON RS232 LED
CALL IO(3,1,CRU+2,1) !SET HANDSHAKE OUT LINE TO HIGH
CALL IO(3,1,CRU+1,0) !SET PIO PORT TO OUTPUT

...

610 IF EOF(1) THEN CLOSE #1::CALL IO(3,1,CRU+7,0)::CALL IO(3,1,CRU,0)::PRINT::PRINT "TRANSFER COMPLETE!"::STOP

What the heck is IO ERROR 90? The referenced file is opened properly.

 

Now if I REM out the CALL IO statements before line 610, I get no errors.

 

Any thoughts?

Link to comment
Share on other sites

10 hours ago, Vorticon said:

Rich, I'm getting a CALL IO ERROR 90 on line 610 with this code:


CALL IO(3,1,CRU,1) !TURN ON RS232 CARD
CALL IO(3,1,CRU+7,1) !TURN ON RS232 LED
CALL IO(3,1,CRU+2,1) !SET HANDSHAKE OUT LINE TO HIGH
CALL IO(3,1,CRU+1,0) !SET PIO PORT TO OUTPUT

...


610 IF EOF(1) THEN CLOSE #1::CALL IO(3,1,CRU+7,0)::CALL IO(3,1,CRU,0)::PRINT::PRINT "TRANSFER COMPLETE!"::STOP

What the heck is IO ERROR 90? The referenced file is opened properly.

 

Now if I REM out the CALL IO statements before line 610, I get no errors.

 

Any thoughts?

Hmmm CALL IO does not use any file access to talk to RS232 card.

It uses GPL direct CRU imput/output the CRU 9901 so I am confused where there is a EOF(1) and ClOSE #1 there in line 610?

 

Link to comment
Share on other sites

9 hours ago, Lee Stewart said:

 

What if you put “CLOSE #1” after the last CALL IO()?

 

...lee

LOL OK figured out the issue! 

 

You are talking to the RS232 card with 9910 CRU and then try to talk to the DISK CONTROLLER but of course you can only talk to one DSR at a time.

Hence you have RS232 DSR turned on and using it then attempt to send/recieve data from Disk Controller card and get IO ERROR 90

IO ERROR 90 = I think is Device not found?

  • Like 2
Link to comment
Share on other sites

28 minutes ago, RXB said:

LOL OK figured out the issue! 

 

You are talking to the RS232 card with 9910 CRU and then try to talk to the DISK CONTROLLER but of course you can only talk to one DSR at a time.

Hence you have RS232 DSR turned on and using it then attempt to send/recieve data from Disk Controller card and get IO ERROR 90

IO ERROR 90 = I think is Device not found?

Ah makes sense. Easy fix: I'll just turn off the RS232 during file reads. That explains why my PIOLIB assembly routines worked with the code because each call to them shuts down the RS232 upon return to RXB.

Thanks for the explanation!

And no IO ERROR 90 is not listed in the error codes list. Don't know what it is and never seen it before.

  • Like 3
Link to comment
Share on other sites

15 hours ago, Vorticon said:

Ah makes sense. Easy fix: I'll just turn off the RS232 during file reads. That explains why my PIOLIB assembly routines worked with the code because each call to them shuts down the RS232 upon return to RXB.

Thanks for the explanation!

And no IO ERROR 90 is not listed in the error codes list. Don't know what it is and never seen it before.

Hmm Editor Assembler codes are pretty much the same for XB Error codes: 90 the 9 is left code and 0 is right code.

18.2 PERIPHERAL ACCESS BLOCK (PAB) DEFINITION
DSRs are accessed through a Peripheral Access Block (PAB). The format of the 'PAB
is the same for every peripheral. In a program that you write, the only difference
between peripherals is that some of them do not allow every option provided for in
the PAB. An example of using a PAB is given in Section 18.3.
The PABs are in VDP RAM. They are created before an OPEN statement and are
not released until the I/O for their corresponding peripheral has been closed.
The following describes the bytes which make up a PAB.
Byte -Bi t Contents Meaninq
0 All I/O Op-code The op-code for the current 110 call. See
Section 18.2.1 for a description of the op-codes.
1 All FlaglStatus All information the system needs about the file
type, mode of operation, and data type. The
meaning of the bits is described below.
0-2 Error code No error is 0. Other errors are indicated in
combination with the I/O op-code. The error
codes are discussed in Section 18.2.2.
3 Record type "Fixed length records" are 0 and "variable length
records" are 1.
4 Datatype DISPLAY is 0 and INTERNAL is 1.
5,6 Mode of UPDATE is 00, OUTPUT is 01, INPUT is 10, and
operation APPEND is 11.
7 File type "Sequential file" is 0 and "relative file" is 1.
293 All Data Buffer The address of the data buffer that the data
Address must be written to or read from in VDP memory.
4 All Logical Record The logical record length for fixed length
Length records or the maximum length for a variable
length record.
5 All Character The number of characters to be transferred
Count for a WRITE op-code or the number of bytes
actually read for a READ op-code.
EDITOR/ASSEMBLER
Page 293
FILE MANAGEMENT
Bit Contents Meaning
697 All Record Number (Only required for a relative record type file.)
The record number on which the current 110
operation is performed. The most-significant bit
is ignored, so this number can be from 0 through
32767.
8 All Screen Offset The offset of the screen characters with respect
to their normal ASCII value. This is used only
by the cassette interface, which must put prompts
on the screen.
9 All Name Length The length of the file descriptor, which starts in
byte 10.
10+ All File The device name and, i f required, the filename
Descriptor and options. The length of this descriptor is
given in byte 9.

 

Edited by RXB
missing text
Link to comment
Share on other sites

13 minutes ago, Vorticon said:

Yes I know but I don't have a description of what a left code of 9 is. The User Manual only goes to 7...

Binary of 90 = 01011010 if you check >837C this is the GPL and DSR status byte.

Binary of 0101 = Hex >5

Binary of 1010 = Hex >A 

Or Decimal 90 = Hex >5A

I think this is the result of a overflow in that DSR reports error but then GPL takes over upon return from DSR and can not resolve the issue.

XB can not find such a error value so just returns the DSR overflow error.

Think of this, XB does a GPL call to a DSR that is the wrong device, but that DSR is there despite being the wrong one requested.

GPL in XB attempts to find that DSR and the length byte is wrong, the device does not exist and wrong CRU is engaged, you are going to get everything WRONG!

 

Link to comment
Share on other sites

"I have fixed BLOAD and BSAVE in the next version of RXB they both do not use >1020 they instead work like variables and allot a location not used, also the new

versions are not 8K but 4K so less VDP space used and can load 4K into anywhere in 32K thus even use the highest line numbers of a program replacing them with 

another page with same line numbers but different lines in them.

Example would be:

32000 ! this is a data statement for lower in program

32010 DATA AB94202C6393614C

32020 DATA 345BDF94572EA753

At different page would have totally different lines, but also reside at same location with same line numbers.

Of course you have to pad the program so that the end result of these line numbers are on a 4K boundry of memory, but you have unlimited XB program sizes.

If you do this in SAMS it is instantaneous switching of pages.

 

This makes SYSTEX seem pretty archaic in comparison let alone by speed.

This new versions will allow Assembly to be loaded in upper 24K area not being used by XB programs.

Can you think of any other ways to use this?"

 

It sounds like you are reserving a 4K block of VDP ram to save/load the code. If you do this while running a large XB program that uses a lot of strings, you may not have the 4K of space required. You might think about saving in something like IV128  IF128  instead, as that could be set up to use the disk buffers or another safe location that would have no impact on the XB program.

Edited by senior_falcon
Link to comment
Share on other sites

13 hours ago, senior_falcon said:

"I have fixed BLOAD and BSAVE in the next version of RXB they both do not use >1020 they instead work like variables and allot a location not used, also the new

versions are not 8K but 4K so less VDP space used and can load 4K into anywhere in 32K thus even use the highest line numbers of a program replacing them with 

another page with same line numbers but different lines in them.

Example would be:

32000 ! this is a data statement for lower in program

32010 DATA AB94202C6393614C

32020 DATA 345BDF94572EA753

At different page would have totally different lines, but also reside at same location with same line numbers.

Of course you have to pad the program so that the end result of these line numbers are on a 4K boundry of memory, but you have unlimited XB program sizes.

If you do this in SAMS it is instantaneous switching of pages.

 

This makes SYSTEX seem pretty archaic in comparison let alone by speed.

This new versions will allow Assembly to be loaded in upper 24K area not being used by XB programs.

Can you think of any other ways to use this?"

 

It sounds like you are reserving a 4K block of VDP ram to save/load the code. If you do this while running a large XB program that uses a lot of strings, you may not have the 4K of space required. You might think about saving in something like IV128  IF128  instead, as that could be set up to use the disk buffers or another safe location that would have no impact on the XB program.

You are thinking of this all wrong.

See say I have a 100K XB program (ALL XB).

The actual program is say 3000 lines long total, now at a 4K boundry at say >C000 to >CFFF now that is XB line numbers is 8000 to 12000

I just BLOAD the 4K page at >C000 to >CFFF (XB lines 8000 to 12000 replaced each time a and I can swap this 4K pages out from the main program.

Now if all the Variables are the same and I use predefined temporary strings I have plenty of VDP memory.

Instead of strings I used mostly hard coded lines like CALL HPUT(10,12,"string of characters") and I can have numerous versions of these on command.

 

You still have 8K of VDP for Strings and temp but each time you do a CALL BLOAD it does a Garbage collection of VDP thus wiping out all the temp strings.

Of course if you have no files access you can do a CALL FILES(0) in RXB which I have also added to RXB. (It sets the pointers correctly for 0 files)

Additionally as BLOAD works with Lower 8K and also I can load Assembly support at >F000 to >FFFF for 16K of assembly in numerous pages...

The entire XB program is small but has muliple pages of the same lines at the same spot.

This would allow things like the same routine that draws screens or change variables on the fly and move back the original to be used.

 

You starting to get the drift of how much can be done?

Edited by RXB
Link to comment
Share on other sites

1 hour ago, RXB said:

You are thinking of this all wrong.

My comments were about the VDP ram and how it is used. What happens if you only have 2K memory remaining in the VDP? the answer is simple - your approach won't work because you need a 4K buffer to load your file. If you use Internal Fixed 128 format this problem goes away.

It's just a suggestion. It's up to you whether you want to spend the time to modify this so it works in every case.

Link to comment
Share on other sites

21 hours ago, senior_falcon said:

My comments were about the VDP ram and how it is used. What happens if you only have 2K memory remaining in the VDP? the answer is simple - your approach won't work because you need a 4K buffer to load your file. If you use Internal Fixed 128 format this problem goes away.

It's just a suggestion. It's up to you whether you want to spend the time to modify this so it works in every case.

First off I load all the pages into SAMS first, with out the SAMS yes this is a huge problem, which is why the 1 Meg SAMS is light years ahead of normal 32K RAM.

No you can load those areas first then the program so keeping 4K available is better then just blowing everything in one load and limiting your program size entirely.

Fixed 128 is so much slower it is not worth the use compared to Program Image.

Besides there are hundreds of Fixed 128 files so how do you tell them apart?

PGM Image are easy to spot as they are always the same size, besides number of disk access is a real slow down.

I have tested various formats for loading SAMS and by a mile PGM Image 4K and 8K chunks is way faster then any other versions by sheer size that speeds up process.

 

4K (4096 bytes) vs 128 bytes means 4096/128=32 disk reads vs 1 disk read access.

Edited by RXB
comment added
  • Like 1
Link to comment
Share on other sites

Hi Rich. I have been reading the Mini Memory manual lately to refresh my own memory re the EXPMEM2 and how it is used/ accessed. (I understand EXPMEM1 had a programming bug.) It uses some Call Load switches or lead-ins to represent the different file types: D/V, I/F, etc. Is it possible to use this approach from an XB environment to access the lower 8K or AMS memory in the same manner? Thank you (I know you are busy). MikeV.

Link to comment
Share on other sites

5 hours ago, MikeV said:

Hi Rich. I have been reading the Mini Memory manual lately to refresh my own memory re the EXPMEM2 and how it is used/ accessed. (I understand EXPMEM1 had a programming bug.) It uses some Call Load switches or lead-ins to represent the different file types: D/V, I/F, etc. Is it possible to use this approach from an XB environment to access the lower 8K or AMS memory in the same manner? Thank you (I know you are busy). MikeV.

Yea using CALL LOAD to put SAMS pages into memory, but be damn careful with that one.

There is no FILE ACCESS built into XB like Mini Memory, RXB 1000 to 1005 did have that feature but did not catch on so dumped it after 2000.

You can use something I use RAMDISK that makes the LOWER 8K into a RAMDISK, it is in my videos:

 

 

 

 

Link to comment
Share on other sites

  • 3 weeks later...
On 6/1/2019 at 6:57 AM, TheBF said:

These are really nice features Rich.

 

I am wondering about the wording in the memory display.

 

Your words. My understanding

-------------- ---------------------

37CB VDP Free Address VDP End Address

 

FFE7 Program Free Address Program End Address

A040 Program End Address Program 1st Address

 

Is this because RX BASIC builds programs downwards in memory? (ie from highest address to lowest)

 

(You have inspired me to improve the memory report in Camel Forth tools.)

All Extended Basics do this, all of them start from Lower Address in RAM (32K) and work up from >A040 to >FFEA in RAM.

RAM in lower 8K does same thing starting at lowest address after CALL INIT up to >3FFF

Now in VDP is the exact opposite as Variables and Temp data is from Top of VDP memory below number of Buffers (Normally 3).

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...