SAMS STANDARD LOADER/SAVER

[RXB]

Ok dreamed up  a new SAMS Loader and Standard.

Will be in RXB 2020C and RXB 2021 so how does it work?

 

When you load SAMS you need  3 main things for a saved files or load files.

1. Where does it load? i.e. >2000, >3000, >A000, >B000, >C000, >D000, >E000, >F000

    These are starting boundaries same thing you see in RXB 2020 PLOAD and PSAVE. i.e. CALL SAMS(2,35) would load at >2000 4K file into SAMS page 35

 

2. How many files and how do you know you are done loading 4K files into SAMS? i.e. numbering them would be best way to control how many.

 

3. What page are you loading? Well if you are numbering the files why not that page too? 

 

SAMS STANDARD LOADER/SAVER
---------------------------------------

File Format where to load. i.e. 2 or 3 or A or B or C or D or E or F

File Format file number to load is last character in any file has to be a number 0 to 9 digit value. i.e  1 or 2 or 3 or 4 or 5 or 6 or 7 or 8 or 9 or 0

All letters between First and Last character in file name are ignored, unless there is another digit in next to left of that digit. i.e. 10 or 07 or 8190

Thus the numbering of the file is also the Page that is loading.

 

EXAMPLE FILENAMES:

F0 or 2CRAP4 or 2CRAP5 or 2CRAP6 or 3SMUT126 or CJUNK16381

F0 would load at >F000 a single 4K file into SAMS page 0

2CRAP4 would load at >2000 a 4K file into SAMS page 4

2CRAP5 would load at >2000 a 4K file into SAMS page 5

2CRAP6 would load at >2000 a 4K file into SAMS page 6

3SMUT126 would load at >3000 a 4K file into SAMS page 126

CJUNK16381 would load at >C000 a 4K file into SAMS page 16381

 

The really cool thing about this is it gives us a standard for the SAMS for all uses in EA or XB.

 

Rich

 

 

[+jedimatt42]

As an end user of EA5 programs, I dislike the PARSEC, PARSED, PARSEE, PARSEF, PARSEG style of naming. 

 

I'd much rather see LVL2 direct-read access meta-data at the front of the file that indicates it is a SAMS assembly language executable, or a SAMS XB program, and then embed the instructions of what blocks of the file to load into what pages of the SAMS, and keep it all as a single file. Unfortunately this requires building more tooling. But the end user gets a single file. These could be PROGRAM images, but not loaded with LOAD. or DIS/FIX 128 files... really doesn't matter. This is what I do in Force Command for it's binary executable format which I plan to extend to SAMS, except I cheat on the tooling. I just waste a little memory by having that metadata displace the start of binary code.

 

With your approach existing tooling can build independent 4k raw binaries. ( _ there is some emoji for 'meh/shrug' _ )

 

[RXB]

1 hour ago, jedimatt42 said:

As an end user of EA5 programs, I dislike the PARSEC, PARSED, PARSEE, PARSEF, PARSEG style of naming. 

 

I'd much rather see LVL2 direct-read access meta-data at the front of the file that indicates it is a SAMS assembly language executable, or a SAMS XB program, and then embed the instructions of what blocks of the file to load into what pages of the SAMS, and keep it all as a single file. Unfortunately this requires building more tooling. But the end user gets a single file. These could be PROGRAM images, but not loaded with LOAD. or DIS/FIX 128 files... really doesn't matter. This is what I do in Force Command for it's binary executable format which I plan to extend to SAMS, except I cheat on the tooling. I just waste a little memory by having that metadata displace the start of binary code.

 

With your approach existing tooling can build independent 4k raw binaries. ( _ there is some emoji for 'meh/shrug' _ )

 

Can you explain to me how you are going to load 188K of files into the 32K at various locations and what kind of buffer are you going to use?

Secondly your approach would increase files size by a considerable amount.

As all my files are same size and small as possible what is important to the filenames to have 10 characters?

 

With my method it works for XB or EA5 or EA3 programs as after you load the SAMS memory you run the program as it is all set up.

With XB a single CALL LINK("NAME") will work or TI BASIC EA support CALL LINK("NAME") or RXB  use CALL EXECUTE(ADDRESS)

 

[+jedimatt42]

I did explain.

 

But to state it simply, read the first blocks that have the loader instructions. Then following the metadata read a subset of blocks into VDP, set SAMS pages, move to pages, read next blocks, set pages, move to pages .. 

 

File size isn't an issue.

 

I am assuming a software is written that that understands the format and does work for the user.

 

I think as I reread your proposal, you are describing a convention users execute, Using existing software loaders.

[RXB]

9 minutes ago, jedimatt42 said:

I did explain.

 

But to state it simply, read the first blocks that have the loader instructions. Then following the metadata read a subset of blocks into VDP, set SAMS pages, move to pages, read next blocks, set pages, move to pages .. 

 

File size isn't an issue.

 

I am assuming a software is written that that understands the format and does work for the user.

 

I think as I reread your proposal, you are describing a convention users execute, Using existing software loaders.

Well RXB has been around since 2001 and has had AMS / SAMS access of a Loader/Saver since RXB 2000 so 20 years would set a standard I would think?

But it only worked with >2000 and >3000 in 16K chunks still in 2015 release.

RXB 2020 has a better standard as it loads in 4K chunks anywhere in SAMS and can handle up to 32767 pages.

Of course TIPI and Hard Drives will have no issue with this other then number of files.

I have tested this with Classic99 up to 8192 pages (32 Meg SAMS) with no issues.

 

I have a kind of diagram of how this works in RXB 2020 FILENAMES:

 

        F

B      I                 N

O      L                U

U      E                M

N      N                B

D      A                E

R      M                R

Y      E                #

 _     $$$$ #####

2      NAME  PAGE#

3      NAME  PAGE#

A      NAME  PAGE#

B      NAME  PAGE#

C      NAME  PAGE#

D      NAME  PAGE#

E      NAME  PAGE#

F      NAME  PAGE#

 

The only disadvantage to this format is names get smaller per number of PAGES needed to be loaded into SAMS.

But as boundaries are a location of where everything is why would you need 10 characters or even 6 for this?

 

[+jedimatt42]

Honestly, adoption sets a standard, not precedence. So neither of us will ever be able to realize a standard. The community is so small there isn't even a need.

 

It also doesn't hurt to have a different model that distinguishes the difference between prerequisite runtime.

Edited February 14, 2021 by jedimatt42

[RXB]

9 hours ago, jedimatt42 said:

Honestly, adoption sets a standard, not precedence. So neither of us will ever be able to realize a standard. The community is so small there isn't even a need.

 

It also doesn't hurt to have a different model that distinguishes the difference between prerequisite runtime.

Faster is not always better look at the TI99/4A. Adaptability is key.

[+jedimatt42]

??? Faster ???  

[RXB]

1 hour ago, jedimatt42 said:

??? Faster ???  

It also doesn't hurt to have a different model that distinguishes the difference between prerequisite runtime.

 

 

[+Lee Stewart]

9 hours ago, RXB said:

Faster is not always better look at the TI99/4A. Adaptability is key.

 

I am pretty sure @jedimatt42’s reference to “runtime” has nothing at all to do with speed—hence his question. This is “runtime” vis-à-vis “compile time“ or “assembly time”. In this context, “runtime” has to do with when the code runs, not how fast it is.

 

...lee

[+jedimatt42]

I was too contemporary with my loose jargon. Sorry.

 

After this SAMS file or file set is loaded it may expect a runtime environment such as XB, EA, RXB or ForceCommand in our cases.

 

I was attempting to suggest it is valuable to easily tell the difference between a file set for XB vs one for RXB or something else.

 

To this end the first word in a ForceCommand executable starts with 0xFCFC, so ForceCommand can disqualify EA5 files or BASIC files easily.

 

 

[+TheBF]

23 minutes ago, jedimatt42 said:

I was too contemporary with my loose jargon. Sorry.

 

After this SAMS file or file set is loaded it may expect a runtime environment such as XB, EA, RXB or ForceCommand in our cases.

 

I was attempting to suggest it is valuable to easily tell the difference between a file set for XB vs one for RXB or something else.

 

To this end the first word in a ForceCommand executable starts with 0xFCFC, so ForceCommand can disqualify EA5 files or BASIC files easily.

 

 

Another header ID could be for Fonts perhaps?

[+jedimatt42]

"CHARA1" type fonts have an advantage by being unadorned with metadata. LOAD operation can plop them right into VDP at the character definition table, without any other processing. But I am sure big pretty fonts for The Printers Apprentice or similar programs benefit from that approach to tell fonts apart from clip-art.

[RXB]

RXB 2020 SAMS files for EA or for XB are always 16 sectors (4096 bytes)

Names always start with where they load. i.e. 2 or 3 or A or B or C or D or E or F

They always are numbered from 0 or 1 up to 32767 at far right of name.

All files can be 2 to 10 characters long.

As no file header they load faster as first byte says where to load.

The loader is an XB program so anyone can modify it or change it on a whim, nothing is fixed in stone.

[GDMike]

Using SNP, I can save/load data from a 25 or less character field, path, in tipi without issues. It works beautiful, my file names can be 1 character to 10 and even lowercase or mixed.

[RXB]

1 hour ago, GDMike said:

Using SNP, I can save/load data from a 25 or less character field, path, in tipi without issues. It works beautiful, my file names can be 1 character to 10 and even lowercase or mixed.

Cool what is SNP?

[GDMike]

10 minutes ago, RXB said:

Cool what is SNP?

Just a text editor, but it's not using DF 80 files, it's using the"Program" file structure to do it's saving, while incrementing the last character.

But saves 100 incrementing files to a tipi path of a user defined area (path must exist though). Else an error is returned.

Latest version is about to release

 

Edited February 16, 2021 by GDMike